요약

  • 1997년 1월 RFC 2068은 HTTP/1.1에 402 Payment Required를 넣고 단 한 줄을 붙였다. “향후 사용을 위해 예약됨.”
  • RFC 2616, RFC 7231, RFC 9110은 그 예약을 이어갔다. HTTP에는 402를 위한 공통 가격, 결제 요청, 정산 규칙이 없다.

표지판은 먼저 왔고, 계산대는 오지 않았다

RFC 1945는 상태 코드를 기계가 읽는 요청 결과로 설명하고 HTTP/1.0에서 인정된 값을 열거했다. 클라이언트 오류 목록은 401 Unauthorized 다음에 403 Forbidden을 두었고 402는 빠져 있었다. 확장 코드는 허용됐으므로 목록 밖 번호도 확장 방식으로 사용할 수 있었다. 다만 공개된 목록은 402에 자체 의미를 부여하지 않았다. RFC 1945 §§6.1.1–6.1.2

1997년 1월의 HTTP/1.1 규격 RFC 2068은 402를 상태 코드 문법에 넣고 10.4.3절을 할당했다. 규칙은 한 문장이 전부였다. “This code is reserved for future use.” 이름은 결제라는 관문을 알렸지만, 표준 문장은 통과 절차를 적지 않았다. RFC 2068 §§6.1.2, 10.4.3

상태 코드는 응답의 종류를 가리킬 수 있다. 402의 정의에는 금액, 통화, 수취인, 결제 증명, 승인, 정산, 이의 제기 절차가 없다. 서버는 본문에 자체 조건을 설명할 수 있지만, HTTP는 그 조건을 여러 서비스와 클라이언트가 함께 쓰는 규칙으로 만들지 않았다.

401에는 인증 요청이 있고, 402에는 대기표만 있다

이웃 코드 401은 공통 동작이 어떻게 규격에 들어가는지 보여준다. RFC 9110은 401 응답에 적용 가능한 인증 챌린지를 하나 이상 담은 WWW-Authenticate 필드를 요구한다. 클라이언트는 방식을 읽고 어떤 자격 정보를 보낼지 판단할 수 있다. 15.5.3절의 402에는 그런 지시가 없다. 미래를 위해 예약됐다는 문장이 전부다. RFC 9110 §§15.5.2–15.5.3

빈자리는 애플리케이션이 메운다. 서비스가 자원을 결제 뒤에 두려면 청구액, 구매자의 결제 증명, 수취인, 증명 거부나 정산 실패 뒤의 처리를 정해야 한다. HTTP는 거절 표지를 제공한다. 계산대와 영수증, 오류 경로는 서비스가 구현한다.

미래는 판본마다 연장됐다

1999년 6월 RFC 2616은 10.4.3절에서 같은 문장을 되풀이했다. RFC 7231은 2014년에, RFC 9110은 2022년에 다시 그렇게 했다. 절 번호만 바뀌고 예약은 그대로였다. HTTP 의미를 새로 정리한 판본마다 결제 규칙이 없는 402도 다음 판본으로 넘어갔다. RFC 2616 §10.4.3 · RFC 7231 §6.5.2

RFC 문서에는 저자들이 염두에 둔 결제 체계가 나오지 않는다. 그 체계를 특정하는 당시의 설계 기록이 발견되면 이 역사는 달라질 수 있다. 공개된 규격에서 확인되는 것은 코드 이름과 예약 결정이며, 빈칸의 기원은 아니다.

이 글을 위해 확인한 IANA 등록부는 2025년 9월 15일 갱신본이며, 402를 여전히 ‘Payment Required’로 기록하고 RFC 9110 15.5.3절을 참조한다. IANA HTTP 상태 코드 등록부

통합 비용은 개발자에게 돌아온다

여기서 개발자 인터페이스의 경제성이 드러난다. 공통 프로토콜은 각 팀이 같은 거래 절차를 별도 문서로 다시 합의하는 수고를 줄일 수 있다. HTTP의 402는 그 비용을 줄이지 못한다. 구매자 클라이언트와 서버는 애플리케이션 층에서 가격, 증명, 자격 정보, 재시도, 결제 완료 조건을 합의해야 한다. 개발팀은 통합과 유지보수를 맡고, 각 서비스는 자기 조건에 대한 통제권을 유지한다.

402는 결제 인터페이스가 아니라 상태의 이름이다. 서버가 접근과 결제를 연결했다는 사실은 알리지만, 클라이언트에게 공통 이행 방법을 주지는 않는다. HTTP의 계산대는 표준 번호를 붙인 서비스별 규칙으로 남아 있다.

출처