검토함의 목적
자동 회복이 안 되는 업무를 사람이 찾고 판단하게 하는 경계입니다. 기술 오류를 모으는 저장소와 달리 다음 행동과 처리 기한이 필요합니다. 비정상 요청·권한 문제·공급자 장애와 결과 불명을 분류해 어떤 자료가 있어야 결정할 수 있는지 적습니다.
가정한 검토 항목
아래는 검토함에 필요한 메타정보의 설계 예시입니다. 실제 고객 원본은 필요한 접근 통제 아래 별도로 다루고 여기에는 참조만 둡니다.
{
"review_ref": "demo-review-041",
"original_run": "demo-run-041",
"reason": "retry_budget_exhausted",
"external_result": "requires_confirmation",
"eligible_actions": ["inspect", "repair_and_replay", "close_with_reason"],
"assigned_role": "integration_operator",
"decision_evidence": null
}
재진입 조건
가정한 예로 입력 코드가 잘못된 요청은 데이터를 확인해 고쳐야 재시도 의미가 있습니다. 반면 외부 작업이 이미 성공한 결과 불명은 재실행보다 확인과 상태 복구가 필요합니다. 오류 코드가 같다는 이유로 모든 항목을 일괄 다시 보내지 않습니다.
검수 순서
- 재시도 한도를 초과하는 실패를 재현합니다.
- 항목·이력·담당자와 필요한 참조를 확인합니다.
- 수정 후 재진입과 사유 있는 종료를 각각 시험합니다.
- 자동 재시도가 동시에 살아나지 않는지 봅니다.
검토함의 보존·접근·알림도 정합니다. 원본 데이터가 만료되면 어떻게 처리할지 기록하고 항목만 영구히 남아 조사할 수 없는 상태를 피합니다. 담당자 부재 때 넘어갈 경로도 확인합니다.
완료 기준
미처리 업무가 검토함에서 잊히지 않아야 합니다. 가장 오래된 항목과 기한 초과를 관찰하고 실제 해결·승인된 종료와 단순 열람을 나눕니다. 검토함 수가 늘면 자동화의 성공률만 보고하지 말고 사람의 처리 부담과 반복 원인을 함께 설명합니다. 복구 후에는 원장과 외부 결과가 맞는지 확인하고 종료 사유를 남겨 같은 오류의 재발을 분석할 수 있게 합니다.
자주 묻는 질문
- 검토함에 들어갔으면 실패 처리가 완료된 건가요?
- 자동 실행이 멈춘 상태일 뿐 실제 업무의 해결은 남아 있을 수 있습니다. 담당자 인수와 재처리·종료 근거가 있어야 운영 상태를 닫을 수 있습니다.
- 수정 후 원본 요청을 그대로 다시 보내도 되나요?
- 현재 유효한 업무인지와 이전 외부 실행 결과를 확인해야 합니다. 이미 처리됐거나 기한이 지난 요청을 재생하지 않도록 재진입 전 검사를 정합니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.