
팀의 Docker 이미지를 어디에 보관할지 결정할 때는 저장 공간만 비교하면 부족합니다. CI가 이미지를 올리고 운영 환경이 내려받는 과정에서 인증, 접근 권한, 취약점 검사와 롤백용 이미지 보존이 모두 연결됩니다. AWS 중심 팀은 Amazon ECR, 다양한 환경과 공개 배포를 함께 다루는 팀은 Docker Hub를 후보로 두고 실제 배포 경로를 시험해 보세요.
1. 레지스트리는 실행 서버와 역할이 다릅니다
컨테이너 레지스트리는 이미지를 저장하고 배포 환경에 전달합니다. 이미지를 보관했다고 웹 서비스가 실행되는 것은 아닙니다. 저장소 이름·태그·다이제스트와 실행 환경의 인증이 맞아야 배포할 수 있습니다. Docker Hub 저장소 공식 안내는 공개·비공개 저장소, 접근 관리와 이미지 보안 분석을 설명합니다. 필요한 기능이 실제 구독·조직 설정에서 제공되는지는 도입 시 확인하세요.
2. ECR과 Docker Hub의 선택 기준
| 판단 기준 | Amazon ECR 검토 방향 | Docker Hub 검토 방향 |
| 주요 배포 위치 | AWS 계정·리전과 배포 경로의 연결 | 여러 환경의 Docker 도구와 배포 경로 |
| 접근 통제 | IAM과 저장소 정책·인증 방식 | 조직·팀·저장소 접근 설정 |
| 공개 배포 | Private와 Public ECR을 구분해 선택 | 공개 또는 비공개 저장소 선택 |
| 검사 | 기본·향상된 스캔 범위와 비용 확인 | 보안 분석 기능·적용 범위 확인 |
| 비용 | 저장·전송·검사 등 적용 항목 확인 | 구독·비공개 저장소·사용 제한 확인 |
어떤 제품이 더 우수하다는 순위표가 아닙니다. 이미 사용 중인 계정 체계, CI 실행 위치, 배포 노드가 있는 곳과 팀 운영 방식이 판단 기준입니다. “무료로 시작할 수 있다”는 이유만으로 운영 저장소를 확정하면 이후 권한 분리와 배포 제한에서 재작업이 생길 수 있습니다.
3. 인증 성공과 다운로드 권한을 따로 시험하기
ECR 인증 공식 문서에서 안내하는 인증 토큰의 권한은 이를 요청한 IAM 주체의 권한과 연결되며 유효 기간도 존재합니다. CI의 로그인 성공만으로 운영 환경까지 내려받을 수 있다고 판단하지 마세요. 이미지 업로드 주체와 다운로드 주체를 구분해 필요한 작업과 저장소만 허용하는 구성을 검증합니다.
가상 예시로 개발팀은 이미지를 올릴 수 있지만 운영 노드는 내려받기만 하도록 설계할 수 있습니다. 시험할 때는 실제 운영과 같은 네트워크·실행 주체로 작은 테스트 이미지를 받아 봅니다. 저장소를 공개로 바꾸는 것이 권한 오류의 기본 해결책은 아닙니다. 개발자의 로컬 로그인과 서버의 인증 경로가 다른지도 확인하세요.
4. 취약점 검사와 이미지 정리 정책
ECR 스캔 안내에 따르면 기본 스캔과 Amazon Inspector 기반 향상된 스캔은 검사 대상과 방식에 차이가 있습니다. 기본 스캔 결과만 보고 모든 언어 패키지까지 지속 검사된다고 생각하면 안 됩니다. 적용 저장소·검사 빈도·알림 수신과 수정 담당자를 함께 정하세요.
이미지를 무한히 남기면 저장 비용과 관리 부담이 늘지만, 최신 몇 개만 기계적으로 보존하면 운영 중인 이미지나 롤백 후보를 지울 수 있습니다. ECR 수명 주기 정책 공식 안내처럼 적용 전 미리보기로 대상 이미지를 확인하고, 배포 중인 다이제스트와 복구 후보가 보존되는지 대조하세요.
예를 들어 개발 태그와 운영 릴리스 태그의 보존 정책을 다르게 설계한 뒤, 테스트 저장소에서 정리 대상 목록을 검토합니다. 실제 보존 개수와 기간은 배포 빈도·감사 요구·복구 목표로 정해야 합니다. “최근 10개면 충분하다”는 식의 공통 숫자를 모든 서비스에 적용하지 않는 편이 좋습니다.
5. 도입 체크리스트와 자주 묻는 질문
체크리스트: ① CI의 업로드 인증 ② 운영 주체의 다운로드 인증 ③ 공개 여부와 팀 권한 ④ 이미지 태그·다이제스트 기록 ⑤ 검사 범위와 알림 ⑥ 롤백 이미지 보존 ⑦ 저장·전송·구독 비용을 확인합니다. 하나라도 운영 담당자가 설명하지 못하면 작은 파일럿 저장소부터 검증하세요.
태그가 같으면 이미지 내용도 항상 같나요? 태그는 다른 이미지로 이동할 수 있습니다. 운영 배포 기록에는 다이제스트를 함께 남기면 무엇을 실행했는지 추적하기 쉽습니다.
스캔 결과가 없으면 안전한가요? 스캔 적용 여부와 완료 상태부터 확인해야 합니다. 검사 범위 밖의 문제와 실행 시 권한·설정 문제는 별도로 검토합니다.
레지스트리를 바꾸면 Dockerfile도 전부 바꾸나요? 먼저 이미지 참조 주소와 CI·운영 인증, 네트워크 경로를 점검합니다. 필요한 변경 범위는 기존 빌드와 배포 구성에 따라 달라집니다.
6. 배포 과정에서 비밀값까지 연결하기
레지스트리 인증정보의 발급·회수 책임까지 운영 문서에 남기세요. 비밀값 관리 방식은 기존 기업용 시크릿 관리 도입 가이드와 연결해 검토할 수 있습니다. 제품 이름보다 업로드부터 롤백까지 실제로 시험한 경로가 최종 선택의 근거가 됩니다.
자료 확인: 2026년 9월 28일. 제품 기능·요금·지원 범위는 변경될 수 있으므로 도입 직전 공식 문서와 해당 계정의 설정을 확인하세요.
'소프트웨어개발' 카테고리의 다른 글
| Docker x509 인증서 오류 해결: unknown authority·사내 CA·프록시 점검 순서 (0) | 2026.09.28 |
|---|---|
| ECS Fargate와 EC2 비교: 컨테이너 운영 비용·관리 책임·도입 체크리스트 (0) | 2026.09.28 |
| DNS_PROBE_FINISHED_NXDOMAIN 해결: 도메인·네임서버·DNS 레코드·캐시 점검 (0) | 2026.09.27 |