“필요한 건 큐인데 스트림 1만 개를 만들고 있다” 크리스 사이먼, 카프카 오용 문제 지적

크리스 사이먼은 과거에는 앨라니스 모리세트의 노래 'Ironic'에 대해 회의적인 시각을 가지고 있었으나, 시간이 지나면서 생각이 바뀌었다고 언급했습니다. 그는 현재 앨라니스가 아이러니라는 개념을 누구보다도 깊이 이해하고 표현했다고 믿게 되었다고 밝혔습니다. 이는 강연의 전반적인 주제인 '큐와 스트림의 혼동'이 얼마나 아이러니한 상황인지 빗대어 설명하려는 의도로 보입니다.

오늘 강연의 핵심 주제는 기술 선택의 아이러니, 즉 필요한 도구와 사용되는 도구 사이의 괴리를 다룰 것임을 암시했습니다.

이벤트 스토밍(Event Storming) 과정에서 개발자들이 자주 혼동하는 부분이 바로 ‘이벤트’와 ‘명령’의 구분이라고 크리스 사이먼은 지적했습니다. 이벤트는 시스템에서 발생한 ‘과거의 사실’을 나타내는 반면, 명령은 시스템이 수행해야 할 ‘미래의 의도’를 의미합니다.

이 두 개념을 명확히 구분하는 것은 이벤트 중심 아키텍처(EDA) 설계의 기본이자 핵심 요소입니다. 혼동할 경우 시스템의 동작 방식과 데이터 흐름을 잘못 이해하게 되어 예측 불가능한 결과를 초래할 수 있습니다.

크리스 사이먼은 이벤트 중심 아키텍처(EDA)가 결합(coupling)의 방향을 근본적으로 바꾼다고 설명했습니다. 전통적인 시스템에서는 서비스 간에 직접적인 의존성이 존재하여 강한 결합이 발생하지만, EDA에서는 발행자(publisher)가 특정 구독자에 대해 알 필요가 없도록 설계됩니다.

결과적으로 발행자는 아무런 서비스와도 직접적으로 결합되지 않으며, 오직 구독자(subscriber)만이 발행자에 종속되는 형태가 됩니다. 이는 결합을 완전히 없앤 것이 아니라, 그 방향성을 재정의하여 시스템의 유연성을 높이고자 하는 EDA의 핵심 원리입니다.

크리스 사이먼은 '주문 제출됨(order submitted)'이라는 이벤트를 예시로 들며, 이 하나의 이벤트를 처리하는 방식에 대해 개발자들 사이에서 다양한 관점이 존재한다고 언급했습니다. 그는 이 이벤트를 접했을 때 즉시 아파치 카프카(Apache Kafka) 토픽으로 생각하는 부류가 있다고 설명했습니다. 이는 카프카가 대용량 이벤트 처리에 널리 사용되기 때문입니다.

다른 개발자들은 큐 기반의 발행-구독(publish-subscribe) 시스템을 떠올릴 수 있습니다. 이는 메시지 큐의 기본적인 역할에 집중하는 관점입니다. 또한, 이벤트 소싱(Event Sourcing)과 이벤트 스토어(Event Store) 개념을 연관 지어 생각하는 그룹도 있다고 밝혔습니다. 이 세 가지 접근 방식은 각각 다른 기술 스택과 아키텍처적 사고방식을 반영하며, 본 강연의 핵심 논의가 이들의 장단점과 올바른 적용에 초점을 맞출 것임을 시사합니다.

이러한 다양한 시각은 각 기술의 본질과 목적에 대한 개발자들의 혼란을 보여주는 사례로 제시되었습니다. 강연은 이러한 혼동을 해소하고 각 기술이 어떤 상황에 적합한지 명확히 하는 데 목적이 있습니다.

크리스 사이먼은 '발행(publishing)'과 '구독(subscribing)'이라는 용어가 주로 비즈니스 개념이나 도메인 아이디어를 설명할 때 사용된다고 설명했습니다. 이는 시스템의 고수준 추상화, 즉 비즈니스 로직과 관련된 이벤트 흐름을 나타낼 때 적합합니다.

반면, '생산자(producer)'와 '소비자(consumer)'라는 용어는 런타임 문제와 실제 시스템 구현에 더 가깝다고 언급했습니다. 이는 메시지가 물리적으로 생성되고 소비되는 방식, 즉 시스템의 낮은 수준의 동작을 다룰 때 사용되는 개념입니다. 이 두 용어의 명확한 구분이 없으면 아키텍처 설계 단계에서 혼란을 야기할 수 있습니다.

