202 Accepted를 받으면 작업 완료로 표시해도 될까

202를 받았을 때 표시할 결과는 완료가 아니라 접수입니다

202 Accepted는 요청을 처리 대상으로 받아들였지만 아직 처리가 끝나지 않았거나 시작하지 않았을 수 있다는 뜻입니다. 이후 실행이 실패하거나 허용되지 않을 수도 있습니다. 따라서 발송 성공·파일 완성·삭제 완료처럼 최종 결과를 뜻하는 표시로 바로 바꾸지 않습니다. 근거: MDN 202 Accepted, 2026-11-04 확인.

근거: MDN 202 Accepted · 2026-11-04 확인

보고서 생성 예제에서는 세 대상을 나눕니다

가상의 보고서 생성 요청 뒤 작업 ID와 상태 조회 주소를 받았다고 합시다. 제출한 요청, 생성 작업의 현재 상태, 완성된 보고서 파일은 각각 다른 대상입니다. 첫 202는 요청 접수에 대한 답이고 보고서 파일이 열리는지에 대한 답이 아닙니다. 화면에는 접수됨을 표시하고 작업 ID를 보관한 뒤 공식 문서가 정한 경로로 다음 상태를 확인하는 흐름을 만들 수 있습니다.

근거: MDN 202 Accepted · 2026-11-04 확인

응답을 기다리기 전에 후속 확인 계약을 읽습니다

문서에서 작업 ID와 조회 주소를 어디서 받는지, 어떤 상태를 완료·실패로 보는지, 조회 간격과 보존 기간이 있는지 확인합니다. 모든 API가 같은 pending·done 문자열을 사용하는 것은 아니며 폴링 대신 알림 같은 다른 방식을 제공할 수도 있습니다. 최초 HTTP 응답이 끝난 뒤 그 응답이 나중에 자동으로 최종 결과로 바뀌는 것은 아닙니다. 결과를 전달하는 별도 수단이 무엇인지 확인해야 합니다.

근거: MDN 202 Accepted · 2026-11-04 확인

상태 확인부터 산출물 확인까지 순서를 정합니다

허가된 시험에서는 요청 식별자를 기록하고 안내된 상태 경로를 정해진 정책에 따라 조회합니다. 완료 상태라면 제공한 결과 주소나 반환값을 확인하고 실제 내용이 요구와 맞는지 봅니다. 실패 상태라면 오류 설명과 작업 ID를 남깁니다. 완료 상태 문자열을 보았다는 사실과 올바른 파일을 열어 확인한 사실을 따로 기록하면 산출물 누락을 놓치지 않을 수 있습니다.

오래 걸리거나 조회가 끊겨도 새 작업부터 만들지 않습니다

문서에 예상 처리 시간이나 제한이 있다면 그 범위로 판단하고, 없다면 임의의 완료 시간을 만들어 안내하지 않습니다. 상태 조회가 일시 실패하면 기존 작업 ID를 유지하고 공식 재시도 정책을 따릅니다. 작업 상태를 알 수 없을 때 동일 생성을 다시 실행하면 중복 업무가 생길 수 있어 지원 경로로 확인하는 편이 낫습니다. 비용이나 되돌리기 어려운 효과가 있다면 추가 제출을 중단합니다.

사용자 안내에는 확인 시점과 남은 일을 씁니다

접수 시각, 마지막으로 확인한 상태, 결과를 다시 볼 위치를 구분해 안내합니다. 실패를 접수 성공으로 감추지 않고 아직 확인하지 못한 상태는 확인 중으로 남깁니다. 이 글의 보고서 흐름은 설명용 예제이며 실제 작업을 시작하거나 완료 시간을 측정한 사례가 아닙니다.

옆 문서로 이어가기