장기 실행 워크플로: 재시도, 데드레터, 가시성

장기간 실행 자동화에서 무엇이 깨지나

장기간 실행 워크플로는 짧은 요청과는 다르게 실패합니다. 짧은 API 호출은 즉시 성공하거나 오류를 반환합니다. 수시간 또는 수일 동안 실행되는 워크플로는 10단계 중 9단계를 통과했어도 엉망이 될 수 있습니다: 절반만 생성된 레코드, 혼란스러운 상태, 다음 행동이 명확하지 않은 상황 등입니다.

그래서 “어제는 잘 됐어요”라는 말이 자주 나옵니다. 워크플로 자체는 변하지 않았지만 환경이 변한 경우가 많습니다. 장기간 워크플로는 다른 서비스가 건강한 상태를 유지하는 것, 자격 증명이 유효한 것, 데이터가 기대하는 형태로 유지되는 것에 의존합니다.

가장 흔한 실패 모드는 다음과 같습니다: 타임아웃과 느린 의존성(파트너 API가 동작하지만 오늘은 40초가 걸림), 부분 업데이트(레코드 A는 생성됐지만 B는 생성되지 않아 안전하게 재실행할 수 없음), 의존성 중단(이메일/SMS 제공자, 결제 게이트웨이, 유지보수 창), 콜백 누락·스케줄 실패(웹훅이 도착하지 않음, 타이머 잡이 실행되지 않음), 그리고 사람이 개입하는 단계가 멈춤(승인이 며칠간 방치되었다가 오래된 가정으로 재개됨).

핵심은 상태(state)입니다. 짧은 요청은 완료될 때까지 메모리에 상태를 유지할 수 있습니다. 워크플로는 그렇지 않습니다. 단계 사이에 상태를 영구 저장하고 재시작, 배포, 충돌 후에도 재개할 수 있어야 합니다. 또한 같은 단계가 두 번 트리거되는 상황(재시도, 중복 웹훅, 운영자 재생 등)에 대응해야 합니다.

실무에서 “신뢰성”은 절대 실패하지 않는 것이 아니라 예측 가능하고, 설명 가능하며, 복구 가능하고, 명확히 소유된다는 뜻입니다.

예측 가능하다는 것은 의존성이 실패할 때마다 워크플로가 항상 같은 방식으로 반응한다는 뜻입니다. 설명 가능하다는 것은 운영자가 1분 내에 “어디에서 막혔고 왜 막혔나?”에 답할 수 있다는 뜻입니다. 복구 가능하다는 것은 안전하게 재시도하거나 계속할 수 있다는 뜻이고, 명확한 소유권은 막힌 항목마다 다음에 취할 행동(대기, 재시도, 데이터 수정, 사람에게 인계)이 분명하다는 뜻입니다.

간단한 예: 온보딩 자동화가 고객 레코드를 만들고 접근을 프로비저닝한 뒤 환영 메시지를 보냅니다. 프로비저닝은 성공했지만 이메일 제공자가 다운되어 메시지 전송이 실패하면 신뢰할 수 있는 워크플로는 “프로비저닝 완료, 메시지 대기”를 기록하고 재시도를 예약합니다. 프로비저닝 단계를 무작정 다시 실행하지 않습니다.

도구는 워크플로 로직과 영구 데이터를 서로 가깝게 유지함으로써 이를 쉽게 만들 수 있습니다. 예를 들어 AppMaster에서는 Data Designer로 워크플로 상태를 모델링하고 Business Processes에서 업데이트할 수 있습니다. 하지만 신뢰성은 도구가 아니라 패턴에서 옵니다: 장기간 자동화를 시간, 실패, 사람 개입을 견디는 일련의 지속 가능한 상태로 취급하세요.

사람이 읽을 수 있는 상태 정의하기

장기간 워크플로는 반복 가능한 방식으로 실패합니다: 서드파티 API가 느려지거나, 사람이 승인을 하지 않거나, 작업이 큐 뒤에 밀려있는 식입니다. 명확한 상태는 그런 상황을 분명히 해 주어 ‘지연 중’과 ‘고장’이 헷갈리지 않게 합니다.

