이벤트 기반 아키텍처(EDA)란?

이벤트 기반 아키텍처는 서비스가 불변의 사실을 이벤트로 알리고 소비자가 각자 독립적으로 반응하는 설계 방식입니다. 벤더 페이지들이 건너뛰는 정확성은 두 단어에 있습니다. 이벤트는 불변의 과거형 사실이고(PlaceOrder가 아니라 OrderPlaced), 생산자는 누가 반응하는지 알지도 못하고 신경 쓰지도 않습니다. 그 무관심이 곧 아키텍처입니다. 소비자는 생산자가 코드 한 줄 바꾸지 않아도 추가되고, 제거되고, 고장 날 수 있습니다. 가장 문자 그대로의 디커플링입니다. 그리고 EDA는 신앙이 아니라 스펙트럼입니다. 웹훅 하나도 이벤트 기반이고, 거대한 스트리밍 인프라도 마찬가지이며, 건강한 시스템 대부분은 그 둘의 하이브리드입니다.

핵심 요약

하나의 사실, 여러 반응

// JavaScript — Cloud Code (cloud/main.js)
// Everyday EDA: the write IS the event; consumers react independently
Parse.Cloud.afterSave('Order', async (req) => {
  const order = req.object;
  const becamePlaced = order.get('status') === 'placed' &&
    req.original?.get('status') !== 'placed';
  if (!becamePlaced) return;

  // Consumers of one fact — none knows about the others:
  await Parse.Cloud.httpRequest({          // fulfillment system (webhook)
    method: 'POST', url: process.env.FULFILL_WEBHOOK,
    body: { event: 'order.placed', id: order.id },
  });
  await enqueueConfirmationEmail(order);   // async job queue
  // Live Query pushes the change to every open dashboard automatically
});

// Flutter / Dart — Back4app Flutter SDK
// The client as event consumer: subscribe to facts, react on arrival
final orders = QueryBuilder<ParseObject>(ParseObject('Order'))
  ..whereEqualTo('status', 'placed');
final sub = await LiveQuery().client.subscribe(orders);
sub.on(LiveQueryEvent.create, (order) => showNewOrder(order));
// Nobody called this screen — it REACTED to an event, like every
// other consumer of "order placed": fulfillment, email, analytics.

// iOS / Swift — Back4app Swift SDK
// The client as event consumer: subscribe to facts, react on arrival
let orders = Order.query("status" == "placed")
let sub = try await orders.subscribe()
sub.handleEvent { _, event in
    if case .created(let order) = event { showNewOrder(order) }
}
// Nobody called this screen — it REACTED to an event, like every
// other consumer of "order placed": fulfillment, email, analytics.

// Android / Kotlin — Back4app Android SDK
// The client as event consumer: subscribe to facts, react on arrival
val orders = ParseQuery.getQuery<ParseObject>("Order")
orders.whereEqualTo("status", "placed")
val sub = ParseLiveQueryClient.Factory.getClient().subscribe(orders)
sub.handleEvent(SubscriptionHandling.Event.CREATE) { _, order ->
    showNewOrder(order)
}
// Nobody called this screen — it REACTED to an event, like every
// other consumer of "order placed": fulfillment, email, analytics.

하나의 사실(주문 접수)과 서로의 존재를 모르는 네 개의 소비자가 있습니다. 웹훅으로 통보받는 주문 처리 시스템, 큐에 들어가는 이메일 작업, 수치를 집계하는 분석, 라이브 구독으로 갱신되는 대시보드입니다. 다섯 번째 소비자를 추가해도 상류(upstream)에서는 아무것도 바뀌지 않습니다. 저장 한 번에 이 아키텍처의 핵심 주장이 모두 담겨 있습니다.

용어 정리

검색 결과 상위 페이지들의 용어 혼란을 표 하나로 정리합니다. 세 가지 메시지 유형을 전송 방식이 아니라 의도로 구분합니다.

Fowler의 경고는 그대로 옮길 가치가 있습니다. 수동 공격적 명령(passive-aggressive command)을 경계해야 합니다. 생산자가 이벤트라고 내보내면서 실은 특정 소비자 하나가 행동하기를 요구하는 “이벤트”를 말합니다. 그 소비자가 응답하지 않을 때 흐름이 깨진다면 그것은 처음부터 명령이었고, 이벤트라는 이름은 결합을 숨겼을 뿐입니다. (인프라 용어인 브로커, 라우터, 버스, 채널, 토픽은 가운데 상자를 가리키는 거의 같은 말입니다. 그 장치는 pub/sub 항목에서 다루며, EDA는 그것을 일반화한 아키텍처입니다.)

이벤트 기반 vs. 요청-응답

한 문장 규칙은 이렇습니다. 호출자가 계속 진행하는 데 결과가 필요하다면 요청-응답, 어떤 반응이 시작되기 전에 생산자의 일이 끝난다면 이벤트입니다. 주문 접수에는 동기적인 답(“성공했습니까?”)이 필요합니다. 그 이후의 모든 것, 즉 이메일, 주문 처리, 분석은 하나의 사실에 대한 반응입니다. 실제 시스템이 타협의 결과가 아니라 설계에 의해 하이브리드가 되는 이유입니다.

Fowler의 세 가지 유형과 이벤트 소싱의 실제 위치

