StarRocks는 무엇이며 왜 이렇게 주목받는가? 토스와 네이버까지 도입한 이유 정리

최근 한국 빅테크들이 OLAP DB를 StarRocks로 전환하고 있다. 토스와 네이버가 대표적이다. 두 회사 모두 자체 기술 블로그에 도입기를 올렸고, 사내 분석 플랫폼 표준 OLAP 엔진으로 깔아두는 분위기다. 그러나 막상 "StarRocks가 무엇인가"라고 물어보면 한 줄로 답하는 사람이 별로 없다. 다들 "빠른 OLAP DB" 정도로만 대충 알고 있다.

 

문제는 StarRocks 자체가 ClickHouse, Druid, Pinot, Trino, Apache Doris 같은 비슷한 엔진들 사이에서 자기 위치를 잡고 등장한 물건이라, "그래서 이것이 ClickHouse와 무엇이 다른가"라는 질문에 답하지 못하면 도입 검토도 어렵다는 점이다. 한국어 자료가 토스와 네이버 글 외에는 거의 없어서 입문이 더 까다롭다.

 

각설하고, 이 글 한 번 읽으면 StarRocks의 정체, 동작 원리, 주목받는 이유, 토스와 네이버가 도입한 배경, 어디에 쓰면 좋고 어디에 쓰면 후회하는지까지 한 번에 정리되도록 작성했다. 기술 블로그 입문서다.

 

StarRocks는 정확히 무엇인가? 한 줄 정의부터 풀어본다

 

 

출처: dbdb.io

 

한 줄로 말하면 오픈소스 MPP OLAP 데이터베이스다. 실시간 분석 데이터베이스로 특화됐고, 표준 SQL과 MySQL 프로토콜을 그대로 쓸 수 있다. C++로 작성되어 있어 빠르다.

 

다만 이 한 줄에 모르는 단어가 너무 많다. MPP, OLAP, 컬럼 기반... 이를 하나씩 풀어줘야 StarRocks가 왜 이런 모양인지 이해된다.

 

StarRocks가 풀려는 문제는 단순하다. 과거에는 분석 시스템을 만들려면 Hadoop + Spark + Hive + Druid + ETL 파이프라인 이렇게 5~6개 시스템을 엮어야 했다. 운영 인력만 한 팀이 갈려나갔다. StarRocks는 "이것을 한 방에 해결하자"며 나온 물건이다.

 

출신은 Apache Doris에서 포크되어 나왔다. 2020년에 등장했고, 현재는 CelerData라는 회사가 상용 버전을 판매하고 있다. 2024년부터는 Linux Foundation 산하 프로젝트다. GitHub 스타는 11,000개를 넘었다.

 

MPP란 무엇인가

 

MPP는 Massively Parallel Processing의 줄임말이다. 우리말로 대규모 병렬 처리다. 쿼리 하나를 여러 노드에 쪼개서 동시에 실행하고, 결과를 합쳐서 돌려주는 구조다.

 

기존 단일 노드 DB는 노드 하나가 모두 처리하므로 데이터가 커지면 답이 없다. MPP는 노드 10개면 거의 10배 빠르다. 페이스북과 구글이 데이터 폭발을 겪던 시절에 이 구조가 표준이 되었다. Greenplum과 Vertica가 1세대였고, StarRocks와 ClickHouse가 요즘 세대다.

 

OLAP vs OLTP 1분 정리

 

OLTP(Online Transaction Processing)는 단건 트랜잭션 처리다. 결제, 주문, 회원가입 같은 작업이다. MySQL과 PostgreSQL이 여기에 속한다.

 

OLAP(Online Analytical Processing)는 대량 데이터의 집계와 분석이다. "어제 매출이 얼마인가", "최근 30일 광고 ROAS를 계산하라" 같은 쿼리다. 한 번에 수백만~수십억 행을 훑는 것이 일이다.

 