‘지금 무슨 일이 일어나고 있나?’라는 질문에 답할 수 있는 적은 수의 상태로 시작하세요. 상태가 30개면 아무도 기억하지 못합니다. 5~8개 정도면 온콜 담당자가 목록을 훑고 이해할 수 있습니다.

많은 워크플로에 실용적인 상태 집합 예시:

• 대기열 (생성됐지만 시작되지 않음)
• 실행 중 (실제로 작업 수행 중)
• 대기 (타이머, 콜백, 사람 입력으로 일시정지됨)
• 성공 (완료)
• 실패 (오류로 중지)

‘대기’와 ‘실행 중’을 분리하는 것이 중요합니다. “고객 응답 대기”는 정상적입니다. “6시간 동안 실행 중”은 걸린 상태일 수 있습니다. 이 분리가 없으면 오탐을 쫓다가 실제 문제를 놓치게 됩니다.

각 상태와 함께 무엇을 저장할까

상태 이름만으로는 충분하지 않습니다. 상태를 실행 가능한 정보로 바꿀 몇 가지 필드를 추가하세요:

• 현재 상태와 마지막 상태 변경 시각
• 이전 상태
• 실패나 일시중지에 대한 짧은 사람이 읽을 수 있는 이유
• 선택적 재시도 카운터 또는 시도 번호

예: 온보딩 흐름은 “대기”와 이유 “매니저 승인 대기”, 마지막 변경 “2일 전”을 보여줄 수 있습니다. 그러면 멈춘 것이 아니라 확인이나 리마인더가 필요하다는 걸 알 수 있습니다.

상태를 안정적으로 유지하기

상태 이름을 API처럼 취급하세요. 매달 이름을 바꾸면 대시보드, 알림, 지원 플레이북이 금세 잘못됩니다. 새로운 의미가 필요하면 기존 상태는 그대로 두고 새 상태를 도입하는 것을 고려하세요.

AppMaster에서는 Data Designer에서 이러한 상태를 모델링하고 Business Process 로직에서 업데이트할 수 있습니다. 이렇게 하면 상태가 로그에 파묻히지 않고 앱 전반에 걸쳐 일관되게 보입니다.

적절한 시점에서 멈추는 재시도

재시도는 문제를 해결하는 데 도움이 되지만, 재시도가 문제를 숨기지 않도록 해야 합니다. 목표는 ‘절대 실패하지 않기’가 아니라 ‘사람이 이해하고 고칠 수 있게 실패하기’입니다. 이를 위해 무엇이 재시도 가능한지, 무엇이 아닌지에 대한 명확한 규칙이 필요합니다.

대부분 팀이 사용할 수 있는 규칙: 일시적일 가능성이 큰 오류(네트워크 타임아웃, 레이트 리밋, 잠깐의 서드파티 장애)는 재시도하세요. 명백히 영구적인 오류(잘못된 입력, 권한 없음, “계정 닫힘”, “카드 거절”)는 재시도하지 마세요. 어느 쪽인지 분간이 안 되면 더 배우기 전까지는 비재시도로 취급하세요.

재시도는 워크플로 전체가 아니라 단계별로 추적하세요

재시도 카운터를 단계별(또는 외부 호출별)로 추적하세요. 워크플로에 10단계가 있고 그중 하나만 불안정할 수 있습니다. 단계별 카운터는 나중 단계가 이전 단계의 시도를 ‘빼앗는’ 일을 막습니다.

예를 들어, “문서 업로드” 호출은 몇 번 재시도할 수 있지만, “환영 이메일 전송”은 업로드에서 시도를 모두 소모했다고 해서 무한정 재시도해선 안 됩니다.

백오프, 중단 조건, 그리고 명확한 다음 행동

위험에 맞는 백오프 패턴을 선택하세요. 단순하고 비용이 낮은 재시도의 경우 고정 지연이 괜찮습니다. 레이트 리밋에 걸릴 가능성이 있으면 지수 백오프가 도움이 됩니다. 대기 시간이 무한히 커지지 않도록 상한을 두고, 재시도 폭주를 막기 위해 약간의 지터를 추가하세요.