회의 시간을 아껴 주는 구분이 있습니다. 이벤트 소싱은 한 시스템이 데이터를 저장하는 방식이고, EDA는 시스템들이 대화하는 방식입니다. 둘은 함께 쓸 수 있지만 어느 쪽도 다른 쪽을 요구하지 않습니다. 벤더들이 흐리는 선이 하나 더 있습니다. pub/sub 전달은 잊어버립니다. 늦게 들어온 구독자는 자신이 도착하기 전에 발생한 이벤트를 놓칩니다. 반면 스트리밍(Kafka 방식의 순서 있는 로그)은 기억하므로 소비자가 어느 지점에서든 재생할 수 있습니다. 이력이 제품의 일부인지에 따라 선택하는 것이 좋습니다.

코레오그래피 vs. 오케스트레이션

오케스트레이션 항목과 공유하는 거울상 규칙입니다. 누군가 워크플로의 결과를 책임져야 한다면 오케스트레이션을, 생산자가 다음에 일어날 일에 정말로 관심이 없다면 코레오그래피를 선택합니다. 여러 서비스에 걸친 긴 비즈니스 트랜잭션은 어느 쪽이든 사가 형태를 띱니다. 이벤트나 오케스트레이터로 연결된 로컬 트랜잭션이며, 롤백이 아니라 보상 트랜잭션으로 되돌립니다.

일상 속의 EDA: 브로커 없이

아키텍처 중심의 글들이 결코 쓰지 않는 부분입니다. 대부분의 앱 개발자는 메시지 브로커 하나 없이 이미 이벤트 기반 패턴을 운영하고 있습니다. beforeSave/afterSave 트리거는 데이터 변경 이벤트의 소비자입니다. 웹훅은 평범한 HTTP로 회사의 경계를 넘는 이벤트입니다. 라이브 쿼리는 클라이언트를 구독자로 둔 pub/sub입니다. 트리거가 큐에 넣는 백그라운드 작업은 비동기 작업을 낳는 이벤트입니다. 위의 코드 탭이 정확히 이 스택입니다. 쓰기가 이벤트이고, 트리거가 라우터이며, 소비자는 웹훅, 큐, 구독입니다. 전용 브로커(Kafka, RabbitMQ, NATS, 그리고 표준 봉투 형식인 CloudEvents)는 이벤트 양, 재생, 팀 간 계약이 요구할 때 비로소 운영 부담만큼의 값을 합니다. 아키텍처는 그보다 훨씬 일찍 시작되며, “브로커가 필요합니까?”라는 질문은 대개 스스로 답을 냅니다. 아직은 아닙니다.

일반적인 사용 사례

• 주문과 결제 흐름: 하나의 사실, 여러 부서. 전형적인 전자상거래 파이프라인입니다.
• 시스템 간 통합: 서로 다른 팀이 소유한 서비스가 직접 호출이나 공유 배포 없이 반응합니다.
• 실시간 기능: 대시보드, 피드, 프레즌스를 클라이언트 측의 이벤트 소비로 구현합니다.
• 급증하는 워크로드: 큐가 버스트를 완충해 소비자가 자기 속도로 처리합니다.
• 감사와 재생: “무슨 일이 어떤 순서로 일어났는가” 자체가 제품인 스트리밍 로그입니다.

이벤트 기반으로 가야 할까? 결정 매트릭스

한계와 트레이드오프

• 디버깅에서 콜 스택이 사라집니다. 다섯 번의 비동기 홉으로 퍼지는 요청은 첫 이벤트부터 전달된 상관관계 ID로만 추적할 수 있습니다. 나중에 덧붙이기는 고통스러우므로 첫날부터 연결해 두는 것이 좋습니다.
• 최종 일관성이 UI까지 닿습니다. 사용자가 프로필을 수정했는데 다음 화면에 예전 이름이 보입니다. UX를 그에 맞게 설계하거나 그 경로를 동기식으로 유지해야 합니다.
• 중복은 계약 사항입니다. 최소 한 번(at-least-once) 전달은 멱등한 소비자를 필수로 만듭니다. 큐가 부과하는 것과 같은 계약입니다. 같은 장치이기 때문입니다.
• 스키마가 소비자의 발밑에서 진화합니다. 이벤트는 알 수 없는 구독자와 맺는 계약입니다. 변경은 추가 방식으로만 하고, 호환성을 깨는 변경에는 버전이 붙은 토픽을 쓰며, 모든 곳에 관대한 리더(tolerant reader)를 두어야 합니다.
• 창발적 워크플로는 숨어 버립니다. 순수한 코레오그래피에서는 아무도 비즈니스 프로세스를 가리킬 수 없습니다. 감사자나 온콜 엔지니어가 그래야 할 때는 오케스트레이터를 추가해야 합니다.

Back4app에서의 이벤트 기반 패턴

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 앞의 일상 속의 EDA 절은 이 플랫폼의 기능 목록을 아키텍처로 읽은 것입니다. 모든 저장은 이벤트이고, afterSave 트리거는 JavaScript 생태계 전체를 쓸 수 있는 서버 측 소비자이며, Live Query는 관리형 웹소켓을 통해 사실을 클라이언트로 팬아웃하고, 웹훅은 이를 외부 시스템으로 전달하며, 백그라운드 작업은 느린 반응을 흡수합니다. 코드 탭은 주문 저장 한 번에서 시작되는 전체 루프를 보여 줍니다. 이 글이 강조하는 규율(멱등한 after 훅, 과거형으로 생각하기, 호출자가 답을 필요로 하는 곳의 동기 처리)은 여전히 사용자의 몫입니다. 반면 브로커 형태의 인프라(팬아웃, 전달, 연결 관리)는 플랫폼 동작으로 제공되며, 나중에 전용 스트리밍 브로커로 옮겨 가는 것은 이 아키텍처에 무언가를 더하는 일이지 다시 쓰는 일이 아닙니다.