우아콘 2022 회원 시스템 이벤트 아키텍처: 3개 계층과 Outbox 학습 노트

2022년 우아콘의 ‘회원시스템 이벤트 기반 아키텍처 구축하기’를 본 뒤 남긴 학습 노트다. 당시 차세대 프로젝트에서 MSA와 이벤트 기반 아키텍처를 다루고 있었고, Java·Spring과 Kafka 기반 구조를 이해하려는 목적이 있었다.

발표는 “메시지 브로커를 쓰면 곧 느슨하게 결합된다”는 단순한 설명에서 출발하지 않는다. 발행자가 구독자에게 해야 할 일을 명령하면 물리적 호출은 사라져도 상대 도메인의 정책을 계속 알아야 한다. 발표가 강조한 기준은 구독자의 목적이 아니라, 발행 도메인에서 실제로 일어난 사건을 이벤트로 표현하는 것이었다.

우아콘 2022 발표의 회원 시스템 이벤트 계층도 (출처: 우아한형제들 기술블로그)

세 종류의 이벤트와 구독 계층

회원 시스템은 이벤트를 세 층으로 나눴다.

1. 애플리케이션 이벤트: 한 애플리케이션 안에서 도메인의 핵심 행위와 부가 관심사를 분리한다. 필요한 경우 원래 트랜잭션의 범위를 공유한다.
2. 내부 이벤트: 시스템 내부 구독자가 처리에 필요한 데이터를 담을 수 있는 열린 이벤트다. 발행 측이 내부 구독자의 변화를 파악하고 관리할 수 있다는 전제가 있다.
3. 외부 이벤트: 다른 시스템과의 결합을 줄이기 위해 형식을 닫아 둔다. 식별자, 행위, 바뀐 속성, 발생 시각처럼 일반화한 정보만 전달하고 추가 데이터는 수신 측이 API로 조회하는 ZERO-PAYLOAD 방식을 택했다.

이 구분은 모든 조직이 따라야 할 표준이 아니라 해당 회원 시스템이 결합도와 운영 요구를 풀기 위해 선택한 설계다. 특히 ZERO-PAYLOAD는 메시지가 작아진다는 장점만 있는 것이 아니다. 구독자가 최신 상태를 다시 조회해야 하므로 조회 API의 가용성, 이벤트 시점의 상태가 필요한 경우, 순서와 경합을 함께 검토해야 한다.

도메인 변경과 이벤트 레코드를 함께 저장하는 Outbox 구조 (출처: 우아한형제들 기술블로그)

이벤트 저장소와 Transactional Outbox

애플리케이션 트랜잭션이 끝난 뒤 SNS 발행이 실패하면 도메인 변경은 반영됐지만 이벤트가 사라질 수 있다. 발표에서는 도메인 데이터와 이벤트 레코드를 같은 RDBMS의 로컬 트랜잭션에 저장하고, 발행 여부와 시각을 기록한 뒤 미발행 이벤트를 배치로 재발행했다. 특정 회원·행위·속성·기간으로 이벤트를 찾을 수 있게 해 운영 중 재처리 요구도 해결했다.

이 접근이 Transactional Outbox 패턴과 닿아 있다. 중요한 경계는 ‘발행 보장’을 정확히 한 번 처리된다는 뜻으로 읽지 않는 것이다. AWS의 Outbox 안내도 표준 SQS에서는 같은 메시지가 두 번 이상 전달될 수 있으므로 소비자를 멱등하게 설계해야 한다고 명시한다.

• 원 발표 정리: 우아한형제들 기술블로그, 회원시스템 이벤트기반 아키텍처 구축하기
• 패턴 경계: AWS Prescriptive Guidance, Transactional outbox pattern

이 세션에서 남은 판단 기준

• 이벤트 이름이 구독자에게 명령하는 문장인지, 발행 도메인에서 일어난 사실인지 확인한다.
• 트랜잭션 커밋과 메시지 발행 사이의 실패 구간을 그린다.
• 재시도만 넣지 말고 중복 처리와 순서 역전의 영향을 확인한다.
• 이벤트 저장소의 쓰기량, 보존 기간, 재발행 권한과 개인정보 접근 통제를 운영 항목으로 둔다.
• 내부 이벤트와 외부 계약을 같은 변경 규칙으로 다루지 않는다.

초고의 “이벤트 저장소가 곧 MSA의 데이터 정합성을 높인다”는 결론은 너무 넓었다. 이 발표에서 배운 핵심은 도구 이름보다 실패 지점과 결합의 방향을 먼저 드러내고, 그 요구에 맞춰 계층과 저장 방식을 선택해야 한다는 것이다.