비동기 호출과 이벤트 기반 프로그래밍의 연결

어떻게 하면 모델링을 잘할 수 있을까?

May 15. 2025

지난 글까지 계속해서 연재 중인 글은 이벤트를 다루고 있습니다. 이렇게 머릿속에 이벤트에 대한 생각을 자주 담고 있는 상황에서 비슷한 글을 보면 연상 작용이 일어나고는 합니다.

서비스의 동기적 호출과 비동기 호출

메일링리스트로 받아 보는 <Synchronous vs Asynchronous Communication: When to Use What?>을 보고 이런저런 생각을 하다가 이벤트와 연관 지어 떠오른 생각을 기록으로 남깁니다. 꽤 잘 정리된 글입니다. 압축해서 표현한 그림을 한참 드려다 보고 여러 가지 생각을 했습니다.

그러다가 다음 내용과 연관 지으면 이벤트의 특성을 설명할 수 있는 내용이 생길 수 있다는 생각이 들었습니다.

It trades immediacy for flexibility.

비동기는 유연성을 얻기 위해 즉각적인 처리의 이점을 포기하는 것입니다. 예를 들어 볼까요? 은행이나 관공서에 가면 번호표 발급 시스템이 있는데, 가장 간단한 비동기 처리 예시라고 할 수 있습니다. 제 문제를 바로 해결해 주면 좋지만, 다양한 고객(민원인)의 요구를 공정하고 효과적으로 처리하기 위해 구상한 방법이겠죠.

비동기 호출과 이벤트 기반 프로그래밍의 연결

아무튼 번호를 발급받으면 대기를 하며 차례가 돌아올 때까지 기다립니다. 프로그램으로 따지면 어떤 알고리즘 조각이 일단 실행을 멈추는 것이죠. 그리고 다시 구동할 때는 해당 프로그램이 아닌 다른 프로그램이 구동 시점이나 조건을 정하게 됩니다. 위 그림에서 Service A가 Queue에 Request를 보낸 것이 번호표를 받고 기다리는 상태에 해당하고, 아래쪽 화살표로 Response 하는 구간이 바로 다른 프로그램 즉, Service B의 구동에 해당합니다.

여기가 제가 연재 중이던 이벤트에 대한 내용을 연상하게 되는 지점입니다.

동료의 메모를 보니 사건을 마주하는 사람들의 인식이 중요하다고 강조하고 있었습니다.

이벤트를 발행한 주체가 아니라 이벤트(혹은 사건)를 인식하는 주체가 관건이라는 의미인데요. 앞서 인용한 동기 그림에서 화살표(Make a Call)의 실행Operation 내용은 하나의 함수나 메소드로 구현됩니다. 반면에 비동기로 하면 실행 내용이 둘로 나뉘어야 합니다. Service A가 요청하는 부분과 Service B가 반응하는 부분으로 말이죠.

이벤트는 변경에 대해 알리는 표준화한 프로그래밍 단위

하지만, 비동기 호출은 이벤트와 직접적인 관련은 없습니다. 그런데, 만일 비동기 호출의 필요성이 늘어난다면 도입을 고려할 수 있는 '개념'이 될 수 있는 것이죠. 그리고, 마치 다음과 같은 쓸모를 만들어 낼 수 있습니다.

프로그램이 너무 복잡한데, 어떻게 명확하게 머리에 담을 방법이 없을까?

유사한 맥락에서 쓴 글이 바로 <이벤트는 변경을 알리는 표준 프로그래밍 단위>입니다. 인용한 그림을 보면 요청한 내용을 메시지로 담아서 보관Queue합니다. 메시지는 봉투 아이콘으로 표현하고 있습니다. 메시지 내용이 모두 같다면 Service B가 전부 처리해도 되겠지만, 메시지 내용이 다르다면 Service B는 if-else 구문으로 복잡해져 갈 것입니다.

이때, 마치 도로 회선을 놓듯이 사람이 인지할 수 있는 유형 별로 나누고 싶을 때 메시지를 이벤트 유형으로 대체하거나 메시지 속에 이벤트 유형을 구분하여 담을 수 있습니다. 이렇게 하는 방식을 이벤트 기반 프로그래밍이라고 말할 수 있습니다.

한편, <이벤트는 변경을 알리는 표준 프로그래밍 단위> 내용을 보면 이벤트는 액션이 아니라는 글이 있습니다. 이벤트를 바로 명령Command(데이터 수정을 암시)에 대응시키면 이벤트 기반 프로그래밍의 이점이 모두 사라집니다. 그래서 Consumer(인용한 그림에서 Service B)가 이벤트를 해석해서 필요한 명령을 내려야 한다는 것이죠.

이벤트 기반 프로그래밍과 CQRS

여기서 비동기에 이어 비대칭이 등장하게 됩니다. 사실 이 부분은 앞서 인용한 동료의 메모와도 연결되는데요. Service B를 다양한 유형의 이벤트 Comsumer들로 각각 담당한 전담 로직만 처리하는 구조가 되는 것이죠. 이렇게 되면 비동기와 비대칭으로 인해 프로그래밍 실행 상의 복잡도는 늘어나지만, 비즈니스 로직을 체계적으로 담을 수 있다는 점에서는 명료한 규칙이 생긴다는 이점을 얻을 수 있습니다.