오류 분류
정상 입력의 일시 실패와 수정해야 하는 입력·인증 실패를 구분합니다. 공급자의 제한 안내와 응답 본문을 확인하되 비밀값을 로그에 복사하지 않습니다. 같은 코드도 도구별 의미와 재시도 권장이 다를 수 있어 현재 공식 문서에 맞춰 정책을 정합니다.
정책 논의용 예시
아래 수치는 가정한 운영 설계입니다. 실제 공급자의 대기 안내와 업무 긴급도, 비용과 처리 기한을 확인한 뒤 정해야 합니다.
{
"policy_name": "demo-transient-failure",
"maximum_attempts": 4,
"delays_seconds": [15, 60, 180],
"stop_on_invalid_input": true,
"stop_on_permission_error": true,
"require_request_deduplication": true,
"after_exhaustion": "manual_review_queue"
}
대기와 총 기한
각 시도의 간격만 아니라 업무가 언제까지 완료돼야 하는지도 정합니다. 긴급 문의 배정과 일일 보고서 갱신은 같은 지연을 허용하지 않을 수 있습니다. 재시도 예약이 누적돼 장애가 풀린 뒤 한꺼번에 실행되는 상황과 호출 한도도 고려합니다.
검수 순서
- 일시 오류와 영구 오류의 가정 응답을 만듭니다.
- 기대 횟수와 대기 조건을 확인합니다.
- 외부 성공 뒤 응답 유실의 중복을 시험합니다.
- 소진 후 원장과 담당자 알림을 검증합니다.
재시도 성공으로 최초 오류 기록을 지우지 않습니다. 실제 지연과 시도 횟수가 남아야 장애 빈도를 알 수 있습니다. 수동 재처리와 자동 재시도가 동시에 같은 업무를 실행하지 않는지도 봅니다.
완료와 운영
어떤 오류가 자동 회복되고 무엇이 사람에게 넘어가는지 담당자가 이해해야 합니다. 단순 성공률보다 최종 미처리와 처리 지연, 중복을 함께 관찰합니다. 재시도가 작동한다는 사실로 외부 서비스 장애가 사라졌다고 보고하지 않고 원인별 빈도와 남은 업무를 구분해 관리합니다.
자주 묻는 질문
- 실패하면 무제한 재시도하는 게 안전한가요?
- 입력이나 권한이 틀린 요청은 반복해도 해결되지 않을 수 있고 호출 제한과 중복을 늘릴 수 있습니다. 오류 분류와 한도, 사람에게 넘길 조건을 정해야 합니다.
- 응답 코드만으로 재시도 여부를 결정하나요?
- 코드와 함께 공급자의 실제 규칙, 작업의 부작용과 결과 확인 가능성을 봅니다. 응답을 못 받은 상태는 실패 확정과 다를 수 있어 안전한 재처리 설계가 필요합니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.