불명 상태의 필요
성공과 실패 두 상태만 두면 실제 결과를 모르는 요청이 어느 한쪽으로 밀립니다. 가정한 예로 CRM 항목은 생성됐지만 응답이 돌아오지 않으면 실패 재시도로 두 번째 항목이 생길 수 있습니다. 처리 상태와 관찰 상태를 구분해 어떤 근거가 더 필요한지 표시합니다.
가정 상태 기록
다음은 운영 원장 필드를 논의하는 예시입니다. 실제 고객 자료 없이도 결과 조회와 재처리 조건을 시험할 수 있도록 설계합니다.
{
"workflow_run": "demo-run-014",
"action": "create_crm_record",
"request_key": "demo-action-014",
"observation": "response_timeout",
"business_result": "unknown",
"next_step": "lookup_before_retry",
"automatic_duplicate_action": "blocked"
}
확인 경로
외부 요청 ID, 업무 식별값이나 승인된 대조 경로로 결과를 찾을 수 있는지 확인합니다. 고객의 개인 정보를 일반 로그에 추가해 임시로 대조하지 않습니다. 조회도 실패하는 상황이라면 담당자에게 넘길 기한과 확인 자료의 범위를 정합니다.
시험 순서
- 외부 실행 전에 연결이 끊기는 상황을 만듭니다.
- 외부 실행 뒤 응답만 유실되는 상황을 나눕니다.
- 결과 조회와 중복 방지의 동작을 확인합니다.
- 확인 불가 항목이 보류 목록에 남는지 봅니다.
성공을 확인한 뒤에는 원래 요청의 상태와 후속 알림이 정상으로 이어지는지 봅니다. 확인 담당자가 동시에 수동 작업을 수행할 수 있으므로 자동 재시도와 충돌하지 않게 실행 권한을 조정합니다.
완료 기준
결과 불명 요청이 조용히 사라지지 않아야 합니다. 실제 처리 사실을 확인한 근거와 상태 변경자를 남기고 일정 시간 뒤에도 미확인인 요청을 운영자가 찾을 수 있어야 합니다. 시간초과 건수를 전체 실패로 보고하지 않고 확정 실패·확인된 성공·미확인을 구분해 장애와 사업 영향의 크기를 설명합니다.
자주 묻는 질문
- 시간초과면 외부 서버도 취소됐나요?
- 클라이언트의 대기 종료가 외부 작업 취소를 뜻하지 않을 수 있습니다. 실제 공급자의 취소·조회 지원과 작업 결과를 확인하고 처리되지 않았다고 추측하지 않습니다.
- 결과를 조회할 방법이 없으면요?
- 어떤 중복 위험과 누락 위험이 있는지 명시하고 수동 확인 또는 보류 절차를 정합니다. 안전한 재처리가 불가능한 구간을 자동 복구 완료라고 표현하지 않습니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.