<aside>
☁️ 클라우드웨이브 시리즈 · W03 · 3/5 · 예상 읽기 6~8분
</aside>
이번 주 학습을 정리하며 나는 Buildx와 멀티플랫폼 이미지, Compose 서비스 선언과 프로필의 첫 구조를 정리한다.라는 질문에서 출발했다. 처음에는 명령을 순서대로 외우려 했지만, 실제로는 실행 단위와 데이터, 통신, 준비 상태를 분리해서 보는 편이 훨씬 명확했다.
Docker는 애플리케이션을 일관된 실행 단위로 묶는 플랫폼이다. 이미지는 실행에 필요한 파일과 설정의 템플릿이고, 컨테이너는 그 이미지를 실행한 상태다. Compose는 여러 서비스와 관계를 선언 파일로 묶는다. 이 관점은 Buildx와 멀티플랫폼 이미지, Compose 서비스 선언과 프로필의 첫 구조를 정리한다.의 핵심이다.
services:
app:
image: example/app:stable
networks:
- internal
volumes:
- app-data:/var/lib/app
networks:
internal:
volumes:
app-data:
이 예시는 실제 계정, 주소, 호스트명, 비밀값을 포함하지 않는 문서용 구성이다. 설정을 읽을 때는 서비스, 이미지 또는 빌드, 포트, 데이터, 네트워크 순으로 확인한다.
컨테이너가 실행 중이라는 사실과 애플리케이션이 요청을 받을 준비가 됐다는 사실은 다르다. 데이터가 컨테이너 안에 보인다는 사실도 영속성이 보장됐다는 뜻은 아니다. 또한 네트워크에 연결됐다고 해서 외부에 공개된 것은 아니다. 이런 경계를 섞으면 설정은 동작해도 운영 이유를 설명하기 어렵다.
Buildx는 여러 플랫폼 대상 빌드와 캐시 활용을 확장한다. 멀티플랫폼 태그가 있다고 해서 모든 네이티브 동작이 자동 검증되는 것은 아니다.
변경이 잦은 부분과 재사용할 부분을 구분했는가? 서비스가 교체돼도 남아야 할 데이터가 무엇인가? 외부에 열어야 할 경계는 어디인가? 실행 순서가 아니라 준비 상태를 어떻게 확인할 것인가? 이 질문을 리뷰 목록으로 만들면 설정 파일이 단순한 실행 명령 모음이 아니라 운영 문서가 된다.
buildx와 BuildKit은 이미지를 만드는 작업을 실행 환경과 분리해 생각하게 한다. 멀티플랫폼 이미지를 다룰 때는 현재 빌드 명령을 실행하는 곳과 최종 이미지가 실행될 대상 플랫폼을 구분해야 한다. 이때 중요한 것은 특정 환경에서 성공했다는 결과를 넓혀 말하는 것이 아니라, 어떤 플랫폼을 빌드 대상으로 삼았는지와 그 결과를 어디에서 사용할지 명시하는 일이다. BuildKit cache도 같은 관점에서 볼 수 있다. 캐시는 이전 빌드의 일부를 재사용하는 빌드 과정의 요소이지, 실행 중인 컨테이너의 데이터나 배포 환경 자체를 의미하지 않는다.
Docker Compose는 여러 서비스를 선언하고 실행 관계를 묶는 형식이며, code-server 실습은 그 선언이 실제 실행 환경과 어떻게 만나는지 살펴보는 사례다. Compose 파일에 적힌 서비스와 volume, network의 경계는 이미지를 만드는 단계와 컨테이너를 실행하는 단계를 구분해서 읽어야 한다. 같은 이미지라도 실행 환경의 플랫폼이나 연결된 저장 공간이 달라지면 확인할 항목이 달라질 수 있다. 따라서 실습을 정리할 때는 빌드 대상 플랫폼, 이미지에 포함된 결과물, Compose가 연결하는 실행 자원을 순서대로 나누어 적는 편이 재현 가능한 설명에 가깝다. 이 구조는 빌드 결과를 어디에서 만들었는지와 실제 서비스가 어떤 조건에서 시작되는지를 섞지 않게 해 준다.