202는 접수와 완료를 구분한다

작업이 접수됐지만 진행 중인 상태와 별도 상태 확인 경로를 나타낸 추상적인 서버·클라이언트 흐름

오래 걸리는 내보내기나 대량 변환 요청을 받았다고 서버가 연결을 끝날 때까지 열어둘 필요는 없다. 202 Accepted는 요청을 처리 대상으로 받아들였지만 아직 처리가 끝나지 않았다는 뜻이다. RFC 9110은 실제 처리 단계에서 요청이 거부될 수도 있어 이 응답이 의도적으로 확약적이지 않다고 설명한다. 따라서 화면에는 “완료”가 아니라 “접수됨” 또는 “처리 중”이라고 표시한다. IETF RFC 9110 §15.3.3

응답에 상태 확인 방법을 담는다

202 응답 표현은 현재 상태를 설명하고, 완료 예상 시점을 확인할 수 있는 상태 모니터를 가리키는 것이 바람직하다. 구현 예로 작업 ID와 /jobs/{id} 같은 URL을 반환하고 queued, running, succeeded, failed 상태를 제공할 수 있다. 이는 권고를 구현하는 한 방식일 뿐, URL이나 상태 이름을 HTTP 표준이 지정하지는 않는다.

상태 조회는 작업 제출과 분리된 읽기 요청으로 둔다. 마지막 갱신 시각, 결과 또는 실패 이유 등 다음 행동에 필요한 정보를 제공하고, 작업 ID가 추측 가능하더라도 다른 사용자의 결과가 노출되지 않게 조회 권한을 확인한다.

재조회 간격은 API 계약으로 정한다

너무 잦은 폴링은 작업이 느린 동안 불필요한 트래픽을 만든다. 첫 조회 전 잠시 기다리고, 계속 처리 중이면 간격을 늘리거나 서비스가 제공한 대기 안내를 따를 수 있다. RFC 9110의 Retry-After는 503에서 서비스가 다시 이용 가능해질 때까지의 시간과 3xx 리다이렉션 요청 전 최소 대기 시간을 정의한다. 이 정의만으로 202의 폴링 간격이 정해지는 것은 아니다. API가 별도 힌트를 반환한다면 그 의미와 단위를 문서화해야 한다. IETF RFC 9110 §10.2.3

연결이 끊겨도 결과는 알 수 없다

202를 보낸 뒤 연결을 닫아도 서버 작업은 계속될 수 있다. 접수 응답은 최종 성공을 보장하지 않는다. 상태 조회가 타임아웃되면 성공이나 실패를 추정하지 말고 같은 작업 ID로 다시 조회한다. 최초 제출 응답을 받지 못했다면 서버가 이미 접수했는지 알 수 없으므로 재시도가 새 작업을 만들지 않도록 별도 중복 방지 정책이 필요하다. RFC는 비동기 처리 결과를 원래 연결로 나중에 되돌려 보내는 HTTP 기능이 없다고 명시한다.

상태 리소스는 “아직”만 반복하기보다 소비자가 다음에 할 수 있는 일을 알려주면 유용하다. 예를 들어 작업 식별자, 현재 단계, 마지막 갱신 시각, 완료 후 결과 링크를 구분해 제공할 수 있다. 이는 RFC의 강제 필드가 아니라 서비스 계약의 설계 선택이다. 예상 완료 시각을 안내한다면 추정치라는 점과 언제 갱신되는지도 설명한다.

상태 조회에는 제출 요청과 별개의 권한 검사가 필요할 수 있다. 작업 ID를 안다는 사실이 결과 열람 권한을 뜻하지 않도록 상태와 결과에 각각 접근을 확인하고, 민감한 실패 정보가 노출되지 않는지 점검한다. 상태 기록을 얼마나 보관할지, 만료된 주소에 무엇을 응답할지, 재제출을 이전 작업과 어떻게 연결할지도 문서화한다. 제출 응답을 받지 못한 경우는 서버가 접수했는지 모를 수 있지만, 상태 조회만 실패한 경우에는 작업 결과가 여전히 미정일 수 있다. 두 불확실성을 같은 실패로 취급하지 않는다.

클라이언트는 상태값을 업무별로 해석할 수 있도록 성공·실패·취소처럼 종결 상태와 대기·진행 상태를 구별해야 한다. HTTP 표준은 이 이름을 지정하지 않으므로, 서로 다른 구현이 같은 값을 뜻한다고 가정하지 말고 API 계약에서 의미를 고정한다.

전문가 자료와 표준의 범위

RFC 9110은 Roy T. Fielding, Mark Nottingham, Julian Reschke가 편집한 HTTP 의미론 표준이다. 202가 미완료 요청의 접수를 나타내고 상태 설명과 모니터를 제공하는 것이 바람직하다는 점을 규정한다. 작업 큐, 폴링 주기, 보존 기간, 취소, 중복 제출 정책은 정하지 않는다. 처리 시간과 비용, 보안 요구를 반영해 API 계약에서 결정해야 한다.

출처

IETF, RFC 9110: HTTP Semantics, §§15.3.3 and 10.2.3 MDN Web Docs: 202 Accepted