이벤트 소싱 (r1)

이벤트 소싱에서 이벤트는 시스템에서 발생한 과거의 사실을 기록한 불변의 객체이다. 이는 애플리케이션의 상태를 변경시킨 중요한 사건, 예를 들어 '주문 생성됨', '배송지 변경됨', '결제 완료됨' 등을 의미한다. 각 이벤트는 일반적으로 발생한 시점, 관련된 엔티티의 식별자, 그리고 해당 변화를 설명하는 데 필요한 모든 데이터를 포함한다.

이벤트는 단순한 로그가 아니라 시스템의 현재 상태를 구성하는 유일한 근원, 즉 진실의 단일 원천이 된다. 전통적인 방식에서는 최신 상태만 데이터베이스에 저장하지만, 이벤트 소싱에서는 상태 자체를 저장하지 않고 상태를 변화시킨 이벤트들의 시퀀스를 순서대로 저장한다. 이를 통해 애플리케이션의 전체 변경 이력을 완벽하게 재구성할 수 있어 강력한 감사 추적 기능을 제공한다.

이러한 이벤트의 불변성과 순차적 저장 특성은 시간 여행 디버깅을 가능하게 한다. 개발자는 특정 시점의 이벤트 로그까지 재생하여 당시의 시스템 상태를 정확히 복원하고 문제를 진단할 수 있다. 또한, 이벤트는 시스템의 내부 비즈니스 로직을 외부에 노출하는 계약과도 같아, 다른 마이크로서비스나 애널리틱스 시스템이 이를 구독하여 자체 상태를 동기화하는 느슨한 결합된 통합을 구현하는 데 핵심적 역할을 한다.

이벤트는 보통 도메인 주도 설계의 맥락에서 도메인 이벤트로 모델링된다. 이는 비즈니스 도메인 전문가와 소프트웨어 개발자가 공유할 수 있는 보편 언어의 일부가 되어, 복잡한 비즈니스 프로세스와 규칙을 보다 명확하게 코드로 표현하는 데 기여한다.

이벤트 저장소는 이벤트 소싱 아키텍처의 핵심 구성 요소로, 시스템에서 발생한 모든 도메인 이벤트를 순서대로 영구적으로 저장하는 저장소이다. 이 저장소는 시스템의 현재 상태를 직접 저장하는 대신, 상태를 만들어낸 모든 변경 이벤트의 로그를 유일한 진실의 원천으로 삼는다. 이는 전통적인 CRUD 방식의 데이터베이스가 최신 상태만을 덮어쓰는 것과 근본적으로 다르다.

이벤트 저장소는 일반적으로 추가 전용 방식으로 동작하며, 한 번 기록된 이벤트는 불변의 사실로 간주되어 수정되거나 삭제되지 않는다. 각 이벤트는 고유한 식별자와 타임스탬프를 가지며, 특정 애그리게이트나 엔티티와 연관된 이벤트들은 그 식별자를 기준으로 스트림 형태로 묶여 관리된다. 이를 통해 특정 객체의 전체 생명주기에 걸친 모든 상태 변화의 역사를 완전한 감사 추적 형태로 보존할 수 있다.

구현 측면에서 이벤트 저장소는 전용 이벤트 스토어 데이터베이스를 사용하거나, 기존의 관계형 데이터베이스, 문서 데이터베이스, 또는 메시지 브로커를 활용하여 구축할 수 있다. 핵심은 이벤트의 순서를 보장하고, 높은 처리량으로 이벤트를 안정적으로 기록하며, 효율적으로 조회할 수 있는 인터페이스를 제공하는 것이다.

이벤트 저장소의 존재는 시스템의 상태를 필요할 때마다 이벤트 로그의 처음부터 재생하여 재구성할 수 있는 가능성을 열어준다. 이는 과거의 특정 시점으로의 '시간 여행'이 가능케 하여 복잡한 버그의 원인을 분석하는 데 유용하며, 새로운 비즈니스 요구사항에 따라 기존 이벤트에서 완전히 새로운 형태의 프로젝션이나 읽기 모델을 생성하는 유연성을 제공한다.

