기술사 학습노트 | imt-log

기술사 학습노트›시스템아키텍처›이벤트 드리븐 아키텍처

System Architecture · 정보관리기술사 / 컴퓨터시스템응용기술사

이벤트 드리븐 아키텍처(EDA, Event Driven Architecture)

시스템 상태 변화나 업무 사건을 이벤트로 발행하고, 서비스 간 직접 호출 의존성을 줄여 확장성·비동기성·실시간 처리 능력을 높이는 분산 시스템 아키텍처

정보관리기술사컴퓨터시스템응용기술사EDAEventDrivenArchitectureMessageBrokerKafkaPubSub비동기처리EventSourcingCQRS

Ⅰ.개요 및 등장배경

가. 정의

이벤트 드리븐 아키텍처(EDA, Event Driven Architecture)는 시스템 내부 또는 외부에서 발생한 상태 변화, 업무 사건, 사용자 행위, 센서 변화, 트랜잭션 결과를 이벤트(Event)로 표현하고, 이벤트 생산자(Producer)가 이를 발행하면 이벤트 브로커 또는 이벤트 버스를 통해 여러 소비자(Consumer)가 비동기적으로 처리하는 아키텍처이다. 여기서 이벤트는 “주문이 생성되었다”, “결제가 완료되었다”, “재고가 차감되었다”, “센서 온도가 임계치를 넘었다”와 같이 이미 발생한 사실을 의미한다.

EDA는 서비스 간 동기 호출을 줄이고 이벤트를 매개로 느슨한 결합(Loose Coupling)을 달성한다. 생산자는 이벤트를 발행할 뿐 누가 소비하는지 알 필요가 없고, 소비자는 필요한 이벤트를 구독하여 독립적으로 처리한다. 이 구조는 마이크로서비스, 실시간 데이터 처리, IoT, 금융 이상거래 탐지, 주문·결제·배송 연계, 클라우드 네이티브 시스템에서 높은 확장성과 장애 격리성을 제공한다.

나. 등장배경

• 동기 호출 기반 시스템의 한계: REST API 중심 동기 호출은 호출 체인이 길어질수록 장애 전파, 지연시간 증가, 결합도 증가 문제가 발생한다.
• 마이크로서비스 확산: 서비스가 세분화되면서 서비스 간 데이터 변경 사실을 안정적으로 전달하는 비동기 통합 방식이 필요해졌다.
• 실시간 처리 요구 증가: 금융 거래, 물류 추적, 추천, 알림, IoT, 모니터링에서 발생 즉시 처리하는 이벤트 기반 구조가 요구되었다.
• 클라우드 네이티브 환경 확대: 서버리스, 컨테이너, 오토스케일링 환경에서는 이벤트 기반 자동 확장과 비동기 처리가 적합하다.
• 데이터 중심 운영 강화: 업무 이벤트를 로그처럼 저장·분석하여 감사, 추적, 재처리, AI 분석에 활용할 필요가 커졌다.

다. 핵심 특징

EDA의 핵심은 비동기성, 느슨한 결합, 확장성, 실시간성, 장애 격리성이다. 이벤트 생산자는 소비자의 처리 완료를 기다리지 않아도 되므로 응답 지연을 줄일 수 있고, 소비자는 독립적으로 확장할 수 있다. 또한 새로운 기능이 필요할 때 기존 생산자를 수정하지 않고 새로운 소비자를 추가할 수 있다. 다만 이벤트 중복, 순서 보장, 메시지 유실, 재처리, 스키마 변경, 결과적 일관성(Eventual Consistency) 같은 분산 시스템 이슈를 반드시 설계해야 한다.

EDA는 업무 사건을 이벤트로 발행하고 브로커를 통해 소비자가 비동기 처리하는 분산 아키텍처이다.
기술사 답안에서는 Producer-Broker-Consumer 구조, Pub/Sub, 비동기 처리, 결과적 일관성, 재처리 전략을 함께 설명해야 한다.

Ⅱ.구성도 및 구성요소

가. EDA 구성도

나. 구성요소

