Docker 이미지 재현성 타임스탬프를 넘어선 도전

초록

본 연구는 2,000개의 GitHub 저장소에 포함된 Dockerfile을 대상으로 빌드 가능성 및 비트 단위 재현성을 측정한다. 전체의 56 %만이 빌드 가능했으며, 기본 환경에서 비트 단위 재현성은 2.7 %에 불과했다. 인프라 설정을 강화해도 재현성은 18.6 %포인트 상승했지만, 여전히 78.7 %가 비재현성 상태였다. 차후 분석에서는 타임스탬프·메타데이터 외에도 캐시, 로그, 문서, 부동 버전 지정 등 개발자 주도적인 요인이 주요 원인임을 밝혀냈다. 연구 결과를 토대로 Dockerfile 작성 가이드와 CI·린터 적용 방안을 제시한다.

상세 분석

이 논문은 Docker 이미지 재현성을 실증적으로 조사한 최초 규모의 연구 중 하나로, 샘플링 설계와 재현성 측정 파이프라인을 체계적으로 구축했다. 먼저 GitHub Archive를 활용해 2024년에 Dockerfile을 수정한 19,262개의 인기 저장소(★ ≥ 5)를 추출하고, 별 수에 따라 4개의 계층으로 층화 무작위 샘플링해 2,000개를 선정했다. 이는 인기 프로젝트와 소규모 프로젝트가 균형 있게 포함되도록 설계된 점이 강점이다.

빌드 파이프라인은 각 저장소에서 최상위 Dockerfile을 자동 탐색하고, 동일한 Docker 도구 체인(BuildKit)으로 두 차례 클린 빌드를 수행한다. 두 이미지의 SHA‑256 해시가 일치하면 ‘비트 단위 재현성(as‑is)’으로 분류한다. 일치하지 않을 경우, SOURCE_DATE_EPOCH를 커밋 시점으로 고정하고 Docker의 rewrite‑timestamp 옵션을 활성화해 인프라 수준의 비결정성을 제거한다. 이 설정 후에도 해시가 동일하면 ‘인프라 재현성’으로, 여전히 차이가 있으면 diffoci·diffoscope를 이용해 파일 내용 차이를 분석한다.

실험 결과는 두 가지 충격적인 사실을 드러낸다. 첫째, 전체 저장소의 절반 이상이 빌드 자체에 실패한다는 점이다. 이는 Dockerfile이 복잡한 외부 의존성(프라이빗 레지스트리, 네트워크 제한, 빌드 컨텍스트 누락 등)과 결합돼 실제 CI 환경에서 재현이 어려움을 시사한다. 둘째, 인프라 설정을 강화해도 비트 단위 재현성 비율은 2.7 %→21.3 %(2.7 %+18.6 %)에 그칠 뿐, 78.7 %가 여전히 비재현성이다. 이는 기존 연구가 강조한 ‘타임스탬프와 메타데이터’만으로는 충분히 설명되지 않음을 의미한다.

diffoscope 분석을 통해 도출된 주요 비재현성 요인은 다음과 같다. (1) 파일 시스템 메타데이터(타임스탬프, 소유자, 권한) – 모든 이미지에 존재. (2) 시스템 로그(/var/log/*) – 43 %에서 발견, 빌드 과정 중 생성된 로그가 이미지에 포함됨. (3) 캐시·데이터베이스 파일(apt 캐시, pip 캐시, npm 캐시 등) – 37 %에서 차이 발생, 캐시 정리 명령이 누락된 경우가 대부분. (4) 컴파일된 바이너리·아티팩트 – 20 %에서 버전·옵션 차이로 인한 바이너리 차이. (5) 애플리케이션 전용 파일(보고서, 모델, 다운로드 파일) – 13 %에서 비재현성 원인으로 확인. (6) 무작위·비결정적 데이터(날짜 기반 난수, UUID) – 9 % 정도. (7) 패키지 매니저 상태(패키지 인덱스, lock 파일 미동기화) – 5.6 %에 불과하지만, 특정 상황에서 큰 영향을 미침.

이러한 결과는 ‘개발자 제어 영역’이 재현성 확보에 핵심임을 강조한다. 단순히 빌드 타임스탬프를 고정하거나 레이어 메타데이터를 정규화하는 것만으로는 한계가 있다. 대신 Dockerfile 작성 시 다음과 같은 실천 방안을 제시한다. 첫째, 여러 RUN 명령을 하나로 합치고 --no-install-recommends 옵션을 사용해 불필요한 패키지 설치를 방지한다. 둘째, 각 패키지 설치 후 apt-get clean && rm -rf /var/lib/apt/lists/* 등 캐시 정리 명령을 반드시 삽입한다. 셋째, 베이스 이미지와 모든 패키지 버전을 명시적으로 고정한다(예: FROM python:3.11.6-slim·RUN pip install --no-cache-dir -r requirements.txt). 넷째, 런타임에 생성되는 파일(/etc/machine-id, 로그, 임시 디렉터리 등)을 이미지에 포함시키지 않도록 VOLUME이나 --tmpfs 옵션을 활용한다. 다섯째, 빌드 시점에 외부 네트워크 호출(예: 모델 다운로드)이나 무작위 데이터 생성을 피하고, 필요 시 사전 다운로드·고정된 파일을 COPY한다.

마지막으로, 연구는 공급망 보안 관점에서 중요한 함의를 제공한다. 현재 실무에서 해시 기반 이미지 검증을 적용하려면, 전체 Dockerfile의 80 % 이상이 비재현성임을 감안해 추가적인 검증 절차(예: 레이어 해시 비교, CI 단계에서 재현성 테스트)를 도입해야 한다. 또한, CI·CD 파이프라인에 재현성 린터를 통합해 위에서 제시한 ‘캐시 정리·버전 고정·런타임 파일 배제’ 규칙을 자동 검증하도록 하면, 개발자에게 실시간 피드백을 제공해 비재현성 코드를 사전에 차단할 수 있다.