도커 이미지 레이어

도커 이미지는 여러 개의 읽기 전용 레이어로 구성된 집합체이다. 각 레이어는 파일 시스템의 변경 사항을 나타내는 차분(diff)으로, Dockerfile의 각 명령어가 실행될 때 생성된다. 예를 들어, RUN apt-get update나 COPY . /app과 같은 명령어는 각각 새로운 레이어를 만든다.

레이어의 핵심 속성은 불변성이다. 한 번 생성된 레이어는 절대 변경되지 않는다. 이는 Union 파일 시스템이 여러 레이어를 하나의 통합된 뷰로 제공하는 방식의 기초가 된다. 만약 하위 레이어의 파일을 수정해야 한다면, 시스템은 실제로 해당 파일을 상위 레이어에 복사하여 수정하는 카피-온-라이트 방식을 사용한다. 이로 인해 원본 레이어는 항상 그대로 유지된다.

이 불변성은 몇 가지 중요한 이점을 제공한다. 첫째, 레이어 캐싱을 가능하게 하여 동일한 명령어 시퀀스를 가진 이미지 빌드 속도를 크게 향상시킨다. 둘째, 여러 이미지가 동일한 베이스 레이어를 공유할 수 있어 저장 공간과 네트워크 대역폭을 절약한다. 셋째, 이미지의 특정 버전을 정확히 재현할 수 있는 재현 가능 빌드의 토대가 된다.

따라서 도커 이미지는 이러한 불변 레이어들의 스택으로 정의되며, 컨테이너가 실행될 때 최상위에 쓰기 가능한 얇은 레이어(컨테이너 레이어)가 추가되어 모든 변경 사항을 담는다.

Union 파일 시스템은 여러 개의 독립적인 파일 시스템 계층(레이어)을 단일 통합 뷰로 결합하는 메커니즘이다. 도커는 이 기술을 기반으로 하여 도커 이미지의 불변적인 레이어를 효율적으로 관리하고 컨테이너의 실행 환경을 구성한다.

Union 파일 시스템의 주요 구현체로는 overlay2, aufs, devicemapper 등이 있으며, 현대적인 도커 환경에서는 주로 overlay2 드라이버가 사용된다. 이 시스템은 읽기 전용의 이미지 레이어와 컨테이너별 쓰기 가능 레이어를 결합하는 방식으로 동작한다. 각 레이어는 파일과 디렉토리의 변경사항 집합으로, 하위 레이어의 내용을 상위 레이어가 가리는 형태로 통합된다. 이 구조는 다음과 같은 이점을 제공한다.

• 공간 효율성: 동일한 기본 레이어를 공유하는 여러 이미지가 존재할 경우, 디스크에 한 번만 저장된다.

• 빌드 효율성: 변경되지 않은 레이어는 캐시되어 재사용되므로 이미지 빌드 시간이 단축된다.

• 불변성: 이미지를 구성하는 레이어는 수정되지 않으므로, 특정 빌드의 정확한 상태를 보장한다.

컨테이너가 실행될 때, 도커는 해당 이미지의 모든 읽기 전용 레이어 스택 위에 쓰기 가능한 얇은 레이어("컨테이너 레이어")를 추가한다. 모든 파일 쓰기, 수정, 삭제 작업은 이 최상위 쓰기 레이어에서 발생한다. 이는 기본 이미지 레이어를 변경하지 않으면서 각 컨테이너 인스턴스에 고유한 상태를 제공하는 Copy-on-Write 전략의 핵심이다. Union 파일 시스템 없이는 도커의 경량성과 빠른 배포 속도를 실현하기 어려웠을 것이다.

Dockerfile의 각 명령어는 일반적으로 하나의 이미지 레이어를 생성한다. 이 레이어는 해당 명령어의 실행 결과로 파일 시스템에 발생한 변경 사항을 기록한 읽기 전용 계층이다. 모든 레이어는 불변성을 가지므로, 한 번 생성되면 그 내용을 수정할 수 없다.

주요 명령어별 레이어 생성 동작은 다음과 같다.

