2026. 6. 7. 07:03ㆍCloud/GCP
"서비스 로그를 Cloud Storage에 쌓고 있는데, 월 저장 비용이 계속 증가합니다. 최근 7일치만 자주 조회하고 나머지는 거의 보지 않는데, 전부 Standard로 저장 중입니다." — 이 상황에서 Storage Class를 분리하면 저장 비용을 50~90%까지 줄일 수 있습니다.
핵심 요약
- GCP Cloud Storage는 4가지 Storage Class를 제공합니다: Standard, Nearline, Coldline, Archive.
- 4가지 클래스 모두 같은 API, 같은 버킷 구조, 같은 내구성(eleven 9s, 99.999999999%)을 제공합니다. 차이는 비용 구조뿐입니다.
- 저장 비용은 Standard가 가장 비싸고 Archive가 가장 저렴합니다. 검색 비용은 반대입니다.
- 선택 기준은 데이터 접근 빈도입니다. 자주 읽으면 Standard, 거의 안 읽으면 Archive.
- Object Lifecycle Management로 시간이 지나면 자동으로 저렴한 클래스로 전환할 수 있습니다.
- 접근 패턴을 예측하기 어려우면 Autoclass를 활성화하여 자동 최적화를 맡길 수 있습니다.
1. Cloud Storage 기본 구조
GCP Cloud Storage는 객체 스토리지(Object Storage) 서비스입니다. 파일(객체)을 버킷(bucket)에 저장하며, 각 버킷에 기본 Storage Class를 설정합니다.
핵심 특성:
- 버킷 단위 기본 클래스: 버킷 생성 시 기본 Storage Class를 지정합니다. 이후 업로드되는 객체는 별도 지정이 없으면 이 클래스를 따릅니다.
- 객체 단위 클래스 설정 가능: 같은 버킷 안에서도 객체마다 다른 Storage Class를 지정할 수 있습니다.
- 동일 API: 어떤 클래스를 사용하든
gsutil, Cloud Console, REST API 사용법은 동일합니다. 클래스 변경을 위해 코드를 수정할 필요가 없습니다. - 동일 내구성: 4가지 클래스 모두 연간 99.999999999% 내구성을 보장합니다. 데이터 손실 위험은 클래스와 무관합니다.
AWS S3와의 차이점: AWS S3의 Glacier 클래스는 복원 시 수 시간이 걸리는 반면, GCP의 Coldline과 Archive는 일반 객체와 동일하게 밀리초 단위로 읽을 수 있습니다. 접근 시 추가 비용이 발생할 뿐, 접근 지연은 없습니다.
2. Storage Class 4가지 비교
2.1 비용 구조
아래 표는 단일 리전(us-central1) 기준 요금입니다.
| 항목 | Standard | Nearline | Coldline | Archive |
|---|---|---|---|---|
| 저장 비용 (GB/월) | $0.020 | $0.010 | $0.004 | $0.0012 |
| 검색 비용 (GB당) | $0 | $0.01 | $0.02 | $0.05 |
| 최소 보관 기간 | 없음 | 30일 | 90일 | 365일 |
| Class A 오퍼레이션 (1,000건) | $0.005 | $0.01 | $0.02 | $0.05 |
| Class B 오퍼레이션 (1,000건) | $0.0004 | $0.001 | $0.01 | $0.05 |
| 가용성 SLA (단일 리전) | 99.99% | 99.9% | 99.9% | 99.9% |
| 가용성 SLA (멀티/듀얼 리전) | 99.95% | 99.95% | 99.95% | 99.95% |
비용 구조의 핵심 원리: 저장 비용과 검색 비용은 반비례합니다. Standard는 저장이 비싸지만 읽기가 무료이고, Archive는 저장이 매우 저렴하지만 읽을 때마다 GB당 $0.05를 지불합니다.
2.2 최소 보관 기간(Minimum Storage Duration)
최소 보관 기간 이전에 객체를 삭제하거나 덮어쓰면 조기 삭제 비용(Early Deletion Fee)이 발생합니다.
예를 들어, Coldline에 저장한 파일을 10일 만에 삭제하면 나머지 80일치(90일 - 10일) 저장 비용을 추가로 청구합니다.
다만 Object Lifecycle Management가 클래스를 변경하는 경우에는 조기 삭제 비용이 면제됩니다. Autoclass가 활성화된 버킷에서도 면제됩니다. 이 점이 수동 변경 대비 Lifecycle 규칙의 비용 이점입니다.
2.3 접근 빈도별 권장 클래스
| Storage Class | 접근 빈도 | 대표 사용 사례 |
|---|---|---|
| Standard | 일 단위 이상 | 활성 서비스 데이터, 웹 자산, CDN 오리진 |
| Nearline | 월 1회 미만 | 월간 백업, BI 분석 원본 데이터 |
| Coldline | 분기 1회 미만 | 분기별 리포트, DR(재해복구) 백업 |
| Archive | 연 1회 미만 | 법적 보관 의무 데이터, 장기 감사 로그 |
3. 실무 시나리오: 언제 어떤 클래스를 선택하는가
시나리오 1: 웹 애플리케이션의 정적 자산
사용자가 업로드한 이미지, CSS, JavaScript 파일을 Cloud Storage에서 서빙하는 경우입니다.
- 접근 패턴: 매일 수천~수만 회 읽기
- 선택: Standard
- 이유: 검색 비용이 $0이므로 읽기 빈도가 높을수록 유리합니다. Cloud CDN과 연동하면 CDN이 캐시한 후에는 오리진 접근 자체가 줄어 오퍼레이션 비용도 절감됩니다.
시나리오 2: 애플리케이션 로그 저장
컨테이너나 VM에서 발생하는 로그를 Cloud Storage에 일별로 적재하는 경우입니다.
- 접근 패턴: 최근 7일은 자주 조회, 이후 월 1~2회 장애 분석 시에만 접근
- 선택: Standard + Lifecycle 규칙으로 30일 후 Nearline, 90일 후 Coldline 전환
- 이유: 최근 데이터는 빠른 접근이 필요하고, 시간이 지나면 접근 빈도가 급격히 줄어듭니다. Lifecycle 규칙으로 전환하면 조기 삭제 비용이 면제되므로 수동 전환보다 유리합니다.
비용 비교 (10TB 기준, 월간): - 전체 Standard: $200/월 - Lifecycle 적용 (Standard 30% + Nearline 30% + Coldline 40%): $200 × 0.3 + $100 × 0.3 + $40 × 0.4 = $60 + $30 + $16 = $106/월 (47% 절감)
시나리오 3: 데이터베이스 백업
Cloud SQL이나 BigQuery의 주간/월간 백업을 장기 보관하는 경우입니다.
- 접근 패턴: 저장 후 거의 접근 없음. DR 발생 시에만 복원
- 선택: Coldline 또는 Archive
- 이유: 법적 보관 의무가 1년 이상이면 Archive($0.0012/GB/월)가 적합합니다. 복원 시 검색 비용($0.05/GB)이 발생하지만, 저장 비용 절감이 압도적입니다. 10TB를 1년간 보관하면 Standard 대비 $2,100 이상 절감됩니다.
Archive 선택 시 주의점: 365일 최소 보관 기간이 있으므로, 보관 기간이 1년 미만인 데이터에는 Coldline이 더 경제적일 수 있습니다.
시나리오 4: 접근 패턴을 예측하기 어려운 경우
신규 서비스를 런칭했거나 데이터 접근 패턴이 불규칙한 경우입니다.
- 선택: Autoclass 활성화
- 이유: Autoclass는 객체별 접근 패턴을 모니터링해서 자동으로 Storage Class를 전환합니다. 30일간 접근이 없으면 Nearline로, 이후에도 없으면 Coldline → Archive 순으로 내려갑니다. 다시 접근이 발생하면 Standard로 올려줍니다.
- trade-off: Autoclass는 관리 수수료($0.0025/1,000 객체/30일)가 있고, 검색 비용이 면제되는 대신 일부 전환에 Class A 오퍼레이션 비용이 발생합니다. 대량의 소형 객체가 많은 경우 오퍼레이션 비용이 무시할 수 없으므로 사전 테스트가 필요합니다.
4. Object Lifecycle Management
Lifecycle 규칙은 조건(Condition)과 액션(Action)으로 구성됩니다. 조건을 만족하는 객체에 자동으로 액션을 실행합니다.
4.1 주요 조건
| 조건 | 설명 |
|---|---|
age |
객체 생성 후 경과 일수 |
createdBefore |
지정 날짜 이전에 생성된 객체 |
matchesStorageClass |
특정 Storage Class에 해당하는 객체 |
numNewerVersions |
현재보다 새로운 버전이 N개 이상인 객체 (버전 관리 시) |
isLive |
현재 버전(true) 또는 이전 버전(false) |
4.2 주요 액션
| 액션 | 설명 |
|---|---|
SetStorageClass |
지정한 Storage Class로 전환 |
Delete |
객체 삭제 |
AbortIncompleteMultipartUpload |
미완료 멀티파트 업로드 정리 |
4.3 실무 Lifecycle 규칙 예시
{
"lifecycle": {
"rule": [
{
"action": {"type": "SetStorageClass", "storageClass": "NEARLINE"},
"condition": {"age": 30, "matchesStorageClass": ["STANDARD"]}
},
{
"action": {"type": "SetStorageClass", "storageClass": "COLDLINE"},
"condition": {"age": 90, "matchesStorageClass": ["NEARLINE"]}
},
{
"action": {"type": "SetStorageClass", "storageClass": "ARCHIVE"},
"condition": {"age": 365, "matchesStorageClass": ["COLDLINE"]}
},
{
"action": {"type": "Delete"},
"condition": {"age": 730}
}
]
}
}
이 규칙은 다음과 같이 동작합니다: 1. 30일 경과 → Standard에서 Nearline으로 전환 2. 90일 경과 → Nearline에서 Coldline으로 전환 3. 365일 경과 → Coldline에서 Archive로 전환 4. 730일(2년) 경과 → 삭제
Lifecycle 전환 시 조기 삭제 비용이 면제되므로, 수동으로 gsutil rewrite를 실행하는 것보다 Lifecycle 규칙을 설정하는 것이 비용 면에서 유리합니다.
4.4 Lifecycle 설계 시 주의점
- 전환 방향 제한: Lifecycle은 Standard → Nearline → Coldline → Archive 방향으로만 전환 가능합니다. 역방향 전환은 지원하지 않습니다. 역방향이 필요하면 Autoclass를 사용합니다.
- 소형 객체 주의: Storage Class 전환은 객체당 Class A 오퍼레이션 비용이 발생합니다. 1KB 미만의 객체가 수억 개 있다면 전환 오퍼레이션 비용이 저장 비용 절감을 초과할 수 있습니다.
- 버전 관리 객체: 버전 관리가 활성화된 버킷에서는
numNewerVersions조건으로 이전 버전을 별도로 관리할 수 있습니다.
5. Autoclass vs Lifecycle: 어떤 것을 선택할까
| 비교 항목 | Lifecycle | Autoclass |
|---|---|---|
| 전환 방향 | 하향(Standard→Archive)만 가능 | 상향(Archive→Standard)도 가능 |
| 전환 기준 | 시간(age) 기반 규칙 | 실제 접근 패턴 기반 |
| 조기 삭제 비용 | 면제 | 면제 |
| 검색 비용 | 적용됨 | 면제 |
| 관리 수수료 | 없음 | $0.0025/1,000 객체/30일 |
| 적합한 상황 | 접근 패턴 예측 가능 시 | 접근 패턴 불규칙 시 |
설계 관점에서의 판단 기준:
- 데이터의 접근 패턴이 명확하고 시간에 따라 규칙적으로 감소한다면 Lifecycle이 단순하고 비용 예측이 쉽습니다.
- 접근 패턴이 불규칙하거나, 오래된 데이터가 갑자기 다시 필요해지는 경우가 있다면 Autoclass가 적합합니다.
- 두 기능을 동시에 사용할 수도 있습니다. Autoclass가 활성화된 버킷에서도 Lifecycle의 Delete 액션은 동작합니다.
6. 비용 최적화 실전 팁
6.1 멀티/듀얼 리전 vs 단일 리전
| 구성 | 저장 비용 (Standard 기준) | 특성 |
|---|---|---|
| 단일 리전 (us-central1) | $0.020/GB/월 | 가장 저렴, 단일 리전 장애 시 접근 불가 |
| 듀얼 리전 | $0.022/GB/월 | 두 리전 간 자동 복제, 리전 장애 복원력 |
| 멀티 리전 (US) | $0.026/GB/월 | 지리적 분산, 글로벌 접근 최적화 |
판단 기준: DR 요구사항이 없고 단일 리전 내 서비스만 접근한다면 단일 리전이 가장 경제적입니다. 크로스 리전 접근이 잦거나 리전 장애 복원이 필요하면 듀얼/멀티 리전을 선택합니다.
6.2 비용 함정 체크리스트
| 함정 | 설명 | 대응 |
|---|---|---|
| 조기 삭제 비용 | 최소 보관 기간 전 삭제 시 잔여 기간 비용 청구 | Lifecycle으로 전환 (면제됨) |
| 오퍼레이션 비용 폭발 | Archive에 LIST 요청 반복 시 $0.05/1,000건 | 메타데이터는 별도 DB로 관리 |
| 검색 비용 간과 | Archive 10TB 복원 시 검색 비용만 $500 | DR 복원 비용을 사전에 예산 책정 |
| 소형 객체 전환 | 1KB 객체 100만 개 전환 시 저장 절감 < 오퍼레이션 비용 | 소형 객체는 Standard 유지 또는 병합 후 전환 |
6.3 gsutil 명령어 참고
# 버킷 생성 시 Storage Class 지정
gsutil mb -c nearline -l us-central1 gs://my-backup-bucket
# 객체의 현재 Storage Class 확인
gsutil stat gs://my-bucket/data.csv
# 버킷의 Lifecycle 규칙 확인
gsutil lifecycle get gs://my-bucket
# Lifecycle 규칙 설정
gsutil lifecycle set lifecycle.json gs://my-bucket
# Autoclass 활성화 (gcloud)
gcloud storage buckets update gs://my-bucket --enable-autoclass
7. AWS S3, Azure Blob Storage와의 비교
| 비교 항목 | GCP Cloud Storage | AWS S3 | Azure Blob Storage |
|---|---|---|---|
| 저빈도 접근 | Nearline, Coldline | S3 IA, S3 Glacier Instant | Cool, Cold |
| 아카이브 | Archive | Glacier Flexible, Glacier Deep | Archive |
| 접근 지연 | 모든 클래스 밀리초 | Glacier: 분~시간 복원 필요 | Archive: 시간 단위 리하이드레이션 |
| 자동 티어링 | Autoclass | S3 Intelligent-Tiering | Access Tier 자동 변경 (Policy) |
| Lifecycle 조기 삭제 면제 | Lifecycle/Autoclass 전환 시 면제 | Lifecycle 전환 시 면제 | 정책에 따라 다름 |
GCP의 차별점: 아카이브 클래스에서도 밀리초 단위 접근이 가능하다는 점은 DR 시나리오에서 복원 시간을 크게 단축합니다. AWS Glacier는 복원 요청 후 수 분~수 시간을 기다려야 하는 반면, GCP Archive는 요청 즉시 데이터를 받을 수 있습니다(비용만 추가).
8. 설계 의사결정 요약
Storage Class 선택은 다음 세 가지 질문으로 결정됩니다:
- 데이터를 얼마나 자주 읽는가? → 접근 빈도로 기본 클래스 결정
- 접근 패턴이 시간에 따라 변하는가? → 변한다면 Lifecycle 또는 Autoclass 적용
- 예기치 않은 접근이 발생할 수 있는가? → 가능하면 Autoclass, 불가능하면 Lifecycle
비용 최적화의 핵심은 "저장 비용 절감 vs 검색 비용 증가"의 균형점을 찾는 것입니다. 데이터 규모가 클수록 저장 비용 절감 효과가 크고, 접근 빈도가 높을수록 검색 비용 부담이 커집니다. 자신의 워크로드에 맞는 균형점을 Cloud Monitoring의 Storage 메트릭으로 측정하고 조정하는 것을 권장합니다.
'Cloud > GCP' 카테고리의 다른 글
| GCP GKE 기본 구조: Autopilot vs Standard, Node Pool, Networking (0) | 2026.06.08 |
|---|---|
| GCP Cloud Run vs Cloud Functions 차이: 서버리스 컴퓨팅 선택 기준 (0) | 2026.06.06 |
| GCP Cloud Load Balancing 기본 구조 정리: 종류, 구성 요소, 동작 원리 (0) | 2026.05.30 |
| GCP IAM 기본 개념: Role, Principal, Policy 이해하기 (0) | 2026.05.30 |
| GCP VPC란 무엇인가: Subnet, Firewall Rule, Route 개념 정리 (0) | 2026.05.30 |