샛별배송을 버티게 한 인프라 — 컬리 AWS 고객사례를 뜯어 읽다

원문: AWS 고객사례 — Kurly

AWS 공식 고객사례 페이지에서 컬리(마켓컬리) 편을 읽었다. 시점상 2020년경에 쓰인 글이라 지금 읽으면 일종의 타임캡슐인데, 오히려 그래서 재밌다. 하이퍼그로스 스타트업이 인프라의 한계에 부딪히고, 갈아엎고, 그 위에서 다시 달리는 전형적인 궤적이 한 페이지에 압축돼 있다.

숫자가 말해주는 상황

배경 숫자부터 심상치 않다. 2015년 첫해 매출 29억 원이 2019년 4,289억 원 — 4년 만에 148배다. 입점 상품 약 2만 개 중 80%가 신선식품이고, 새벽 7시까지 배송하는 샛별배송이 간판이다. 물류센터 면적은 4.9배로 늘고 출고량은 2.9배가 됐다.

문제는 시스템이 이 속도를 따라가지 못했다는 것. CTO의 표현을 빌리면, 사업 초기 외부 업체 솔루션으로 구축한 온라인몰·물류 시스템은 하루 3,000~4,000건 주문까지는 훌륭했지만 그 이상에서 병목이 났다. 그래서 2019년 6월, 인프라를 AWS로 이전하면서 온라인몰과 물류를 모놀리식에서 마이크로서비스 구조로 재개발하는 대형 프로젝트를 돌렸다. 결과는 "약 60배의 성장 속도에도 안정적 서비스"라는 요약으로 정리돼 있다.

서비스 목록에서 아키텍처를 역산하기

고객사례는 마케팅 문서라 아키텍처 다이어그램을 주지 않는다. 대신 서비스 이름을 나열해 주는데, 이 목록을 겹쳐 보면 대략의 그림이 역산된다.

[온라인몰 · 물류 마이크로서비스]
   ├─ Aurora ──────── 주문·상품 등 핵심 트랜잭션
   ├─ DynamoDB ────── 서비스별 독립 스토어
   ├─ DocumentDB ──── 문서형 데이터
   ├─ ElastiCache ─── 조회 캐싱 (트래픽 방어)
   └─ Amazon MQ / MSK ─ 서비스 간 비동기 메시징

[데이터 분석]
   └─ S3 → Athena / Redshift ─ 수요예측 모델링

눈에 띄는 건 메시징이 두 종류라는 점이다. Amazon MQ(전통적 메시지 브로커)와 MSK(Kafka)가 같이 등장하는데, 모놀리식을 쪼개는 과도기 조직의 흔적으로 읽힌다 — 기존 시스템이 쓰던 브로커 프로토콜을 MQ로 수용하면서, 새로 짓는 스트리밍 파이프라인은 Kafka로 가는 그림. 마이그레이션은 빅뱅이 아니라 이렇게 신구가 공존하는 상태를 한동안 버티는 일이라는 게 서비스 목록에서도 드러난다.

데이터베이스가 네 종류인 것도 마이크로서비스 전환의 방증이다. 모놀리식이면 RDB 하나로 끝났을 것을, 서비스마다 자기 데이터 특성에 맞는 스토어를 고른 결과다.

이 사례의 진짜 주인공은 수요예측

인프라 이전보다 흥미로웠던 건 데이터 쪽이다. 신선식품은 유통기한이 2~3일이다. 많이 들여오면 폐기하고, 적게 들여오면 품절이다. 수요예측이 마케팅 최적화가 아니라 손익의 본체인 사업인 것이다.

그래서 컬리는 내부 데이터 분석팀을 꾸리고, 오픈소스 기반 분석 플랫폼을 구축해 기존 구매 데이터에 날씨 데이터까지 얹어 수요예측 모델을 돌렸다. 분석 쿼리는 Athena와 Redshift로. 비 오는 날과 맑은 날의 장바구니가 다르다는 걸 모델에 넣은 셈이다. 화려한 ML 스택 이야기가 아니라 "예측이 틀리면 물건이 썩는다"는 절박함에서 나온 구조라는 점이 좋았다.

배운 것

• 인프라 전환의 트리거는 기술 부채가 아니라 성장 속도다. 3,000건까지 잘 돌던 시스템은 잘못 만든 게 아니다. 그 시점의 올바른 선택이 성장 때문에 수명을 다했을 뿐이고, 갈아탈 타이밍을 놓치지 않은 게 실력이다.
• 고객사례는 서비스 목록으로 읽는 문서다. 다이어그램은 없지만 MQ와 MSK의 병존, DB 네 종류 같은 디테일에서 전환기의 실제 모습이 역산된다. 보도자료를 채용 공고로 검증하듯, 사례 문서는 서비스 조합으로 검증하며 읽게 된다.
• 도메인의 물리적 제약이 데이터 조직의 우선순위를 정한다. 유통기한 2~3일이라는 제약 하나가 "분석팀 신설 → 날씨 데이터 결합 → 수요예측 모델"이라는 투자 순서를 만들었다. 어떤 데이터 과제가 진짜인지는 사업의 물리학이 알려준다.