---
id: P-REINFORCE-WIKI-ARCH-EDA
title: "이벤트 기반 아키텍처 (Event-Driven Architecture, EDA)"
category: "10_Wiki/🏗️ Topics_Arch"
status: verified
canonical_id: ""
aliases: ["EDA", "이벤트 주도 설계", "비동기 메시징", "메시지 기반 아키텍처"]
duplicate_of: ""
source_trust_level: A
confidence_score: 1.0
tags: ["Architecture", "EDA", "Asynchronous", "Message_Broker", "Scalability"]
raw_sources: ["Datacollector_Export_2026-05-02"]
last_reinforced: 2026-05-02
github_commit: ""
---

# [[이벤트 기반 아키텍처 (Event-Driven Architecture, EDA)]]

## 1. 개요
이벤트 기반 아키텍처(EDA)는 시스템의 상태 변화를 '이벤트(Event)'라는 메시지로 표현하고, 이를 비동기적으로 주고받으며 상호작용하는 아키텍처 스타일이다. 생산자(Producer)와 소비자(Consumer)가 서로의 존재를 직접 알 필요가 없는 느슨한 결합(Loose Coupling)을 통해 고도로 확장 가능하고 탄력적인 시스템을 구축할 수 있다.

## 2. 핵심 구성 요소
- **이벤트 생산자 (Event Producers)**: 상태 변화를 감지하고 이벤트를 생성하여 발행하는 주체.
- **이벤트 브로커 (Event Broker)**: 생산자와 소비자 사이에서 이벤트를 수집, 저장, 라우팅하는 중계 인프라 (예: Kafka, RabbitMQ).
- **이벤트 소비자 (Event Consumers)**: 브로커를 구독(Subscribe)하고 있다가 특정 이벤트가 발생하면 비즈니스 로직을 실행하는 주체.
- **데드 레터 큐 (Dead Letter Queue, DLQ)**: 처리에 실패한 이벤트를 격리하여 분석 및 재처리를 가능하게 하는 보관소.

## 3. 실전 적용 가치
- **유연한 확장성**: 특정 소비자의 처리 성능이 부족할 경우, 생산자나 다른 소비자에게 영향을 주지 않고 해당 소비자만 수평 확장(Scale-out) 가능.
- **실시간 반응성**: 주식 가격 변동, 결제 완료 알림, IoT 센서 데이터 처리 등 즉각적인 반응이 필요한 도메인에 최적화.
- **시스템 복원력**: 특정 컴포넌트가 일시적으로 중단되어도 이벤트 브로커에 메시지가 보관되므로 시스템 전체의 데이터 유실 방지.

## 4. 트레이드오프 및 주의사항
- **운영 복잡도**: 분산 시스템 특유의 트랜잭션 관리(Saga 패턴 등), 이벤트 순서 보장, 메시지 유실 방지 등을 위한 고도의 운영 역량 필요.
- **멱등성 (Idempotency) 보장**: 네트워크 장애나 재시도로 인해 동일한 이벤트가 여러 번 전달될 수 있으므로, 소비자는 중복 처리에 대한 방어 로직을 반드시 갖춰야 함.
- **디버깅 및 추적의 어려움**: 직접적인 호출 스택이 존재하지 않으므로 분산 추적(Distributed Tracing) 도구 없이는 문제 발생 시 원인 파악이 힘듦.

## 5. 지식 연결 (Related)
- [[Microservices_Architecture]]: EDA가 서비스 간 통신을 위해 가장 흔히 채택되는 아키텍처 환경.
- [[CQRS_Pattern]]: 상태 변경 후 조회 모델을 업데이트하기 위해 EDA가 핵심 통신 수단으로 사용됨.
- [[Event_Storming]]: EDA의 핵심인 도메인 이벤트를 도출하기 위한 설계 기법.

## 🧪 검증 상태 (Validation)
- **정보 상태**: 검증 완료 (Verified)
- **출처 신뢰도**: A
- **검토 이유**: 비동기 워크플로우와 고가용성 시스템 구축을 위한 현대적 분산 아키텍처의 핵심 패러다임 정립.