---
id: P-REINFORCE-WIKI-C4E95109
category: "10_Wiki/💡 Topics/02_Architecture_Principles"
confidence_score: 0.95
tags: ['mediator-topology', 'event-driven-architecture-(eda)', 'broker-topology', 'event-mediator', 'business-process-execution-language-(bpel)', 'architecture-principles']
last_reinforced: 2026-05-02
---

# [[Mediator Topology]]

## 📌 Brief Summary
**Mediator Topology**(메디에이터 토폴로지)는 이벤트 기반 아키텍처(Event-Driven Architecture, EDA)에서 다중 단계의 비즈니스 프로세스나 복잡한 이벤트 조율이 필요할 때 사용되는 핵심 아키텍처 토폴로지입니다 [1, 2]. 중앙의 이벤트 메디에이터(Event Mediator)가 워크플로우의 상태를 유지하고, 각 단계에 맞는 처리 명령을 지정된 채널로 디스패치하여 오케스트레이션(Orchestration) 방식으로 시스템 흐름을 중앙 제어합니다 [2, 3]. 전체 시스템에 이벤트를 브로드캐스팅하는 브로커(Broker) 토폴로지와 달리, 프로세스 제어, 분산된 오류 처리, 그리고 향상된 데이터 일관성을 제공하는 것이 특징입니다 [3].

## 📖 Core Content
메디에이터 토폴로지는 복잡한 비즈니스 로직과 워크플로우를 체계적으로 관리하기 위해 여러 구성 요소가 유기적으로 협력하는 구조입니다.

*   **주요 구성 요소**: 시작 이벤트(Initiating Event), 이벤트 큐(Event Queue), 이벤트 메디에이터(Event Mediator), 이벤트 채널(Event Channel), 이벤트 프로세서/핸들러(Event Processor/Handler)로 구성됩니다 [4, 5]. 
*   **오케스트레이션 기반의 워크플로우**: 클라이언트로부터 발생한 이벤트가 큐를 거쳐 메디에이터로 전달되면, 메디에이터는 전체 비즈니스 프로세스의 다음 단계를 결정하여 적절한 이벤트 채널로 비동기 명령(Processing Event)을 보냅니다 [5, 6]. 각 이벤트 프로세서는 이 이벤트를 수신하여 실제 비즈니스 로직을 수행하며, 메디에이터 자체는 비즈니스 로직을 수행하지 않고 오직 프로세서들에게 처리 지침만을 제공합니다 [7]. 이후 프로세서는 처리가 완료되었음을 비동기 메시지로 메디에이터에 알립니다 [6].
*   **이벤트의 성격**: 브로커 토폴로지에서의 이벤트가 "이미 발생한 사실(Things that happened)"이라면, 메디에이터 토폴로지에서의 이벤트는 비즈니스 프로세스의 다음 단계를 실행하도록 지시하는 "명령(Command)"의 성격을 띠며 반드시 실행되어야 합니다 [8]. (예: '경매 입찰 발생' 대신 '입찰자들에게 알림', '아이템 결제' 등 [8])
*   **다중 메디에이터 및 구현 도구**: 엔터프라이즈 환경에서는 도메인(예: 고객 이벤트, 주문 이벤트, 재고 이벤트 등)별로 다수의 이벤트 메디에이터를 구현하여 부하를 분산시키고 신뢰성을 높일 수 있습니다 [6]. 이벤트 조율 및 에러 처리가 비교적 단순할 때는 Apache Camel이나 Spring Integration 같은 라이브러리를 사용하며, 장기 실행 프로세스나 고도로 복잡한 동적 경로 결정이 필요할 때는 BPEL(Business Process Execution Language)이나 BPM(Business Process Management) 실행 엔진을 활용할 수 있습니다 [9].

## ⚖️ Trade-offs & Caveats
메디에이터 토폴로지는 강력한 제어력을 제공하지만, 구조적 특성상 뚜렷한 한계와 반대급부(Trade-off)를 수반합니다.

*   **장점 (이점)**: 
    *   **복잡한 워크플로우 및 에러 제어**: 프로세스의 상태를 저장하고 유지할 수 있으므로, 에러 발생 시 트랜잭션을 재시작하거나 복구하는 등 복잡한 에러 처리가 매우 용이합니다 [2, 3, 10].
    *   **데이터 일관성**: 워크플로우가 중앙에서 관리되므로 잠재적으로 더 나은 데이터 일관성을 제공할 수 있습니다 [3].
*   **단점 (제약 사항 및 부작용)**:
    *   **단일 장애점 및 성능 병목(Bottleneck)**: 모든 이벤트 흐름이 중앙 메디에이터를 거치기 때문에, 트래픽이 급증할 경우 메디에이터가 성능 병목이 되거나 단일 장애점(Single Point of Failure)으로 전락할 위험이 큽니다 [2, 3].
    *   **결합도(Coupling) 증가**: 처리기(Processor)들이 중앙의 메디에이터를 인지하고 상호작용해야 하므로 브로커 토폴로지에 비해 컴포넌트 간의 결합도가 높아집니다 [2, 3]. 이로 인해 극단적인 수평적 확장성(Scalability)을 달성하는 데에는 브로커 모델보다 불리할 수 있습니다 [2, 10].

## 🔗 Knowledge Connections

### Related Concepts

#### [관계 유형 A: 아키텍처/기반 기술]
*   **[[Event-Driven Architecture (EDA)]]**
    *   연결 이유: 메디에이터 토폴로지가 속한 상위 아키텍처 스타일입니다.
    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 상태 변경(이벤트)을 비동기적으로 감지하고 반응하여 시스템의 확장성 및 응답성을 극대화하는 전반적인 메커니즘을 이해할 수 있습니다 [11-13].
