Event-driven Architecture (EDA, 이벤트 기반 아키텍처)란?

최근 백엔드 개발을 하면서 마이클로서비스 환경이나 대규모 시스템에서 자주 등장하는 개념 중 하나가 바로 Event-driven Architecture, 즉 이벤트 기반 아키텍처이다.
오늘은 이 개념에 대해 정리해보고자 한다.

---

📌 이벤트 기반 아키텍처란?

이벤트 기반 아키텍처는 말 그대로, 시스템이 어떤 '이벤트'가 발생했을 때 이를 감지하고 반응하는 구조를 의미한다.

우리가 흔히 쓰는 REST API는 요청과 응답이 명확하게 이어지는 동기 방식인 반면, 이벤트 기반은 이벤트가 발생하면 이를 다른 컴포넌트들이 비동기적으로 처리한다는 점에서 구조가 다르다.

아래 예시를 들어보자

• 사용자가 쇼핑몰에서 상품을 주문하면 -> OrderCreated라는 이벤트가 발생하고
• 이 이벤트를 수신한 결제 시스템이 자동으로 결제 준비를 시작하고
• 동시에 알림 서비스가 사용자에게 "주문이 접수되었습니다"라는 메시지를 보내는 식이다.

즉, 하나의 이벤트가 여러 시스템에 동시에 영향을 주고, 각 시스템은 그 이벤트에 적절히 반응만 하면 된다.

---

 

🧱 기본 구성 요소

구성 요소	설명
Event Producer	이벤트를 발생시키는 주체 (ex 주문 서비스)
Event	시스템에서 발생한 상태 변화 (ex OrderCreated)
Event Broker	이벤트를 중개해주는 시스템 (ex Kafka, RabbitMQ)
Event Consumer	이벤트를 받아 처리하는 컴포넌트 (ex 결제/알림 서비스)

 

여기서 중요한 건, Producer와 Consumer가 서로를 몰라도 동작할 수 있다는 점이다.

중간에 Broker가 있어서 메시지를 대신 전달해주기 때문에, 시스템 간 결합도는 매우 낮아지고 유연성은 훨씬 높아진다.

---

🔁 작동 흐름 예시

 

간단한 물류 시스템을 예제로 들어보자.

1. 사용자가 상품 주문 -> 주문 서비스에서 OrderCreated 이벤트 발생
2. Kafka에 이 이벤트가 전달됨
3. 배송 서비스는 해당 이벤트를 수신하고 -> 배송 준비 시작
4. 알림 서비스는 이벤트를 수신하고 -> 사용자에게 푸시 메시지 전송

한 번의 주문으로 여러 서비스가 독립적으로 동시에 반응할 수 있게 되는 구조다.

---

✅ 장점과 단점

 

👍 장점

• 확장성이 매우 뛰어남
  • 새로운 서비스가 생겨도 이벤트만 구독하면 됨
• 결합도가 낮아서 유지보수가 쉬움
• 비동기 처리로 성능에 유리
  • 대용량 트래픽도 유연하게 처리 가능
• 장애 격리 가능
  • 특정 서비스 장애가 전체에 영향을 주지 않음

👎 단점

• 구조가 복잡해짐
  • 메시지 흐름을 추적하기 어려움
• 디버깅 난이도 높음
  • 누가 이벤트를 처리했는지 로그 없으면 추적 불가
• 일관성 문제
  • 강한 트랜잭션이 어렵고 결국은 'eventual consistency'로 타협해야 함

---

🔍 실무에서 고려할 점

 

이벤트 기반 구조를 실제로 도입할 때는 다음과 같은 것들을 고민해야 한다.

• 이벤트 명명 규칙 (OrderCreated, PaymentCompleted 등)
• Payload 구조 표준화 (스키마 관리)
• 중복 이벤트 처리 -> Idempotency 처리 로직 반드시 필요
• 모니터링 -> 메시지 유실/오류 추적 위한 로그 설계
• 오류 처리 방식 -> DLQ(Dead Letter Queue) 사용 여부

---

❔REST 기반과는 뭐가 다른가요?

비교 항목	REST API	이벤트 기반
통신 방식	요청-응답 (동기)	메시지 기반 (비동기)
결합도	높음	낮음
확장성	상대적으로 낮음	높음
장애 전파	전체 장애로 번질 수 있음	서비스 간 격리 가능

---

❔실무에서 이벤트 처리 실패하면 어떻게 하나요?

• 재시도 로직을 넣거나
• DLQ(Dead Letter Queue)에 저장해서 따로 처리
• 모니터링 시스템과 연계해서 알림 띄우는 방식 사용

---

✨ 관련 개념도 같이 정리해보자

개념	설명
Idempotency (멱등성)	같은 이벤트를 여러 번 처리해도 결과가 같아야 함
Event Sourcing	데이터 상태를 저장하지 않고, 이벤트 자체를 저장
CQRS	조회/명령을 분리해서 처리하는 구조, 이벤트 기반과 자주 함께 사용됨

 

🚀 마무리

Event-driven Architecture는 단순히 "비동기" 아키텍처 그 이상이다.

설계 자체가 복잡해지고, 운영에 신경 쓸 것도 많지만, 확장성과 유연성을 동시에 가져갈 수 있는 강력한 아키텍처 패턴이다.

Kafka 같은 메시지 브로커를 활용해서 실제 시스템이 적용하는 경험을 통해, EDA가 왜 필요한지 더 분명하게 체감할 수 있을 거라 생각한다.