GCP를 처음 공부하는 분들이 가장 먼저 느끼는 당혹감 중 하나는 데이터 서비스의 종류가 너무 많다는 것입니다. Cloud Storage, Cloud SQL, Spanner, Firestore, Bigtable, BigQuery, Memorystore… 언뜻 비슷한 일을 하는 것처럼 보이지만 설계 목적이 근본적으로 다릅니다. GCP-ACE 시험에서는 바로 이 선택 기준이 핵심 출제 영역입니다. 암기 목록보다 "이 조건이 보이면 이 서비스"라는 패턴을 익히는 것이 목표입니다.
---
Cloud Storage: 객체 스토리지의 4가지 클래스와 라이프사이클
Cloud Storage는 GCP의 핵심 객체 스토리지 서비스입니다. 이미지, 동영상, 로그 파일, 백업, 파이프라인 원본 데이터 등 비정형 파일을 무제한 저장합니다. 서버 없이 사용하고 용량을 미리 프로비저닝할 필요가 없습니다.
Cloud Storage의 핵심 설계 결정은 스토리지 클래스 선택입니다. 파일에 얼마나 자주 접근하느냐에 따라 단가가 크게 달라집니다.
| 클래스 | 주 사용 목적 | 최소 보관 기간 | 스토리지 단가 | 검색 비용 | |--------|------------|--------------|--------------|----------| | Standard | 자주 접근하는 핫 데이터 | 없음 | 가장 높음 (~$0.020/GB/월) | 없음 | | Nearline | 월 1회 미만 접근 | 30일 | ~$0.010/GB/월 | 있음 | | Coldline | 분기 1회 미만 접근 | 90일 | ~$0.004/GB/월 | 있음 | | Archive | 연 1회 이하, 장기 보존 | 365일 | 최저 (~$0.0012/GB/월) | 가장 높음 |
시험에서는 접근 빈도와 보관 기간 조건이 함께 나옵니다. "7년 장기 보관, 법적 분쟁 시에만 열람"이라는 조건이 보이면 Archive가 정답입니다. "분기마다 한 번 재해 복구 드릴을 수행한다"는 백업이라면 Coldline이 적합합니다. 최소 보관 기간을 어기면 조기 삭제 수수료가 부과됩니다.
라이프사이클 정책을 활용하면 클래스 전환을 자동화할 수 있습니다. "생성 후 30일 경과 시 Nearline, 90일 경과 시 Coldline, 365일 경과 시 Archive로 전환"하는 규칙을 한 번 설정해두면 수동 관리 없이 비용이 최적화됩니다.
---
스토리지 유형 비교: 객체 vs 블록 vs 파일
Cloud Storage가 객체 스토리지라면, GCP에는 블록 스토리지와 파일 스토리지도 있습니다. 이 세 가지는 근본적으로 다른 방식으로 데이터를 저장하며, 사용 목적도 완전히 다릅니다.
| 스토리지 유형 | GCP 서비스 | 접근 단위 | 주요 사용 목적 | |------------|----------|---------|-------------| | 객체 스토리지 | Cloud Storage | HTTP/HTTPS (REST API) | 이미지·동영상·백업·파이프라인 원본 | | 블록 스토리지 | Persistent Disk | 블록 단위 (VM 마운트) | VM 운영 디스크, 데이터베이스 서버 | | 파일 스토리지 | Filestore | NFS (다중 VM 공유 마운트) | 공유 파일 시스템, 레거시 NAS 이전 |
Persistent Disk는 Compute Engine VM에 부착하는 블록 스토리지입니다. Regional Persistent Disk는 동일 리전 내 2개 존에 동기 복제되어, 존 장애 시 데이터 손실 없이 다른 존으로 장애 조치할 수 있습니다. Filestore는 여러 VM이 동시에 NFS로 마운트해서 사용하는 공유 파일 스토리지로, 온프레미스 NAS 워크로드를 이전할 때 선택합니다.
!Object vs Block vs File 스토리지
Cloud SQL: 매니지드 RDB의 위치
Cloud SQL은 MySQL, PostgreSQL, SQL Server를 완전 관리형으로 제공하는 서비스입니다. 엔진 수준의 호환성이 유지되기 때문에 연결 문자열만 바꿔서 온프레미스 데이터베이스를 마이그레이션할 수 있습니다.
| 기능 | Cloud SQL | |------|----------| | 지원 엔진 | MySQL 8.0, PostgreSQL 15, SQL Server 2019 | | 고가용성 | 동일 리전 내 다른 존에 Primary + Standby 자동 구성 | | 자동 장애 조치 | 존 장애 시 약 60초 내 Standby로 자동 전환 | | 읽기 복제본 | 동일·타 리전 복제본 지원, 읽기 부하 분산 | | PITR | 최대 7일 이내 임의 시점 복구 | | 최대 스토리지 | 64TB |
Cloud SQL의 한계는 단일 인스턴스에 묶인다는 점입니다. 읽기 복제본으로 읽기 부하를 분산할 수 있지만, 쓰기는 Primary 인스턴스 한 대에 집중됩니다. 데이터가 수십 TB를 넘거나 쓰기 처리량이 단일 인스턴스 한계를 초과하기 시작하면 Cloud Spanner로의 이전을 검토해야 합니다.
---
Spanner: 글로벌 강일관성이라는 새로운 카테고리
Cloud Spanner는 SQL과 ACID 트랜잭션을 지원하면서 여러 리전에 걸쳐 수평 확장이 가능한 서비스입니다. 이 조합을 동시에 제공하는 서비스는 GCP에서 Spanner가 유일합니다.
| 특성 | Cloud SQL | Cloud Spanner | |------|----------|---------------| | 스케일링 방식 | 단일 인스턴스 수직 확장 | 노드 추가 수평 확장 (샤딩 자동) | | 최대 규모 | ~64TB | 제한 없음 (수 PB 이상) | | 리전 범위 | 단일 리전 | 단일 리전 또는 멀티 리전 | | 가용성 SLA | 99.95% (HA 구성) | 99.999% (멀티 리전) | | 쓰기 확장 | Primary 1대로 제한 | 여러 노드 자동 분산 | | 비용 | 낮음 | 높음 (노드당 과금) |
Spanner의 핵심 기술은 TrueTime입니다. GPS와 원자시계를 사용해 전 세계 분산 노드 간의 시간을 동기화함으로써, 지리적으로 떨어진 리전에서도 외부 일관성(External Consistency)을 보장합니다. Paxos 기반 복제로 멀티 리전 간 데이터를 동기 복제하며, 리더 리전 장애 시 자동으로 새 리더를 선출합니다. RPO=0, RTO 수 초입니다.
시험 패턴: "글로벌", "강한 일관성", "ACID 트랜잭션", "리전 장애 내성", "수평 확장"이 한 문장에 같이 나오면 Cloud Spanner 멀티 리전이 정답입니다.
---
Firestore와 Bigtable: NoSQL의 두 얼굴
GCP의 NoSQL 서비스는 크게 두 가지입니다. Firestore는 문서형 NoSQL이고, Bigtable은 와이드컬럼 NoSQL입니다. 설계 목적이 완전히 다릅니다.
| 특성 | Firestore | Bigtable | |------|----------|----------| | 데이터 모델 | 컬렉션 → 문서 (JSON 유사) | 행 키 + 컬럼 패밀리 (와이드컬럼) | | 처리량 | 서버리스 자동 확장 | 초당 수백만 건, 밀리초 지연 | | 최적 워크로드 | 모바일·웹 앱, 사용자 프로필 | IoT 시계열, 게임, 광고, 분석 | | 오프라인 지원 | 있음 (자동 동기화) | 없음 | | 트랜잭션 | 단일 문서 원자성 | 단일 행 원자성만 | | HBase 호환 | 없음 | 있음 |
Firestore는 실시간 리스너와 오프라인 동기화가 내장되어 있어 모바일 앱 백엔드에 적합합니다. Native mode는 모바일 SDK와 실시간 업데이트를 지원하고, Datastore mode는 구 Cloud Datastore 앱을 마이그레이션할 때 사용합니다.
Cloud Bigtable은 행 키 설계가 성능의 핵심입니다. IoT 시계열 데이터라면 형태로 설계해야 최신 데이터 조회가 빠릅니다. 순방향 타임스탬프를 쓰면 모든 쓰기가 마지막 행에 집중되어 핫스팟이 발생합니다.
---
BigQuery: 분석 워크로드의 표준
BigQuery는 서버리스 데이터 웨어하우스입니다. 클러스터 프로비저닝 없이 수 페타바이트의 데이터에 SQL 쿼리를 바로 실행합니다. 스토리지와 컴퓨팅이 완전히 분리된 아키텍처 덕분에, 저장해두고 쿼리할 때만 비용을 지불하는 온디맨드 모델이 가능합니다.
| 특성 | 내용 | |------|------| | 아키텍처 | 스토리지·컴퓨팅 완전 분리, 서버리스 | | 데이터 형식 | 컬럼 기반 저장 — 집계 쿼리 최적화 | | 과금 모델 | 온디맨드: 스캔 데이터 1TB당 약 $5 / 정액제: 슬롯 예약 | | 처리 규모 | 수 PB 데이터를 초~분 내 쿼리 처리 | | 외부 테이블 | Cloud Storage의 JSON/CSV/Parquet 파일 직접 쿼리 |
BigQuery는 분석(OLAP) 워크로드에 특화되어 있습니다. 수억 건의 레코드를 집계하는 배치 분석이 BigQuery의 영역이고, 초당 수백 건의 소규모 트랜잭션은 Cloud SQL이나 Spanner의 영역입니다. 플래그로 쿼리를 실행하기 전에 스캔 예상 바이트 수를 사전 확인할 수 있어, 대규모 분석 전 비용을 미리 검토하는 실무 패턴으로 자주 사용됩니다.
---
시험에서 자주 헷갈리는 데이터 서비스 선택 시나리오
GCP-ACE 시험에서 데이터 서비스 문제는 키워드 조합으로 정답이 결정됩니다. 아래 패턴을 익혀두면 문제를 읽는 순간 정답 범위가 좁혀집니다.
| 키워드 조합 | 정답 서비스 | 오답 함정 | |-----------|-----------|----------| | 글로벌 + 강한 일관성 + ACID + 리전 장애 내성 | Cloud Spanner 멀티 리전 | Cloud SQL (단일 리전 한계) | | 초당 수백만 건 + 밀리초 지연 + 시계열/IoT | Cloud Bigtable | Cloud Spanner (트랜잭션 집중형) | | 모바일 앱 + 오프라인 동기화 + 실시간 업데이트 | Firestore Native | Bigtable (모바일 SDK 없음) | | 수 PB SQL 분석 + 서버리스 + 집계 쿼리 | BigQuery | Cloud SQL (OLTP용, 규모 한계) | | 온프레미스 MySQL 이전 + 최소 코드 변경 | Cloud SQL | Spanner (비용·복잡도 과잉) | | 비정형 파일 + 7년 보관 + 연 1회 미만 접근 | Cloud Storage Archive | Coldline (최소 보관 90일) | | 분기 1회 백업 조회 + 장기 보관 | Cloud Storage Coldline | Archive (연 1회 미만만 해당) | | 캐시 + 서브밀리초 지연 + Redis 호환 | Memorystore for Redis | Bigtable (영속 스토리지) |
Spanner와 BigQuery 혼동이 흔합니다. Spanner는 트랜잭션 처리(OLTP), BigQuery는 분석 집계(OLAP)입니다. "실시간 트랜잭션"이면 Spanner, "수억 건 집계 분석"이면 BigQuery입니다. Bigtable과 Spanner 혼동도 잦습니다. Bigtable은 글로벌 ACID 트랜잭션을 지원하지 않으므로 "트랜잭션 일관성" 키워드가 명시되면 Spanner를 선택하세요.
Memorystore는 Redis와 Memcached를 완전 관리형으로 제공하는 인메모리 캐시입니다. "세션 캐시", "DB 앞단 캐시", "서브밀리초"가 보이면 Memorystore입니다. 영속 스토리지가 아닌 캐시 레이어라는 점을 기억하세요.
---
정리: 워크로드별 데이터 서비스 의사결정 표
아래 표는 시험에서 빠르게 정답을 찾기 위한 의사결정 기준입니다.
| 서비스 | 데이터 모델 | 확장 방식 | 선택 신호 키워드 | |--------|-----------|----------|---------------| | Cloud Storage | 객체 스토리지 | 무제한 자동 | 이미지·동영상·백업·비정형 파일 | | Persistent Disk | 블록 스토리지 | 수직 (크기 증가) | VM 디스크, 랜덤 I/O | | Filestore | 파일 스토리지 | 수직 | 다중 VM 공유 마운트, NFS | | Cloud SQL | 관계형 (RDB) | 수직 (인스턴스 업그레이드) | MySQL/PostgreSQL 이전, 단일 리전 ACID | | Cloud Spanner | 분산 관계형 | 수평 (노드 추가) | 글로벌 + 강한 일관성 + 수평 쓰기 확장 | | Firestore | 문서형 NoSQL | 서버리스 자동 | 모바일 앱, 오프라인 동기화, 실시간 리스너 | | Bigtable | 와이드컬럼 NoSQL | 수평 (노드 추가) | 초당 수백만 건, 밀리초, IoT 시계열 | | BigQuery | 분석 (DW) | 서버리스 자동 | PB 규모 분석, 집계 쿼리, 서버리스 SQL | | Memorystore | 인메모리 캐시 | 수직 | Redis 호환, 서브밀리초 캐시 |
| Cloud Storage 클래스 | 접근 빈도 | 최소 보관 | 선택 상황 | |---------------------|---------|---------|----------| | Standard | 수시로 | 없음 | 서비스 중인 콘텐츠, CDN 원본 | | Nearline | 월 1회 미만 | 30일 | 월별 보고서, 최근 백업 | | Coldline | 분기 1회 미만 | 90일 | 분기 DR 훈련용 백업 | | Archive | 연 1회 이하 | 365일 | 규제 장기 보관, 법적 증거 보존 |
데이터 서비스 선택은 세 가지 축으로 수렴합니다. 데이터 구조(비정형/관계형/문서형/와이드컬럼), 일관성 요구사항(강한 일관성/최종 일관성), 규모와 확장 방식(단일 인스턴스/글로벌 수평 확장). 이 세 축을 기준으로 서비스를 분류해두면 시험 문제에서 어떤 조건이 주어지더라도 빠르게 정답 범위를 좁힐 수 있습니다.