Event Sourcing이 탄력적인 배달 시스템 구축에 대해 우리에게 가르쳐 준 것

Source: Dev.to

위에 제공된 소스 링크 외에 번역할 텍스트가 포함되어 있지 않습니다. 번역을 원하는 본문을 제공해 주시면 한국어로 번역해 드리겠습니다.

몇 년 전, 저는 대규모 지속적 배포 시스템에서 이벤트 소싱을 적용한 방법을 설명하는 두 부분 시리즈를 공동 저술했습니다. 그 기사들은 우리가 만든 것과 아키텍처가 실제로 어떻게 작동했는지에 초점을 맞췄습니다.

이 글은 다릅니다.

이벤트 소싱의 메커니즘을 다시 살펴보는 대신, 저는 시간이 지나면서 시스템 설계, 운영 탄력성, 그리고 아키텍처 선택이 팀의 사고와 작업 방식을 어떻게 형성하는지에 대해 이 경험이 우리에게 가르쳐준 점을 되돌아보고 싶습니다. 이러한 교훈은 다이어그램이나 프레임워크에서 나온 것이 아니라, 실제 제약 하에서 실제 시스템을 운영하면서 얻은 것입니다.

이벤트 소싱은 규모만이 아니라 인지 부하에 관한 것이다

이벤트 소싱은 종종 확장성이나 처리량 측면에서 논의됩니다. 이러한 이점도 실제이지만, 가장 중요한 것은 아니었습니다.

가장 중요한 것은 인지 부하였습니다.

복잡한 전달 시스템에서는 알고리즘이 단독으로 잘못되어 발생하는 오류는 드뭅니다. 오류는 여러 사건이 시간적으로 가깝게, 시스템 경계를 넘어 동시에 발생하고, 엔지니어가 부분적인 상태, 불완전한 로그, 불명확한 인과 관계를 추론해야 할 때 일어납니다. 이런 순간에 어려운 것은 코드를 작성하는 것이 아니라 불확실성 속에서 명확하게 사고하는 것입니다.

사실(이벤트), 상태 재구성, 반응을 별개의 관점으로 분리함으로써 이벤트 소싱은 그 부담을 줄였습니다. 엔지니어는 더 간단하고 정확한 질문을 할 수 있었습니다:

• 실제로 무슨 일이 일어났는가?
• 어떤 순서로 일어났는가?
• 시스템은 그때 그 사실들을 어떻게 해석했는가?

그 명확성은 순수한 성능 최적화보다 훨씬 더 중요한 가치였습니다.

시간과 상태가 복잡성의 진정한 원인

대부분의 분산 시스템은 비즈니스 로직 때문에 복잡한 것이 아니라 시간과 상태가 미묘하게 상호작용하기 때문에 복잡합니다.

전통적인 CRUD 기반 시스템은 히스토리를 하나의 가변 스냅샷으로 압축하는 경향이 있습니다. 이는 현재 상태를 읽기 쉽게 만들지만, 과거를 이해하기는 어렵거나 불가능하게 합니다. 문제가 발생했을 때, 팀은 권위 있는 설계가 아닌 로그에서 의도를 재구성해야 합니다.

이벤트 소싱은 다른 사고 모델을 강요합니다: 현재는 저장되는 것이 아니라 파생됩니다. 상태는 히스토리를 대체하는 것이 아니라 히스토리에 대한 해석이 됩니다.

이러한 전환은 팀이 문제를 디버깅하는 방식을 바꿉니다. 시스템이 특정 상태에 도달했을 것이라고 추측하는 대신, 실제로 어떻게 진행됐는지를 재생할 수 있습니다. 시간이 지나면서 가정이 줄어들고, 사고 후 분석이 개선되며, 교정 조치에 대한 신뢰도가 높아집니다.

아키텍처가 조직 행동을 형성한다

보다 미묘한 교훈 중 하나는 아키텍처가 행동에 얼마나 강력하게 영향을 미치는가 하는 점이다—시스템뿐 아니라 팀에도 마찬가지다.

역사가 보존되고 상태 전이가 명시될 때, 대화 방식이 바뀐다. 엔지니어들은 의견 논쟁을 멈추고 사실을 검토하기 시작한다. 운영 리뷰는 비난보다 이해에 초점을 맞추게 된다. 팀은 events, transitions, invariants에 대한 공동 언어를 형성한다.

