2nd/10_Wiki/Topics/Architecture/Event-Driven_Architecture.md

---
category: Architecture
tags: [auto-wikified, technical-documentation, architecture]
title: Event-Driven Architecture
description: "Event-Driven Architecture(이벤트 기반 아키텍처)는 메시지 큐와 비동기 메시징을 활용하여 시스템 구성 요소 간에 이벤트를 전달하고 처리하는 소프트웨어 설계 방식입니다."
last_updated: 2026-05-04
---

# Event-Driven Architecture

## 📌 Brief Summary
Event-Driven Architecture(이벤트 기반 아키텍처)는 메시지 큐와 비동기 메시징을 활용하여 시스템 구성 요소 간에 이벤트를 전달하고 처리하는 소프트웨어 설계 방식입니다. [1, 2] Spring Boot와 NestJS 등의 현대적 백엔드 프레임워크에서 마이크로서비스 간의 통신을 위해 널리 지원되며, 메일, 알림, 로깅과 같은 비동기 작업 처리에 필수적으로 사용됩니다. [1, 3, 4] 확장성과 시스템 효율성을 확보하기 위해 대규모 트래픽을 다루는 시스템(예: 맥도날드)에서 활용하는 핵심 아키텍처 패턴입니다. [5]

## 📖 Core Content
* **프레임워크별 지원 방식:** 
  Spring Boot는 Spring AMQP, Spring Kafka 등을 통해 이벤트 기반 아키텍처와 메시징 패턴을 적극적으로 지원합니다. [6] 반면, NestJS는 `@nestjs/microservices` 모듈을 통해 Redis, NATS, Kafka, RabbitMQ, gRPC 등 다양한 전송 계층(Transport layer)을 내장 지원하며, 요청-응답(request-response) 및 이벤트 기반(event-based) 메시지 패턴을 모두 처리할 수 있습니다. [3, 4, 6]
* **일관된 API와 전환의 용이성:** 
  NestJS의 경우 다양한 메시지 브로커 전송 계층 간의 API가 일관되게 제공되므로, 프로젝트 요구사항이나 환경 변화에 따라 메시지 브로커를 전환하는 작업이 매우 직관적이고 간단합니다. [4]
* **비동기 메시징의 활용 시점:** 
  메일 발송, 알림, 로깅, 아카이빙과 같은 작업은 비동기 메시징을 사용하여 처리하는 것이 권장됩니다. [1] 이는 시스템이 마이크로서비스로 완전히 분리되기 전인 20명 이하의 개발자가 참여하는 모놀리식(Monolith) 환경에서도 가급적 이른 시점에 도입하는 것이 좋습니다. [1]
