[아티클]컬리, 토스증권 데이터 파이프라인 엿보기

https://helloworld.kurly.com/blog/bigquery-1/

컬리의 BigQuery 도입기 - 1부 - 컬리 기술 블로그

 

1부: 전환 배경 

기존 시스템의 4가지 문제

① 긴 지연시간 : 데이터가 창고에 도착하기까지 20분~1시간 걸림.

② 스토리지 부족 : 데이터가 계속 쌓여 오래된 데이터를 주기적으로 삭제해야 했음.

③ 느린 쿼리 응답 : 적재 작업과 조회 작업이 같은 자원을 두고 경쟁해 서로 성능을 떨어뜨림.

④ 복잡한 적재 과정 : 데이터가 창고에 도달하기까지 거치는 경로(파이프라인)가 지나치게 길고 얽혀 있음.

기존 파이프라인의 경로

여러 원본 DB → CDC(변경분 추출) → Kafka(중간 정거장) → S3(임시 저장소) → Airflow(적재 작업 실행) → 최종 창고

경로가 이렇게 길다 보니 문제가 생겼을 때 어느 단계가 원인인지 파악하기 어려웠음.

빅쿼리로 세운 목표

• 지연시간 : 스트리밍 방식으로 창고에 직접 적재
• 스토리지 : 용량 제한 없는 저장소 + 보관 기간 지정
• 자원 경쟁 : 적재용 공간과 조회용 공간을 분리
• 복잡성 : 중간 단계(S3) 제거

여기까지가 1부, 즉 전환의 방향을 제시한 계획 단계임.

---

https://helloworld.kurly.com/blog/bigquery-2/

컬리의 BigQuery 도입기 - 2부 - 컬리 기술 블로그

 

2부: 실제 구축 및 결과 

1. 파이프라인을 두 종류로 분리

데이터 성격이 두 가지로 나뉘어, 파이프라인도 그에 맞춰 둘로 나눴음.

정형 데이터 : 칸(형식)이 고정된 표 형태의 데이터(이름, 주소, 가격처럼 자리가 정해짐). Oracle, Aurora 같은 관계형 DB에서 발생.

비정형 데이터 : 형식이 정해지지 않아 항목이 유동적인 데이터. DocumentDB 같은 NoSQL에서 발생.

비정형 데이터는 정형 데이터와 달리 형식(스키마)이 고정되어 있지 않아, 파이프라인을 지나는 중에 데이터 변환 작업이 필요함.

2. 정형 데이터 파이프라인, 핵심은 Merge(병합)

앞부분은 1부와 유사함. 원본 DB → CDC로 변경분 추출 → Kafka → (여기서부터 달라짐) 빅쿼리에 직접 저장. 중간의 S3(임시 저장소)가 사라진 것이 핵심임.

빅쿼리 안에는 표가 두 개 있음.

• CDC 로그 테이블 : 변경 사항을 접수하는 표. "이 레코드가 추가됐다 / 수정됐다 / 삭제됐다" 같은 변경 이력만 계속 쌓임.
• Final 테이블 : 원본 DB와 동일한 최신 상태를 유지하는 사본 표.

그렇다면 접수된 변경 이력을 어떻게 사본에 반영할까? 여기서 Merge(병합) 방식이 쓰임.

Merge는 변경 이력과 사본을 대조해 한 번에 상태를 맞추는 작업임.

Airflow가 주기적으로 Merge를 실행하면 Final 테이블이 원본 DB와 동일한 상태가 됨. 접수된 추가, 수정, 삭제를 사본에 반영해 항상 최신으로 유지하는 것임.

이 방식이 중요한 이유는 기존 방식(UPSERT)에 결함이 있었기 때문임. (아래 3번에서 설명)

3. 도입 결과

① 데이터를 삭제하지 않아도 됨 (레이크하우스 구축)

- 빅쿼리는 기존 창고보다 저장 비용이 훨씬 저렴하고 확장성이 뛰어나, 이제 오래된 데이터나 각종 로그를 삭제하지 않고 계속 보관할 수 있음. 예전에는 용량이 부족해 버려야 했던 데이터까지 포함해서임.

 

② 파이프라인의 속도와 정확성 개선

- 기존 방식(UPSERT)은 임시 테이블 생성 → 과거 데이터 삭제 → 신규 데이터 삽입 → 임시 테이블 삭제의 4단계를 거쳐 속도가 느렸고, 결정적으로 삭제(Delete) 작업이 반영되지 않아 원본과 사본이 어긋나는 정합성 문제가 있었음(원본에서는 삭제됐으나 사본에는 남는 식).