크리스 사이먼은 아파치 카프카(Apache Kafka)가 상태(state)를 관리한다는 오해를 바로잡았습니다. 많은 사람이 카프카에 메시지가 저장되므로 카프카 자체가 상태를 관리한다고 생각하지만, 실제로는 메시지를 소비하는 주체인 소비자가 상태를 관리합니다.

그는 분산 로그 소비자는 상태를 가진(stateful) 소비자이며, 큐는 상태가 없는(stateless) 소비자라고 설명했습니다. 스트림 소비자가 상태를 가진다는 것은 상태가 카프카에 저장되는 경우가 많다는 것을 의미하는데, 이때 사람들은 카프카가 상태를 관리한다고 혼동하게 된다는 것입니다. 하지만 실제 상태는 소비자가 스스로 추적하고 관리하는 것입니다.

크리스 사이먼은 컨플루언트(Confluent)가 아파치 카프카를 '움직이는 데이터(data in motion)'라고 광고하는 방식에 대해 아이러니하다고 비판했습니다. 그는 이러한 표현이 실제로는 스트림보다 큐(Queue) 시스템에 훨씬 더 정확하게 적용된다고 주장했습니다. 스트림에서는 데이터가 일단 큐에 들어가면 그곳에 머물러 움직이지 않으며, 다른 소비자가 능동적으로 데이터를 가져가야 하기 때문입니다.

반면, 큐 시스템에서는 데이터가 큐에 들어가고 소비자에 의해 처리된 후에는 큐에서 삭제됩니다. 이는 데이터가 큐를 '통과하며 이동'하는 개념에 더 부합합니다. 따라서 카프카를 '움직이는 데이터'로 광고하는 것은 그 본질적인 작동 방식과 맞지 않으며, 개발자들에게 혼란을 줄 수 있다는 지적입니다. 이러한 광고 문구는 큐와 스트림의 역할을 혼동하게 만드는 한 요인이 될 수 있음을 강조했습니다.

분산 로그 시스템에서 저수준 소비자(low-level consumer)를 사용할 때 메시지 중복 처리 문제가 발생할 수 있다고 크리스 사이먼은 설명했습니다. 메시지가 동일한 분산 로그 파티션에 할당되면, 동일 서비스의 여러 인스턴스가 메시지를 두 번 읽을 위험이 있다는 것입니다.

이는 일반적으로 개발자들이 원하는 동작이 아닙니다. 대부분의 경우 메시지가 단 한 번만 처리되기를 원하기 때문입니다. 특히 상태를 공유하는 분산 시스템에서는 이러한 중복 처리가 심각한 문제를 야기할 수 있으며, 고수준 소비자 라이브러리 없이는 이 문제를 해결하기 어렵다고 지적했습니다.

크리스 사이먼은 큐잉 시스템과 분산 로그(스트림) 시스템의 확장 방식에 본질적인 차이가 있다고 강조했습니다. 큐잉 시스템의 경우, 클러스터에 새로운 노드를 추가하는 즉시 해당 노드가 메시지 처리 용량을 증가시키는 데 기여합니다. 이는 시스템의 처리량을 유연하게 확장할 수 있게 해주는 장점입니다.

하지만 분산 로그 시스템에서는 새로운 노드를 추가하더라도, 파티션을 수동으로 재할당하기 전까지는 추가된 노드가 유휴 상태로 남아있게 됩니다. 즉, 자동으로 처리 용량이 증가하지 않고 개발자의 명시적인 개입이 필요하다는 의미입니다. 이러한 차이점은 각 시스템이 설계된 목적과 사용 시나리오를 명확히 이해하는 데 중요한 요소입니다.

크리스 사이먼은 메시지 처리 실패 시 큐잉 시스템과 분산 로그 시스템이 대처하는 방식의 큰 차이를 설명했습니다. 큐잉 시스템, 예를 들어 래빗MQ(RabbitMQ)와 같은 브로커는 특정 메시지 처리 시도 횟수를 기록하고, 설정된 횟수를 초과하면 해당 메시지를 자동으로 Dead Letter Queue(DLQ)로 전달합니다. DLQ는 실패한 메시지를 격리하여 다른 시스템이 이를 추적하고, 알람을 발생시키며, 수동으로 처리하거나 나중에 다시 큐에 넣어 재처리할 수 있도록 합니다. 이는 메시지의 손실을 방지하고 워크플로의 안정성을 높이는 데 중요한 기능입니다.

