"이 상황에는 어떤 데이터베이스가 맞는가"는 Cloud Digital Leader에서 가장 자주 나오는 유형 중 하나입니다. 2026년 8월 개정 출제 범위의 도메인 2(약 18%)는 Cloud Storage, Spanner, Cloud SQL, AlloyDB, Bigtable, BigQuery, Firestore 중에서 사용 사례에 맞는 제품을 고르고, 스토리지 클래스와 Autoclass를 비용과 접근 빈도로 구분하고, 기존 데이터베이스를 클라우드로 옮기거나 현대화하는 방법을 설명하라고 요구합니다. 이 가운데 AlloyDB와 Autoclass는 이번 개정에서 새로 이름이 나온 제품입니다.
이 글은 먼저 꼭 알아야 할 용어를 정리하고, 질문 네 개로 저장소를 좁히는 판단 흐름, 제품별 비교, AlloyDB, 스토리지 클래스와 Autoclass, 데이터베이스 마이그레이션, 하이브리드·멀티클라우드용 데이터 제품 순서로 다룹니다. 각 서비스의 기본 설명은 데이터 트랜스포메이션에서, 데이터베이스와 데이터 웨어하우스와 데이터 레이크의 개념 차이는 데이터 기초 개념에서 먼저 다뤘습니다.
---
먼저 알아야 할 용어
음식마다 맞는 그릇이 있듯 데이터마다 맞는 저장소가 있습니다. 국은 대접에, 케이크는 접시에 담는 것처럼, 데이터의 모양과 쓰임새를 알면 저장소가 정해집니다. 출제 범위는 다음 용어를 정의할 수 있는지 묻습니다.
| 용어 | 뜻 | |------|------| | 관계형 데이터베이스 | 표(테이블)와 표 사이의 관계로 데이터를 저장, 구조가 미리 정해져 있고 일관성이 강함 | | 비관계형 데이터베이스(NoSQL) | 문서, 키-값, 넓은 열 같은 유연한 구조로 저장, 대규모 확장에 강함 | | SQL | 관계형 데이터를 조회하고 바꾸는 표준 언어 | | 객체 스토리지 | 파일을 데이터와 메타데이터를 묶은 객체로 저장, 용량 제한 없이 URL로 접근 | | 트랜잭션 | 여러 작업이 모두 성공하거나 모두 취소되어 데이터가 어긋나지 않게 하는 단위 (예: 계좌 이체) | | 수직 확장 vs 수평 확장 | 서버 한 대의 사양을 높임 vs 서버 수를 늘림 |
시험 팁: "계좌 이체처럼 여러 단계가 한 번에 성공하거나 실패해야 한다"는 관계형 데이터베이스의 트랜잭션입니다. "구조가 자주 바뀌는 유연한 데이터를 대규모로"는 NoSQL입니다.
---
어떤 저장소를 고를까: 질문 네 개로 좁히기
선택지가 일곱 개나 되지만, 순서대로 네 가지만 물으면 대부분 하나로 좁혀집니다.
!질문 네 개로 Cloud Storage, BigQuery, 관계형 세 가지, NoSQL 두 가지 중 하나를 고르는 흐름
파일, 이미지, 동영상, 백업 같은 객체인가? 그렇다면 Cloud Storage 대규모 분석과 BI 보고가 목적인가? 그렇다면 BigQuery 관계형 구조와 트랜잭션이 필요한가? 그렇다면 Cloud SQL, AlloyDB, Spanner 중에서 규모와 성능으로 고름 남은 NoSQL이라면 데이터 종류로 고름: 시계열과 IoT 같은 대용량 데이터는 Bigtable, 모바일과 웹 앱의 문서 데이터는 Firestore
---
제품별 비교
| 제품 | 유형 | 맞는 상황 | 문제 속 단서 | |------|------|------|------| | Cloud Storage | 객체 스토리지 | 이미지, 동영상, 백업, 데이터 레이크 | "비정형 파일", "용량 제한 없이", "아카이브" | | Cloud SQL | 관리형 관계형 | MySQL, PostgreSQL, SQL Server 기반의 일반 웹 앱과 업무 시스템 | "기존 MySQL을 그대로", "관리 부담 줄이기" | | AlloyDB | PostgreSQL 호환 고성능 관계형 | 성능이 중요한 업무 시스템, 거래 데이터에 바로 분석 쿼리 | "PostgreSQL 호환", "거래와 분석을 함께", "고성능" | | Spanner | 전 세계 분산 관계형 | 글로벌 금융, 재고, 게임처럼 전 세계에서 강한 일관성이 필요한 서비스 | "전 세계", "수평 확장", "99.999% 가용성" | | Bigtable | 넓은 열 NoSQL | IoT 센서, 시계열, 광고 기술, 대규모 개인화 | "초당 수백만 건", "밀리초 지연", "시계열" | | Firestore | 문서 NoSQL | 모바일과 웹 앱, 실시간 협업, 오프라인 동기화 | "모바일 앱", "실시간 동기화", "서버리스" | | BigQuery | 서버리스 데이터 웨어하우스 | 페타바이트 규모의 SQL 분석과 BI | "대규모 분석", "서버 관리 없이 SQL" |
시험 팁: 관계형이 필요하다는 것까지 알았다면 마지막은 규모와 성능입니다. 보통의 앱은 Cloud SQL, PostgreSQL 호환에 더 높은 성능과 분석까지 원하면 AlloyDB, 전 세계 규모로 수평 확장해야 하면 Spanner입니다.
---
AlloyDB: PostgreSQL을 더 빠르게, 분석까지
AlloyDB for PostgreSQL은 PostgreSQL과 완전히 호환되는 완전 관리형 데이터베이스입니다. 기존 PostgreSQL 도구(psql, pgAdmin)와 코드를 그대로 쓰면서, 성능과 분석 기능을 크게 높인 것이 특징입니다.
거래와 분석을 함께(HTAP): 운영 중인 거래 데이터에 복잡한 분석 쿼리를 실행해도 성능과 가용성에 영향을 덜 줌 열 기반 엔진: 분석에 필요한 데이터를 메모리에 열 형식으로 두어 분석 쿼리를 가속 읽기 풀: 읽기 전용 인스턴스를 붙여 읽기 부하를 나눔 인덱스 어드바이저: 성능을 높일 스키마 개선을 제안 AlloyDB Omni: 다운로드해서 온프레미스, 다른 클라우드, Kubernetes 환경에서 실행하는 버전
| 구분 | Cloud SQL | AlloyDB | Spanner | |------|------|------|------| | 엔진 | MySQL, PostgreSQL, SQL Server | PostgreSQL 호환 | Google의 분산 데이터베이스 | | 확장 방식 | 주로 서버 사양을 높이고 읽기 복제본 추가 | 고성능 기본 인스턴스와 읽기 풀 | 읽기와 쓰기 모두 수평 확장, 여러 리전에 분산 | | 분석 | 별도의 분석 시스템과 함께 사용 | 열 기반 엔진으로 실시간 분석 가속 | 대규모 운영 데이터와 분석 연동 | | 맞는 상황 | 기존 앱을 그대로 옮기는 일반적인 경우 | 성능이 중요한 업무 시스템, 상용 데이터베이스에서 옮겨 오는 경우 | 전 세계에서 하나의 일관된 데이터베이스가 필요한 경우 |
시험 팁: "PostgreSQL과 호환되면서 기존 PostgreSQL보다 빠르고, 거래 데이터를 바로 분석하고 싶다"는 AlloyDB입니다. "규제 때문에 온프레미스에서도 같은 데이터베이스를 써야 한다"는 AlloyDB Omni입니다.
---
Cloud Storage 클래스와 Autoclass
Cloud Storage는 데이터를 얼마나 자주 꺼내 쓰는지에 따라 스토리지 클래스를 고르게 합니다. 자주 입는 옷은 옷장에, 철 지난 옷은 창고에 두는 것과 같습니다. 창고는 보관비가 싸지만 꺼낼 때 수고가 듭니다.
| 클래스 | 최소 보관 기간 | 데이터 조회 요금 | 맞는 접근 빈도 | 예 | |------|------|------|------|------| | Standard | 없음 | 없음 | 자주 접근 | 웹사이트 이미지, 분석 중인 데이터 | | Nearline | 30일 | 있음 | 한 달에 한 번 이하 | 월간 백업 | | Coldline | 90일 | 있음 | 분기에 한 번 이하 | 재해 복구용 사본 | | Archive | 365일 | 있음 | 1년에 한 번 이하 | 법정 보관 기록, 장기 아카이브 |
모든 클래스가 같은 내구성(연간 99.999999999%)을 갖고, 데이터를 꺼낼 때 기다리는 시간도 밀리초 단위로 같습니다. 차이는 보관 비용, 조회 요금, 최소 보관 기간입니다. 최소 보관 기간보다 일찍 지우면 남은 기간만큼 요금이 부과됩니다.
Autoclass: 알아서 옷장을 정리해 주는 기능
Autoclass를 켜면 버킷 안의 객체마다 실제 접근 패턴을 보고 클래스를 자동으로 바꿉니다.
새 객체는 Standard로 시작 한동안 읽지 않은 객체는 점점 더 차가운 클래스로 이동 (기본 최종 클래스는 Nearline, 설정하면 Archive까지) 읽은 객체는 다시 Standard로 돌아옴 데이터 조회 요금과 조기 삭제 요금이 없고, 대신 관리 수수료가 붙음 128KiB보다 작은 객체는 Standard에 그대로 남음
시험 팁: "데이터 접근 패턴을 예측할 수 없고, 관리 부담 없이 저장 비용을 줄이고 싶다"는 Autoclass입니다. "30일이 지나면 Coldline으로 옮긴다"처럼 정해진 규칙으로 바꾸는 것은 객체 수명 주기 관리(Object Lifecycle Management)입니다.
---
데이터베이스를 클라우드로 옮기는 방법
기존 데이터베이스를 클라우드로 옮기는 길은 노력과 효과에 따라 여러 가지입니다. 이삿짐을 그대로 옮길지, 가구를 새로 바꿀지, 집 구조까지 고칠지 고르는 것과 같습니다.
| 방법 | 내용 | 예 | 특징 | |------|------|------|------| | 그대로 옮기기(리호스트) | 데이터베이스를 Compute Engine VM에 그대로 설치 | 기존 데이터베이스 서버를 VM으로 | 가장 빠르지만 패치와 백업 관리는 그대로 | | 같은 엔진의 관리형 서비스로 | 같은 데이터베이스 엔진의 관리형 서비스로 이전 | MySQL → Cloud SQL for MySQL | 패치와 백업을 Google이 맡음 | | 다른 엔진으로 현대화 | 데이터베이스 엔진을 바꿔 이전 | Oracle → Cloud SQL for PostgreSQL 또는 AlloyDB | 라이선스 비용 절감, 스키마와 코드 변환 필요 | | 클라우드 네이티브로 재설계 | 확장이 필요한 부분을 새로운 데이터베이스로 다시 설계 | 글로벌 주문 시스템 → Spanner | 효과가 가장 크지만 노력도 가장 큼 |
Database Migration Service는 Cloud SQL과 AlloyDB for PostgreSQL로의 이전을 돕는 서버리스 서비스입니다. 같은 엔진끼리의 이전(동종)과 Oracle에서 PostgreSQL처럼 엔진이 다른 이전(이종)을 모두 지원합니다. 처음 전체 데이터를 복사한 뒤 바뀐 내용만 계속 복제하다가, 원본과 대상이 같아진 순간 전환하기 때문에 다운타임을 최소화할 수 있습니다. 이종 이전에서는 Gemini가 스키마와 코드 변환을 돕습니다.
시험 팁: "MySQL 데이터베이스를 최소한의 다운타임으로 Cloud SQL로 옮긴다"는 Database Migration Service입니다. "상용 데이터베이스의 라이선스 비용을 없애고 싶다"는 PostgreSQL 기반의 Cloud SQL이나 AlloyDB로 현대화하는 것입니다.
---
하이브리드·멀티클라우드에서 쓰는 데이터 제품
모든 데이터가 Google Cloud에 있을 수는 없습니다. 규제, 기존 투자, 다른 클라우드의 데이터 때문에 여러 환경에 걸쳐 데이터를 다뤄야 하는 경우를 위해 Google Cloud는 다음 제품을 제공합니다.
| 제품 | 하는 일 | |------|------| | AlloyDB Omni | AlloyDB를 온프레미스, 다른 클라우드, Kubernetes 환경에서도 실행 | | Spanner Omni | Spanner를 Google Cloud 밖의 인프라에서 실행하는 다운로드형 버전 | | BigQuery Omni | Amazon S3나 Azure Blob Storage의 데이터를 옮기지 않고 BigQuery로 분석 | | Looker | 여러 클라우드와 데이터베이스에 있는 데이터에 연결해 하나의 BI 환경 제공 |
시험 팁: 이름에 Omni가 붙으면 "Google Cloud 밖에서도"라는 뜻으로 기억하세요.
---
시험 핵심 정리
시험장 가기 전 마지막으로 확인할 핵심 포인트입니다.
| 구분 | 핵심 암기 사항 | |------|------| | 관계형 vs NoSQL | 표와 관계 · 강한 일관성 vs 유연한 구조 · 대규모 확장 | | 객체 스토리지 | 파일을 객체로 저장, Cloud Storage | | 선택 순서 | 객체인가 → 분석인가 → 관계형인가 → NoSQL 종류 | | Cloud SQL | MySQL · PostgreSQL · SQL Server 관리형, 일반 앱 | | AlloyDB | PostgreSQL 호환, 고성능, 거래와 분석을 함께(HTAP) | | Spanner | 전 세계 분산 관계형, 수평 확장, 최대 99.999% 가용성 | | Bigtable | 넓은 열 NoSQL, 시계열 · IoT, 밀리초 지연 | | Firestore | 문서 NoSQL, 모바일 · 웹, 실시간 동기화 | | BigQuery | 서버리스 데이터 웨어하우스, SQL로 대규모 분석 | | 스토리지 클래스 | Standard(없음) · Nearline(30일) · Coldline(90일) · Archive(365일) | | Autoclass | 접근 패턴에 따라 클래스를 자동 변경, 조회 · 조기 삭제 요금 없음 | | 수명 주기 관리 | 정해진 규칙(기간 등)으로 클래스 변경이나 삭제 | | Database Migration Service | Cloud SQL · AlloyDB로 이전, 동종 · 이종, 최소 다운타임 | | Omni | Google Cloud 밖에서도 (AlloyDB Omni, Spanner Omni, BigQuery Omni) |
---
다음 단계
데이터를 어디에 둘지 정했다면, 이제 쉬지 않고 흘러 들어오는 데이터를 실시간으로 다루는 방법을 볼 차례입니다. Pub/Sub, Dataflow, Managed Service for Apache Spark와 Looker는 실시간 분석과 Looker에서 이어집니다. 비슷한 서비스를 한 번에 비교하고 싶다면 헷갈리는 서비스 비교 총정리도 참고하세요.
데이터베이스 문제는 "무엇을 저장하나, 관계형인가, 얼마나 크게 확장하나, 얼마나 자주 꺼내나" 네 질문으로 대부분 풀립니다. CDL 모의고사에서 데이터베이스 선택 문제를 풀며 확인해 보세요.