오류가 났다는 이유만으로 반복하지 않습니다
입력 형식이 틀린 작업을 같은 값으로 반복해도 문제는 고쳐지지 않습니다. 반면 일시적인 접속 장애는 시간이 지난 뒤 해결될 수 있습니다. 확인한 상태와 필요한 수정 행동을 기준으로 분류하세요.
재시도 결정에는 실패 원인뿐 아니라 이미 외부 동작이 적용되었을 가능성도 중요합니다. 결과를 받지 못했는데 메시지나 데이터는 이미 생성됐을 수 있습니다.
기다릴 조건과 수정할 조건을 나눕니다
아래는 가상의 운영 기준입니다. 실제 API나 서비스의 오류 의미·제한·재시도 안내를 확인한 뒤 적용하세요. 같은 오류 이름도 시스템마다 처리 조건이 다를 수 있습니다.
입력이 잘못되거나 권한이 부족한 경우에는 수정 담당자를 정하고 정상 항목과 분리합니다. 일부 항목의 오류 때문에 전체 작업을 처음부터 반복하지 않도록 범위를 기록합니다.
| 확인한 상황 | 초기 판단 예시 | 다음 행동 |
|---|---|---|
| 입력 필수값 누락 | 그대로 재시도하지 않음 | 입력 수정 후 재검증 |
| 일시적 서비스 불가 | 안내에 따라 제한 재시도 | 대기·횟수·결과를 기록 |
| 권한 확인 필요 | 재시도보다 점검 | 계정·권한 담당자 확인 |
| 외부 결과 적용 여부 불명 | 중복 위험 확인 | 대상 상태를 조회 후 결정 |
대기 안내가 있다면 의미대로 처리합니다
HTTP의 Retry-After는 다음 요청 전 기다릴 시간을 안내하며 날짜 형식이나 지연 초 수를 사용할 수 있습니다. 503 응답에서는 서비스 불가 기간의 안내로 사용될 수 있습니다.
이 헤더가 없다고 즉시 무제한 재시도해도 된다는 뜻은 아닙니다. 실제 서비스의 안내에 맞춰 최대 횟수와 총 대기 시간을 정하고, 긴 대기가 필요하면 이번 실행을 종료해 다음 처리로 넘기는 방식을 고려하세요.
다시 보낼 때 결과 중복을 확인합니다
HTTP 표준은 안전성이 확인되지 않은 비멱등 요청의 자동 반복을 경계합니다. 업무에서는 요청 형태뿐 아니라 실제 저장·전송 결과와 중복 방지 조건을 확인해야 합니다.
가상의 알림 작업이라면 “전송 실패” 기록만 보고 재발송하지 말고 수신 결과를 확인할 수 있는지 봅니다. 확인할 수 없다면 미확인 상태를 따로 남기고 사람의 판단이 필요한 범위를 정하세요.
격리는 삭제가 아니라 다음 행동의 기록입니다
정상 입력은 계속 처리하고, 문제가 있는 항목은 원인·현재 상태·담당자·재처리 조건을 남깁니다. 단순히 숨기면 같은 항목이 계속 들어와 같은 실패를 만들 수 있습니다.
문제가 해결되면 해당 항목만 다시 검증하고 처리합니다. 재시도 횟수가 많다는 사실을 안정성의 증거로 보지 말고 실제 복구율과 사람이 쓴 시간을 함께 관찰하세요.