상태 재구성은 이벤트 소싱에서 애플리케이션의 현재 상태를 얻기 위한 기본 메커니즘이다. 이 패턴에서는 시스템의 현재 상태를 직접 저장하지 않고, 시스템에 발생한 모든 변화를 기록한 이벤트의 시퀀스를 저장한다. 따라서 특정 시점의 상태가 필요할 때는 저장된 이벤트 로그의 처음부터 해당 시점까지의 모든 이벤트를 순차적으로 재생하여 상태를 계산해 낸다. 이 과정을 통해 애플리케이션은 이벤트 저장소에 기록된 불변의 사실들로부터 언제든지 유효한 상태를 생성할 수 있다.

상태 재구성의 핵심은 이벤트를 처리하는 도메인 로직에 있다. 시스템은 각 이벤트 타입에 대해 정의된 상태 전이 함수를 가지고 있으며, 초기 상태(보통 '비어 있음' 또는 '생성됨' 상태)에서 시작하여 관련 이벤트들을 하나씩 적용함으로써 최종 상태에 도달한다. 예를 들어, 주문 관리 시스템에서 '주문 생성', '상품 추가', '결제 완료'라는 이벤트들이 순차적으로 재생되면, 최종적으로 완결된 주문 객체의 상태가 만들어지는 방식이다.

이 접근법은 전통적인 CRUD 모델과 근본적으로 다르다. 전통적 모델에서는 현재 상태만을 덮어쓰며 과거 기록이 소실되기 쉽지만, 상태 재구성을 통한 이벤트 소싱은 모든 상태 변화의 역사가 보존된다. 이는 완전한 감사 추적을 제공하며, 특정 버그가 발생한 정확한 시점의 상태로 시스템을 되돌려 검토하는 '시간 여행 디버깅'을 가능하게 한다. 또한, 새로운 비즈니스 요구사항에 따라 과거 이벤트를 재해석하여 다른 형태의 프로젝션을 생성하는 유연성도 제공한다.

상태 재구성 과정은 성능상의 고려가 필요하다. 시간이 오래되고 이벤트가 많아질수록 매번 처음부터 모든 이벤트를 재생하는 것은 비효율적일 수 있다. 이를 해결하기 위해 주기적으로 특정 시점의 상태 스냅샷을 저장해 두는 방법이 일반적으로 사용된다. 최신 상태를 구성할 때는 가장 최근의 스냅샷부터 이후의 이벤트들만 재생하면 되므로, 재구성에 필요한 시간과 자원을 크게 절약할 수 있다.

명령과 쿼리 책임 분리(CQRS)는 데이터를 변경하는 작업과 데이터를 읽는 작업을 위한 모델을 분리하는 소프트웨어 아키텍처 패턴이다. 이 패턴은 이벤트 소싱과 매우 밀접하게 연관되어 있으며, 종종 함께 사용된다. 전통적인 CRUD 기반 시스템에서는 단일 데이터 모델이 생성, 읽기, 갱신, 삭제 모든 작업에 사용되지만, CQRS는 명령(상태 변경)과 쿼리(상태 조회)를 위한 별도의 책임과 모델을 정의한다.

명령 모델은 도메인 로직을 처리하고 상태를 변경하는 책임을 지며, 이 변경은 불변의 이벤트로 이벤트 저장소에 기록된다. 반면 쿼리 모델은 사용자 인터페이스나 API에 최적화된 형태로 데이터를 제공하는 데 특화된다. 이 두 모델은 물리적으로 같은 데이터베이스를 공유할 수도 있고, 완전히 분리된 저장소를 가질 수도 있다. 이벤트 소싱을 적용할 경우, 쿼리 모델은 이벤트 저장소의 이벤트 스트림을 구독하여 자체적으로 최적화된 뷰를 생성하고 유지한다.

이러한 분리는 시스템의 복잡성을 관리하는 데 큰 이점을 제공한다. 명령 측면에서는 도메인 주도 설계를 적용하여 비즈니스 규칙을 명확하게 구현하는 데 집중할 수 있다. 쿼리 측면에서는 데이터베이스 스키마를 보고에 최적화된 형태로 자유롭게 설계할 수 있어 성능과 확장성을 크게 향상시킬 수 있다. 또한, 읽기와 쓰기 작업의 부하를 독립적으로 확장할 수 있다는 장점도 있다.

