---
id: P-REINFORCE-WIKI-DB427E96
category: "10_Wiki/💡 Topics/02_Architecture_Principles"
confidence_score: 0.95
tags: ['event-driven-architecture-(eda)', 'broker-topology', 'mediator-topology', 'microservices-architecture', 'complex-event-processing-(cep)', 'architecture-principles']
last_reinforced: 2026-05-02
---

# [[Event-Driven Architecture (EDA)]]

## 📌 Brief Summary
이벤트 기반 아키텍처(EDA)는 시스템 내에서 의미 있는 상태 변화(이벤트)의 생성, 감지, 소비 및 반응을 중심으로 구성된 비동기식 소프트웨어 아키텍처 패러다임이다[1, 2]. 이벤트 생산자와 소비자가 직접적인 요청을 기다리지 않고 이벤트 채널을 통해 소통하므로, 구성 요소 간의 결합도가 매우 낮게 유지된다[1, 3, 4]. 이 아키텍처는 고도의 확장성, 내결함성 및 응답성을 제공하여 실시간 데이터 처리, IoT 워크로드 및 복잡하고 동적인 시스템에 특히 적합하다[4-6].

## 📖 Core 대Content
이벤트 기반 아키텍처는 시스템 결합도를 낮추고 비동기적 흐름을 제어하기 위해 여러 핵심 구성 요소와 토폴로지를 활용한다.

*   **주요 구성 요소**
    *   **이벤트 생산자(Event Producers):** 특정 동작이나 상태 변화가 발생했을 때 이벤트를 생성하고 감지하는 역할을 한다[3, 7].
    *   **이벤트 채널(Event Channels):** 메시지 브로커나 큐(예: Kafka, RabbitMQ)를 활용하여 생산자로부터 소비자에게 이벤트를 비동기적으로 전송하는 파이프라인 역할을 한다[7, 8].
    *   **이벤트 소비자(Event Consumers) / 처리기(Processors):** 전달된 이벤트를 수신하여 특정 비즈니스 로직을 수행하거나 데이터를 처리한다[3, 7]. 생산자는 누가 이벤트를 소비하는지 알 필요가 없다[9].

*   **주요 토폴로지(Topologies)**
    *   **브로커 토폴로지(Broker Topology):** 중앙의 조정자 없이 구성 요소들이 이벤트를 시스템 전체에 브로드캐스트하는 방식(Choreography)이다[10, 11]. 흐름이 단순하고 처리량이 높을 때 유리하며, 확장성과 결합도 감소에 최적화되어 있으나 중앙 제어가 없으므로 전체 트랜잭션을 추적하거나 오류를 복구하기는 어렵다[10, 12].
    *   **메디에이터 토폴로지(Mediator Topology):** 이벤트 메디에이터라는 중앙 컴포넌트가 존재하여 여러 단계의 워크플로우를 조정하고 오케스트레이션(Orchestration)하는 방식이다[10, 11, 13]. 복잡한 비즈니스 프로세스나 에러 핸들링이 필요한 경우 적합하지만, 메디에이터 자체가 성능의 병목(Bottleneck)이나 단일 장애점(Single Point of Failure)이 될 위험이 있다[10, 11].

*   **이벤트 페이로드 구조 전략**
    *   **모든 속성 포함:** 소비자가 외부 데이터 소스를 조회할 필요 없도록 모든 데이터를 전달한다. 빠르지만 페이로드 크기가 커져 대역폭 소비가 늘어나고, 여러 복제본으로 인한 데이터 일관성 문제가 발생할 수 있다[14, 15].
    *   **키(Key)/ID만 포함:** 최소한의 식별자만 포함하며 소비자가 필요한 데이터를 데이터베이스에서 직접 조회한다. 일관성 유지는 용이하지만 데이터 소스 조회가 빈번해져 성능 저하가 발생할 수 있다[14, 15].

*   **이벤트 처리 스타일**
    *   **단순 이벤트 처리(Simple Event Processing):** 단일 이벤트 발생 시 즉각적인 후속 조치를 유도한다[16].
    *   **이벤트 스트림 처리(Event Stream Processing):** 수많은 이벤트를 실시간으로 스트리밍하여 주목할 만한 정보를 걸러낸다[17].
    *   **복합 이벤트 처리(Complex Event Processing, CEP):** 장시간에 걸친 다양한 이벤트 간의 패턴을 분석하여 이상 징후나 기회 등 복합적인 상황을 추론한다[18].