구분	요소	설명
이벤트	Event	시스템에서 이미 발생한 상태 변화나 업무 사실이다. 예: 주문생성, 결제완료, 배송시작.
생산자	Producer	업무 처리 후 이벤트를 생성하여 브로커에 발행하는 서비스 또는 시스템이다.
브로커	Event Broker	이벤트를 수신, 저장, 라우팅, 전달하는 중간 계층이다. Kafka, RabbitMQ, Pulsar 등이 해당된다.
토픽	Topic	이벤트를 유형별로 분류하는 논리 채널이며, 여러 소비자가 독립적으로 구독할 수 있다.
큐	Queue	메시지를 소비자에게 작업 단위로 전달하는 구조이며, 일반적으로 한 메시지는 하나의 소비자가 처리한다.
소비자	Consumer	필요한 이벤트를 구독하여 후속 업무를 수행하는 서비스이다.
이벤트 저장소	Event Store	이벤트를 로그 형태로 보관하여 재처리, 감사, 상태 재구성에 활용한다.
스키마	Schema Registry	이벤트 구조와 버전을 관리하여 생산자와 소비자 간 호환성을 유지한다.
장애처리	Retry / DLQ	처리 실패 이벤트를 재시도하거나 Dead Letter Queue로 격리한다.
관측성	Monitoring / Tracing	이벤트 지연, 소비자 lag, 실패율, 처리량, 상관관계 ID를 추적한다.

EDA 구성요소는 Event, Producer, Broker, Topic/Queue, Consumer, Event Store, Schema Registry, Retry/DLQ, Observability로 정리된다.
Ⅱ.가 구성도에서는 이벤트 발행·구독 흐름과 장애처리·스키마·모니터링 같은 공통 관심사를 함께 표현해야 한다.

Ⅲ.동작방식 및 아키텍처

가. EDA 동작 절차

• 1단계 이벤트 발생: 주문 생성, 결제 승인, 파일 업로드, 센서 감지, DB 변경 등 업무 사건이 발생한다.
• 2단계 이벤트 생성: 생산자는 이벤트 ID, 발생시각, 이벤트 타입, 페이로드, 상관관계 ID, 버전 정보를 포함한 이벤트를 만든다.
• 3단계 이벤트 발행: 생산자는 이벤트 브로커의 토픽 또는 큐에 이벤트를 발행한다.
• 4단계 이벤트 저장·라우팅: 브로커는 이벤트를 저장하고 구독 규칙에 따라 소비자에게 전달한다.
• 5단계 이벤트 소비: 소비자는 이벤트를 수신하여 재고 차감, 알림 발송, 포인트 적립, 분석 적재 같은 후속 처리를 수행한다.
• 6단계 실패 처리: 소비 실패 시 재시도, 백오프, DLQ 격리, 수동 보정 또는 보상 트랜잭션을 수행한다.
• 7단계 모니터링: 이벤트 처리량, 지연시간, 컨슈머 lag, 실패율, 순서 오류, 중복 처리 여부를 관찰한다.

나. 이벤트 유형

유형	설명	예시
Domain Event	업무 도메인에서 발생한 의미 있는 상태 변화	OrderCreated, PaymentCompleted
Integration Event	서비스 간 통합을 위해 외부로 발행하는 이벤트	CustomerRegistered, ShipmentRequested
Notification Event	상태 변화 사실을 알리는 이벤트	EmailSendRequested, AlertRaised
Command Message	특정 작업을 수행하라는 지시 메시지	ReserveInventory, CancelOrder
CDC Event	DB 변경 내용을 캡처하여 발행하는 이벤트	RowInserted, RowUpdated
System Event	인프라 또는 운영 상태 변화 이벤트	InstanceStarted, CPUThresholdExceeded

다. Pub/Sub와 Queue 방식

EDA에서 Pub/Sub 방식은 하나의 이벤트를 여러 소비자가 독립적으로 구독하여 처리하는 구조이다. 예를 들어 주문 생성 이벤트를 재고 서비스, 알림 서비스, 분석 서비스가 각각 소비할 수 있다. 반면 Queue 방식은 메시지를 작업 단위로 분배하여 하나의 소비자 그룹 내에서 하나의 메시지를 한 소비자가 처리하는 구조이다. Pub/Sub는 확장성과 기능 추가에 유리하고, Queue는 작업 분산과 부하 제어에 유리하다.

라. Event Sourcing과 CQRS

Event Sourcing은 현재 상태만 저장하는 것이 아니라 상태 변경 이벤트 전체를 저장하고, 필요 시 이벤트를 재생하여 현재 상태를 복원하는 패턴이다. 이 방식은 감사 추적과 재처리에 강하지만 이벤트 버전 관리와 저장소 운영이 중요하다. CQRS(Command Query Responsibility Segregation)는 쓰기 모델과 읽기 모델을 분리하여 명령 처리와 조회 성능을 각각 최적화하는 패턴이다. EDA와 CQRS를 결합하면 쓰기 이벤트를 기반으로 조회 전용 뷰를 비동기 갱신할 수 있어 대규모 조회 시스템에 적합하다.

마. 결과적 일관성과 멱등성