그러나 CQRS는 아키텍처의 복잡성을 증가시킨다. 두 개의 모델을 동기화하고 일관성을 유지해야 하며, 특히 이벤트 소싱과 결합할 경우 최종 일관성을 시스템 전반에 수용해야 한다. 따라서 단순한 CRUD 애플리케이션보다는 복잡한 비즈니스 로직을 가진 시스템이나 높은 성능과 확장성이 요구되는 환경에서 더 적합한 패턴으로 평가된다.

이벤트 소싱은 종종 CQRS 패턴과 함께 사용되며, 두 패턴은 상호 보완적인 관계에 있다. CQRS는 명령과 쿼리의 책임을 분리하는 패턴으로, 데이터를 업데이트하는 명령 모델과 데이터를 조회하는 쿼리 모델을 물리적으로 분리한다. 이벤트 소싱은 주로 명령 모델의 상태를 관리하는 데 적합한 저장 메커니즘을 제공한다. 명령 모델에서는 비즈니스 로직을 수행하며 상태 변화를 불변의 이벤트로 기록하고, 이 이벤트 스트림이 시스템의 유일한 진실의 원천이 된다.

이러한 조합에서 쿼리 모델은 이벤트 저장소에서 발생하는 이벤트를 구독하여, 특정 읽기 모델이나 프로젝션을 생성하고 유지한다. 예를 들어, 고객 정보를 표 형태로 보여주는 뷰나 대시보드의 통계 데이터는 이벤트 스트림을 기반으로 실시간으로 구축된다. 이는 명령 측의 복잡한 도메인 모델과 쿼리 측의 단순한 데이터 모델을 독립적으로 최적화하고 확장할 수 있게 해준다. 결과적으로, 쓰기 작업의 성능과 읽기 작업의 성능을 각각의 요구사항에 맞게 독립적으로 조정할 수 있는 장점이 생긴다.

이벤트 소싱과 CQRS를 함께 적용할 때의 주요 이점은 시스템의 유연성과 확장성이다. 명령 모델은 도메인 주도 설계의 원칙을 따르며 복잡한 비즈니스 규칙을 구현하는 데 집중할 수 있고, 쿼리 모델은 사용자 인터페이스나 보고서 생성에 최적화된 다양한 뷰를 자유롭게 생성할 수 있다. 또한, 이벤트 로그를 기반으로 한 감사 추적이 자연스럽게 구현되며, 과거의 특정 시점으로 시스템 상태를 재구성하는 '시간 여행'이 가능해진다.

그러나 이 두 패턴을 결합하면 아키텍처의 복잡성이 상당히 증가한다는 점을 고려해야 한다. 이벤트의 버전 관리, 최종 일관성 모델 처리, 읽기 모델의 유지 보수 등 운영상의 부담이 따르며, 개발 팀이 새로운 패러다임에 익숙해져야 한다. 따라서 트랜잭션 처리와 강한 일관성이 요구되는 시스템이나 단순한 CRUD 애플리케이션에는 불필요한 과도한 설계가 될 수 있다.

이벤트 스토어는 이벤트 소싱 아키텍처의 핵심 구성 요소로, 시스템에서 발생한 모든 도메인 이벤트를 순서대로 영구 저장하는 저장소이다. 이 저장소는 이벤트 로그의 형태를 가지며, 애플리케이션의 현재 상태를 직접 저장하는 대신 상태를 변화시킨 모든 사건의 기록을 유일한 진실의 원천으로 삼는다. 각 이벤트는 불변의 사실로 기록되며, 일반적으로 이벤트 스트림이나 애그리게이트 식별자별로 그룹화되어 저장된다.

이벤트 스토어의 주요 역할은 이벤트의 영속성과 데이터 무결성을 보장하는 것이다. 새로운 이벤트가 추가될 때는 항상 로그의 끝에만 추가되는 추가 전용 방식으로 작동하여 기존 기록을 덮어쓰지 않는다. 이를 통해 시스템의 전체 변경 이력에 대한 완전한 감사 추적이 가능해지며, 과거의 특정 시점으로 상태를 재구성하는 시간 여행이나 디버깅이 용이해진다. 또한, 이벤트 스토어는 이벤트 기반 아키텍처에서 다른 하위 시스템이나 프로젝션이 구독하여 데이터를 동기화할 수 있는 신뢰할 수 있는 소스가 된다.

