Docker Image

배포마다 서버에 파일을 복사하고 의존성을 다시 설치하면, 매번 결과가 조금씩 달라질 수 있습니다. 어떤 서버에는 라이브러리가 하나 더 깔려 있고, 어떤 서버에는 환경 변수가 빠져 있는 식의 차이가 장애로 이어집니다. 실행에 필요한 전체 상태를 한 번에 고정하는 단위가 없으면 재현성과 롤백이 모두 어려워집니다.

소프트웨어 배포는 오랫동안 패키지 파일, 설치 스크립트, 운영 문서가 나뉜 채로 전달됐습니다. 컨테이너 생태계에서는 실행 환경 전체를 이미지라는 단위로 고정해 주는 쪽이 더 적합했습니다. 특히 CI/CD가 보편화되면서 '코드 커밋마다 같은 규칙으로 새 실행 패키지를 만들고 태그로 식별한다'는 흐름이 이미지 중심으로 정착했습니다.

이미지는 베이스 레이어 위에 의존성 설치, 애플리케이션 파일, 실행 메타데이터가 차례대로 쌓이는 구조입니다. 각 레이어는 읽기 전용이라 한 번 만들어진 결과를 다시 덮어쓰지 않고, 새 빌드는 새 레이어를 추가하는 방식으로 진행됩니다. 이 구조 덕분에 같은 베이스나 의존성 레이어를 여러 이미지가 공유할 수 있습니다.

Docker Image와 Container Registry는 모두 배포 흐름에서 핵심이지만 역할이 다릅니다. 이미지는 실행 패키지 자체이고, 레지스트리는 그 패키지를 저장하고 전달하는 장소입니다. 즉 '무엇을 실행하는가'와 '그것을 어디서 받아 오는가'를 나눠서 봐야 흐름이 정리됩니다.

실무에서는 운영 환경에 소스코드를 직접 복사하기보다, CI가 빌드한 이미지를 태그로 식별해 그대로 배포하는 방식이 기본입니다. 이때 이미지 태그를 Git 커밋이나 릴리스 버전과 연결해 두면, 어떤 코드가 실제 운영 중인지 추적하고 되돌리는 일이 훨씬 쉬워집니다.