## ⚖️ Trade-offs & Caveats
이벤트 기반 아키텍처는 고도의 확장성과 비결합성을 제공하지만, 분산 시스템 특유의 복잡성으로 인해 다음과 같은 한계와 반대 급부가 따른다.

*   **최종 일관성(Eventual Consistency) 감수:** 생산자와 소비자가 비동기 채널로 분리되어 있으므로, 데이터가 전체 시스템에 동기화되는 데 지연이 발생한다. 따라서 시스템은 순간적으로 데이터의 불일치 상태를 허용해야 하며, 아키텍트는 소비자가 과거의(stale) 데이터를 조회할 가능성을 고려해 설계해야 한다[19, 20].
*   **복잡한 에러 처리 및 트랜잭션 관리:** 비동기 환경에서는 요청-응답 모델처럼 즉각적인 예외 처리가 어렵다. 오류 발생 시 별도의 에러 처리기나 데드 레터 큐(DLQ)를 구축해야 하며, 복수의 서비스에 걸친 트랜잭션이 실패할 경우 이를 취소하기 위해 보상 트랜잭션(Compensating Transaction)을 논리적으로 구현해야 한다[20].
*   **관측성(Observability) 및 디버깅의 어려움:** 공유된 호출 스택(Call stack)이 없기 때문에 단일 비즈니스 트랜잭션을 추적하기 어렵다. 이를 극복하려면 모든 이벤트에 상관관계 ID(Correlation ID)를 포함시켜 시스템 전체의 로그를 연결하는 분산 트레이싱을 도입해야 한다[21].
*   **순서 보장 및 멱등성 문제:** 성능과 확장성을 위해 동일한 처리기의 여러 인스턴스가 동시에 실행될 경우, 이벤트의 처리 순서가 뒤섞일 수 있다. 이로 인한 오류를 방지하려면 로직을 멱등성(Idempotent, 여러 번 처리해도 결과가 동일함) 있게 구현하거나 순서를 강제하는 추가적인 설계가 필수적이다[20].
*   **스키마 진화(Schema Evolution) 관리:** 생산자와 소비자가 독립적으로 배포되므로, 생산자가 이벤트의 구조(스키마)를 변경할 경우 이를 이해하지 못하는 구버전 소비자에 장애가 발생할 수 있다. 초기에 명확한 스키마 버전 관리 전략이 수립되어야 한다[21].

## 🔗 Knowledge Connections

### Related Concepts

#### [토폴로지 및 설계 구조]
- [[Broker Topology]]
  - 연결 이유: EDA의 이벤트 흐름을 제어하는 가장 기본적인 구조 중 하나이다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 중앙 오케스트레이션 없이 브로드캐스트와 자율적인 구독을 통해 시스템이 성능과 확장성을 극대화하는 방식 및 그에 따른 한계점[10, 11, 22].
- [[Mediator Topology]]
  - 연결 이유: 복잡한 이벤트 워크플로우를 중앙에서 제어하기 위한 EDA의 대안적 구조이다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 중앙 집중식 큐와 메디에이터를 통해 오류 복구와 조건부 비즈니스 로직을 다루는 방법[10, 11, 13, 23].

#### [아키텍처 및 시스템 패턴]
- [[Microservices Architecture]]
  - 연결 이유: EDA와 결합하여 대규모 분산 환경에서 각각의 서비스가 비동기적으로 통신하도록 구성할 때 자주 사용된다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 개별 서비스가 어떻게 독립적인 데이터베이스를 유지하면서도, 이벤트를 통해 시스템 전반의 데이터를 통합하고 상호 작용하는지[24, 25].
- [[Complex Event Processing (CEP)]]
  - 연결 이유: EDA 시스템이 고도화될 때 적용되는 대표적인 이벤트 분석 및 처리 기법이다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 시공간적 인과관계를 가진 다양한 단순 이벤트를 융합하여 이상 징후, 위협 또는 비즈니스 기회로 추론해 내는 원리[18].

#### [데이터 관리 및 일관성 메커니즘]
- [[Eventual Consistency]]
  - 연결 이유: EDA에서 컴포넌트 간 비동기적 결합 해제로 인해 필연적으로 발생하는 데이터 특성이다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 즉각적인 일관성(Strong Consistency)을 포기하는 대신 시스템 가용성(Availability)과 확장성을 얻게 되는 분산 컴퓨팅의 트레이드오프 원리[20].