구현 측면에서 이벤트 스토어는 관계형 데이터베이스, 문서 데이터베이스, 또는 이벤트 저장에 특화된 전용 데이터베이스를 활용하여 구축될 수 있다. 저장된 이벤트를 효율적으로 조회하고 상태를 재구성하기 위해 스냅샷 메커니즘이 함께 사용되기도 한다. 이벤트 스토어는 명령과 쿼리 책임 분리 패턴과 자연스럽게 결합되어, 명령 모델은 이벤트 스토어에 이벤트를 기록하고, 쿼리 모델은 이벤트를 기반으로 생성된 프로젝션을 조회하는 구조를 완성한다.

프로젝션은 이벤트 저장소에 저장된 불변의 이벤트 스트림을 읽어, 애플리케이션이 필요로 하는 특정 형태의 읽기 모델이나 뷰를 생성하고 유지하는 구성 요소이다. 이벤트 소싱 시스템에서 상태는 기본적으로 이벤트의 시퀀스로만 존재하기 때문에, 사용자 인터페이스나 쿼리 처리에 적합한 구조로 변환하는 과정이 필요하다. 프로젝션은 이벤트를 소비하여 데이터베이스 테이블, 문서 저장소의 문서, 인메모리 캐시와 같은 구체적인 읽기 전용 모델을 지속적으로 갱신하는 역할을 담당한다.

하나의 이벤트 스트림으로부터 여러 개의 서로 다른 프로젝션을 생성할 수 있다는 점이 핵심 장점이다. 예를 들어, 동일한 주문 이벤트 스트림을 바탕으로 '고객별 주문 내역' 뷰, '실시간 판매 대시보드' 뷰, '재고 관리' 뷰 등을 각각 독립적으로 구축할 수 있다. 이는 명령과 쿼리 책임 분리 패턴과 자연스럽게 결합되어, 쓰기 작업을 위한 도메인 모델과 다양한 읽기 작업을 위한 최적화된 다중 뷰를 동시에 관리할 수 있게 해준다.

프로젝션의 구현 방식은 크게 동기식과 비동기식으로 나눌 수 있다. 동기식 프로젝션은 명령을 처리하는 동일한 트랜잭션 내에서 이벤트를 발생시키고 즉시 읽기 모델을 갱신한다. 반면, 비동기식 프로젝션은 이벤트가 발행된 후 별도의 프로세스나 서비스가 이를 구독하여 읽기 모델을 최종적 일관성으로 유지한다. 비동기 방식은 시스템의 확장성과 응답성을 높이는 데 유리하며, 이벤트 브로커를 활용하는 이벤트 기반 아키텍처에서 흔히 사용된다.

프로젝션을 설계할 때는 이벤트 스키마 변경에 대한 대응 전략이 중요하다. 기존 이벤트 스트림의 구조가 바뀌면, 영향을 받는 프로젝션을 재처리해야 할 수 있다. 이를 위해 프로젝션은 특정 시점부터 이벤트를 다시 재생할 수 있는 능력을 갖추거나, 스냅샷과 결합하여 초기 상태부터의 완전 재구성을 효율화하는 방안을 고려해야 한다.

이벤트 소싱의 가장 큰 장점은 시스템에서 발생한 모든 상태 변화의 완전한 기록을 이벤트 저장소에 보관한다는 점이다. 이는 변경 불가능한 이벤트 로그를 유일한 진실의 원천으로 삼기 때문에, 누가 언제 무엇을 변경했는지에 대한 완벽한 감사 추적을 가능하게 한다. 이는 금융 거래나 의료 기록과 같이 규제 준수가 중요한 분야에서 특히 가치가 크다.

또한, 저장된 이벤트 스트림을 특정 시점까지 재생함으로써 과거의 어느 순간의 애플리케이션 상태도 정확히 재구성할 수 있다. 이 '시간 여행' 기능은 복잡한 버그의 원인을 추적하는 디버깅이나 특정 비즈니스 질의에 대한 과거 상태 분석에 매우 유용하다. 시스템의 현재 상태뿐만 아니라 상태에 이르기까지의 전체 역사를 보유하게 되는 것이다.

