이벤트 기반 아키텍처 설계

이벤트 기반 아키텍처란

이벤트 기반 아키텍처(event-driven architecture)는 시스템이 「무슨 일이 일어났다」는 사실을 이벤트로 발행하고, 관심 있는 다른 시스템이 그 이벤트를 구독해 각자 반응하는 구조다. 발행자는 누가 무엇을 하는지 모른다.

모듈 사이에 직접 호출이 늘면 기능 하나를 붙일 때마다 기존 코드를 고쳐야 하고, 순환 의존이 생기고, 모듈 경계가 무너진다. 이벤트는 이 호출 사슬을 끊는 수단이다.

구성 요소는 셋이다. 이벤트 생산자(event producer)가 이벤트를 발행하고, 이벤트 라우터(event router, 브로커·이벤트 버스)가 이벤트를 걸러 소비자에게 밀어 주며, 이벤트 소비자(event consumer)가 이벤트를 받아 자기 상태에 반영한다. 생산자는 소비자를 모르고 소비자끼리도 서로 모른다. 구현 패턴으로는 발행·구독, 이벤트 소싱과 CQRS, 사가가 있다.

잘 맞는 곳은 메타데이터·지표 수집, 서버·보안 로그 모으기, 서로 다른 기술로 된 시스템 잇기, 하나의 사건을 여러 곳에서 병렬로 처리하는 팬아웃이다.

시스템을 물리적으로 나누거나 호출을 비동기로 바꾸는 것만으로는 결합이 줄지 않는다. 「회원 탈퇴 후 쿠폰을 회수해 줘」라는 메시지를 비동기로 보내도, 발행자가 쿠폰 시스템의 할 일을 알고 있으면 논리적 의존은 그대로다. 결합을 끊는 것은 메시지의 의도다.

메시지, 이벤트, 커맨드

메시지(message) 는 시스템 사이에 오가는 전달 단위다. 봉투(헤더, ID, 타입)와 본문으로 이뤄지고, 브로커가 큐나 토픽으로 나른다. 메시지가 무엇을 담느냐에 따라 커맨드와 이벤트로 나뉜다. 「메시지는 지시, 이벤트는 사실」이라는 말은 이 구분을 줄인 것이다. 엄밀히는 둘 다 메시지이고, 커맨드는 받는 쪽에게 행동을 지시하는 메시지, 이벤트는 이미 일어난 사실을 알리는 메시지다.

메시지에 수신 측의 할 일이 들어가 있으면 이벤트 모양을 한 커맨드다. 큐와 이벤트 스트림의 구조 차이는 메시지 큐와 Kafka에 있다. 도메인의 핵심 행위가 무엇인지 잘 보이지 않으면 이벤트 스토밍으로 도메인 이벤트부터 찾는다(도메인 주도 설계(DDD)).

발행자가 수신자를 모른다는 것

이벤트의 세 계층

같은 「이벤트」라도 범위에 따라 역할과 설계 규칙이 다르다.

• 주 행위와 부가 정책을 이벤트로 나누면 도메인의 응집도가 올라가고, 부가 정책이 바뀌어도 주 행위 코드는 그대로다.
• 앱 이벤트 리스너는 트랜잭션의 어느 단계에서 실행할지(커밋 전·커밋 후)를 고를 수 있다. 부가 작업을 같은 트랜잭션에 넣을지, 커밋 뒤로 미룰지를 도메인 코드를 건드리지 않고 정한다.
• 프로세스 안에서 쓰는 발행기와 외부 메시징은 릴레이 컴포넌트로 잇는다. 발행·구독 인터페이스로 메시징 기술을 감싸 두면 브로커를 바꾸기도 쉽다.

페이로드 설계

외부 이벤트는 수신 측의 업무 변화에 끌려다니지 않게 작게 만든다. 수신 측마다 필요한 필드를 넣어 주기 시작하면 발행자가 수신 측의 요구를 알게 되고, 결합이 다시 생긴다.

이벤트는 봉투(envelope) 모양으로 감싼다. 발생 시각, 이벤트 타입, 원본 데이터를 함께 담아 역직렬화와 라우팅에 쓴다. 타입 정보를 보고 클래스를 골라 역직렬화하는 방식은 편하지만, 임의 타입을 만들 수 있게 열어 두면 호환성과 보안 문제가 생기므로 허용 목록으로 제한한다.

