관련 이미지들 여기에 두 장 골랐어요. 블로그에 이미지로 함께 넣으면 개념 전달이 더 수월해질 겁니다.
원하시면 이미지 설명 문구도 같이 만들어드릴게요.
도커를 처음 배우면 docker run 한 줄로 뭔가가 “실행된다”는 사실은 쉽게 이해되지만,
그게 이미지에서 컨테이너가 만들어지는 과정이라는 건 잘 와닿지 않습니다.
“이미지를 실행하면 컨테이너가 생긴다”라는 말을 듣긴 하지만,
그게 정확히 무슨 의미인지 직접 눈으로 보기 전까진 잘 안 잡히죠.
도커 이미지는 설계도, 컨테이너는 실제 기계

이걸 비유로 설명하면 훨씬 이해가 쉬웠습니다.
도커 이미지(Docker Image) 는 “제품을 만들기 위한 설계도”입니다.
그리고 컨테이너(Container) 는 그 설계도를 토대로 실제로 조립해서 작동 중인 제품이죠.
즉, 이미지는 절대 변하지 않습니다.
설계도가 바뀌면 새로 그려야 하듯, 이미지를 수정하려면 새로 빌드해야 합니다.
반면 컨테이너는 실행 중이기 때문에 내부에서 파일을 수정하거나 로그를 쌓을 수도 있죠.
처음엔 이 차이를 모르고 컨테이너 안에서 코드를 바꾸고 저장했는데,
다음에 docker run으로 다시 띄웠더니 모든 변경사항이 사라져 있었습니다.
그때 “아, 이미지와 컨테이너는 완전히 별개구나”라는 걸 깨달았습니다.
직접 실행해보면 확실히 다르다
터미널에서 다음 명령을 입력해보세요.
docker pull nginx
docker run -d --name my-nginx nginx
이 두 줄이 바로 “이미지 → 컨테이너” 흐름의 핵심입니다.
docker pull은 이미지를 다운로드하는 단계고,
docker run은 그 이미지를 기반으로 컨테이너를 생성하고 실행하는 단계입니다.
컨테이너 목록을 확인하면 이렇게 나옵니다.
docker ps
이때 my-nginx가 실행 중이라면, 그것은 nginx 이미지의 “실행 인스턴스”입니다.
즉, 같은 이미지를 여러 번 실행하면 동일한 환경의 컨테이너를 여러 개 띄울 수도 있습니다.
이미지를 변경하려면 다시 빌드해야 한다

처음 도커를 쓸 땐 컨테이너 안에서 바로 코드를 수정하는 경우가 많습니다.
예를 들어 docker exec -it my-nginx /bin/bash로 들어가서
index.html을 바꾸고 “됐다!” 싶었는데,
다음에 컨테이너를 삭제하고 새로 띄우면 수정이 사라져 있죠.
그 이유는 이미지에는 그 변경이 반영되지 않았기 때문입니다.
컨테이너는 일종의 임시 실행 공간이기 때문에,
그 안에서 바꾼 건 “메모리 위의 변화”에 가깝습니다.
이미지 자체를 바꾸고 싶다면, Dockerfile을 수정하고 다시 docker build해야 합니다.
데이터가 유지돼야 한다면? 볼륨을 써야 한다
여기서 자연스럽게 다음 개념이 나옵니다 — Volume(볼륨).
볼륨은 컨테이너 외부에 데이터를 저장해서
컨테이너가 재시작되더라도 데이터가 유지되도록 하는 기능입니다.
예를 들어 이런 식으로 실행합니다.
docker run -d -v /home/user/html:/usr/share/nginx/html nginx
이렇게 하면, 로컬 /home/user/html 폴더가 컨테이너 내부 /usr/share/nginx/html에 연결됩니다.
즉, 로컬 파일을 수정하면 컨테이너에서도 바로 반영되고,
컨테이너를 삭제해도 데이터는 그대로 남아있죠.
이걸 알고 나서부터는 개발용 환경을 구성할 때 훨씬 편해졌습니다.
코드를 컨테이너 안에 매번 복사할 필요가 없으니까요.
실무에서 겪었던 혼란
처음 회사 프로젝트에 도커를 도입했을 때,
“이미지가 업데이트됐는데 컨테이너가 예전 상태로 실행되는” 문제가 있었습니다.
알고 보니 이전 버전의 이미지를 기반으로 실행 중인 컨테이너가 그대로 남아 있었던 거죠.
docker ps -a로 확인해보면 중지된 컨테이너들이 여럿 있었고,
docker rm으로 정리한 후 새 이미지를 다시 실행하니 문제없이 해결됐습니다.
이 일을 겪고 나서야
도커를 제대로 관리하려면 “이미지 - 컨테이너 - 볼륨”의 관계를 명확히 이해해야 한다는 걸 깨달았습니다.
개발 환경에 도커를 적용하면서 느낀 점
이제는 프로젝트를 새로 시작할 때면
“서버 세팅부터 직접 하지 말고, 일단 도커로 올리자”는 게 자연스러워졌습니다.
이미지로 환경을 표준화하면 팀원이 바뀌더라도
“왜 내 컴퓨터에서는 안 돼요?” 같은 말이 거의 사라집니다.
도커가 약속하는 건 결국 **“모든 환경에서 똑같이 돌아간다”**는 일관성입니다.
'docker' 카테고리의 다른 글
| 도커 이미지 최적화 — 용량을 줄이고 속도를 높이기 (0) | 2025.11.12 |
|---|---|
| Docker Compose로 여러 컨테이너 한 번에 다루기 (0) | 2025.11.12 |
| Dockerfile 이해하기 — 이미지가 만들어지는 과정 (0) | 2025.11.12 |
| 도커로 무중단 배포(Blue-Green Deployment) 구현하기 (0) | 2025.11.12 |
| 도커와 CI/CD — 자동으로 빌드하고 배포하기 (0) | 2025.11.12 |