도커 (Docker) 아키텍처

핵심 인사이트 (3줄 요약)

본질: 도커 (Docker)는 클라이언트-서버 (Client-Server) 아키텍처를 기반으로 커널 수준의 격리 기술인 네임스페이스 (Namespace)와 제어 그룹 (Cgroups: Control Groups)을 추상화하여 컨테이너 수명주기를 관리하는 플랫폼이다.

가치: 애플리케이션 실행 환경을 이미지 (Image)로 규격화하여 "한 번 빌드하면 어디서든 실행 (Build Once, Run Anywhere)"할 수 있는 이식성과 하이퍼바이저 (Hypervisor) 대비 낮은 오버헤드로 높은 집적도를 제공한다.

융합: 클라우드 네이티브 (Cloud Native) 환경의 표준 실행 단위로서 쿠버네티스 (Kubernetes)와 같은 오케스트레이션 도구 및 CI/CD (Continuous Integration / Continuous Deployment) 파이프라인과 결합하여 현대적인 마이크로서비스 아키텍처 (MSA: Microservices Architecture)의 근간을 형성한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 도커 (Docker)는 리눅스 커널의 자원 격리 기능을 활용하여 애플리케이션과 그 의존성 패키지를 독립된 컨테이너 (Container) 단위로 패키징하고 배포하는 오픈소스 가상화 플랫폼이다. 하드웨어를 가상화하는 가상 머신 (VM: Virtual Machine)과 달리 호스트 OS (Operating System)의 커널을 공유하며 프로세스 수준의 격리를 제공한다.
필요성: 기존 가상화 방식은 게스트 OS (Guest OS)를 포함해야 하므로 용량이 크고 부팅 속도가 느려, 급변하는 트래픽에 대응하는 탄력적 확장이 어려웠다. 또한 개발 환경과 운영 환경의 라이브러리 버전 차이로 발생하는 "내 PC에서는 되는데 서버에선 안 된다"는 문제를 해결하기 위해 실행 환경 자체를 코드화하여 관리할 필요가 대두되었다.
💡 비유: 도커는 "표준화된 화물 컨테이너"와 같다. 화물(애플리케이션)의 종류에 상관없이 표준 규격의 컨테이너에 담기만 하면, 배(서버)나 기차(클라우드) 등 어떤 운송 수단에서도 동일한 방식으로 취급하고 적재할 수 있다.
등장 배경:
1. 가상 머신의 자원 낭비: 각 VM마다 커널을 복제 배치해야 하는 중복성 해결 필요.
2. 환경 일관성 (Environment Consistency): 개발-테스트-운영 간의 배포 불일치 해소.
3. 데브옵스 (DevOps) 가속화: 코드 기반 인프라 (IaC: Infrastructure as Code)를 통한 신속한 배포 요구.

기존 하이퍼바이저 기반 가상화와 컨테이너 기반 가상화의 구조적 차이를 시각화하면 다음과 같다. 컨테이너 방식은 하드웨어와 커널 계층의 중복을 제거하여 효율성을 극대화한다.

  ┌───────────────────────────────┐      ┌──────────────────────────────────┐
  │      가상 머신 (VM) 방식       │      │       컨테이너 (Docker) 방식    │
  ├───────────────────────────────┤      ├──────────────────────────────────┤
  │ ┌──────┐ ┌──────┐ ┌──────┐    │      │ ┌──────┐ ┌──────┐ ┌──────┐       │
  │ │ App  │ │ App  │ │ App  │    │      │ │ App  │ │ App  │ │ App  │       │
  │ ├──────┤ ├──────┤ ├──────┤    │      │ ├──────┤ ├──────┤ ├──────┤       │
  │ │ Libs │ │ Libs │ │ Libs │    │      │ │ Libs │ │ Libs │ │ Libs │       │
  │ ├──────┤ ├──────┤ ├──────┤    │      │ └──────┘ └──────┘ └──────┘       │
  │ │Guest │ │Guest │ │Guest │    │      │ ┌───────────────────────────┐    │
  │ │ OS   │ │ OS   │ │ OS   │    │      │ │      Docker Engine        │    │
  │ └──────┘ └──────┘ └──────┘    │      │ ├───────────────────────────┤    │
  │ ┌───────────────────────────┐ │      │ │      Host OS Kernel       │    │
  │ │      Hypervisor           │ │      │ └───────────────────────────┘    │
  │ ├───────────────────────────┤ │      │ ┌───────────────────────────┐    │
  │ │      Host OS / HW         │ │      │ │      Hardware             │    │
  │ └───────────────────────────┘ │      │ └───────────────────────────┘    │
  └───────────────────────────────┘      └──────────────────────────────────┘

