ClickHouse vs Athena SQL vs BigQuery SQL: 진짜 실무 선택 가이드

데이터 팀이나 로그저장할때 가장 자주 나오는 질문 중 하나:

“우리 분석 엔진 뭐 써야 해?”

그리고 가장 자주 나오는 답:

“그건 케바케…”

맞는 말이긴 한데, 너무 무책임하다.
이 글에서는 케바케를 줄이기 위해 선택 기준을 구조화해서 정리한다.

핵심은 간단하다.

• ClickHouse: 빠른 실시간 분석에 강함
• Athena: S3 데이터 레이크 조회에 편함
• BigQuery: 대규모 협업 분석에 강함

하지만 이 한 줄로 결정하면 100% 후회한다.
왜냐면 진짜 승부는 SQL 문법이 아니라 운영 모델 + 비용 모델 + 팀 역량에서 갈리기 때문이다.

---

1) 먼저 비유로 잡고 가자

ClickHouse = 고성능 스포츠카

• 튜닝 잘하면 미친 듯이 빠름
• 대신 세팅/정비를 잘 알아야 함

Athena = 렌터카

• 당장 쓰기 편함
• S3에 데이터만 있으면 바로 달릴 수 있음
• 단, 운전 습관(파일 설계/쿼리 습관) 나쁘면 기름값(비용) 폭발

BigQuery = 고속철도

• 대규모 승객(데이터/사용자) 처리에 강함
• 노선(스키마/파이프라인) 잘 깔면 운영이 안정적
• 정해진 과금 모델 이해가 필수

---

2) 각 엔진의 핵심 성격

2-1. ClickHouse

강점

• 컬럼형 OLAP에 최적화
• 집계/필터 쿼리 빠름
• 실시간 대시보드에 강함

약점

• 운영/튜닝 난이도 존재
• 엔진 구조 이해 없이 쓰면 장점 못 살림

잘 맞는 케이스

• 이벤트 로그 실시간 집계
• 모니터링 대시보드
• 지연 민감한 분석

---

2-2. Athena

강점

• S3 데이터 바로 SQL 조회
• 인프라 관리 부담 낮음
• ad-hoc 분석에 빠르게 투입 가능

약점

• 파일 설계 잘못하면 성능/비용 급락
• 쿼리 습관에 비용 민감

잘 맞는 케이스

• 데이터 레이크 탐색
• 배치 결과 검증
• 운영팀/분석팀의 빠른 조회

---

2-3. BigQuery

강점

• 대규모 분석 처리 안정적
• 협업/BI/ML 연동 생태계 좋음
• 서버리스 운영이 편함

약점

• 스캔량 기반 과금 관리 필요
• 설계 없이 쓰면 비용 증가

잘 맞는 케이스

• 전사 분석 플랫폼
• 여러 팀이 동시에 쓰는 환경
• 장기적인 데이터 표준화

---

3) “어떤 걸 선택해야 하냐”에 대한 실전 의사결정 트리

아래 질문 순서대로 답하면 선택이 빨라진다.

Q1. 응답속도 SLA가 빡센가?

• 예: ClickHouse 우선 검토
• 아니오: 다음 질문

Q2. 데이터가 주로 S3에 쌓여 있나?

• 예: Athena 우선 검토
• 아니오: 다음 질문

Q3. 조직이 분석 표준 플랫폼을 원하나?

• 예: BigQuery 우선 검토
• 아니오: PoC로 비용/성능 비교

Q4. 팀에 운영 튜닝 역량이 있나?

• 예: ClickHouse 운영 가능성↑
• 아니오: Athena/BigQuery의 관리형 이점↑

---

4) 비용이 터지는 대표 패턴 (진짜 중요)

4-1. Athena 비용 폭탄 패턴

• 작은 파일 수십만 개
• 파티션 안 잡힘
• SELECT * 습관

해결

• Parquet/ORC 전환
• 파티션 컬럼 설계
• 컬럼 최소 조회

4-2. BigQuery 비용 폭탄 패턴

• 필요 없는 컬럼까지 매번 스캔
• 무분별한 조인
• 테이블 파티션/클러스터링 미활용

해결

• 파티션/클러스터링 적용
• materialized view 활용
• 쿼리 예산/알림 설정

4-3. ClickHouse 운영 피로 패턴

• 정렬키/파티션키 설계 미흡
• merge/compaction 이해 부족
• 모니터링 부재

해결

• 초기 데이터 모델링 투자
• 운영 메트릭 대시보드 구축
• 워크로드별 테이블 전략 분리

---

5) SQL 관점 차이 (개발자 체감)

세 엔진 다 SQL이지만 체감은 다르다.

• ClickHouse: 성능을 위한 함수/엔진 이해가 중요
• Athena: Trino/Presto 문맥 이해가 유리
• BigQuery: 표준 SQL + 중첩 타입(ARRAY/STRUCT) 활용이 핵심

즉, SQL 문법보다 데이터 모델링 습관이 더 중요하다.

---

6) 팀 규모별 추천 전략

소규모 팀

• 시작은 Athena 또는 BigQuery (운영 단순)
• KPI 명확해지면 ClickHouse 검토

중간 규모 팀

• 공용 분석은 BigQuery/Athena
• 실시간 대시보드는 ClickHouse 병행

대규모 조직

• 목적별 다중 엔진 전략이 일반적
  • 실시간: ClickHouse
  • 레이크 조회: Athena
  • 전사 표준 분석: BigQuery

현실적으로는 “하나로 끝”보다 “용도별 분리”가 더 안정적이다.

---

7) 요약하면

• ClickHouse: “빠른데 손이 많이 감”
• Athena: “쉽게 시작하는 데이터레이크 SQL”
• BigQuery: “조직이 커질수록 빛나는 분석 철도망”

정답은 하나가 아니다.
우리 팀의 속도, 데이터 위치, 운영 역량, 예산 구조가 정답을 만든다.

---

8) 결론

이 세 도구를 비교할 때 가장 위험한 질문은 “뭐가 제일 좋아요?”다.

올바른 질문은 이거다.

“우리의 실제 워크로드에서, 어느 선택이 성능·비용·운영의 균형을 가장 잘 맞추는가?”

이 기준으로 보면 의사결정이 훨씬 선명해진다.

---

출처

• ClickHouse Docs: https://clickhouse.com/docs
• Amazon Athena Docs: https://docs.aws.amazon.com/athena/
• BigQuery Docs: https://cloud.google.com/bigquery/docs