요즘 팀들이 공통으로 부딪히는 문제는 기능 추가 속도가 아니라 “흐름 제어 복잡도"입니다. 결제 후 정산, 주문 후 물류 연동, 배포 후 검증 같은 멀티스텝 프로세스가 늘어날수록, 단순한 큐 컨슈머 + 재시도 조합으로는 운영이 버티기 어렵습니다. 실패가 나면 어느 단계에서 멈췄는지 추적이 어렵고, 수동 재처리 스크립트가 늘어나며, 장애 때는 담당자 경험에 의존한 복구가 반복됩니다.

이 때문에 2026년엔 “워크플로 자체를 런타임으로 운영"하려는 흐름이 강해지고 있습니다. 핵심은 함수 몇 개를 붙여 실행하는 게 아니라, 상태·재시도·타임아웃·보상을 워크플로 엔진 레벨에서 일관되게 관리하는 것입니다. 즉 Durable Execution은 백엔드 코드 스타일이 아니라, 운영 비용 구조를 바꾸는 선택지가 되고 있습니다.

이 글에서 얻는 것

  • Durable Execution이 단순 배치 스케줄러나 메시지 큐 재시도와 무엇이 다른지 실무 관점에서 구분할 수 있습니다.
  • 어떤 팀/시스템에서 도입 효과가 크고, 어떤 경우엔 과한 선택인지 판단 기준을 숫자로 정리할 수 있습니다.
  • 도입 시 가장 먼저 분리해야 할 흐름(API·배치·운영 자동화)과 운영 지표를 함께 가져갈 수 있습니다.

핵심 개념/이슈

1) 트렌드의 본질: 비즈니스 로직보다 “실패 제어 로직"을 플랫폼으로 올린다

예전에는 각 서비스가 아래를 개별 구현했습니다.

  • 재시도 횟수/간격
  • 타임아웃/취소 처리
  • 단계별 상태 저장
  • 수동 복구 도구

문제는 서비스 수가 늘수록 정책 불일치가 폭발한다는 점입니다. 어떤 서비스는 3회 재시도, 어떤 서비스는 무한 재시도, 어떤 서비스는 타임아웃 후에도 하위 작업이 계속 돌아갑니다. Durable Execution 런타임을 쓰는 팀은 이 제어 로직을 공통 정책으로 끌어올려 운영 편차를 줄입니다.

이 방향은 승인형 Auto-Remediation 트렌드와도 맞닿아 있습니다. 자동화가 늘어날수록 “어떤 조건에서 자동으로 어디까지 실행할지"를 표준화해야 하기 때문입니다.

2) 이벤트 기반 아키텍처의 다음 병목은 “오케스트레이션 가시성"이다

이벤트 드리븐 시스템은 결합도를 낮춰주지만, 흐름 전체 가시성은 오히려 나빠질 수 있습니다. 특히 다음 상황에서 비용이 커집니다.

  • A 이벤트가 B/C/D로 퍼진 뒤 일부만 실패
  • 보상 트랜잭션이 부분 실행되어 데이터 불일치 발생
  • 재처리 시 중복 실행 여부를 시스템마다 다르게 판단

최근 팀들은 “이벤트는 전송 계층, 오케스트레이션은 실행 계층"으로 분리하는 쪽을 택합니다. 이벤트 버스로 느슨한 결합을 유지하되, 비즈니스 핵심 흐름은 워크플로 ID 기준으로 추적/재개/보상을 통합합니다. 이는 Transactional Outbox + CDC와 Outbox/Saga 패턴을 운영 단계로 확장한 형태입니다.

3) 2026년 도입 패턴: “배치부터"가 아니라 “실패비용이 큰 흐름부터”

현장에서 효과가 큰 케이스는 단순 주기성 배치보다, 실패 시 고객 영향과 운영비가 큰 흐름입니다.

  • 결제 후 정산·영수증·알림 연쇄 처리
  • 주문 후 재고·배송·환불 보상 체인
  • 배포 후 헬스체크·스모크 테스트·자동 롤백

공통 특징은 “단계가 4개 이상이고, 사람 개입 없이 끝나야 하는 흐름"입니다. 반대로 단계 1~2개인 단순 ETL은 기존 큐/잡 스케줄러가 더 단순하고 저렴할 수 있습니다.

4) 운영 관점 핵심: 실패 복구 시간을 코드가 아니라 상태모델이 결정한다

Durable Execution의 차이는 결국 상태입니다. 어디까지 완료됐는지, 어떤 단계가 재실행 가능한지, 보상 순서가 무엇인지가 런타임에 명시됩니다.

실무에서 자주 쓰는 운영 기준 예시:

  • 워크플로 단계 타임아웃: 비즈니스 SLA의 20~30% 이내
  • 자동 재시도 상한: 멱등 단계 3회, 비멱등 단계 0~1회
  • 인간 승인 단계 삽입 기준: 금전 이동, 계정 정지, 외부 공지 발송
  • DLQ 전환 기준: 동일 에러 원인 10분 내 3회 반복

