[DevOps 기본]독커의 역사와 컨테이너란
도커(Docker)는 개발·배포·운영 모든 단계에서 효율성을 극대화한 현대 DevOps 생태계의 핵심 기술로 꼽힌다. 컨테이너라는 가벼운 실행 환경을 누구나 쉽게 활용할 수 있게 만들면서 소프트웨어 패키징 방식 자체를 바꿔 버렸다. 이 글에서는 Docker가 등장한 배경, 기존 기술과의 차이, 그리고 “컨테이너”라는 개념이 무엇을 의미하는지 상세히 알아본다.
목차
도커가 등장하기 전, 개발과 배포의 어려움
도커 이전에도 애플리케이션을 패키징하고 배포하는 수단은 존재했다. 대표적으로 가상머신(Virtual Machine), ISO 기반 패키징, 시스템 이미지 복제 방식 등이 있었다. 하지만 이 방식들은 운영체제를 통째로 포함해야 했고, 배포하는 이미지 크기는 수 GB에 달했다. 애플리케이션을 단순하게 실행하기 위해 너무 많은 리소스를 사용해야 했던 것이다.
특히 다음과 같은 문제들이 개발자와 운영자 모두를 괴롭혔다.
- 환경 불일치 문제: 개발 환경과 운영 서버의 패키지 버전 차이로 발생하는 오류
- 배포 과정 복잡성: 동일한 애플리케이션을 여러 서버에 배포할 때마다 설정이 미묘하게 달라짐
- 무거운 이미지와 긴 부팅 시간: VM은 OS 전체를 포함하므로 실행 속도가 매우 느림
- 확장성 부족: 대규모 트래픽에 대응하기 위한 빠른 확장이 어려움
이 모든 요소는 DevOps 시대가 요구하는 민첩한 배포(pipeline), 자동화 환경, 반복 가능한 인프라 관리에 큰 장애물이었다.
리눅스 컨테이너(LXC)의 등장
컨테이너 개념은 도커의 발명품이 아니다. 리눅스 커널에는 이미 오래전부터 네임스페이스(namespaces)와 cgroups(control groups)라는 기능이 있었다. 이 기능은 프로세스를 격리하고, CPU·메모리·네트워크·IO 사용량을 제한하는 목적으로 만들어졌다.
이 두 기술이 결합되어 LXC(Linux Containers) 라는 경량 가상화 기술이 등장했고, 초창기 PaaS 플랫폼(CloudFoundry, Heroku 등)은 LXC 기반 격리 기술을 활용하기도 했다.
하지만 문제는 여전히 남아 있었다.
- 컨테이너 이미지를 관리할 표준 도구가 없었고
- 개발자가 사용하기엔 너무 복잡했으며
- 실행 환경을 재현하거나 배포하기 쉽지 않았다
이 지점을 해결한 것이 바로 Docker다.
Docker의 혁신: 이미지를 정의하는 표준을 만들다
Docker는 단순히 컨테이너를 실행하는 도구가 아니라, 컨테이너 이미지를 효율적으로 만들고, 공유하고, 실행하는 모든 과정을 표준화했다.
Docker가 가져온 핵심 혁신은 아래 네 가지다.
- Dockerfile을 통한 이미지 정의 자동화
사람이 직접 설치 명령을 수행하는 대신, 코드로 이미지를 정의하도록 만들었다. - 레이어 기반 이미지 구조
기존 VM은 OS 전체가 하나의 거대한 파일이었다. Docker는 레이어 단위로 변경 사항만 저장하는 방식으로 효율성을 극대화했다. - Registry 시스템 도입
이미지를 GitHub처럼 pull/push할 수 있는 구조를 도입했다. - 모든 플랫폼에서 실행 가능한 ‘표준화된 패키지’ 제공
개발자 노트북, 스테이징 서버, 운영 서버 어디서든 동일하게 실행되었다.
이 네 가지 요소가 합쳐지면서 Docker는 단숨에 DevOps 생태계를 뒤흔든 핵심 기술이 되었다.
컨테이너란 무엇인가?
컨테이너는 애플리케이션 실행에 필요한 모든 요소를 하나의 패키지로 묶고, 격리된 환경에서 실행하는 단위이다.
컨테이너는 다음 요소를 포함한다.
- 애플리케이션 소스 코드
- 라이브러리 및 런타임
- 환경 변수
- 실행 스크립트
- 필요한 최소 OS 레이어
즉, “어디서나 동일하게 실행되는 독립적인 실행 환경”이라고 요약할 수 있다.
컨테이너와 가상머신의 차이
간단히 말해, 컨테이너는 OS 전체가 아니라 ‘프로세스 수준 격리’에 불과하다.
반면 VM은 하드웨어를 가상화하여 OS 전체를 실행한다.
| 항목 | 컨테이너 | 가상머신 |
|---|---|---|
| 가상화 방식 | 프로세스 격리 | 하드웨어 가상화 |
| OS 포함 여부 | X (호스트 OS 공유) | O |
| 이미지 크기 | 수십~수백 MB | 수 GB |
| 부팅 시간 | 거의 즉시 | 수십 초~수 분 |
| 확장성 | 매우 뛰어남 | 상대적으로 부족 |
이 차이 덕분에 컨테이너는 현대적인 DevOps 파이프라인, MSA 아키텍처, 대규모 배포 환경에서 매우 효율적이다.
Docker가 DevOps 시대의 표준이 된 이유
Docker는 개발과 운영 과정에서 가장 중요한 원칙을 충족시켰다.
- 반복 가능한 환경 제공
- 지속적 배포(CD)에 최적화된 구조
- 클라우드 네이티브 아키텍처와 완벽한 호환성
- MSA 구조와 함께 폭발적으로 성장
특히 Kubernetes가 표준 오케스트레이터가 되면서 Docker 이미지 포맷은 사실상 업계 표준이 되었다.
마무리 및 다음 편 안내
이번 글에서는 Docker가 어디서부터 시작됐고, 왜 DevOps의 핵심 기술이 되었는지 탐구했다.
다음 2편에서는 Docker가 해결한 문제들, 즉 가상머신과 컨테이너의 구조적 차이를 더 깊이 있게 다뤄본다.
