Event Log 데이터 모델링
3줄 요약
Event Log 데이터 모델링 챕터는 현재 상태가 아니라 실제로 발생한 사건을 이벤트 로그로 남기고 스키마, 순서, 호환성을 관리한다.- 목표는 Kafka 메시지 모양을 예쁘게 만드는 것이 아니라, 재처리 가능한 사건 기록과 consumer가 오래 사용할 수 있는 계약을 설계하는 것이다.
- Java/Spring 백엔드 개발자는 state 변경 코드에서 어떤 domain event가 발생하고, 어떤 integration event가 downstream으로 나가는지 설명할 수 있어야 한다.
핵심 정리
Event와 State 차이: state는 현재 결과이고 event는 그 결과에 도달한 사건이다. 파이프라인은 대개 state보다 event를 더 잘 재처리한다.Event Schema 설계: event schema는 producer와 consumer 사이의 계약이다. 필드 이름보다 event 의미, key, version, 발생 조건이 중요하다.Event Versioning과 Compatibility: event는 이미 소비자가 존재하므로 마음대로 바꿀 수 없다. 새 필드는 호환적으로 추가하고 의미 변경은 새 version으로 분리한다.Audit Log와 Domain Event 차이: audit log는 누가 언제 무엇을 했는지 추적하고, domain event는 비즈니스 사건을 downstream 처리에 전달한다.이벤트 모델링 실수와 리뷰 기준: 좋은 이벤트 리뷰는 이름이 예쁜지보다 재처리 가능한 key, 발생 조건, 취소/삭제 표현, schema 호환성을 본다.- 이 챕터의 모든 문서는 Web-Database의 OLTP 판단을 넘어, 데이터 이동과 재처리 가능성을 중심으로 읽어야 한다.
헷갈리는 지점
- state 변경 내역을 그대로 event라고 보기 쉽다.
status=PAID는 현재 상태이고 OrderPaid는 발생한 사건이다.- 상태만 남기면 어떤 일이 어떤 순서로 일어났는지 재처리하기 어렵다.
- event schema를 DTO처럼 마음대로 바꿔도 된다고 오해하기 쉽다.
- event는 이미 저장되고 소비된 계약이므로 필드 삭제와 의미 변경이 consumer를 깨뜨릴 수 있다.
- 새 필드는 호환적으로 추가하고 의미 변경은 새 event 또는 version으로 분리해야 한다.
- audit log와 domain event를 같은 로그로 처리하기 쉽다.
- audit log는 추적과 감사 목적이고, domain event는 downstream 처리를 위한 비즈니스 사건이다.
- 두 목적을 섞으면 개인정보, 보관 기간, consumer 계약이 모두 애매해진다.
확인 질문
- 이 챕터의 핵심 판단 기준은 무엇인가?
- 현재 상태와 발생 사건을 구분하고, event id, aggregate id, occurredAt, version, 취소/삭제 표현을 명확히 하는 것이다.
- Web-Database와의 경계는 무엇인가?
- Web-Database는 상태를 저장하고 조회하는 DB 설계 중심이고, 이 챕터는 그 상태 변화가 event log로 이동할 때의 계약과 호환성 중심이다.
- 개인 프로젝트에서 최소로 챙길 것은 무엇인가?
- event table, event id, aggregate id, event type, version, payload, 발행 여부, 간단한 consumer 처리 이력이다.