요약

  • 2025년 3월의 RFC 9745는 Structured Fields 날짜를 담는 Deprecation 응답 필드를 정의했다. 사용 중단 대상으로 알린 뒤에도 자원의 동작은 그대로일 수 있다.
  • deprecation이라는 Link 관계는 정책이나 이전 설명서로 연결하며 날짜 필드보다 먼저 나타날 수 있다. 2019년 RFC 8594의 Sunset은 응답이 끊길 것으로 예상되는 별도 시점이다.
  • 공지는 먼저 해당 응답의 자원에 적용된다. API 전체로 넓히려면 제공자가 범위 규칙을 밝혀야 한다.

성공한 응답에 붙은 퇴장 알림

서비스가 끝나기 전까지는 모든 것이 정상일 수 있다. 요청은 성공하고 가동률 지표도 녹색이다. 그러나 운영자는 새 경로를 만들고 다음 고객에게 옛 자원을 선택하지 말라고 안내하려 한다. 안내가 사람용 문서에만 있으면 실제 통신을 살피는 개발자가 놓칠 수 있다. 첫 실패와 함께 도착한 안내라면 고객에게 시험과 배포를 준비할 시간은 없다.

RFC 9745는 그 알림을 HTTP 응답 자체에 넣었다. Deprecation은 그 응답이 가리키는 자원이 사용 중단 단계에 들어갈 날짜 또는 이미 들어간 날짜를 말한다. 값은 Structured Fields의 Date 형식이다. 규격의 Deprecation: @1688169599는 2023년 6월 30일 23시 59분 59초 UTC다. 미래의 값은 앞으로 시작할 시점, 과거의 값은 이미 시작한 시점을 가리킨다.

이 필드가 실린 자원은 기존처럼 동작할 수 있다. RFC는 사용 중단 예고 자체가 자원 동작을 바꾸지 않는다고 적었다. 같은 응답이 지금의 성공과 장래의 이전 요청을 함께 전달한다. 고객은 현재 데이터를 받으면서도 새 기능을 이 경로에 얹을지 다시 계산해야 한다. 오늘의 가동 상태와 내일의 투자 가치는 다른 질문이다.

적용 범위도 확인해야 한다. 필드는 기본적으로 그 응답의 자원에 관한 말이다. 운영자가 API 전체나 여러 경로를 함께 정리하려면, 한 자원의 공지가 다른 곳까지 어떻게 미치는지 규칙을 밝혀야 한다. 한 번의 응답만 보고 모든 엔드포인트가 같은 날짜에 끝난다고 추측할 근거는 없다.

설명서가 시계보다 먼저 올 수 있다

RFC 9745는 Link의 deprecation 관계도 등록했다. 서버는 이 관계로 정책, 대체 경로, 이전 절차를 설명하는 문서에 연결할 수 있다. 링크는 날짜가 붙은 Deprecation보다 먼저 나타나도 된다. 그 단계에서 자원은 아직 사용 중단 상태가 아니지만, 고객은 운영자가 앞으로 어떤 방식으로 알릴지 볼 수 있다.

날짜 하나로 권한, 데이터 형식, 시험 절차가 옮겨지지는 않는다. 클라이언트 팀은 대체 자원의 실제 기능을 확인하고 제품을 다시 배포해야 한다. 실행 중인 응답에서 문서에 도달할 수 있으면 그 작업을 계획하기 쉽다. 그러나 문서의 질과 대체 경로의 준비 상태는 제공자가 책임진다. 표준화된 공지가 이전 비용을 대신 지불해 주지는 않는다.

낡아지는 날과 멈출 날

2019년 5월의 RFC 8594는 Sunset을 정의해 자원이 응답하지 않게 될 것으로 예상되는 시간을 HTTP 날짜로 전한다. Deprecation은 아직 돌아가는 자원을 새 의존의 기반으로 삼지 말라는 시점이다. 두 날짜는 서로 다른 결정을 돕는다. 새로운 결합을 멈출 때와 실제 응답이 사라질 것으로 보는 때는 같을 필요가 없다.

2025년 규격은 두 필드를 함께 사용할 수 있게 하면서 Sunset이 Deprecation보다 앞서서는 안 된다고 정했다. 예시는 2023년 6월 30일에 사용 중단 단계를 시작하고, 2024년 6월 30일을 예상 종료일로 둔다. 순서를 뒤집으면 떠나라는 공지보다 먼저 문을 닫겠다는 일정이 된다. 표기법도 다르다. Deprecation은 @가 붙은 구조화 날짜, Sunset은 전통적인 HTTP 날짜를 쓴다.

특정 서비스가 이 새 필드를 언제 썼는지는 날짜가 남은 실제 응답을 확인해야 한다. RFC는 설계의 출발점을 기록한다. 작동하는 자원이 자신의 응답으로 퇴장을 알리고, 고객에게 아직 열려 있는 이전 시간을 줄 수 있게 됐다.