글
이미지는 GCP에서 자주 쓰는 스토리지 및 데이터베이스 서비스를 “무엇을 저장하느냐/어떻게 쓰느냐” 기준으로 묶어 놓은 지도입니다. 위에서부터 큰 분류는 다음 6가지입니다.
객체(Object): Cloud Storage
파일(File/NAS): Filestore
관계형 DB(RDBMS): Cloud SQL, Cloud Spanner, AlloyDB
비관계형(NoSQL): Firestore, Cloud Bigtable
데이터 웨어하우스: BigQuery
Redis(인메모리 캐시): Memorystore
아래는 ELI5(초등학생도 이해하게) 방식으로 “각각이 어떤 서랍인지, 언제 쓰는지”를 자세히 풀어 설명합니다.
1) 객체 스토리지: Cloud Storage
ELI5 비유
큰 창고에 상자(파일)를 넣고, 상자에 이름표(키)를 붙여 보관하는 방식입니다.
무엇에 쓰나
사진, 동영상, PDF, 백업 파일처럼 “그냥 파일 덩어리”를 오래 보관
웹서비스 업로드 파일 저장소의 표준 선택지
특징
아주 많이 저장해도 잘 버팀(확장성 매우 좋음)
URL/API로 꺼내 쓰기 쉬움(웹/앱에 적합)
폴더처럼 보이지만 실제로는 “객체(상자)” 단위 저장
예시
이미지/동영상 저장 및 배포
로그/백업 아카이브
2) 파일 스토리지(NAS): Filestore
ELI5 비유
**반 친구들이 동시에 들어가서 쓰는 “공용 폴더(공유 드라이브)”**입니다.
무엇에 쓰나
여러 서버가 같은 폴더를 동시에 읽고/써야 할 때
레거시 앱이 “/mnt/uploads 같은 경로”에 저장해야 할 때
특징
진짜 폴더/파일 개념(NFS) 그대로 사용
“공유 폴더”가 꼭 필요하면 좋음
다만, 대규모 인터넷 배포는 보통 Cloud Storage+CDN이 더 흔함
예시
CMS의 업로드 디렉터리를 여러 웹서버가 공유
내부 파일 서버/공유 볼륨
3) 관계형 DB(RDBMS): Cloud SQL / Cloud Spanner / AlloyDB
관계형 DB는 ELI5로 말하면 **“엑셀 표를 엄청 크게, 규칙을 지키며(정합성) 안전하게 저장하는 창고”**입니다.
(예: 사용자, 주문, 결제 같은 “정확해야 하는 데이터”)
이미지는 관계형을 3개로 나눠 보여줍니다.
3-1) Cloud SQL
ELI5: “일반적인 학교 행정실 컴퓨터(표준 DB)”
MySQL/PostgreSQL 같은 대표 DB를 관리형으로 제공
웹서비스의 기본 DB로 가장 흔한 선택
좋을 때
보통 규모의 웹/앱 서비스
운영 부담 줄이고 빠르게 시작
예시
회원/게시글/주문 데이터
3-2) Cloud Spanner
이미지의 용도: “RDBMS + 확장, HA, HTAP” 성격을 강조합니다.
ELI5: “전국 지점이 동시에 쓰는 초대형 ‘하나의 장부’”
관계형의 정확함을 유지하면서 매우 크게 확장하고
장애에도 매우 강한(HA) 전역/대규모 서비스를 목표로 함
좋을 때
트래픽/데이터가 아주 커서 일반 RDBMS로 버티기 어려운 경우
글로벌 서비스, 높은 가용성/확장성 요구
예시
대규모 사용자/거래 데이터(금융, 대형 플랫폼 등)
3-3) AlloyDB
이미지의 용도: “하이브리드 트랜잭션 및 분석 처리” + 예시로 “머신러닝/생성형 AI” 같은 키워드를 붙여 두었습니다.
ELI5: “PostgreSQL을 더 빠르고 분석에도 유리하게 튜닝한 고성능 버전”
PostgreSQL 호환을 강하게 가져가면서 성능/운영 편의 개선을 목표로 함
좋을 때
PostgreSQL 기반 앱인데 성능을 더 끌어올리고 싶을 때
트랜잭션(업무 처리) + 분석 성격이 같이 있을 때
예시
고성능 서비스 DB, 분석 쿼리가 많은 서비스
4) 비관계형(NoSQL): Firestore / Cloud Bigtable
비관계형은 ELI5로 말하면 **“표(엑셀)보다 더 자유로운 방식으로 저장하는 큰 수납장”**입니다.
대신 “JOIN 같은 복잡한 표 조합”보다는 빠른 조회/확장에 강합니다.
4-1) Firestore
이미지의 용도: “계층, 모바일, 웹” / 예시: “사용자 프로필, 게임 상태”
ELI5: “폴더 안에 또 폴더가 있는 ‘문서 보관함’(문서 DB)”
앱/모바일에서 빠르게 쓰기 좋은 형태(문서/컬렉션 구조)
좋을 때
사용자 프로필, 설정값, 채팅, 게임 상태 등
“데이터 구조가 자주 변하거나 계층 구조”가 자연스러울 때
4-2) Cloud Bigtable
이미지의 용도: “대량 읽기/쓰기 이벤트” / 예시: “애드테크, 금융, IoT”
ELI5: “초대형 타임라인/이벤트 기록장(매우 많은 행을 빠르게)”
엄청난 양의 이벤트/시계열/로그를 빠르게 넣고 읽는 데 강함
좋을 때
IoT 센서 데이터, 클릭 로그, 이벤트 스트림 등
“초대량, 고속 읽기/쓰기”가 핵심일 때
5) 데이터 웨어하우스: BigQuery
이미지의 용도: “엔터프라이즈 데이터웨어하우스” / 예시: “분석, 대시보드”
ELI5: “모든 기록을 모아 ‘통계/분석’하는 거대한 분석실”
운영 DB처럼 ‘실시간 업무 처리’가 아니라
쿼리로 집계하고 분석하고 대시보드 만드는 용도
좋을 때
매출 분석, 사용자 행동 분석, BI 대시보드
여러 시스템 데이터를 모아서 분석(데이터 레이크/웨어하우스)
6) Redis(인메모리): Memorystore
이미지의 용도: “복잡한 Redis 및 Memcached 작업 자동화” / 예시: “가용성, 장애조치, 패치 사용 설정”
ELI5: “책상 위 포스트잇(아주 빠르지만 오래 보관용은 아님)”
디스크가 아니라 메모리에 두니까 엄청 빠름
대신 보통은 “원본 저장소”가 아니라 “캐시/세션/임시 저장” 역할
좋을 때
로그인 세션, 자주 조회하는 값 캐싱
랭킹/카운터/레이트리밋 같은 빠른 처리
한 장 요약: 어떤 걸 고르면 되나?
아래 질문으로 결정하면 실무에서 거의 틀리지 않습니다.
업로드 파일(이미지/동영상/PDF) 저장?
→ Cloud Storage (필요 시 CDN)여러 서버가 ‘같은 폴더’를 공유해야 함?
→ Filestore회원/주문/결제처럼 정확해야 하는 업무 데이터?
→ 관계형 DB보통: Cloud SQL
초대형/글로벌/강한 HA: Spanner
PostgreSQL 고성능/분석성 동반: AlloyDB
모바일/웹에서 문서 형태(프로필/상태)로 빠르게?
→ Firestore이벤트/로그/시계열을 초대량으로 빠르게 넣고 읽기?
→ Bigtable분석/대시보드/통계가 목적?
→ BigQuery속도가 최우선인 임시 저장/캐시?
→ Memorystore (Redis)
원하시면, “웹서비스 업로드 + DB”를 GCP 기준으로 실제로 많이 쓰는 조합(예: Cloud Storage + Cloud SQL + Memorystore + BigQuery)으로 **요청/응답 흐름(업로드, 다운로드, 권한, CDN, signed URL)**까지 한 번에 아키텍처로 정리해 드리겠습니다.
아래는 GCP에서 “웹서비스 업로드 + DB”를 가장 흔하게 구성하는 조합을 기준으로, 업로드/다운로드 요청 흐름, 권한(IAM), CDN, Signed URL까지 한 번에 정리한 아키텍처입니다. (실무에서 그대로 설계 문서로 옮겨도 될 수준으로 구성했습니다.)
1) 권장 아키텍처(표준 조합)
구성 요소
프론트엔드/클라이언트: Web/APP
백엔드 API: Cloud Run 또는 GKE 또는 Compute Engine(어느 것이든 원리는 동일)
오브젝트 스토리지: Cloud Storage (업로드 파일 원본/파생본 저장)
관계형 DB: Cloud SQL (파일 메타데이터/권한/업로드 상태)
캐시/세션: Memorystore (Redis) (세션/토큰/자주 조회 메타 캐시)
분석: BigQuery (다운로드/조회/이벤트 로그 분석)
CDN: Cloud CDN (+ External HTTPS Load Balancer)
보안 URL: Signed URL (업로드/다운로드 모두에 적용 가능)
2) 데이터 설계 원칙(중요)
파일(바이너리)은 Cloud Storage, 메타데이터는 DB
Cloud Storage: 실제 파일(원본/썸네일/변환본)
Cloud SQL: 파일 레코드 (누가, 어떤 파일, 접근권한, 상태, 저장 위치 등)
예시(Cloud SQL 테이블 개념)
file_id(UUID)bucket,object_path(예:uploads/{tenant}/{user}/{file_id})owner_user_id,tenant_idcontent_type,size_bytes,hashvisibility(private/public/shared)status(pending/uploaded/failed)created_at,expires_at(선택)
3) 업로드 흐름(권장: 클라이언트 직업로드 + Signed URL)
대규모 트래픽에서 가장 흔한 패턴입니다. API 서버가 파일 바이트를 받지 않아서 비용/부하가 줄어듭니다.
3-1) 업로드 URL 발급(요청/응답)
(1) Client → API: “업로드할 파일이 있어요”
Request: 파일명, MIME type, 크기, 목적(프로필/게시글 등)
API는 사용자의 인증(세션/JWT)을 확인하고 권한 검사
(2) API → Cloud SQL: 업로드 “예약” 레코드 생성
status = pendingobject_path결정 (충돌 방지 위해 file_id 기반 권장)
(3) API → Client: 업로드용 Signed URL 반환
Signed URL에는 짧은 만료시간(예: 5~15분)
업로드 대상 버킷/오브젝트 경로/허용 메서드(PUT 등)/Content-Type 조건 포함
3-2) 실제 업로드(클라이언트가 Storage로 직접)
(4) Client → Cloud Storage: Signed URL로 업로드(PUT/POST)
클라이언트는 API 서버를 거치지 않고 GCS로 직접 업로드
3-3) 업로드 완료 확정(서버가 “진짜 업로드 됐는지” 확인)
실무에서는 “업로드 완료”를 확정짓는 절차가 필수입니다. (클라이언트가 성공했다고 말만 하는 것 방지)
옵션 A(가장 흔함): Cloud Storage 이벤트 기반
Cloud Storage → Pub/Sub → Cloud Run(또는 Cloud Functions) 트리거
오브젝트 생성 이벤트를 받으면
파일 메타(크기, Content-Type, 해시 등) 검증
바이러스 스캔/이미지 리사이즈 같은 후처리 가능
Cloud SQL의
status = uploaded로 업데이트
옵션 B(간단): Client가 업로드 후 API에 “완료” 호출
API가 GCS
HEAD(메타 조회)로 실제 존재 확인 후 DB 업데이트이벤트 방식보다 단순하지만, 대규모/비동기 처리에는 A가 더 안정적
4) 다운로드/조회 흐름(권장: CDN + Signed URL)
다운로드는 “권한 제어가 필요하냐”에 따라 패턴이 갈립니다.
4-1) 공개 파일(권한 제어 필요 없음)
Cloud Storage 오브젝트를 공개로 두거나
더 흔히는 Public Bucket은 피하고, 아래 “Signed URL” 방식으로 통제하면서 CDN 사용
4-2) 비공개 파일(권한 제어 필요)
(1) Client → API: “file_id 다운로드하고 싶어요”
API가 Cloud SQL에서 파일 소유/공유 권한 확인
필요하면 Redis 캐시로 권한/메타 조회 가속
(2) API → Client: 다운로드용 Signed URL 반환
만료시간 짧게(예: 1~10분)
URL을 받은 클라이언트는 그 링크로 바로 파일을 받음
(3) Client → Cloud CDN/Load Balancer → Cloud Storage
Signed URL로 요청하면,
CDN이 캐시 히트면 CDN에서 응답
캐시 미스면 원본(GCS)에서 가져와 캐시 후 응답
결과적으로 대규모 트래픽도 저렴하게 흡수 가능
5) CDN 구성 포인트(실무 체크)
GCP에서 Cloud CDN은 보통 External HTTPS Load Balancer 뒤에서 동작하며, 오리진은 Cloud Storage(백엔드 버킷)로 연결합니다.
Backend Bucket: Cloud Storage 버킷을 LB의 오리진으로 설정
Cloud CDN 활성화: 캐시 정책(TTL), 캐시 키 정책(Query string 포함 여부 등) 설정
Signed URL과 캐싱:
“Signed URL이 매번 달라서 캐시가 깨지는 문제”가 발생할 수 있음
해결책은 설계 옵션이 몇 가지 있는데, 실무에서는 다음 중 택합니다.
Signed URL을 짧게 쓰되 캐시 키에서 서명 파라미터를 제외(가능한 정책일 때)
애초에 “권한이 필요한 파일은 캐싱 제한”하고, 권한이 필요 없는 파생본(썸네일 등)만 CDN 캐시
앱 설계를 “공개 리소스는 별도 버킷/경로로 분리”하여 CDN 캐시 효율 극대화
(프로젝트 요구사항에 따라 최적 선택이 달라집니다. 다만 “공개/비공개 분리”가 가장 운영이 편합니다.)
6) IAM/권한 모델(핵심 원칙)
원칙 1) 버킷을 기본적으로 Private로 유지
“누구나 읽기” 같은 공개 버킷은 최소화
접근은 서버(서비스 계정) 또는 Signed URL로 통제
원칙 2) API 서버의 서비스 계정에 최소 권한 부여
예시 역할 방향(개념적)
업로드 URL 발급/검증용:
storage.objects.create,storage.objects.get등 최소 권한오브젝트 삭제가 필요하면
storage.objects.delete추가가능하면 버킷/경로 단위로 제한(조직 정책/버킷 정책 설계)
원칙 3) “사용자 권한”은 DB에서 판정
IAM은 “서비스-서비스” 접근 제어에 강함
최종 사용자별 세밀한 권한(소유자/공유/테넌트)은 보통 Cloud SQL에서 판정 후
그 결과로 Signed URL을 발급하는 방식이 가장 흔함
7) Memorystore(Redis)를 어디에 쓰나?
실무에서 Redis는 다음에 많이 사용됩니다.
로그인 세션/토큰 블랙리스트
파일 메타데이터 캐시(예: file_id → object_path, visibility)
권한 캐시(예: user_id + file_id → allow/deny, TTL 짧게)
업로드 상태 추적(대용량 업로드/멀티파트 처리 시)
8) BigQuery로 무엇을 분석하나?
운영 DB(Cloud SQL)를 분석에 쓰면 느려지거나 비용/성능 문제가 생길 수 있습니다. 그래서 이벤트를 따로 모읍니다.
수집 데이터 예시
file_uploaded(파일 업로드 성공/실패, 크기, 타입, 처리시간)file_downloaded(다운로드 수, 사용자/테넌트, 리퍼러, 국가/지역 등)image_transform(썸네일 생성, 트랜스코딩 단계별 소요시간)
파이프라인(대표)
API/서비스 로그 → Cloud Logging → Sink → BigQuery
또는 이벤트 → Pub/Sub → Dataflow → BigQuery
9) 텍스트 아키텍처 다이어그램(한눈에)
[Client(Web/App)]
| (1) 업로드 요청(메타)
v
[API(Cloud Run/GKE/CE)] --(2) write pending--> [Cloud SQL]
| (3) Signed URL 발급
v
[Client] --(4) PUT via Signed URL--> [Cloud Storage]
|
| (5) Object finalize event
v
[Pub/Sub + Worker(Cloud Run/Functions)]
|
+-- validate/resize/scan
+-- update status --> [Cloud SQL]
다운로드:
[Client] --(1) file_id 요청--> [API] --(2) 권한 체크(SQL/Redis)--> [Signed URL]
[Client] --(3) GET--> [Cloud CDN + HTTPS LB] --miss--> [Cloud Storage]
|
+-- hit 시 CDN 응답
(이벤트/로그) -----------------------------------------------> [BigQuery]
10) 운영 관점 베스트 프랙티스(핵심만)
업로드는 직업로드 + 짧은 TTL Signed URL
버킷은 기본 private
“업로드 완료”는 이벤트 기반으로 확정(정합성/보안)
다운로드는 권한 체크 후 Signed URL 발급
트래픽 크면 Cloud CDN을 앞단에 두고 공개 리소스/파생본 위주로 캐시 최적화
분석은 BigQuery로 분리
원하시면, 다음 중 하나를 선택해 더 실전 설계로 내려드리겠습니다(추가 질문 없이도 일반적인 가정으로 작성 가능합니다).
“회원별 비공개 파일 + 공유 링크(만료/비밀번호)”까지 포함
이미지 업로드 후 자동 썸네일 생성(여러 사이즈) 파이프라인
멀티테넌트 SaaS(조직별 버킷/프리픽스 분리, 키 설계, 접근 정책)
이미지는 Google Cloud Storage(클라우드 스토리지)의 **저장 클래스 4종(Standard / Nearline / Coldline / Archive)**을 “언제 꺼내 쓰는 데이터냐” 기준으로 비교한 표입니다. 핵심은 한 문장으로 요약하면 이렇습니다.
자주 꺼내 쓰면(Standard) 보관은 편하고, 거의 안 꺼내 쓰면(Archive) 보관은 싸지만 꺼낼 때(검색/조회) 비용과 제약이 생깁니다.
아래는 ELI5(초등학생도 이해하게) 설명입니다.
1) 4가지 저장소를 “창고”로 비유하면
클라우드 스토리지를 창고라고 생각해보면, 창고에도 4종류가 있습니다.
Standard (스탠다드) = “책상 위 서랍”
자주 쓰는 물건을 넣는 곳
꺼내 쓰기 가장 편함
Nearline (니어라인) = “가끔 여는 수납장”
가끔(예: 한 달에 한두 번) 꺼내는 물건
보관료는 더 싸지만, 꺼낼 때 작은 비용이 붙음
Coldline (콜드라인) = “창고 깊숙한 선반”
거의 안 꺼내는 물건(예: 분기별 1회 수준)
더 싸게 보관하지만, 꺼낼 때 비용이 더 큼
Archive (아카이브) = “장기 보관 창고”
1년에 한 번 꺼낼까 말까 한 물건(보관/백업/재해복구)
보관은 가장 싸게 하되, 꺼낼 때 비용/제약이 가장 큼
2) 표에 있는 항목들을 쉽게 풀면
A. 사용 사례(무슨 데이터에 쓰나)
Standard: “핫 데이터(자주 읽고 쓰는 데이터)”
예: 서비스 이미지, 자주 다운로드되는 파일, 실시간 처리 데이터Nearline: 백업, 롱테일 멀티미디어, 보관은 하지만 자주 접근하지 않는 데이터
Coldline: 읽기/수정이 드물고(표에 “분기당 최대 1회” 느낌), 자주 접근하지 않는 데이터
Archive: 장기 보관, 온라인 백업, 재해 복구용 데이터
B. 최소 저장 기간(“최소 몇 일은 창고에 넣어둬야 함”)
표 기준:
Standard: 없음
Nearline: 30일
Coldline: 90일
Archive: 365일
ELI5로 말하면:
Nearline/Coldline/Archive는 “최저 계약기간”이 있어서 그 전에 지우면 남은 기간에 대한 요금이 발생할 수 있다는 의미입니다(조기 삭제 페널티 개념).
C. 검색 비용(실무에선 보통 “꺼내기/조회(리트리벌) 비용”으로 이해)
표 기준:
Standard: 없음
Nearline: 1GB당 $0.01
Coldline: 1GB당 $0.02
Archive: 1GB당 $0.05
ELI5:
창고 보관료(월세)는 싸게 해주는데, 물건을 꺼낼 때마다 출고 수수료가 붙는 구조입니다.
그래서 “자주 꺼낼 데이터”를 Archive에 넣으면 오히려 비싸질 수 있습니다.
D. 가용성 SLA(“서비스가 얼마나 잘 열려 있냐”)
표에 따르면:
Standard: 멀티/이중 99.95%, 리전 99.90%
Nearline/Coldline/Archive: 멀티/이중 99.90%, 리전 99.00% (표에 표시된 공통 값)
ELI5:
Standard가 “조금 더 항상 잘 열리는” 창고이고, 나머지는 “덜 자주 꺼내는 창고”라 SLA가 약간 낮게 잡혀 있습니다.
E. 내구성(“데이터가 안 없어질 확률”)
표에 **99.999999999%**로 표시(사실상 매우 높음)되어 있고, 이 값은 클래스 전반에 동일하게 제시되어 있습니다.
ELI5:
어느 창고에 넣든 “물건이 없어질 확률”은 매우 낮게 관리됩니다. 차이는 주로 자주 꺼내 쓰는 편의/비용 구조입니다.
3) 어떤 걸 선택해야 하나? (초간단 선택 룰)
매일/수시로 읽는 파일 → Standard
가끔(월 단위) 조회하는 백업/콘텐츠 → Nearline
거의 안 꺼내고 분기 단위로만 확인 → Coldline
장기 보관(1년 이상), 감사/규정/재해복구 목적 → Archive
4) 웹서비스 업로드 파일에 적용하면(실전 감각)
사용자가 자주 보는 프로필 이미지/게시물 이미지: 보통 Standard
“예전 사진/첨부파일”처럼 시간이 지나면 거의 안 보게 되는 것:
수명주기(Lifecycle) 정책으로 Nearline/Coldline/Archive로 자동 이동시키는 패턴이 흔합니다.예: 30일 후 Nearline, 180일 후 Coldline, 365일 후 Archive
원하시면, “우리 서비스가 이미지/첨부/백업 중 뭐가 중심인지”만 기준으로 **Lifecycle 정책 예시(규칙) + 비용이 터지지 않는 설계 주의점(리트리벌 폭증 방지)**까지 한 번에 정리해 드리겠습니다.
아래는 “서비스의 중심이 이미지/첨부/백업 중 무엇이냐”만으로도 바로 적용 가능한 **Cloud Storage Lifecycle 정책 예시(규칙)**와, 실무에서 자주 터지는 리트리벌(조회/출고) 비용 폭증 방지 체크리스트를 한 번에 정리한 것입니다. (GCP 기준, 개념은 AWS S3 Lifecycle과 동일합니다.)
0) 기본 원칙 3가지
자주 내려받는 데이터는 Standard에 남겨라
Nearline/Coldline/Archive는 보관은 싸지만, 꺼낼 때(리트리벌) 비용이 발생합니다.버킷을 목적별로 분리하라
“이미지(자주 조회)”와 “백업(거의 조회 없음)”을 같은 버킷에 섞으면 Lifecycle/권한/캐시 전략이 꼬여 비용이 튑니다.전환(transition)은 ‘시간’이 아니라 ‘접근 패턴’으로 설계하라
기간 기반은 편하지만, 실제 비용은 “얼마나 자주 내려받느냐”가 결정합니다.
1) 이미지 중심 서비스 (예: 게시물 이미지, 프로필, 썸네일)
권장 버킷 분리
bucket-images-hot(Standard): 최근/자주 보는 이미지bucket-images-cold(Nearline/Coldline): 오래된 원본/고해상도, 거의 안 보는 것(선택)
bucket-images-derivatives(Standard): 썸네일/웹용 변환본은 계속 Standard 유지 권장
Lifecycle 정책 예시(현업에서 가장 무난)
원본(고해상도)
0~30일: Standard
31~180일: Nearline
181~365일: Coldline
365일+: Archive(규정/보관 목적이면), 아니면 Coldline 유지
썸네일/웹용(자주 조회)
대부분 Standard 유지 (CDN 캐시 효율 극대화)
비용 폭증 방지 포인트(이미지에서 가장 흔한 함정)
CDN 필수: 다운로드 트래픽이 Storage로 직격하면, 클래스가 내려갈수록 리트리벌 비용이 커집니다.
Cloud CDN(또는 캐시 계층)을 앞에 둬서 “반복 조회”를 CDN이 흡수하게 하십시오.원본과 파생본 분리: 사용자는 보통 썸네일/웹용만 자주 봅니다.
“원본까지 Coldline으로 내려갔다가, 어느 날 원본을 대량 재처리/재다운로드”하면 비용이 급증합니다.일괄 재처리(리사이즈/ML 재학습) 계획이 있다면 원본을 Coldline/Archive로 내리기 전에 고려해야 합니다.
대량 작업은 “리트리벌 비용 + 네트워크 egress”가 동시에 발생할 수 있습니다.
2) 첨부파일 중심 서비스 (예: PDF, 계약서, 업무 문서, 영수증)
첨부파일은 “초기엔 자주 보다가 시간이 지나면 거의 안 보는” 패턴이 많고, **권한 제어(비공개)**가 중요합니다.
권장 버킷 분리
bucket-attachments-private(기본 private)(선택)
bucket-attachments-public(공개 배포용이 정말 필요할 때만)
Lifecycle 정책 예시(업무형 서비스에 흔한 형태)
0~90일: Standard (초기 열람/재다운로드 빈도가 높음)
91~365일: Nearline (가끔 조회)
365일+: Coldline 또는 Archive (규정/감사/보관)
법적 보관이 명확하면 Archive까지 내리는 것이 비용 효율적
“가끔이라도 누군가 뽑아보는” 조직이면 Coldline 유지가 안전
비용 폭증 방지 포인트(첨부에서 터지는 대표 시나리오)
만료 정책/권한 링크: 임직원이 대량으로 과거 문서를 재다운로드하는 이벤트(감사, 분쟁, 세무) 발생 가능
→ Archive로 내려갔으면 그 시점에 리트리벌이 폭증합니다.
→ “감사 시즌/정산 시즌”에 대량 조회가 예상되면 최소한 Coldline에 두거나, 조회 대상만 별도로 Standard로 승격하는 운영 플랜이 필요합니다.**서버에서 주기적으로 ‘존재 확인(HEAD/LIST)’**을 대량 호출하지 않도록 설계
첨부 리스트 화면에서 매번 스토리지 메타를 확인하면 호출이 폭증합니다.
→ 메타데이터는 **DB(Cloud SQL)**에 저장하고, Storage를 매번 조회하지 말 것.Signed URL 발급은 API가 하되, 다운로드는 CDN/스토리지로 직접
앱 서버를 경유하면 서버 비용/대역폭이 증가합니다.
3) 백업 중심 서비스 (예: DB 백업, 로그 아카이브, 재해복구)
백업은 전형적으로 “거의 안 꺼내고, 오래 보관”이 목적입니다. 가장 Lifecycle 효과가 큽니다.
권장 버킷 분리
bucket-backups(전용 버킷)bucket-dr(재해복구용, 리전/멀티리전 정책은 요구사항에 따름)
Lifecycle 정책 예시(가장 흔한 백업 보관 정책)
0~30일: Nearline (최근 백업은 복구 가능성이 상대적으로 높음)
31~90일: Coldline
90일+: Archive
추가로 “세대(버전) 관리”를 같이 둡니다:
일간 7개, 주간 4개, 월간 12개, 연간 7개 등(업계 관행)
비용 폭증 방지 포인트(백업의 함정)
**정기적인 복구 테스트(restore test)**를 “전량”으로 하면 Archive 리트리벌이 터질 수 있습니다.
→ 테스트는 “샘플 복구” 또는 “최근 구간(예: Nearline 구간)” 중심으로 설계.로그/백업을 분석(BigQuery 등)하려고 갑자기 대량 읽기가 발생할 수 있음
→ 분석 목적 데이터는 애초에 BigQuery/데이터 레이크 파이프라인로 분리하거나, 분석 기간 동안만 Standard로 일시 승격하는 운영 필요.최소 저장 기간(30/90/365일) 조기 삭제 페널티 고려
백업 정책에서 “필요 없으면 바로 삭제”를 자동화하면 오히려 비용이 나갈 수 있습니다.
→ 라이프사이클/보존기간을 최소 저장 기간과 정렬하십시오.
4) 리트리벌(조회 비용) 폭증을 막는 설계 체크리스트
아래 중 2~3개만 지켜도 사고 확률이 크게 줄어듭니다.
A. “리스트 화면”에서 Storage를 직접 조회하지 말 것
잘못된 패턴: 화면 로딩마다 GCS LIST/HEAD 호출 다량 발생
올바른 패턴: **파일 메타(크기, 타입, 생성일, 경로, 접근권한)**는 DB에 저장하고, 화면은 DB만 조회
B. CDN/캐시 계층을 반드시 고려할 것(이미지/다운로드 트래픽)
트래픽이 큰 리소스는 CDN으로 반복 요청을 흡수
특히 Coldline/Archive로 내려간 데이터에 대한 빈번한 접근은 금물
C. “배치 작업”이 가장 위험하다
썸네일 재생성, 포맷 마이그레이션, 재암호화, 재인덱싱 같은 작업이
Coldline/Archive 데이터에 걸리면 한 번에 비용이 폭발합니다.해결: 작업 대상만 사전에 Standard로 승격하거나, 작업 주기를 분할/샘플링
D. 버킷/프리픽스(경로) 기반으로 정책을 나눌 것
예:
/images/original/vs/images/thumb/
원본은 내려도, 썸네일은 Standard 유지 같은 방식이 비용 최적에 유리
E. 모니터링/알림
“스토리지 클래스별 GET/LIST/EGRESS 추세”를 지표로 잡고, 급증 시 알림
비용은 보통 “특정 이벤트(감사, 배치, 버그)”에서 튑니다. 조기 감지가 핵심입니다.
5) 바로 가져다 쓰는 Lifecycle 규칙 템플릿(개념)
서비스 성격별로 아래처럼 “단계 전환”만 잡아도 실전 적용이 가능합니다.
이미지(원본): Standard(30d) → Nearline(180d) → Coldline(365d) → Archive(선택)
이미지(썸네일): Standard 유지 (+ CDN)
첨부: Standard(90d) → Nearline(365d) → Coldline/Archive
백업: Nearline(30d) → Coldline(90d) → Archive(365d+)
원하시면, 당신의 서비스가 (1) 이미지 중심 / (2) 첨부 중심 / (3) 백업 중심 중 어디에 가까운지만 기준으로,
버킷/경로 구조(예: prefix 설계)
Lifecycle 규칙 세트(정책 초안)
“대량 조회 이벤트”가 있을 때 운영 플랜(승격/다운그레이드 전략)
까지 한 페이지 설계안 형태로 정리해 드릴 수 있습니다.
아래는 GCP 기준 “웹서비스 업로드 + DB” 환경에서 바로 적용 가능한
① 버킷/경로(prefix) 구조 → ② Lifecycle 규칙 세트 → ③ 대량 조회 이벤트 대응 운영 플랜을
한 페이지 설계안 형태로 정리한 문서입니다.
(실무 설계 문서/아키텍처 설명용으로 그대로 써도 무방한 수준입니다.)
Cloud Storage 설계안 (업로드 파일 중심 서비스)
1. 버킷 / 경로(prefix) 구조 설계
1-1. 설계 원칙
목적별 버킷 분리: 접근 패턴·Lifecycle·권한이 다른 데이터는 섞지 않는다
prefix 단위로 Lifecycle 적용 가능하도록 설계
“자주 조회”와 “보관 목적” 데이터는 반드시 분리
1-2. 권장 버킷 구조 (이미지 + 첨부 + 백업 혼합 서비스 기준)
bucket-app-assets (Standard, CDN 연결)
└── images/
├── thumbs/ # 썸네일 (항상 자주 조회)
│ └── yyyy/mm/dd/...
└── web/ # 웹용 리사이즈
└── yyyy/mm/dd/...
bucket-app-originals (Lifecycle 적용)
└── images/
└── original/ # 고해상도 원본
└── tenant_id/user_id/file_id
└── attachments/
└── private/ # PDF, 문서, 첨부
└── tenant_id/user_id/file_id
bucket-app-backups (전용 백업)
└── db/
└── daily/
└── weekly/
└── monthly/
왜 이렇게 나누는가?
썸네일/웹용 이미지는 CDN 캐시 효율이 매우 중요 → Standard 유지
원본/첨부는 시간이 지나면 조회 빈도가 급감 → Lifecycle 대상
백업은 접근 패턴이 완전히 다름 → 전용 버킷 필수
2. Lifecycle 규칙 세트 (정책 초안)
2-1. bucket-app-assets (썸네일/웹 이미지)
❌ Lifecycle 없음
Storage Class: Standard 고정
Cloud CDN 연결
이유: 조회 트래픽이 많고 리트리벌 비용 리스크가 큼
2-2. bucket-app-originals (원본 이미지 / 첨부 파일)
(A) 원본 이미지 (images/original/)
| 경과 시간 | Storage Class |
|---|---|
| 0 ~ 30일 | Standard |
| 31 ~ 180일 | Nearline |
| 181 ~ 365일 | Coldline |
| 365일 이후 | Archive (선택, 규정/보관 목적일 경우) |
(B) 첨부 파일 (attachments/private/)
| 경과 시간 | Storage Class |
|---|---|
| 0 ~ 90일 | Standard |
| 91 ~ 365일 | Nearline |
| 365일 이후 | Coldline 또는 Archive |
주의
감사/분쟁 등으로 대량 열람 가능성이 있으면 Archive 대신 Coldline 유지
2-3. bucket-app-backups (백업 전용)
| 경과 시간 | Storage Class |
|---|---|
| 0 ~ 30일 | Nearline |
| 31 ~ 90일 | Coldline |
| 91일 이후 | Archive |
추가 규칙:
일간 백업: 7개 유지
주간 백업: 4개 유지
월간 백업: 12개 유지
연간 백업: 5~7개 유지
3. “대량 조회 이벤트” 발생 시 운영 플랜
(비용 폭증 방지 핵심 파트)
3-1. 대량 조회 이벤트 유형
감사/세무/분쟁 대응
대규모 고객 다운로드
배치 재처리(썸네일 재생성, AI 재학습)
서비스 장애 후 복구 점검
3-2. 기본 대응 전략 개요
절대 원칙
👉 Coldline / Archive 데이터를 “그대로” 대량 조회하지 않는다
3-3. 승격(Promotion) 전략 (가장 중요)
(1) 대상 선별
DB(Cloud SQL) 기준으로 조회 대상 파일 목록 확정
전체가 아니라 정확한 prefix 또는 file_id 집합만 선택
(2) 일시적 승격
대상 오브젝트만 Standard로 일시 승격
방법:
Storage Rewrite(copy) API
동일 객체를 Standard 클래스 경로로 복사
승격 기간: 7~30일(이벤트 기간 한정)
(3) 조회/배치 작업 수행
CDN 캐시 활성화
서버/배치가 Standard만 접근하도록 통제
(4) 이벤트 종료 후 재다운그레이드
Lifecycle 또는 수동 정책으로 Nearline/Coldline/Archive 복귀
3-4. 절대 하면 안 되는 패턴
❌ Coldline/Archive 전체 prefix에 대해:
대량 LIST
일괄 다운로드
전체 재처리 배치
→ 리트리벌 + 네트워크 비용 폭발
4. 운영 안전장치(Checklist)
A. 메타데이터 접근 분리
파일 크기/타입/날짜/권한 → Cloud SQL
Storage는 “실제 다운로드할 때만” 접근
B. CDN 전략
썸네일/웹용 이미지는 항상 CDN
Signed URL + CDN 조합 시:
캐시 키 설계 주의
공개 파생본은 별도 prefix 유지
C. 모니터링 필수 지표
Storage Class별 GET 요청 수
Retrieval 비용
갑작스러운 LIST/HEAD 증가
D. 배치 작업 사전 점검
“이 배치가 어느 클래스의 데이터를 읽는가?”
Coldline/Archive 접근 여부 사전 체크
5. 한 줄 요약 (의사결정용)
버킷은 목적별로 분리
자주 보는 데이터는 Standard + CDN
보관용은 Lifecycle로 자동 하향
대량 조회는 항상 ‘일시 승격 후 처리’
Coldline/Archive 직접 대량 조회는 금지
원하시면 다음 단계로:
실제 GCP Lifecycle JSON 정책 예시
Cloud SQL 테이블 설계 + 파일 권한 모델
Signed URL 발급 로직(API 설계)
중 하나를 바로 이어서 정리해 드릴 수 있습니다.
댓글 없음:
댓글 쓰기