RUN apt-get update && apt-get install -y package와 같이 여러 명령을 &&로 연결하여 하나의 RUN 명령어로 작성하면, 중간에 생성되는 불필요한 캐시 레이어를 제거하고 최종적으로 하나의 레이어만 생성하게 되어 이미지 크기를 줄이는 데 도움이 된다. 반면, 각 명령을 별도의 RUN 줄로 작성하면 각각이 독립적인 레이어가 되어 이미지 크기가 증가한다.

레이어 생성은 레이어 캐싱 메커니즘과 밀접하게 연관된다. Dockerfile의 명령어 순서를 변경하면, 변경된 명령어부터 그 이후의 모든 레이어 캐시가 무효화되고 재생성된다. 따라서 자주 변경되는 작업(예: 애플리케이션 소스 코드 복사)은 Dockerfile 하단에, 덜 자주 변경되는 작업(예: 의존성 패키지 설치)은 상단에 배치하는 것이 빌드 효율성을 높인다.

Dockerfile의 각 명령어는 실행 시 새로운 도커 이미지 레이어를 생성합니다. 빌드 과정에서 도커 엔진은 이전에 생성된 레이어를 재사용하여 빌드 시간을 단축하는 레이어 캐싱 메커니즘을 사용합니다. 이 메커니즘의 핵심은 각 레이어를 고유한 다이제스트로 식별하고, Dockerfile 명령어와 해당 명령어의 컨텍스트가 변경되지 않았다면 캐시된 레이어를 그대로 사용하는 것입니다.

캐시 적중 여부는 Dockerfile의 명령어를 순서대로 평가하여 결정됩니다. 각 명령어에 대해 도커 엔진은 기존 캐시에서 동일한 명령어와 동일한 부모 레이어를 가진 레이어를 찾습니다. 일치하는 레이어가 발견되면 해당 레이어를 재사용하고 다음 명령어를 계속 평가합니다. 그러나 한 명령어라도 변경되거나, ADD나 COPY 명령어에서 참조하는 파일의 내용이 변경되면 그 지점부터의 모든 후속 명령어에 대한 캐시는 무효화됩니다. 이는 레이어가 불변성을 가지기 때문입니다.

레이어 캐싱의 효율성을 높이기 위한 일반적인 전략은 다음과 같습니다.

캐시 무효화를 유발하는 요소는 명령어 문자열 자체의 변경뿐만 아니라, ADD나 COPY 명령어의 소스 파일 내용(체크섬), 그리고 이전 명령어로부터 생성된 레이어의 변경까지 포함됩니다. 또한 docker build 명령에 --no-cache 옵션을 사용하면 명시적으로 캐시를 사용하지 않고 모든 레이어를 새로 생성할 수 있습니다.

도커 이미지의 각 레이어는 호스트 시스템의 특정 디렉터리에 tar 아카이브 파일과 메타데이터 파일로 저장된다. 기본 저장 위치는 리눅스 시스템의 /var/lib/docker/overlay2 디렉터리이다[4]. 이 디렉터리 아래에는 각 레이어를 고유하게 식별하는 해시 값으로 명명된 하위 디렉터리가 생성된다.

각 레이어 디렉터리에는 diff, link, lower, merged, work 등의 파일과 디렉터리가 포함된다. diff 디렉터리는 해당 레이어에서 변경된 실제 파일과 디렉터리를 담고 있다. lower 파일은 유니온 마운트를 구성하기 위해 하위 레이어들의 경로 정보를 기록한다. 저장소는 이러한 레이어들을 효율적으로 관리하고, 여러 이미지가 공통의 기저 레이어를 참조할 수 있도록 설계되었다.

도커는 컨텐츠 어드레서블 스토리지 방식을 채택하여 레이어를 저장한다. 이는 레이어의 내용을 SHA-256 해시 알고리즘으로 계산한 다이제스트 값을 기반으로 저장하고 식별하는 것을 의미한다. 이 방식 덕분에 내용이 동일한 레이어는 단 한 번만 저장되며, 서로 다른 이미지라도 동일한 레이어를 공유하여 디스크 공간을 절약할 수 있다. docker system df 명령어를 통해 저장소 사용량과 공유된 레이어 정보를 확인할 수 있다.

