이벤트 기반 아키텍처로 느슨하게 연결하는 분산 시스템
이벤트 기반 아키텍처의 생산자·브로커·소비자 역할과 발행-구독, 이벤트 소싱 패턴, 설계 시 운영 고려사항을 정리한다.
2026-08-14 · 최초 발행 2025-05-23
이벤트가 서비스 사이의 연결점이 될 때
이벤트 기반 아키텍처(Event Driven Architecture, EDA)는 시스템에서 발생한 상태 변화나 중요한 사실을 이벤트로 전달하고, 각 컴포넌트가 이를 감지해 처리하도록 구성하는 아키텍처 패턴이다. 애플리케이션끼리 직접 연결하는 대신 이벤트를 매개로 상호작용하므로, 구성요소는 느슨한 결합을 유지한 채 독립적으로 동작할 수 있다.
요청을 보내고 즉시 응답을 기다리는 전통적인 요청-응답 방식과 달리, EDA는 비동기 통신을 지향한다. 이벤트는 특정 상태 변화나 중요 사항을 담은 데이터 패킷이며, 이를 받아 처리하는 쪽은 이벤트를 만든 쪽을 직접 알 필요가 없다.
생산자, 채널, 소비자가 나누는 역할
이벤트 생산자(Event Producer)는 이벤트 발생을 감지해 메시지를 만든다. 이벤트를 발행한 뒤에는 수신자 정보를 알지 못해도 다음 작업을 계속할 수 있으며, 비즈니스 로직을 크게 바꾸지 않고 새 이벤트 유형을 추가할 수 있다.
생산자와 소비자 사이에는 이벤트 채널(Event Channel)이 놓인다. 메시지 큐, 이벤트 버스, 브로커가 이 역할을 맡으며 Apache Kafka, RabbitMQ, Amazon SNS/SQS 등이 대표적인 구현체다.
이벤트 소비자(Event Consumer)는 채널에서 이벤트를 받아 필요한 작업을 수행한다. 생산자와 독립적으로 작동하므로 새 소비자를 추가해도 전체 시스템에 미치는 영향이 작다.
이벤트 프로세서(Event Processor)는 받은 이벤트를 변환하거나 처리한다. 필터링, 집계, 변환을 담당하며 복잡한 이벤트 처리(CEP) 시스템에서 특히 중요한 위치를 차지한다.
브로커를 거치는 비동기 흐름
생산자는 브로커에 이벤트를 발행하고, 브로커는 이를 저장하거나 적절한 소비자에게 라우팅한다. 여러 소비자가 같은 이벤트를 받아 각자의 책임을 수행할 수 있으므로, 생산자는 후속 처리의 세부 구현에 묶이지 않는다.
목적에 따라 달라지는 이벤트 패턴
발행-구독(Publish-Subscribe) 패턴에서는 생산자가 특정 토픽에 메시지를 발행하고, 해당 토픽을 구독한 모든 소비자가 메시지를 전달받는다. 1:N 통신 구조라 확장에 적합하다.
이벤트 스트리밍(Event Streaming) 패턴은 연속적으로 들어오는 이벤트 흐름을 처리하는 데 초점을 둔다. 실시간 데이터 처리와 분석에 적합하며 Apache Kafka가 대표적인 구현 기술이다.
이벤트 소싱(Event Sourcing)은 현재 상태를 직접 저장하는 대신 상태 변경 이벤트의 시퀀스를 보관한다. 변경 이력을 추적할 수 있고, 이벤트를 다시 적용해 시스템 상태를 재구성하거나 감사에 활용할 수 있다.
결합도를 낮추는 대신 운영 복잡도는 남는다
EDA는 구성요소 간 직접 의존성을 줄여 각 컴포넌트를 독립적으로 개발·배포·확장할 수 있게 한다. 한 컴포넌트의 장애가 전체 시스템으로 번지는 영향을 줄이고, 부하가 늘면 필요한 부분만 수평적으로 확장할 수 있다. 클라우드 환경과 레거시 시스템 통합에도 유리하다.
새 기능을 추가할 때 기존 시스템 변경을 최소화할 수 있고, 컴포넌트마다 다른 기술 스택을 선택할 여지도 생긴다. 메시지를 다시 처리할 수 있어 일시적 장애에 대응하기 좋으며, 비동기 통신은 일부 시스템 장애 중에도 다른 흐름이 계속 작동하도록 돕는다.
반면 분산 환경의 이벤트 흐름은 추적과 디버깅을 어렵게 만든다. 비동기 프로세스를 테스트하기도 쉽지 않다. 이벤트 순서 보장, 중복 이벤트 처리, 최종 일관성(Eventual Consistency)은 구현에서 피할 수 없는 관리 대상이다.
메시지 브로커를 구축하고 운영하는 비용, 네트워크 트래픽과 시스템 리소스 사용량도 고려해야 한다. 이벤트 스키마와 버전 관리 전략, 비동기 프로그래밍 방식에 대한 팀의 이해가 함께 필요하다.
구현에 쓰이는 기술 범위
메시지 브로커로는 고성능과 내구성을 갖춘 분산 스트리밍 플랫폼인 Apache Kafka, AMQP 프로토콜 기반의 RabbitMQ, AWS의 Amazon SNS/SQS, GCP의 Google Pub/Sub를 사용할 수 있다.
이벤트 처리에는 Spring Cloud Stream, Apache Flink, 액터 모델 기반의 Akka, .NET 기반 메시징 프레임워크인 NServiceBus가 활용된다. 서버리스 처리 환경에서는 AWS Lambda, Azure Functions, Google Cloud Functions가 이벤트 기반 컴퓨팅을 제공한다.
이벤트가 잘 맞는 업무 흐름
금융 서비스에서는 트랜잭션 처리, 사기 탐지, 실시간 위험 분석, 규제 준수와 감사 추적에 이벤트 흐름을 적용할 수 있다. JP Morgan의 Athena 플랫폼이 사례로 언급된다.
전자상거래에서는 주문 처리, 재고 관리, 물류 연동, 개인화 추천 시스템이 서로 다른 이벤트에 반응할 수 있다. Amazon의 마이크로서비스 아키텍처가 사례다.
IoT 시스템은 센서 데이터를 실시간으로 처리하고 장치 상태를 모니터링하며 이벤트 기반 자동화를 수행한다. 스마트 홈과 스마트 공장 시스템이 여기에 해당한다.
인프라 모니터링, 이상 탐지와 자동 대응, 사용자 행동 분석에도 이벤트 기반 구조를 적용할 수 있으며 Netflix의 모니터링 시스템이 사례로 제시된다.
설계에서 미리 정할 문제들
이벤트 자체는 스키마를 표준화하고 버전 관리 전략을 세워야 한다. 이벤트 크기와 포맷 역시 처리 목적에 맞게 다뤄야 한다.
오류가 난 메시지를 위한 데드 레터 큐(Dead Letter Queue), 재시도 메커니즘, 장애 복구 전략도 필요하다. 성능 측면에서는 메시지 배치 처리, 파티셔닝, 메시지 압축과 직렬화 방식을 검토한다.
운영 단계에서는 이벤트 흐름을 시각화하고 성능 측정 지표를 정의하며 분산 추적(Distributed Tracing)을 구현해야 한다. EDA의 이점은 이벤트를 발행하는 순간보다, 이벤트가 실패하거나 지연되거나 중복됐을 때도 흐름을 통제할 수 있는 설계에서 드러난다.