그다음 언제 멈출지 결정하세요. 좋은 중단 조건은 명시적입니다: 최대 시도 횟수, 최대 총 시간, 특정 오류 코드에 대해 즉시 포기 등. 결제 게이트웨이가 “잘못된 카드”를 반환하면 일반적으로 즉시 중단해야 하며, 평소 허용하는 5회 시도를 모두 쓰지 않아야 합니다.

운영자는 다음에 무슨 일이 일어날지 알아야 합니다. 다음 재시도 시간과 이유를 기록하세요(예: “재시도 3/5, 14:32에 타임아웃으로 재시도”). AppMaster에서는 워크플로 레코드에 이를 저장해 대시보드가 ‘언제까지 대기 중’인지 추측하지 않아도 되게 할 수 있습니다.

좋은 재시도 정책은 흔적을 남깁니다: 무엇이 실패했는지, 몇 번 시도했는지, 언제 다시 시도할지, 언제 멈추고 데드레터로 넘길지 등의 정보가 있어야 합니다.

멱등성(idempotency)과 중복 보호

수시간 또는 수일 동안 실행되는 워크플로에서는 재시도가 흔합니다. 위험은 이미 성공한 단계를 다시 실행하는 것입니다. 멱등성은 이것을 안전하게 만드는 규칙입니다: 어떤 단계를 두 번 실행해도 한 번 실행한 것과 같은 결과가 나오면 그 단계는 멱등합니다.

고전적인 실패 예: 카드를 청구했지만 워크플로가 “결제 성공”을 저장하기 전에 크래시가 납니다. 재시도하면 카드가 다시 청구됩니다. 외부는 변경됐지만 워크플로 상태는 기록되지 않은 ‘이중 처리’ 문제입니다.

가장 안전한 패턴은 각 부작용이 있는 단계에 대해 안정적인 아이덤포턴시 키를 생성하고 이를 외부 호출에 함께 보내며, 결과를 받는 즉시 단계 결과를 저장하는 것입니다. 많은 결제 제공자와 웹훅 수신자는 아이덤포턴시 키를 지원합니다(예: 주문 ID로 청구). 단계가 반복되면 제공자가 원래 결과를 반환해 액션을 다시 수행하지 않습니다.

워크플로 엔진 내부에서는 모든 단계가 재생될 수 있다고 가정하세요. AppMaster에서는 보통 단계 출력물을 데이터베이스 모델에 저장하고 Business Process에서 통합을 다시 호출하기 전에 이를 확인합니다. “환영 이메일 전송”에 이미 MessageID가 기록되어 있다면 재시도는 그 기록을 재사용하고 다음 단계로 넘어가야 합니다.

중복 안전한 실무적 접근법:

• 워크플로 ID + 단계 이름 + 비즈니스 엔터티 ID 같은 안정적인 데이터로 단계별 아이덤포턴시 키 생성
• 외부 호출 전에 “단계 시작” 레코드 작성
• 성공 시 응답(트랜잭션 ID, 메시지 ID, 상태)을 저장하고 단계를 ‘완료’로 표시
• 재시도 시 저장된 결과를 조회해 재호출 대신 재사용
• 불확실한 경우(예: 시작되었는데 10분 이상 응답이 없을 때)는 재시도 전에 제공자 상태 확인 규칙 추가

중복은 특히 들어오는 웹훅이나 사용자가 같은 버튼을 여러 번 누르는 경우에 발생합니다. 이벤트 타입별 정책을 정하세요: 정확한 중복(같은 아이덤포턴시 키)은 무시, 호환 가능한 업데이트는 병합(예: 프로필 필드에 대해 최신 쓰기 우선), 금전이나 규제 위험이 있는 경우 검토 대상으로 표시 등.

컨텍스트를 잃지 않는 데드레터 처리

