소규모 조직에서 EDA 도전기: Zero Payload에서Full payload로 🚀

오늘은 소규모 조직에서 이벤트 중심 아키텍처(EDA)를 도입하면서 겪은 이야기와 그 과정에서 배운 점들을 공유해보려고 해요. 특히 Zero Payload 방식에서 full payload로 전환하게 된 배경과 그 과정에서 마주한 한계들에 대해 이야기해볼게요. 이 이야기를 통해 비슷한 고민을 하고 있는 분들께 도움이 되길 바라요!

Zero Payload 이벤트, 왜 선택했을까?

EDA를 도입하면서 처음 선택한 방법 중 하나가 Zero Payload였어요. 이게 뭐냐면, 이벤트 자체에 데이터가 첨부되지 않고 단순히 "무언가 일어났다!"라는 신호만 보내는 방식이에요.

Zero Payload의 매력 포인트

• 단순함: 페이로드가 없으니 이벤트 스키마를 정의하거나 관리할 필요가 없어요. 빠르게 움직이는 스타트업에게는 큰 장점이죠.
• 빠른 구현: 소규모 팀에게 Zero Payload는 빠르게 설정할 수 있어서 초기 단계에서 시간과 노력을 절약할 수 있었어요.
• 결합도 낮추기: 이벤트를 소비하는 쪽이 필요한 데이터를 직접 가져오니까, 서비스 간의 결합도가 낮아졌어요.

그런데 문제도 있었죠… 😅

Zero Payload 방식은 정말 간단하고 빠르게 시작할 수 있었지만, 시간이 지나면서 몇 가지 큰 단점들이 보이기 시작했어요. 특히 Single Source of Truth (SSOT)와 Replayability에서 문제가 되었죠.

SSOT의 그림자

SSOT는 모든 데이터가 하나의 소스에서 관리되어 일관성을 유지하는 개념인데요, Zero Payload를 사용하면서 이런 문제가 발생했어요:

• 데이터 호출 오버헤드: 이벤트를 받은 쪽에서 필요한 데이터를 추가로 호출해야 해서 지연 시간이 늘어났어요.
• 일관성 문제: 이벤트 발생 시점과 데이터를 가져오는 시점 사이에 데이터가 변경되면 불일치가 생길 수 있었어요.
• 데이터 스토어 의존도: 데이터 스토어의 가용성과 성능에 의존하게 되어, EDA의 장점인 결합도 낮추기가 무색해졌어요.

Replay의 불가능성

EDA의 큰 장점 중 하나는 이벤트를 재생(replay)해서 시스템 상태를 복구하거나 새로운 서비스를 초기화할 수 있다는 점인데요, Zero Payload는 이걸 불가능하게 만들었어요:

• 재생 불가: 데이터가 없는 이벤트는 시스템 상태를 복원할 수 없어요.
• 감사 기록 부족: 이벤트 발생 당시의 데이터 상태를 알 수 없어서, 감사나 분석에 문제가 생겼어요.

깨달음의 순간: O’Reilly의 책 덕분에 ✨

이런 문제들을 해결하기 위해 고민하던 중, O’Reilly의 "이벤트 기반 마이크로서비스 구축" 책을 읽게 되었어요. 이 책을 통해 EDA의 진정한 잠재력과 함께 Event Payload의 중요성을 깨닫게 되었죠. 덕분에 저희는 Zero Payload에서 벗어나 이벤트에 페이로드를 포함시키는 방향으로 전환하게 되었어요.

페이로드 포함의 매력 🌟

이제 이벤트에 데이터를 담아 보내는 Payload 포함 방식으로 바꾸면서 얻은 장점들을 소개할게요:

• Replay 가능: 모든 이벤트 데이터를 통해 시스템 상태를 재구축하거나 문제를 디버깅할 수 있어요.
• 향상된 결합도 낮추기: 추가 데이터를 가져올 필요가 없어져서 다른 서비스에 대한 의존성이 줄었어요.
• 감사 가능성 향상: 이벤트가 히스토리 로그 역할을 해서 컴플라이언스와 분석에 유용해졌어요.

전환의 도전 과제

물론 페이로드를 포함시키면서 몇 가지 도전도 있었어요:

• 스키마 관리 필요: 이벤트 스키마를 정의하고 유지 관리해야 했어요.
• 데이터 직렬화 처리: 직렬화 형식을 관리하고, 이벤트 구조의 이전 버전과 호환성을 유지해야 했어요.
• 복잡성 증가: 이벤트 생산자와 소비자가 이벤트 구조에 대해 동기화된 상태를 유지해야 해서 복잡해졌어요.

스타트업의 현실: 속도 vs. 완성도

스타트업에서는 자원이 한정되어 있고, 빠르게 시장에 나가는 게 중요한데요. 초기에는 Zero Payload가 정말 좋은 선택이었어요.

허용 가능한 트레이드오프

• 속도 우선: 완벽한 아키텍처보다는 빨리 작동하는 시스템을 만드는 게 더 중요했어요.
• 학습의 기회: 단순한 구조 덕분에 EDA의 기본 원칙을 배우고 적응하는 데 집중할 수 있었어요.

장기적인 비전

하지만 시스템이 성장하면서 초기의 트레이드오프가 확장성과 유지보수성을 저해하기 시작했어요. 그래서 full payload 이벤트로 전환하는 것이 필요했죠. 이건 단순한 기술적 변화가 아니라, 우리의 아키텍처를 더 견고하게 만드는 중요한 투자였어요.

마무리하며 🎯

EDA를 도입하면서 Zero Payload에서 시작해 여러 도전과 한계를 겪었지만, O’Reilly의 책 덕분에 중요한 깨달음을 얻고 페이로드 포함 방식으로 전환할 수 있었어요. 이 과정에서 배운 점들은 우리 시스템을 더 견고하고 확장 가능하게 만들어줬고, 앞으로의 성장에도 큰 도움이 될 거라 믿어요.

비슷한 고민을 하고 있는 스타트업 분들께 조언을 드리자면, 초기의 단순함과 빠른 속도도 중요하지만, 장기적인 확장성과 유지보수성을 함께 고민하는 것이 중요해요. Zero Payload가 빠른 시작을 가능하게 하지만, 그에 따른 트레이드오프를 이해하고 필요할 때 적절히 트레이드 오프를 고려하시길.. ㅎㅎ