Artifact Registry 비용을 줄이는 가장 확실한 방법은 사용하지 않는 오래된 이미지 버전을 자동으로 삭제하는 '정리 정책(Cleanup Policies)'을 도입하는 것입니다. 단순히 이미지를 업로드하는 것에 그치지 않고, 프로젝트의 생명 주기에 맞춰 보관 기간이나 개수를 제한하지 않으면 저장소 비용은 매달 기하급수적으로 늘어날 수밖에 없습니다.
클라우드 인프라를 운영하다 보면 컴퓨팅 자원만큼이나 신경 쓰이는 것이 바로 스토리지 비용입니다. 특히 CI/CD 파이프라인이 활발하게 돌아가는 환경에서는 하루에도 수십 개의 컨테이너 이미지가 생성되는데, 이를 방치하면 어느 순간 전체 클라우드 비용의 상당 부분을 차지하게 됩니다. 구글 클라우드(GCP)의 전반적인 비용 관리 체계를 이해하고 있다면, 서비스별로 최적화 포인트를 찾는 것이 운영 효율화의 핵심입니다.
많은 운영자가 실수하는 부분 중 하나가 '나중에 필요할지도 모른다'는 막연한 불안감에 모든 빌드 결과물을 무기한 보관하는 것입니다. 하지만 실제 장애 복구나 롤백에 필요한 이미지는 최근 몇 개의 버전인 경우가 대부분입니다. 따라서 비즈니스 요구사항에 맞는 명확한 삭제 기준을 세우는 것이 기술적인 설정보다 선행되어야 합니다.
이 글에서는 Artifact Registry의 요금 구조를 명확히 짚어보고, 실무에서 즉시 적용할 수 있는 자동 정리 설정법과 비용을 낭비하게 만드는 흔한 운영 실수들을 정리해 보겠습니다.
핵심 내용 먼저 보기
핵심 키워드 Artifact Registry 비용 줄이기 · 연관 검색어 Artifact Registry 비용 줄이기, GCP 비용 최적화, 컨테이너 이미지 관리, Artifact Registry 정리 정책, 구글 클라우드 스토리지 비용
Artifact Registry 요금이 생각보다 많이 나오는 이유: 저장소와 네트워크의 관계
Artifact Registry의 비용은 크게 데이터 저장 용량(Storage)과 네트워크 전송량(Egress)으로 나뉩니다. 저장소 요금은 매달 저장된 데이터의 GB당 단가로 계산되는데, 리전별로 단가가 다르며 멀티 리전(Multi-region)을 사용할 경우 단일 리전보다 비용이 더 높게 책정됩니다. 고가용성이 필수적인 운영 환경이 아니라면 굳이 비싼 멀티 리전을 고집할 필요가 없습니다.
네트워크 비용의 경우, 동일한 리전 내의 Google Cloud 서비스(예: GKE, Cloud Run)로 이미지를 당겨올 때는 비용이 발생하지 않지만, 외부 네트워크나 다른 리전으로 이미지를 전송할 때는 상당한 비용이 발생할 수 있습니다. 따라서 빌드 서버와 배포 대상, 그리고 레지스트리의 위치를 최대한 일치시키는 것이 네트워크 비용 최적화의 기본입니다.
수동 삭제는 한계가 있습니다: 자동 정리 정책(Cleanup Policies) 설정하기
가장 권장하는 방법은 Artifact Registry에서 제공하는 정리 정책 기능을 활용하는 것입니다. 이 기능을 사용하면 특정 태그가 없는 이미지(Untagged images)를 삭제하거나, 생성된 지 일정 기간이 지난 이미지를 자동으로 정리할 수 있습니다. 예를 들어 '최근 10개의 버전만 유지'하거나 '30일이 지난 이미지는 삭제'하는 식의 규칙을 JSON이나 콘솔 UI를 통해 설정할 수 있습니다.
실무적인 팁을 드리자면, keepMostRecentVersions와 keepTags 조건을 조합하는 것이 좋습니다. 중요한 릴리스 버전(예: v1.0, v2.0)은 태그를 기준으로 보존하고, 단순 개발용 빌드(latest 또는 커밋 해시 태그)는 기간을 짧게 잡아 삭제 주기를 빠르게 가져가는 전략이 비용 절감에 매우 효과적입니다.
실무에서 놓치기 쉬운 포인트: 태그 없는 이미지(Dangling Images)와 멀티 리전 설정
이미지를 새로 푸시할 때 동일한 태그(예: latest)를 사용하면, 기존에 해당 태그를 가졌던 이미지는 태그가 없는 상태(Untagged)로 남게 됩니다. 이를 흔히 'Dangling Image'라고 부르는데, 눈에 보이지 않지만 여전히 용량을 차지하며 비용을 발생시킵니다. 정리 정책을 설정할 때 반드시 tagState: "UNTAGGED" 조건을 포함하여 이 유령 이미지들을 주기적으로 청소해줘야 합니다.
또한, 초기 설정 시 기본값으로 선택되는 경우가 많은 멀티 리전(us, eu, asia 등) 설정은 데이터 복제 비용이 포함되어 있어 단일 리전보다 약 2배 가까이 비쌉니다. 서비스가 특정 국가에서만 운영된다면 해당 국가의 단일 리전(예: asia-northeast3)으로 레지스트리를 생성하는 것만으로도 고정 지출을 절반으로 줄일 수 있습니다.
빌드 파이프라인 최적화로 불필요한 이미지 생성 줄이기
근본적으로 저장소에 쌓이는 데이터 양을 줄이려면 CI/CD 파이프라인 자체를 점검해야 합니다. 모든 커밋마다 이미지를 빌드하고 푸시하는 방식은 편리하지만, 실제 배포되지 않는 수많은 쓰레기 이미지를 양산합니다. 특정 브랜치(Main, Develop)에 머지될 때만 푸시하거나, 빌드 단계에서는 로컬 캐시를 활용하고 최종 승인된 결과물만 레지스트리에 올리는 구조로 개선해 보세요.
이미지 자체의 크기를 줄이는 것도 방법입니다. Multi-stage build를 활용해 실행에 불필요한 빌드 도구나 소스 코드를 제외하고, Alpine Linux나 Distroless 같은 경량 베이스 이미지를 사용하면 이미지 한 장당 용량을 수백 MB에서 수십 MB 단위로 줄일 수 있습니다. 이는 저장 비용뿐만 아니라 배포 속도 향상에도 큰 도움이 됩니다.
Artifact Registry 비용 관리는 한 번의 설정으로 끝나는 것이 아니라, 프로젝트의 규모가 커짐에 따라 지속적으로 모니터링해야 하는 영역입니다. 자동 정리 정책을 도입하고 리전 설정을 최적화하는 것만으로도 운영 비용의 30~50% 이상을 절감할 수 있는 경우가 많습니다.
만약 빌드 과정 전반의 비용을 더 깊게 최적화하고 싶다면, 레지스트리뿐만 아니라 빌드 도구의 사양과 실행 시간도 함께 살펴봐야 합니다. 무조건 낮은 사양을 쓴다고 비용이 줄어드는 것은 아니기 때문입니다.
이와 관련하여 더 자세한 내용이 궁금하시다면, 이전에 작성한 Cloud Build 비용 줄이기, 무작정 낮은 사양만 고집하면 안 되는 이유 글을 참고해 보시기 바랍니다. 빌드 효율과 저장소 관리는 결국 하나의 파이프라인 안에서 맞물려 돌아가는 톱니바퀴와 같습니다.
자주 묻는 질문
이미지 태그만 삭제하면 실제 용량도 줄어드나요?
아니요, 태그를 삭제한다고 해서 실제 이미지 데이터(Layer)가 삭제되지는 않습니다. 태그가 없는 상태(Untagged)로 저장소에 남아 계속 비용이 발생하므로, 정리 정책을 통해 해당 다이제스트(Digest) 자체를 삭제해야 합니다.
정리 정책을 설정하면 소급 적용이 되나요?
네, 정리 정책을 설정하고 활성화하면 조건에 맞는 기존의 오래된 이미지들도 정책에 따라 순차적으로 삭제됩니다. 단, 실제 삭제가 반영되기까지는 약간의 시간이 소요될 수 있습니다.
멀티 리전에서 단일 리전으로 이미지를 옮기려면 어떻게 하나요?
기존 레지스트리의 설정을 직접 바꿀 수는 없습니다. 새로운 단일 리전 레지스트리를 생성한 뒤, 이미지를 다시 푸시하거나 gcrane 같은 도구를 사용하여 이미지를 복사해야 합니다. 이후 파이프라인의 주소를 새 레지스트리로 변경해야 합니다.
함께 보면 좋은 글
해시태그
#ArtifactRegistry비용줄이기 #GCP비용최적화 #컨테이너이미지관리 #ArtifactRegistry정리정책 #구글클라우드스토리지비용 #DanglingImages삭제
'IT' 카테고리의 다른 글
| 하드코딩 상수 추출이 코드 유지보수 비용을 결정짓는 이유와 실무 적용 기준 (0) | 2026.08.09 |
|---|---|
| Docker Python 스크립트 배포, 환경 충돌 없이 컨테이너로 실행하는 실전 방법 (0) | 2026.08.09 |
| Cloud Build 비용 줄이기, 무작정 낮은 사양만 고집하면 안 되는 이유 (0) | 2026.08.09 |
| AI 답변 품질 높이기: 원하는 결과가 안 나오는 이유와 실무 프롬프트 전략 (0) | 2026.08.09 |
| 벡터 검색이란 무엇인가: 키워드 매칭의 한계를 넘는 의미 기반 데이터 탐색 원리 (0) | 2026.08.09 |