재시도와 멱등성의 관계: 같은 요청을 두 번 보내도 괜찮을까요
페이지 정보
본문
파일 생성 요청을 보냈는데 응답이 오지 않으면 다시 보내도 되는지 고민하게 됩니다. 서버가 요청을 받지 못했을 수도 있고 작업은 끝났지만 응답만 사라졌을 수도 있기 때문입니다.
재시도는 일시적인 실패를 회복하는 수단이지만 같은 일을 반복 수행하는 문제를 만들 수 있습니다. 멱등성은 이때 반복된 요청이 의도한 상태에 어떤 영향을 주는지 설명하는 개념입니다.
AI 생성 삽화 · 반복된 전달과 하나의 완료 결과를 표현한 개념 삽화입니다.
핵심 정리
응답을 못 받은 상황은 작업 실패가 확정된 상황과 다릅니다. 같은 의도의 재시도를 식별하고 중복된 효과를 막는 계약이 필요합니다.
1. 시간 초과가 알려주는 범위를 구분합니다
클라이언트의 시간 초과는 정해진 시간 안에 기대한 응답을 받지 못했다는 관찰입니다. 그것만으로 서버의 작업이 시작되지 않았거나 취소됐다고 확정할 수는 없습니다.
요청이 도착하기 전, 서버 처리 중, 완료 응답이 돌아오는 중 어디에서 문제가 생겼는지에 따라 상태가 다를 수 있습니다. 이 구분을 놓치면 불확실한 상태를 실패로 단순화하고 새로운 작업을 계속 만들게 됩니다.
예를 들어 보고서 생성 요청을 보낸 뒤 연결이 끊어졌다고 가정합니다. 서버에 보고서가 이미 만들어졌는데 클라이언트가 새 생성 요청을 보내면 같은 내용의 파일이 두 개 생길 수 있습니다.
이 예시는 특정 서비스의 장애 사례가 아니라 재시도 판단을 설명하는 상황입니다. 먼저 완료 여부를 확인할 수 있는 식별자나 상태 조회 경로가 있는지 설계에서 살펴보는 것이 좋습니다.
2. 멱등성은 반복 후 의도한 효과를 봅니다
멱등한 요청은 같은 요청을 반복했을 때 의도한 서버 상태의 효과가 한 번 수행한 것과 같다는 성질로 이해할 수 있습니다. RFC 9110은 HTTP 메서드의 멱등성을 이 관점에서 설명합니다.
모든 응답 바이트가 같아야 한다거나 내부 로그가 한 줄만 남아야 한다는 의미는 아닙니다. 요청이 다시 도착했다는 관찰 자체는 여러 번 기록될 수 있습니다.
학습용 예로 표시 이름을 특정 문자열로 설정하는 동작과 숫자 카운터를 하나 증가시키는 동작을 비교해볼 수 있습니다. 같은 이름으로 다시 설정해도 목표 이름은 같지만 증가 연산을 반복하면 값이 계속 달라집니다.
실제 API에서는 부수 동작과 동시 요청도 함께 검토해야 하므로 이 단순 예시만으로 구현 전체가 멱등하다고 판정하지 않습니다. 어떤 효과를 한 번으로 제한하려는지 먼저 정의해야 합니다.
3. 동일한 내용과 동일한 의도는 다릅니다
내용이 같은 요청을 모두 중복으로 막으면 사용자의 새 요청까지 사라질 수 있습니다. 같은 양식의 보고서 두 부를 별개의 작업으로 만들고 싶을 수도 있습니다.
반대로 네트워크 문제로 같은 생성 의도를 다시 보낼 때는 새 작업으로 만들지 않아야 합니다. 본문의 값만 비교하는 방식이 항상 충분하지 않은 이유입니다.
AWS Builders' Library는 호출자가 제공하는 요청 식별자로 의도를 구분하는 접근을 설명합니다. 이 방식을 개념적으로 적용하면 최초 시도와 재시도에 같은 식별자를 사용하고 별개의 작업에는 새 식별자를 사용합니다.
식별자의 이름과 적용 범위는 API 계약에 따라 다릅니다. 식별자 하나를 모든 기능과 사용자에게 무조건 공유하는 식으로 설계하지 않습니다.
호출자와 작업 종류, 유지 기간 등 어느 범위에서 같은 요청으로 판단할지 정해야 합니다.
4. 요청 식별자와 결과를 함께 관리합니다
서버가 이미 본 식별자라는 사실만 저장하고 실제 작업 결과와 연결하지 않으면 재시도에 무엇을 응답할지 어려워집니다. 처리 중인지 완료됐는지, 동일 식별자로 다른 내용이 들어오면 어떻게 할지 등 상태를 계약으로 정해야 합니다.
특히 식별 기록을 저장하는 일과 실제 효과를 만드는 일 사이에 실패가 생길 수 있다는 점을 생각해야 합니다. 한 줄의 중복 검사만 넣어 모든 문제가 해결되는 것은 아닙니다.
가상의 보고서 서비스에서 요청 식별자 R을 처음 받았다고 해보겠습니다. 처리 중 상태라면 두 번째 R에 새 보고서 생성을 시작하는 대신 계약에 맞는 처리 중 안내나 결과 조회 방법을 제공할 수 있습니다.
완료됐다면 기존 결과와 연결합니다. 이는 설계 예시이며 응답 코드나 저장 방식의 정답을 제시하는 것은 아닙니다.
사용하는 데이터베이스와 작업 특성에 맞춰 원자성 및 복구 방법을 검토해야 합니다.
5. 재시도 조건과 횟수는 별도로 정합니다
멱등성이 있다고 해서 모든 오류를 무한히 재시도할 필요는 없습니다. 입력 형식이 잘못됐다면 같은 입력을 계속 보내도 문제가 해결되지 않을 수 있습니다.
일시적인 장애로 판단할 수 있는 응답과 수정이 필요한 오류를 구분하고 API가 안내하는 재시도 조건을 확인해야 합니다. 기다리는 간격, 총 시도 수, 전체 작업 제한 시간은 멱등성 여부와 별도로 설계하는 항목입니다.
연습 프로젝트에서는 정상 응답, 처리 결과가 불확실한 시간 초과, 명확한 입력 오류를 세 가지 시나리오로 적어볼 수 있습니다. 각 경우에 다시 보낼지, 상태를 조회할지, 사용자에게 수정을 요청할지 정합니다.
기존 라이브러리가 자동으로 재시도하는지도 확인해야 합니다. 애플리케이션과 라이브러리가 각각 반복하면 예상보다 많은 요청이 발생할 수 있기 때문입니다.
재시도 횟수는 한 계층의 코드만 보고 판단하기 어렵습니다.
6. 요청의 늦은 도착과 내용 변경을 생각합니다
같은 식별자를 얼마나 오래 기억할지도 중요한 질문입니다. 기록을 지운 뒤 늦게 도착한 재시도를 새 작업으로 받아들일 가능성이 있는지 검토해야 합니다.
무조건 영구 보관하거나 임의의 짧은 시간을 정하기보다 서비스 계약과 재시도 기간을 연결합니다. 이 글에서는 특정 보관 시간을 권장하지 않습니다.
실제 API의 보장 범위와 호출 방식에 따라 달라지는 부분입니다. 같은 식별자로 다른 보고서 조건이 들어오는 경우도 따로 생각해볼 수 있습니다.
사용자가 조건을 바꾼 새 요청인지 클라이언트가 식별자를 잘못 재사용했는지 모호해집니다. 서버가 조용히 이전 결과를 반환하면 사용자는 바뀐 조건이 반영됐다고 오해할 수 있습니다.
내용 불일치를 어떻게 알릴지 정하고 호출 측에서도 새 의도에 새 식별자를 쓰도록 관리해야 합니다. 식별자는 임의의 장식 값이 아니라 요청 의미를 연결하는 정보입니다.
7. 세 번의 호출을 표로 검토하는 연습
직접 설계한 예제로 첫 호출 R, 같은 내용의 재호출 R, 같은 내용이지만 새 의도인 호출 S를 적어봅니다. R의 재호출에서는 결과가 중복 생성되지 않아야 하고 S는 새 작업으로 처리돼야 한다는 기대를 먼저 씁니다.
여기에 R을 다른 내용으로 보낸 경우를 추가하면 오류 계약까지 생각할 수 있습니다. 실제 실행 전의 기대값과 실행 후 관찰 결과는 별도로 기록해야 합니다.
테스트를 한다면 단순히 요청 두 번에 성공 응답이 왔는지만 보는 것은 부족합니다. 실제 결과물이 몇 개 생겼는지, 두 응답이 어떤 작업을 가리키는지, 중간 실패에서 어떤 상태가 남았는지 확인할 수 있어야 합니다.
외부 시스템의 효과가 포함되면 그 시스템의 계약도 검토 대상입니다. 멱등성을 이해하는 목표는 재시도 버튼을 많이 누를 수 있게 만드는 것이 아닙니다.
불확실한 통신 상황에서도 동일한 의도와 새로운 의도를 구분해 원하는 결과로 수렴하도록 설계하는 데 있습니다.
8. 자주 묻는 질문
Q1. 응답이 없으면 서버 작업도 실패한 것인가요?
그렇게 확정할 수 없습니다. 서버 처리 전후 어느 단계에서 응답을 받지 못했는지 불확실할 수 있으므로 상태 조회나 재시도 계약을 확인합니다.
Q2. 같은 JSON이면 같은 요청으로 보면 되나요?
동일한 내용으로 새 작업을 원할 수도 있습니다. 내용의 동일성과 사용자의 의도는 구분하고 요청 식별자의 의미를 계약으로 정합니다.
Q3. 멱등한 요청은 응답도 항상 같아야 하나요?
의도한 서버 효과가 기준이며 모든 응답 표현이나 내부 기록이 동일해야 한다는 뜻은 아닙니다. 구체적인 응답 보장은 해당 API 문서를 확인합니다.
Q4. 식별자만 추가하면 중복 처리가 해결되나요?
서버의 식별 기록, 실제 작업, 결과 반환, 동시 요청과 실패 복구가 연결되어야 합니다. 식별자를 보내는 것만으로 서버가 그 계약을 구현했다고 볼 수는 없습니다.
참고 자료
- 이전글LLM 토큰과 컨텍스트 길이, 글자 수와 다른 이유 26.09.13
- 다음글캐시와 원본 데이터의 차이: 만료와 무효화를 이해하기 26.09.13
댓글목록
등록된 댓글이 없습니다.