Kafka를 활용한 이벤트 기반 아키텍처 구축 #우아콘2023 #우아한형제들

우아한테크·우아콘 2023 2023·2023년

AI 요약

우아한형제들 딜리버리 조직이 점점 복잡해지는 배달 시스템에 카프카 기반 이벤트 아키텍처(EDA)를 적용한 경험을 공유한다. 알림·통계·쿠폰 같은 부가 기능을 배달 본체에서 떼어내는 결과적 일관성 개념부터, 이벤트 구성 요소 설계, 순서 보장을 위한 카프카·아웃박스 패턴, 그리고 이벤트 스트림 활용까지 다룬다.

핵심 포인트

알림·통계는 배달과 "동시에"가 아니라 준실시간으로만 반영되면 되는 결과적 일관성 관계라, 이벤트로 분리해 배달 시스템의 복잡도를 불변으로 유지했다
이벤트를 대상·행동·정보·시간 네 요소로 정의하고, 마틴 파울러의 도메인 이벤트를 참고하되 배민 특성상 주문 식별자도 함께 담았다
순서 보장을 위해 카프카를 택하고, 발행 순단 문제는 트랜잭셔널 아웃박스 패턴 + Debezium CDC로 해결했으며, 이벤트 스트림을 CQRS·데이터 레이크·실시간 집계에 활용했다

왜 읽나모놀리식 도메인 분리와 EDA 도입, 특히 이벤트 순서 보장과 발행 신뢰성을 고민하는 백엔드 개발자에게 설계 결정과 운영 함정의 해법을 보여 준다.

챕터별 상세

010:00 – 2:21

배달 시스템의 복잡도 문제

딜리버리 서비스팀 임준수 님과 배차 시스템팀 송인태 님이 점점 복잡해지는 배달 시스템에 이벤트 기반 아키텍처(EDA)를 적용한 경험을 공유한다. EDA를 왜 구축했는지와 이벤트 구성 요소는 임준수 님이, 전달 파이프라인과 활용 사례는 송인태 님이 맡는다.

딜리버리 조직의 역할은 주문한 음식이 집 앞에 오기까지의 "배달"을 잘하는 것이다. 처음엔 배달만 잘하면 됐지만, 배달 상황 변경 시 고객 알림, 적절한 배달 시간 안내, 진행 배달·지표 통계, 늦으면 주는 쿠폰 같은 기능이 차례로 추가되며 배달과 직접 관련 없는 기능들이 배달 시스템에 녹아들어 복잡도가 계속 높아졌다.

복잡도를 낮추려 배달 기능과 배달이 아닌 기능을 분리하려 하니, 알림·통계 같은 기능이 배달과 강한 일관성을 갖지 않음을 발견했다. 강한 일관성은 주문·결제처럼 어느 시점에 확인해도 항상 함께 만족해야 하는 관계를 뜻한다.

배달 부가 기능은 반드시 반영되어야 하지만 "동시에" 반영될 필요는 없고 준실시간으로만 만족하면 고객 경험을 해치지 않는다는 것이 핵심 통찰이다. 이렇게 "언젠가" 반영되는 관계를 결과적 일관성(eventual consistency)이라 하며 이벤트로 표현할 수 있었다. 이벤트로 연동한 구조가 EDA로, 그 결과 배달은 배달만 잘 수행하며 변경 사항을 이벤트로 전달하고 알림·통계는 그 이벤트만 수신해 자기 일을 수행하는 미래를 그릴 수 있었다.

EDA를 구현하려니 "이벤트에 어떤 속성이 들어가야 하는가"가 필요했다. 마틴 파울러의 도메인 이벤트 개념을 참고해 이벤트 구성 요소를 대상·행동·정보·시간 네 가지로 뽑았다. "대상"은 어떤 배달이 변경됐는지 식별자로 나타내고, "행동"은 이미 발생한 일이라 "배차되었다"처럼 과거형으로 적으며, "정보"는 행위와 밀접한 값에 더해 배민 대부분 프로세스가 "주문" 기준이라 주문 식별자도 함께 담는다. "시간"은 발행 시각이 아니라 실제 행위가 발생한 시각이다. 이 네 요소를 이벤트 아이디·타입·데이터·오커스(occurredAt) 네 필드로 표현했다.