StarRocks는 100% OLAP 전용이다. 따라서 MySQL 대체용으로 쓰면 안 된다. 이를 헷갈리는 사람이 의외로 많다.

 

컬럼 기반 vs 로우 기반

 

전통 DB는 한 행을 하나의 단위로 저장한다(로우 기반). MySQL이 그렇다. 다만 OLAP은 보통 "특정 컬럼 몇 개만" 읽는다. 예를 들어 "유저별 결제 합계"라면 user_id, amount 두 컬럼만 필요하다. 그러나 로우 기반은 전체 행을 다 읽어야 한다. 비효율적이다.

 

컬럼 기반은 컬럼별로 따로 저장한다. 필요한 컬럼만 읽으면 된다. 압축률도 훨씬 좋다(같은 타입 데이터끼리 모여 있기 때문이다). StarRocks는 당연히 컬럼 기반이다.

 

StarRocks 아키텍처 뜯어보기, 어떻게 동작하는가

 

 

출처: StarRocks (194KB)

 

StarRocks는 2-tier 구조다. FE와 BE 두 종류의 노드로 나뉜다. 단순해서 운영하기 편하다.

 

FE와 BE 역할 분담

 

• FE (Frontend Node): 메타데이터 관리, 쿼리 파싱, 플래닝, 클러스터 관리 담당. Java로 작성된다. 보통 3대를 띄워 HA로 구성한다
• BE (Backend Node): 실제 데이터 저장, 쿼리 실행, 컴팩션 담당. C++로 작성된다. 데이터가 늘면 BE만 추가하면 스케일아웃된다

 

쉽게 말하면 FE는 "뇌", BE는 "근육"이다. 사용자 SQL이 FE로 들어오면 FE가 어느 BE에게 시킬지 계획을 짜고, BE들이 병렬로 실행하며, FE가 결과를 모아서 돌려준다.

 

왜 빠른가? 벡터화 엔진 쉽게 설명

 

과거 DB 엔진은 한 번에 한 행씩 처리했다(volcano model). 행 하나를 읽고 함수를 호출하고 결과를 뽑고, 또 행 하나를 읽고... 이 방식은 CPU 입장에서 너무 비효율적이다.

 

벡터화 실행 엔진(Vectorized Execution)은 한 번에 수천 행씩(StarRocks 기본 4096행) 묶어서 처리한다. CPU 캐시에 모두 올려두고 SIMD 명령어로 한 방에 처리한다. ClickHouse도 이 방식으로 떴고, StarRocks도 이를 채택했다. 단순 집계 쿼리는 과거 엔진보다 5~10배 빠르다.

 

추가로 CBO(Cost-Based Optimizer)가 통계 기반으로 최적의 실행 계획을 짜준다. 조인 순서와 어느 인덱스를 쓸지 자동으로 결정한다. 이것이 없는 OLAP 엔진(ClickHouse 같은)은 조인이 많은 쿼리에서 무너진다.

 

외부 데이터 직접 쿼리 (Iceberg, Hive, Hudi 연동)

 

이것이 진짜 핵심 기능 중 하나다. External Catalog 기능으로 데이터를 StarRocks에 적재하지 않고 데이터 레이크 위에서 바로 쿼리할 수 있다.

 

기존에는 Iceberg/Hive에 있는 데이터를 분석하려면 ETL로 OLAP DB에 옮겨야 했다. StarRocks는 그저 "이 Iceberg 카탈로그를 보라"고 하면 끝이다. 적재 비용 0원, 데이터 동기화도 필요 없다. 데이터 레이크하우스 구성에서 OLAP 레이어로 자리잡은 이유가 바로 이것이다.

 

추가로 Materialized View 기능도 강력하다. 자주 쓰는 집계를 사전에 만들어두면, 똑같은 패턴의 쿼리가 들어왔을 때 자동으로 MV로 재작성해준다. 사용자는 원본 테이블을 쿼리하지만 실제로는 MV를 읽어 응답이 100배 빨라진다.

 

