패스잇
시스템 설계 · 심화

이벤트 소싱(Event Sourcing)과 CQRS(Command Query Responsibility Segregation) 패턴을 적용하여 시스템을 설계할 경우, 데이터베이스 구조와 운영 방식에 어떤 근본적인 변화가 발생하는지 설명하고, 전통적인 CRUD 기반의 데이터베이스 설계와 비교하여 장단점 및 적합한 사용 사례를 제시하시오.

힌트 · 이벤트 소싱은 상태 대신 이벤트를 저장하고, CQRS는 쓰기 모델과 읽기 모델을 분리하여 데이터베이스를 최적화합니다. 이는 데이터 일관성 모델, 확장성, 감사 가능성에 큰 영향을 미칩니다.

이벤트 저장소비정규화최종 일관성명령 모델쿼리 모델

모범답안

이벤트 소싱과 CQRS를 적용하면 데이터베이스 운영 방식에 근본적인 변화가 생깁니다.

먼저 이벤트 소싱은 현재 상태를 직접 저장하는 대신, 시스템에서 발생한 모든 변경 사항을 '이벤트' 형태로 순차적으로 저장합니다. 따라서 데이터베이스는 상태를 나타내는 테이블이 아닌, 시간 순서대로 정렬된 이벤트 스트림을 저장하는 '이벤트 저장소'가 됩니다.

CQRS는 이러한 이벤트 소싱과 결합될 때, 쓰기(Command)와 읽기(Query)를 위한 별도의 모델과 데이터 저장소를 사용합니다. 쓰기 모델은 이벤트 저장소에 이벤트를 기록하는 데 집중하고, 읽기 모델은 쿼리 성능에 최적화된 형태로 데이터를 비정규화하여 저장합니다.

전통적인 CRUD 방식은 단일 데이터베이스에서 상태를 직접 관리하며 일관성을 보장하지만, 복잡한 쿼리나 높은 쓰기/읽기 부하에서 성능 저하가 발생할 수 있습니다.

이벤트 소싱과 CQRS의 장점은 다음과 같습니다.

  • 감사 가능성: 모든 변경 이력이 이벤트로 남아 있어 추적이 용이합니다.
  • 확장성: 읽기 모델을 독립적으로 확장하여 쿼리 성능을 높일 수 있습니다.
  • 복원력: 특정 시점의 상태를 이벤트 스트림으로부터 재구성할 수 있습니다.
  • 최종 일관성: 읽기 모델은 쓰기 모델과 분리되어 있어 즉각적인 일관성보다는 최종 일관성을 가집니다.

단점으로는 구현 복잡성이 증가하고, 이벤트 스트림을 읽어 현재 상태를 복원하는 과정이 필요하며, 최종 일관성 모델에 대한 이해가 요구됩니다.

이 패턴은 특히 금융 거래 시스템, 감사 추적이 중요한 시스템, 복잡한 비즈니스 로직을 가진 애플리케이션, 그리고 높은 쓰기/읽기 동시성 요구사항이 있는 경우에 매우 적합합니다.

읽었다면, 이제 직접 답해볼 차례예요

패스잇 앱에서 이 질문에 말로 답하면 AI가 꼬리질문까지 이어가며 1:1 코칭합니다.

함께 보는 데이터베이스 설계 면접 질문

← 데이터베이스 설계 면접 질문 전체 보기