데드레터는 실패한 워크플로 항목을 정상 경로에서 분리해 다른 항목을 막지 않도록 보관한 것입니다. 되돌려놓는 것이 목적입니다. 목표는 무슨 일이 일어났는지 이해하고, 고칠 수 있는지 판단하며, 안전하게 재처리할 수 있게 만드는 것입니다.

가장 큰 실수는 오류 메시지만 저장하는 것입니다. 나중에 데드레터를 보는 사람은 추측 없이 문제를 재현할 수 있을 만큼의 컨텍스트가 필요합니다.

유용한 데드레터 항목에는 다음을 포함하세요:

• 안정적인 식별자(고객 ID, 주문 ID, 요청 ID, 워크플로 인스턴스 ID)
• 원래 입력(또는 안전한 스냅샷)과 주요 파생 값
• 실패 지점(단계 이름, 상태, 마지막 성공 단계)
• 시도 내역(재시도 횟수, 타임스탬프, 예정된 다음 재시도 시간 등)
• 오류 세부 정보(메시지, 코드, 가능하면 스택 트레이스, 의존성 응답 페이로드)

분류하면 데드레터가 실무적으로 유용해집니다. 짧은 카테고리는 운영자가 적절한 다음 단계를 선택하게 도와줍니다. 일반 그룹으로는 영구 오류(비즈니스 규칙 위반, 잘못된 상태), 데이터 문제(필드 누락, 형식 오류), 의존성 다운(타임아웃, 레이트 리밋, 중단), 인증/권한 문제(토큰 만료, 자격 거부) 등이 있습니다.

재처리는 통제되어야 합니다. 목표는 두 번 청구하거나 이메일을 스팸처럼 다시 보내는 같은 피해를 반복하지 않는 것입니다. 누가 재시도할 수 있는지, 언제 재시도할 수 있는지, 무엇을 변경할 수 있는지(특정 필드 편집, 누락 문서 첨부, 토큰 갱신), 무엇은 고정되어야 하는지(요청 ID 및 다운스트림 아이덤포턴시 키) 같은 규칙을 정의하세요.

데드레터 항목은 안정적인 식별자로 검색 가능해야 합니다. 운영자가 “주문 18422”를 입력하면 정확한 단계, 입력, 시도 내역을 볼 수 있어야 고치기가 빠르고 일관됩니다.

AppMaster로 이를 구축할 경우 데드레터를 일급 데이터베이스 모델로 취급하고 상태, 시도 수, 식별자를 필드로 저장하세요. 그러면 내부 대시보드에서 쿼리, 필터, 제어된 재처리 액션을 트리거할 수 있습니다.

문제 진단에 도움이 되는 가시성

장기 워크플로는 느리거나 혼란스러운 방식으로 실패합니다: 단계가 이메일 회신을 기다리거나, 결제 제공자가 타임아웃을 반환하거나, 웹훅이 두 번 도착하는 식입니다. 워크플로가 지금 무엇을 하는지 볼 수 없으면 추측만 하게 됩니다. 훌륭한 가시성은 “고장났다”를 “어떤 워크플로, 어떤 단계, 어떤 상태, 다음에 무엇을 해야 하는지”로 바꿉니다.

모든 단계가 동일한 소형 필드 집합을 방출하도록 하세요. 운영자가 빠르게 훑어볼 수 있어야 합니다:

• 워크플로 ID(테넌트/고객 정보가 있다면 포함)
• 단계 이름과 단계 버전
• 현재 상태(실행 중, 대기, 재시도 중, 실패, 완료 등)
• 지속 시간(해당 단계에 머문 시간과 워크플로 전체 소요 시간)
• 외부 시스템을 위한 연관 ID(결제 ID, 메시지 ID, 티켓 ID)

이 필드들은 한눈에 상태를 보여주는 기본 카운터를 지원합니다. 장기 워크플로에서는 단일 오류보다 누적 수치가 더 중요합니다. 추세를 찾아야 하기 때문입니다: 작업이 쌓이고 있는지, 재시도가 급증하는지, 대기가 끝나지 않는지 등을 봐야 합니다.

