무신사 CDP — self-hosted ClickHouse에서 Cloud로
무신사는 CDP의 Audience Engine을 self-hosted ClickHouse에서 ClickHouse Cloud로 옮겼습니다. 노드에 결합된 스토리지가 스케일 국면에서 병목이 된 것이 계기였습니다.
- 16.4M 회원·7.2M MAU·약 11,000 파트너 브랜드·13개국 서비스 위에 2,500개 오디언스와 약 11억 row의 cohort-to-user 매핑이 올라가 있습니다
✓. - 걸린 것은 네 갈래입니다. EBS가 노드에 묶여 컴퓨트 증설이 불필요한 스토리지를 동반했고 노드 스펙은 고정돼 무거운 쿼리가 시스템을 압박했습니다. 단일 클러스터에서는 비즈니스 로직과 배치 작업이 자원을 두고 경합했습니다. 자체 운영 부담도 예상보다 컸습니다
✓. - 직접적인 계기는 ClickHouse Cloud를 AWS 서울 리전에서 쓸 수 있게 된 것입니다. 기존 self-hosted 설정을 거의 그대로 재사용할 수 있어 마이그레이션 리스크가 낮다고 봤습니다. 운영 자동화·솔루션 아키텍트 지원과 인프라 제약 해소도 이유로 들었습니다
✓. - compute와 storage 계층을 분리했습니다. 워크로드별 전용 컴퓨트에는 스펙을 개별 배정했고 자동 idling·수직 오토스케일링이 함께 붙었습니다. 실시간 적재 경로는 Databricks Auto Loader(별도 Spark 클러스터)에서 ClickPipes로 옮겼습니다
✓. - 스토리지 계층을 분리해 스토리지 비용을 86.5% 줄였습니다. 컴퓨트 계층을 도입해 TCO를 최대 71.4% 줄였습니다
Ⓥ. 비교 기준선이 된 기존 구성의 상세는 공개되지 않았습니다✓.
이 장은 질문 하나에 답합니다 — 노드에 스토리지가 결합된 self-hosted ClickHouse를 실제 스케일 국면까지 밀고 간 국내 팀은 무엇에 걸렸고, 무엇을 어떻게 바꿨나. 프로덕션 운영 사례가 “K8s + operator + 로컬 NVMe” 실증 사례를 여러 건 큐레이션한다면, 이 장은 국내 CDP 사례 한 건의 상세 기록입니다. 배포 형태 선택의 논리는 Managed vs Self-hosted, 스토리지 아키텍처 결정 자체는 스토리지 · 로컬 NVMe가 담당합니다. 이 장은 그 결정을 재론하지 않습니다.
이 장의 사실 원천은 ClickHouse 블로그 글 한 편입니다. 무신사 엔지니어의 AWS Summit Seoul 2026 발표를 정리한 글입니다 ✓.
근거 등급 태그 · 출처 규칙
사례 서술 사실은 입력 조사의 판정(confidence high)을 이어받아 ✓, 조사가 추정으로 남긴 것은 ≈, 원문에 없는 것은 ?로 둡니다. 절감률처럼 당사자가 자기 보고한 수치는 이 레포 규약상 Ⓥ(벤더 주장) 로 표기합니다 — 등급 규약의 일관성 문제이고 수치의 진위 판정이 아닙니다. 이 장의 새 종합 판단은 Σ. URL은 출처에서 관리합니다. 이 페이지에는 싣지 않습니다.
무엇을 만들었나
무신사는 2025년 8월 CDP(Customer Data Platform)를 출시했습니다 ✓. 그 안의 Audience Engine이 이 장의 대상 워크로드입니다 — 마케팅·개인화에 쓸 오디언스(코호트) 정의를 평가해 “어떤 회원이 어떤 오디언스에 속하는가"를 매핑으로 관리하는 컴포넌트입니다. 그 매핑 테이블이 ClickHouse에 올라가 있습니다 ≈.
회원 수가 이 워크로드의 row 상한을 결정합니다. 나머지 지표는 플랫폼 규모의 맥락입니다.
| 항목 | 값 | 등급 |
|---|---|---|
| 회원 | 16.4M | ✓ |
| MAU | 7.2M | ✓ |
| 파트너 브랜드 | 약 11,000 | ✓ |
| 서비스 국가 | 13개국 | ✓ |
| CDP 출시 | 2025-08 | ✓ |
오디언스 정의의 축으로 원문이 제시하는 예시는 “men in their 30s”, “people who abandoned a cart in the last seven days"처럼 인구통계와 행동입니다 ✓. 브랜드·국가가 정의 축으로 쓰이는지는 원문에 없습니다 ?. 매핑 row 수의 상한은 회원 수(16.4M)가 정합니다. 오디언스 개수(2,500)는 마케터의 작업이 쌓인 결과값입니다 Σ.
데이터 모델과 규모
| 항목 | 값 | 등급 |
|---|---|---|
| 오디언스 수 | 2,500 | ✓ |
| cohort-to-user 매핑 row | 약 11억(1.1B) | ✓ |
| 오디언스 1개 추가 시 row 증가(최악) | 최대 1,600만 | ✓ |
| 오디언스당 평균 매핑 row | 약 44만(11억 ÷ 2,500) | Σ⁽계산⁾ |
이 숫자가 아픈 이유는 매핑 테이블의 row가 오디언스 × 그 조건을 만족하는 회원의 곱이기 때문입니다 Σ. 오디언스 하나를 추가할 때 늘어나는 row는 그 오디언스의 모집단 크기입니다. 상한은 전체 회원 수입니다 — 최악 1,600만 row는 사실상 “회원 거의 전부가 한 오디언스에 들어오는 정의"에 해당합니다(회원 16.4M) Σ. 평균 44만 row와 최악 1,600만 row의 간격이 36배쯤 되므로 정의 하나가 얼마를 먹을지 사전에 알 수 없습니다 Σ.
이 워크로드의 매핑 테이블은 이벤트 유입 속도만으로 자라지 않습니다. 오디언스 정의가 하나 늘 때마다 계단식으로 자랍니다 Σ. 원문은 이 성장을 “Since the data grows exponentially"라고 표현합니다. 그래서 “we had to think about how to scale both the data and our computing resources"라고 적습니다 ✓ — 요구는 스토리지 한쪽이 아니라 데이터와 컴퓨트를 각각 독립적으로 늘릴 수 있는가였습니다 Σ.
기존 self-hosted 구성에서 걸린 것
원문은 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” — 사업 변화가 빨라 인프라 운영 개선에 시간을 배분하기 어려웠다 | ✓ |
네 항목은 독립적이지 않고 위의 성장 구조와 맞물립니다 Σ. 스토리지만 늘릴 수 없으면 용량 증설은 노드 증설이 되고 노드 증설은 데이터 재배치를 동반하므로 작업 리스크가 됩니다. 같은 클러스터에서 비즈니스 로직과 배치 작업이 같은 자원을 두고 경합하면 한쪽의 무거운 쿼리가 다른 워크로드의 지연으로 번집니다. 예측 불가능한 계단식 성장과 “증설 = 데이터 작업"이 겹치는 지점이 통증의 원점입니다 Σ.
네 번째 항목은 성격이 다릅니다. 앞 세 개는 구성의 제약이지만 자체 운영 부담은 팀의 시간 배분 문제입니다. 그 부담이 곧 Managed vs Self-hosted가 결정적 변수로 꼽은 people TCO입니다 Σ. 앞 세 제약은 구성을 바꿔 완화할 여지가 있지만 구성을 바꿀 시간이 없다는 조건이 겹치면 선택지가 managed 쪽으로 좁아집니다 Σ.
Cloud 이전 결정과 사유
직접적인 계기는 ClickHouse Cloud를 AWS 서울 리전에서 쓸 수 있게 된 것입니다 ✓ — 원문 표현은 “ClickHouse Cloud was now available in the Seoul region"입니다. GA 여부·시점은 명시되지 않습니다 ?. 이전 사유로 든 것은 아래와 같습니다.
| 사유 | 내용 | 등급 |
|---|---|---|
| 낮은 마이그레이션 리스크 | 기존 self-hosted 설정을 거의 그대로 재사용할 수 있다 | ✓ |
| 운영 부담 이전 | 운영 자동화와 솔루션 아키텍트 지원을 받는다 | ✓ |
| 인프라 제약 해소 | self-hosting에서 걸렸던 위 세 제약을 없앤다 | ✓ |
첫 번째 사유가 이 결정의 실질적 무게중심입니다 Σ. 같은 엔진·같은 스키마·같은 쿼리를 유지한 채 배포 형태만 바꾸는 이전은 데이터스토어 교체보다 이사에 가깝습니다. 통증이 명확한 상태에서 고를 수 있는 가장 짧은 경로가 됩니다.
아키텍처 변화
compute와 storage 계층을 나눈 것이 가장 큰 변화입니다. 다이어그램 캡션 원문은 다음과 같습니다.
“Self-hosted ClickHouse tied storage to each node through attached EBS volumes. ClickHouse Cloud separates the layers, with compute nodes drawing on shared S3 storage.”
이전 구성에서는 스토리지가 부착 EBS 볼륨으로 각 노드에 묶여 있었습니다. 이후 구성에서는 계층이 분리되어 compute 노드가 공유 S3 스토리지를 참조한다는 서술입니다 ✓. 본문 산문은 같은 변화를 “separating the compute and storage layers”, “allowing you to use shared storage and connect compute resources only when needed"로 표현합니다 ✓ — 공유 스토리지를 두고 컴퓨트는 필요할 때만 붙인다는 뜻입니다.
계층 분리는 컴퓨트 배치도 바꿨습니다. 단일 클러스터가 모든 것을 함께 처리하던 구성에서 워크로드마다 전용 컴퓨트를 두고 스펙을 따로 맞추는 구성으로 옮겼습니다 — 원문 표현은 “By separating computing resources by function and assigning the right specs to each, every task runs independently without interfering with one another” 입니다 ✓. 여기에 자동 idling(쓰지 않는 클러스터를 유휴로 전환)과 수직 오토스케일링(쿼리가 메모리를 더 요구할 때 자원을 올리고 끝나면 되돌림)이 붙습니다 ✓. 원문은 자동 idling이 배치 파이프라인·주기 적재에 특히 효과적이라고 적습니다 ✓ — 상시 가동이 아닌 워크로드는 유휴 구간이 그만큼 길다는 뜻입니다 Σ.
적재 경로도 함께 바뀌었습니다. 실시간 적재를 기존에는 Databricks Auto Loader가 별도 Spark 클러스터 위에서 담당했습니다. 이전 후에는 ClickPipes로 전환했습니다 ✓.
| 축 | 이전 (self-hosted) | 이후 (ClickHouse Cloud) |
|---|---|---|
| 스토리지 배치 | 노드에 부착된 EBS 볼륨 ✓ | compute 노드가 공유 S3 스토리지를 참조 ✓ |
| 계층 관계 | storage가 노드에 결합 ✓ | compute / storage 분리 ✓ |
| 컴퓨트 배치 | 단일 클러스터가 모든 워크로드를 함께 처리 ✓ | 워크로드(기능)별 전용 컴퓨트에 각기 다른 스펙 배정 ✓ |
| 유휴·확장 | 원문 미언급 ? | 자동 idling(미사용 시 유휴 전환) + 수직 오토스케일링 ✓ |
| 실시간 적재 | Databricks Auto Loader(별도 Spark 클러스터) ✓ | ClickPipes ✓ |
| 리전 | 원문 미명시 ? | AWS 서울 ✓/≈(서울 가용화가 계기라는 진술까지가 원문, 배치 리전 명시는 없음) |
원문은 ClickPipes 전환의 효과를 “reducing operational overhead and Databricks costs"로 적습니다 ✓. 캡션은 ClickPipes가 ClickHouse Cloud로 직접 적재해 머티리얼라이즈드 뷰와 스토리지로 인계한다고 서술합니다 ✓. 관리 대상 클러스터가 하나 줄어 이전의 이득이 ClickHouse 계층에만 국한되지 않는다는 뜻입니다 Σ. 전환 범위가 실시간 경로에 한정된 것인지, Databricks 쪽 배치 경로가 함께 정리된 것인지는 원문에서 확인되지 않습니다 ?.
결과
| 지표 | 값 | 등급 |
|---|---|---|
| 스토리지 비용 | 86.5% 절감 | Ⓥ |
| TCO(총소유비용) | 최대 71.4% 절감 | Ⓥ |
원문이 제시한 마이그레이션 성과 수치는 이 둘뿐입니다 ✓. 원문은 두 수치의 귀속을 구분합니다 — 86.5%는 스토리지 계층 분리의 결과로, 71.4%는 컴퓨트 계층 도입의 결과(“By introducing this computing layer, we were able to reduce previous total cost of ownership by up to 71.4%")로 적습니다 ✓. 두 수치의 비교 기준선 — 기존 self-hosted 구성의 노드 수·인스턴스 타입·EBS 볼륨 규모, 비교 대상 기간 — 은 공개되지 않았습니다 ✓.
Σ. 이 사례의 86.5% / 71.4%는 무신사의 기존 구성 대비라는 조건 안에서 읽습니다. 우리 견적에 그대로 곱해 쓰지 않습니다. 우리 쪽 비교는 Managed vs Self-hosted의 컴포넌트 분해로 직접 계산합니다.공개되지 않은 수치
이 사례에서 확인되지 않는 것
아래는 원문 전문을 교차 확인해도 나오지 않은 항목입니다. 후속 조사거리 메모로 남깁니다.
| 항목 | 상태 |
|---|---|
| 일일 이벤트 처리량 | 원문 미공개 ? |
| 압축률 | 원문 미공개 ? |
| 쿼리 레이턴시(p50 / p99) | 원문 미공개 ? |
| 이전 self-hosted의 배포 환경(EC2 자체관리인지 온프레미스인지) | 원문 미명시 — “EBS"라는 표현으로 AWS 위였을 가능성만 추정된다 ≈ |
| 이전 self-hosted의 노드 수 | 원문 미공개 ? |
| 절감률의 비교 기준선 구성·기간 | 원문 미공개 ? |
후속: 이 글은 AWS Summit Seoul 2026 발표를 정리한 것이므로 위 항목 일부는 발표 원본(영상·슬라이드)에 있을 수 있습니다 ?. 우리 용량 산정에 이식할 값이 필요해지면 발표 원본을 1차 출처로 확인하는 것이 다음 단계입니다.
우리 케이스에서는
무신사의 선택은 그들의 맥락 — 계단식으로 튀는 스토리지 수요, 증설이 곧 데이터 작업이 되는 구성, 서울 리전을 쓸 수 있게 된 타이밍 — 안에서 합리적입니다 Σ. 우리가 가져올 것은 그들의 결론이 아닙니다. 통증의 위치입니다. 세 지점이 우리 구성에 그대로 대응합니다 Σ.
| 무신사가 겪은 것 | 우리 구성의 등가물 | 우리 방어 수단 |
|---|---|---|
| 스토리지가 노드에 결합돼 따로 못 늘림 | 로컬 NVMe(결합도 더 높음) | 노드당 데이터량 상한 + 재수화 런북 사전 리허설 |
| 노드 추가·제거가 데이터를 건드림 | local PV·리샤딩 수동성 | drain·PV 청소·RF 검증 절차 문서화 |
| 단일 클러스터의 워크로드 간섭 | 관측성 CH와 범용 분석 CH 혼재 | 관측성 CH·범용 분석 CH를 별도 CHI로 분리 — 04의 권고 ≈(확정 결정 아님) |
노드에 스토리지가 결합된 구성이 스케일 국면에서 실제로 아프다는 사실이 이 사례에서 가장 그대로 옮겨올 수 있는 부분입니다 Σ. 이 약점은 우리 local PV 전략에 더 강하게 걸립니다 — 우리는 인스턴스에 물린 로컬 NVMe를 쓰므로 부착 EBS보다 결합도가 한 단계 더 높습니다. 노드가 사라지면 볼륨을 다시 붙이는 선택지조차 없습니다 Σ. 우리는 아키텍처를 교체하는 대신 런북으로 방어합니다: operator 배포 플레이북의 노드 소실 · 재수화 절차와 스케일 런북을 사전 리허설로 검증해 두는 것, 그리고 노드당 데이터량을 절제해 재수화 시간이 replica 여유도를 갉아먹지 않게 상한을 두는 것입니다.
두 번째로 이식할 것은 워크로드 간섭입니다. 단일 클러스터가 여러 워크로드를 함께 받아 서로 간섭했다는 서술은 operator 배포 플레이북이 별도 CHI 분리를 권고한 근거와 같은 통증을 가리킵니다 ≈.
세 번째는 용량 산정 관점입니다. 오디언스 정의 개수가 데이터량을 계단식으로 밀어 올린다는 구조는 성장 동인이 트래픽이 아닌 워크로드도 있다는 뜻입니다 Σ. 우리 쪽에서 이에 대응하는 것은 사용자가 정의하는 대시보드·저장 쿼리·머티리얼라이즈드 뷰입니다. 이 축의 증가는 인제스트 예측만으로는 잡히지 않습니다.
우리 스토리지 결정과 이 사례의 관계는 짧습니다. 스토리지 · 로컬 NVMe의 결정(로컬 NVMe hot + S3 cold, 내구성은 디스크가 아니라 복제로)은 이 사례로 바뀌지 않습니다 — 무신사는 managed로 갔습니다. 이 챕터는 self-host 게이트를 통과한 전제 위에 서 있어 전제 자체가 다릅니다 Σ. 이 사례는 우리 결정의 약점 위치를 확인해 주는 자료로 쓰고 결정을 재판정하는 근거로는 쓰지 않습니다. 시점 기준 2026-08.