이벤트 기반 아키텍처: 분산 시스템을 느슨하게 연결하는 방식

서비스 호출 대신 이벤트 흐름으로 연결하기

EDA(Event Driven Architecture)는 이벤트 생성과 이벤트 처리를 중심에 두는 소프트웨어 아키텍처다. 분산 시스템의 구성요소는 서로를 직접 의존하기보다 이벤트를 통해 비동기적으로 통신하며, 이 방식은 느슨한 결합과 실시간 데이터 처리를 지원한다.

사용자 입력, 센서 데이터 수신, 시스템 상태 변경, 특정 시점 도달, 비즈니스 조건 충족처럼 시스템 안팎의 중요한 상태 변화가 이벤트가 된다. 이벤트에는 발생 시간, 출처, 특성 같은 메타데이터도 함께 담긴다.

이벤트를 감지해 메시지를 만드는 쪽은 이벤트 생산자다. 생산자는 이벤트 채널로 메시지를 전달할 뿐, 누가 어떤 방식으로 처리하는지는 알 필요가 없다. 반대로 이벤트 소비자는 특정 유형의 이벤트를 받아 처리 로직을 실행한다. 하나의 이벤트를 여러 소비자가 함께 처리할 수도 있다.

생산자와 소비자 사이에는 이벤트 채널이 놓인다. 이 채널은 보통 메시지 브로커나 이벤트 버스 형태로 구현하며, Apache Kafka, RabbitMQ, AWS EventBridge가 대표적인 구현 사례다.

이벤트 처리 요구에 맞춰 고르는 패턴

발행-구독으로 다수의 소비자 연결

발행-구독 패턴에서는 생산자가 특정 토픽에 이벤트를 발행하고, 해당 토픽을 구독한 소비자가 이벤트를 받는다. 생산자와 소비자를 완전히 분리할 수 있어 동일한 이벤트에 새로운 처리 기능을 덧붙이기 쉽다.

⤢✕

연속 데이터는 스트림으로 처리

이벤트 스트리밍은 끊임없이 이어지는 이벤트 흐름을 실시간으로 다루는 방식이다. Apache Kafka, Apache Flink 등의 기술로 구현할 수 있으며, 대용량 데이터 스트림 처리에 적합하다.

⤢✕

상태 대신 변경 이력을 저장하는 이벤트 소싱

이벤트 소싱은 상태 변경을 이벤트 시퀀스로 보관한다. 현재 상태는 이벤트 히스토리를 다시 구성해 얻으며, 감사와 시간 기반 쿼리에 유용하다.

⤢✕

읽기와 쓰기의 책임을 분리하는 CQRS

CQRS(Command Query Responsibility Segregation)는 데이터를 바꾸는 명령과 조회를 위한 쿼리의 책임을 나눈다. 이벤트 소싱과 함께 사용할 때 시너지 효과가 있으며, 읽기와 쓰기에 맞춘 별도 모델을 둘 수 있다.

⤢✕

이벤트를 전달하고 관찰하는 기반

복잡 이벤트 처리(Complex Event Processing, CEP) 엔진은 이벤트 스트림에서 패턴을 탐지하고 분석해 실시간 의사결정을 지원한다. Esper, WSO2 Stream Processor 등이 활용된다.

메시지 브로커는 이벤트의 라우팅과 배달을 담당하며, 메시지 버퍼링으로 일시적인 부하를 처리한다. Apache Kafka, RabbitMQ, ActiveMQ가 여기에 해당한다.

운영 측면에서는 이벤트 모니터링과 추적, SLA(Service Level Agreement) 관리, 이벤트 로깅과 감사가 필요하다. 이기종 시스템을 연결해야 한다면 API 관리 및 게이트웨이, ESB(Enterprise Service Bus) 연계도 함께 고려한다.

느슨한 결합이 만드는 운영상 이점

구성요소를 독립적으로 확장할 수 있으므로 트래픽 증가에 유연하게 대응할 수 있고, 클라우드 환경에도 잘 맞는다. 새 기능이 필요할 때는 기존 생산자를 바꾸지 않고 새로운 소비자를 추가할 수 있어 변경의 영향 범위를 줄일 수 있다.

비동기 통신은 신속한 응답과 시스템 부하 분산에 기여한다. 또한 일부 구성요소에 장애가 발생해도 전체 시스템에 미치는 영향을 줄일 수 있으며, 메시지 지속성(persistence)을 활용하면 데이터 손실 방지와 장애 복구 메커니즘 구현에 도움이 된다.

이벤트가 서비스 경계를 넘는 방식

금융권의 실시간 사기 탐지에서는 거래 시스템이 거래 이벤트를 만들고, Kafka를 통해 사기 탐지 엔진으로 전달한다. CEP 엔진은 의심 패턴을 즉시 탐지하며, 비정상 거래가 감지되면 알림과 차단으로 이어질 수 있다.

⤢✕

IoT 스마트홈에서는 여러 센서의 이벤트를 IoT 게이트웨이와 클라우드 이벤트 허브에서 통합한다. 온도 변화는 온도 조절 서비스로, 동작 감지는 보안 서비스로 전달할 수 있으며, 실시간 환경 변화 대응과 사용자 행동 패턴 학습·자동화에 활용된다.

⤢✕

전자상거래 주문 처리에서는 주문 서비스가 주문 생성 이벤트를 이벤트 버스에 발행하고, 재고·결제·배송·알림 서비스가 이를 비동기적으로 처리한다. 각 서비스는 독립적으로 확장할 수 있으며, 시스템 일부에 장애가 있어도 주문 접수는 가능하다.

⤢✕

이벤트 계약과 전달 보장을 함께 설계하기

이벤트 형식과 구조는 표준화하고, 스키마 진화(evolution) 전략을 세워야 한다. Confluent Schema Registry 같은 스키마 레지스트리를 활용할 수 있다.

이벤트 순서가 중요한 도메인이라면 파티셔닝 전략과 이벤트 시퀀스 번호를 고려한다. 메시지 전달 보장을 위해 재시도가 발생하면 중복 이벤트가 생길 수 있으므로, 멱등성(idempotence) 구현과 이벤트 ID 기반 중복 제거 메커니즘이 필요하다.

분산 추적(distributed tracing) 시스템을 구축해 이벤트 흐름을 시각화하고, 지연 시간(latency)과 처리량(throughput)을 모니터링해야 한다. 이벤트가 늘어날수록 개별 서비스의 상태만으로는 전체 처리 경로를 파악하기 어렵기 때문이다.

서버리스와 AI 파이프라인으로 넓어지는 이벤트 처리

AWS Lambda, Azure Functions 같은 서버리스 환경에서는 이벤트를 기준으로 함수를 실행할 수 있다. 인프라 관리 부담을 줄이고 사용량에 따른 자동 확장과 비용 효율성을 기대할 수 있다.

이벤트 메시 아키텍처는 단일 중앙화 브로커에 대한 의존성을 줄이고, 분산된 이벤트 라우터로 구성한다. 대규모 글로벌 시스템에 적합한 접근이다.

실시간 이벤트 스트림에 머신러닝 모델을 적용하면 이상 탐지와 예측 분석이 가능하다. 이 방식은 스트림 처리와 AI 파이프라인을 하나의 흐름으로 통합한다.