프론트엔드 설계
불확실한 응답과 멱등 재시도
같은 주문·결제 요청을 다시 보내더라도 중복 처리가 생기지 않도록 요청 식별 키와 서버 계약을 함께 맞춥니다.
이럴 때 필요해요
결제나 예매 버튼을 눌렀는데 네트워크 타임아웃이 났을 때, 서버는 이미 처리를 끝냈는데 응답만 오지 않은 것인지 실제로 실패한 것인지 구분해야 합니다.
어떻게 동작하나요?
요청을 보낸 뒤 응답을 받지 못했다고 해서 서버가 아무 일도 하지 않았다고 단정할 수 없습니다. 서버에서는 주문 처리가 성공했는데 돌아오는 응답만 네트워크에서 끊겼을 수 있기 때문입니다. 따라서 프론트엔드의 '응답 시간 초과'와 서버의 '실제 작업 결과'는 나누어 다루어야 합니다.
이때 같은 요청을 여러 번 보내더라도 결과가 한 번 처리한 것과 같게 유지되는 성질을 멱등성(Idempotency)이라고 합니다. API가 지원하는 멱등성 키(Idempotency-Key)는 '이 재시도는 아까 보낸 그 주문과 같은 의도입니다'라고 알려주는 식별자입니다. 단, 프론트엔드에서 헤더에 키를 적어 보내는 것만으로는 충분하지 않고, 서버가 그 키와 요청 내용·처리 결과를 대조해 중복 실행을 막는 계약을 구현해야 성립합니다.
클라이언트는 타임아웃 후 같은 주문을 다시 시도할 때는 기존 키를 그대로 유지하고, 사용자가 완전히 새로운 주문을 시작할 때만 새 키를 발급합니다. 동시에 진행 중임을 알리는 화면 표시, 버튼 중복 클릭 방지, 현재 처리 상태를 먼저 조회하는 흐름도 함께 설계해야 안전합니다.
코드 예제
동작을 설명하는 읽기 전용 예제입니다.
POST /orders/order-42/confirm
Idempotency-Key: intent-order-42-v1
타임아웃 후 같은 주문 의도를 재시도:
같은 키 + 같은 의미의 매개변수
새로운 주문 의도:
새 키 + 별도의 주문 식별설명용 요청 계약입니다. 실제 서버나 결제를 실행하지는 않으며, 응답이 유실된 뒤 같은 주문 의도로 재시도할 때 동일한 키를 유지하는 흐름을 보여 줍니다.
자주 헷갈리는 포인트
- 프론트엔드에서 멱등성 키를 만들어 보냈다는 사실만으로 서버의 중복 방지까지 자동으로 보장된다고 생각하면 안 됩니다.
- 멱등 재시도는 내 요청이 두 번 실행되는 것을 막아 줄 뿐, 다른 사용자와 같은 좌석을 두고 경쟁하는 문제까지 자동으로 해결해 주지는 않습니다.
내 말로 설명해 보기
서버가 처리를 끝냈지만 응답만 못 받은 상황에서, 버튼 비활성화·상태 조회·멱등성 키는 각각 어떤 문제를 막아 주나요?
생각할 단서 사용자의 연속 클릭, 현재 서버 상태 확인, 재전송 시 중복 실행 방지를 각각 나누어 생각해 보세요.
예시 답변 확인
설명에 들어갈 핵심
- 버튼 비활성화는 진행 중 사용자의 중복 클릭을 줄입니다
- 상태 조회는 이미 처리된 작업을 다시 요청하지 않게 확인합니다
- 멱등성 키는 서버 계약과 함께 같은 의도의 재시도가 중복 실행되지 않게 돕습니다
예시 답변
버튼 비활성화는 응답을 기다리는 동안 사용자가 버튼을 연타해 요청이 여러 번 나가는 것을 막습니다. 상태 조회는 타임아웃 직후 서버에서 이미 주문이 완료되었는지 먼저 확인할 때 쓰이고, 멱등성 키는 재시도 요청이 들어가더라도 서버가 같은 작업 의도임을 알아보고 중복 결제나 중복 생성을 막도록 연결해 줍니다.
문장을 그대로 외우기보다 예제의 값과 실행 흐름을 떠올리며 설명해 보세요.