반면, 분산 로그 시스템에서는 메시지 처리 실패 시 이러한 자동화된 메커니즘이 기본적으로 제공되지 않습니다. 특정 메시지가 중요하다고 판단되어 반복적으로 처리 시도했지만 여전히 실패하는 경우, 개발자가 명시적으로 수동 개입하여 해당 메시지를 처리해야 합니다. 이는 분산 로그가 주로 데이터의 순서 보장과 저장에 초점을 맞추고 있으며, 개별 메시지의 라이프사이클 관리에는 덜 최적화되어 있음을 보여줍니다. 결과적으로 분산 로그를 사용할 때는 실패 메시지 처리에 대한 추가적인 설계와 구현이 필요하게 됩니다.

크리스 사이먼은 스트림 시스템에서 명령(Command)을 처리할 때 발생하는 문제점과 '명령 이벤트(Command Event)'라는 용어에 대한 비판적 시각을 제시했습니다. 큐 시스템에서는 특정 명령을 처리할 수 있는 서비스에 직접 메시지를 보내는 것이 가능하지만, 스트림에서는 모든 것이 토픽(Topic)이라는 개념으로 통합됩니다.

이로 인해 명령 메시지가 토픽에 들어가게 될 때, 해당 메시지가 명령이며 단 하나의 소비자(consumer)만 처리해야 한다는 것을 명시하거나 명확히 할 수 있는 고유한 방법이 부족합니다. 이는 명령의 단일 처리 보장을 어렵게 만듭니다. 그는 컨플루언트(Confluent) 문서에서 토픽 내 메시지를 '명령 이벤트'라고 부르는 것에 대해 강하게 비판하며, 명령과 이벤트는 완전히 다른 개념이므로 명확히 구분해야 한다고 강조했습니다.

명령은 어떤 행동을 요청하는 것이고, 이벤트는 이미 발생한 사실을 알리는 것이므로, 이 둘을 혼용하는 것은 시스템의 의미론적 명확성을 해치고 혼란을 가중시킬 수 있다는 주장입니다.

크리스 사이먼은 큐와 스트림 시스템 간의 기록 메시지 저장 및 접근 방식 차이를 설명했습니다. 카프카와 같은 스트림 시스템에서는 브로커가 메시지를 저장하며, 이는 이벤트 로그의 전체 기록을 보관하여 나중에 다른 서비스를 시작하고 처음부터 메시지를 다시 재생할 수 있다는 점에서 개발팀에게 매우 매력적인 특징입니다.

반면, 큐 시스템에서 기록 메시지(예: 처리된 모든 메시지의 히스토리)가 필요한 경우에는 개발자가 수동으로 이를 처리하고 저장해야 합니다. 큐는 기본적으로 메시지가 소비되면 삭제되므로, 영구적인 기록 보관 기능이 내장되어 있지 않기 때문입니다. 이 차이점은 각 시스템을 어떤 목적으로 사용할지 결정하는 데 중요한 고려 사항입니다.

크리스 사이먼은 이벤트 로그를 저장하는 용도로 아파치 카프카(Apache Kafka)를 사용하는 것이 겉보기에는 좋은 해결책처럼 보일 수 있지만, 본질적으로는 부적합하다고 주장했습니다. 그는 분산 로그(카프카)는 토픽(Topic)과 오프셋(Offset)을 기반으로 순차적으로 데이터를 쿼리하는 데 최적화되어 있다고 설명했습니다.

하지만 특정 엔티티(예: 사용자 ID, 주문 ID)에 대한 모든 이벤트를 효율적으로 가져오기 위해서는 전용 이벤트 저장소(Event Store)가 훨씬 더 적합합니다. 카프카는 엔티티 ID 등으로 데이터를 색인화하는 기능을 제공하지 않기 때문입니다. 겉으로 보기에는 이벤트 저장소와 유사해 보일지라도, 내부적인 최적화와 사용 목적이 다르므로 카프카를 순수한 이벤트 로그 저장소로 사용하는 것은 피해야 한다고 강조했습니다.

크리스 사이먼은 컨플루언트(Confluent)가 2017년에 아파치 카프카를 메시징의 '단일 진실 공급원'으로 광고하며 이벤트 소싱(Event Sourcing)을 위한 훌륭한 솔루션이라고 홍보했던 과거를 지적했습니다. 하지만 이후 컨플루언트가 이벤트 소싱에 대한 더 많은 문서를 공개하면서, 카프카 같은 스트림 시스템만으로 모든 이벤트를 처리할 필요는 없다고 인정하게 되었다고 설명했습니다.

