feat: Wiki 지식 자산 업데이트 - UX Scenarios, Frontend, Game Design, Topics 추가 [2026-05-08]
This commit is contained in:
@@ -1,17 +1,29 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-C4E95109
|
||||
category: Unified
|
||||
id: wiki-2026-0508-mediator-topology
|
||||
title: Mediator Topology
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-WIKI-C4E95109]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: ['mediator-topology', 'event-driven-architecture-(eda)', 'broker-topology', 'event-mediator', 'business-process-execution-language-(bpel)', 'architecture-principles']
|
||||
tags: [mediator-topology, event-driven-architecture-(eda), broker-topology, event-mediator, business-process-execution-language-(bpel), architecture-principles]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-02
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Mediator Topology]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
**Mediator Topology**(메디에이터 토폴로지)는 이벤트 기반 아키텍처(Event-Driven Architecture, EDA)에서 다중 단계의 비즈니스 프로세스나 복잡한 이벤트 조율이 필요할 때 사용되는 핵심 아키텍처 토폴로지입니다 [1, 2]. 중앙의 이벤트 메디에이터(Event Mediator)가 워크플로우의 상태를 유지하고, 각 단계에 맞는 처리 명령을 지정된 채널로 디스패치하여 오케스트레이션(Orchestration) 방식으로 시스템 흐름을 중앙 제어합니다 [2, 3]. 전체 시스템에 이벤트를 브로드캐스팅하는 브로커(Broker) 토폴로지와 달리, 프로세스 제어, 분산된 오류 처리, 그리고 향상된 데이터 일관성을 제공하는 것이 특징입니다 [3].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
메디에이터 토폴로지는 복잡한 비즈니스 로직과 워크플로우를 체계적으로 관리하기 위해 여러 구성 요소가 유기적으로 협력하는 구조입니다.
|
||||
|
||||
* **주요 구성 요소**: 시작 이벤트(Initiating Event), 이벤트 큐(Event Queue), 이벤트 메디에이터(Event Mediator), 이벤트 채널(Event Channel), 이벤트 프로세서/핸들러(Event Processor/Handler)로 구성됩니다 [4, 5].
|
||||
@@ -19,7 +31,7 @@ last_reinforced: 2026-05-02
|
||||
* **이벤트의 성격**: 브로커 토폴로지에서의 이벤트가 "이미 발생한 사실(Things that happened)"이라면, 메디에이터 토폴로지에서의 이벤트는 비즈니스 프로세스의 다음 단계를 실행하도록 지시하는 "명령(Command)"의 성격을 띠며 반드시 실행되어야 합니다 [8]. (예: '경매 입찰 발생' 대신 '입찰자들에게 알림', '아이템 결제' 등 [8])
|
||||
* **다중 메디에이터 및 구현 도구**: 엔터프라이즈 환경에서는 도메인(예: 고객 이벤트, 주문 이벤트, 재고 이벤트 등)별로 다수의 이벤트 메디에이터를 구현하여 부하를 분산시키고 신뢰성을 높일 수 있습니다 [6]. 이벤트 조율 및 에러 처리가 비교적 단순할 때는 Apache Camel이나 Spring Integration 같은 라이브러리를 사용하며, 장기 실행 프로세스나 고도로 복잡한 동적 경로 결정이 필요할 때는 BPEL(Business Process Execution Language)이나 BPM(Business Process Management) 실행 엔진을 활용할 수 있습니다 [9].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
메디에이터 토폴로지는 강력한 제어력을 제공하지만, 구조적 특성상 뚜렷한 한계와 반대급부(Trade-off)를 수반합니다.
|
||||
|
||||
* **장점 (이점)**:
|
||||
@@ -29,8 +41,7 @@ last_reinforced: 2026-05-02
|
||||
* **단일 장애점 및 성능 병목(Bottleneck)**: 모든 이벤트 흐름이 중앙 메디에이터를 거치기 때문에, 트래픽이 급증할 경우 메디에이터가 성능 병목이 되거나 단일 장애점(Single Point of Failure)으로 전락할 위험이 큽니다 [2, 3].
|
||||
* **결합도(Coupling) 증가**: 처리기(Processor)들이 중앙의 메디에이터를 인지하고 상호작용해야 하므로 브로커 토폴로지에 비해 컴포넌트 간의 결합도가 높아집니다 [2, 3]. 이로 인해 극단적인 수평적 확장성(Scalability)을 달성하는 데에는 브로커 모델보다 불리할 수 있습니다 [2, 10].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A: 아키텍처/기반 기술]
|
||||
@@ -70,4 +81,53 @@ last_reinforced: 2026-05-02
|
||||
* 확장 방향: 도메인별로 작고 독립적인 서비스로 분할된 환경에서, 각 서비스 간의 효율적인 상호작용 및 오케스트레이션을 위해 이벤트 기반 아키텍처(메디에이터 포함)가 어떻게 MSA의 한계를 보완하고 복잡성을 제어하는지 분석합니다 [3, 16, 17].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
Reference in New Issue
Block a user