각 도커 이미지 레이어는 고유한 SHA-256 해시 값인 다이제스트(digest)로 식별됩니다. 이 다이제스트는 레이어의 압축된 tar 아카이브 내용을 암호화 해시 함수로 계산하여 생성되므로, 레이어의 내용이 단 한 바이트라도 변경되면 완전히 다른 다이제스트 값이 생성됩니다. 이는 레이어의 불변성과 무결성을 보장하는 핵심 메커니즘입니다.

레이어는 일반적으로 sha256: 접두사로 시작하는 다이제스트 문자열로 참조됩니다. 예를 들어, sha256:3c3a4604a545cdc127456d94e421cd355bca5b528f4a9c1905b15da2eb4a4c6a와 같은 형식을 가집니다. 이 식별자는 도커 레지스트리에서 레이어를 저장하고, 풀(pull)하거나 푸시(push)할 때, 그리고 로컬 캐시에서 레이어를 찾을 때 사용되는 고유 키 역할을 합니다.

docker image inspect 명령어를 실행하면 이미지의 JSON 형식 상세 정보에서 RootFS.Layers 필드에 레이어 다이제스트 목록을 확인할 수 있습니다. 이 목록은 이미지를 구성하는 레이어들의 순서를 나타내며, 최하단 베이스 이미지 레이어부터 최상위 레이어까지 쌓입니다. 레지스트리는 이러한 다이제스트를 기준으로 레이어를 저장하고, 여러 이미지가 동일한 레이어를 참조할 경우 단일 물리적 복사본만 유지하여 저장 공간과 네트워크 대역폭을 절약합니다.

Dockerfile의 각 명령어는 일반적으로 새로운 도커 이미지 레이어를 생성합니다. 불필요하게 많은 레이어는 이미지 크기를 증가시키고 빌드 시간을 늘리며, 취약점 관리의 복잡성을 높입니다. 따라서 레이어 수를 최소화하는 것은 효율적인 이미지 빌드의 핵심 전략입니다.

가장 기본적인 방법은 여러 RUN 명령어를 논리적으로 하나로 결합하는 것입니다. 예를 들어, 패키지 설치, 업데이트, 정리를 하나의 RUN 명령어 체인으로 수행하면 불필요한 중간 레이어 생성을 방지할 수 있습니다. 또한, apt-get update와 apt-get install을 같은 RUN 명령어에서 실행해야 캐시된 오래된 패키지 목록으로 인한 설치 실패를 예방할 수 있습니다[5]. .dockerignore 파일을 사용하여 빌드 컨텍스트에 불필요한 파일이 포함되지 않도록 하는 것도 중요합니다. 이는 빌드 컨텍스트 크기를 줄여 빌드 속도를 높이고, 의도치 않은 파일이 레이어에 추가되는 것을 방지합니다.

다음 표는 레이어 수를 줄이기 위한 일반적인 Dockerfile 명령어 최적화 패턴을 보여줍니다.

또한, COPY나 ADD 명령어는 파일 시스템의 변경을 유발하므로 신중하게 사용해야 합니다. 변경 빈도가 높은 파일(예: 애플리케이션 소스 코드)과 낮은 파일(예: 의존성 패키지 목록 파일)을 분리하여 복사하면, 빌드 캐시를 효과적으로 활용할 수 있습니다. 이는 소스 코드만 변경되었을 때 의존성 설치 단계부터 재빌드하지 않도록 합니다. 최종 이미지에서 필요하지 않은 빌드 의존성이나 중간 파일은 같은 RUN 명령어 내에서 삭제하여 해당 레이어의 최종 크기를 줄이는 것도 좋은 관행입니다.

