GCP 데이터베이스 선택 가이드 — Firestore·Cloud SQL·BigQuery 무엇을 쓸까
이 글은 「GCP 기초」 연재의 여섯 번째 글이다. 앞 편에서 파일 둘 곳을 만들었다면 이번에는 데이터 차례다. 그런데 콘솔의 데이터베이스 메뉴를 열면 이름이 열 개 넘게 쏟아진다. 그중 개인 프로젝트에서 실제로 고민하게 되는 건 Firestore, Cloud SQL, BigQuery 세 개다. 셋 다 데이터베이스라고 불리지만 성격도, 요금 매기는 방식도, 무료 한도 유무도 전부 다르다. 이 글을 다 읽으면 내 프로젝트에 무엇이 맞는지를 세 번의 질문으로 정할 수 있다.
같은 이름으로 불리지만 다른 물건이다
Firestore는 문서형 NoSQL이다. JSON 비슷한 문서를 컬렉션에 담고, 문서 하나를 통째로 읽고 쓴다. 테이블도 스키마도 미리 정하지 않고, 앱이 데이터 변경을 실시간으로 받아 볼 수 있다. 모바일·웹 앱의 저장소로 만들어진 물건이다.
Cloud SQL은 우리가 아는 그 관계형 DB다. MySQL·PostgreSQL·SQL Server를 구글이 대신 운영해 준다. 테이블과 스키마가 있고 조인과 트랜잭션이 되며, 기존 SQL 지식이 그대로 통한다. 대신 서버 한 대를 빌리는 구조라는 점이 뒤에서 요금을 가른다.
BigQuery는 데이터베이스라기보다 분석 창고다. 수억 행을 통째로 훑어 집계하는 데 특화돼 있다. SQL로 질의하지만 안에서 하는 일이 완전히 달라서, 한 건을 찾아 꺼내는 작업에는 오히려 느리고 비싸다.
데이터베이스 메뉴. 이 글에서 다루는 셋 외에도 AlloyDB·Spanner·Bigtable·Memorystore가 함께 보인다
어떤 일에 무엇이 맞나
| 하려는 일 | 맞는 것 | 이유 |
| 앱 회원 정보·게시글 저장 | Firestore | 문서 단위 읽기·쓰기, 실시간 반영 |
| 주문·재고처럼 정합성이 중요 | Cloud SQL | 트랜잭션과 조인이 필요 |
| 로그·결제 내역 집계 리포트 | BigQuery | 대량 스캔 집계에 특화 |
| 이미지·동영상 파일 | Cloud Storage | 애초에 DB에 넣을 것이 아니다 |
요금 매기는 잣대가 서로 다르다
Firestore는 요청 건수로 센다. 문서를 읽으면 읽기 1회, 쓰면 쓰기 1회다. 공식 문서 기준 기본 데이터베이스 하나에 대해 하루 읽기 5만 회, 쓰기 2만 회, 삭제 2만 회와 1GiB 저장이 무료다. 여기서 놓치기 쉬운 조건이 둘 있다. 무료 한도는 프로젝트당 기본 데이터베이스 하나에만 적용되고, 결과가 0건인 쿼리도 읽기 1회로 계산된다. 그리고 2025년 8월부터 MongoDB 호환을 제공하는 Enterprise 에디션이 정식 출시됐는데, 이쪽은 요금 체계가 아예 다르니 만들 때 어느 에디션인지 확인해야 한다.
Cloud SQL은 인스턴스가 켜져 있는 시간으로 센다. 접속이 한 건도 없어도 초 단위로 요금이 붙고, 상시 무료 등급이 없다. 세 가지 중 유일하게 "가만히 둬도 돈이 나가는" 쪽이다. 인스턴스를 중지하면 컴퓨팅 요금은 멈추지만 디스크와 IP 요금은 계속된다. 실습으로 하나 만들었다면 지우기 전까지 과금된다고 생각하는 편이 안전하다.
가장 작은 사양은 코어를 공유하는 유형인데, 공식 문서는 이 유형을 개발·테스트용으로 안내하며 SLA 대상에서도 제외한다. 실제 금액은 사양과 리전에 따라 크게 달라지니, 인스턴스 만들기 화면에 표시되는 예상 비용을 그때그때 확인하는 편이 정확하다.
대신 신규 고객에게는 30일짜리 무료 체험 인스턴스가 따로 제공된다. 콘솔의 Cloud SQL 시작 화면에서 엔진과 리전만 고르면 바로 만들 수 있고, 체험 사양이 상당히 넉넉해서 학습용으로는 충분하다. 화면에도 업그레이드하지 않는 한 요금이 청구되지 않는다고 적혀 있다.
다만 두 가지를 기억해 두는 편이 좋다. 첫째, 30일이 지나면 그대로 과금으로 넘어간다. 체험이라고 방치하면 앞 편에서 본 요금 사고의 전형이 된다. 둘째, 체험이 아니라 직접 만들 때는 시작 화면 아래쪽의 샌드박스·개발 프리셋을 참고하면 편하다. 사양을 하나씩 고르는 대신 용도에 맞게 묶어 둔 구성이라, 학습 목적이면 가장 작은 쪽을 고르면 된다.
Cloud SQL 시작 화면. 위쪽은 30일 무료 체험, 아래쪽은 용도별 프리셋이다. 학습용이면 샌드박스가 가장 작다
BigQuery는 쿼리가 읽은 바이트로 센다. 결과가 한 줄이어도 스캔한 양이 많으면 그만큼 청구된다. 공식 문서 기준 월 1TiB의 쿼리 처리량과 10GiB의 저장이 무료이고, 초과분은 온디맨드 기준 1TiB당 6.25달러 수준이다. 그래서 SELECT * 대신 필요한 열만 고르는 것만으로 요금이 크게 줄어든다.
BigQuery 쿼리 편집기. 실행 전에 스캔할 데이터 양이 표시되고, 그 양이 곧 요금이 된다
가장 흔한 오용 세 가지
- BigQuery를 앱 DB로 쓰기. 가장 자주 보는 실수다. BigQuery는 점 조회가 아니라 테이블 스캔으로 동작하도록 설계돼 있고, 갱신 구문도 대량 수정을 전제로 만들어졌다. 사용자 한 명을 찾는 화면에 붙이면 느리고 비싸다.
- Firestore로 집계 리포트 만들기. 문서를 전부 읽어 와서 세는 방식이 되므로 읽기 횟수가 폭증한다. 집계가 목적이면 데이터를 BigQuery로 내보내 거기서 집계하는 게 맞다.
- 실습용 Cloud SQL 방치. 앞 두 개는 성능 문제지만 이건 바로 요금 문제다. 켜 둔 채 잊으면 매달 청구된다.
세 번째는 GCP 요금 폭탄 막는 법 — 예산 알림·할당량·비용 통제에서 다룬 예산 알림으로 대부분 잡힌다. BigQuery를 제대로 쓰는 쪽 예시는 BigQuery 결제 데이터로 월별 AI 비용 리포트 자동화가 전형적이다. 결제 데이터를 흘려 넣고 월별로 집계하는, 딱 창고에 맞는 일이다. Vertex AI 모델별 토큰 사용량과 비용 추적이나 구글 클라우드 API 사용량 실시간 모니터링 방법도 같은 패턴이다.
세 번만 물으면 정해진다
순서가 중요하다. 위에서부터 답이 "예"가 나오는 지점에서 멈추면 된다.
- 쌓아 둔 데이터를 모아서 집계·분석하나? → BigQuery. 로그, 결제 내역, 사용량 기록처럼 계속 쌓이기만 하고 개별 수정은 거의 없는 데이터다.
- 조인과 트랜잭션, 정해진 스키마가 필요한가? → Cloud SQL. 여러 테이블이 서로를 참조하고, 한 작업이 중간에 실패하면 통째로 되돌려야 하는 데이터다.
- 앱이 문서 하나 단위로 읽고 쓰나? → Firestore. 화면 하나가 문서 하나에 대응되고, 스키마가 자주 바뀌는 데이터다.
셋 다 아니라면 그건 데이터가 아니라 파일일 가능성이 높다. 이미지나 영상, 백업 압축 파일은 DB가 아니라 Cloud Storage에 넣는다. 그리고 하나로 다 하려다 셋 다 어중간해지는 경우가 가장 흔하니, 처음에는 주 저장소 하나만 정하고 나중에 필요할 때 추가하는 편이 낫다.
마무리
정리하면 이렇다. Firestore는 건수로, Cloud SQL은 시간으로, BigQuery는 스캔량으로 요금을 매긴다. 무료 한도는 Firestore와 BigQuery에 있고 Cloud SQL에는 없다. 그래서 실습 단계에서 청구서를 0원으로 유지하고 싶다면 선택지가 사실상 둘로 좁혀진다. 무료 등급 전반은 GCP 무료로 어디까지 되나 — 무료 등급과 크레딧 활용법에서 확인할 수 있다.
다음 편에서는 이 데이터를 움직이는 코드를 올린다. 서버를 준비하지 않고 함수 하나만 배포하는 Cloud Functions로 작은 자동화를 만들어 본다.
· · · 연재 순서 · · ·
(이전) Cloud Storage 실전 — 버킷 만들기부터 공개 설정·수명 주기까지
(다음) Cloud Functions로 작은 자동화 만들기
※ 이 글의 금액과 한도는 2026년 8월 기준이며 요금·메뉴 구성은 자주 변경됩니다.
댓글
댓글 쓰기