서버 응답이 끊겼을 때 요청을 다시 보내도 될까: 중복 실행과 재시도 설계

가정한 문제: 서버는 처리했지만 응답이 도착하지 않습니다

해석 제출이나 라이선스 재발급처럼 상태를 바꾸는 요청을 보냈는데 연결이 끊기는 상황을 가정합니다. 클라이언트가 같은 요청을 새 요청으로 다시 보내면 중복 작업이나 불필요한 상태 변경이 발생할 수 있습니다. 인증 실패와 일시 장애도 서로 다른 대응이 필요합니다. IETF RFC 9110은 멱등 메서드의 자동 재시도 조건과 비멱등 요청 재시도의 제한을 설명합니다. POST라는 메서드 이름만 보고 안전한 재시도라고 판단하지 않습니다. 서버의 작업 계약과 이미 처리됐는지 판단할 수 있는 근거가 필요합니다.

• 요청별 공개 가능한 식별자·시간·메서드·결과 상태를 기록하고 비밀번호·라이선스 키·인증 토큰은 로그에서 제외합니다.
• 401·403 같은 인증·권한 오류는 자격과 권한을 먼저 확인합니다. 같은 비밀값을 반복 전송하는 방식으로 해결하지 않습니다.
• 재시도 횟수·총 대기 시간·사용자 취소를 제한합니다. 무한 반복이 다른 장애를 만들지 않도록 설계합니다.

대안 A: 제출 후 결과 조회로 불확실성을 줄입니다

개발 적용 제안: 작업 제출 전에 클라이언트 요청 식별자를 만들고 서버가 이를 작업 ID와 연결해 보관합니다. 응답 유실 뒤 같은 식별자로 상태를 조회해 존재 여부와 진행 상태를 확인합니다. 적용 조건: 서버가 사용자의 소유권을 확인하는 조회 API와 보존 기간을 제공해야 합니다. 조회 결과가 없더라도 조회 시점의 지연·처리 중 상태를 고려해야 합니다. 이를 확인하지 않고 곧바로 새 작업을 만드는 것은 안전한 계약이 아닙니다. 비용과 한계: 상태 보존과 사용자별 권한 확인이 필요합니다. 상태 조회는 중복 실행 방지를 자동으로 보장하지 않습니다. 현재 사이트에 범용 해석 작업 제출·조회 API가 구현돼 있다는 뜻은 아닙니다.

대안 B: 서버가 중복 방지 키와 요청 내용을 함께 검증합니다

개발 적용 제안: 같은 사용자·같은 작업 범위·같은 중복 방지 키는 한 논리 요청으로 취급하고 요청 내용 해시도 비교합니다. 같은 키로 다른 내용을 보내면 오류로 처리하고, 같은 내용의 반복에는 최초 작업 결과나 처리 중 상태를 반환하는 계약을 정의합니다. 원자적 저장과 경쟁 요청 처리를 설계해야 합니다. 먼저 존재 여부를 조회한 뒤 따로 삽입하는 방식은 동시 요청 경쟁을 놓칠 수 있습니다. 데이터베이스 고유 제약·트랜잭션 또는 큐 계약은 해당 저장소의 보장을 확인한 뒤 선택합니다. 비용과 한계: 키의 보존 기간, 사용자 범위, 만료 뒤 동작, 진행 중 응답과 장애 복구를 명확히 해야 합니다. 키를 인증 수단으로 사용하지 않으며 다른 고객의 결과를 반환하지 않습니다. 아래 비교는 설계 제안이며 현재 모든 운영 API에 적용되어 있지 않습니다.

대안 C: 안전성이 확인된 요청만 제한적으로 재시도합니다

조회처럼 재시도에 따른 효과가 명확한 요청이나 서버가 중복 방지 계약을 제공하는 상태 변경 요청에서 검토합니다. 오류 종류를 나누고 시도 간 대기와 총 시도 수를 제한합니다. 일시적으로 사용할 수 없는 응답에 Retry-After가 있으면 그 의미를 우선 고려합니다. RFC 9110은 503 응답의 Retry-After를 서비스가 사용할 수 없을 것으로 예상되는 기간과 연결해 설명합니다. 개발 적용 제안: 지수적 대기와 무작위 분산을 후보로 비교하고, 총 대기 시간 예산 안에서만 수행합니다. 이것은 RFC가 특정 지연 상수를 권장한다는 뜻이 아니며 해당 서비스의 요청 제한과 사용자 경험에 맞춰 검증해야 합니다. 비용과 한계: 재시도는 부하를 늘립니다. 처리 여부가 불확실한 상태 변경 요청에는 대기 시간을 늘리는 것만으로 중복 문제를 해결할 수 없습니다. 요청 계약이 부족하면 자동 재시도를 멈추고 결과 확인 절차를 안내하세요.

통신 오류 주입 검증과 복원 조건

개발용 격리 환경에서 응답 전 연결 해제, 처리 후 응답 유실, 같은 키의 동시 요청, 같은 키의 다른 내용, 권한 오류, 서비스 일시 장애를 나눠 검증합니다. 운영 고객의 라이선스를 재발급하는 방식으로 시험하지 않습니다. 검증 기준: 한 논리 요청이 몇 개의 작업·상태 변경을 만들었는지, 다른 고객의 결과가 노출되는지, 취소와 대기 상한이 지켜지는지를 확인합니다. 통신 성공률만으로 정합성을 판정하지 않습니다. 중복 변경이나 권한 오류가 발생하면 자동 재시도를 중단하고 이전 정책으로 복원합니다. 이미 생성된 작업은 운영 검토 후 처리하며 임의 삭제나 재발급을 하지 않습니다.