이벤트 스키마는 생산자와 여러 소비자 사이의 계약이므로, 바꿀 때는 하위 호환을 지킨다. 기본값 있는 필드만 추가하고, 이름·타입·의미는 바꾸지 않고, 깨지는 변경은 새 이벤트 타입·버전으로 낸다. 호환성 종류와 스키마 레지스트리는 데이터 관리 패턴의 스키마 진화에 있다.

메시징 브로커가 구독 필터(메시지 속성으로 거르기)를 지원하면, 구독자는 필요한 이벤트만 받고 애플리케이션에서 분류할 부담이 준다.

발행 시점과 정합성

도메인 데이터 저장과 이벤트 발행을 어떻게 맞추느냐가 가장 어려운 문제다.

아웃박스의 동작은 데이터 관리 패턴: CDC, 이벤트 소싱, CQRS, 최종 일관성에 있다. 발행한 이벤트를 모두 저장해 두면 조건별 재발행, 사용자 활동 추적, 흩어진 이력 테이블의 통합에도 쓸 수 있다. 대신 그 저장소의 쓰기·읽기 부하를 감당할 확장 계획이 필요하다.

전달 모델과 소비자

같은 역할의 서버 여러 대가 토픽을 구독하면 서버마다 같은 이벤트를 처리하는 중복이 생긴다. 그래서 구독 그룹 단위로는 토픽, 그룹 안에서는 큐처럼 동작하는 모델(Kafka 컨슈머 그룹, ActiveMQ Virtual Topic, SNS → SQS 팬아웃)을 쓴다(메시지 큐와 Kafka).

소비자 쪽에서 지킬 것은 다음과 같다.

• 멱등하게 처리한다. 대부분의 브로커는 최소 한 번(at-least-once) 전달이라 같은 메시지가 다시 온다. 이벤트 ID로 처리 여부를 기록하거나, 결과가 같아지는 연산으로 만든다(장애 확산을 막는 복원력 패턴).
• 순서는 공짜가 아니다. 순서 보장과 처리량은 맞바꾼다. 순서가 보장되지 않는 큐에서 선행 데이터가 아직 없으면 몇 번 재시도한 뒤 데드 레터 큐(DLQ) 로 보내 따로 처리한다.
• 원격 호출을 메시지로 바꾸면 시간적 결합이 사라진다. 받는 쪽 DB가 잠시 죽어도 메시지는 쌓였다가 복구 후 처리된다. 대신 즉시 결과가 필요한 작업(중복 사용을 막아야 하는 차감 등)은 동기로 남긴다.

브로커가 단일 장애점이 되지 않게

모든 이벤트가 브로커를 지나므로 브로커가 멈추면 시스템 전체가 멈춘 것처럼 보인다. 여러 겹으로 막는다.

이벤트를 기록하는 데이터 모델

금전·포인트처럼 이력이 중요한 데이터는 수정·삭제 없이 행을 추가만 하는(insert-only) 원장 모델이 잘 맞는다.

• 적립·사용·만료·취소를 모두 새 행으로 쌓는다. 잔액은 합계이거나 따로 관리하는 스냅샷이다.
• 차감과 만료를 적립 건 단위로 추적하는 상세 테이블을 두면 「어느 적립분에서 얼마가 빠졌나」 계산이 단순해진다.
• 누락이나 오류는 기존 행을 고치지 않고 보정 행을 추가해 바로잡으므로 변경 이력이 그대로 남는다.

이 생각을 극단까지 밀면 상태 대신 이벤트 자체를 저장하는 이벤트 소싱이 된다(데이터 관리 패턴: CDC, 이벤트 소싱, CQRS, 최종 일관성).

불변성과 정정

이벤트는 이미 일어난 사실이므로 고치거나 지우지 않는다(immutability).

과거 이벤트가 틀렸으면 새 이벤트로 바로잡는다.

정정 이벤트에는 원 이벤트 ID와 사유를 담아 「무엇을 왜 고쳤나」가 기록에 남게 한다. 개인 정보 삭제처럼 정말로 지워야 하는 경우는 데이터 관리 패턴의 crypto-shredding을 쓴다.

조회 모델 분리와 재처리

여러 원천 시스템의 데이터를 화면 하나에 모아 보여 줘야 할 때, 조회할 때마다 원천을 호출하면 원천 장애가 조회 장애로 번진다. 대신 원천의 변경 이벤트를 구독해 조회 전용 저장소를 서비스 관점으로 다시 만든다(CQRS식 읽기 모델).