이 기준이 없으면 엔진을 도입해도 “재시도 지옥"이 다른 형태로 반복됩니다.

실무 적용

1) 도입 판단 기준(숫자·조건·우선순위)

다음 중 2개 이상이면 Durable Execution 도입 효과가 큽니다.

  • 멀티스텝 비즈니스 흐름이 10개 이상 운영 중
  • 수동 재처리 티켓이 주당 5건 이상 발생
  • 장애 후 데이터 정합성 점검/복구에 2시간 이상 소요
  • 동일 흐름의 재시도/타임아웃 정책이 서비스마다 다름

우선순위는 고객 영향 큰 흐름 표준화 > 운영 복구 시간 단축 > 개발 생산성 개선 순으로 두는 게 안전합니다.

2) 3단계 도입 방식

1단계: 흐름 인벤토리(1~2주)

  • 현재 비즈니스 흐름을 단계 수/실패 비용/복구 시간으로 점수화
  • 상위 3개 흐름 선정(결제, 주문, 배포 같은 코어 체인)

2단계: 상태모델 표준화(2~3주)

  • 단계 타입 구분: idempotent / compensatable / manual-approval
  • 타임아웃/재시도/보상 정책을 템플릿화
  • 흐름별 SLO 정의(예: 99%가 3분 내 완료)

3단계: 운영 일원화(2주+)

  • 워크플로 실행 이력과 알람을 단일 대시보드로 통합
  • 수동 복구를 “스크립트"가 아니라 “resume/retry/cancel” 액션으로 전환
  • 릴리스 게이트에 워크플로 회귀 테스트 포함

3) 의사결정 기준 예시

  • Go
    • 핵심 흐름의 실패 재처리 시간이 월 평균 8시간 이상
    • 단계별 멱등성 정의가 이미 문서화돼 있음
    • 플랫폼 팀이 공통 런타임 운영 책임을 맡을 수 있음
  • Hold
    • 이벤트 스키마 버전 관리가 안 되어 재처리 시 호환성 깨짐
    • 비즈니스 단계 정의가 불명확해 “어디까지 성공인가” 합의 없음
    • 관측 시스템이 미흡해 워크플로 병목을 계측할 수 없음

이 영역은 이벤트 스키마 호환성 플레이북과 관측 알람 임계치 설계를 같이 참고해야 안전합니다.

4) 모니터링 최소 세트

  • workflow_success_rate
  • workflow_duration_p95
  • step_retry_count, step_timeout_count
  • manual_intervention_rate
  • compensation_invocation_rate

특히 manual_intervention_rate가 내려가지 않으면 도입 효과가 제한적입니다. 단순 실행 성공률보다 운영 개입률 감소를 KPI로 잡는 팀이 실제로 빨라집니다.

트레이드오프/주의점

  1. 초기 학습비용이 높다
    워크플로 DSL/SDK, 상태 모델링, 보상 설계까지 익혀야 해서 초반 생산성이 일시적으로 떨어질 수 있습니다.

  2. 모든 흐름을 오케스트레이션할 필요는 없다
    단순 CRUD 후 단일 이벤트 발행 같은 짧은 흐름까지 엔진으로 옮기면 과설계가 됩니다.

  3. 엔진 도입만으로 멱등성이 생기지 않는다
    재실행 가능한 도메인 연산 설계가 선행되지 않으면, 런타임은 실패를 더 빨리 드러낼 뿐 해결하지 못합니다.

  4. 플랫폼팀-도메인팀 책임 경계가 불명확하면 운영이 꼬인다
    공통 런타임이 있다고 해서 모든 복구 책임이 플랫폼팀으로 쏠리면 병목이 생깁니다. 흐름 소유권을 명확히 나눠야 합니다.

체크리스트 또는 연습

체크리스트

  • 실패 비용이 큰 멀티스텝 흐름 Top 3가 선정되어 있다.
  • 단계별 멱등성/보상 가능 여부가 문서화되어 있다.
  • 타임아웃·재시도·승인 조건이 공통 정책으로 정의돼 있다.
  • 수동 복구가 스크립트가 아니라 표준 액션(resume/retry/cancel)으로 전환되고 있다.
  • manual_intervention_rate와 workflow_duration_p95를 핵심 운영 KPI로 본다.

연습 과제

  1. 현재 서비스의 핵심 비즈니스 흐름 3개를 골라 단계별 실패 비용(금액/시간/사용자 영향)을 점수화해보세요.
  2. 한 흐름을 대상으로 idempotent 단계, 보상 단계, 승인 단계를 나눠 상태 전이 다이어그램을 작성해보세요.
  3. 최근 1개월 장애 중 수동 재처리 사례를 모아, 워크플로 런타임으로 대체 가능한 액션(resume/retry/cancel)을 분류해보세요.

관련 글