EDA 구축 후 가장 좋았던 점은 요구사항이 추가되어도 배달 시스템 자체의 복잡도에는 변경이 없다는 것이다. 두 번째 장점은 소비처와의 결합도 감소로, 풍부한 정보를 담아 전달하면 소비처가 변경 사항을 모두 파악해 배달 시스템에 다시 물을 필요가 없다. 세 번째는 데이터 분석으로, 배달에 일어난 사건을 상세히 저장하면 도메인 히스토리를 분석에 활용할 수 있다.

다만 주의점도 있다. 이벤트에 무분별하게 데이터를 추가하면 소비처 비즈니스에 결합되므로 최소한 행위자 기준으로 정의해야 하고, 무엇보다 이벤트의 순서가 매우 중요하다.

송인태 님이 이벤트 순서 보장의 중요성을 사고 사례로 보여준다. 주문이 생성 후 취소됐는데 이벤트가 취소·생성 순으로 거꾸로 도착하면, 생성 이벤트를 보고 배달을 생성하면 안 되는 상황이 생긴다.

메시지 브로커로는 사내 SNS/SQS와 카프카 중 카프카를 선택했고, 이유로 순서 보장, 고성능·고가용성, 통합 도구, 전담팀 지원 네 가지를 든다. 카프카는 토픽의 파티션별로 소비 순서를 보장하므로 배달 번호를 키로 발행하면 배달별 순서를 지키고, 한 브로커에 문제가 생겨도 다른 브로커가 파티션을 처리해 고가용성을 보장한다. 카프카 스트림즈·커넥트 같은 통합 도구를 쓸 수 있고, 사내에 카프카를 전담 관리하는 팀이 있어 안정적으로 쓸 수 있었던 점을 가장 중요한 이유로 꼽는다.

운영에 도입하니 EBS 볼륨·주키퍼 통신·네트워크 이슈로 이벤트 발행이 순단되면 발행 실패나 재시도 중 순서가 바뀌어, 도메인 상태와 이벤트 발행 결과가 어긋나 장애로 확산됐다. 이를 해결하기 위해 트랜잭셔널 아웃박스 패턴을 도입한다. 발행할 이벤트를 도메인 트랜잭션과 묶어 아웃박스 테이블에 저장해 일관성을 보장하고, 메시지 릴레이가 그 이벤트를 순서대로 읽어 발행한다. 메시지 릴레이는 직접 구현하지 않고 CDC 오픈소스 Debezium을 택했는데, 카프카 커넥트로 제공돼 사내 환경·모니터링을 그대로 쓸 수 있고(저비용), DB 변경 로그를 순서대로 읽으며(안정성), MySQL 커넥터의 태스크 1개 제약은 아웃박스 테이블을 파티셔닝하고 각각 커넥터를 붙여 처리량을 늘려 해결했다.

마지막으로 유실 없이 순서가 보장된 이벤트 스트림을 활용한 세 사례를 공유한다. 첫째 CQRS로 조회용 쿼리 모델을 분리해 조회 쪽 문제가 커맨드 쪽에 영향을 주지 않게 했고, 둘째 S3 싱크 커넥터로 저장한 뒤 AWS 글루·아테나로 분석 환경을 구축해 전사 데이터 레이크에 연동했으며, 셋째 카프카 스트림즈로 특정 시간·지역의 실시간 라이더 수 같은 집계를 배치 부하 없이 처리했다. EDA와 카프카 기반 파이프라인을 고민하는 이들에게 도움이 되기를 바란다는 말로 마무리한다.