BigQuery vs Redshift — 팀에서 안 싸우고 고르는 기준 (HTML)

 

BigQuery vs Redshift는 ‘성능 비교’로 시작하면 10분 만에 싸움 난다.

대부분 팀이 진짜로 힘들어하는 건 성능이 아니라 운영 방식과 비용 방식이다.

그래서 이 글은 초보자 기준으로 ‘데이터 웨어하우스가 뭔지’부터 짚고, 선택 기준을 팀 질문으로 바꿔서 정리한다.

 

1. 데이터 웨어하우스가 뭐냐

데이터 웨어하우스(Data Warehouse)는 한마디로 회사 데이터가 모이는 큰 창고다.

서비스 로그, 결제, 회원, 마케팅, 앱 이벤트 같은 데이터가 여기로 모이고, 이 데이터를 SQL로 조회해서 리포트를 만들거나 분석한다.

비유하면 이런 느낌이다.

- 운영 DB(MySQL/Postgres): 계산대. 결제/주문 같은 실시간 처리에 최적화.

- 데이터 웨어하우스(BigQuery/Redshift): 창고. 분석/집계를 한 번에 크게 돌리는 데 최적화.

포인트: 운영 DB로 “지난 1년간 유입→구매 전환율” 같은 쿼리를 세게 돌리면 서비스가 느려질 수 있다. 그래서 분석은 웨어하우스로 분리하는 게 흔하다.

 

2. 한 줄 결론

- BigQuery는 서버리스 + 쿼리 단위 비용 모델에 맞는 조직이면 편해진다.

- Redshift는 고정 리소스/워크로드 관리를 할 준비가 된 팀이면 강하다.

 

3. 왜 이 비교가 의미 있나

웨어하우스 선택은 한 번 하면 오래 간다. 마이그레이션이 생각보다 귀찮기 때문이다.

그래서 선택 기준은 결국 아래 3개로 수렴한다.

(1) 비용을 예측하고 싶은가, (2) 운영을 예측하고 싶은가, (3) 튜닝을 누가 책임질 건가.

 

4. 용어 정리(처음 보는 사람용)

쿼리(Query): SQL로 던지는 질문이다. 예: ‘지난주 일별 매출 알려줘’.

워크로드(Workload): 동시에 돌아가는 쿼리/ETL/리포트/배치 작업 묶음이다.

ETL/ELT: 데이터를 옮기고, 정리하고, 형태를 맞추는 파이프라인이다.

서버리스(Serverless): 인프라(서버/클러스터)를 직접 운영하지 않는 방식이다. 편한 대신 비용/제한이 플랫폼 규칙을 따른다.

 

5. 핵심 비교표

항목	BigQuery	Redshift
운영 방식	대부분 서버리스 감각. “클러스터 운영” 부담이 적다	클러스터/리소스 관리가 핵심이다
비용 모델	쿼리/스캔 기반. 많이 돌리면 많이 나온다	리소스 기반. 놀려도 기본 비용이 나간다
성능/튜닝 포인트	파티셔닝/클러스터링, 쿼리 패턴	분산키/정렬키, WLM/동시성
팀에 필요한 역량	사용 규칙/거버넌스(누가 무엇을 얼마나 돌릴지)	운영/튜닝(성능, 자원, 장애 대응)

 

6. 선택 기준을 질문으로 바꿔보기

6.1. 우리 팀은 “운영”을 누가 할 건가

Redshift는 잘 굴리면 안정적이다. 근데 잘 굴리는 사람이 필요하다.

리소스/동시성/WLM, 유지보수(vacuum 등), 장애/성능 대응까지 잡을 사람이 없으면 운영 공백이 생긴다.

 

6.2. 쿼리가 폭증했을 때, 비용을 통제할 장치가 있나

BigQuery는 쿼리가 늘어나기 쉬운 대신, 통제가 없으면 비용도 같이 뛴다.

ad-hoc 분석이 많고 실험이 잦은 팀이면, ‘누가 무엇을 얼마나 돌릴 수 있나’ 같은 가드레일이 필요하다.

 

7. 팀 회의용 체크리스트

아래에서 ‘예’가 많은 쪽이 현실적으로 덜 힘들다.

BigQuery가 유리한 팀: 인프라 운영 인력이 부족하다 / ad-hoc 쿼리가 많다 / 실험이 잦다 / 쿼리·권한 정책을 문서로 만들 수 있다.

Redshift가 유리한 팀: 예측 가능한 월 비용이 중요하다 / 워크로드가 정형화돼 있다 / 튜닝 담당자가 있다 / 특정 시간대 쿼리 몰림을 제어할 수 있다.

 

8. 마무리

둘 중 하나가 항상 정답인 케이스는 없다.

제일 좋은 방법은 실제 워크로드를 작은 샘플로 재현해서, 동시성/비용/운영 부담을 숫자로 비교해보는 거다.

 

참고: BigQuery vs Redshift: Cloud Data Warehouse 선택을 위한 비교