멀티-스테이지 빌드는 단일 Dockerfile 내에 여러 개의 FROM 지시문을 정의하여 빌드 과정을 여러 단계로 나누는 기법이다. 각 FROM 지시문은 새로운 빌드 단계를 시작하며, 이전 단계에서 생성된 아티팩트를 선택적으로 다음 단계로 복사할 수 있다. 이 방식의 핵심 목적은 최종 도커 이미지의 크기를 최소화하고, 불필요한 빌드 도구나 중간 파일을 제거하여 보안성을 높이는 것이다.

예를 들어, 애플리케이션을 컴파일하는 단계와 실행하는 단계를 분리할 수 있다. 첫 번째 단계에서는 JDK나 Node.js와 같은 무거운 빌드 도구와 의존성을 포함한 베이스 이미지를 사용하여 소스 코드를 컴파일한다. 이후 두 번째 단계에서는 JRE나 경량 런타임만 포함된 베이스 이미지를 사용하며, COPY --from=<이전_단계> 명령어를 통해 첫 번째 단계에서 생성된 컴파일된 실행 파일만을 가져온다. 결과적으로 최종 이미지에는 빌드 도구가 포함되지 않아 크기가 크게 줄어든다.

멀티-스테이지 빌드를 효과적으로 활용하기 위한 주요 전략은 다음과 같다.

이 기법은 특히 Go, Rust와 같이 정적 컴파일이 가능한 언어나, Java, C#과 같이 빌드 결과물이 독립적인 패키지인 경우에 매우 효과적이다. 이를 통해 개발자는 빌드 환경의 복잡성을 Dockerfile 내에서 관리하면서도, 프로덕션에 배포할 경량이고 안전한 이미지를 생성할 수 있다.

도커 이미지는 여러 레이어로 구성되며, 각 레이어는 Dockerfile의 명령어 실행 결과로 생성된 파일 시스템의 변경 사항을 담고 있다. 이는 빌드 효율성과 재사용성을 높이지만, 하위 레이어에 포함된 취약한 소프트웨어 패키지나 구성 파일이 최종 이미지에 그대로 남아 보안 위협이 될 수 있다. 따라서 이미지 내 각 레이어를 분석하여 알려진 취약점을 식별하는 레이어 스캐닝 과정이 보안 체계의 필수 요소가 되었다.

레이어 스캐닝은 일반적으로 정적 분석 방식을 사용한다. 스캐닝 도구는 이미지를 풀어 각 레이어에 포함된 파일(예: 패키지 관리자 데이터베이스, 라이브러리, 실행 파일)을 검사한다. 이후 CVE 데이터베이스와 같은 취약점 정보 소스와 비교하여 사용 중인 소프트웨어의 버전에 알려진 취약점이 존재하는지 확인한다. 분석 결과는 취약점의 심각도(위험, 높음, 중간, 낮음), CVE ID, 영향받는 패키지, 해결 방안(예: 특정 버전으로 업데이트) 등을 포함한 상세 보고서 형태로 제공된다.

주요 스캐닝 도구와 접근 방식은 다음과 같다.

효과적인 취약점 관리를 위해서는 스캐닝을 개발 파이프라인(CI/CD)에 통합하여 새로운 이미지가 생성될 때마다 자동으로 검사하도록 해야 한다. 발견된 심각한 취약점에 대해서는 빌드 실패를 유발하도록 정책을 설정할 수 있다. 또한, 스캔은 일회성 작업이 아니라 지속적인 과정으로, 기본 이미지나 종속성에 새로운 취약점이 발견되면 기존에 배포된 이미지도 재평가해야 한다.

Dockerfile에 시크릿 정보(예: API 키, 데이터베이스 비밀번호, SSH 개인 키 등)를 평문으로 포함하는 것은 보안상 심각한 문제를 초래할 수 있다. 이러한 정보는 도커 이미지의 불변성을 가진 레이어에 영구적으로 기록되며, 최종 이미지를 공유하거나 도커 레지스트리에 푸시할 때 외부에 노출될 위험이 있다.