[다이어그램 해설] 가상 머신 (VM) 방식은 하이퍼바이저 (Hypervisor) 위에서 동작하며, 각 애플리케이션마다 독립된 게스트 운영체제 (Guest OS)를 탑재해야 한다. 이는 커널과 시스템 라이브러리의 중복으로 인한 메모리 점유 및 디스크 공간 낭비를 초래한다. 반면 도커 (Docker) 방식은 호스트 운영체제 (Host OS)의 커널을 모든 컨테이너가 공유하며, 도커 엔진 (Docker Engine)이 프로세스 단위로 자원을 격리한다. 이 구조적 차이로 인해 도커 컨테이너는 VM 대비 수십 배 빠른 부팅 속도와 높은 자원 효율성을 가지며, 동일 사양의 서버에서 더 많은 인스턴스를 실행할 수 있게 한다. 하지만 커널을 공유하기 때문에 호스트 커널의 취약점이 모든 컨테이너에 영향을 줄 수 있다는 보안적 트레이드오프가 존재한다.

📢 섹션 요약 비유: 별도의 집(VM)을 짓는 대신, 하나의 큰 아파트(호스트 커널)에서 벽(네임스페이스)을 세워 각자의 방(컨테이너)을 쓰는 것과 같습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

구성 요소

요소명	역할	내부 동작	관련 기술	비유
Docker Client	사용자의 명령을 전달	REST (Representational State Transfer) API를 통해 데몬과 통신	CLI (Command Line Interface)	리모컨 버튼
Docker Daemon (dockerd)	컨테이너 관리 주체	이미지 빌드, 컨테이너 생성/실행 및 자원 할당 제어	REST API, containerd	아파트 관리소
Docker Image	컨테이너 실행에 필요한 스냅샷	읽기 전용 레이어의 적층 구조 (Layered FS)	Union Mount, OverlayFS	요리 레시피
Docker Container	이미지의 실행 인스턴스	이미지 레이어 위에 쓰기 가능한 레이어 추가	Namespace, Cgroups	실제 요리
Docker Registry	이미지 저장 및 배포소	컨테이너 이미지의 푸시(Push)/풀(Pull) 처리	Docker Hub, ECR	대형 마트 창고

도커 클라이언트-서버 모델 동작 흐름

도커는 클라이언트-서버 (Client-Server) 아키텍처를 따른다. 사용자가 클라이언트에서 명령어를 입력하면, 백그라운드에서 실행 중인 도커 데몬 (Docker Daemon)이 이를 수신하여 실제 작업을 수행한다.

  ┌───────────────────────────────────────────────────────────────┐
  │                 Docker Architecture Data Flow                 │
  ├───────────────────────────────────────────────────────────────┤
  │                                                               │
  │   [Client]                [Host (Docker Daemon)]   [Registry] │
  │      │                           │                     │      │
  │ docker build ───(REST API)────▶ Image Build            │      │
  │      │                           │                     │      │
  │ docker pull ────(REST API)────▶ Image Pull  ◀──────────┘      │
  │      │                           │      │              │      │
  │      │                    ┌──────┴──────┴─────┐        │      │
  │      │                    │  Local Image Cache│        │      │
  │      │                    └──────┬──────┬─────┘        │      │
  │ docker run ─────(REST API)────▶ Container Run          │      │
  │                                  │      │                     │
  │                          ┌───────▼──────▼──────┐              │
  │                          │  Running Containers │              │
  │                          └─────────────────────┘              │
  └───────────────────────────────────────────────────────────────┘

