배민스토어에 최신 기술 한방에 때려넣기: Kotlin, Spring WebFlux, EDA #우아콘2023 #우아한형제들

동기 연동의 한계를 풀기 위해 이벤트 기반 아키텍처(EDA)를 도입했다. 여기서 "이벤트"는 이미 발생한 사실이라 변경할 수 없다는 점이 핵심이다. 시스템 간 느슨한 결합·높은 확장성·도메인 특화 모델이라는 장점이 있는 반면 구성 난이도가 높아 카프카(Kafka) 같은 솔루션을 활용했다.

두 가지 이벤트 연동 방식을 함께 쓴다. 쿠폰처럼 등록 이벤트가 발행되면 페이로드 자체를 저장하고, 상품은 동시성·순서 역전 이슈가 있어 이벤트로는 상품 아이디만 수집한 뒤 조회 API로 최신 데이터를 저장하는 제로 페이로드(zero payload) 방식을 쓴다. 가게·쿠폰·프로모션 정보는 결국 샵 아이디·셀러 아이디 기준으로 모이므로 그 키 중심으로 전시 최적화 모델로 재설계하면 빠르게 응답할 수 있다.

도메인 이벤트가 발행되면 카프카로 수집한 뒤, 컨슈머(워커)가 1차로 DynamoDB, 2차로 Redis에 데이터를 적재한다. 전시에 필요한 데이터만 필터링해 샵 아이디 기준으로 모은 전시 최적화 모델을 구성하고, 조회 API는 먼저 Redis에서 응답하되 없으면 폴백으로 DynamoDB에서 가져온다. 이렇게 미리 모델을 만들어 두면 동기식 플랫폼을 매번 호출할 필요가 줄어 빠르게 응답한다.

EDA 도입 이후의 고민도 솔직히 털어놓는다. 전시 관련 도메인만 10개가 넘고 이벤트 개수도 매우 많으며, 상품 데이터는 약 천만 건을 동시에 수집해야 했고 재고 이벤트는 수억 단위 이상의 카프카 오프셋이 발행될 만큼 규모가 크다.

모든 도메인을 이벤트로 연동할 수는 없다는 한계와 오픈 이후 운영 문제를 짚는다. 상품·판매자·가격 이벤트가 계속 늘어 크기·양이 줄지 않았고, 예상과 달리 비즈니스 진화로 스키마도 자주 바뀌었으며, 연동 이벤트가 증가하는 만큼 에러도 함께 증가하는 것이 치명적이었다.

대응으로, 컨슈머가 밀려 이벤트가 지연되는 경우를 위한 데이터 보정을 고민하고, 정보 갱신 이벤트를 배치 서비스에서 발행하거나 수기로 발행하기도 한다. 나아가 DLT(Dead Letter Topic)를 적극 활용해 스스로 복원력을 갖는 시스템을 지향하고, 모든 플랫폼을 동기 연동할 수 없으므로 서킷 브레이커로 일부 영역은 노출하지 않는 구성을 택하기도 하며, 도메인 이벤트를 추적하고 "어떤 데이터 기준으로 모을 것인가"를 끊임없이 고민하는 것이 중요하다고 강조한다.

김민태 님은 신기술 도입 기준으로 적절한 개발 기간과 충분한 이점을 꼽으며 "기술을 비즈니스에 맞추지 말고 비즈니스에 기술을 맞춰야 한다"고 강조한다. EDA도 그대로 따르기보다 적절히 섞어 쓰는 것이 맞다고 정리한다.

이어 오지산 님이 코틀린과 스프링 웹플럭스 적용기를 발표한다. 동네 사장님 입점을 위한 "일반 셀러 프로젝트"를 앞두고 코드·API를 새로 짜기로 했다. 코틀린은 큰 이견 없이 도입했지만, 웹플럭스는 프로젝트 리액터의 러닝 커브가 높아 신중했고, 여러 외부 API를 실시간 호출하는 화면에서 논블로킹·병렬 호출로 응답 시간을 줄일 수 있다는 장기 관점에서(찬성 4·중립 2·우려 1) 전시 API에만 도입하고 어드민·배치성에는 도입하지 않기로 했다.

회고에서는 기대와 현실의 차이를 공유한다. 핀포인트(APM)상 더 많은 요청에도 레이턴시가 줄었지만 MVC와 통제된 비교를 못 한 아쉬움이 남았다. 백프레셔(backpressure)는 외부 API를 한두 번 호출하는 로직보다 카프카 수신·커서 페이지네이션 같은 배치성 로직에서 진가를 발휘함을 깨달아 방향을 수정했다. 코틀린은 확장 함수·DSL로 검색 플랫폼 DSL을 래핑해 컴파일 시점에 오류를 차단한 사례가 긍정적이었으나, 모노(Mono)의 빈 값 전파 같은 널 안정성 한계에서 "프로젝트 리액터가 코틀린을 이겨버린 것 아닐까"라는 통찰에 이른다. 다음 스텝으로 코틀린 코루틴을 점진 적용 중이며, 신기술 도입은 정답이 없으니 성과를 독립적으로 측정하고 스터디·페어·코드 리뷰 같은 기본 문화를 챙겨야 한다고 당부하며 마무리한다.