시크릿을 안전하게 관리하기 위한 주요 방법은 다음과 같다. 첫째, 빌드 시점에 환경 변수를 주입하는 --build-arg 인자를 사용하거나, 도커 빌드킷의 --secret 기능을 활용하여 빌드 과정에서만 일시적으로 시크릿을 사용하고 최종 이미지 레이어에는 포함되지 않도록 할 수 있다. 둘째, 멀티-스테이지 빌드를 적용하여 시크릿이 필요한 빌드 단계와 최종 애플리케이션 실행 단계를 분리한다. 시크릿은 초기 빌드 스테이지에서만 사용하고, 최종 이미지에는 빌드된 산출물만 복사하도록 구성하면 된다. 셋째, 애플리케이션 런타임에 시크릿을 제공하는 방법으로, 도커 스웜의 도커 시크릿 객체나 쿠버네티스의 시크릿을 활용하거나, 외부 키 관리 시스템(KMS)이나 하시코프 볼트와 같은 도구를 통한 동적 주입 방식을 고려할 수 있다.

이미지에 실수로 시크릿이 포함되었는지 확인하기 위해 docker history 명령어로 레이어 생성 명령을 검토하거나, dive와 같은 도구로 각 레이어의 파일 시스템 변경 사항을 점검할 수 있다. 이미 노출된 시크릿이 있다면 해당 이미지 태그를 삭제하고, 레지스트리에서 해당 레이어가 더 이상 참조되지 않도록 관리하는 것이 중요하다.

도커 레지스트리에 이미지를 푸시(push)하거나 풀(pull)할 때, 실제로 전송되는 단위는 개별 도커 이미지 레이어이다. 이 과정은 이미지 매니페스트에 기술된 레이어 목록을 기반으로 효율적으로 진행된다.

이미지를 풀할 때, 도커 데몬은 먼저 레지스트리로부터 매니페스트를 가져온다. 매니페스트에는 해당 이미지를 구성하는 모든 레이어의 다이제스트(고유 식별자) 목록이 포함되어 있다. 데몬은 로컬 저장소를 확인하여 동일한 다이제스트를 가진 레이어가 이미 존재하는지 검사한다. 이미 존재하는 레이어는 네트워크를 통해 다시 다운로드하지 않고 재사용한다. 없는 레이어만 순차적으로 다운로드받아 Union 파일 시스템 위에 쌓아 최종 이미지를 구성한다. 이 메커니즘은 동일한 베이스 이미지를 사용하는 여러 애플리케이션을 실행할 때 저장 공간과 대역폭을 절약하게 해준다.

이미지를 푸시할 때도 유사한 과정이 역순으로 이루어진다. 데몬은 업로드할 이미지의 레이어 목록을 레지스트리에 전송하고, 레지스트리는 자신이 보유하지 않은 레이어만을 업로드받도록 요청한다. 따라서 레지스트리에 이미 존재하는 레이어(예: 공용 우분투 베이스 레이어)는 업로드 과정에서 자동으로 생략된다. 이 과정은 다음과 같은 순서로 요약할 수 있다.

이러한 레이어 기반의 전송 방식은 데이터 중복 제거를 가능하게 하여 네트워크 효율성을 극대화한다. 특히 대규모 클러스터 환경에서 여러 노드에 동일한 이미지를 배포할 때 그 효과가 두드러진다.

도커 레지스트리에서 이미지를 풀(pull)하거나 푸시(push)할 때, 개별 레이어 단위로 데이터가 전송된다. 이 과정에서 레이어 재사용은 네트워크 대역폭과 저장 공간을 절약하는 핵심 메커니즘이다. 레지스트리는 각 레이어를 고유한 다이제스트(Digest, 주로 SHA-256 해시)로 식별하여 관리한다. 따라서 서로 다른 이미지가 동일한 내용의 레이어를 공유한다면, 레지스트리와 클라이언트 모두 디스크에 하나의 사본만 저장하고, 네트워크를 통해 한 번만 전송하면 된다.

