Minimus 사용자가 먼저 확인할 일정
Docker Blog에 따르면 Minimus는 운영 종료를 공지했고, 기존 이미지는 2026년 10월 22일 레지스트리가 내려가기 전까지 60일 유지보수 기간 동안 업스트림 업데이트를 받습니다. 이미 내려받은 이미지는 그 이후에도 실행될 수 있지만, 레지스트리 종료 뒤에는 추가 업데이트가 제공되지 않습니다. 즉 새 CVE가 발견되어도 해당 이미지에는 패치가 들어오지 않는다는 점이 핵심입니다.
따라서 지금 봐야 할 질문은 “어느 이미지로 바꿀 것인가”보다 먼저 “어떤 서비스가 Minimus 이미지를 실제로 쓰고 있는가”입니다. 개인 서버, 연구용 실험 환경, 수업 프로젝트, 회사 CI/CD 모두 Dockerfile의 FROM 라인과 빌드 로그, 배포 매니페스트, 이미지 태그 고정 방식을 확인해야 합니다.
Docker Hardened Images로 옮길 때의 핵심
Docker는 Minimus 고객에게 무료 마이그레이션 지원을 제공한다고 밝혔습니다. 이미지 목록, 컴플라이언스 요구사항, 전환 계획을 검토받고 싶다면 minimus@docker.com으로 문의할 수 있습니다. 다만 실제 적용 전에는 자신의 계정, 팀 권한, 사용 중인 이미지 범위, 유료 기능 필요 여부를 따로 확인해야 합니다.
Docker Hardened Images는 Docker가 소스에서 빌드하고 지속적으로 유지보수하는 최소화된 hardened 이미지 카탈로그입니다. 원문 기준으로 4,000개 이상의 이미지가 제공되며 Alpine과 Debian 계열 호환성을 강조합니다. 많은 서비스에서는 Dockerfile의 FROM 라인을 대응 이미지로 바꾸는 방식이 출발점이 될 수 있지만, 모든 워크로드가 단순 교체로 끝난다고 단정하면 안 됩니다.
무료 카탈로그와 유료 기능을 구분해야 하는 이유
원문은 Docker의 무료 오픈소스 카탈로그가 Apache 2.0 라이선스로 제공되고, 프로덕션 사용이 가능하며, 사용자 수 제한이 없다고 설명합니다. 이 내용만 보면 개인 사용자나 학생, 연구자에게는 진입 장벽이 낮아 보입니다. 하지만 가격표, 팀 정책, 보안 요건, 지원 수준은 실제 적용 시점의 공식 문서를 기준으로 다시 확인해야 합니다.
특히 유료 티어에는 SLA 기반 remediation, FIPS와 STIG 변형, 커스터마이징, 수명 종료 이후 버전에 대한 최대 5년 보장 같은 항목이 포함된다고 소개됩니다. 이 기능들은 보안 감사를 받는 조직, 규제 산업, 장기 유지보수 버전을 운영하는 팀에는 중요할 수 있습니다. 반대로 개인 프로젝트나 단기 연구 환경이라면 무료 카탈로그만으로 충분한지 먼저 검토하는 편이 합리적입니다.
전환 전에 이미지 목록부터 고정하기
가장 먼저 해야 할 일은 현재 쓰는 Minimus 기반 이미지를 나열하는 것입니다. Dockerfile만 보면 빠지는 경우가 있으므로 GitHub Actions, GitLab CI, Compose 파일, Kubernetes 매니페스트, Helm values, 빌드 스크립트까지 함께 확인해야 합니다. 이미지 이름과 태그, 사용 서비스, 배포 환경, 롤백 방법을 표로 정리하면 전환 범위를 과장하지 않고 볼 수 있습니다.
| 확인 항목 | 질문 | 판단 기준 |
|---|---|---|
| 이미지 사용 위치 | Minimus 이미지가 Dockerfile, CI, 배포 설정 중 어디에 들어가 있는가? | 실제 프로덕션 경로에 있으면 우선순위를 높인다. |
| 대응 이미지 | DHI 카탈로그에 같은 런타임, 배포판 계열, 버전대가 있는가? | Alpine 또는 Debian 호환성이 맞아야 검증을 시작한다. |
| 보안 산출물 | SBOM, CVE 가시성, provenance, 서명 검증이 필요한가? | 감사나 납품 요건이 있으면 문서화된 증빙까지 확인한다. |
| 유료 기능 | SLA, FIPS, STIG, EOL 이후 지원이 필요한가? | 필요 기능이 무료 카탈로그 밖에 있으면 비용과 계약 조건을 확인한다. |
FROM 라인 교체가 충분한지 보는 법
Docker는 이번 전환을 “재구축보다 교체에 가깝다”는 취지로 설명합니다. 실제로 대부분의 서비스에서는 FROM 라인을 바꾸는 것이 첫 변경점일 수 있습니다. 하지만 베이스 이미지가 바뀌면 패키지 경로, 기본 사용자, 인증서 위치, 셸 유무, libc 차이, 패키지 매니저 동작이 달라질 수 있습니다.
개발자는 교체 직후 빌드 성공 여부만 보지 말고 런타임 동작을 확인해야 합니다. 컨테이너가 뜨는지, 헬스체크가 통과하는지, 로그 포맷이 유지되는지, 애플리케이션이 필요한 OS 패키지를 모두 찾는지, CI 캐시가 예상대로 동작하는지를 함께 봐야 합니다. 연구 환경에서는 재현성도 중요합니다. 기존 결과와 새 이미지에서 나온 결과가 달라지는지 확인하고, 이미지 digest를 기록해두는 것이 좋습니다.
보안 장점은 수치보다 조건을 봐야 한다
원문은 DHI가 near-zero CVE, 억제되지 않은 CVE 가시성, 전체 SBOM, SLSA Build Level 3 provenance, 암호학적 서명을 제공한다고 설명합니다. 또한 표준 공개 이미지에서 이동한 팀이 CVE를 최대 95%, 공격 표면을 최대 90% 줄인 사례를 언급합니다. 이 수치는 관심을 가질 만하지만, 모든 프로젝트에 같은 결과가 보장된다는 뜻으로 읽으면 안 됩니다.
실제 판단 기준은 현재 이미지가 얼마나 비대하고, 어떤 패키지가 포함되어 있으며, 취약점 스캐너가 무엇을 보고 있는지입니다. 이미 최소 이미지와 엄격한 빌드 정책을 쓰는 팀이라면 개선폭이 작을 수 있습니다. 반대로 오래된 범용 이미지를 쓰고 있거나 불필요한 패키지가 많은 서비스라면 효과가 클 수 있습니다.
개인 사용자와 학생에게 맞는 확인 방식
개인 서버나 사이드 프로젝트라면 전환의 핵심은 비용과 유지관리 부담입니다. 무료 카탈로그에서 필요한 이미지가 제공되고, Dockerfile 변경만으로 빌드와 배포가 통과한다면 시도해볼 가치가 있습니다. 다만 레지스트리 접근 방식, 이미지 태그 정책, 업데이트 주기, 기존 백업 이미지를 어떻게 보관할지는 미리 정해야 합니다.
학생이나 연구자는 과제 제출, 논문 재현, 실험 자동화에서 이미지 변경이 결과에 영향을 주지 않는지 확인해야 합니다. 보안성이 좋아도 실험 재현성이 깨지면 별도의 기록이 필요합니다. 기존 Minimus 이미지와 DHI 기반 이미지에서 같은 테스트 데이터를 실행하고 결과 차이를 남기는 방식이 안전합니다.
팀과 CI/CD 담당자가 볼 지점
팀 환경에서는 한 서비스만 바꾸는 문제가 아닙니다. 공통 베이스 이미지, 내부 템플릿, 보안 스캐너 예외 목록, 배포 승인 정책, SBOM 저장 위치가 함께 연결되어 있을 수 있습니다. DHI가 제공하는 SBOM과 provenance, 서명을 실제 파이프라인에서 검증할지, 단순 보관할지, 배포 차단 조건으로 쓸지도 정해야 합니다.
마이그레이션은 전체 서비스를 한 번에 바꾸기보다 영향이 작은 서비스부터 시작하는 편이 낫습니다. 빌드 시간, 이미지 크기, CVE 리포트, 배포 실패율, 롤백 소요 시간을 비교하면 전환이 실제 운영 비용을 줄이는지 볼 수 있습니다. 레지스트리 종료일이 정해져 있으므로 프로덕션에서 쓰는 Minimus 이미지는 우선순위를 앞에 두는 것이 합리적입니다.
마이그레이션 기록에 남길 항목
- 기존 Minimus 이미지 이름, 태그, digest
- 대응되는 Docker Hardened Images 항목
- Dockerfile 또는 CI 설정 변경 위치
- 빌드와 테스트 통과 여부
- 런타임 검증 결과와 헬스체크 상태
- 취약점 스캔 결과 변화
- SBOM, provenance, 서명 검증 여부
- 문제 발생 시 되돌릴 이미지와 배포 절차
바로 옮기기 어려운 경우
대응 이미지가 없거나, 특정 OS 패키지에 강하게 묶여 있거나, 감사 요건상 이미지 공급망 변경 승인이 필요한 경우에는 단순 교체가 어렵습니다. 이때는 Minimus 유지보수 기간 안에 대체 이미지를 비교하고, 임시로 고정해둘 이미지와 장기적으로 옮길 이미지를 분리해야 합니다. 이미 내려받은 이미지는 계속 실행될 수 있지만, 2026년 10월 22일 이후 새 취약점 패치를 기대할 수 없다는 점을 리스크로 기록해야 합니다.
결론적으로 이번 변화는 새 도구를 도입할지 말지의 문제가 아니라, 이미 쓰고 있을 수 있는 베이스 이미지의 공급망이 바뀌는 문제입니다. Minimus 이미지를 프로덕션이나 반복 연구 환경에서 쓰고 있다면 지금 이미지 목록을 확인하고, DHI 카탈로그 또는 다른 대안을 기준으로 교체 가능성을 검증해야 합니다.
출처와 검증
이 글은 Docker Blog의 발표 내용을 바탕으로 작성했다. 세부 카탈로그 범위, 유료 기능, 지원 조건, 마이그레이션 가이드는 적용 시점의 공식 문서를 기준으로 다시 확인해야 한다.
원문: Moving from Minimus to Docker Hardened Images | Docker Blog