[다이어그램 해설] 도커의 동작은 크게 세 가지 주요 명령어로 설명된다. ① docker build는 Dockerfile을 기반으로 로컬에 새로운 이미지를 생성한다. ② docker pull은 로컬에 없는 이미지를 외부 레지스트리 (Registry)에서 다운로드하여 로컬 이미지 캐시에 저장한다. ③ docker run은 로컬 이미지 캐시의 이미지를 기반으로 격리된 프로세스인 컨테이너 (Container)를 생성하고 실행한다. 이 과정에서 도커 클라이언트와 데몬은 동일 호스트에 있을 수도 있고, 원격으로 연결될 수도 있으며 Unix Socket 또는 TCP를 통해 통신한다. 데몬은 컨테이너의 CPU, 메모리 자원 할당을 위해 커널의 제어 그룹 (Cgroups)을 설정하고, 네트워크 네임스페이스를 생성하여 독립된 IP 주소를 부여한다.

컨테이너 격리의 핵심 원리 (Namespace & Cgroups)

도커 컨테이너는 하이퍼바이저가 아닌 리눅스 커널의 두 가지 핵심 기술을 통해 격리된다. 네임스페이스 (Namespace)는 "무엇을 볼 수 있는가"를 제한하고, 제어 그룹 (Cgroups: Control Groups)은 "얼마나 쓸 수 있는가"를 제한한다.

  ┌─────────────────── 컨테이너 격리 메커니즘 ───────────────────────┐
  │                                                                  │
  │  [Namespace] : 자원 가시성 격리 (Look but don't touch)           │
  │  - mnt (파일시스템) : 컨테이너별 루트 경로 분리                  │
  │  - pid (프로세스) : 컨테이너 내 1번 프로세스로 인식              │
  │  - net (네트워크) : 독립적 IP, Port, 라우팅 테이블               │
  │  - ipc (통신) : 세마포어, 공유 메모리 격리                       │
  │  - uts (호스트명) : 컨테이너마다 다른 호스트이름 부여            │
  │                                                                  │
  │  [Cgroups] : 자원 사용량 제한 (Quota & Priority)                 │
  │  - CPU : 점유율 (Shares) 및 코어 할당 (Cpuset)                   │
  │  - Memory : 최대 가용량 제한 및 스왑 설정                        │
  │  - I/O : 디스크 읽기/쓰기 속도 (BPS/IOPS) 제어                   │
  │  - Device : 특정 하드웨어 접근 권한 제어                         │
  │                                                                  │
  └──────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 리눅스 네임스페이스 (Namespace)는 커널 수준에서 전역 자원을 추상화하여 각 프로세스 그룹이 마치 자신만의 자원을 가진 것처럼 착각하게 만든다. 예를 들어 PID 네임스페이스를 통해 컨테이너 안의 메인 프로세스는 1번 PID (Process ID)를 갖게 되지만, 호스트 입장에서 보면 수천 번대의 일반 프로세스에 불과하다. 제어 그룹 (Cgroups)은 한 컨테이너가 호스트의 모든 CPU나 메모리를 점유하여 다른 컨테이너나 호스트 시스템을 굶주리게 만드는 "시끄러운 이웃 (Noisy Neighbor)" 문제를 방지한다. 도커는 이러한 로우 레벨 기술을 사용자가 docker run -m 512m과 같은 간단한 옵션으로 제어할 수 있도록 추상화 계층을 제공하며, 이는 전통적인 가상화 대비 최소한의 오버헤드로 하드웨어 성능을 99% 이상 끌어낼 수 있게 한다.

📢 섹션 요약 비유: 네임스페이스는 각 방에 있는 사람들에게 옆방이 안 보이게 하는 "가림막"이고, Cgroups는 각 방에 공급되는 전기와 물의 양을 제한하는 "계량기"와 같습니다.

Ⅲ. 융합 비교 및 다각도 분석

가상 머신 (VM) vs 도커 컨테이너 (Container)

비교 항목	가상 머신 (VM)	도커 컨테이너 (Container)
격리 수준	하드웨어 수준 (Strong)	프로세스 수준 (Medium)
운영체제	개별 Guest OS 포함	호스트 OS 커널 공유
기동 속도	분 (Minutes) 단위	초 (Seconds) 단위
자원 효율	높음 (중복 자원 소모)	매우 높음 (필요한 만큼만 사용)
이식성	하이퍼바이저 종속적	도커 엔진만 있으면 어디서든 동일
보안성	커널 격리로 상대적 우수	커널 공유로 취약점 전파 위험

도커와 쿠버네티스 (Kubernetes)의 시너지

도커가 "단일 컨테이너"의 빌드와 실행에 집중한다면, 쿠버네티스는 수많은 도커 컨테이너들의 배포, 확장, 로드 밸런싱을 자동화하는 "오케스트레이션" 역할을 수행한다.

  ┌──────────────────────────────────────────────────────────────────┐
  │                 Docker & Kubernetes Synergy                      │
  ├──────────────────────────────────────────────────────────────────┤
  │                                                                  │
  │  [Docker] : "단일 컨테이너 표준화"                               │
  │     Dockerfile -> Image -> Container                             │
  │                                                                  │
  │             ▼ (통합 및 자동화)                                   │
  │                                                                  │
  │  [Kubernetes] : "클러스터 단위 운영 자동화"                      │
  │     - Scheduling : 빈 노드에 컨테이너 배치                       │
  │     - Self-healing : 죽은 컨테이너 자동 재시작                   │
  │     - Auto-scaling : 트래픽 증가 시 인스턴스 확장                │
  │                                                                  │
  └──────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 도커는 애플리케이션의 "패키징 규격"을 정의하여 환경 일관성을 제공한다. 하지만 실제 운영 환경에서는 수백 개의 컨테이너가 유기적으로 움직여야 하며, 특정 노드 장애 시 컨테이너를 다른 노드로 옮기거나 트래픽에 따라 숫자를 조절하는 기능이 필요하다. 쿠버네티스 (Kubernetes)는 도커 컨테이너를 관리의 기본 단위인 파드 (Pod)로 감싸서 클러스터 전체의 상태를 원하는 모습 (Desired State)으로 유지한다. 따라서 도커는 "부품 제작"을, 쿠버네티스는 "공장 라인 관리"를 담당한다고 볼 수 있으며, 이 둘의 결합을 통해 무중단 배포와 고가용성 서비스가 가능해진다.

📢 섹션 요약 비유: 도커가 잘 만들어진 "레고 블록"이라면, 쿠버네티스는 그 블록들을 조립하고 무너지면 다시 고쳐주는 "전문 조립가"와 같습니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오 및 해결 방안

이미지 크기 비대화 문제: 빌드 환경의 도구들이 최종 이미지에 포함되어 용량이 수 GB로 늘어나는 경우.
- 해결: 멀티 스테이지 빌드 (Multi-stage Build)를 도입하여 빌드용 이미지와 실행용 이미지를 분리한다. 이를 통해 최종 이미지에는 실행 바이너리만 남겨 보안성과 전송 속도를 확보한다.
컨테이너 데이터 휘발성 문제: 컨테이너 삭제 시 내부 데이터가 함께 사라지는 문제.
- 해결: 도커 볼륨 (Volume)이나 바인드 마운트 (Bind Mount)를 사용하여 데이터를 호스트 시스템이나 외부 스토리지에 영구 저장한다.
특권 권한 (Privileged) 남용에 따른 보안 사고: 컨테이너에 호스트의 모든 장치 접근 권한을 부여하여 보안이 뚫리는 경우.
- 해결: 최소 권한 원칙 (Least Privilege)에 따라 필요한 기능 (Capabilities)만 부여하고, non-root 사용자로 컨테이너를 실행한다.

도커 도입 의사결정 트리

  ┌────────────────────────────────────────────────────────────────┐
  │               Docker Adoption Decision Tree                    │
  ├────────────────────────────────────────────────────────────────┤
  │                                                                │
  │   애플리케이션 배포 속도가 느린가? ──────▶ [YES] ──┐           │
  │                                                     │          │
  │   환경 설정 차이로 오류가 잦은가? ──────▶ [YES] ──┼──▶ [도커 도입]
  │                                                     │          │
  │   서버 자원 활용률이 낮은가? ──────────▶ [YES] ──┘             │
  │                                                                │
  │   [고려사항]                                                   │
  │   - 커널 버전 종속성이 강한가? (VM이 유리할 수 있음)           │
  │   - 보안 요구 수준이 극도로 높은가? (물리 격리 필요)           │
  │   - 윈도우/리눅스 혼합 환경인가? (도커 데스크탑 고려)          │
  │                                                                │
  └────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 도커 도입의 핵심 판단 기준은 "민첩성"과 "효율성"이다. 마이크로서비스로 전환 중이거나 빈번한 배포가 필요한 환경에서는 도커가 필수적이다. 하지만 모든 상황에서 도커가 정답은 아니다. 예를 들어 커널을 공유하기 때문에 특정 버전의 리눅스 커널 기능을 직접 제어해야 하거나, 커널 수준의 커스터마이징이 필요한 경우에는 가상 머신이나 베어메탈 (Bare-metal) 서버가 더 적합할 수 있다. 실무에서는 이러한 기술적 제약 사항과 보안 정책을 검토한 뒤, 도커를 통한 생산성 향상이 관리 복잡성 증가보다 큰지를 따져보아야 한다.

📢 섹션 요약 비유: 무조건 큰 가방(VM)을 들고 다니기보다, 필요할 때마다 작은 주머니(Container)를 꺼내 쓰는 것이 활동성 면에서 유리한 것과 같습니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	도입 전	도입 후	기대 효과
배포 속도	평균 20분 (OS 부팅 포함)	평균 1분 이내 (프로세스 실행)	95% 단축
자원 밀도	서버당 평균 5~10개 VM	서버당 평균 50~100개 컨테이너	10배 집적도 향상
운영 비용	환경 설정 오류 수정에 시간 소요	이미지 기반 일관성으로 오류 급감	유지보수 공수 50% 절감

미래 전망

WebAssembly (Wasm)와의 결합: 커널 종속성을 더욱 줄이고 보안을 강화하기 위해 Wasm 런타임을 도커에서 직접 지원하는 방향으로 진화 중이다.
Serverless Container: 인프라 관리 없이 컨테이너만 던지면 실행되는 AWS Fargate, Google Cloud Run과 같은 서버리스 형태가 주류가 될 것이다.

도커는 단순한 도구를 넘어 현대 소프트웨어 엔지니어링의 "언어"가 되었다. 이제는 단순히 컨테이너를 띄우는 법을 아는 것을 넘어, 보안(DevSecOps), 최적화(Slim Images), 그리고 거대한 오케스트레이션(Kubernetes) 생태계와의 조화를 이해하는 역량이 필수적이다.

📢 섹션 요약 비유: 과거에는 말을 타고 먼 길을 갔다면, 이제는 고속열차(도커)를 타고 목적지까지 빠르고 정확하게 이동하는 시대가 온 것입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
컨테이너런타임 (Container Runtime)	도커 엔진 아래에서 실제 컨테이너를 실행하는 로우 레벨 소프트웨어 (runc, containerd).
도커파일 (Dockerfile)	이미지를 생성하기 위한 텍스트 기반 설계도.
레이어드 파일시스템 (Layered File System)	변경 사항만 저장하여 용량을 절약하는 도커 이미지의 저장 방식.
네임스페이스 (Namespace)	프로세스 간 자원 가시성을 분리하는 리눅스 커널 기술.
제어 그룹 (Cgroups)	하드웨어 자원 할당량과 우선순위를 제어하는 리눅스 커널 기술.

👶 어린이를 위한 3줄 비유 설명

도커는 컴퓨터 안의 "투명한 보관 상자" 같아요. 게임이나 프로그램을 이 상자에 담으면 다른 컴퓨터로 옮겨도 바로 똑같이 실행할 수 있어요.
예전에는 프로그램마다 커다란 가방(VM)에 담아서 무거웠지만, 도커 상자는 아주 가벼워서 하나의 컴퓨터에 수백 개를 넣어도 괜찮아요.
이 상자 덕분에 개발자들은 "내 컴퓨터에서는 되는데 친구 컴퓨터에서는 안 돼!"라는 걱정 없이 멋진 앱을 만들 수 있게 되었답니다.