레이어 재사용의 효율성은 Dockerfile 작성 방식에 직접적인 영향을 받는다. 예를 들어, 동일한 베이스 이미지(ubuntu:22.04 등)를 사용하는 여러 애플리케이션 이미지는 그 베이스 이미지의 모든 레이어를 공유한다. 또한, Dockerfile에서 자주 변경되지 않는 명령어(예: RUN apt-get update)를 상위에 배치하면, 그 아래의 명령어만 변경되었을 때 이전에 빌드된 캐시 레이어를 재사용할 수 있다. 반대로, 애플리케이션 소스 코드(COPY . /app)를 빌드 초기에 복사하면 소스 코드가 조금만 변경되어도 그 아래의 모든 레이어 캐시가 무효화되는 비효율이 발생한다.

다음 표는 레이어 재사용이 효율성에 미치는 영향을 요약한다.

이러한 재사용 메커니즘은 대규모 컨테이너 환경에서 특히 중요하다. 수백 개의 마이크로서비스가 공통 라이브러리 레이어를 공유하면 전체적인 배포 속도가 향상되고, 레지스트리의 저장소 부하가 크게 감소한다. 따라서 효율적인 이미지 설계는 중복 레이어를 최대한 생성하지 않고, 가능한 한 많은 이미지가 공통 레이어를 참조하도록 하는 것이다.

docker image inspect 명령어는 도커 이미지 레이어의 상세 메타데이터를 JSON 형식으로 출력하는 도구이다. 이 명령어는 이미지의 구성, 레이어 정보, 생성 기록, 환경 변수, 네트워크 설정 등을 포함한 모든 내부 정보를 조회할 수 있게 한다. 명령어의 기본 사용법은 docker image inspect <이미지명 또는 이미지 ID>이다. 출력되는 JSON 데이터는 매우 방대하므로, --format 옵션을 사용해 특정 필드만 추출하여 가독성을 높이는 것이 일반적이다[9].

이 명령어를 통해 얻을 수 있는 주요 레이어 관련 정보는 다음과 같다.

이 정보는 이미지 빌드 최적화, 문제 디버깅, 보안 취약점 분석에 활용된다. 예를 들어, .History 필드를 분석하면 어떤 명령어가 새로운 레이어를 생성했는지 확인할 수 있으며, 불필요한 레이어를 제거하는 빌드 전략 수립에 도움이 된다. 또한, .RootFS.Layers에 나열된 다이제스트를 통해 특정 레이어가 다른 이미지와 공유되고 있는지 여부를 추론할 수 있다.

dive는 도커 이미지의 내부 구조를 시각적으로 분석하고 각 레이어의 내용과 크기를 검사하는 데 특화된 오픈 소스 도구이다. 이 도구는 CLI 기반의 인터페이스를 제공하며, 이미지의 효율성을 평가하고 불필요한 파일을 식별하여 이미지 최적화를 돕는 데 주로 사용된다.

dive를 사용하여 특정 이미지를 분석하려면 dive <이미지_이름:태그> 명령어를 실행한다. 실행하면 화면이 두 개의 주요 패널로 나뉜다. 왼쪽 패널에는 이미지를 구성하는 모든 레이어 목록이 Dockerfile의 명령어와 함께 계층적으로 표시된다. 오른쪽 패널에는 현재 선택된 레이어에서 추가되거나 변경된 파일 시스템의 내용이 트리 구조로 보여진다. 사용자는 화살표 키로 레이어를 탐색하며, 각 레이어가 이미지 전체 크기에 기여하는 정도와 해당 레이어에서 실제로 변경된 파일을 정확히 확인할 수 있다.

dive는 단순한 내용 확인을 넘어서 이미지 효율성에 대한 지표를 제공한다. 분석이 끝나면 이미지의 "이미지 효율 점수"를 표시하는데, 이는 모든 레이어에서 낭비되는 공간(예: 후속 레이어에서 삭제된 파일이 남긴 데이터)의 비율을 계산한 것이다. 또한, 각 파일의 변경 이력을 추적하여 최종 이미지에는 존재하지 않지만 중간 레이어에 남아 불필요하게 공간을 차지하는 파일을 쉽게 찾아낼 수 있다. 이를 통해 개발자는 .dockerignore 파일 정리, Dockerfile 명령어 순서 재배치, 멀티-스테이지 빌드 적용 등의 최적화 작업을 데이터에 기반하여 수행할 수 있다.