무신사 CDP — self-hosted ClickHouse에서 Cloud로
무신사의 CDP에서는 오디언스 정의 하나가 최대 1,600만 행을 추가할 수 있습니다. 회원이 어느 오디언스에 속하는지 저장하는 매핑이기 때문입니다. 정의가 2,500개로 늘면서 매핑은 약 11억 행이 됐고, 팀은 데이터와 컴퓨트를 각각 확장할 방법을 찾았습니다.
기존 self-hosted ClickHouse에서는 노드 증설에 EBS 스토리지도 따라붙었습니다. 비즈니스 로직과 배치 작업은 한 클러스터의 자원을 나눠 썼습니다. 무신사는 ClickHouse Cloud로 옮겨 공유 S3 스토리지와 워크로드별 컴퓨트를 사용하고, 실시간 적재를 Databricks Auto Loader에서 ClickPipes로 바꿨습니다.
이 글은 무신사 엔지니어의 AWS Summit Seoul 2026 발표를 정리한 ClickHouse 블로그를 바탕으로 합니다. 절감률은 당사자 보고이므로 Ⓥ, 공개되지 않은 항목은 ?, 계산과 해석은 Σ로 표시합니다. 원문은 출처, 다른 회사 사례는 운영 사례에 있습니다.
무엇을 만들었나
무신사는 2025년 8월 CDP(Customer Data Platform)를 출시했습니다 ✓. Audience Engine은 마케팅과 개인화에 사용할 오디언스 조건을 평가합니다. 예를 들어 30대 남성이나 최근 7일 안에 장바구니를 이탈한 회원을 찾고, 어떤 회원이 어떤 오디언스에 속하는지 관리합니다. 이 매핑을 ClickHouse에 저장하는 구조로 이해할 수 있습니다 ≈.
공개된 서비스 규모는 다음과 같습니다. 회원 수는 오디언스 하나에 포함될 수 있는 최대 인원을 이해하는 데 필요합니다.
| 항목 | 값 | 등급 |
|---|---|---|
| 회원 | 16.4M | ✓ |
| MAU | 7.2M | ✓ |
| 파트너 브랜드 | 약 11,000 | ✓ |
| 서비스 국가 | 13개국 | ✓ |
| CDP 출시 | 2025-08 | ✓ |
원문은 인구통계와 행동 조건을 예로 듭니다. 브랜드·국가를 실제 오디언스 조건으로 사용하는지는 밝히지 않았습니다 ?. 서비스가 여러 국가에 걸쳐 있다는 사실만으로 데이터 모델의 조건을 추가해 해석하지는 않습니다.
데이터 모델과 규모
| 항목 | 값 | 등급 |
|---|---|---|
| 오디언스 수 | 2,500 | ✓ |
| cohort-to-user 매핑 row | 약 11억(1.1B) | ✓ |
| 오디언스 1개 추가 시 row 증가(최악) | 최대 1,600만 | ✓ |
| 오디언스당 평균 매핑 row | 약 44만(11억 ÷ 2,500) | Σ⁽계산⁾ |
매핑 테이블에는 오디언스와 그 조건을 만족하는 회원의 조합이 들어갑니다. 따라서 오디언스 하나를 추가할 때 늘어나는 행 수는 해당 조건을 만족하는 회원 수입니다 Σ. 평균은 약 44만 행이지만 거의 모든 회원을 포함하는 조건이라면 최대 약 1,600만 행까지 늘어납니다. 두 값의 차이가 약 36배라 오디언스 개수만으로 용량 증가를 예측하기는 어렵습니다.
이 테이블은 이벤트가 들어올 때만 자라는 것이 아닙니다. 마케터가 오디언스 정의를 추가할 때도 커집니다. 원문은 이를 “exponentially”라고 표현했지만, 공개된 데이터 모델만으로 수학적인 지수 성장을 확정할 수는 없습니다. 확인할 수 있는 운영 요구는 데이터 용량과 조건 평가에 필요한 컴퓨트를 각각 늘릴 수 있어야 한다는 점입니다 Σ.
기존 self-hosted 구성에서 걸린 것
원문이 제시한 문제는 노드와 스토리지의 결합, 고정된 컴퓨트 사양, 워크로드 경합, 운영 부담입니다. 그중 스토리지 결합은 비용과 변경 작업 양쪽에 영향을 줬습니다.
| 걸린 것 | 내용 | 등급 |
|---|---|---|
| 스토리지 스케일링 | 컴퓨트를 늘리려 노드를 추가하면 필요 없는 스토리지까지 함께 늘어 비용이 올라갔고, 스토리지만 따로 늘릴 수도 없었다. 원문 표현은 “EBS storage and compute were tied to the same node” | ✓ |
| 작업 리스크 | 노드 추가·제거가 데이터 자체에 영향을 준다 — 용량 조정이 곧 데이터 이동 작업이 되어 리스크를 진다 | ✓ |
| 고정 스펙 | 노드 스펙이 고정돼 무거운 쿼리가 시스템을 압박했고, 외부 컴퓨팅 자원에 의존한 때가 있었다 — “There were times when we had to rely on external computing resources” | ✓ |
| 워크로드 간섭 | 단일 클러스터가 여러 워크로드를 동시에 처리해, 비즈니스 로직과 배치 작업이 같은 자원을 두고 경합했다 | ✓ |
| 자체 운영 부담 | “Managing ClickHouse ourselves turned out to be more burdensome than expected” — 사업 변화가 빨라 인프라 운영 개선에 시간을 배분하기 어려웠다 | ✓ |
용량을 늘리려면 노드를 추가하고 데이터를 재배치해야 했습니다. 한 클러스터의 배치 쿼리가 무거워지면 비즈니스 로직도 자원 부족의 영향을 받았습니다. 오디언스별 데이터 증가 폭이 큰 상황에서 이러한 증설·경합 문제를 함께 다뤄야 했습니다 Σ.
구성을 고칠 수 있더라도 팀이 그 작업에 시간을 배정할 수 있어야 합니다. 무신사는 빠른 사업 변화 속에서 자체 운영 부담이 예상보다 컸다고 설명합니다. 배포 형태의 TCO 비교에서 인건비를 따로 계산하는 이유와 연결됩니다 Σ.
Cloud 이전 결정과 사유
ClickHouse Cloud를 AWS 서울 리전에서 사용할 수 있게 된 것이 이전의 계기였습니다 ✓. 원문은 가용화 사실만 언급하므로 GA 날짜까지 알 수는 없습니다 ?. 팀은 아래 이유로 이전을 선택했습니다.
| 사유 | 내용 | 등급 |
|---|---|---|
| 낮은 마이그레이션 리스크 | 기존 self-hosted 설정을 거의 그대로 재사용할 수 있다 | ✓ |
| 운영 부담 이전 | 운영 자동화와 솔루션 아키텍트 지원을 받는다 | ✓ |
| 인프라 제약 해소 | self-hosting에서 걸렸던 위 세 제약을 없앤다 | ✓ |
기존 설정을 재사용할 수 있다는 점은 이전 범위를 줄여줍니다. 새 데이터스토어에 맞춰 스키마와 쿼리를 모두 바꾸는 작업보다 기존 동작을 유지하면서 운영 구성을 바꿀 여지가 컸던 것으로 해석할 수 있습니다 Σ.
아키텍처 변화
Cloud에서는 compute 노드가 공유 S3 스토리지를 읽습니다. 이전에는 각 노드에 EBS를 붙였으므로 노드 변경이 데이터 배치에도 영향을 줬습니다. 스토리지를 공유하면서 필요한 컴퓨트를 별도로 붙이는 구성으로 바뀌었습니다 ✓.
컴퓨트는 기능별로 나누고 각 작업에 맞는 사양을 할당했습니다. 사용하지 않을 때는 자동 idling을 적용하고, 쿼리가 메모리를 더 요구하면 수직 오토스케일링으로 자원을 조정합니다. 원문은 특히 배치·주기 적재처럼 유휴 시간이 있는 작업에서 idling의 효과를 설명합니다 ✓.
실시간 적재에 사용하던 Databricks Auto Loader의 별도 Spark 클러스터는 ClickPipes로 대체했습니다. ClickHouse 외부의 관리 대상도 함께 줄어든 변화입니다.
| 축 | 이전 (self-hosted) | 이후 (ClickHouse Cloud) |
|---|---|---|
| 스토리지 배치 | 노드에 부착된 EBS 볼륨 ✓ | compute 노드가 공유 S3 스토리지를 참조 ✓ |
| 계층 관계 | storage가 노드에 결합 ✓ | compute / storage 분리 ✓ |
| 컴퓨트 배치 | 단일 클러스터가 모든 워크로드를 함께 처리 ✓ | 워크로드(기능)별 전용 컴퓨트에 각기 다른 스펙 배정 ✓ |
| 유휴·확장 | 원문 미언급 ? | 자동 idling(미사용 시 유휴 전환) + 수직 오토스케일링 ✓ |
| 실시간 적재 | Databricks Auto Loader(별도 Spark 클러스터) ✓ | ClickPipes ✓ |
| 리전 | 원문 미명시 ? | AWS 서울 ✓/≈(서울 가용화가 계기라는 진술까지가 원문, 배치 리전 명시는 없음) |
원문은 ClickPipes 전환으로 Databricks 비용과 운영 부담을 줄였다고 설명합니다 ✓. ClickPipes가 Cloud에 적재한 데이터는 머티리얼라이즈드 뷰와 스토리지로 이어집니다. Databricks의 배치 작업까지 모두 제거했는지는 공개되지 않았습니다 ?.
결과
| 지표 | 값 | 등급 |
|---|---|---|
| 스토리지 비용 | 86.5% 절감 | Ⓥ |
| TCO(총소유비용) | 최대 71.4% 절감 | Ⓥ |
86.5%는 스토리지 계층 분리에 따른 스토리지 비용 절감, 최대 71.4%는 컴퓨트 계층 도입 뒤의 TCO 절감으로 보고됐습니다 Ⓥ. 기존 노드 수, 인스턴스 타입, EBS 용량, 비교 기간이 공개되지 않아 두 절감률을 다른 환경에서 재계산할 수는 없습니다.
공개되지 않은 수치
이 사례에서 확인되지 않는 것
아래는 원문 전문을 교차 확인해도 나오지 않은 항목입니다. 후속 조사거리 메모로 남깁니다.
| 항목 | 상태 |
|---|---|
| 일일 이벤트 처리량 | 원문 미공개 ? |
| 압축률 | 원문 미공개 ? |
| 쿼리 레이턴시(p50 / p99) | 원문 미공개 ? |
| 이전 self-hosted의 배포 환경(EC2 자체관리인지 온프레미스인지) | 원문 미명시 — “EBS"라는 표현으로 AWS 위였을 가능성만 추정된다 ≈ |
| 이전 self-hosted의 노드 수 | 원문 미공개 ? |
| 절감률의 비교 기준선 구성·기간 | 원문 미공개 ? |
후속: 이 글은 AWS Summit Seoul 2026 발표를 정리한 것이므로 위 항목 일부는 발표 원본(영상·슬라이드)에 있을 수 있습니다 ?. 우리 용량 산정에 이식할 값이 필요해지면 발표 원본을 1차 출처로 확인하는 것이 다음 단계입니다.
노드 교체와 워크로드 경합에 남는 과제
무신사 사례에서 우리 로컬 NVMe 구성과 겹치는 문제는 노드 변경이 데이터 작업으로 이어진다는 점입니다. NVMe는 인스턴스가 사라지면 EBS처럼 볼륨을 재부착할 수도 없습니다. 스토리지 설계에서 노드당 데이터량과 복구 시간을 제한해야 하는 이유입니다.
워크로드 경합도 참고할 부분입니다. 관측성 적재와 범용 분석이 서로 영향을 준다면 배포 플레이북처럼 CHI와 노드풀을 분리하는 구성을 검토합니다. 동일한 ClickHouse를 쓰더라도 모든 작업을 한 클러스터에 둘 필요는 없습니다.
용량 예측에는 인제스트 외의 변화도 넣습니다. 무신사는 오디언스 정의가 매핑 데이터를 늘렸습니다. 우리 환경에서는 머티리얼라이즈드 뷰가 만드는 저장량과 대시보드·저장 쿼리가 만드는 조회 부하를 각각 계산해야 합니다.
이 사례만으로 self-host나 Cloud를 결정하지는 않습니다. 운영 시간을 확보하기 어렵고 워크로드별 컴퓨트 분리가 필요해지는지, 로컬 디스크의 성능 이득이 그 부담을 감수할 만큼 큰지 비용 비교에 반영합니다. 시점 기준 2026-08.