문제 20 — 이벤트 소싱(Event Sourcing)과 CQRS

많은 게임/거래 서버는 "현재 상태"만 저장하는 대신, 상태를 바꾼 사건(event)들의 로그를 저장하고 그것으로 현재 상태를 재구성한다. 이벤트 소싱과 CQRS(Command Query Responsibility Segregation)의 개념·장단점·게임 서버 적용을 설명하라.

다음을 포함해 답하라.

1. 핵심 개념: 상태 저장(state-oriented) 방식과 이벤트 소싱의 차이. "현재 잔액 100" 을 저장하는 것과 "입금 60, 입금 40" 이벤트를 저장하고 접어서(fold) 잔액을 얻는 것의 차이를 설명하라. 이벤트가 불변(append-only) 이라는 점의 함의도 다뤄라.

2. 재구성·스냅샷: 이벤트가 수백만 개면 매번 처음부터 접는 것이 비싸다. 스냅샷(snapshot) 으로 어떻게 최적화하는지, 스냅샷 이후 이벤트만 재생하는 방식을 설명하라.

3. CQRS: 쓰기 모델(커맨드 → 이벤트 생성)과 읽기 모델(조회용 프로젝션/뷰)을 분리하는 이유. 이벤트로부터 여러 읽기 뷰(리더보드, 인벤토리, 통계)를 프로젝션으로 파생시키는 방식과, 읽기 모델이 쓰기보다 약간 뒤처지는 최종 일관성(eventual consistency) 의 트레이드오프를 논하라.

4. 게임 서버에서의 이점: 감사(audit)·치팅 조사, 리플레이/관전, 버그로 잘못된 상태를 이벤트 재생으로 복구, 시간여행 디버깅. 왜 "무슨 일이 있었는지"가 게임/경제 서버에서 중요한지 설명하라.

5. 함정과 한계: 이벤트 스키마 진화(옛 이벤트 버전 호환), 이벤트가 곧 계약이라 삭제/수정 불가, GDPR 등 삭제 요구와의 충돌, 프로젝션 재빌드 비용, 과도한 도입의 복잡성. 언제 이벤트 소싱이 과한 선택인지도 논하라.