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