김현진 블로그

컨테이너 기술은 현대 클라우드 네이티브 아키텍처의 핵심 요소로 자리 잡았습니다.
하드웨어 스펙이 고도로 향상되고 서비스 규모가 비대해짐에 따라, 컴퓨팅 자원을 극도로 효율적으로 사용하면서도 신속하게 배포할 수 있는 환경에 대한 필요성이 대두되었습니다.
이러한 흐름 속에서 탄생한 Docker와 컨테이너 기술의 핵심 개념, 그리고 내부 구동 아키텍처를 다룹니다.

Virtual Machine vs Container

순수 아키텍처 구조와 자원/보안 관점의 트레이드오프 분석

Virtual Machine

하드웨어 가상화 기반 격리 구조

VM 1

App 1

Bins / Libs

Guest OS

VM 2

App 2

Bins / Libs

Guest OS

Hypervisor

Host Operating System

Infrastructure (Hardware)

구조적 한계로 인한 트레이드오프

강점완벽한 보안 격리 (Security)

독립된 가상 하드웨어와 별도의 커널(Guest OS)을 사용합니다. 특정 VM이 해킹당하더라도 하이퍼바이저 장벽이 존재하여 호스트 OS나 다른 VM으로 위협이 전파되지 않는 매우 강력한 보안을 제공합니다.

강점자원 독점 배정 (Resource)

가상 CPU와 메모리 자원을 완전히 예약하여 물리적으로 분할 배정합니다. 한 VM의 과부하가 다른 VM의 구동 성능에 영향을 미치는 간섭(Noisy Neighbor) 현상이 원천 차단됩니다.

한계극심한 오버헤드 (Overhead)

각 애플리케이션마다 무거운 Guest OS를 중복으로 띄워야 하므로 디스크와 메모리 낭비가 심합니다(GB 단위). 또한, 부팅 속도가 느리며 OS 단위의 보안 패치 및 유지보수 공수가 크게 발생합니다.

Container

운영체제 커널 공유 기반 논리적 격리 구조

C 1

App 1

Bins / Libs

C 2

App 2

Bins / Libs

C 3

App 3

Bins / Libs

Container Engine (e.g., Docker)

Host Operating System (Shared Kernel)

Infrastructure (Hardware)

구조적 한계로 인한 트레이드오프

한계보안 격리의 취약성 (Security)

모든 컨테이너가 단일 Host OS의 커널을 논리적으로만 나누어 공유합니다. 컨테이너 내부에서 커널 취약점(Kernel Exploit) 공격 성공 시 전체 호스트와 다른 컨테이너들까지 연쇄적으로 침해당할 리스크가 존재합니다.

한계자원 경합 발생 (Resource)

기본적으로 호스트의 물리 자원을 동적으로 공유합니다. 별도의 Limit 설정(cgroups)을 하지 않으면 특정 컨테이너의 과부하가 호스트 전체의 자원을 고갈시켜 다른 서비스들을 마비시킬 수 있습니다.

강점최소 오버헤드와 민첩성 (Agility)

Guest OS가 생략되어 이미지 크기가 매우 작고(MB 단위), 시스템 콜을 직접 호스트에 전달하여 하드웨어 성능 저하가 없습니다. 부팅이 초 단위로 빠르며, 중앙 커널만 관리하면 되므로 일관된 유지보수가 가능합니다.

1. 컨테이너 기술의 부상 배경 (컴퓨팅 자원의 향상과 가상화)

1) 컴퓨팅 자원의 고도화와 가상화의 필요성

컴퓨터 하드웨어(CPU, 메모리 등) 성능이 비약적으로 향상되면서, 단일 물리 서버의 성능을 최대로 끌어올리기 위한 서버 가상화 기법이 활발히 연구되었습니다.

기존 Hypervisor 가상화(VM)의 한계: 각 가상 머신마다 독립적인 Guest OS를 포함해야 했기에 부팅이 느리고, 중복되는 OS 커널로 인해 심각한 리소스 낭비가 발생했습니다. 하드웨어 성능은 좋아졌지만, 이를 관리하기 위한 무거운 가상 OS들이 자원을 불필요하게 점유하는 병목이 발생했습니다.
컨테이너 가상화의 등장: 호스트 OS의 커널을 공유하면서 프로세스 레벨에서 완벽한 격리를 제공하는 '컨테이너 가상화'가 각광받기 시작했습니다. Guest OS가 없어 매우 가볍고, 하드웨어 자원을 극도로 효율적이며 밀도 높게 사용할 수 있게 되었습니다.

2) 초기 컨테이너 기술 한계