아키텍처적 측면에서 이벤트 소싱은 느슨한 결합된 마이크로서비스나 분산 시스템 간의 통합을 용이하게 한다. 한 시스템이 발행한 이벤트를 다른 시스템이 구독하여 자신의 상태를 업데이트하는 이벤트 기반 아키텍처와 자연스럽게 조화를 이룬다. 이를 통해 시스템 간의 데이터 동기화 문제를 해결하고, 각 서비스가 독립적으로 진화할 수 있는 유연성을 제공한다.

마지막으로, 이 패턴은 복잡한 비즈니스 도메인을 모델링하는 데 강력한 도구가 된다. 도메인 주도 설계와 결합될 때, 비즈니스에서 발생하는 사건을 직접적으로 반영하는 이벤트를 중심으로 도메인 로직을 설계할 수 있어, 모델의 표현력과 유지보수성을 높이는 데 기여한다.

이벤트 소싱은 여러 장점에도 불구하고 몇 가지 명확한 단점과 도전 과제를 지닌다. 가장 큰 단점은 구현과 운영의 복잡성 증가이다. 기존의 CRUD 중심 데이터베이스 접근법에 비해 아키텍처가 복잡해지며, 이벤트 저장소 설계, 이벤트 버전 관리, 프로젝션 유지 관리 등 고려해야 할 요소가 많다. 특히 시스템의 현재 상태를 확인하기 위해 이벤트 스트림을 재생해야 하는 경우, 쿼리 성능이 중요한 애플리케이션에서는 심각한 문제가 될 수 있다.

또한 학습 곡선이 가파르다는 점도 단점으로 꼽힌다. 개발팀이 도메인 주도 설계, 불변성, 이벤트 스토밍 등의 개념을 익혀야 하며, 기존의 상태 중심 사고방식에서 이벤트 중심 사고방식으로의 전환이 필요하다. 이는 프로젝트 초기 비용과 시간을 증가시키는 요인이 된다.

데이터의 최종적 일관성은 또 다른 주요 고려사항이다. 이벤트가 발생하고 프로젝션이 이를 처리해 읽기 모델을 업데이트하기까지 지연이 발생할 수 있어, 사용자에게 즉시 일관된 뷰를 제공하기 어려울 수 있다. 이는 은행 거래나 재고 관리와 같이 강한 일관성이 요구되는 특정 비즈니스 시나리오에서는 제약이 될 수 있다.

마지막으로, 데이터 보관과 관련된 운영 부담이 있다. 불변의 이벤트 로그는 시간이 지남에 따라 방대하게 커질 수 있으며, 이를 영구적으로 저장하고 관리하는 비용이 발생한다. 오래된 이벤트를 아카이브하거나 스냅샷 전략을 통해 상태 재구성 시간을 최적화하는 등의 추가 작업이 필요해진다.

이벤트 버전 관리는 이벤트 소싱 시스템에서 시간이 지남에 따라 이벤트의 구조가 변경될 때 발생하는 문제를 해결하기 위한 중요한 기법이다. 애플리케이션의 요구사항이 진화하면, 저장된 이벤트의 데이터 형식이나 의미도 변경될 수 있다. 이때 새로운 버전의 애플리케이션이 과거의 오래된 형식으로 저장된 이벤트를 올바르게 해석하고 처리할 수 있어야 시스템의 무결성과 일관성을 유지할 수 있다.

버전 관리를 위한 일반적인 접근 방식은 이벤트에 명시적인 버전 번호를 포함시키는 것이다. 이벤트를 직렬화하여 저장할 때 메타데이터의 일부로 버전 정보를 추가하면, 이벤트를 읽어들이는 쪽에서 해당 버전을 식별하고 적절한 방법으로 역직렬화하거나 업그레이드할 수 있다. 버전 변경은 주로 새로운 필드 추가, 기존 필드의 의미 변경, 또는 필드 제거와 같은 경우에 필요하다.

구체적인 버전 업그레이드 전략으로는 업캐스팅이 널리 사용된다. 이는 이벤트 저장소에서 이벤트를 읽은 후, 최신 버전의 형식으로 변환하는 과정을 의미한다. 변환 로직은 이벤트 소비자 측에 위치시켜 저장소의 불변성을 유지하거나, 배치 작업을 통해 저장소 내의 기존 이벤트 자체를 마이그레이션하는 방법도 있다. 또한, 이벤트 스토어에서 직접 이벤트를 제공할 때 요청된 버전에 맞게 변환하여 전달하는 방법도 고려할 수 있다.