컨플루언트는 '도메인 이벤트'와 '통합 이벤트'라는 개념을 도입하며 이벤트의 종류와 목적에 따라 다른 접근 방식이 필요함을 시사했습니다. 사이먼은 컨플루언트가 2017년 기사를 철회한 것에 대해 감사를 표하며, 많은 개발팀이 카프카를 이용해 이벤트 소싱을 시도하다가 수많은 문제에 직면했기 때문이라고 그 배경을 설명했습니다. 이는 기술의 오용이 실제 개발 현장에서 얼마나 큰 어려움을 초래할 수 있는지 보여주는 사례입니다.

크리스 사이먼은 이벤트를 사용하여 내부 워크플로, 즉 비즈니스 프로세스 코레오그래피의 다음 단계를 트리거해야 하는 경우에 어떤 기술이 적합한지 설명했습니다. 이러한 상황에서는 모든 이벤트 메시지가 중요하며, 누락 없이 처리되어야 합니다. 그는 메시지 기반, 큐 기반, 발행/구독(publish/subscribe) 시스템이 이러한 종류의 상황에 가장 적합하다고 강조했습니다.

이러한 시스템들은 브로커에 데드 레터 큐(Dead Letter Queue), 메시지 삭제 방지, 확장성, 그리고 모든 메시지가 궁극적으로 성공적으로 처리되도록 보장하는 다양한 기능이 내장되어 있기 때문입니다. 이는 개별 메시지의 신뢰성 있는 전달과 처리가 핵심인 워크플로 시스템에 필수적인 요소들입니다.

크리스 사이먼은 공개 이벤트(public event)에 포함되는 데이터의 양을 최소화해야 스키마 변경 시 발생할 수 있는 위험을 줄일 수 있다고 강조했습니다. 공개 이벤트에 많은 데이터가 포함될수록, 스키마가 변경될 때 모든 다운스트림 소비자(downstream consumer)에게 영향을 미칠 가능성이 커지기 때문입니다. 이벤트 버전을 관리하거나 스키마를 변경하거나 완전히 새로운 이벤트를 도입해야 할 경우, 모든 구독자가 새로운 버전을 처리하도록 업데이트해야 하는 복잡한 작업이 발생합니다.

이러한 위험을 최소화하는 가장 효과적인 방법 중 하나는 가능한 한 최소한의 데이터만을 경량 알림 이벤트(lightweight notification event)에 포함시키는 것입니다. 즉, 이벤트 자체는 특정 사실이 발생했다는 알림 역할만 하고, 필요한 상세 데이터는 소비자가 직접 요청하여 가져가도록 설계하는 것입니다. 이는 경계 컨텍스트(Bounded Context) 간에 흐르는 공개 이벤트의 필요성과도 잘 부합하며, 시스템 전반의 유연성과 유지보수성을 높이는 데 기여합니다. 데이터 최소화 전략은 시스템 변경에 대한 저항력을 높이고, 서비스 간의 결합도를 낮추는 핵심적인 방법론입니다.

크리스 사이먼은 레거시 시스템의 복잡한 데이터 구조를 다룰 때 스트림 또는 분산 로그(예: 카프카)가 매우 효과적인 해결책이 될 수 있다고 제안했습니다. 이러한 상황에서는 개별 이벤트의 중요성이 상대적으로 낮고, 나중에 발생한 이벤트가 이전 이벤트를 대체하는 특성을 가집니다.

스트림을 사용하면 전체 데이터 세트가 이벤트에 포함되므로, 오래된 데이터에 대해 크게 걱정할 필요 없이 항상 최신 데이터 또는 가장 최근 기록에 접근할 수 있습니다. 이는 레거시 시스템에서 현재 상태를 복제하거나 다른 시스템으로 데이터를 동기화할 때 유용하게 활용될 수 있는 장점입니다.

크리스 사이먼은 강연에서 다룬 모든 시나리오에 대한 C# 구현 예시를 담은 GitHub 저장소를 제공한다고 밝혔습니다. 이 저장소에는 일반 브로커 인터페이스와 여러 가지 패턴 구현이 포함되어 있으며, 각 브로커가 메시지 실패 및 파티션 수준으로 확장하는 방법을 확인할 수 있습니다. 그는 이 내용이 자신이 제공하는 'Imagine the Future and Build for the Now'라는 교육 과정에서 파생된 것이라고 덧붙였습니다.