Event Sourcing

일반적인 CRUD 저장소는 지금 값은 잘 보여 주지만 그 값이 어떻게 만들어졌는지는 지워 버립니다. 주문 상태가 왜 취소가 됐는지, 잔액이 어떤 순서로 변했는지, 어느 규칙이 어떤 시점에 적용됐는지는 현재 테이블만 봐서는 복원하기 어렵습니다. 감사 추적, 디버깅, 재처리, 새로운 읽기 모델 생성이 필요해질수록 현재 상태만 저장하는 구조는 점점 답답해집니다.

금융, 정산, 워크플로 시스템처럼 변경 이력 자체가 중요한 도메인에서는 상태 변화의 순서를 잃는 것이 곧 정보 손실이었습니다. 동시에 이벤트 스트리밍과 로그 기반 시스템이 성숙하면서 append-only 저장소를 운영하는 비용도 현실적인 수준으로 내려왔습니다. 이 배경에서 '현재 상태를 저장하는 것'보다 '변화를 기록하는 것'이 더 본질적이라는 관점이 설계로 자리 잡았습니다.

사용자 요청이 들어오면 애그리거트가 현재 이벤트 히스토리를 바탕으로 규칙을 검증하고, 새로운 이벤트를 만들어 이벤트 저장소에 append합니다. 읽기 쪽은 이 이벤트들을 받아 조회에 맞는 projection을 만듭니다. 필요한 경우 오래된 이벤트부터 다시 재생해서 다른 읽기 모델을 만들 수도 있습니다. 즉 쓰기 모델은 이벤트 생성에 집중하고, 읽기 모델은 그 이벤트를 어떻게 보여 줄지에 집중합니다.

Event Sourcing과 CQRS는 자주 같이 등장하지만 같은 개념은 아닙니다. CQRS는 읽기와 쓰기 모델을 분리하는 방식이고, Event Sourcing은 쓰기 쪽의 영속 표현을 이벤트 로그로 택하는 방식입니다. CQRS만 쓰고 현재 상태 저장소를 유지할 수도 있습니다. 단순 CRUD 업무나 이벤트 버전 관리 비용을 감당할 이유가 없는 시스템에서는 Event Sourcing이 과할 수 있습니다.

잔액, 계약 상태, 주문 라이프사이클처럼 변경 이력과 순서 자체가 비즈니스 의미를 가지는 도메인에서 적합합니다. 감사 추적과 재처리, 시점 복원이 중요할수록 장점이 커집니다. 대신 이벤트 스키마 진화, 재생 비용, projection 운영, 중복 처리 같은 추가 책임이 생기므로, 단순히 유행이라서 도입할 구조는 아닙니다.