Artifact Registry 비용을 줄이는 가장 확실한 방법은 '정리 정책(Cleanup Policies)'을 자동화하고, 불필요한 태그 없는(Untagged) 이미지를 주기적으로 소거하는 것입니다. 많은 운영 환경에서 빌드 파이프라인이 돌아갈 때마다 새로운 이미지가 쌓이지만, 정작 오래된 이미지를 지우는 프로세스는 누락되어 매달 스토리지 비용이 계단식으로 상승하곤 합니다.
클라우드 인프라를 운영하다 보면 서비스 규모가 커질수록 컨테이너 이미지의 크기와 개수도 기하급수적으로 늘어납니다. 처음에는 미미했던 비용이 어느 순간 무시하지 못할 수준이 되는 이유는 단순히 '보관'만 하기 때문이 아니라, 리전 간 데이터 전송이나 멀티 리전 설정 같은 세부적인 과금 요소를 간과하기 때문입니다.
이 글을 본격적으로 읽기 전에, Google Cloud의 전반적인 자원 관리 체계를 먼저 이해하고 있다면 Artifact Registry의 세부 설정이 왜 전체 아키텍처 비용에 영향을 주는지 더 명확하게 파악할 수 있습니다. 특히 CI/CD 파이프라인의 효율성과 저장소 관리는 떼려야 뗄 수 없는 관계에 있습니다.
단순히 '삭제' 버튼을 누르는 것을 넘어, 아키텍처 구조를 변경하고 정책을 자동화하여 지속 가능한 비용 절감 구조를 만드는 구체적인 방법들을 정리했습니다. 실무에서 흔히 놓치는 포인트들을 중심으로 하나씩 점검해 보시기 바랍니다.
핵심 내용 먼저 보기
핵심 키워드 Artifact Registry 비용 줄이기 · 연관 검색어 Artifact Registry 비용, Artifact Registry 비용 줄이기, GCP 비용 최적화, 컨테이너 이미지 관리, Artifact Registry 정리 정책
비용이 발생하는 두 가지 핵심 축: 스토리지와 네트워크
Artifact Registry의 과금 체계는 크게 데이터 보관(Storage)과 데이터 전송(Network)으로 나뉩니다. 스토리지는 매달 저장된 기가바이트(GB) 단위로 요금이 부과되며, 네트워크는 이미지를 Registry에서 외부나 다른 리전으로 끌어올 때 발생합니다. 많은 팀이 간과하는 사실 중 하나는 '멀티 리전' 저장소를 사용할 경우 단일 리전보다 보관 단가가 높을 뿐만 아니라, 리전 간 복제 비용이 추가될 수 있다는 점입니다.
실무적인 판단 포인트는 '가용성'과 '비용' 사이의 균형입니다. 모든 이미지를 멀티 리전에 둘 필요는 없습니다. 개발(Dev)이나 스테이징(Staging) 환경의 이미지는 단일 리전에 배치하고, 운영 환경과 동일한 리전에 저장소를 위치시켜 네트워크 전송료(Egress)를 0으로 만드는 것이 기본 중의 기본입니다.
정리 정책(Cleanup Policies)으로 자동 삭제 프로세스 구축
수동으로 이미지를 지우는 것은 운영 실수(Human Error)를 유발할 뿐만 아니라 지속 가능하지 않습니다. Artifact Registry에서 제공하는 '정리 정책' 기능을 활용하면 특정 조건에 맞는 이미지를 자동으로 삭제할 수 있습니다. 예를 들어, '최근 10개의 이미지만 남기고 나머지는 삭제'하거나 '생성된 지 30일이 지난 이미지는 삭제'하는 식의 규칙을 설정할 수 있습니다.
여기서 주의할 점은 'Keep' 정책과 'Delete' 정책의 우선순위입니다. 중요한 릴리스 태그(예: v1.0, prod-*)가 붙은 이미지는 절대 지워지지 않도록 보호 규칙을 먼저 세우고, 그 외의 임시 빌드 결과물들을 삭제 대상으로 지정해야 합니다. 정책을 처음 적용할 때는 --dry-run 옵션이나 콘솔의 미리보기를 통해 어떤 이미지가 삭제될지 반드시 확인하는 과정이 필요합니다.
태그 없는(Untagged) 이미지와 레이어 낭비 막기
CI/CD 과정에서 동일한 태그(예: latest)로 이미지를 계속 푸시하면, 기존에 해당 태그를 가졌던 이미지는 태그가 사라진 채 'Dangling Image' 상태가 됩니다. 이 이미지들은 콘솔 화면에서 필터를 걸지 않으면 잘 보이지 않지만, 실제로는 스토리지 용량을 그대로 차지하며 비용을 발생시킵니다. 정리 정책 설정 시 tagState: UNTAGGED 조건을 활용하여 이 유령 데이터들을 주기적으로 소거해야 합니다.
또한, Dockerfile 작성 시 레이어 수를 최소화하고 .dockerignore를 적절히 설정하여 이미지 자체의 크기를 줄이는 노력도 병행되어야 합니다. 이미지 크기가 1GB에서 200MB로 줄어들면 보관 비용뿐만 아니라 빌드 속도와 배포 속도까지 개선되는 일석삼조의 효과를 거둘 수 있습니다.
실무에서 자주 하는 실수: 리전 불일치와 과도한 보관
가장 흔한 운영 실수 중 하나는 GKE(Google Kubernetes Engine) 클러스터는 서울(asia-northeast3)에 있는데, Artifact Registry는 미국(us)이나 멀티 리전(us, eu 등)에 두는 경우입니다. 이 경우 이미지를 Pull 할 때마다 대륙 간 네트워크 비용이 발생하여 배포 비용이 폭증하게 됩니다. 반드시 워크로드가 실행되는 위치와 저장소의 위치를 일치시키십시오.
또한, 모든 브랜치의 빌드 결과물을 Artifact Registry에 저장할 필요가 있는지 검토해야 합니다. Feature 브랜치의 테스트용 이미지는 빌드 후 테스트가 끝나면 즉시 삭제하거나, 별도의 단기 보관용 저장소를 운영하는 것이 효율적입니다. 무분별한 docker push가 월말 청구서의 주범임을 인지해야 합니다.
Artifact Registry 비용 최적화는 단순히 돈을 아끼는 문제를 넘어, 클라우드 자원을 얼마나 체계적으로 관리하고 있느냐를 보여주는 척도입니다. 자동화된 정리 정책을 도입하고 리전 배치를 최적화하는 것만으로도 별도의 인프라 변경 없이 상당한 금액을 절감할 수 있습니다.
이미지 저장소의 비용을 줄였다면, 다음 단계로는 이미지를 생성하는 과정인 빌드 파이프라인의 비용을 점검해 볼 차례입니다. 빌드 시간이 길어질수록 컴퓨팅 자원 비용이 늘어나고, 이는 결국 전체 운영 비용의 상승으로 이어지기 때문입니다.
효율적인 CI/CD 환경을 구축하고 싶다면 이전에 다룬 Cloud Build 비용 줄이기: 빌드 시간 단축과 머신 유형 선택으로 낭비 막는 법 글을 함께 읽어보시길 권장합니다. 빌드 최적화와 저장소 최적화가 결합될 때 비로소 진정한 의미의 운영 효율화가 완성됩니다.
자주 묻는 질문
정리 정책을 설정하면 이미지가 즉시 삭제되나요?
아니요. 정리 정책은 설정 후 즉시 실행되는 것이 아니라 Google Cloud의 백그라운드 작업 스케줄에 따라 주기적으로 실행됩니다. 정책을 적용한 후 실제 용량이 줄어들기까지는 약간의 시간이 소요될 수 있습니다.
멀티 리전 저장소를 단일 리전으로 변경할 수 있나요?
기존 저장소의 위치 설정을 직접 변경할 수는 없습니다. 단일 리전에 새로운 저장소를 생성한 뒤, 필요한 이미지를 복사(gcrane 등의 도구 활용)하고 파이프라인의 주소를 변경하는 마이그레이션 과정이 필요합니다.
태그가 없는(Untagged) 이미지는 왜 생기나요?
동일한 태그 이름(예: latest)으로 새 이미지를 푸시하면, 기존에 그 태그를 달고 있던 이미지에서 태그가 떨어져 나가면서 발생합니다. 이를 방지하려면 빌드 시마다 고유한 버전 번호나 커밋 해시를 태그로 사용하는 것이 좋지만, 이 경우에도 오래된 이미지는 정리 정책으로 지워줘야 합니다.
함께 보면 좋은 글
해시태그
#ArtifactRegistry비용줄이기 #ArtifactRegistry비용 #GCP비용최적화 #컨테이너이미지관리 #ArtifactRegistry정리정책 #구글클라우드스토리지요금
'IT' 카테고리의 다른 글
| .env 파일 관리, 보안 사고를 막고 배포 효율을 높이는 실무 운영 원칙 (0) | 2026.07.26 |
|---|---|
| Docker Python 스크립트 배포 시 환경 충돌을 방지하는 Dockerfile 작성과 실행 방법 (0) | 2026.07.25 |
| Cloud Build 비용 줄이기: 빌드 시간 단축과 머신 유형 선택으로 낭비 막는 법 (0) | 2026.07.25 |
| 검색 유입형 글쓰기, 클릭을 부르는 제목과 끝까지 읽게 만드는 본문 설계의 핵심 (0) | 2026.07.25 |
| AI 블로그 운영, 단순 자동화보다 '검색 의도'와 '전문성'을 결합해야 성장한다 (0) | 2026.07.25 |