---
id: P-REINFORCE-WIKI-F81E0CF7
category: Dev
confidence_score: 0.95
tags: ['event-mediator', 'event-driven-architecture', 'broker-topology', 'message-queues', 'bpm-engine-/-bpel', 'architecture-principles']
last_reinforced: 2026-05-02
---

# [[Event Mediator]]

## 📌 Brief Summary
이벤트 메디에이터(Event Mediator)는 이벤트 기반 아키텍처(Event-Driven Architecture)의 메디에이터 토폴로지(Mediator Topology) 내에서 이벤트의 흐름을 통제하고 워크플로우를 중앙에서 오케스트레이션(Orchestration)하는 핵심 구성 요소이다 [1, 2]. 다수의 단계가 필요한 복잡한 상황에서 각 프로세서가 수행할 명령을 지정된 채널로 전달하며, 비즈니스 프로세스의 상태를 유지하고 에러 처리 및 복구(재시작) 기능을 제공하는 것이 특징이다 [1-3]. 반면, 모든 흐름을 중앙에서 제어하기 때문에 성능 병목이나 단일 장애점이 될 위험이 존재한다 [1, 2].

## 📖 Core Content
* **중앙 집중식 워크플로우 제어:** 이벤트 메디에이터는 이벤트 큐(Event Queue)로부터 초기 이벤트(Initiating Event)를 수신한 후, 비즈니스 프로세스를 구현하기 위해 단계를 조정한다 [4]. 이벤트 핸들러가 처리 완료 메시지를 보내면, 메디에이터는 이를 바탕으로 조건부(conditional) 또는 반복적(iterative) 논리를 적용해 다음 단계를 결정하고 후속 처리 이벤트(Processing Event)를 발송한다 [4].
* **명령(Command) 기반의 오케스트레이션:** 시스템 전체에 이벤트를 브로드캐스트하는 브로커(Broker) 토폴로지와 달리, 지정된 채널(주로 메시지 큐)을 통해 특정 명령 형태의 이벤트를 디스패치한다 [1]. 즉, 이벤트 메디에이터 구조에서의 이벤트는 단순한 상태 변화의 알림이 아니라 반드시 실행되어야 할 '명령'으로 취급된다 [5].
* **상태 유지 및 강력한 에러 복구:** 이벤트 메디에이터는 비즈니스 프로세스의 상태를 유지(maintain the state)할 수 있어, 에러가 발생했을 때 이를 복구하고 프로세스를 재시작(restart)할 수 있는 능력을 제공한다 [1, 2]. 이를 통해 분산 환경에서 더욱 정교한 에러 핸들링과 향상된 데이터 일관성을 확보할 수 있다 [1].
* **도메인별 분산 및 확장 구현:** 단일 메디에이터 구성뿐만 아니라 고객, 브라우징, 주문, 재고 등 문제 도메인별로 다수의 메디에이터를 분할 구현하여 부하에 따라 독립적으로 확장성을 확보하고 신뢰성을 높일 수 있다 [4]. 단순한 제어 로직은 일반 코드로, 복잡한 제어나 긴 실행 시간이 필요한 워크플로우는 BPEL(Business Process Execution Language)이나 BPM(Business Process Management) 엔진과 같은 도구를 사용하여 제어한다 [6].

## ⚖️ Trade-offs & Caveats
* **성능 병목 및 단일 장애점(SPOF) 위험:** 메디에이터가 모든 워크플로우와 이벤트 흐름을 중앙에서 제어하고 조정하기 때문에, 트래픽이 집중될 경우 메디에이터 자체가 성능의 병목(bottleneck) 현상을 유발하거나 시스템의 신뢰성을 위협하는 단일 장애점이 될 위험이 존재한다 [1, 2].
* **컴포넌트 간 결합도(Coupling) 증가:** 중앙 집중형 오케스트레이션 방식을 따르므로, 처리기(Consumer/Handler)들이 메디에이터의 명령을 인식해야 하며 프로세스 제어를 위한 일정 수준의 결합이 수반되어 전체적으로 컴포넌트 간 결합도가 증가한다 [1, 2, 7].
* **상대적으로 낮은 확장성:** 브로커 토폴로지와 같이 각 구성 요소가 극도로 느슨하게 결합되어 자율적으로 이벤트를 처리하는 방식에 비해, 메디에이터 병목 등으로 인해 상대적인 시스템 확장성과 성능 한계가 낮다 [2].

## 🔗 Knowledge Connections

### Related Concepts

#### [관계 유형 A (아키텍처/기반 기술)]
- [[Event-Driven Architecture]]
  - 연결 이유: 이벤트 메디에이터가 핵심 오케스트레이션 역할을 수행하는 최상위 아키텍처 패턴이기 때문이다 [8, 9].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 이벤트를 비동기적으로 생성하고 감지하여 처리하는 분산 시스템 전반의 동작 원리와 유연성을 이해할 수 있다 [8, 10].