실제로 이것은 다음과 같은 결과를 낳았다:

• “유령 버그” 감소
• 재현 불가능한 이슈 감소
• 조직 기억에 대한 의존도 감소

신입 엔지니어도 이전 사건을 모두 겪어보지 않아도 시스템 행동을 추론할 수 있게 되었다. 이러한 효과는 우연이 아니라, 시스템 행동을 설계 단계에서 관찰 가능하고 설명 가능하도록 만든 직접적인 결과이다.

이벤트 소싱이 적합하지 않은 경우

이벤트 소싱은 보편적인 해결책이 아니며, 이를 보편적인 해결책으로 간주하는 것은 실수이다. 실제 비용을 초래한다:

• 개념적 복잡성 증가
• 추가 인프라 및 도구 필요
• 이벤트‑드리븐 모델에 익숙하지 않은 팀을 위한 학습 곡선

상태 전이가 단순하고, 감사 요구사항이 낮으며, 동시성이 제한된 시스템에서는 이러한 트레이드‑오프가 정당화되지 않을 수 있다. 더 간단한 모델이 더 효과적이고 유지 관리가 쉬울 수 있다.

패턴을 적용하지 말아야 할 위치를 인식하는 것은 패턴이 빛을 발하는 위치를 이해하는 만큼 중요하다. 이벤트 소싱은 정확성, 추적 가능성, 장기적인 진화 가능성이 즉각적인 단순성보다 중요한 시스템에서 그 가치를 발휘한다.

유지된 점과 다르게 할 점

돌아보면, 핵심 원칙들은 잘 유지되었습니다. 불변의 히스토리를 보존하고, 관심사를 분리하며, 이벤트로부터 상태를 재구성하는 것이 주변 기술이 발전함에도 견고함을 입증했습니다.

더 많은 반복이 필요했던 것은 도구와 개발자 경험이었습니다. 초기 구현은 종종 모든 팀이 갖추고 있지 않은 함수형 또는 이벤트‑주도 사고에 대한 친숙함을 전제로 했습니다. 명확한 추상화, 강력한 규칙, 그리고 좋은 문서는 기본 아키텍처만큼이나 중요하다는 것이 드러났습니다.

오늘 다시 시작한다면, 우리는 그 지원 요소들에 더 일찍 투자했을 것입니다—패턴 자체가 결함이 있어서가 아니라, 채택이 정확성만큼이나 사용성에 좌우되기 때문입니다.

왜 이 교훈들은 여전히 중요한가

시스템이 점점 더 상호 연결되고 신뢰성에 대한 기대가 높아짐에 따라, 시스템 동작을 오해하는 비용이 급격히 상승합니다. 역사를 보존하고 상태 전환을 명시적으로 만드는 아키텍처는 특히 감사 가능성, 신뢰, 운영 명확성이 중요한 분야에서 장기적인 시스템의 기반을 제공합니다.

이벤트 소싱은 새로운 것이 아니라, 시간이 중요함, 역사가 중요함을 인식하고, 시스템이 이러한 현실을 숨기지 않고 명시적으로 드러내야 한다는 점에 관한 것입니다.

실제로 적용하면서 얻은 가장 지속적인 교훈은 바로 명확성은 복합적인 효과를 만든다는 것입니다. 시간이 지남에 따라 투명성과 논리를 중시하는 아키텍처는 시스템 동작뿐만 아니라 팀이 소프트웨어를 구축하고 운영하며 진화시키는 방식에서도 큰 이익을 가져다줍니다.

링크

• 파트 1: Event Sourcing at Scale: Connecting the Dots for a Better Future
• 파트 2: Event Sourcing at Scale: Continuous Delivery in Practice

독립적인 보도

이 작업과 그 동반 기사들은 InfoQ에 의해 독립적으로 요약되었으며, InfoQ는 대규모 지속적 배포 시스템에서 이벤트 소싱의 적용을 조사했습니다.

Event Sourcing at eBay – InfoQ

여기에 표현된 의견은 저 개인의 것이며 현재 혹은 이전 고용주의 입장을 대변하지 않습니다.