효율적인 버전 관리 전략을 수립하지 않으면, 시스템 변경이 어려워지고 상태 재구성 과정에서 오류가 발생할 위험이 크다. 따라서 애플리케이션의 수명 주기 초기부터 이벤트의 진화와 호환성을 고려한 설계가 필수적이다. 이는 장기적으로 감사 로그의 신뢰성과 시간 여행 디버깅의 실용성을 보장하는 기반이 된다.

스냅샷은 이벤트 소싱 시스템에서 성능을 최적화하기 위해 사용되는 기법이다. 애플리케이션의 현재 상태를 재구성하기 위해서는 특정 엔티티의 모든 과거 이벤트를 순차적으로 재생해야 한다. 엔티티의 수명이 길어지고 누적된 이벤트가 많아질수록 이 재생 과정은 시간과 자원을 많이 소모하게 된다. 스냅샷은 특정 시점의 엔티티 상태를 캡처하여 저장함으로써, 상태 재구성을 위한 이벤트 재생의 시작점을 앞당겨 성능 저하를 방지한다.

스냅샷을 생성하는 전략은 다양하다. 가장 일반적인 방법은 특정 수의 이벤트가 누적될 때마다 자동으로 스냅샷을 생성하는 것이다. 예를 들어, 한 애그리게이트에 100개의 이벤트가 쌓일 때마다 100번째 이벤트를 적용한 직후의 상태를 스냅샷으로 저장할 수 있다. 또는, 일정 기간이 지날 때마다 생성하거나, 시스템 부하가 낮은 시간대에 배치 작업으로 생성하는 방식도 사용된다. 스냅샷은 일반적으로 이벤트 저장소에 이벤트와 함께 저장되거나, 별도의 최적화된 저장소에 보관된다.

상태를 조회할 때 시스템은 먼저 해당 엔티티의 최신 스냅샷을 로드한 후, 스냅샷이 캡처된 시점 이후부터 발생한 이벤트들만 재생하여 최신 상태를 계산한다. 이는 처음부터 모든 이벤트를 재생하는 것보다 훨씬 효율적이다. 스냅샷은 성능 향상이라는 명확한 장점을 제공하지만, 구현 시 스냅샷의 직렬화 형식과 버전 관리 전략, 그리고 스냅샷 자체의 저장 및 관리에 대한 부가적인 복잡성이 발생한다는 점을 고려해야 한다.

이벤트 직렬화는 이벤트 소싱 시스템에서 생성된 불변의 이벤트 객체를 데이터베이스나 메시지 브로커에 저장하거나 네트워크를 통해 전송하기 위해 바이트 스트림이나 텍스트 형식으로 변환하는 과정이다. 이벤트는 시스템의 유일한 진실의 원천이므로, 직렬화된 형태는 장기간 안정적으로 보관되고 다양한 시스템에서 읽을 수 있어야 한다.

직렬화 형식으로는 JSON, XML, 프로토콜 버퍼, 아브로 등이 널리 사용된다. 선택 시 고려해야 할 주요 요소는 스키마 진화 지원, 읽기/쓰기 성능, 데이터 크기, 그리고 언어 간 호환성이다. 특히 이벤트 소싱은 이벤트 로그를 영구 보관하는 패턴이므로, 시간이 지나도 이벤트 구조가 변경되더라도 과거 데이터를 여전히 읽을 수 있는 역직렬화 호환성을 보장하는 것이 매우 중요하다.

이벤트 직렬화는 이벤트 저장소의 구현과 밀접한 관련이 있다. 저장소에 기록된 이벤트는 나중에 상태 재구성이나 새로운 프로젝션을 생성할 때 다시 읽혀진다. 또한 CQRS와 결합된 아키텍처에서는 직렬화된 이벤트가 이벤트 버스를 통해 다른 마이크로서비스나 읽기 모델로 전파되기도 한다. 따라서 직렬화 방식은 시스템의 전반적인 성능과 유지보수성에 직접적인 영향을 미친다.