<aside>
☁️ 클라우드웨이브 시리즈 · W03 · 1/5 · 예상 읽기 6~8분
</aside>
이번 주 학습을 정리하며 나는 이미지와 컨테이너의 관계, Dockerfile 단계, 멀티 스테이지 빌드를 입문자 관점에서 정리한다.라는 질문에서 출발했다. 처음에는 명령을 순서대로 외우려 했지만, 실제로는 실행 단위와 데이터, 통신, 준비 상태를 분리해서 보는 편이 훨씬 명확했다.
Docker는 애플리케이션을 일관된 실행 단위로 묶는 플랫폼이다. 이미지는 실행에 필요한 파일과 설정의 템플릿이고, 컨테이너는 그 이미지를 실행한 상태다. Compose는 여러 서비스와 관계를 선언 파일로 묶는다. 이 관점은 이미지와 컨테이너의 관계, Dockerfile 단계, 멀티 스테이지 빌드를 입문자 관점에서 정리한다.의 핵심이다.
services:
app:
image: example/app:stable
networks:
- internal
volumes:
- app-data:/var/lib/app
networks:
internal:
volumes:
app-data:
이 예시는 실제 계정, 주소, 호스트명, 비밀값을 포함하지 않는 문서용 구성이다. 설정을 읽을 때는 서비스, 이미지 또는 빌드, 포트, 데이터, 네트워크 순으로 확인한다.
컨테이너가 실행 중이라는 사실과 애플리케이션이 요청을 받을 준비가 됐다는 사실은 다르다. 데이터가 컨테이너 안에 보인다는 사실도 영속성이 보장됐다는 뜻은 아니다. 또한 네트워크에 연결됐다고 해서 외부에 공개된 것은 아니다. 이런 경계를 섞으면 설정은 동작해도 운영 이유를 설명하기 어렵다.
Dockerfile에서는 빌드에 필요한 도구와 실행에 필요한 결과물을 멀티 스테이지로 나눌 수 있다.
변경이 잦은 부분과 재사용할 부분을 구분했는가? 서비스가 교체돼도 남아야 할 데이터가 무엇인가? 외부에 열어야 할 경계는 어디인가? 실행 순서가 아니라 준비 상태를 어떻게 확인할 것인가? 이 질문을 리뷰 목록으로 만들면 설정 파일이 단순한 실행 명령 모음이 아니라 운영 문서가 된다.
이미지는 애플리케이션을 실행하기 위한 파일과 설정을 묶어 둔 결과물이고, 컨테이너는 그 이미지를 실제 실행 단위로 만든 상태다. 따라서 이미지에 무엇을 넣을지와 컨테이너가 실행 중에 무엇을 맡을지는 같은 질문이 아니다. Dockerfile의 각 지시는 이미지에 레이어를 쌓는 과정으로 이어지므로, 자주 바뀌는 내용과 재사용할 내용을 구분하면 변경 범위를 읽기 쉬워진다. 멀티 스테이지 빌드는 빌드 과정과 최종 실행에 필요한 결과를 분리하는 방식으로 이해할 수 있다. 이 구분은 이미지 크기만 줄이는 요령이 아니라, 빌드 도구와 실행 책임을 서로 다른 단계에 두는 설계다.
PostgreSQL 컨테이너 실습에서는 이미지로부터 컨테이너를 만들고, 실행 중인 컨테이너에 접속해 데이터베이스와 테이블을 다루는 흐름을 확인했다. 여기서 중요한 것은 특정 실행 결과를 외우는 것이 아니라, 어떤 이미지와 환경 설정으로 컨테이너를 만들었는지, 데이터가 어느 경계에 놓이는지 다시 설명할 수 있는가이다. Dockerfile과 실행 설정이 분리되어 있으면 빌드 책임과 실행 책임을 각각 점검할 수 있고, 같은 절차를 다시 따라갈 때도 확인할 지점이 분명해진다. 결국 작은 실습도 이미지의 재사용성, 컨테이너의 일시성, 데이터의 보존 위치를 함께 기록해야 재현 가능한 설명이 된다.