*   **[[Broker Topology]]**
    *   연결 이유: 중앙 제어가 있는 메디에이터 토폴로지와 대비되는 무중앙(Choreography) 방식의 토폴로지입니다.
    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 중앙 조정자 없이 컴포넌트 간 높은 디커플링(Decoupling)과 확장성을 달성하는 방식을 통해 메디에이터 도입 시 포기해야 하는 트레이드오프를 명확히 이해할 수 있습니다 [2, 3, 14].

#### [관계 유형 B: 구현/활용 도구]
*   **[[Event Mediator]]**
    *   연결 이유: 메디에이터 토폴로지의 두뇌 역할을 하는 가장 핵심적인 중앙 조정 컴포넌트입니다.
    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 프로세스 상태 저장, 분산된 오류의 복구 및 재시작 논리가 중앙에서 어떻게 조율(Orchestration)되는지 파악할 수 있습니다 [3, 4].
*   **[[Business Process Execution Language (BPEL)]] / [[BPM]]**
    *   연결 이유: 복잡한 이벤트 조율, 다중 캐스팅, 동적 경로 결정, 예외 처리 등을 메디에이터에 구현하기 위해 사용되는 선언적 언어 및 관리 엔진입니다.
    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 단순한 코드로 처리하기 어려운 장기 실행(Long-running) 비즈니스 트랜잭션과 인간의 개입이 필요한 워크플로우를 시스템이 어떻게 자동화하는지 실무적 관점에서 배울 수 있습니다 [9].

### Deeper Research Questions
- 메디에이터 토폴로지 내에서 메디에이터 자체의 성능 병목 및 단일 장애점(SPOF) 위험을 완화하기 위해 어떤 분산 및 고가용성 설계 전략이 사용될 수 있는가? 
- 단일 시스템 내에서 단순한 이벤트는 브로커 토폴로지로, 복잡한 트랜잭션은 메디에이터 토폴로지로 처리하는 하이브리드 아키텍처는 어떻게 구현되며, 두 토폴로지 간의 통신은 어떻게 제어되는가? 
- 마이크로서비스 아키텍처(MSA) 환경에서 메디에이터 토폴로지(오케스트레이션)를 적용할 때 필연적으로 발생하는 서비스 간 결합도 증가 문제를 설계 단계에서 어떻게 최소화할 수 있는가?
- 중앙 메디에이터가 각 이벤트 처리기(Processor)에 비동기 명령(Processing Event)을 디스패치할 때, 메시지 유실이나 순서 역전을 방지하기 위한 기술적 메커니즘(예: Guaranteed Delivery 등)은 무엇인가?
- 메디에이터가 프로세스 상태를 추적하고 실패 시 트랜잭션을 재시작/복구하는 과정에서 보상 트랜잭션(Compensating Transaction)은 어떻게 실행되며 데이터 일관성은 어떻게 보장되는가?

### Practical Application Contexts
*   **Implementation:** 복잡한 이벤트 코디네이션이 필요한 도메인에서 Apache Camel이나 Spring Integration 같은 메시징 인프라를 활용해 메디에이터를 프로그래밍하거나, 복잡도에 따라 jBPM 같은 BPM 실행 엔진을 도입하여 워크플로우를 선언적으로 구현합니다 [9].
*   **System Design:** 전자상거래 시스템이나 보험 청구 처리처럼 사용자 상호작용 후 주문, 재고 확인, 결제, 배송 등 일련의 다단계 후속 작업이 반드시 정해진 순서와 규칙에 따라 진행되고, 중간에 에러가 났을 때 전체를 취소(Rollback)하거나 재시도해야 하는 시스템 설계 시 채택됩니다 [6, 8].
*   **Operation / Maintenance:** 메디에이터가 전체 비즈니스 흐름의 생살여탈권을 쥐고 있으므로 운영 팀은 중앙 메디에이터와 연결된 채널(메시지 큐)의 병목 여부, 큐 지연 시간(Latency) 등을 집중 모니터링해야 합니다 [2, 3].
*   **Learning Path:** 이벤트 기반 아키텍처의 기본 개념 습득 -> 브로커 방식과 메디에이터 방식의 장단점 비교 -> 비동기 메시지 채널(RabbitMQ, Kafka 등) 실습 -> Saga 패턴 및 오케스트레이션 프레임워크 학습 순으로 지식을 확장합니다.
*   **My Project Relevance:** 여러 마이크로서비스를 넘나드는 비즈니스 프로세스(예: 주문 처리 워크플로우)에서 트랜잭션의 상태 관리가 복잡해져 디버깅과 에러 복구에 어려움을 겪고 있다면, 중앙에서 흐름을 통제하는 메디에이터 패턴 도입을 검토하여 시스템의 안정성과 제어력을 높일 수 있습니다.

### Adjacent Topics
*   **[[Saga Pattern (Orchestration)]]**
    *   확장 방향: 마이크로서비스 환경에서 중앙 오케스트레이터(메디에이터와 유사한 역할)를 두고 분산 트랜잭션을 관리하며, 실패 시 보상 트랜잭션(Compensating Transaction)을 통해 데이터의 최종 일관성을 달성하는 방법론으로 학습을 확장합니다 [13, 15].
*   **[[Microservices Architecture (MSA)]]**
    *   확장 방향: 도메인별로 작고 독립적인 서비스로 분할된 환경에서, 각 서비스 간의 효율적인 상호작용 및 오케스트레이션을 위해 이벤트 기반 아키텍처(메디에이터 포함)가 어떻게 MSA의 한계를 보완하고 복잡성을 제어하는지 분석합니다 [3, 16, 17].

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