Event-Driven Architecture
▶아키텍처 다이어그램
점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다
서비스가 많아질수록 직접 호출 그래프는 빠르게 얽힙니다. 한 요청이 여러 후속 작업을 순차 호출하면 응답 시간도 길어지고, 중간 의존성 하나만 느려져도 전체 흐름이 흔들립니다. 누가 누구를 알아야 하는지도 점점 복잡해집니다. Event-Driven Architecture는 이 직접 결합을 낮추기 위해 사건의 발생 자체를 중심에 둡니다.
시스템이 커지면서 주문 하나, 사용자 행동 하나가 여러 후속 처리를 동시에 일으키는 일이 흔해졌습니다. 이 모든 흐름을 직접 호출로만 엮으면 응답 시간이 길어지고 변경 파급도 커졌습니다. 메시지 브로커와 스트리밍 인프라가 성숙해지면서, 사건을 발행하고 필요한 쪽이 구독하는 방식이 더 현실적인 선택지가 되었습니다. Event-Driven Architecture는 그 운영 압력의 산물입니다.
어떤 서비스가 상태 변화를 만들면 그 사실을 이벤트 채널에 발행하고, 필요한 소비자들이 각자 반응합니다. 생산자는 누가 듣는지 몰라도 되고, 소비자는 자기 책임에 맞는 처리만 수행하면 됩니다. 핵심은 호출 그래프의 중심을 '특정 서비스 주소'가 아니라 '발생한 사실'로 바꾸는 데 있습니다.
Event-Driven Architecture와 Client-Server는 둘 다 컴포넌트 간 통신 구조이지만, Client-Server는 요청자가 응답을 즉시 기대하는 대화 모델이고 Event-Driven Architecture는 누가 반응할지 분리한 채 사건을 흘려보내는 모델입니다. 전자는 즉시 결과가 중요한 상호작용에 강하고, 후자는 후속 처리와 fan-out에 강합니다.
한 사건이 재고, 결제, 알림, 분석처럼 여러 후속 처리를 시작해야 할 때 Event-Driven Architecture는 자연스럽습니다. 특히 생산자와 소비자의 릴리스 속도를 분리하고, 후속 기능을 나중에 붙이고 싶을 때 유리합니다. 다만 비동기라는 이유로 흐름이 보이지 않기 쉬우므로 이벤트 정의와 관측 가능성을 함께 챙겨야 합니다.
더 읽어보기
현재 페이지의 개념 설명을 본 뒤 배경 설명과 참고 문서를 이어서 볼 수 있습니다.