StarRocks vs ClickHouse: OLAP DB 비교, 굳이 갈아탈 이유가 있는가

 

 

출처: StarRocks (44KB)

 

이것이 가장 많이 받는 질문이다. "어차피 ClickHouse가 빠른데 왜 굳이 StarRocks인가?" 이런 질문이다.

 

항목	StarRocks	ClickHouse	Apache Doris	Druid	Trino
MPP 분산 조인	강함	약함	강함	매우 약함	강함
단일 테이블 집계	매우 빠름	가장 빠름	빠름	빠름	보통
표준 SQL 호환	MySQL 프로토콜	자체 방언	MySQL 프로토콜	제한적	ANSI SQL
운영 난이도	낮음	중간~높음	낮음	높음	중간
데이터 레이크 쿼리	강함 (Iceberg/Hive/Hudi)	약함	중간	약함	가장 강함
라이선스	Apache 2.0	Apache 2.0	Apache 2.0	Apache 2.0	Apache 2.0

 

ClickHouse 대비 강점

 

ClickHouse는 단일 테이블 집계가 정말 미친 듯이 빠르다. 다만 단점이 명확하다.

 

1. 분산 조인이 약하다: ClickHouse는 분산 환경에서 큰 테이블끼리 조인할 때 무너진다. 작은 테이블 broadcast 조인 정도만 무난하다. 데이터가 정규화되어 있으면 ClickHouse는 답이 없다
2. 자체 SQL 방언: ClickHouse SQL은 표준이 아니다. BI 도구(Tableau, Looker, Metabase)와 연동할 때 호환성 문제가 자주 터진다
3. 운영이 복잡하다: ClickHouse Keeper, ZooKeeper, ReplicatedMergeTree 같은 개념을 모두 알아야 한다. 클러스터 운영 노하우가 까다롭다

 

StarRocks는 이 셋 다 약점이 아니다. MPP 조인이 강하고, MySQL 프로토콜을 그대로 쓰며, FE/BE만 띄우면 된다. 그래서 "분석 환경을 새로 구축한다면 StarRocks를 보는 것이 낫다"는 평가가 많다.

 

Apache Doris StarRocks 차이, 한 뿌리에서 갈라진 형제다

 

이것이 헷갈리는 부분이다. Apache Doris가 StarRocks의 원조다. 2020년에 Doris 핵심 개발자들이 따로 나와 StarRocks를 만들었다. 한 뿌리에서 두 갈래로 갈라진 셈이다.

 

현재는 둘 다 활발히 개발 중이라 어느 쪽이 낫다고 단정하기 어렵다. 큰 차이는 다음과 같다:

 

• StarRocks: 외부 카탈로그(Iceberg/Hive 직접 쿼리), Materialized View 자동 재작성에 더 공격적이다. 초기에는 Elastic License 2.0이었는데 2022년 12월에 Apache 2.0으로 변경했고 Linux Foundation 산하다
• Apache Doris: Apache 재단 정식 프로젝트. 라이선스 Apache 2.0. 중국 내수 시장에서 강하다

 

해외와 국내 빅테크는 StarRocks 쪽 채택률이 높은 편이다. 토스와 네이버도 StarRocks를 선택했다.

 

토스와 네이버는 왜 StarRocks를 도입했는가

https://toss.tech/article/operating-starrocks-1

StarRocks 운영기: Resource Group으로 멀티테넌트 워크로드 격리하기

 

출처: toss.tech (130KB)

 

이 부분이 가장 궁금할 것이다. 한국 빅테크 두 곳이 비슷한 시기에 같은 기술을 고른 것은 우연이 아니다.

 

토스가 풀고 싶었던 문제

 

토스 운영기 1편을 보면 도입 배경이 명확하다. 기존에는 MySQL + Hadoop + Spark 조합이었다. 같은 데이터를 두 갈래에 두고 검증하고 서빙해야 하는 이중 경로 구조였다.

 