flowchart LR
  src["원천 시스템들"] -->|"변경 이벤트"| h["이벤트 처리기"] --> st["조회 전용 저장소"] --> api["조회 API"]
  re["재처리 배치<br/>(전체 재적재 / 특정 시점 이후 / 개별 건)"] --> h

• 조회 경로는 쓰기 쪽 시스템을 직접 부르지 않는다. 한쪽 장애가 다른 쪽으로 퍼지지 않는다.
• 이벤트는 유실되거나 잘못 처리될 수 있다. 전체 재적재, 특정 시점 이후 재갱신, 개별 데이터 갱신 세 가지 재처리 경로를 처음부터 열어 두면 장애 복구와 정합성 보정이 쉽다.
• 처리 성공·실패·건너뜀 같은 도메인 지표를 표준 메트릭에 더해 두면 이벤트 흐름이 눈에 보인다.

기존 시스템에 영향 없이 새 기능 붙이기

트래픽이 큰 기존 시스템에 새 기능(예: 실시간 갱신)을 붙일 때도 이벤트가 유용하다. 기존 시스템은 이미 내던 이벤트를 그대로 발행하고, 새 기능은 그 이벤트를 구독하는 독립된 경로로 만든다. 새 기능이 무너져도 기존 기능(읽기·쓰기)은 영향을 받지 않는다. 역할은 가능한 한 잘게 나눈다. 모듈 하나가 하는 일이 적을수록 장애 원인을 찾기 쉽다.

flowchart LR
  s["기존 서비스"] -->|"이벤트"| b["브로커"] --> p["메시지 가공기"] --> ch["Pub/Sub 채널"] --> rt["실시간 서버들"] --> c["클라이언트"]

실시간 서버 쪽 설계는 실시간 웹소켓 서버 설계에 있다.

요청-응답과 비교한 장단점

장점 셋: 서비스끼리의 결합이 줄어 독립적으로 배포·확장하고, 장애가 번지지 않고 버퍼링되며, 같은 이벤트로 새 기능을 기존 코드 수정 없이 붙인다.

단점 셋:

• 흐름이 코드에 드러나지 않는다. 이벤트가 어디서 나와 어디로 가는지 문서·추적 도구 없이는 파악하기 어렵다.
• 최종 일관성을 받아들여야 한다. 사용자에게 「방금 한 일」이 바로 보여야 하는 화면은 따로 설계한다.
• 중복, 유실, 순서 뒤바뀜, 스키마 호환을 모두 소비자와 운영 쪽에서 다뤄야 한다.

마이크로서비스 사이 통신을 고를 때도 이 비교가 기준이다. 호출자가 결과를 받아야 다음으로 갈 수 있으면(재고 확인 후 주문, 로그인) 동기 API로, 다른 서비스가 알기만 하면 되는 사실(주문 완료 → 알림·적립·통계)이면 이벤트로 보낸다. 오래 걸리는 작업은 비동기 요청-응답(접수 후 상태 조회)으로 뗀다(분산 시스템의 통신·데이터 흐름 패턴).

정리

• 결합을 끊는 것은 비동기가 아니라 이벤트의 의도다. 사실을 알리고, 할 일은 구독자가 정한다.
• 이벤트는 앱·내부·외부 계층으로 나누고, 외부 이벤트의 페이로드는 작게 닫아 둔다.
• 저장과 발행의 정합성은 트랜잭셔널 아웃박스로 맞추고, 아웃박스와 브로커 복제로 브로커가 단일 장애점이 되지 않게 한다.
• 이벤트는 불변이다. 틀린 사실은 역분개·보정 이벤트로 바로잡는다.
• 소비자는 멱등하게, 순서는 필요한 만큼만, 실패는 DLQ와 재처리 경로로 다룬다.
• 잘 나눈 이벤트 경계는 나중에 서비스를 떼어 낼 때의 경계가 된다.

더 읽을거리: 「분산 시스템에서 데이터를 전달하는 효율적인 방법」(우아한테크 영상)

관련 노트: 분산 트랜잭션: 2PC와 사가, Kafka 운영: 복제, 컨슈머 그룹, 튜닝, 모니터링, 데이터 관리 패턴: CDC, 이벤트 소싱, CQRS, 최종 일관성, 메시지 큐와 Kafka, 마이크로서비스 아키텍처, 도메인 주도 설계(DDD), 장애 확산을 막는 복원력 패턴, 실시간 웹소켓 서버 설계