- [[Broker Topology]]
  - 연결 이유: 중앙 조정자인 메디에이터 없이 컴포넌트들이 브로드캐스트된 이벤트를 자율적으로 처리하는(안무 방식) 상반된 토폴로지이기 때문이다 [1, 2, 10].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 중앙 통제형(오케스트레이션) 방식과 분산 통제형(안무) 방식의 장단점(결합도, 에러 처리, 확장성)을 비교 및 대조하여 분석할 수 있다 [2, 5].

#### [관계 유형 B (구현/활용 도구)]
- [[Message Queues]]
  - 연결 이유: 이벤트 메디에이터가 다음 작업을 수행할 소비자(이벤트 핸들러)에게 명령(이벤트)을 디스패치할 때 지정하는 주요 통신 채널 기술이기 때문이다 [1].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 이벤트의 비동기적 버퍼링 및 전달을 통한 시스템의 부하 분산과 안정성 확보 메커니즘을 배울 수 있다 [4, 11].
- [[BPM Engine / BPEL]]
  - 연결 이유: 메디에이터에서 에러 처리와 조건부 논리 제어 등 복잡도가 높은 비즈니스 로직을 구현할 때 활용하는 언어 및 실행 엔진이기 때문이다 [6].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 복잡한 조건부 처리, 동적 경로 결정 및 긴 실행 시간(Long-running)을 가지는 워크플로우 관리 기법을 이해할 수 있다 [6].

### Deeper Research Questions
- 오케스트레이션(Orchestration) 방식의 메디에이터 패턴과 안무(Choreography) 방식의 브로커 패턴을 비즈니스 복잡도에 따라 하이브리드 형태로 어떻게 결합할 수 있는가?
- 이벤트 메디에이터가 상태를 유지(Stateful)하면서도 대규모 트래픽 하에서 성능 병목이나 단일 장애점(SPOF)이 되는 것을 피하기 위한 스케일링 전략이나 기술 구조는 무엇인가?
- 메디에이터 토폴로지 환경에서 단계 중 에러 발생 시, 중앙 메디에이터는 어떠한 방식으로 프로세스를 재시작(restart)하고 보상 트랜잭션(Compensating Transaction)을 지시하는가?
- 이벤트 메디에이터 내부의 로직을 일반 코드로 직접 구현하는 방식과 BPEL 등의 DSL(Domain Specific Language)을 활용하는 방식 사이의 선택 기준과 각각의 유지보수 이점은 무엇인가?
- 단일 시스템 내에서 문제 도메인별로 다수의 이벤트 메디에이터를 분할할 때, 초기 이벤트 큐에서 각 메디에이터로 이벤트를 분류 및 라우팅하는 효율적인 구조는 어떻게 설계해야 하는가?

### Practical Application Contexts
- **Implementation:** 복잡한 비즈니스 로직 및 에러 처리 구현이 요구될 경우, Apache Camel, Spring Integration과 같은 메시징 인프라나 jBPM 같은 BPM 실행 엔진을 사용하여 워크플로우를 통제하는 메디에이터를 직접 구현한다.
- **System Design:** 아키텍처 설계 시, 에러 복구와 프로세스의 상태 보존이 필수적인 워크플로우 구간(예: 다단계 금융 결제, 복잡한 재고 처리 등)을 식별하고 이 부분에 메디에이터 토폴로지를 적용해 데이터 일관성을 확보한다.
- **Operation / Maintenance:** 운영 측면에서 중앙 이벤트 메디에이터 자체가 성능의 병목이나 단일 장애점이 될 수 있으므로, 해당 메디에이터 컴포넌트의 이중화 구성과 집중적인 상태 모니터링(Observability) 체계를 관리한다.
- **Learning Path:** 이벤트 기반 아키텍처의 기본 원리와 브로커 토폴로지의 느슨한 결합을 먼저 학습한 뒤, 분산 시스템에서의 에러 핸들링과 워크플로우 통제 필요성에 따라 메디에이터 토폴로지의 구조적 특징과 한계를 순차적으로 학습한다.
- **My Project Relevance:** 여러 서비스에 걸쳐 비동기적으로 실행되는 복잡한 비즈니스 프로세스 프로젝트를 진행할 때, 특정 단계의 실패 시 전체 프로세스 롤백 혹은 재시작을 중앙에서 조율해야 하는 관리 오케스트레이터의 도입을 검토할 때 참고한다.

### Adjacent Topics
- [[Microservices Architecture]]
  - 확장 방향: 독립적으로 배포된 다수의 마이크로서비스 간에 걸쳐진 분산 트랜잭션 관리와 프로세스 조정을 위해 이벤트 메디에이터를 어떻게 효율적으로 통합할 것인지 연구한다.
- [[Saga Pattern]]
  - 확장 방향: 분산 환경에서 ACID 트랜잭션 대신 최종 일관성(Eventual Consistency)을 보장하기 위한 오케스트레이션 기반 SAGA 패턴 구현 시, 중앙 메디에이터의 보상 트랜잭션 제어 기법을 심층 학습한다.

---
*Last updated: 2026-05-02*