시작된 수, 완료된 수, 실패한 수, 재시도 중인 수, 대기 중인 수를 시간 경과에 따라 추적하세요. 소수의 대기 항목은 정상(사람 승인)일 수 있습니다. 대기 수가 증가하면 보통 무언가 막힌 것입니다. 재시도 중인 수가 늘면 제공자 문제나 같은 오류가 반복되는 버그를 의심하세요.

알림은 운영자가 경험하는 상황과 맞아야 합니다. “오류 발생” 대신 증상에 대해 경고하세요: 누적 대기(backlog)가 증가한다(시작된 수 - 완료된 수가 계속 증가), 예상 시간을 넘긴 대기 항목이 많다, 특정 단계의 재시도율이 높다, 배포나 설정 변경 직후 실패가 급증했다 등.

각 워크플로에 대한 이벤트 트레일을 유지해 “무슨 일이 있었나?”를 한 화면에서 답할 수 있게 하세요. 유용한 트레일에는 타임스탬프, 상태 전이, 입력/출력 요약(민감한 전체 페이로드는 제외), 재시도 또는 실패 이유 요약 등이 포함됩니다. 예: “카드 청구: 재시도 3/5, 제공자 타임아웃, 다음 시도 10분 후.”

상호 연관 ID(correlation ID)가 접착제 역할을 합니다. 고객이 “결제가 두 번 됐어요”라고 하면 워크플로 이벤트를 결제 제공자의 청구 ID와 내부 주문 ID에 연결할 수 있어야 합니다. AppMaster에서는 Business Process 로직에서 연관 ID를 생성해 API 호출과 메시징 단계에 전달하면 대시보드와 로그가 일치하도록 표준화할 수 있습니다.

운영자 친화적 대시보드와 액션

워크플로가 수시간 또는 수일 동안 실행되면 실패는 정상입니다. 문제는 대시보드가 단지 “실패”라고만 표시하고 아무것도 알려주지 않을 때 발생합니다. 목표는 운영자가 세 가지 질문에 빠르게 답할 수 있게 하는 것입니다: 무슨 일이 일어나고 있는가, 왜 그러한가, 그리고 안전하게 무엇을 할 수 있는가.

가장 중요한 항목 몇 개를 쉽게 찾을 수 있는 워크플로 목록으로 시작하세요. 필터가 있으면 당황과 채팅 소음을 줄일 수 있습니다. 누구나 빠르게 뷰를 좁힐 수 있기 때문입니다.

유용한 필터: 상태, 경과 시간(시작 시간 및 현재 상태에 머문 시간), 담당자(팀/고객/담당 운영자), 유형(워크플로 이름/버전), 우선순위(고객 영향도가 있는 단계).

다음으로 상태 옆에 ‘왜’가 보이게 하세요. 상태 표식만 있으면 로그에서 숨긴 이유를 찾느라 시간을 낭비합니다. 상태 표식은 마지막 오류 메시지, 짧은 오류 카테고리, 시스템이 다음에 뭘 할 계획인지와 함께 제공되어야 합니다. 두 개의 필드가 대부분을 해결합니다: 마지막 오류와 다음 재시도 시간. 다음 재시도가 비어 있으면 그 항목이 사람을 기다리는지, 일시중지인지, 영구 실패인지 분명히 표시하세요.

운영자 액션은 기본적으로 안전해야 합니다. 먼저 저위험 작업을 안내하고 위험한 작업은 명확히 표시하세요:

• 지금 재시도(기존 재시도 규칙 따름)
• 일시중지/재개
• 취소(사유 필수 입력)
• 데드레터로 이동
• 강제 계속(무엇이 건너뛰어지는지, 무엇이 깨질 수 있는지 명시해야 함)

“강제 계속”은 대부분의 피해가 발생하는 곳입니다. 이 기능을 제공한다면 위험을 평이한 언어로 명확히 적으세요: “이 작업은 결제 검증을 건너뛰어 미지급 주문을 생성할 수 있습니다.” 또한 진행 시 어떤 데이터가 기록될지 보여주세요.

