이벤트 소싱(Event Sourcing)과 CQRS(Command Query Responsibility Segregation) 패턴을 적용하여 시스템을 설계할 경우, 데이터베이스 구조와 운영 방식에 어떤 근본적인 변화가 발생하는지 설명하고, 전통적인 CRUD 기반의 데이터베이스 설계와 비교하여 장단점 및 적합한 사용 사례를 제시하시오.
힌트 · 이벤트 소싱은 상태 대신 이벤트를 저장하고, CQRS는 쓰기 모델과 읽기 모델을 분리하여 데이터베이스를 최적화합니다. 이는 데이터 일관성 모델, 확장성, 감사 가능성에 큰 영향을 미칩니다.
모범답안
이벤트 소싱과 CQRS를 적용하면 데이터베이스 운영 방식에 근본적인 변화가 생깁니다.
먼저 이벤트 소싱은 현재 상태를 직접 저장하는 대신, 시스템에서 발생한 모든 변경 사항을 '이벤트' 형태로 순차적으로 저장합니다. 따라서 데이터베이스는 상태를 나타내는 테이블이 아닌, 시간 순서대로 정렬된 이벤트 스트림을 저장하는 '이벤트 저장소'가 됩니다.
CQRS는 이러한 이벤트 소싱과 결합될 때, 쓰기(Command)와 읽기(Query)를 위한 별도의 모델과 데이터 저장소를 사용합니다. 쓰기 모델은 이벤트 저장소에 이벤트를 기록하는 데 집중하고, 읽기 모델은 쿼리 성능에 최적화된 형태로 데이터를 비정규화하여 저장합니다.
전통적인 CRUD 방식은 단일 데이터베이스에서 상태를 직접 관리하며 일관성을 보장하지만, 복잡한 쿼리나 높은 쓰기/읽기 부하에서 성능 저하가 발생할 수 있습니다.
이벤트 소싱과 CQRS의 장점은 다음과 같습니다.
- 감사 가능성: 모든 변경 이력이 이벤트로 남아 있어 추적이 용이합니다.
- 확장성: 읽기 모델을 독립적으로 확장하여 쿼리 성능을 높일 수 있습니다.
- 복원력: 특정 시점의 상태를 이벤트 스트림으로부터 재구성할 수 있습니다.
- 최종 일관성: 읽기 모델은 쓰기 모델과 분리되어 있어 즉각적인 일관성보다는 최종 일관성을 가집니다.
단점으로는 구현 복잡성이 증가하고, 이벤트 스트림을 읽어 현재 상태를 복원하는 과정이 필요하며, 최종 일관성 모델에 대한 이해가 요구됩니다.
이 패턴은 특히 금융 거래 시스템, 감사 추적이 중요한 시스템, 복잡한 비즈니스 로직을 가진 애플리케이션, 그리고 높은 쓰기/읽기 동시성 요구사항이 있는 경우에 매우 적합합니다.
읽었다면, 이제 직접 답해볼 차례예요
패스잇 앱에서 이 질문에 말로 답하면 AI가 꼬리질문까지 이어가며 1:1 코칭합니다.
함께 보는 데이터베이스 설계 면접 질문
- 기업의 데이터 분석 및 의사결정을 위한 데이터 웨어하우스를 설계해야 합니다. OLTP 시스템과 OLAP 시스템의 데이터 모델링 접근 방식의 근본적인 차이점을 설명하고, 스타 스키마(Star Schema)와 스노우플레이크 스키마(Snowflake Schema)의 장단점을 비교하여 특정 분석 요구사항(예: 복잡한 차원 분석 vs. 저장 공간 최적화)에 따라 어떤 스키마를 선택할지 설계 관점에서 설명하시오.
- 마이크로서비스 아키텍처 환경에서 각 서비스가 독립적인 데이터베이스를 소유하도록 설계할 때 발생할 수 있는 데이터 일관성 및 분산 트랜잭션 문제를 해결하기 위한 데이터베이스 설계 패턴 및 전략(예: Saga 패턴, CQRS, Event Sourcing)을 설명하고, 각 패턴의 장단점과 적용 시나리오를 구체적으로 제시하시오.
- 서비스 운영 중에 데이터베이스 스키마를 변경해야 하는 상황(예: 컬럼 추가/삭제, 타입 변경, 테이블 분리/병합)이 발생했을 때, 무중단 배포(Zero-downtime deployment)를 지원하면서 데이터 정합성을 유지하기 위한 효과적인 스키마 마이그레이션 전략 및 롤백 방안을 설계 관점에서 설명하시오.
- 복잡한 분석 쿼리(예: 다중 조건 조인, 부분 문자열 검색, 공간 데이터 검색)의 성능을 최적화하기 위한 고급 인덱싱 전략을 설명하시오. 특히, 함수 기반 인덱스(Function-Based Index), 부분 인덱스(Partial Index), 커버링 인덱스(Covering Index), 공간 인덱스(Spatial Index) 등의 개념과 실제 적용 사례, 그리고 각 인덱스의 장단점 및 주의사항에 대해 논하시오.