Vercel이 Workflow SDK 5.3.1에서 start() 함수에 원자적(atomic) 멱등성 처리를 추가했다. 중복 workflow 시작 시 HookConflictError로 안전하게 거부하고, 기존 두 단계 패턴의 경쟁 상태(race condition)를 완전히 제거했다는 게 핵심이다.

경쟁 상태, 왜 생겼나

기존엔 getHookByToken() 함수로 토큰을 확인한 후 start() 함수로 workflow를 시작하는 두 단계 구조였다. 그 사이 네트워크 지연이나 장애 상황에서 같은 주문번호나 임포트ID로 동시에 요청이 들어오면, 체크 후 시작 사이의 극히 짧은 시간 갭 때문에 두 개의 workflow가 실행되는 문제가 있었다.

이런 중복 실행은 전자상거래의 주문 처리, 신용카드 결제 승인, 대량 데이터 동기화 같은 민감한 작업에서 매우 위험하다. 같은 주문이 두 번 배송되거나 결제가 중복 청구되면 심각한 사업상 손실이 발생한다.

원자적 처리로 해결

이번 업데이트는 토큰 검사와 workflow 시작을 **하나의 단일 연산(atomic operation)**으로 통합했다. start() 함수가 호출되는 순간, 토큰 체크와 workflow 시작이 동시에 일어난다. 중복 요청이 들어와도 정확히 하나의 workflow만 실행되고, 나머지는 HookConflictError를 받게 된다.

에러에는 이미 실행 중인 workflow의 ID(conflictingRunId)가 담겨 있다. 개발자는 이 정보를 이용해 중복 요청의 페이로드를 기존 workflow로 자동 라우팅할 수 있다. 예를 들어 주문 수정 요청이 중복되면, 첫 번째 workflow가 처리 중인 주문에 수정 내용을 붙여 보낸다.

실제 코드로는 try-catch 블록에서 HookConflictError를 감지하고, resumeHook() 함수로 기존 workflow에 중복 데이터를 연결한다.

토큰만으로 멱등성 보장

토큰은 개발자가 정의한다. 주문ID, 송장번호, 임포트ID, 사용자 요청ID 같은 비즈니스 식별자다. 그 토큰 하나로 멱등성이 자동 보장된다. 같은 토큰으로 start() 함수를 여러 번 호출해도 절대 두 번 실행되지 않는다.

workflow 내부도 단순하다. createHook({ token: 'order:12345' })로 같은 토큰을 지정하면, 이미 claimed된 상태의 hook에 자동으로 연결된다. 새로운 hook이 만들어지지 않는다. conflict 에러도 발생하지 않는다. workflow는 그저 payload를 기다렸다가 처리하면 된다.

개발자 복잡도가 대폭 감소

수동 체크 코드 제거: 기존엔 getHookByToken() → start() 사이에서 개발자가 직접 중복을 감지하고 처리해야 했다. 이제는 framework가 자동으로 한다.

재시도 안전성: 네트워크 타임아웃, 청크 업로드 중단, 브라우저 새로고침 같은 상황에서 재시도해도 side effect 걱정이 없다. 정확히 한 번만 실행된다.

hook 선택 가능: workflow가 hook을 열지 않으면, 토큰은 순수 멱등성 키로만 동작한다. 불필요한 메시지 구독이나 long-polling이 없다.

retention 정책: experimental_minRetention 설정으로 workflow 완료 후 토큰 보호 기간을 정할 수 있다. 늦은 요청도 거부 가능하다.

업데이트 범위와 의미

Vercel은 이번 변화를 experimental 단계로 배포했다. SDK 5.3.1 이상에서 사용 가능하며, 공식 멱등성 가이드에서 상세한 구현 방법을 제시했다.

이것은 서버리스 workflow 패턴이 성숙해가고 있다는 신호다. 비동기 작업의 신뢰성을 framework 수준에서 보장하려는 업계 추세가 강해지고 있다. AWS의 Step Functions, Google Cloud의 Workflows, 오픈소스 Temporal 같은 경쟁 서비스들도 유사한 방향으로 진화 중이다. Vercel의 이번 움직임은 "개발자 경험 우선"이라는 회사 철학을 기술로 구현한 사례다.