• Spark 배치로 만든 데이터를 MySQL 온라인 쿼리 결과와 일일이 비교해야 했다
• Hadoop에 있는 데이터를 대시보드에서 보려면 MySQL로 따로 옮겨야 했다
• 시스템이 두 갈래라 운영 복잡도가 폭발했다
• 분석가도 "이 데이터가 어디 있는가"라고 매번 물어봤다. 데이터 사일로화

 

StarRocks 도입과 함께 단일 엔진으로 통합되었다. MySQL 호환 SQL이라 기존 쿼리를 거의 그대로 옮겼고, 대용량 분석과 서비스 조회를 한 엔진에서 처리하게 되었다. 토스가 시리즈로 운영기를 쓸 정도로 만족도가 높은 편이다.

 

네이버가 풀고 싶었던 문제

 

네이버 D2 헬로월드 글에서 정리한 도입 맥락은 다소 다르다. 네이버는 기존에 ClickHouse를 분석 엔진으로 쓰고 있었는데 분산 조인이 약한 것이 골칫거리였다.

 

 

• ClickHouse는 큰 테이블 조인을 하지 못해 비정규화 테이블로 들고 있어야 했다. 차원이 고정되어 분석가가 자유롭게 쓰지 못했다
• 노드를 늘릴 때마다 데이터 수동 리밸런싱이 필요했다
• 실시간 upsert/delete 성능도 나오지 않았다

 

Trino, Pinot, Druid, StarRocks 후보들을 벤치마크한 끝에 StarRocks를 선택했다. 다중 테이블 조인을 네이티브로 지원해 비정규화하지 않아도 되고, 집계 쿼리 성능도 ClickHouse 수준 이상이었다. 쿠버네티스에서 스토리지와 컴퓨트 분리 구조로 운영 중이다.

 

공통 도입 이유 정리

 

토스와 네이버의 도입기를 비교해보면 공통점이 명확하다.

 

1. 운영 단순화: 여러 시스템 → 단일 엔진. 인력 비용 절감
2. 표준 SQL 호환: MySQL 프로토콜이라 BI 도구와 분석가의 진입장벽이 낮다
3. 속도와 분산 조인의 강점: 벡터화 엔진 + CBO + MV에 다중 테이블 조인까지 네이티브 지원
4. 데이터 레이크 친화성: Iceberg 등 외부 카탈로그 직접 쿼리

 

이 네 가지가 StarRocks의 핵심 셀링 포인트다. 다른 OLAP 엔진들은 이 네 가지를 모두 만족시키지 못한다.

 

StarRocks는 어디에 쓰면 좋고 어디에 쓰면 후회하는가

 

 

출처: Radial Consulting (99KB)

 

마케팅 자료는 다 좋다고만 하니 솔직하게 정리한다. 도입을 검토하기 전에 이것부터 먼저 봐야 한다.

 

잘 맞는 케이스

 

✅ 실시간 대시보드: 광고 성과, 결제 분석, 트랜잭션 모니터링. 초~분 단위로 갱신되는 지표를 보여주는 데 최적이다

 

✅ 사용자 행동 분석: 퍼널 분석, 코호트 분석, 리텐션 계산. 큰 테이블과 복잡한 윈도우 함수 조합에 강하다

 

✅ 데이터 레이크 위 ad-hoc 분석: Iceberg/Hive에 데이터가 있는 상태에서 분석가가 자유롭게 쿼리해야 할 때. ETL을 하지 않아도 되어 매우 편리하다

 

✅ BI 도구 백엔드: Tableau, Metabase, Superset 같은 BI 도구를 MySQL 프로토콜로 그대로 붙일 수 있다

 

안 맞는 케이스

 

❌ OLTP 워크로드: 결제 처리, 회원가입 같은 단건 트랜잭션이 빈번한 서비스 DB 용도로 쓰면 안 된다. 이는 PostgreSQL/MySQL 영역이다

 

