도커의 두 기둥: 이미지와 컨테이너의 차이
설계도 역할을 하는 '이미지'와, 그 설계도를 바탕으로 실행된 '컨테이너'의 차이를 알기 쉽게 정리합니다.
도커를 처음 접할 때 가장 헷갈리는 두 단어가 있습니다. 바로 '이미지(Image)'와 '컨테이너(Container)'입니다. 이 두 가지 개념은 도커 생태계를 떠받치는 핵심 기둥입니다. 많은 사람들이 두 용어를 혼용해서 사용하지만, 실제로 도커를 능숙하게 다루려면 이 둘의 차이를 명확히 아는 것이 필수적입니다. 이번 에피소드에서는 이미지와 컨테이너가 각각 무엇이고, 서로 어떤 관계를 맺고 있는지 일상적인 비유를 통해 확실하게 이해해 봅니다.
도커 이미지(Image)란 무엇인가?
도커 이미지(Docker Image)는 컨테이너를 만들기 위해 필요한 '설계도' 혹은 '틀'입니다. 프로그램 소스 코드, 라이브러리, 컴파일된 실행 파일, 환경 변수 등 특정 프로그램을 실행하는 데 필요한 모든 것이 이 이미지 하나에 얼어붙은 상태로 저장되어 있습니다.
변하지 않는 붕어빵 틀
이미지는 읽기 전용(Read-Only)이라는 아주 중요한 특징을 가집니다. 한 번 만들어진 이미지는 내부의 내용을 절대로 수정할 수 없습니다.
마치 무쇠로 만든 '붕어빵 틀'과 같습니다. 붕어빵 틀의 형태(팥이 들어갈 자리, 꼬리 모양 등)는 한 번 주물로 떠내면 바꿀 수 없습니다. 도커 이미지도 마찬가지로 누군가 한 번 "이 이미지는 Node.js 20버전과 내 웹사이트 코드를 담고 있다"고 확정 지어 만들면, 그 상태 그대로 고정됩니다.
모든 것이 포함된 패키지
도커 이미지는 단순히 코드만 있는 것이 아닙니다. 예를 들어 우분투 리눅스 운영체제의 핵심 파일들, 파이썬 설치 파일, 내 파이썬 코드, 그리고 코드가 실행될 때 필요한 폴더 구조까지 통째로 압축된 파일 덩어리입니다. 이 이미지 파일 하나만 다른 사람에게 전달하면, 그 사람은 추가로 무엇을 다운로드할 필요 없이 바로 내 프로그램을 실행할 수 있습니다.
도커 컨테이너(Container)란 무엇인가?
도커 컨테이너(Docker Container)는 이미지를 바탕으로 실제로 메모리에 올라가서 '실행 중인 상태'를 의미합니다. 정지해 있던 설계도(이미지)에 숨을 불어넣어 살아 움직이게 만든 독립적인 가상 환경입니다.
구워져 나온 붕어빵
앞서 이미지가 붕어빵 틀이라면, 컨테이너는 그 틀에서 구워져 나온 '따끈따끈한 붕어빵'입니다. 틀(이미지)은 하나지만, 밀가루 반죽을 붓고 굽는 과정을 반복하면 수십 개의 붕어빵(컨테이너)을 만들어낼 수 있습니다.
중요한 점은 구워져 나온 붕어빵들은 각자 독립적이라는 것입니다. 첫 번째 붕어빵을 한 입 베어 먹었다고 해서, 두 번째 붕어빵이 줄어들지는 않습니다. 마찬가지로 한 이미지에서 만들어진 여러 개의 컨테이너는 서로 완전히 분리되어 작동하며, 한 컨테이너 내부에서 파일을 삭제하거나 수정해도 다른 컨테이너나 원본 이미지에는 전혀 영향을 주지 않습니다.
생명 주기를 가진 실행 환경
컨테이너는 생명 주기(Lifecycle)를 가집니다. 생성되고, 실행되고, 정지되고, 결국 삭제됩니다. 컨테이너 내부에서 발생하는 변경 사항(예: 사용자가 업로드한 이미지 파일 저장, 로그 파일 생성 등)은 컨테이너가 살아있는 동안에만 임시로 유지됩니다. 컨테이너를 지우면 그 안에 있던 데이터도 특별한 조치를 취하지 않는 한 함께 날아갑니다.
이미지와 컨테이너의 핵심 차이점
| 이미지 (Image) | 컨테이너 (Container) |
|---|---|
| 붕어빵 틀, 설계도, 게임 설치 파일 | 구워진 붕어빵, 지어진 집, 실행된 게임 |
| 정적 (움직이지 않음, 파일 형태로 디스크에 존재) | 동적 (메모리에 띄워져서 실행 중인 상태) |
| 읽기 전용 (한 번 만들어지면 수정 불가) | 읽기 및 쓰기 가능 (내부에서 임시로 파일 수정 가능) |
| 코드와 실행 환경을 포장하여 안전하게 배포하는 것이 목적 | 실제로 사용자에게 서비스와 기능을 제공하는 것이 목적 |
이미지와 컨테이너의 관계 이해하기
이미지와 컨테이너는 떼려야 뗄 수 없는 관계입니다. 이미지가 없으면 컨테이너를 실행할 수 없고, 컨테이너로 실행하지 않는 이미지는 단순히 용량만 차지하는 무용지물에 불과합니다.
게임 설치 파일과 실행된 게임
우리가 스팀(Steam)에서 게임을 다운로드받았다고 가정해 봅시다. 다운로드가 완료된 상태의 '게임 설치 파일들'은 도커 이미지와 같습니다. 하드디스크에 고정되어 변하지 않습니다.
이제 게임 실행 버튼을 더블 클릭합니다. 화면이 뜨고 몬스터가 움직이며 게임이 시작됩니다. 이때 실행 중인 게임 창 하나하나가 바로 '컨테이너'입니다. 게임을 2개 켜면 2개의 컨테이너가 돌아가는 셈입니다. 게임을 끄면 컨테이너는 사라지지만, 게임 설치 파일(이미지)은 여전히 남아 내일 다시 켤 수 있게 해줍니다.
한 이미지에서 여러 컨테이너 생성하기
도커의 강력함은 한 개의 이미지로 똑같은 컨테이너를 수없이 복제해 낼 수 있다는 데 있습니다.
예를 들어, 사용자 트래픽이 몰려서 웹 서버 한 대로는 감당이 안 될 때, 도커를 사용하면 미리 만들어둔 '웹 서버 이미지'를 이용해 순식간에 컨테이너 5개를 실행할 수 있습니다. 5대의 완벽히 똑같은 서버가 마법처럼 눈앞에 생겨나는 것입니다.
컨테이너가 삭제되어도 이미지는 남는다
컨테이너를 정지하고 삭제하는 것을 두려워할 필요가 없습니다. 컨테이너에 오류가 생겼거나 꼬였다면, 복잡하게 원인을 찾아 고치려 하지 말고 그냥 컨테이너를 지우고 이미지에서 새 컨테이너를 다시 만들면 됩니다. 이미지는 원본 상태 그대로 변함없이 유지되기 때문에, 항상 깨끗하고 정상적인 처음 상태로 언제든 돌아갈 수 있습니다.
초보자가 자주 하는 오해
오해 또는 실수
컨테이너 안의 소스 코드를 열심히 수정해서 저장했다. 내일도 그대로 있겠지?
바로잡기
컨테이너를 삭제하면 내부에서 수정한 파일도 모두 날아갑니다. 영구 보존이 필요하다면 볼륨(Volume)을 쓰거나 이미지를 새로 구워야 합니다.
오해 또는 실수
이미지 안의 설정을 조금만 바꾸고 싶은데, 이미지 파일을 열어서 직접 텍스트를 수정하면 될까?
바로잡기
이미지는 읽기 전용이라 직접 수정이 불가능합니다. 설정이 바뀌었다면 'Dockerfile'을 수정하여 이미지를 완전히 새로 빌드(Build)해야 합니다.
개념 퀴즈
퀴즈 답을 맞춰야 학습 완료가 됩니다.도커 이미지(Image)와 컨테이너(Container)의 관계를 올바르게 설명한 것은 무엇인가요?
3줄 요약
- 1도커 이미지는 프로그램 실행에 필요한 모든 것을 담아둔 변하지 않는 '설계도' 또는 '붕어빵 틀'입니다.
- 2도커 컨테이너는 이미지를 바탕으로 실행되어 동작하는 독립적인 가상 환경, 즉 구워져 나온 '붕어빵'입니다.
- 3하나의 똑같은 이미지로부터 완벽히 동일한 환경을 가진 여러 개의 컨테이너를 찍어낼 수 있습니다.