Event-Driven Architecture

주문 하나가 완료됐을 때 재고 차감, 결제 확인, 알림 발송, 분석 기록을 모두 처리해야 한다면, 이것을 순차 직접 호출로 엮으면 어떻게 될지 생각해 보십시오. 알림 서비스가 응답이 느리면 사용자의 주문 완료 응답도 함께 늦어집니다. 분석 서비스가 일시 장애라면 주문 전체가 실패한 것처럼 처리됩니다. 서비스가 하나 추가될 때마다 주문 서비스 코드를 열어 호출을 추가해야 하고, 누가 누구를 알아야 하는지가 시간이 지날수록 거미줄처럼 얽힙니다.

단일 서버가 모든 처리를 순서대로 수행하던 시절에는 직접 호출 방식이 자연스러웠습니다. 시스템이 커지면서 하나의 사용자 행동이 여러 후속 처리를 동시에 일으키는 경우가 많아졌고, 이를 모두 요청 경로 안에서 직접 처리하면 응답 시간이 길어지고 장애 파급도 커졌습니다. 메시지 브로커와 스트리밍 인프라가 성숙해지면서 사건을 발행하고 각 시스템이 독립적으로 반응하는 방식이 운영 현실과 더 잘 맞아떨어지기 시작했습니다. Event-Driven Architecture는 그 운영 압력 속에서 직접 결합을 낮추는 방향으로 자리 잡은 구조입니다.

어떤 서비스가 상태를 변경하면 그 사실을 이벤트 채널에 발행합니다. 구독하는 서비스들은 각자 관심 있는 이벤트를 수신해 자신의 책임에 맞는 처리를 수행합니다. 생산자는 소비자 목록을 알지 못하고, 소비자는 다른 소비자의 존재를 알지 못한 채 독립적으로 동작합니다. 새 소비자를 붙일 때 생산자 코드를 건드릴 필요가 없고, 소비자가 잠시 다운됐다가 복구돼도 이벤트를 나중에 처리할 수 있습니다.

Event-Driven Architecture와 Client-Server는 컴포넌트 간 통신 방식이라는 점에서 같은 문제를 다루지만 전제가 다릅니다. Client-Server는 호출자가 즉시 응답을 기대하는 구조라서 결과를 바로 알아야 하는 상호작용에 적합합니다. Event-Driven Architecture는 응답을 기다리지 않고 사건만 알리는 구조라서, 후속 처리가 여러 시스템에 걸쳐 있거나 처리 시점이 달라도 되는 흐름에 맞습니다. 사용자가 결과를 실시간으로 받아야 하는 경우라면 이벤트 방식만으로는 부족할 수 있습니다.

한 사건이 여러 후속 처리를 일으켜야 하고 그 처리들이 서로 독립적으로 실행되어도 되는 상황이라면 Event-Driven Architecture를 고려할 시점입니다. 특히 생산자와 소비자의 배포 주기를 분리하고 싶거나, 나중에 새 소비자를 붙일 가능성이 높을 때 유리합니다. 반면 흐름이 이벤트로 분산되면서 전체 처리 상태를 한눈에 보기 어려워지므로, 이벤트 정의를 명확히 유지하고 각 소비자의 처리 결과를 추적할 수 있는 관측 체계를 함께 갖춰야 합니다.