* **실제 적용 사례:** 
  맥도날드(McDonald's)는 대규모 확장성(scalability)과 효율성을 달성하기 위해 이벤트 기반 아키텍처를 도입하여 시스템을 운영하는 대표적인 실전 사례 중 하나입니다. [5]

## ⚖️ Trade-offs & Caveats
* **동기식 프로토콜의 한계 극복과 복잡성 증가:** 
  HTTP는 동기식(Synchronous) 프로토콜이므로 트래픽이 높은 시스템에서는 제한 요소가 될 수 있습니다. 이를 극복하기 위해 자동 백프레셔(automatic back pressure) 기능이 있는 비동기 메시징이나 논블로킹(non-blocking) 통신 방식을 활용해야 합니다. [1]
* **분산 시스템 도입 시의 운영 오버헤드:** 
  이벤트 기반 통신을 위해 마이크로서비스 기반의 분산 시스템으로 전환하는 것은 개발 관점에서 복잡성을 줄여주지 않으며, 오히려 시스템의 구조적 복잡성을 증가시킵니다. [7] 따라서 이 패턴을 실전에 적용할 경우 배포를 위한 고도의 자동화(Automation) 및 오케스트레이션(Orchestration)이 필수적으로 요구됩니다. [7]

## 🔗 Knowledge Connections

### Related Concepts

#### [관계 유형 A (아키텍처/통신 패턴)]
- [[Asynchronous Messaging]]
  - 연결 이유: 이벤트 기반 아키텍처의 핵심 통신 방식으로, HTTP의 동기적 한계를 극복하기 위해 사용됩니다. [1]
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 이메일 발송, 로깅, 알림 등 즉각적인 응답이 필요 없는 논블로킹(Non-blocking) 백그라운드 작업의 비동기 처리 원리와 백프레셔(Back pressure) 메커니즘을 이해할 수 있습니다. [1]
- [[Microservices]]
  - 연결 이유: 단위 서비스 간의 결합도를 낮추고 통신하기 위해 이벤트 기반 아키텍처가 널리 사용됩니다. [3]
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 모놀리식 구조의 한계를 넘어 TCP, Redis, Kafka 등을 활용한 분산 시스템 내 서비스 간 데이터 교환 및 통신 전략을 설계하는 방법을 이해할 수 있습니다. [1, 3, 4]

#### [관계 유형 B (구현/활용 도구)]
- [[Kafka & RabbitMQ]]
  - 연결 이유: Spring Boot와 NestJS 프레임워크 모두에서 내장 지원하는 대표적인 메시지 브로커 전송 계층입니다. [2-4, 6]
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 대규모 애플리케이션에서 메시지 큐를 어떻게 연결하고 실제 데이터 파이프라인에서 이벤트 패턴을 구현하는지에 대한 기술적 상세를 알 수 있습니다. [4, 6]
- [[NestJS Microservices Module]]
  - 연결 이유: NestJS에서 다양한 메시지 브로커를 일관된 API로 묶어 이벤트 기반 통신을 쉽게 구현하도록 돕는 내장 모듈입니다. [4]
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 프레임워크가 강력한 추상화를 통해 인프라스트럭처(메시지 브로커) 교체를 어떻게 용이하게 만들고 개발 생산성을 높이는지에 대한 설계 원리를 이해할 수 있습니다. [4]

### Deeper Research Questions
- 트래픽이 많은 시스템에서 HTTP 동기화의 한계를 극복하기 위한 '자동 백프레셔(automatic back pressure)를 동반한 비동기 메시징 통신'은 구체적으로 어떻게 구현되며 어떤 제약 사항을 해결하는가?
- NestJS의 `@nestjs/microservices` 모듈을 활용할 때, 단일 애플리케이션 내에서 HTTP 트래픽과 이벤트 기반 마이크로서비스 전송을 동시에 처리하는 하이브리드(Hybrid) 애플리케이션은 아키텍처적으로 어떻게 구성되는가?
- Spring AMQP/Kafka 생태계와 NestJS의 마이크로서비스 전송 계층 간의 메시지 처리량(Throughput) 및 엔터프라이즈 프로덕션 환경에서의 성능 차이는 어떠한가?
- 맥도날드(McDonald's)는 이벤트 기반 아키텍처를 도입하여 대규모 트래픽 확장성과 효율성을 달성하기 위해 어떠한 세부 설계 원칙과 메시징 도구를 사용했는가?
- 이벤트 기반 아키텍처 채택으로 인해 불가피하게 증가하는 분산 시스템의 복잡성을 관리하기 위해 배포 자동화 및 오케스트레이션(Orchestration) 파이프라인을 어떻게 최적화해야 하는가?

### Practical Application Contexts
- **Implementation:** Java/Spring Boot 환경에서는 Spring AMQP 또는 Spring Kafka 모듈을 사용하여 구현하며, TypeScript/Node.js 환경에서는 NestJS의 마이크로서비스 트랜스포터를 통해 Kafka, RabbitMQ 등의 브로커를 연결하여 메시지 기반 패턴을 구현합니다. [4, 6]
- **System Design:** 애플리케이션 설계 시 메일 발송, 로깅, 알림 처리 등 즉각적인 응답이 필요 없는 작업을 식별하여, 동기식 HTTP에서 분리된 비동기 메시징(논블로킹) 기반의 워크플로우로 설계합니다. [1]
- **Operation / Maintenance:** 다수의 서비스 간에 이벤트 통신이 발생하여 시스템 복잡도가 크게 증가하므로, 안정적인 운영 및 유지보수를 위해서는 배포 프로세스의 고도화된 자동화와 컨테이너 오케스트레이션 환경 구축이 선행되어야 합니다. [7]
- **Learning Path:** 소규모 팀에서 단일 모놀리식 애플리케이션으로 개발을 시작하더라도 우선적으로 비동기 메시징 패턴을 도입하여 학습한 뒤, 시스템 규모 확장 시 점진적으로 다양한 전송 계층을 활용하는 마이크로서비스 아키텍처로 나아가는 경로를 취할 수 있습니다. [1, 3]
- **My Project Relevance:** 소스에 관련 정보가 부족합니다.

### Adjacent Topics
- [[Monolithic Architecture]]
  - 확장 방향: 이벤트 기반 마이크로서비스로 전환하기 전 단계로서 모놀리식 아키텍처의 한계를 비교 분석하고, 서비스 분리의 명확한 기준과 시점을 조사하는 방향으로 지식을 확장합니다.
- [[Distributed Systems Observability]]
  - 확장 방향: 이벤트가 여러 마이크로서비스를 거쳐 흐르는 분산 시스템의 특성상 에러와 성능 병목을 추적하기가 어렵기 때문에, 이를 해결하기 위한 로깅, 모니터링, 분산 트레이싱(Distributed Tracing) 기술로 지식을 확장합니다.

---
*Last updated: 2026-05-03*