
도커 이미지 핸드북
핵심 요약 도커 이미지는 컨테이너 실행에 필요한 파일 시스템과 메타데이터를 계층(layer) 형태로 패키징한 불변(immutable) 표준화된 템플릿이다. 이미지는 Docker Hub 같은 레지스트리에서 가져오거나 Dockerfile로 직접 빌드할 수 있으며, 계층 구조를 활용해 빌드 속도와 저장 효율을 극대화한다1.
1. 도커 이미지를 선택한 이유 및 목적
도커 이미지는 다음과 같은 이유로 사용된다.
- 일관성 있는 실행 환경: 개발·테스트·운영 환경 모두 동일한 이미지로 배포 가능1.
- 경량화된 배포 단위: 필요한 파일과 의존성만 포함해 크기를 최소화2.
- 버전 관리 및 재현성: 이미지 레이어별 변경 이력을 추적해 언제든 복원 가능2.
- 보안 및 신뢰성: 검증된 공식 이미지·Verified Publisher 이미지 사용으로 취약점 최소화1.
“이미지(Image)”라는 명칭의 기원
도커에서 “이미지”라는 용어는 시스템 파일과 설정을 그대로 복제한 스냅샷(snapshot) 개념에서 유래했다. 컴퓨팅 분야 전반에서 “이미지”는 특정 시점의 상태를 정확히 그대로 복제하여 저장한 파일이나 자료를 가리킨다.
-
디스크 이미지(Disk Image)
-
실행 파일 이미지(Executable Image)
-
운영체제(OS)에서 메모리에 로드되어 바로 실행 가능한 상태로 저장된 프로그램을 “실행 이미지”라 한다.
-
프로그램의 실행 상태(초기화된 메모리 레이아웃, 코드·데이터 섹션 등)를 그대로 묶어둔 정적(immutable) 파일이기 때문에 “이미지”라는 명칭이 쓰인다2.
-
-
컨테이너 이미지(Container Image)
정리하면, “이미지”라는 용어는 **“원본을 그대로 복제하여 보존한 자료”**라는 컴퓨터 과학 전통 용어가 도커에도 적용된 것이다. 즉 컨테이너 이미지란 파일 시스템과 설정의 스냅샷(snapshot)을 불변 형태로 저장한 패키지이므로 ‘이미지’라 부른다.
도커 이미지(Docker Image)와 닌텐도 게임 카트리지 칩 비유
도커 이미지는 컨테이너 실행에 필요한 모든 파일 시스템과 설정을 담고 있는 **‘불변(immutable) 패키지’**입니다. 이를 닌텐도 게임기의 **게임 카트리지(칩)**에 비유하면 다음과 같습니다.
-
전체 환경을 담은 스냅샷
-
닌텐도 카트리지 칩에는 게임 실행에 필요한 프로그램 코드, 그래픽·사운드 데이터, 설정 파일이 모두 저장되어 있습니다.
-
도커 이미지도 애플리케이션 실행에 필요한 OS 라이브러리, 실행 파일, 환경 변수, 설정 등이 한곳에 패키징되어 있습니다.
-
-
어디서나 동일하게 동작
-
닌텐도 카트리지를 다른 기기에 꽂아도 동일한 게임이 똑같이 실행되듯,
-
도커 이미지를 어떤 서버나 클라우드에 배포해도 컨테이너는 항상 동일한 환경에서 동일하게 실행됩니다.
-
-
읽기 전용(불변) 구조
-
카트리지 칩은 공장에서 제작된 후 사용 중에는 내부 데이터를 변경할 수 없습니다.
-
도커 이미지도 한 번 빌드된 뒤에는 직접 수정할 수 없고, 새로운 버전을 위해선 다시 빌드해야 합니다.
-
-
계층적 구성(멀티 스테이지)
-
닌텐도 게임이 업데이트되거나 DLC가 추가될 때 별도의 칩 조각을 교체·추가한다고 상상해 보세요.
-
도커 이미지는 여러 레이어(layer)가 쌓여 최종 이미지를 구성하며, 공통 레이어는 여러 이미지가 공유해 저장 효율과 빌드 속도를 높입니다.
-
-
경량화와 최적화
-
닌텐도 카트리지는 용량 제한 안에서 불필요한 데이터를 제거해 크기를 최소화합니다.
-
도커 이미지도 불필요한 파일을 제거하고 멀티 스테이지 빌드를 활용해 최종 이미지를 가능한 작게 유지합니다.
-
이처럼 **도커 이미지는 닌텐도 카트리지 칩처럼 “실행에 필요한 모든 것을 담은, 불변의 실행 템플릿”**으로 이해할 수 있습니다.
2. 도커 이미지의 구조
2.1 계층(Layer) 개념
- 각 레이어는 파일 시스템 변경사항(add, modify, delete)을 캡처한 불변 단위
- Dockerfile의 명령마다 새로운 레이어가 생성되며, 상위 레이어는 하위 레이어를 참조2
- 계층별 컨텐츠 주소 지정(content-addressable)과 유니온 파일시스템(union filesystem) 기술로 결합2
2.2 이미지 메타데이터
manifest.json
: 전체 레이어 순서 및 해시 목록- 각 레이어 디렉터리:
layer.tar
(파일 시스템 스냅샷),VERSION
,json
(생성 타임스탬프·명령어 기록) 포함3
2.3 불변성과 재사용
- 이미지 생성 후 직접 수정 불가(immutable)
- 동일 레이어는 여러 이미지 간에 공유 가능해 네트워크 대역폭 및 디스크 사용량 절감2
3. 이미지 생성 및 관리
3.1 Dockerfile 작성
FROM
: 베이스 이미지를 지정RUN
·COPY
·ADD
: 각 명령어가 별도 레이어 생성CMD
·ENTRYPOINT
: 컨테이너 실행 시 실행될 기본 명령어 정의
3.2 빌드 단계
docker build -t <이미지명>:<태그> .
로 Dockerfile 기반 이미지 빌드- 중간 레이어는 캐시로 저장되어 다음 빌드 시 재사용
docker images
로 로컬 이미지 목록 확인4
3.3 레지스트리와 배포
docker push <레포지토리>/<이미지>:<태그>
로 레지스트리에 업로드docker pull
로 원격 레지스트리에서 다운로드- Docker Hub 외에 사설 레지스트리 활용 가능
4. 사용법과 워크플로우
4.1 컨테이너 실행
docker run -d --name <컨테이너명> <이미지>:<태그>
: 백그라운드 실행docker run -it <이미지> bash
: 상호작용형 터미널로 실행
4.2 이미지 검사 및 디버깅
docker image inspect <이미지>
: 메타데이터와 구성정보 조회5docker image history <이미지>
: 레이어별 생성 명령어와 시간 확인
4.3 이미지 최적화
- 불필요한 파일 제거 및 멀티 스테이지 빌드 활용으로 최종 이미지 크기 최소화
.dockerignore
파일로 빌드 컨텍스트에서 제외할 항목 정의- 공식·경량 베이스 이미지(alpine, distroless) 사용 권장6
5. 베스트 프랙티스
5.1 보안 강화
- 최소 권한으로 실행(
USER
지시자 사용) - 비공개 정보(시크릿) 하드코딩 금지
- 이미지 스캐너(hadolint, Sysdig Secure 등)로 CI 파이프라인에서 취약점 사전 점검6
5.2 이미지 유지보수
- 주기적 재빌드: 베이스 이미지의 보안 패치 최신화
- 태그 전략: 안정 버전(stable), 롱텀 서포트(LTS) 태그 고수
- 메타데이터 레이블(labels)로 버전·유지보수 담당자 정보 포함6
5.3 레이어 관리
- 레이어 수 최소화: RUN 명령 병합, 캐시 유효 활용
- 공통 단계는 재사용 가능한 빌드 스테이지로 분리(멀티 스테이지 빌드)7
6. 고급 기능
6.1 멀티 스테이지 빌드
- 빌드 단계와 런타임 단계를 분리해 불필요한 빌드 툴 제거
- 최종 이미지만 경량화
6.2 디스트로리스(Distroless)
- 베이스 이미지를
scratch
또는 distroless로 시작해 라이브러리 의존성 최소화6
6.3 서명과 검증
- Docker Content Trust 활성화로 이미지 서명 및 런타임 검증
- Notary, Harbor 서명 기능 통합 가능
7. 요약 가이드
- Dockerfile 최적화: 계층 수 최소·멀티 스테이지 활용
- 보안 모니터링: 빌드·배포 전 이미지 스캐닝
- 버전 관리: 레이블·태그 전략 수립
- 정기 재빌드: 보안 패치 통합 및 캐시 관리
- 경량 베이스: Alpine·Distroless·Scratch 기반 이미지 우선 사용
이 핸드북을 통해 도커 이미지를 설계·생성·운영·보안·최적화하는 전 과정을 체계적으로 이해하고, 실무에 바로 적용할 수 있다.