EDA는 비동기 처리 특성상 모든 서비스의 상태가 즉시 일치하지 않고 시간이 지나며 일관성을 맞추는 결과적 일관성(Eventual Consistency)을 갖는다. 따라서 주문은 생성되었지만 재고 반영이나 알림 발송은 약간 늦을 수 있다. 또한 네트워크 장애나 재시도로 인해 동일 이벤트가 여러 번 전달될 수 있으므로 소비자는 멱등성(Idempotency)을 보장해야 한다. 멱등성이란 같은 이벤트를 여러 번 처리해도 결과가 한 번 처리한 것과 동일하도록 설계하는 것이다.

EDA는 이벤트 발생, 발행, 브로커 저장·라우팅, 소비, 실패 처리, 모니터링 순서로 동작한다.
결과적 일관성, 멱등성, 이벤트 순서, 중복 처리, DLQ는 EDA 설계에서 반드시 다뤄야 하는 핵심 쟁점이다.

Ⅳ.실무적용 및 사례

가. 산업별 적용 사례

분야	EDA 적용 방식	효과
전자상거래	주문 생성 이벤트를 기반으로 결제, 재고, 배송, 알림, 추천 서비스를 비동기 연계한다.	주문 처리 확장성 향상, 서비스 간 결합도 감소
금융	거래 이벤트를 실시간으로 분석하여 이상거래 탐지와 리스크 평가를 수행한다.	실시간 탐지, 감사 추적, 장애 격리
제조	설비 센서 이벤트를 수집하여 예지보전과 공정 이상탐지를 수행한다.	다운타임 감소, 생산 품질 향상
물류	배송 상태 변경 이벤트를 기반으로 고객 알림과 경로 최적화를 수행한다.	추적성 향상, 고객 경험 개선
클라우드 운영	인프라 이벤트를 기반으로 자동 확장, 장애 알림, 자동 복구를 수행한다.	운영 자동화와 복원력 향상
데이터 플랫폼	CDC 이벤트를 수집하여 데이터 레이크, DW, 검색 인덱스를 실시간 갱신한다.	실시간 분석과 데이터 동기화

나. 설계 원칙

• 이벤트는 명령보다 “발생한 사실” 중심으로 명명한다. 예: CreateOrder보다 OrderCreated.
• 이벤트 ID, 발생 시간, 이벤트 타입, 버전, 상관관계 ID를 포함하여 추적성을 확보한다.
• 소비자는 중복 이벤트를 견딜 수 있도록 멱등 처리 구조를 갖춘다.
• 중요 이벤트는 유실 방지를 위해 영속 저장, Ack, 재시도 정책을 설계한다.
• 스키마 호환성을 위해 Schema Registry와 버전 정책을 운영한다.
• 처리 실패 이벤트는 DLQ로 격리하고 재처리·보정 절차를 마련한다.
• 컨슈머 lag, 처리 지연, 실패율, 브로커 용량, 파티션 편중을 모니터링한다.
• 개인정보와 민감정보는 이벤트 페이로드에 최소화하고 암호화·마스킹 정책을 적용한다.

다. 주요 리스크와 대응

리스크	원인	대응 방안
이벤트 유실	브로커 장애, Ack 오류, 비영속 메시지 사용	영속 저장, 복제, Ack 정책, 재시도, 모니터링 적용
중복 처리	재시도, 네트워크 장애, at-least-once 전달	멱등 키, 처리 이력 테이블, 중복 제거 로직 적용
순서 불일치	파티션 분산, 병렬 소비, 재처리	키 기반 파티셔닝, 순서 보장 범위 정의, 버전 필드 적용
스키마 깨짐	이벤트 필드 삭제 또는 타입 변경	Schema Registry, 하위 호환 정책, 버전 관리 적용
장애 은닉	비동기 처리로 실패가 즉시 드러나지 않음	DLQ, 알림, 추적 ID, 대시보드, SLO 기반 모니터링
복잡도 증가	이벤트 흐름이 많아져 전체 업무 추적이 어려움	이벤트 카탈로그, 표준 네이밍, 분산 추적, 아키텍처 거버넌스 적용

라. 실무 운영 포인트

EDA는 단순히 메시지 브로커를 도입한다고 완성되지 않는다. 이벤트 표준, 토픽 설계, 스키마 버전, 소비자 책임 범위, 장애 처리, 관측성, 보안 정책이 함께 정립되어야 한다. 특히 비동기 구조에서는 장애가 조용히 누적될 수 있으므로 컨슈머 lag, DLQ 적재량, 처리 실패율, 재시도 폭증을 운영 지표로 관리해야 한다. 또한 이벤트가 조직 전체의 통합 언어가 되므로 도메인 이벤트 명세와 이벤트 카탈로그를 운영하면 서비스 간 협업과 변경관리가 쉬워진다.

