feat: Wiki 지식 자산 업데이트 - UX Scenarios, Frontend, Game Design, Topics 추가 [2026-05-08]

10_Wiki/Topics/Architecture/Broker Topology.md

@@ -1,17 +1,29 @@
 ---
-id: P-REINFORCE-WIKI-15DEEFAA
-category: Unified
+id: wiki-2026-0508-broker-topology
+title: Broker Topology
+category: 10_Wiki/Topics
+status: needs_review
+canonical_id: self
+aliases: [P-REINFORCE-WIKI-15DEEFAA]
+duplicate_of: none
+source_trust_level: A
 confidence_score: 0.95
-tags: ['broker-topology', 'event-driven-architecture', 'mediator-topology', 'choreography', 'message-broker', 'architecture-principles']
+tags: [broker-topology, event-driven-architecture, mediator-topology, choreography, message-broker, 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
 ---
 
 # [[Broker Topology]]
 
-## 📌 Brief Summary
+## 📌 한 줄 통찰 (The Karpathy Summary)
 Broker Topology(브로커 토폴로지)는 이벤트 기반 아키텍처(Event-Driven Architecture)를 구현하는 두 가지 주요 토폴로지 중 하나로, 중앙의 조정자(Orchestrator)나 메디에이터 없이 컴포넌트들이 비동기적으로 이벤트를 브로드캐스트하는 구조입니다 [1, 2]. 이 방식은 중앙 통제 대신 각 독립적인 이벤트 핸들러가 자율적으로 이벤트에 반응하는 형태(Choreography)를 취합니다 [2, 3]. 결합도가 매우 낮아 확장성과 반응성이 뛰어나며 단일 장애점을 최소화할 수 있지만, 복잡한 트랜잭션 관리와 워크플로우 제어에는 불리한 특성이 있습니다 [1-3]. 
 
-## 📖 Core Content
+## 📖 구조화된 지식 (Synthesized Content)
 *   **핵심 구성 요소 (Core Components):**
     브로커 토폴로지는 주로 개시 이벤트(Initiating Event), 이벤트 브로커(Event Broker), 이벤트 채널(Event Channel), 이벤트 핸들러(Event Handler), 처리 이벤트(Processing Event) 등 5가지 요소로 구성됩니다 [1, 4]. 클라이언트가 이벤트를 발생시키면 이벤트 브로커의 특정 채널로 전달되고, 해당 채널을 수신하는 이벤트 핸들러들이 이벤트를 가져와 처리한 뒤, 다음 단계를 위한 새로운 처리 이벤트를 다시 브로커에 발행하는 연쇄적인 방식으로 동작합니다 [4].
 *   **중앙 조정자의 부재 (Lack of Central Coordinator):**
@@ -21,13 +33,12 @@ Broker Topology(브로커 토폴로지)는 이벤트 기반 아키텍처(Event-D
 *   **최적의 사용 사례 (Best Use Cases):**
     이 토폴로지는 여러 단계의 복잡한 오케스트레이션(Orchestration)이 필요 없는 단순한 이벤트 스트림 처리에 가장 적합합니다 [8]. 예를 들어, 보안 시스템에서 침입 센서가 이벤트를 발생시키면 이를 직접 브로커로 전달하고, 경보 울림, 경찰 통보 등의 개별 프로세서가 이 알림에 비동기적으로 반응하는 시나리오 등에 효과적입니다 [9]. 
 
-## ⚖️ Trade-offs & Caveats
+## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
 *   **복잡한 에러 처리 및 트랜잭션 복구의 한계:** 중앙에서 프로세스를 조정하는 요소가 없으므로, 여러 서비스에 걸친 분산 트랜잭션을 관리하기가 매우 위험하고 까다롭습니다 [2]. 중간 단계에서 오류가 발생하더라도 이를 인지하고 전체 프로세스를 재시작(Restart)하거나 재생(Replay)하는 내장 메커니즘이 부족하므로 수동 개입 전략이나 별도의 에러 핸들러 설계가 요구됩니다 [2, 5].
 *   **데이터의 일관성 문제 (Data Inconsistency):** 모든 행위가 비동기적으로 분리되어 실행되기 때문에, 각 서브시스템이 이벤트를 처리하고 상태를 업데이트하는 속도가 다를 수 있습니다 [2, 10]. 이로 인해 일시적으로 서비스 간 데이터의 불일치가 발생하는 최종 일관성(Eventual Consistency) 모델을 감수해야 합니다 [2, 10].
 *   **워크플로우 모니터링의 난해함:** 모든 처리가 개별 핸들러들의 자율적인 안무(Choreography) 방식으로 이루어지기 때문에, 비즈니스 워크플로우의 전체적인 진행 상황을 파악하거나 추적하기 어렵습니다 [3]. 이를 해결하기 위해 모든 이벤트에 상관 ID(Correlation ID)를 포함시켜 분산 추적(Distributed Tracing)을 가능하게 하는 부가적인 노력이 필수적입니다 [11].
 
-## 🔗 Knowledge Connections
-
+## 🔗 지식 연결 (Graph)
 ### Related Concepts
 
 #### [아키텍처/기반 기술]
@@ -67,4 +78,53 @@ Broker Topology(브로커 토폴로지)는 이벤트 기반 아키텍처(Event-D
     *   확장 방향: 마이크로서비스 간 느슨한 결합(Loose Coupling)을 실현하고 서비스 자율성을 부여하기 위한 내부 통신 수단으로서 브로커 토폴로지가 어떻게 접목되는지 탐구합니다 [10, 23].
 
 ---
-*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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*