운영자의 모든 행동을 감사(audit)하세요. 누가 언제 무엇을 했는지, 전/후 상태, 사유 메모를 기록하세요. AppMaster로 내부 도구를 만들면 이 감사 로그를 일급 테이블로 저장해 워크플로 상세 페이지에 표시하면 인수인계가 깨끗해집니다.

단계별: 간단한 신뢰 가능한 워크플로 패턴

이 패턴은 워크플로를 예측 가능하게 유지합니다: 모든 항목은 항상 명확한 상태에 있고, 실패는 갈 곳이 있으며, 운영자는 추측하지 않고 행동할 수 있습니다.

Step 1: 상태와 허용 전이를 정의하세요. 사람이 이해할 수 있는 작은 상태 집합을 적으세요(예: 대기열, 실행 중, 외부 대기, 성공, 실패, 데드레터). 그런 다음 어떤 이동이 합법적인지 결정해 작업이 방황하지 않도록 합니다.

Step 2: 작업을 명확한 입력과 출력이 있는 작은 단계로 쪼개세요. 각 단계는 하나의 잘 정의된 입력을 받고 하나의 출력(또는 명확한 오류)을 내보내야 합니다. 사람의 결정이나 외부 API 호출이 필요하면 그것을 별도의 단계로 만들어 일시중지하고 깔끔하게 재개할 수 있게 하세요.

Step 3: 단계별 재시도 정책을 추가하세요. 시도 제한, 시도 간 지연, 그리고 절대 재시도하지 않을 이유(잘못된 데이터, 권한 거부, 필수 필드 누락)를 정하세요. 단계별 재시도 카운터를 저장해 운영자가 무엇이 막혔는지 정확히 볼 수 있게 하세요.

Step 4: 각 단계가 끝날 때 진행을 영구 저장하세요. 단계가 끝나면 새 상태와 주요 출력물을 저장하세요. 프로세스가 재시작되면 처음부터가 아니라 마지막 완료 단계부터 이어야 합니다.

Step 5: 재시도가 소진되면 데드레터로 라우팅하고 재처리를 지원하세요. 재시도 한계를 넘으면 항목을 데드레터 상태로 이동하고 전체 컨텍스트(입력, 마지막 오류, 단계 이름, 시도 횟수, 타임스탬프)를 보관하세요. 재처리는 신중히: 먼저 데이터나 설정을 고친 다음 특정 단계부터 재대기(re-queue)하세요.

Step 6: 대시보드 필드와 운영자 액션을 정의하세요. 좋은 대시보드는 ‘무엇이 실패했는지, 어디서, 그리고 내가 무엇을 할 수 있는지’를 답합니다. AppMaster에서는 이를 워크플로 테이블로 백업되는 간단한 관리자 웹앱으로 만들 수 있습니다.

포함할 핵심 필드와 액션:

• 현재 상태와 현재 단계
• 재시도 카운트와 다음 재시도 시간
• 마지막 오류 메시지(짧게)와 오류 카테고리
• “단계 재실행”과 “워크플로 재대기”
• “데드레터로 이동”과 “해결로 표시”

예시: 사람이 승인하는 단계가 있는 온보딩 워크플로

직원 온보딩은 테스트용으로 좋습니다. 승인, 외부 시스템, 오프라인인 사람 등이 섞여 있습니다. 간단한 흐름은 HR이 신규 채용 양식을 제출하면 매니저가 승인하고 IT 계정이 생성되며 신규 직원에게 환영 메시지가 전달되는 흐름입니다.

상태를 읽기 쉽게 만드세요. 누군가 레코드를 열었을 때 “승인 대기”와 “계정 설정 재시도 중”의 차이를 즉시 알 수 있어야 합니다. 한 줄의 명확성이 한 시간의 추측을 절약할 수 있습니다.

UI에 표시할 명확한 상태 예시:

• 초안(HR이 아직 편집 중)
• 매니저 승인 대기
• 계정 프로비저닝 중(재시도 카운터 포함)
• 신규 직원 알림 중
• 완료(또는 취소)