사실 Linux 커널에는 아주 오래전부터 격리 환경을 만들기 위한 기능들(Namespace, Cgroups 등)과 이를 활용한 초기 컨테이너 기술(LXC 등)이 존재했습니다. 하지만 초기 기술들은 사용하기가 극도로 까다롭고 복잡했습니다. 리눅스 커널 깊숙한 곳의 설정을 직접 손으로 만져야 했기에, 리눅스 시스템과 커널 구조를 완벽하게 꿰뚫고 있는 극소수의 고급 시스템 엔지니어들만 다룰 수 있는 '그림의 떡' 같은 기술이었습니다.

3) Docker의 등장과 판도의 변화

2013년 Docker의 등장은 이러한 판도를 완전히 바꾸어 놓았습니다. Docker는 어렵고 복잡했던 리눅스 커널 격리 기술을 단 몇 줄의 명령어만으로 손쉽게 다룰 수 있도록 **'표준화'**하고 **'단순화'**했습니다.

컨테이너의 이미지화: 애플리케이션 실행에 필요한 모든 환경(코드, 런타임, 라이브러리, 의존성 등)을 하나의 파일(Image)로 묶어 제공하는 표준 포맷을 정의했습니다.
압도적인 이식성: 개발 환경과 운영 환경의 불일치로 인해 발생하는 "내 컴퓨터에서는 잘 되는데 서버에서는 왜 안 되지?"라는 고질적인 문제를 완벽하게 해결했습니다. 어떤 환경이든 Docker만 설치되어 있으면 항상 동일하게 동작하게 되었습니다.

2. 컨테이너 기술이 대세가 된 시대적 배경 (3가지 트렌드)

Docker의 등장 시점은 IT 패러다임이 거대하게 전환되던 시기와 정확히 맞물렸습니다. 컨테이너가 각광받을 수밖에 없었던 시대적 배경 3가지는 다음과 같습니다.

1) 마이크로서비스 아키텍처(MSA)의 부상

과거에는 하나의 거대한 프로그램(Monolithic)을 만들었지만, 10여 년 전부터 서비스를 기능별로 작게 쪼개는 MSA가 대세가 되었습니다. 수십, 수백 개로 늘어난 작은 서비스들을 무거운 VM으로 각각 띄우는 것은 비용과 리소스 측면에서 불가능에 가까웠습니다. 이때 가볍고 빠르게 떴다 사라지는 컨테이너가 MSA를 실현할 최고의 파트너로 선택되었습니다.

2) 클라우드 컴퓨팅(Cloud Computing)과 비용 절감

AWS, Azure 같은 퍼블릭 클라우드 시장이 급성장하면서 '인프라를 사용하는 만큼 돈을 내는 시대'가 되었습니다. 기업들은 서버 리소스를 극도로 효율적으로 써야 유효한 비용 절감을 할 수 있었고, VM에 비해 CPU와 메모리를 훨씬 적게 소모하면서도 밀도 높게 애플리케이션을 구동할 수 있는 컨테이너 기술에 열광하게 되었습니다.

3) DevOps와 CI/CD(지속적 통합/배포)의 활성화

개발(Dev)과 운영(Ops)의 경계를 허물고 배포를 자동화하는 DevOps 문화가 정착되기 시작했습니다. 코드를 수정하면 몇 분 만에 빌드, 테스트, 배포까지 완료되어야 하는데, 부팅에 수 분이 걸리는 VM은 이 속도를 따라갈 수 없었습니다. 반면 수 초 만에 빌드되고 실행되는 컨테이너는 자동화 파이프라인의 핵심 엔진이 되었습니다.

요약하자면 기존의 어렵던 기술을 Docker가 쓰기 쉽게 표준화한 타이밍에, MSA, 클라우드, DevOps라는 시대적 요구와 컴퓨팅 자원 향상에 따른 효율 극대화 흐름이 맞물리면서 컨테이너 기술이 인프라의 표준으로 자리 잡게 되었습니다.

3. 컨테이너 기술의 핵심 기술 요소

Docker는 하이퍼바이저 기반의 하드웨어 가상화와 달리, 리눅스 커널의 기능을 활용한 운영체제 레벨 가상화를 제공합니다.

Namespace: 파일 시스템, 프로세스 트리, 네트워크 인터페이스 등 시스템 자원을 프로세스별로 격리하는 기능입니다. 이를 통해 각 컨테이너는 독립된 운영체제를 가진 것처럼 동작합니다.
Cgroups (Control Groups): CPU, 메모리, 디스크 I/O 등의 하드웨어 리소스 사용량을 그룹별로 할당하고 제한하는 기능입니다. 한 컨테이너가 시스템 전체 자원을 독점하는 것을 방지합니다.