쉬운 설명
'내 컴퓨터에선 잘 되는데 서버에선 안 돼요'라는 말은 환경 차이 — 라이브러리 버전·OS·설정 — 가 다르기 때문에 생깁니다. 컨테이너는 앱과 그 환경을 한 박스에 통째로 담아 어디서 풀어도 같은 식으로 동작하게 합니다. 박스 안은 가상 머신처럼 격리돼 있어 다른 앱과 충돌하지 않습니다.
가상 머신과 비슷해 보이지만 훨씬 가볍습니다. 가상 머신은 OS 전체를 포함해 무거운 반면, 컨테이너는 호스트 OS의 커널을 빌려 쓰면서 자기 라이브러리만 별도로 가집니다. 그래서 한 서버에 컨테이너를 수십·수백 개 올릴 수 있고, 시작·종료도 1~2초면 됩니다.
동작 흐름은 단순합니다. ① 개발자가 Dockerfile에 '이 앱은 이 환경에서 이렇게 실행하라'고 적음. ② 이 파일로부터 이미지(불변 스냅샷) 생성. ③ 이미지를 컨테이너 레지스트리(Docker Hub·ECR·GCR)에 올림. ④ 어디든 그 이미지를 풀(pull)하면 같은 환경의 컨테이너가 즉시 뜸. 같은 이미지를 노트북·CI·스테이징·운영에서 똑같이 실행하는 게 컨테이너의 핵심 이점입니다.
마이크로서비스 시대의 기반 기술이 됐습니다. 한 서비스가 한 컨테이너로 패키징되고, 쿠버네티스 같은 오케스트레이션 도구가 수많은 컨테이너를 자동으로 띄우고·옮기고·죽이며 관리합니다. 컨테이너는 '실행 단위', 쿠버네티스는 '실행 단위를 관리하는 매니저'라고 보면 됩니다.
주의할 점도 있습니다. ① 이미지가 너무 커지면 배포가 느려지고 저장 비용이 듭니다. ② 보안 패치를 베이스 이미지 단계에서 챙겨야 합니다(취약점 스캔). ③ 컨테이너는 가볍지만 '진짜로 가상 머신처럼 격리'되지는 않습니다 — 같은 커널을 공유하므로 고도의 격리가 필요하면 가상 머신·전용 격리 기술이 필요합니다.
비유로 보면
컨테이너는 표준 규격 선적 컨테이너와 비슷합니다. 안에 무엇이 들었든(코드든 라이브러리든) 컨테이너 자체는 같은 모양이라, 트럭·배·기차 어디에 실어도 같은 방식으로 다룰 수 있습니다. 표준화된 박스 덕분에 글로벌 물류가 가능해졌듯, 컨테이너 덕분에 글로벌 소프트웨어 운영이 단순해졌습니다.
어디에서 만나나
거의 모든 현대 백엔드 배포의 기본 단위. 마이크로서비스 아키텍처, 머신러닝 학습 환경, CI/CD 빌드 격리, 개발자 로컬 환경 통일, 다양한 클라우드 사이의 이식성 확보. 도커는 사실상 모든 백엔드 엔지니어의 필수 도구가 됐습니다.
작은 예시
회사 신규 개발자가 노트북에 프로젝트를 받아 돌릴 때, 옛날에는 'Node 버전 16, 그런데 DB는 Postgres 14, 그리고 Redis도 깔아야...' 하며 환경을 맞추는 데 하루가 걸렸습니다. 컨테이너로 묶어 두면 'docker-compose up' 한 줄로 같은 환경이 즉시 뜹니다.
자주 하는 오해
한 줄 정리
컨테이너의 비결은 '환경의 표준화'입니다. 한 번 만든 박스가 어디서든 같은 결과를 내게 만드는 것 — 그게 마이크로서비스·CI/CD·클라우드 시대의 기반이 됐습니다.