계정 프로비저닝(이메일, SSO, Slack), 이메일/SMS 전송, 내부 API 호출과 같은 네트워크나 서드파티에 의존하는 단계는 재시도 후보입니다. 재시도 카운터를 표시하고 상한을 두세요(예: 최대 5회, 지연을 늘리며 재시도 후 중단).

데드레터 처리는 스스로 해결되지 않는 문제(양식에 매니저가 없음, 잘못된 이메일 주소, 정책과 충돌하는 접근 요청)에 사용하세요. 실행을 데드레터로 보낼 때는 어떤 필드가 유효성 검사에 실패했는지, 마지막 API 응답, 누가 재승인 권한이 있는지를 저장하세요.

운영자는 데이터 수정(매니저 추가, 이메일 수정), 실패한 한 단계만 재실행(전체 워크플로 재시작 아님), 또는 깔끔한 취소(부분 설정도 롤백 필요 시 그 처리 포함) 같은 소수의 직관적 액션을 가져야 합니다.

AppMaster를 사용하면 Business Process Editor에서 이를 모델링하고 재시도 카운터를 데이터에 보관하며, 웹 UI 빌더로 상태, 마지막 오류, 실패 단계 재시도 버튼을 보여주는 운영자 화면을 만들 수 있습니다.

체크리스트와 다음 단계

대부분의 신뢰성 문제는 예측 가능합니다: 단계가 두 번 실행되거나 새벽 2시에 재시도가 폭주하거나 ‘멈춘’ 항목에 마지막에 무슨 일이 있었는지 아무런 단서가 없는 경우입니다. 체크리스트는 추측을 방지합니다.

초기에 잡아내는 데 효과적인 빠른 체크:

• 비기술자도 각 상태를 읽고 이해할 수 있는가(예: 결제 대기, 이메일 전송 중, 승인 대기, 완료, 실패)?
• 재시도가 한계가 설정되어 있는가(최대 시도, 최대 시간) 및 각 시도는 가시적인 카운터를 증가시키는가?
• 각 단계 후 진행이 저장되어 재시작 시 마지막 확인된 지점부터 이어지는가?
• 모든 단계가 멱등성을 갖거나 요청 키, 락, 또는 “이미 완료됨” 검사로 중복을 방지하는가?
• 데드레터로 이동할 때 재처리와 재실행을 안전하게 할 수 있는 충분한 컨텍스트(입력 데이터, 단계 이름, 타임스탬프, 마지막 오류, 제어된 재실행 액션)가 저장되는가?

한 가지 개선만 할 수 있다면 가시성을 개선하세요. 많은 “워크플로 버그”는 사실 “무엇을 하고 있는지 볼 수 없음”에서 옵니다. 대시보드는 마지막에 무슨 일이 있었는지, 다음에 무엇이 일어날지, 그리고 언제 일어날지를 보여줘야 합니다.

실용적인 운영자 뷰에는 현재 상태, 마지막 오류 메시지, 시도 횟수, 다음 재시도 시간, 그리고 한 가지 명확한 액션(지금 재시도, 해결로 표시, 수동 검토로 보냄)이 포함되어야 합니다. 기본 동작을 안전하게 유지하세요: 전체 워크플로를 다시 실행하지 말고 단일 단계만 재실행하게 하세요.

다음 단계 제안:

• 먼저 상태 모델을 스케치하세요(상태, 전이, 어떤 상태가 종료 상태인지).
• 단계별로 재시도 규칙을 작성하세요: 어떤 오류를 재시도하고, 얼마나 기다리며, 언제 중단할지.
• 중복 방지 방법을 결정하세요: 아이덤포턴시 키, 고유 제약 조건, 또는 “확인 후 실행” 가드.
• 사람이 진단하고 재실행할 수 있도록 데드레터 레코드 스키마를 정의하세요.
• 흐름과 운영자 대시보드를 AppMaster 같은 도구로 구현한 뒤, 타임아웃, 잘못된 입력, 서드파티 장애 등 강제 실패 상황으로 테스트하세요.

이 체크리스트를 살아있는 문서로 취급하세요. 새 단계를 추가할 때마다 프로덕션에 배포하기 전에 이 점검을 실행하세요.