Cloud Storage를 스스로 점검한다: Storage Intelligence Advisor GA의 의미
클라우드 스토리지는 용량만 늘어나는 서비스가 아닙니다. 객체 수가 증가하고, 애플리케이션이 다른 리전의 버킷을 읽고, 오래 보관하려고 선택한 저비용 스토리지에 예상보다 자주 접근하면 비용과 성능 문제가 함께 생깁니다. 문제는 이런 변화가 한 프로젝트의 단일 대시보드가 아니라 조직·폴더·프로젝트·버킷·서비스 계정에 흩어져 나타난다는 점입니다.
Google Cloud는 2026년 9월 18일 Cloud Storage용 Storage Intelligence Advisor의 정식 출시(GA)를 알렸습니다. Advisor는 Cloud Storage 사용량의 기준선을 만들고, 이상 징후를 찾아내며, 원인이 되는 리소스까지 내려가 볼 수 있는 다음 단계를 제시합니다. 공식 설명에 따르면 별도의 커스텀 데이터 파이프라인이나 BigQuery 스크립트를 먼저 만들지 않아도 조직 단위의 스토리지 상태를 볼 수 있습니다.
이번 출시는 단순한 “스토리지 대시보드 하나 추가”로 보기보다, 스토리지 운영을 관측 → 원인 분석 → 비용·성능 조정의 반복 가능한 제어 루프로 바꾸려는 흐름으로 이해할 필요가 있습니다.
이 글은 Google Cloud의 2026년 9월 18일 발표, Storage Intelligence Advisor 개발자 문서, Cloud Storage 가격 문서를 기준으로 작성했습니다. 기능과 가격은 리전·에디션·리소스 범위에 따라 달라질 수 있으므로 실제 활성화 전 콘솔과 최신 문서를 확인해야 합니다.
1. 무엇이 정식 출시됐나?
Storage Intelligence Advisor는 Storage Intelligence에 포함된 관리 화면입니다. 사용자는 프로젝트, 폴더 또는 조직을 범위로 선택해 다음 세 종류의 정보를 확인합니다.
| 정보 | 의미 | 활용 |
|---|---|---|
| Metrics | 저장 용량, 객체 수, 연산량 같은 측정값 | 현재 상태와 추세 파악 |
| Findings | 평소 기준선에서 벗어난 이상 징후 | 무엇이 바뀌었는지 우선순위 지정 |
| Next steps | 발견 사항에 연결된 권장 조치 | 비용·성능 개선의 출발점 |
Google Cloud가 발표한 GA 기능은 네 가지 핵심 이상 징후를 자동으로 찾습니다.
- Coldline·Archive 데이터의 Class A/B 작업 급증
- 다른 리전으로 나가는 Cloud Storage 데이터 전송량 급증
429 Too Many Requests와 같은 요청 제한 오류 급증- 최근 30일 기준선보다 총 저장 바이트가 빠르게 증가
각 발견 사항은 단순히 “비용이 올랐다”라고 말하는 대신, 영향을 받은 프로젝트·버킷·객체 접두사(prefix)·서비스 계정을 확인할 수 있는 드릴다운 정보를 제공합니다. 운영자는 원인을 확인한 뒤 스토리지 클래스 변경, 리전 배치 조정, I/O 패턴 개선 같은 조치를 선택합니다.
중요한 점은 Advisor가 운영자의 승인 없이 모든 것을 자동으로 바꾸는 마이그레이션 도구가 아니라는 것입니다. 이상 징후를 발견하고 근거를 모아 다음 결정을 빠르게 만드는 서비스에 가깝습니다.
2. 스토리지 문제를 “크기”만으로 보면 놓치는 것
많은 팀은 월별 저장 용량과 청구 금액만 확인합니다. 하지만 Cloud Storage의 비용과 품질은 다음 축이 함께 움직여 결정됩니다.
- 저장 용량: 데이터가 얼마나 오래 남아 있는가?
- 객체 수: 작은 파일이 얼마나 많이 쌓여 있는가?
- 작업 종류: Class A·B 요청이 얼마나 자주 발생하는가?
- 접근 위치: 애플리케이션과 버킷이 서로 다른 리전에 있는가?
- 오류와 재시도: 요청 제한으로 같은 작업을 반복하는가?
- 스토리지 클래스: 실제 접근 패턴과 Standard·Nearline·Coldline·Archive 선택이 맞는가?
예를 들어 Archive는 저장 단가가 낮지만 자주 읽는 데이터에 적합하지 않습니다. 월간 보고서를 Archive에 저장하고 분석 작업이 매일 전체 파일을 읽으면 저장 비용에서 얻은 이점이 검색·작업·검색 데이터 전송 비용으로 상쇄될 수 있습니다.
반대로 Standard 버킷을 무조건 저비용 클래스로 바꾸는 것도 위험합니다. 복구·분석·배치 작업이 많은 데이터라면 검색 지연과 retrieval fee, 애플리케이션 복잡도가 더 커질 수 있습니다. Advisor의 가치는 “싼 클래스가 무엇인가”가 아니라 관측된 사용 패턴과 현재 선택이 맞지 않는 지점을 찾는 것에 있습니다.
3. 30일 기준선은 경보와 어떻게 다른가?
Advisor는 모든 요청을 실시간으로 차단하는 방화벽이나 초 단위 APM이 아닙니다. 과거 활동에서 기준선을 만들고 그 기준선에서 의미 있는 변화가 생겼는지 판단합니다.
특히 저장 용량 증가 발견 사항은 최근 30일의 소비 추세를 기준으로 “평소보다 빠른 증가”를 식별합니다. Coldline·Archive의 Class A/B 작업 증가, 429 오류, 교차 리전 전송도 과거 패턴과 비교해 이상 징후로 표시됩니다.
이 방식의 장점은 계절성이 있는 업무에서 단순 임계값보다 오탐을 줄일 수 있다는 점입니다.
- 월말 정산 기간에 일시적으로 작업량이 늘어나는 팀
- 학기 시작과 함께 교육 데이터가 급증하는 기관
- 주기적인 백업으로 특정 요일에 저장량이 늘어나는 서비스
하지만 기준선 방식은 급작스러운 장애를 대체하지 못합니다. 어제부터 발생한 429 오류를 즉시 차단하거나, 데이터 유출을 실시간으로 판단하는 용도라면 Cloud Monitoring, Cloud Logging, 알림 정책, 보안 도구를 함께 사용해야 합니다.
운영 설계는 다음처럼 나누는 것이 안전합니다.
실시간 경보
├─ Cloud Monitoring / Logging
├─ 요청 오류·지연·가용성 알림
└─ 애플리케이션의 즉시 대응
추세 분석
├─ Storage Intelligence Advisor
├─ 30일 기준선과 비용·성능 발견
└─ 주간·월간 FinOps 의사결정
Advisor는 후자의 시간을 크게 줄여 주지만 전자를 없애지는 않습니다.
4. 네 가지 발견 사항을 읽는 법
4.1 Coldline·Archive의 Class A/B 작업 급증
Coldline과 Archive는 거의 접근하지 않는 데이터를 낮은 저장 비용으로 보관할 때 유리합니다. 그런데 이 클래스에서 Class A·B 작업이 평소보다 많이 발생하면, 데이터의 실제 사용 패턴이 저장 클래스의 가정과 어긋났을 수 있습니다.
가능한 원인은 다음과 같습니다.
- 분석 작업이 보관 데이터를 매일 스캔함
- 작은 객체를 대량으로 열고 닫는 배치가 실행됨
- 백업 검증이나 검색 인덱싱이 반복적으로 전체 데이터를 읽음
- 애플리케이션이 캐시 없이 원본 버킷을 직접 조회함
지속적인 접근이 확인되면 Standard 또는 Nearline이 더 적합할 수 있고, Autoclass로 접근 빈도에 따라 클래스를 조정하는 방법도 검토할 수 있습니다. 다만 Autoclass 전환 자체에 작업 비용이 생길 수 있으므로, Advisor의 권고를 그대로 적용하기보다 실제 접근 기간과 retrieval fee를 함께 계산해야 합니다.
4.2 교차 리전 egress 급증
버킷이 asia-northeast3에 있고 Compute Engine, 분석 작업 또는 다른 서비스가 us-east1에서 반복적으로 데이터를 읽는다면 네트워크 비용과 지연이 함께 커질 수 있습니다.
Advisor는 어느 프로젝트와 버킷에서 교차 리전 전송이 증가했는지 보여주고, 관련 리소스를 같은 리전에 배치하거나 버킷을 이전하는 방안을 안내합니다. 그러나 리전 이동은 데이터 주권, 백업, 장애 복구, 사용자 지연시간을 함께 고려해야 하는 아키텍처 변경입니다.
다음 질문을 먼저 확인해야 합니다.
- 데이터가 어느 국가·리전에 있어야 하는가?
- 애플리케이션 요청의 대부분은 어느 리전에서 발생하는가?
- 복제와 재해 복구를 위해 일부 교차 리전 전송이 의도된 것인가?
- 버킷을 옮길 때 이름, IAM, Pub/Sub 알림, 수명 주기 정책이 유지되는가?
- 이동 기간 중 이중 저장 비용과 변경 동기화는 어떻게 처리하는가?
비용 발견이 곧바로 “같은 리전으로 옮겨라”는 명령은 아닙니다. 네트워크 비용을 데이터 배치 설계의 신호로 사용하라는 의미에 가깝습니다.
4.3 429 요청 제한 오류 급증
Cloud Storage는 서비스 안정성을 위해 버킷과 객체에 대한 요청 속도를 제한합니다. 429가 늘면 애플리케이션의 재시도가 겹쳐 지연이 더 커지고, 같은 파일을 여러 번 읽어 비용까지 늘어날 수 있습니다.
원인과 대응 예시는 다음과 같습니다.
- 지나치게 많은 작은 객체를 한꺼번에 조회 → 객체 묶음·prefix 설계 검토
- 동시성만 높인 배치 → exponential backoff와 jitter 적용
- 한 버킷에 집중되는 트래픽 → 키 분산과 작업 분할 검토
- 잘못된 재시도 정책 → 최대 시도 횟수와 중단 조건 설정
- 지역 배치 불일치 → 데이터와 컴퓨팅 위치를 함께 재검토
429 발견 사항을 해결할 때는 클라이언트의 재시도 코드를 먼저 확인해야 합니다. 서버 측 제한을 올려 달라고 요청하는 것만으로는 폭주 패턴과 비용 문제를 해결할 수 없습니다.
4.4 저장 바이트가 추세보다 빠르게 증가
30일 기준선보다 총 저장 바이트가 빠르게 늘었다면 새 데이터가 정상적으로 생성된 것인지, 삭제·보관 정책이 작동하지 않은 것인지 분리해야 합니다.
Advisor의 버킷·prefix 드릴다운을 사용해 다음을 확인할 수 있습니다.
- 특정 프로젝트나 버킷의 증가 기여도
- 어느 객체 접두사에서 증가가 발생했는지
- 데이터가 새 버전 또는 임시 파일로 쌓였는지
- Object Versioning과 보존 정책이 의도대로 작동하는지
- 삭제된 것으로 생각한 객체가 비정상적으로 남아 있는지
이 발견 사항은 데이터 품질과 비용 거버넌스를 연결합니다. 단순히 저장 클래스만 바꾸기 전에 데이터 수명 주기, 버전, 백업 보존 기간, 법적 보존 의무를 확인해야 합니다.
5. 조직·폴더·프로젝트 범위에서 얻는 것
Storage Intelligence Advisor는 단일 버킷 관리자용 화면에 머물지 않습니다. 조직 또는 폴더 범위에서 발견 사항을 보면 여러 프로젝트의 영향을 묶어 보여주고, 프로젝트 수와 버킷별 원인으로 내려갈 수 있습니다.
이 계층 구조는 중앙 플랫폼 팀과 각 제품 팀의 책임을 나누는 데 유용합니다.
| 범위 | 주로 답하는 질문 | 담당자 |
|---|---|---|
| 조직 | 전체 스토리지 비용과 위험의 방향은 무엇인가? | FinOps·플랫폼·보안 |
| 폴더 | 특정 사업·학과·환경에서 어느 프로젝트가 문제인가? | 조직/사업 운영자 |
| 프로젝트 | 어떤 버킷과 서비스 계정이 변화를 만들었나? | 제품·데이터 팀 |
| 버킷·객체 | 어떤 prefix와 작업 패턴을 바꿔야 하나? | 애플리케이션 담당자 |
다만 중앙 화면이 모든 IAM 권한을 자동으로 주는 것은 아닙니다. Google 문서에는 조회에 Storage Admin 역할 또는 관련 커스텀 권한이 필요하다고 안내되어 있습니다. 조직 단위에서 요약을 봐도 세부 프로젝트에 접근할 권한이 없으면 해당 프로젝트를 자세히 확인할 수 없습니다.
권한 설계는 “비용을 보는 사람”과 “데이터를 읽을 수 있는 사람”을 분리하는 방향으로 구성해야 합니다. 저장 데이터 자체에 대한 접근 권한을 과도하게 넓히지 않고도 메타데이터·활동·발견 사항을 확인할 수 있는 커스텀 역할을 검토하는 것이 좋습니다.
6. 390일의 이력은 장점이지만 만능 감사 로그는 아니다
Advisor는 집계된 버킷 메타데이터와 활동 데이터를 최대 390일 보존해 과거 추세를 볼 수 있습니다. 삭제된 버킷이 과거 집계에 포함될 수도 있어, 현재 리소스 목록과 화면의 추세가 항상 같지는 않습니다.
이 이력은 다음 분석에 유용합니다.
- 이번 학기와 지난해 같은 기간의 저장량 비교
- 특정 서비스 출시 이후 객체 수 변화 확인
- 아카이브 전환 뒤 Class A/B 작업이 줄었는지 검증
- 리전 이전 전후의 교차 리전 egress 비교
- 429 오류가 일회성인지 반복 패턴인지 확인
하지만 집계 데이터는 원본 액세스 로그의 대체물이 아닙니다. 특정 사용자의 모든 객체 읽기 요청, 법적 감사에 필요한 원문 이벤트, 보안 사고의 세부 타임라인은 Cloud Audit Logs와 별도 보존 정책으로 관리해야 합니다.
즉, Advisor는 운영 의사결정을 위한 장기 추세 화면이고, 감사·포렌식은 로그 시스템의 책임입니다.
7. 비용: 30일 시험이 무료 운영을 뜻하지는 않는다
Storage Intelligence에는 Trial과 Standard 같은 구성이 있으며, 가격은 사용 기능과 관리 객체 수에 따라 달라집니다. Google Cloud 가격 문서의 예시는 1000개의 버킷에 각각 1000개 객체가 있고 10개 프로젝트에 걸쳐 Storage Intelligence Standard를 적용하면, 100만 객체 기준 월 2.5달러의 Standard Object Management Fee가 발생하는 방식으로 설명합니다.
이 숫자를 모든 환경의 고정 가격으로 이해하면 안 됩니다. 실제 비용을 계산할 때는 다음을 함께 봐야 합니다.
- 관리 범위에 포함하는 버킷과 객체 수
- Storage Insights 데이터셋과 BigQuery 쿼리 비용
- 버킷 이전·배치 작업의 데이터 처리·전송 비용
- 기존 Cloud Storage 저장·작업·검색·네트워크 요금
- Trial 종료 뒤 Standard로 전환되는 설정
- 조기 해지 수수료와 조직 단위 상속 범위
30일 introductory trial에서는 Storage Intelligence 객체 관리 수수료가 면제되지만, 저장과 쿼리 사용료까지 모두 사라지는 것은 아닙니다. 또한 Trial이 끝난 뒤 Standard로 계속 사용하지 않을지 미리 결정해야 합니다.
권장 절차는 다음과 같습니다.
- 대표 프로젝트와 작은 버킷 범위로 Trial을 활성화합니다.
- Advisor가 발견하는 이상 징후와 실제 로그를 비교합니다.
- 관리 객체 수, 데이터셋 크기, 쿼리 비용을 측정합니다.
- 어떤 팀이 어떤 발견 사항을 처리할지 정합니다.
- Standard 전환 시 예상 비용과 종료 정책을 문서화합니다.
8. 보안 경계와 VPC Service Controls의 한계
Storage Intelligence advisor는 VPC Service Controls를 지원합니다. 서비스 경계 안의 프로젝트에서는 Advisor API를 데이터 외부 반출 위험으로부터 보호하는 데 도움이 됩니다.
하지만 Google 문서에는 중요한 제한이 함께 적혀 있습니다. VPC Service Controls는 폴더와 조직 수준 리소스를 서비스 경계에 추가하는 방식을 지원하지 않으므로, Advisor를 조직·폴더 단위로 활성화해도 VPC Service Controls로 보호되는 범위는 프로젝트 수준입니다. 조직·폴더의 중앙 관리는 IAM으로 통제해야 합니다.
따라서 규제 환경에서는 다음을 따로 검토해야 합니다.
- Advisor API와 Cloud Storage 데이터의 서비스 경계
- 조직·폴더에서 조회 가능한 메타데이터 범위
- Gemini Cloud Assist를 통한 자연어 분석 권한
- Storage Insights 데이터셋이 생성되는 프로젝트와 접근 주체
- 관리자 화면에 노출되는 버킷명·서비스 계정·prefix 정보
- 분석 결과를 외부 티켓·채팅·대시보드로 전송하는 경로
“스토리지를 분석하는 도구”도 메타데이터를 다루는 서비스이므로, 원본 객체를 직접 읽지 않는다고 해서 보안 검토가 필요 없는 것은 아닙니다.
9. Advisor를 운영 루프에 넣는 방법
주간 FinOps 회의
매주 조직·폴더 범위에서 새 발견 사항과 이전 주의 미해결 사항을 확인합니다. 저장 바이트, Class A/B 작업, 교차 리전 전송을 비용 변화와 연결해 봅니다.
제품 팀의 원인 소유
각 발견 사항에 버킷·prefix·서비스 계정 단위의 담당 팀을 붙입니다. 중앙 플랫폼 팀이 모든 스토리지 문제를 직접 해결하려고 하면 데이터 의미와 애플리케이션 맥락을 놓칠 수 있습니다.
조치 전후 검증
스토리지 클래스 변경, 리전 이전, 재시도 정책 변경 뒤에는 같은 지표가 실제로 개선됐는지 확인합니다. 권고를 적용했다는 사실보다 비용·지연·오류가 줄었는지가 중요합니다.
예외를 기록
규제 보존, 재해 복구, 저지연 복제처럼 비용이 늘어도 필요한 설계가 있습니다. 이런 예외는 “미해결 발견”으로 방치하지 말고, 의도된 비용이라는 이유와 재검토 날짜를 남겨야 합니다.
다음과 같은 간단한 상태표를 운영에 사용할 수 있습니다.
| 상태 | 의미 |
|---|---|
| New | 새 발견, 담당자 미지정 |
| Investigating | 로그·트래픽·데이터 수명 확인 중 |
| Accepted risk | 비용 증가가 의도된 예외 |
| Remediating | 변경 작업 진행 중 |
| Verified | 변경 후 지표 개선 확인 |
| Monitoring | 재발 여부 관찰 |
10. 교육과 실무에서 얻는 데이터 엔지니어링 교훈
Storage Intelligence Advisor는 학생에게 “대시보드 읽기”만 가르치는 도구가 아닙니다. 운영 데이터에서 가설을 세우고 조치를 검증하는 데이터 엔지니어링 실습으로 연결할 수 있습니다.
실습 1: 기준선과 임계값 비교
30일 기준선 기반 발견과 고정 임계값 알림을 같은 가상 데이터에 적용해 계절성·오탐·미탐을 비교합니다.
실습 2: 비용과 성능의 Pareto 경계
Standard·Nearline·Coldline·Archive의 저장 비용, 검색 비용, 접근 빈도, 지연을 표로 만들고 업무 요구에 맞는 선택을 토론합니다.
실습 3: prefix와 서비스 계정 드릴다운
전체 버킷의 평균만 보지 않고 prefix와 호출 주체별로 데이터를 분해해 “누가 비용을 만들었는가”를 찾습니다. 이는 데이터 품질과 접근 제어를 함께 배우는 과제가 됩니다.
실습 4: 권고를 자동 실행하지 않는 이유
Advisor의 다음 단계는 설계 의사결정을 보조합니다. 데이터 보존·지역·복구·규정 조건을 확인하지 않고 자동 수정하면 비용을 줄이는 대신 복구 가능성과 규정 준수를 해칠 수 있음을 사례로 검증합니다.
좋은 클라우드 엔지니어는 지표를 읽는 사람을 넘어, 관측된 변화가 정상인지 위험인지 판단하고 조치 후 결과를 다시 측정하는 사람입니다.
11. 도입 체크리스트
- 조직·폴더·프로젝트 중 어느 범위를 관리할지 정했는가?
- 스토리지 비용뿐 아니라 객체 수·작업량·오류·전송량을 함께 보는가?
- 30일 기준선이 즉시 장애 탐지와 다른 목적임을 이해했는가?
- Coldline·Archive 접근 패턴과 retrieval fee를 확인했는가?
- 교차 리전 egress가 의도된 복제인지 비용 누수인지 구분했는가?
- 429 오류와 클라이언트 재시도 정책을 함께 분석하는가?
- 발견 사항마다 제품 팀과 중앙 플랫폼 팀의 담당자를 정했는가?
- Advisor의 드릴다운에 필요한 IAM 권한을 최소 범위로 부여했는가?
- 390일 이력이 감사 로그를 대체하지 않는다는 점을 문서화했는가?
- Trial 종료 후 Standard 비용과 조기 해지 조건을 계산했는가?
- VPC Service Controls가 조직·폴더 범위까지 동일하게 보호하지 않는다는 점을 확인했는가?
- Cloud Monitoring·Logging으로 실시간 경보를 별도 운영하는가?
- 권고 조치 후 비용·지연·오류를 검증하는가?
- 의도된 비용 증가와 미해결 위험을 구분해 기록하는가?
결론
Storage Intelligence Advisor의 GA는 Cloud Storage가 단순한 객체 저장소에서 관측 가능한 운영 자산으로 진화하는 흐름을 보여줍니다. 저장 용량이 얼마나 되는지만 보는 대신, 객체 수·작업 패턴·리전·오류·스토리지 클래스가 실제 업무와 맞는지 한 화면에서 질문할 수 있게 됐습니다.
가치는 네 가지 이상 징후의 숫자 자체보다, 조직·폴더·프로젝트에서 시작해 버킷·prefix·서비스 계정까지 내려가는 분석 경로에 있습니다. 이 경로가 있으면 비용 증가는 막연한 청구서가 아니라 특정 접근 패턴과 애플리케이션 설계의 문제로 바뀝니다.
다만 Advisor는 실시간 보안 관제나 자동 remediation 엔진이 아닙니다. 30일 기준선과 집계 이력은 추세 분석에 적합하고, 즉시 장애와 감사·포렌식은 Cloud Monitoring·Logging·Audit Logs가 담당해야 합니다. Trial도 모든 사용료를 면제하지 않으며, 조직 단위 IAM과 VPC Service Controls의 범위도 따로 확인해야 합니다.
가장 좋은 도입 방식은 권고를 즉시 자동 실행하는 것이 아니라, 발견 → 담당자 지정 → 원인 검증 → 변경 → 지표 재측정의 운영 루프에 Advisor를 넣는 것입니다. 그렇게 할 때 Cloud Storage의 비용 최적화는 단순한 절약이 아니라 데이터 배치, 애플리케이션 성능, 보안과 복구를 함께 개선하는 설계 활동이 됩니다.
참고 자료
- Google Cloud Blog, What’s new with Google Cloud (2026-09-18)
- Google Cloud Documentation, About Storage Intelligence advisor
- Google Cloud Documentation, View Storage Intelligence advisor
- Google Cloud Documentation, Findings reference catalog
- Google Cloud Documentation, Manage cross-region egress
- Google Cloud Documentation, Improve performance by mitigating rate limited request errors
- Google Cloud Storage pricing, Storage Intelligence
기능 범위, 권한, 보존 기간, Trial과 Standard 가격은 변경될 수 있습니다. 실제 조직에 적용하기 전에는 대상 프로젝트의 콘솔 설정과 Google Cloud의 최신 가격·문서를 함께 확인해야 합니다.