01
행동마다 요청 번호
예약·주문처럼 한 번만 반영되어야 하는 행동에 고유한 번호를 붙여 같은 시도를 알아봅니다.
개발 기술 · 더 알아보기 · 직접 체험형
요청이 실패하거나 두 번 전송되면 서버는 어떻게 처리할까요?
버튼을 한 번 눌러도 통신 지연 때문에 같은 요청이 다시 전달될 수 있습니다. 앱의 버튼만 잠그지 않고 서버가 요청을 구분하고 저장 결과를 확인해야 중복 예약·주문·제출을 막을 수 있습니다.
약 11분쉽게 보는 핵심 기준
SAFE REQUEST FLOW결과는 하나
같은 요청 2번
REQ-2409
요청 번호 확인
이미 처리 중
한 번만 저장
예약 R-1024
첫 번째 응답
예약 R-1024 생성
두 번째 응답
같은 R-1024 반환
먼저 이해할 내용
앱이 응답을 못 받았다고 서버 처리까지 실패한 것은 아닙니다
앱과 서버 사이의 응답이 늦거나 끊기면 사용자는 처리 결과를 알 수 없습니다. 이때 무조건 새 요청을 만들지 않고 같은 행동에 요청 번호를 붙여 서버의 기존 처리 결과를 먼저 확인하면, 다시 눌러도 예약이나 주문이 한 번만 반영되게 만들 수 있습니다.
- 01
요청 번호 만들기
- 02
서버 처리 확인
- 03
한 번만 저장
- 04
같은 결과 안내
요청 처리 과정 직접 확인하기
같은 요청이 다시 와도 결과는 하나만 만들어야 합니다
서비스와 발생 상황을 고른 뒤 네 단계를 눌러보세요. 앱 화면, 서버 판단과 저장 결과가 어떻게 달라지는지 문장과 흐름으로 함께 보여드립니다.
어떤 상황이 벌어졌나요?
현재 상황 · 빠른 두 번 누르기
9월 12일 오후 2시 상담을 신청합니다.
지금 벌어지는 일 · 고객 앱
두 번 눌러도 같은 REQ-RSV-2409를 사용합니다
9월 12일 오후 2시 상담을 신청합니다. 첫 요청이 끝나기 전에 버튼이 다시 눌렸습니다. 두 전달이 같은 사용자 행동임을 구분해야 합니다.
- 사용자 화면
- 버튼은 즉시 처리 중으로 바꾸지만 느린 기기나 통신에서는 두 요청이 도착할 수도 있습니다.
- 서버 판단
- 아직 서버에 도착하기 전입니다.
- 저장된 상태
- 저장된 결과가 없습니다.
- 안전한 다음 행동
- 화면 차단과 서버 확인을 함께 사용합니다.
1 / 4 단계
중복과 실패를 막는 기본
버튼 잠금과 서버의 요청 확인을 함께 적용합니다
화면에서 연속 누르기를 줄이는 것은 첫 번째 보호입니다. 느린 통신, 자동 재시도와 여러 기기에서도 결과가 하나가 되려면 서버와 저장소가 요청 번호를 기준으로 다시 확인해야 합니다.
02
서버에서 중복 확인
앱 버튼을 잠그는 것에 그치지 않고 서버와 저장소가 같은 번호의 두 번째 처리를 막습니다.
03
저장 결과와 응답 분리
앱이 응답을 놓쳐도 서버에 저장된 결과를 다시 찾아 같은 완료 화면으로 이어갑니다.
04
정해진 조건만 재시도
모든 오류를 반복하지 않고 일시적인 오류만 횟수와 간격을 제한해 다시 처리합니다.
오류마다 다른 다음 행동
모든 실패를 자동으로 다시 보내지는 않습니다
잘못된 입력이나 권한 문제는 같은 요청을 반복해도 해결되지 않습니다. 다시 시도할 수 있는 오류와 사용자의 확인이 필요한 오류를 구분합니다.
입력값 오류
바로 재시도하지 않음누락된 값이나 잘못된 형식을 알려주고 사용자가 수정한 뒤 새로 요청합니다.
로그인·권한 만료
사용자 확인 후 이어가기로그인이나 권한을 다시 확인하고 원래 하던 행동으로 안전하게 돌아갑니다.
일시적인 통신·서버 오류
간격을 늘리며 제한 재시도같은 요청 번호를 사용하고 재시도 횟수와 전체 대기 시간을 제한합니다.
처리 결과를 알 수 없음
기존 결과부터 확인새 요청을 만들기 전에 요청 번호나 주문·예약 번호로 이미 반영됐는지 조회합니다.
고객과 함께 정하는 내용
- 한 번만 반영되어야 하는 예약·주문·결제·제출 행동
- 처리 중 사용자가 기다릴 수 있는 시간과 안내 문구
- 최종 실패 후 확인할 화면과 문의 방법
- 중복이 생겼을 때 유지할 결과와 취소·복구 정책
데브크래프트가 구현하는 내용
- 요청 번호 생성과 서버·저장소의 중복 확인
- 처리 중·완료·실패 상태와 기존 결과 조회
- 오류 종류별 재시도 횟수·간격·중단 조건
- 중복·지연·실패 기록과 운영자 확인 화면
공식 기준과 실제 서비스 사례를 참고합니다
안전하게 반복할 수 있는 요청인지 먼저 구분합니다
HTTP 표준은 같은 요청을 반복해도 서버의 의도한 결과가 같아야 하는 성질을 설명합니다. 결제 API와 클라우드 서비스도 요청 번호와 제한된 재시도 조건으로 중복 처리를 줄이는 방법을 제공합니다.
“오류가 났으니 다시 눌러주세요”만 안내하면 중복 결과가 생길 수 있습니다
앱이 응답을 받지 못한 것과 서버가 처리하지 못한 것은 다릅니다. 새 요청 전에 기존 결과를 확인하고, 같은 사용자 행동이라면 같은 요청 번호를 사용해야 사용자가 안심하고 이어갈 수 있습니다.
확인할 내용
이 내용을 보면 알 수 있습니다
- 앱의 통신 실패와 서버의 실제 처리 실패가 서로 다를 수 있다는 점 이해하기
- 같은 행동에 요청 번호를 붙여 중복 저장을 막고 기존 결과를 돌려주는 방법 확인하기
- 다시 시도할 오류와 사용자가 입력을 고쳐야 할 오류를 구분해 안내하기
판단 기준
실제 구현에서는 이렇게 확인합니다
- 01응답이 끊긴 뒤 서버에 이미 반영됐는지 같은 요청 번호로 확인할 수 있는가
- 02빠른 두 번 누르기와 자동 재시도가 한 건의 예약·주문·제출로 처리되는가
- 03재시도 횟수와 간격, 최종 실패 후 사용자·운영자 확인 방법이 정해져 있는가
우리 서비스의 실패·재시도 기준을 함께 정리해보세요
예약·주문·결제·파일 제출처럼 중복되면 곤란한 기능을 알려주세요. 요청 구분, 저장과 복구, 사용자 안내 기준을 30분 상담에서 함께 정리합니다.