❌ 단순 KV 룩업: "user_id로 1개 행 조회" 같은 패턴은 Redis/DynamoDB가 답이다. StarRocks를 쓰면 오버킬이다

 

❌ 비정형 데이터 처리: JSON 처리는 어느 정도 가능하다. 다만 본격적인 도큐먼트 DB 용도로 쓰려면 MongoDB나 Elasticsearch로 가야 한다

 

운영 함정

 

도입 후 후회하는 포인트를 몇 가지 정리한다.

 

1. BE 노드 메모리 폭주: 집계 쿼리가 복잡해지면 BE 메모리가 터진다. 쿼리 메모리 제한과 BE 노드 사이즈를 신중하게 정해야 한다
2. 컴팩션 지연: 잦은 인서트가 발생하면 컴팩션이 따라오지 못한다. 쓰기 패턴 설계를 잘 해야 한다
3. 라이선스 변경 이력 주의: 2022년 12월 Elastic License 2.0에서 Apache 2.0으로 변경되었다. 과거 자료와 블로그를 보면 아직도 "Elastic License라 SaaS 재판매 금지" 같은 정보가 남아 있는데 현재 버전은 정식 오픈소스다. 이력만 알아두면 문제없다
4. 한국어 자료 부족: 영문 자료는 충분한데 한국어는 토스와 네이버 외에는 빈약하다. 운영 노하우가 적은 것이 진입 비용이다
5. 버전 차이가 큼: 2.x → 3.x 사이에 외부 카탈로그 등 큰 변화가 있었다. 최신 버전을 기준으로 보고 도입을 결정해야 한다

 

도입 전 체크리스트

 

• [ ] 우리 워크로드가 OLAP인가? (OLTP면 패스)
• [ ] 데이터 규모가 단일 노드 DB로 감당 안 되는 수준인가?
• [ ] 표준 SQL/MySQL 프로토콜 호환이 필요한가?
• [ ] 라이선스(현재 Apache 2.0)를 검토했는가?
• [ ] PoC로 우리 쿼리 패턴에서 실측해봤는가?

 

핵심 정리: StarRocks 지금 깔아봐야 할 이유

 

여기까지 읽었다면 StarRocks가 무엇인지, 어떻게 동작하는지, 왜 토스와 네이버가 선택했는지, 어디에 쓰면 좋은지 모두 정리되었을 것이다. 핵심만 3줄로 다시 정리하면 다음과 같다:

 

1. 빠른 MPP OLAP DB다. 벡터화 엔진 + CBO + MV로 ClickHouse급 속도를 내면서 분산 조인까지 가능하다
2. 운영이 단순하다. FE + BE 2-tier 구조에 MySQL 프로토콜을 그대로 사용한다. 토스와 네이버가 이 점 때문에 선택했다
3. 데이터 레이크 친화적이다. Iceberg/Hive 외부 카탈로그를 직접 쿼리할 수 있어 ETL을 하지 않아도 된다

 

단점도 솔직히 말하면 한국어 자료가 부족하고, 운영 노하우를 가진 사람이 적으며, 컴팩션과 메모리 튜닝 같은 운영 함정이 존재한다. 그럼에도 새로 분석 인프라를 구축한다면 StarRocks를 검토하지 않는 것은 직무유기 수준이다.

 

도입을 고민 중이라면 공식 문서 Quick Start로 30분간 설치해보고 GitHub 저장소를 한 번 둘러보면 답이 나온다. 회사 데이터 일부를 넣어보고 ClickHouse/Doris와 직접 벤치마크를 돌려보면 더 확실하다. PoC 한 번 돌리는 데 들이는 시간 대비 얻는 것이 많다.

 

다음 글에서는 StarRocks 실제 운영 노하우(BE 노드 사이징, MV 설계, 외부 카탈로그 활용 패턴)를 정리할 예정이다.