시간 초과 뒤 재시도했더니 두 번 저장됐다: 요청과 결과를 구분하기

메모 저장 버튼을 눌렀는데 응답이 늦어져 오류가 떴다. 다시 누르면 될까? 클라이언트에 표시된 시간 초과만으로는 서버가 저장하지 않았다고 결론 내릴 수 없다. 이 글에서는 저장을 완료한 뒤 응답만 보류하는 작은 API를 만들고, 같은 내용을 다시 보냈을 때 데이터가 어떻게 달라지는지 확인했다.

응답이 없는 것과 처리가 안 된 것은 별개였다

두 실험 경로 모두 첫 요청에서 메모 한 개를 메모리 목록에 넣었다. 그 뒤 응답을 보내기 직전에 이벤트를 기다리게 했다. 클라이언트는 0.2초 동안 기다린 뒤 timeout으로 끝났다. 이 값은 일부러 결과를 재현하려고 짧게 정한 것이며 실제 서비스의 권장 제한 시간이 아니다. 스크립트는 저장 단계에 도달했다는 이벤트도 별도로 확인했다.

실험의 plain 경로는 요청을 받을 때마다 새 메모를 만들었다. keyed 경로는 요청 키와 입력 내용의 해시를 기록하고, 이미 처리한 같은 키·같은 입력이면 기존 ID를 반환했다. 두 경로에 동일한 논리적 메모를 다시 요청해 저장 수와 응답을 비교했다.

plain에서는 첫 응답이 timeout이었지만 재시도 직전 저장 수가 이미 1이었다. 재시도는 201과 ID 2를 반환했고 저장 수가 2가 됐다. keyed도 첫 요청에서 1개를 저장했지만 재시도는 200과 기존 ID 1을 돌려줬고 저장 수는 1이었다. 200과 201의 선택은 이번 합성 API가 정한 응답 정책이지, 모든 API가 따라야 하는 재시도 응답 규칙은 아니다.

무엇을 같은 요청으로 볼지 먼저 정했다

같은 제목을 쓰는 메모가 두 개 있을 수도 있기 때문에 제목만으로 중복을 판정하지 않았다. 실험은 Idempotency-Key라는 헤더에 논리적 요청 식별자를 넣고 그 키와 입력 바이트의 SHA-256을 함께 저장했다. 재시도에는 처음과 같은 키를 보냈다. 매번 새 키를 만들면 서버는 이전 시도와 연결할 근거를 잃는다.

def process_once(key, input_hash, create_note, completed, lock):
    with lock:
        if key in completed:
            old_hash, result = completed[key]
            if old_hash != input_hash:
                raise ValueError("same key, different input")
            return result
        result = create_note()
        completed[key] = (input_hash, result)
        return result

이 함수는 중복 판정 부분만 나타낸 예제다. create_note는 새 메모를 만드는 콜백이고 completed는 처리 결과 사전이다. HTTP 요청을 받고 상태 코드로 변환하는 부분은 내려받을 수 있는 전체 스크립트에 있다. 실행 스크립트에서는 하나의 threading.Lock 안에서 키 조회·메모 생성·결과 기록을 수행했다. 단일 프로세스의 메모리 사전이므로 프로세스가 사라지면 기록도 사라진다. 외부 저장을 완료한 뒤 키 기록 전에 장애가 나는 문제를 해결한 영속 구현으로 받아들이면 안 된다.

같은 키로 다른 입력을 보내면 어떻게 되는가

성공한 keyed 요청의 키를 유지하고 제목만 바꿔 추가 요청했다. 실험 API는 409와 key reused with different input 오류를 돌려줬고 새 메모를 만들지 않았다. 기존 결과를 조용히 반환하면 요청자가 변경된 제목이 저장됐다고 오해할 수 있어 이 실험에서는 충돌로 처리했다. 이 역시 우리가 선택한 계약이며, 사용하는 외부 API의 키 범위와 재사용 규칙은 해당 문서로 확인해야 한다.

입력 비교도 단순하지 않다. 이번에는 동일한 JSON 바이트로 재시도했으므로 해시를 그대로 비교할 수 있었다. 의미가 같은 JSON이라도 공백이나 키 순서가 바뀌면 바이트는 달라질 수 있다. 실제 구현에서는 어떤 필드를 같은 작업으로 볼지, 정규화와 비교 범위를 어떻게 정할지 별도로 설계해야 한다.

클라이언트에서 무조건 재전송하기 전에 확인할 것

RFC 9110은 비멱등 요청을 자동 재시도할 때 원래 요청이 적용되지 않았음을 알거나 그 의미가 멱등임을 아는 등의 조건을 다룬다. 여기서 멱등은 같은 의도의 요청을 반복해도 의도한 서버 효과가 한 번과 같다는 의미다. 요청이 POST라는 사실만 보고 무조건 재시도하거나, timeout이면 미처리라고 간주하는 방식 모두 충분하지 않다.

예를 들어 이 실험의 같은 키·같은 입력은 timeout → 200·기존 ID 1이었고, 키 없는 단순 재시도는 timeout → 201·새 ID 2였다. 이 응답 규칙을 외부 API에 임의로 적용하지 않는다. 키 보관 시간, 재사용 범위와 오류 후 동작은 사용하는 API의 계약을 먼저 읽는다.

운영에 적용하려면 남은 검증이 있다

하나의 서버 안에서도 키 기록과 실제 저장 사이에 일관성을 유지해야 한다. 여러 서버가 요청을 나눠 받으면 공통 저장소와 충돌 처리도 필요하다. 이번 실험은 이 분산 문제를 다루지 않는다. 또한 재시도 간격을 늘리거나 무작위 지연을 섞는 전략과 중복 방지는 목적이 다르다. 기다렸다 재전송하더라도 같은 작업을 다시 만들 수 있다는 점은 남는다.

운영 기록에는 처음 시도와 재시도를 연결하는 ID, 시도 횟수, 최종 확인 결과를 남기는 것이 좋다. 비밀번호나 전체 요청 본문을 로그에 넣을 필요는 없다. 이 실험의 메모 내용은 고정 합성 문자열이며 실제 계정이나 외부 API를 호출하지 않았다.

python3 lab-http-retry.py --output new-observations.json