docker commit vs Dockerfile: 컨테이너 수정 내용을 이미지로 남겨도 될까?

실행 중인 Docker 컨테이너에서 소스와 패키지를 수정한 뒤 이미지로 남길 수는 있습니다. 하지만 docker commit과 Dockerfile은 목적이 다릅니다. 빠른 진단용 스냅샷과 다시 만들 수 있는 배포 이미지 중 무엇을 선택해야 하는지, volume 누락과 비밀정보 위험까지 비교합니다.

핵심 요약

일회성 조사·복구 지점은 docker commit이 유용할 수 있습니다. 팀 배포와 반복 빌드는 변경 과정을 Dockerfile·의존성 파일·소스 관리에 기록하세요. commit에는 mounted volume 데이터가 포함되지 않습니다.

목차

1. 핵심 차이
2. commit이 저장하는 범위
3. 재현성과 보안
4. 크기·성능·비용
5. 상황별 추천과 전환
6. FAQ

1. docker commit vs Dockerfile 핵심 차이

기준	docker commit	Dockerfile + build
입력	현재 컨테이너의 변경 상태	명령과 build context
추적성	무엇을 했는지 별도 기록 필요	Dockerfile을 코드 리뷰·버전 관리 가능
재현	같은 수동 과정을 되풀이하기 어려움	같은 입력으로 다시 빌드 가능, 외부 입력 고정은 별도 필요
대표 용도	디버깅 상태 보존·임시 조사	개발·CI·배포 이미지

2. 컨테이너 수정 내용은 어디까지 저장될까?

컨테이너는 읽기 전용 이미지 레이어 위에 고유한 writable layer를 가집니다. 컨테이너 내부에서 파일을 만들거나 패키지를 설치하면 일반적으로 이 writable layer에 변경이 기록됩니다. docker commit 컨테이너 새이미지:태그는 그 변경으로 새 이미지를 만듭니다.

docker container diff my-container
docker commit --message "debug snapshot before rebuild" my-container myapp:debug-20260910
docker image inspect myapp:debug-20260910 --format '{{.Id}}'
docker image history myapp:debug-20260910

docker container diff의 표시는 A(추가), C(변경), D(삭제)입니다. 그러나 mounted volume이나 bind mount의 데이터는 commit에 포함되지 않습니다. 소스를 bind mount로 연결해 편집했다면 수정된 소스는 host에 있고 새 이미지에 자동 복사되지 않습니다.

공식 문서상 commit 중에는 일관성 위험을 줄이기 위해 컨테이너 프로세스가 기본적으로 일시 중지됩니다. --no-pause를 쓰면 실행 중 변경과 겹칠 수 있으므로 상태가 많은 앱에서는 주의합니다.

3. 재현성과 비밀정보가 선택을 가릅니다

Dockerfile은 각 명령으로 이미지 레이어를 만들고 COPY로 build context의 파일을 넣습니다. 변경 이유를 코드 리뷰하고 CI에서 다시 실행하기 쉽습니다. 다만 태그·패키지 버전·외부 다운로드를 고정하지 않으면 Dockerfile만 있다고 완전한 재현성이 생기는 것은 아닙니다.

commit은 셸 기록, 편집 순서, 다운로드 출처가 이미지 자체에서 충분히 설명되지 않습니다. 또한 writable layer에 토큰, 셸 기록, 임시 설정, 캐시가 남아 있다면 새 이미지에도 들어갈 수 있습니다. 레지스트리에 올리기 전에 단순히 파일을 삭제했다고 안심하지 말고 새 Dockerfile에서 필요한 항목만 복사해 다시 빌드하는 편이 안전합니다.

주의

commit은 volume 백업 도구도, 비밀정보 정리 도구도 아닙니다. 이미지 layer에 들어간 비밀은 후속 layer에서 삭제해도 이전 layer에 남을 수 있습니다. 의심되는 자격 증명은 폐기·교체하고 깨끗한 입력으로 다시 빌드하세요.

4. 크기·성능·가격을 어떻게 비교할까?

commit과 Dockerfile은 별도 사용료가 있는 두 상품이 아닙니다. 비용은 이미지 저장·전송, CI 시간, 장애 복구와 검토 시간에서 생깁니다. commit이 항상 더 빠르거나 Dockerfile 이미지가 항상 더 작다고 단정할 수 없습니다. 실제 layer 내용과 빌드 캐시, 정리 방식에 따라 달라집니다.

비교할 때는 docker image history, docker image inspect, 레지스트리 저장량, 깨끗한 host에서 재빌드 성공 여부를 확인하세요. 애플리케이션 처리 성능은 생성 방식보다 최종 파일과 런타임 설정에 더 직접적으로 좌우되므로 동일 작업으로 측정해야 합니다. 이 글은 벤치마크를 제시하지 않습니다.

5. 상황별 추천과 Dockerfile로 전환하는 방법

• 장애 컨테이너 조사: 즉시 상태를 보존해야 하고 접근이 통제된 환경이라면 commit을 임시 증거·복구 지점으로 검토합니다.
• 팀에 전달할 개발 환경: Dockerfile, lock/requirements 파일, 소스 커밋으로 표현합니다.
• 운영 배포: CI에서 Dockerfile을 빌드하고 이미지 digest·SBOM·스캔 정책을 적용하는 흐름을 우선합니다.
• 데이터셋 이동: 데이터가 mount에 있다면 애플리케이션별 백업·복원 방식을 사용합니다.

이미 수동으로 만든 컨테이너가 있다면 다음 순서로 전환합니다.

1. docker diff로 바뀐 경로를 목록화합니다.
2. 셸 기록과 패키지 목록을 참고하되 비밀정보는 새 입력에 넣지 않습니다.
3. 필요한 설치 명령은 Dockerfile RUN, 소스는 COPY, 실행 설정은 CMD 또는 ENTRYPOINT로 옮깁니다.
4. 깨끗한 build context에서 새 태그로 빌드합니다.
5. 임시 commit 이미지와 동작을 비교한 뒤 필요한 데이터는 별도 복원합니다.

6. FAQ

컨테이너 안에서 고친 소스도 commit되나요?

writable layer에서 고친 파일은 포함될 수 있습니다. 하지만 bind mount나 volume 경로에서 고친 내용은 포함되지 않습니다. docker inspect의 Mounts와 docker diff를 함께 확인하세요.

commit 이미지에서 Dockerfile을 복원할 수 있나요?

이미지 history와 설정 일부를 볼 수 있지만 원래 Dockerfile, 주석, 수동 명령의 의도를 완전하게 복원할 수는 없습니다.

commit 뒤 바로 push해도 되나요?

먼저 내용·설정·자격 증명·라이선스를 검토하세요. 공유·배포 목적이면 필요한 변경만 담은 Dockerfile로 다시 만드는 것을 권합니다.

docker commit 대신 docker save를 쓰면 되나요?

역할이 다릅니다. commit은 컨테이너 변경으로 새 이미지를 만들고 save는 이미 존재하는 이미지를 tar 아카이브로 옮깁니다.

결론

docker commit vs Dockerfile은 가능 여부가 아니라 목적의 선택입니다. 즉시 상태 보존에는 commit, 반복 가능한 팀 개발과 배포에는 Dockerfile을 사용하고 mounted 데이터와 비밀정보는 별도 관리하세요.

참고자료

• Docker Docs — docker container commit
• Docker Docs — docker container diff
• Docker Docs — Dockerfile overview
• Docker Docs — Storage drivers: images and writable container layer
• Docker Docs — Building best practices

작성·정보 확인: 2026-09-10