- 새로 도입한 Merge 방식은 추가, 수정, 삭제를 한 번에 정확히 처리함. 그 효과로, 기존에 30분 넘게 걸리던 작업이 13초 만에 완료됨.

 

③ 쿼리 응답 시간 단축

적재용 공간과 조회용 공간을 분리해 자원 경쟁을 없앴고, 조회 시 반드시 파티션(날짜 단위 구획)을 사용하도록 강제해 스캔 범위를 줄임으로써 응답 속도를 개선함. 체감 속도가 크게 개선되어 CTO의 반응이 별도로 소개될 정도였음.

 

④ 비용 절감

기존 창고는 서버 규모에 따라 정액을 지불했으나, 빅쿼리는 스캔한 용량만큼 지불하거나 슬롯(처리 자원)을 예약 구매하는 방식임. 사용량이 많은 곳은 슬롯을 예약하고, 나머지는 하루 스캔 용량에 상한을 두어 결과적으로 비용을 기존보다 크게 줄였음.

4. 마무리 

POC(사전 검증)부터 이관 완료까지 약 6개월이 걸렸으며, 기존 파이프라인을 운영하면서 동시에 새 파이프라인을 구축하느라 상당한 시간이 소요됐음. 컬리는 e-Commerce 업계 최초로 빅쿼리를 도입했음.

---

궁금증&답(Claude 답변 중심이라 100% 정확하지 않음)

1. 애초에 왜 Amazon S3 거쳐야 됨?

• 요약: Kafka에서 데이터 웨어하우스로 바로 넣기가 어려웠기 때문
• Kafka = 계속 흘러가는 강물 같은 것 = 데이터가 실시간으로 끊임없이 지나가는데, 이걸 데이터 웨어하우스에 곧바로 한 건씩 밀어넣으면 창고가 부담을 못 견딤. 데이터 웨어하우스는 원래 "한 번에 뭉텅이로 받아서 정리"하는 데 최적화돼 있지, "실시간으로 한 방울씩 받기"엔 안 맞음.
• 그래서 중간에 S3라는 양동이를 둔 것 강물(Kafka)을 일단 양동이(S3)에 날짜별로 받아 모아두고, Airflow가 정해진 시간마다 그 양동이를 통째로 창고에 부은 것.
• S3를 거친 이유를 정리하면:
  • 완충 역할 : 실시간으로 쏟아지는 데이터를 일단 저렴하게 쌓아두는 버퍼
  • 뭉텅이 처리 : 모아뒀다 한꺼번에 넣는 게 당시 창고 방식엔 효율적
  • 저렴한 저장소 : S3는 원래 대용량을 싸게 보관하는 용도라 임시 적재에 부담이 적음
• Problem: 이게 바로 병목의 원인이었음. "양동이에 받았다가 다시 퍼서 옮기는" 두 번 일을 함.
• Solution: 빅쿼리는 Streaming API 덕분에 강물을 양동이 없이 창고로 바로 흘려넣을 수 있게 돼서 S3를 없앨 수 있었음.

2. 이커머스 업계에서 왜 빅쿼리 안 사용했었음? 2026년 현재는?

"안 썼다"기보다 "다른 걸 먼저 썼다"가 정확함.

컬리가 "이커머스 최초 빅쿼리 도입"이라고 한 건, 국내 이커머스 중에서 핵심 데이터 파이프라인 전체를 빅쿼리로 옮긴 첫 사례라는 의미에 가까움. 빅쿼리 자체는 그전에도 많은 회사가 부분적으로 쓰고 있었음.

 

그동안 이커머스가 빅쿼리 전면 도입을 망설인 이유는 대략 아래와 같음.

① 이미 AWS에 살고 있었음
대다수 이커머스는 서비스 인프라를 AWS(아마존 클라우드) 위에 지어놓. 그러면 데이터 창고도 자연스럽게 같은 AWS의 Redshift를 쓰는 게 편함. 데이터를 굳이 구글 클라우드로 넘기려면 비용과 손이 더 들거든요. 컬리도 원래 AWS 기반(DMS, Kafka, S3)이었는데, 데이터 창고만 구글 빅쿼리로 넘기면서 AWS↔구글을 오가는 구조가 됨.

 

② 도입하면 되돌리기 어려움
데이터 웨어하우스는 특성상 한 번 도입하면 쉽게 바꾸기 어렵기 때문에 신중하게 선택해야 함.

 

