도커 이미지와 컨테이너의 관계 — 실행 구조를 제대로 이해하기

 

도커 이미지는 ‘설계도’다

 

 

도커 이미지는 말 그대로 실행 환경의 설계도입니다.
내가 실행할 애플리케이션과 그 안에서 필요한 모든 설정, 패키지, 라이브러리, 실행 명령까지 하나의 묶음으로 저장한 템플릿입니다.

예를 들어 Node.js 애플리케이션을 배포한다고 해봅시다.
보통은 서버에서 Node 설치하고, npm으로 패키지를 설치하고, 실행 스크립트를 지정하죠.
하지만 도커를 쓰면 이 과정을 Dockerfile이라는 파일에 정리할 수 있습니다.

FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
CMD ["npm", "start"]

이 파일을 기반으로 docker build를 하면 이미지가 만들어집니다.
이 이미지 안에는 Node 18 버전, 앱의 코드, 의존성 정보가 전부 들어 있습니다.
이제 다른 사람이 이 이미지를 받으면, 별도의 세팅 없이 docker run 한 줄로 같은 환경을 그대로 재현할 수 있죠.

이게 바로 도커 이미지의 진짜 힘입니다.
환경을 문서가 아니라 코드로 보존한다는 점이죠.

---

컨테이너는 ‘실행 중인 인스턴스’다

이미지가 설계도라면, 컨테이너는 그 설계도를 실제로 실행한 결과물입니다.
즉, 이미지를 기반으로 “실제 동작하는 공간”을 만드는 것입니다.

docker run myapp 명령을 실행하면, 도커는 이미지로부터 새로운 컨테이너를 하나 생성하고, 그 안에서 앱을 구동시킵니다.
이 컨테이너는 완전히 독립된 환경처럼 동작하지만, 사실은 호스트 OS의 커널을 공유하고 있습니다.
그래서 가상머신보다 훨씬 가볍고 빠릅니다.

컨테이너 안에서 파일을 수정하거나 로그를 남기면, 그것은 이미지에 직접 저장되지 않습니다.
컨테이너는 실행 중 생긴 임시 데이터만 담고 있고, 종료하면 대부분 사라집니다.
이미지는 그대로 남아 있기 때문에, 필요할 때마다 동일한 환경으로 여러 개의 컨테이너를 띄울 수 있습니다.

---

직접 써보면 감이 오는 구조

도커를 처음 실무에서 쓸 때, docker ps 명령으로 실행 중인 컨테이너를 보고, docker stop으로 종료하고, docker rm으로 지워보는 과정을 거치면 비로소 “이미지는 변하지 않는다”는 걸 체감하게 됩니다.

특히 docker commit으로 컨테이너 상태를 새로운 이미지로 저장해보면 이해가 확실히 됩니다.
한마디로 컨테이너는 이미지를 실행한 ‘복사본’이고, 거기서 무언가를 수정했다면 그건 오직 해당 컨테이너 내부의 일입니다.

저는 그 구조를 “이미지는 CD 원본, 컨테이너는 CD를 돌리고 있는 플레이어”라고 설명하곤 합니다.
같은 CD를 여러 개의 플레이어에서 동시에 돌려도 원본은 변하지 않죠.

---

흔히 하는 착각들

처음 도커를 쓸 때 가장 많이 하는 착각은 “컨테이너 안에서 수정하면 그게 이미지에 반영될 줄 안다”는 겁니다.
예를 들어 컨테이너 안에서 npm install로 라이브러리를 추가해도, 이미지에는 전혀 반영되지 않습니다.
컨테이너를 삭제하면 그 설정도 함께 사라지죠.

그 상태를 새로운 이미지로 남기려면 docker commit을 하거나, 애초에 Dockerfile을 수정해서 다시 docker build를 해야 합니다.
이 흐름을 정확히 이해하지 못하면, 도커를 쓰면서도 “왜 매번 세팅이 날아가냐”는 문제를 겪게 됩니다.

---

도커는 결국 ‘재현성’을 위한 도구

 

결국 도커의 목적은 어디서나 같은 결과를 내는 것입니다.
이미지와 컨테이너 구조는 이를 위한 수단입니다.
이미지를 통해 실행 환경을 보존하고, 컨테이너를 통해 여러 환경에서 손쉽게 실행하는 것이죠.

저는 이걸 실무에서 정말 크게 체감했습니다.
AWS EC2, 로컬 Mac, 회사의 Ubuntu 서버 — 전부 OS가 다르지만,
도커 이미지 하나만 있으면 결과는 완전히 동일했습니다.
빌드할 때의 스트레스가 사라졌고, “환경 세팅”이라는 말 자체가 거의 사라졌습니다.

---

다음으로 넘어가기 전에 정리해보자

• 이미지는 실행 전 상태, 컨테이너는 실행 중 상태
• 이미지는 변하지 않지만, 컨테이너는 언제든 만들고 지울 수 있음
• 컨테이너 안에서 한 변경은 이미지에 반영되지 않음
• 결국 도커는 **‘환경을 복제 가능한 형태로 만든다’**는 것이 핵심

이 관계만 명확히 이해하면, 도커의 70%는 이미 잡은 셈입니다.
다음 단계에서는 Dockerfile의 문법과 이미지 빌드 과정을 실제로 뜯어보면서,
이미지를 효율적으로 관리하는 방법을 자세히 다뤄보겠습니다.