- [[Event Sourcing]]
  - 연결 이유: 상태의 최종 결과만 저장하는 대신 애플리케이션의 상태 변화(이벤트) 전체를 불변의 로그로 저장하는 패턴으로, EDA와 강한 시너지를 낸다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 과거 이벤트 재실행(Replay)을 통한 시스템 상태 복원, 완벽한 감사(Audit) 추적, 비즈니스 유연성 향상 기법[26, 27].

### Deeper Research Questions

- 대규모 분산 EDA 시스템에서 이벤트 스트림의 순서 보장(Ordering)과 '정확히 한 번 처리(Exactly-once processing)'를 기술적으로 어떻게 최적화하여 달성할 수 있는가?
- 이벤트 브로커 토폴로지와 메디에이터 토폴로지를 혼합한 하이브리드 아키텍처를 설계할 때, 각 토폴로지를 적용할 경계(Bounded Context)를 결정하는 최적의 기준은 무엇인가?
- EDA에서 이벤트 페이로드에 전체 데이터를 포함하는 방식과 키(Key)만 포함하는 방식을 사용할 때, 대용량 트래픽 환경에서 발생하는 성능(대역폭 소비) 및 일관성 차이의 실제 사례는 어떠한가?
- 비동기 처리 과정 중 발생하는 오류를 해결하기 위해 데드 레터 큐(DLQ)와 보상 트랜잭션(Compensating Transaction)을 결합한 에러 복구 파이프라인 설계 전략은 무엇인가?
- 이벤트 기반 시스템에서 컴포넌트가 중단 없이 업데이트되기 위해, 이벤트 스키마의 진화(Schema Evolution)와 버전 관리를 어떻게 전략적으로 수행해야 하는가?

### Practical Application Contexts

- **Implementation:** 비즈니스 이벤트를 생성하고 수신하기 위해 Kafka, RabbitMQ 등과 같은 메시지 브로커 또는 이벤트 스트리밍 플랫폼을 시스템 간의 통신 채널로 구축한다[7, 8].
- **System Design:** 요구사항에 맞추어 중앙집중적 워크플로우 제어가 필요하면 메디에이터 패턴을, 극단적인 확장성과 빠른 응답이 필요하면 브로커 패턴을 채택하며, 시스템의 부하를 조절하기 위해 적절한 페이로드 설계(Keys vs All attributes)를 진행한다[10, 14, 28].
- **Operation / Maintenance:** 개별 이벤트마다 Correlation ID를 필수적으로 포함시켜 분산 트레이싱(Distributed Tracing) 환경을 구축함으로써, 비동기 호출로 흩어진 시스템 내의 문제 발생 지점을 효율적으로 식별하고 디버깅한다[21].
- **Learning Path:** 기본적으로 시스템 간의 비동기 메시징 및 큐/스트림의 차이를 이해한 후, 최종 일관성(Eventual Consistency)을 보장하기 위한 분산 트랜잭션 설계(Saga 패턴 등) 및 에러 복원 전략으로 지식을 확장한다[20, 29, 30].
- **My Project Relevance:** 실시간으로 방대한 데이터나 트래픽을 처리해야 하는 시스템(예: IoT 센서 데이터 수집, 주식 거래 플랫폼, 대규모 이커머스 등) 혹은 모놀리식 시스템을 분리하여 마이크로서비스 간의 통신 결합도를 낮추어야 할 때 가장 핵심적인 설계 전략으로 검토된다[5, 7, 8, 31].

### Adjacent Topics

- [[Service-Oriented Architecture (SOA)]]
  - 확장 방향: 서비스를 네트워크 상에서 호출한다는 점은 유사하나, EDA의 비동기 트리거 방식과 달리 동기식 요청-응답(Request-Response) 패턴을 주로 사용하는 아키텍처로서 분산 통신의 설계 차이를 비교 분석한다[32, 33].
- [[Space-Based Architecture]]
  - 확장 방향: EDA와 마찬가지로 고트래픽 처리 및 동시성 문제를 해결하기 위한 아키텍처로, 관계형 데이터베이스의 병목을 인메모리 데이터 그리드(In-memory Data Grid)로 대체하여 확장성을 확보하는 원리를 확장 학습한다[34-36].

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