minjae.log

Oct 5, 2024

by 강민재HomeInsightMemoLog

도커, 컨테이너, 커널을 지금 시점에서 이해해보기

아직 깊게 공부하기 전, “지금 내가 이해하고 있는 그림”을 기록해두고
나중에 다시 비교해보는 용도의 글입니다.

1. 가상환경: 언어 레벨 vs 시스템 레벨

내가 처음 떠올린 이미지는 이거다.

  • 언어 차원의 가상환경

    • 예: Python venv, Node.js node_modules
    • 같은 PC 안에서도 프로젝트마다 다른 라이브러리 버전을 쓰게 해주는 “논리적 공간”

  • 시스템 차원의 가상환경

    • 예: 컨테이너(container), 가상머신(virtual machine)
    • 하나의 물리 머신 위에 **여러 개의 “작은 OS 환경”**을 띄워서 서로 간섭 없이 쓰게 해준다.

내 현재 이해로는:

언어 레벨 가상환경이 “같은 방 안에서 책장만 나누는 느낌”이라면,
컨테이너는 “아예 방을 얇게 하나 더 만들어서 쓰는 느낌”에 가깝다.

2. 도커(Docker): 컨테이너를 다루는 대표적인 도구

지금 나는 도커를 이렇게 이해하고 있다.

2-1. 도커의 핵심 역할

  • 이미지(Image)
    • “이 애플리케이션을 돌리려면 필요한 파일 + 라이브러리 + 설정”을 한 번에 묶어둔 템플릿
  • 컨테이너(Container)
    • 이미지를 실제로 실행한 구체적인 인스턴스(instance)
    • 이미지 = 설계도, 컨테이너 = 그 설계도로 지은 집

도커는 기본적으로:

Build, Ship, Run
“이미지를 만들고(Build), 어디로든 옮기고(Ship), 똑같이 실행한다(Run)”를 편하게 해주는 도구

2-2. 컨테이너 vs 가상머신(Virtual Machine)

내 머릿속 이미지는 이렇다.

  • 가상머신(VM)

    • 하드웨어를 통째로 가상화
    • 각 VM 안에 완전한 OS(Operating System) 를 하나씩 설치
    • 무겁고, 부팅도 느리지만 완전히 분리된 환경

  • 컨테이너(Container)

    • 호스트 OS의 커널(kernel)을 공유
    • 필요한 라이브러리와 실행 파일만 얇게 올림
    • “OS 전체”가 아니라 “프로세스 실행 환경”만 가볍게 분리하는 느낌

그래서 도커 컨테이너는:

  • 가볍게 만들고
  • 빨리 띄우고
  • 팀원에게 그대로 공유하기 좋다.

3. 쿠버네티스(Kubernetes): 컨테이너 오케스트레이션 도구

도커로 컨테이너를 하나 둘 띄우는 단계까지는 괜찮다.
하지만 서비스가 커지면 이런 문제가 생긴다.

  • 컨테이너가 수십, 수백 개가 되면
  • “어디에 몇 개 띄워야 하지?”, “죽으면 다시 어떻게 띄우지?” 같은 관리 이슈가 터진다.

여기서 등장하는 게 쿠버네티스(Kubernetes, 흔히 K8s).

내 현재 이해:

쿠버네티스는 “여러 서버에 흩어져 있는 수많은 컨테이너를
어디에 얼마나, 언제, 어떤 규칙으로 띄울지 대신 관리해주는 시스템”

  • 자동 배포(Deployment)
  • 자동 확장(Autoscaling)
  • 장애 시 재시작(Self-healing)
  • 서비스 디스커버리(Service Discovery)

등을 알아서 해주는 컨테이너 오케스트레이션(orchestration) 플랫폼이라고 받아들이고 있다.

4. 커널(Kernel)과 운영체제(OS)

내가 적어둔 문장:

“커널은 하드웨어로 가는 길목 같다.”

이 비유가 꽤 괜찮다고 느낀다.

  • 커널(Kernel)

    • CPU, 메모리, 디스크 같은 하드웨어 자원과 직접 맞닿아서
      • 프로세스 관리
      • 메모리 관리
      • 파일 시스템
      • 드라이버
    • 등을 담당하는, OS의 “핵심 엔진”

  • 운영체제(Operating System)

    • 커널 + 각종 유틸리티(utility) + 쉘(shell), GUI 같은 사용자 인터페이스(UI, User Interface)

컨테이너가 “호스트 OS의 커널을 같이 쓴다”는 말은:

커널이라는 ‘길목’은 공유하지만, 그 위에 올라가는 프로세스와 파일 시스템 뷰는 논리적으로 나눠 쓴다
는 뜻으로 이해하고 있다.

5. 모놀리식 커널 vs 마이크로커널

내가 처음 떠올린 비유는
공산주의 vs 자유주의였는데, 조금 더 중립적으로 정리하면 이렇게 보인다.

5-1. 모놀리식 커널(Monolithic Kernel)

“중앙집권형 국가” 느낌

  • 커널 안에
    • 프로세스 관리
    • 메모리 관리
    • 파일 시스템
    • 드라이버
      같은 것들이 한 덩어리로 들어있다.
  • 장점
    • 내부 호출이 빠르고
    • 한 번 잘 짜면 성능이 좋다.
  • 단점
    • 커널이 거대하고 복잡해지며
    • 커널 안에서 문제가 나면 전체 시스템에 영향을 줄 수 있다.

5-2. 마이크로커널(Microkernel)

“분권형·연방제 국가” 느낌

  • 커널은 정말 최소한만 가지고 있다.
    • 스케줄링(scheduling)
    • IPC(Inter-Process Communication) 같은 기본 기능
  • 파일 시스템, 드라이버 등은 커널 밖의 독립 모듈로 분리
  • 장점
    • 각 기능이 분리돼 있어, 하나가 망가져도 전체 시스템이 덜 흔들린다.
    • 설계 관점에서 더 모듈화(modular)되어 있다.
  • 단점
    • 모듈 사이를 왔다 갔다 하는 통신 비용(오버헤드, overhead)이 생기고
    • 구현 난도가 올라간다.

내 현재 한 줄 정리:

모놀리식 커널: “한 건물에 모든 부서를 몰아넣은 정부청사”
마이크로커널: “기능별로 건물이 분산된 정부 캠퍼스”

6. 한 줄 요약

  • 도커(Docker)
    → “애플리케이션을 가볍게 포장해서,
    어디서든 같은 환경으로 돌릴 수 있게 해주는 컨테이너 도구”

  • 컨테이너(Container)
    → “호스트 커널을 같이 쓰면서,
    필요한 라이브러리와 실행 환경만 얇게 따로 격리하는 실행 단위”

  • 쿠버네티스(Kubernetes)
    → “컨테이너가 많아졌을 때,
    어디에 몇 개를 띄우고, 죽으면 다시 살리고, 트래픽 따라 늘리고 줄이는 자동 관리 시스템”

  • 커널(Kernel)
    → “하드웨어와 소프트웨어 사이에서
    자원을 나눠 주고, 보호하고, 스케줄링하는 운영체제의 심장”

  • 모놀리식 vs 마이크로커널
    → “모든 기능을 한 덩어리로 넣은 중앙집권형 vs
    최소 코어만 남기고 나머지는 밖으로 뺀 분권형 설계 차이”

나중에 도커와 쿠버네티스를 실제로 써보고 나면,
이 글에서 틀렸던 부분과 너무 단순화한 부분이 눈에 들어올 거다.
그때 이 글을 다시 읽으면서 “내 이해가 어떻게 업그레이드됐는지” 비교해보면 재밌을 것 같다.