실무 EDA는 전자상거래, 금융, 제조, 물류, 클라우드 운영, 데이터 플랫폼에서 확장성과 실시간성을 높이는 데 활용된다.
성공적인 EDA 도입은 브로커 선택보다 이벤트 표준화, 멱등성, DLQ, 스키마 관리, 모니터링 체계가 더 중요하다.

Ⅴ.비교분석 및 발전전망

가. EDA와 SOA/REST 비교

구분	EDA	REST 기반 동기 호출	SOA
통신 방식	비동기 이벤트 발행·구독	요청·응답 중심 동기 호출	서비스 계약 기반 통합
결합도	낮음	상대적으로 높음	중간
확장성	소비자 독립 확장 가능	호출 대상 서비스 성능에 영향	ESB 중심 확장
장애 영향	브로커 버퍼링으로 장애 격리 가능	호출 실패가 즉시 전파될 수 있음	중앙 통합 계층 장애 영향 가능
일관성	결과적 일관성 중심	즉시 일관성 구현이 상대적으로 쉬움	계약과 오케스트레이션 중심
적합 업무	실시간 이벤트, MSA, IoT, 알림, 분석	조회, 즉시 응답, 단순 API	기업 통합, 레거시 연계

나. Kafka와 RabbitMQ 비교

구분	Kafka	RabbitMQ
중심 모델	분산 로그 기반 이벤트 스트리밍	메시지 큐와 라우팅 중심
메시지 보관	일정 기간 보관 후 재처리 가능	소비 후 제거되는 큐 모델 중심
강점	고처리량, 순차 로그, 스트림 처리, 재생	복잡한 라우팅, 작업 큐, 다양한 프로토콜
적합 사례	로그 수집, CDC, 실시간 분석, 이벤트 소싱	작업 분산, 비동기 업무 처리, 명령 메시지
운영 포인트	파티션, 컨슈머 lag, 보존 기간, 스키마 관리	Exchange, Queue, Routing Key, Ack, DLQ 관리

다. 발전전망

• 클라우드 네이티브 EDA 확대: 서버리스 함수, 이벤트 라우터, 관리형 브로커를 활용한 이벤트 기반 시스템이 증가한다.
• Real-time Enterprise 확산: 업무 이벤트를 실시간 분석과 자동 의사결정에 활용하는 기업 구조가 강화된다.
• Event Mesh 발전: 멀티클라우드와 하이브리드 환경에서 이벤트를 글로벌하게 라우팅하는 구조가 확산된다.
• Data Streaming Platform화: Kafka와 같은 스트리밍 플랫폼이 단순 메시징을 넘어 데이터 통합과 분석 기반이 된다.
• EDA와 AI 결합: 실시간 이벤트를 기반으로 이상탐지, 추천, 예측 모델을 즉시 실행하는 구조가 확대된다.
• 거버넌스 강화: 이벤트 카탈로그, 스키마 정책, 데이터 계보, 개인정보 보호, 감사 추적이 필수 요건이 된다.

라. 기술사 답안 정리

이벤트 드리븐 아키텍처 답안은 “정의 → 등장배경 → 구성도 → 구성요소 → 동작 절차 → 이벤트 유형 → Pub/Sub·Queue → Event Sourcing·CQRS → 실무 적용 → 비교분석 → 발전전망” 순서로 작성하면 안정적이다. 구성도에는 Producer, Event Broker, Topic/Queue, Consumer, Event Store, Schema Registry, Retry/DLQ, Observability를 포함해야 한다. 또한 결과적 일관성, 멱등성, 이벤트 순서, 중복 처리, 스키마 진화, DLQ 같은 운영 이슈를 반드시 언급해야 한다. 마지막에는 클라우드 네이티브, Event Mesh, 실시간 분석, AI 연계, 이벤트 거버넌스를 제시하면 최신성과 실무성을 확보할 수 있다.

답안 암기 포인트: “EDA = Producer가 Event를 발행 → Broker가 라우팅·저장 → Consumer가 비동기 처리 → 느슨한 결합·확장성·실시간성 확보”로 정리하면 된다.

EDA는 이벤트 기반 비동기 통신으로 서비스 결합도를 낮추고 확장성과 실시간 처리 능력을 높이는 아키텍처이다.
향후 EDA는 클라우드 네이티브, Event Mesh, 실시간 데이터 스트리밍, AI 기반 자동화와 결합되어 핵심 시스템 통합 구조로 발전할 것이다.

블로그: 기술사 학습노트 · imt-log.tistory.com

← [시스템아키텍처] 목록