③ 선택지가 여럿임
현재 시장에서 가장 인기 있는 클라우드 데이터 웨어하우스는 구글 빅쿼리, 아마존 레드시프트, 스노우플레이크 셋. 각각 장단점이 뚜렷해서, 회사 상황에 맞는 걸 고르다 보면 빅쿼리가 아닐 수도 있음.

 

2026년 현재는?

:빅쿼리, 레드시프트, 스노우플레이크 3강 구도가 유지되고 있고, 여기에 ClickHouse 같은 초고속 대안도 주목받는 상황. 특정 하나가 압도했다기보다, "우리 인프라와 예산에 뭐가 맞나"로 나뉨. 

3. 다른 이커머스 서비스들의 데이터 파이프라인은 어떠함?

 "원본 DB → 변경분 추출 → 중간 정거장 → 데이터 창고" 구조는 업계 공통.

갈리는 지점은 주로 어느 클라우드를 쓰고, 데이터 창고로 뭘 고르느냐.

• AWS 중심 회사(쿠팡 등 대형 이커머스가 흔히 이쪽) : Redshift를 쓰거나, S3에 데이터 레이크를 두고 그 위에서 분석하는 구조가 일반적. 컬리와 달리 굳이 구글로 안 넘기고 AWS 안에서 다 해결하는 형태.
• 스노우플레이크 : 스노우플레이크의 가장 큰 선택 이유는 데이터 공유(Data Sharing)에 있음. 자체 마켓플레이스에서 데이터 공유를 제공해, 별도의 CDC 이력 관리나 third-party 프로그램 없이도 외부 데이터를 연동할 수 있기 때문임. 여러 회사 데이터를 주고받아야 하는 경우 유리함.
• 공통 고려사항 : 어떤 창고를 고르든, 회사는 수집하는 데이터가 비정형인지, 배치(뭉텅이)로 모아도 되는지 아니면 실시간 스트리밍으로 받아야 하는지를 먼저 고려해야 함. 

---

다른 사례와 비교하기

https://toss.tech/article/toss-securities-visualize-lineage

토스증권의 수 천개 실시간 데이터 파이프라인 운영방법 #1: Visualize Lineage

 

• 서비스가 성장하면서 데이터가 커지면, 배치 처리보다 데이터가 생성되면 실시간으로 가져가는 방식이 적합함.
• But 실시간 파이프라인 구축 시, '좋은 운영'을 위해 필요한 것
  • SLA 충족: 최소 Latency, 24/7 계속 운영되어야 함. 유실X, 중복 최소화.
  • 확장성 고려한 클러스터 설계 필요: 각 파이프라인이 독립적으로 리소스를 할당받도록
  • 시각화: 커뮤니케이션 비용 줄여주기 위해 필요.

위 컬리 사례와의 공통점&차이점

• 공통점:
  • 원본 DB → CDC(변경분 추출) → Kafka.
  • 배치 방식 한계 있는 상황
  • 분리?: 컬리는 적재용/조회용 프로젝트 분리, 토스는 파이프라인별 독립 리소스 할당
• 차이점:
  
  • 글의 목적: 컬리 = 빅쿼리로 갈아탄 '전환'. 토스 = 수천 개로 불어난 파이프라인 '운영'.
  • 실시간성 강도: 컬리 = 준실시간(사본 주기적 최신화). 토스(증권이라) = 초 단위 시세, 무중단·무유실 SLA로 훨씬 빡셈.
  • 저장소 전략: 컬리 = 빅쿼리 하나로 통일(단순화). 토스 = ClickHouse·Hadoop·Kudu·ES 등 용도별 병행(다양화).
  • 핵심 고민: 컬리 = 비용(스캔량, 슬롯). 토스 = 복잡성 관리 → 파이프라인 시각화(Data Lineage, DAG).
  • 클라우드 사용: 컬리 = AWS+빅쿼리 하이브리드. 토스 = 오픈소스 엔진 직접 조합(Flink, Kafka, ClickHouse 등)

---

오늘 인사이트, 느낀 점

• 솔직히 원문의 50%는 이해 못했음. 그냥 claude와 함께 전반적인 파이프라인의 구조를 이해해보려고 노력함.
• SQL 기억이 안 남. 다시 기억 되살려야겠음.
• 토스증권 글 말미에 실시간 파이프라인과 배치 파이프라인(DBT)을 연결해 진정한 End-to-End 리니지를 만들려 한다고 밝히는데, 이 "데이터 웨어하우스 생태계로 넘어가는" 부분이 바로 컬리가 다룬 영역과 맞닿아서 재밌었다.
• 토스증권 글 2부, 3부는 도저히 읽을 수가 없음.