한꺼번에 짊어지던 배치를 내려놓고, 하나씩 흘려보내는 워크플로로

Temporal 도입은 부담스러웠고, 그렇다고 배치를 그대로 둘 순 없었습니다 – 입맛대로 골라 Claude로 뚝딱 만든 워크플로 엔진 개발기 ℹ️ 이 글에 등장하는 수치와 설정값(대기 시간, 타임아웃, 재시도 횟수 등)은 이해를 돕기 위한 예시이며, 실제 운영 설정과는 다릅니다. 들어가는 말 배달의민족 사장님이 사용하는 포스(POS)의 백엔드를 만들다 보면, "지금 당장 처리할 일"보다 "시간이 흐른 뒤에 처리해야 할 일"이 의외로 많습니다. 주문이 들어왔는데 일정 시간 접수되지 않으면 알림을 보내고, 사장님 응답이 없으면 자동으로 거절하며, 픽업 후 일정 시간이 지나면 자동으로 주문을 완료 처리합니다. 이런 "긴 시간을 가지는 상태 머신"을 우리는 오랫동안 배치 잡으로 처리해 왔습니다. 배치는 편합니다. 주기적으로 돌면서 조건에 맞는 대상을 한꺼번에 훑어 처리하면 되니까요. 그런데 주문이 몰리는 피크타임이 되면 이야기가 달라집니다. 한 번 돌 때 훑어야 할 대상이 급격히 늘고, 그만큼 한 사이클의 부담도 커집니다. "한꺼번에" 처리하는 방식의 숙명입니다. 그래서 생각했습니다. 주문 하나하나를 "그 주문만의 흐름"으로 다룰 수 있다면, 즉 배치가 한꺼번에 훑던 일을 주문 1건 = 워크플로 1개로 쪼갤 수 있다면, 피크타임에도 부담 없이 흘려보낼 수 있지 않을까? 워크플로 모델이 바로 그 그림이었고, 그 생각을 Flowkit이라는 자체 라이브러리로 만들었습니다. Flowkit으로는 지금 여러 비즈니스를 워크플로로 옮겨가고 있는데, 이 글에서는 이해를 돕기 위해 그중 가장 단순한 접수지연 알림 하나를 바꾼 사례에 집중해 이야기하겠습니다. 배경 워크플로 하면 가장 먼저 떠오르는 것은 Temporal입니다. workflow / activity / signal이라는 깔끔한 추상화로 이 문제를 본질적으로 잘 풀어내는 엔진이죠. 실제로 우리도 가장 먼저 Temporal을 검토했습니다. Temporal은 어떤 일을 하나? Temporal은 "오래 걸리는 작업"을 코드로 안정적으로 다루게 해주는 워크플로 엔진입니다. 개발자는 흐름을 정의하는 워크플로와 외부 세계를 호출하는 액티비티를 평범한 함수처럼 작성하고, 클라이언트는 워크플로를 시작하거나 시그널을 보냅니다. 실제 코드는 워커(worker) 프로세스가 실행하고, Temporal Server는 워크플로의 모든 실행 단계를 이벤트 히스토리로 영속화합니다. 그래서 프로세스가 죽...