도커와 컨테이너,
왜 개발 바닥이 바뀌었나
“내 컴퓨터에서는 되는데?”
이 한마디를 없애기 위해 컨테이너가 태어났습니다.
“제 컴퓨터에서는 잘 됩니다.”
모든 개발자가 한 번은 들어본,
그리고 한 번은 말해본 문장입니다.
도커는 이 문제를 해결하기 위해 만들어졌습니다.
숫자로 보는 컨테이너 도입 추이
2013년 도커 출시 이후
컨테이너 도입률은 매년 가파르게 올라갔습니다.
컨테이너 기술 도입률 추이 (엔터프라이즈 기준, %)
출처: CNCF Annual Survey, Gartner, Datadog Container Report 종합. 2013~2017은 업계 추정치, 2018~2025는 서베이 기반
Kubernetes 프로덕션 배포율 추이 (%)
출처: CNCF Annual Survey 2021~2025. 컨테이너 사용 조직 중 K8s를 프로덕션에 운영하는 비율
핵심 수치
2013년 도커 출시 당시 컨테이너 도입률 1% 미만.
2025년 현재 92%. CNCF 조사 기준 98%의 조직이
클라우드 네이티브 기술을 어떤 형태로든 사용 중.
조직당 평균 컨테이너 수는 2023년 1,140개에서
2025년 2,341개로 2배 이상 증가.
도커가 없던 시절
2013년 이전의 개발과 배포는 이랬습니다.
개발 환경 세팅에 하루
새 팀원이 들어오면 개발 환경 구축에
반나절에서 하루가 걸렸습니다.
Python 버전, Node 버전, DB 설치,
환경변수, 라이브러리 의존성까지
위키 문서 보면서 하나하나 설치합니다.
배포할 때마다 긴장
개발 서버에서 잘 되던 코드가
운영 서버에서 안 됩니다.
원인은 보통 라이브러리 버전 차이,
OS 패키지 차이, 설정 파일 경로 차이.
“환경이 달라서”가 장애의 흔한 원인이었습니다.
서버 한 대에 여러 서비스
서버가 비쌌기 때문에
한 서버에 웹 서버, DB, 캐시, 배치 작업을
전부 올렸습니다.
하나가 메모리를 잡아먹으면 나머지가 같이 죽었습니다.
Python 2와 Python 3가 같은 서버에서 충돌했습니다.
컨테이너란 무엇인가
컨테이너를 이해하는 가장 쉬운 비유는
화물 컨테이너입니다.
화물 컨테이너가 물류를 바꾼 것처럼
과거에는 화물마다 크기와 형태가 달라서
배, 트럭, 기차에 실을 때마다 다르게 포장했습니다.
표준 컨테이너가 나오자
안에 뭐가 들었든 상관없이
어떤 운송 수단에든 실을 수 있게 됐습니다.
소프트웨어 컨테이너도 마찬가지입니다
애플리케이션과 그것이 필요로 하는 모든 것
(코드, 라이브러리, 설정, 런타임)을
하나의 패키지에 담습니다.
이 패키지는 어떤 서버에서든 동일하게 실행됩니다.
“내 컴퓨터에서는 되는데”가 사라지는 이유입니다.
가상 머신과 뭐가 다른가
“그러면 VM(가상 머신)이랑 같은 거 아닌가?”
아닙니다. 핵심 차이가 있습니다.
| 가상 머신 (VM) | 컨테이너 | |
|---|---|---|
| 격리 단위 | 하드웨어 가상화 (OS 전체) | 프로세스 격리 (OS 커널 공유) |
| 크기 | 수 GB (OS 포함) | 수십 MB (앱 + 라이브러리만) |
| 시작 시간 | 분 단위 (OS 부팅) | 초 단위 (프로세스 시작) |
| 리소스 효율 | OS마다 메모리/CPU 점유 | 커널 공유로 오버헤드 최소 |
| 비유 | 각각 독립된 집 | 같은 건물의 칸막이 사무실 |
VM은 집을 통째로 짓는 것이고,
컨테이너는 건물 안에 칸막이를 치는 것입니다.
칸막이 사무실은 벽과 문이 있어서
옆 사무실과 완전히 분리되지만,
전기, 수도, 엘리베이터(커널)는 공유합니다.
그래서 가볍고 빠릅니다.
컨테이너가 작동하는 원리
컨테이너는 마법이 아닙니다.
리눅스 커널이 원래 가지고 있는
세 가지 기술을 조합한 것입니다.
Namespace (이름공간)
“이 프로세스가 보는 세계를 제한합니다.”
컨테이너 안의 프로세스는
자기 자신만 볼 수 있습니다.
다른 컨테이너의 프로세스, 파일, 네트워크가 보이지 않습니다.
마치 서버를 혼자 쓰는 것처럼 느껴집니다.
cgroup (컨트롤 그룹)
“이 프로세스가 쓸 수 있는 자원을 제한합니다.”
CPU, 메모리, 디스크 I/O, 네트워크 대역폭을
컨테이너별로 할당합니다.
한 컨테이너가 메모리를 다 먹어도
다른 컨테이너에 영향을 주지 않습니다.
Union File System (레이어 파일시스템)
“같은 베이스를 공유하고, 차이만 저장합니다.”
Ubuntu 이미지 위에 Python을 설치하면
Ubuntu 레이어는 그대로 두고
Python만 새 레이어로 추가합니다.
같은 Ubuntu를 쓰는 컨테이너 10개가
Ubuntu를 10번 복사하지 않습니다.
그러면 도커는 뭔가
컨테이너 기술 자체는 도커 이전에도 있었습니다.
LXC, chroot 같은 리눅스 도구가 있었지만
쓰기가 어려웠습니다.
도커가 한 일은
이 복잡한 기술을 누구나 쓸 수 있게 단순화한 것입니다.
도커가 가져온 것들
· Dockerfile: 환경 구축 과정을 코드로 작성. “이 순서대로 설치하면 됩니다”가 파일 하나로
· 이미지: Dockerfile로 빌드한 결과물. 실행에 필요한 모든 것이 담긴 스냅샷
· 컨테이너: 이미지를 실행한 인스턴스. 이미지 하나로 컨테이너 100개를 띄울 수 있음
· Docker Hub: 이미지 저장소. npm이 패키지를 공유하듯, 이미지를 공유
· docker-compose: 여러 컨테이너(웹+DB+캐시)를 한 번에 정의하고 실행
도커 이전 vs 이후, 무엇이 바뀌었나
이전
· 신규 입사자 환경 구축: 반나절~하루
· 배포: 운영팀이 수동으로 파일 복사
· 롤백: “어디까지 되돌려야 하지?”
· 스케일링: 서버 구매, OS 설치, 세팅
· 테스트: “로컬에서는 됐는데...”
이후
· 환경 구축: docker compose up (5분)
· 배포: 이미지 빌드 → 푸시 → 배포 (자동화)
· 롤백: 이전 이미지 태그로 재배포 (30초)
· 스케일링: 컨테이너 수를 늘림 (초 단위)
· 테스트: 프로덕션과 동일한 컨테이너에서 실행
가장 큰 변화: “환경”이 코드가 되었다
과거에는 환경 구축이 위키 문서에 적힌
“1. Python 3.9를 설치합니다. 2. pip install...” 같은 절차였습니다.
도커 이후에는 Dockerfile이 곧 환경입니다.
코드와 함께 Git에 관리되고,
누가, 언제, 어디서 실행해도 같은 결과를 보장합니다.
실무에서 도커를 쓰는 장면
1. 개발 환경 통일
팀원 A는 Mac, B는 Windows, C는 Linux.
docker compose up 한 번이면
세 사람이 동일한 환경에서 개발합니다.
“내 컴퓨터에서는 됐는데”가 사라집니다.
2. 마이크로서비스
하나의 거대한 애플리케이션 대신
작은 서비스 여러 개로 쪼갭니다.
각 서비스가 독립된 컨테이너에서 실행됩니다.
인증 서비스는 Go로, API는 Python으로,
프론트엔드는 Node로. 언어가 달라도 상관없습니다.
3. CI/CD 파이프라인
코드를 푸시하면 자동으로
이미지를 빌드하고, 테스트를 돌리고, 배포합니다.
빌드 환경과 프로덕션 환경이 같은 이미지이므로
“빌드는 됐는데 배포가 안 돼”가 없습니다.
4. AI/ML 워크로드
CUDA 버전, PyTorch 버전, Python 버전이
모두 정확히 맞아야 하는 ML 환경에서
도커가 특히 빛납니다.
NVIDIA Container Toolkit으로
GPU까지 컨테이너에 할당할 수 있습니다.
왜 지금도 컨테이너를 도입하는가
도커가 나온 지 13년이 지난 2026년에도
컨테이너를 아직 도입하지 않은 조직이 있습니다.
도입을 고민한다면 이 질문들을 떠올려 보세요.
신규 입사자가 개발 환경을 세팅하는 데 얼마나 걸리나요?
30분 이상이면 컨테이너가 필요합니다.
개발 서버와 운영 서버의 환경이 다른가요?
다르다면 컨테이너가 이 차이를 없앱니다.
배포 후 롤백이 어렵나요?
컨테이너 이미지는 불변입니다. 이전 태그로 재배포하면 끝.
한 서버에 여러 서비스가 영향을 주고받나요?
컨테이너가 프로세스와 리소스를 격리합니다.
트래픽이 몰릴 때 서버를 빠르게 늘려야 하나요?
컨테이너는 초 단위로 복제됩니다.
그 다음 단계, 쿠버네티스
컨테이너가 1개, 2개일 때는
docker compose로 충분합니다.
하지만 컨테이너가 수십, 수백 개가 되면
“어떤 서버에서 실행할 것인가”
“죽으면 자동으로 다시 띄울 것인가”
“트래픽을 어떻게 분산할 것인가”를
관리해야 합니다.
이것을 하는 도구가 쿠버네티스(Kubernetes, K8s)입니다.
도커가 “컨테이너를 만들고 실행하는 도구”라면
쿠버네티스는 “컨테이너들을 관리하는 도구”입니다.
쿠버네티스가 하는 일
· 스케줄링: 컨테이너를 어떤 노드(서버)에서 실행할지 자동 결정
· 자동 복구: 컨테이너가 죽으면 자동으로 재시작
· 오토스케일링: 부하에 따라 컨테이너 수를 자동 증감
· 로드밸런싱: 트래픽을 여러 컨테이너에 분산
· 롤링 업데이트: 무중단으로 새 버전 배포
단계별 도입 권장
처음부터 쿠버네티스를 도입할 필요는 없습니다.
1단계: Dockerfile로 개발 환경 통일
2단계: docker compose로 로컬 + 스테이징 환경
3단계: CI/CD에서 이미지 빌드 + 자동 배포
4단계: 서비스가 10개 이상이면 쿠버네티스 검토
도커와 컨테이너는
“개발 환경과 운영 환경을 같게 만드는 도구”입니다.
이 한 가지가
개발, 테스트, 배포, 운영의 모든 단계를 바꿨습니다.
환경 구축에 하루를 쓰던 시대에서
5분이면 되는 시대로.
아직 컨테이너를 쓰지 않고 있다면
가장 먼저 해볼 일은 간단합니다.
지금 만들고 있는 프로젝트에
Dockerfile을 하나 추가해 보세요.
본 글은 리원에이스 기술개발본부가 작성한 기술 콘텐츠입니다. 외부 공유 시 출처를 명시해 주세요.
2026년 8월 19일
리원에이스 기술개발본부