요약

  • 과거 AUTH48이라 불렸던 RFC 파이널 리뷰(Final Review)는 출판 스트림이 인터넷 초안(Internet-Draft)을 승인한 뒤에 시작됩니다. 저자는 편집 완료된 전체 내용과 형식을 검토하고, 질문을 해소하며, 출판을 승인합니다. 이 검증은 실질적이지만 새로운 IETF 투표가 아닙니다.
  • RFC 프로덕션 센터(RFC Production Center)는 문서가 대기열에 들어간 뒤 프로덕션 사본을 관리합니다. 편집상 수정은 이 관리 경로를 통해 처리될 수 있지만, 편집을 넘어서는 추가·삭제·기술적 변경은 원출판 스트림의 승인을 필요로 합니다.
  • 2025–2026년 kramdown-rfc 및 GitHub 파일럿은 이 경계를 평소보다 두드러지게 드러냅니다. 2026년 8월 27일 기준, RFC-to-be 10025에는 실시간 파이널 리뷰 페이지와 공개 리뷰 저장소가 존재했지만, RFC 정보 URL은 아직 게시된 기록을 반환하지 않았습니다.
  • 신뢰할 수 있는 파이널 리뷰 기록은 승인된 초안 개정판, 스트림 결정, RPC 편집 집합, 이슈 분류, 저자 및 스트림 승인, 최종 출력 해시, 출판 발표를 보존합니다. 구현과 배포는 별도의 증거 계층으로 남습니다.

두 번째 투표처럼 보인 풀 리퀘스트

가장 위험한 상태 판단 오류는 흔히 진짜 스크린샷에서 시작됩니다. 기술 리스크 팀이 RFC-to-be의 공개 저장소를 열어봅니다.RPC-edits브랜치, 열린 이슈, 리뷰 요청, 그리고 아직 최종 승인을 내지 않은 이름들이 보입니다. 한 분석가는 "초안이 여전히 편집 검토 중"이라고 기록합니다. 다른 분석가는 "저자들이 표준을 거부했다"고 기록합니다. 세 번째는 이 풀 리퀘스트를 두 번째 합의 라운드라고 부릅니다.

추가 증거 없이 뒷받침될 수 있는 것은 첫 번째 서술뿐입니다.

파이널 리뷰는 서로 다른 두 제도적 행위 사이의 관리 구간입니다. 그 전에 출판 스트림이 인터넷 초안의 출판을 승인합니다. 그 뒤에 RFC 프로덕션 센터가 정의된 출력 파일 집합을 게시하고 RFC를 발표합니다. 그 사이에서 편집자, 저자, 스트림 담당자는 프로덕션 사본의 충실도와 출판 준비 상태를 다룹니다.

이 중간 구간이 중요합니다. 알고리즘의 누락된 한 줄, 형식이 잘못된 ABNF 조각, 잘못된 IANA 지시, 참조 오류, 렌더링 결함은 RFC가 참조의 기록적 기준점이 된 뒤에는 수년간 남을 수 있습니다. 그러나 중요성이 관할권을 지우지는 않습니다. 최종 검증이 저자, 편집자, GitHub 참여자로 이루어진 새로운 입법부에 문서를 넘겨주는 것은 아닙니다.

바로 이것이 현재 실험의 거버넌스적 가치입니다. 저장소는 단순히 더 많은 활동을 노출하지 않습니다. 나중에 읽는 사람이 무엇이 승인되었는지, RPC가 어떤 편집을 제안했는지, 어떤 질문이 제기되었는지, 누가 답변을 요청받았는지, 편집을 넘어서는 변경에 어떤 승인이 필요한지 구분할 수 있게 합니다. 투명성은 모든 보이는 참여자를 권위자로 만드는 대신 경계를 보존할 때 비로소 유용해집니다.

승인은 대기열 이전에 일어난다

현재 RFC 출판 지침은 상태 대시보드에서 잃기 쉬운 사실로 시작합니다: 출판 절차는 RFC 스트림 중 하나가 인터넷 초안을 승인할 때 시작됩니다. IETF, IAB, IRTF, Independent, Editorial 스트림은 각자 고유한 승인 경로를 가집니다. 문서는 관련 경로가 출판 결정을 내린 뒤에야 RFC 프로덕션 센터에 도달합니다.

이 선행 행위는 장식이 아닙니다. 어떤 내용이 승인되었는지, 어느 스트림이 소유하는지, 누가 실질적 변경을 허가할 수 있는지를 정의합니다. 문서가 출판 대기열에 들어가면 RPC가 프로덕션 사본에 대한 변경 관리를 맡습니다. 변경을 원하는 저자가 승인된 파일을 그냥 교체할 수는 없습니다. 변경은 RPC를 거치고, 기술적이거나 편집 범위를 넘어서는 경우 원 스트림으로 되돌아갑니다.

RFC 9920, 즉 현재 RFC 편집자 모델(RFC Editor Model)은 이 구분을 명시합니다. 스트림 승인 기구는 자기 스트림의 콘텐츠에 책임을 집니다. RFC 편집자 기능은 생산과 배포에 책임을 집니다. RPC는 문서를 편집하고, 편집과 대화의 기록을 보존하며, 기술적 영향이 있을 수 있는 변경을 식별하고, 명확화를 요청하고, 출판 준비 상태를 확정하고, 최종 산출물을 게시합니다.

이것은 "진짜 엔지니어"와 "단순 편집자"의 대결이 아닙니다. 두 통제는 모두 필요하며 어느 쪽도 다른 쪽을 흉내 내서는 안 됩니다. 스트림은 아이디어를 승인했다고 말하는 것만으로 신뢰할 수 있는 시리즈를 지킬 수 없습니다. RPC는 프로덕션 사본을 관리한다는 이유만으로 프로토콜을 재설계할 권한을 얻을 수 없습니다. 저자도 집단적 스트림 결정을 통과한 문서의 단독 소유권을 조용히 되찾을 수 없습니다.

따라서 방어 가능한 레지스터는 저자 체크리스트에 도달하기 전에승인된 원본과승인 스트림이라는 두 필드를 필요로 합니다. 이것들이 없으면 이후의 모든 편집은 책임 있는 기준선 없이 떠 있는 것처럼 보입니다.

저자가 실제로 승인하는 것

파이널 리뷰는 의례가 아닙니다. 같은 현재 지침은 저자에게 RPC의 질문을 해소하고, 공동저자가 제출한 변경을 검토하며, 전체 내용을 점검하고, 저작권 고지와 시맨틱 마크업을 확인하고, HTML·PDF·텍스트 출력을 살펴보라고 요구합니다. 이 절차는 여러 차례의 교환과 대체 문구를 필요로 할 수 있으며, 나열된 모든 저자가 최종 승인을 내릴 때 끝납니다.

현재 kramdown-rfc 지침은 파일럿 경로에서 이 책임을 두 번의 승인으로 나눕니다. 저자는 먼저 마크다운 콘텐츠가 RFCXML로 변환하기에 충분히 안정적임을 표시합니다. 이후 콘텐츠와 모든 최종 형식을 승인합니다. 두 번째 승인이 중요한 이유는 올바른 원본도 결함 있는 표현을 만들어낼 수 있기 때문입니다. 코드, 그림, 참조, 줄바꿈, 시맨틱 마크업이 변환을 거쳐 살아남아야 합니다.

따라서 저자 승인은 무결성 증명(attestation)으로 이해하는 것이 가장 적절합니다. 최종 프로덕션 산출물이 저자가 책임지는 작업을 충실히 표현하며 영구 출판이 될 준비가 되었다는 선언입니다. 한 저자의 선호가 이제 문서를 승인한 워킹 그룹, IESG 또는 다른 스트림 권위보다 우선한다는 뜻이 아닙니다.

연락 불가능한 저자 규칙은 이 구분이 의도된 것임을 보여줍니다. 현재 지침은 저자가 더 이상 행동할 수 없을 때 세 경로를 제시합니다: 그 사람을 감사의 말씀(Acknowledgements)으로 옮기거나, 기여자(Contributors)로 옮기거나, 스트림 관리자가 그 저자를 대신해 승인하는 것입니다. 이 선택은 기여를 보존하면서 생산 단계가 도달 불가능한 한 개의 메일함에 우연히 영구 거부권을 만들지 않도록 합니다.

이것이 부재한 승인을 사소한 것으로 만들지는 않습니다. 빠진 저자가 미묘한 편집 왜곡을 알아볼 수 있는 유일한 사람일 수 있습니다. 기록은 누가 연락 불가능한지, 어느 경로가 선택되었는지, 누가 허가했는지, 왜인지를 보여주어야 합니다. 오류는 그 미해결 질문을 정의되지 않은 권력으로 만드는 것이며, 명시된 에스컬레이션 경로를 사용하는 것이 아닙니다.

GitHub 머지가 넘을 수 없는 선

RPC는 2025년 9월 1일kramdown-rfc 파일럿을 시작했습니다. 명시된 목표에는 저자들이 점점 더 많이 쓰는 형식으로 문서를 검토하는 것과 콘텐츠 변경에 초점을 맞춘 더 깨끗한 diff를 만드는 것이 포함되었습니다. 초기 계획은 매월 최소 다섯 건의 요청을 수용하고, 더 넓은 사용 전에 절차를 다듬을 수 있게 했습니다.

2026년까지 공개 지침은 AUTH48을파이널 리뷰라고 부르게 되었습니다. 새 이름이 더 정확합니다. 48은 기한이 아니었고, "저자 검토"라는 말은 물려받은 대기열 코드보다 목적을 더 잘 설명합니다. GitHub 표면은 또한 관리를 구체적으로 만듭니다. 브랜치는 RPC 편집을 담고, 이슈는 질문을 보존하며, 풀 리퀘스트는 제안된 변경을 보여주고, 아카이브는 대화를 유지합니다.

RFC-to-be 10025의 저장소, 즉 HTTP 쿠키 명세의 개정판은 유용한 실시간 표본입니다. README는 초기 마크다운이 출판 승인 당시 인터넷 초안의 사본이라고 설명합니다. RPC 편집은 별도 브랜치에 있습니다. 저자는 콘텐츠와 형식을 승인합니다. 에어리어 디렉터(Area Director)는 편집을 넘어서는 변경을 승인합니다. 워킹 그룹 의장과 문서 셰퍼드는 리뷰 표면에 초대됩니다. 참여자가 필요로 하면 절차는 이메일로 되돌아갈 수 있습니다.

2026년 8월 27일 기준,파이널 리뷰 상태 페이지와 저장소는 살아 있었고, RFC 10025에 대한 RFC 편집자 정보 URL은 404를 반환했습니다. 검토 시점에 저장소에는 열다섯 개의 이슈와 하나의 풀 리퀘스트가 있었습니다. 이 수치는 열다섯 개의 기술적 결함, 열다섯 개의 반대, 열다섯 개의 막힌 결정을 의미하지 않습니다. 보이는 작업 표면에 이름이 붙은 리뷰 항목이 존재했다는 증거일 뿐입니다.

이 상태는 이 기사의 스냅샷 이후에 바뀔 수 있습니다. 그래야만 레지스터가 관측 시각과 권위 있는 URL을 저장해야 하는 이유입니다.In Final Review는 현재 상태입니다.Published as RFC 10025는 최종 기록이 존재할 때에만 별도의 사건이 됩니다.

RFC 9991과 에어리어 디렉터가 필요했던 키워드

추상적 규칙은 실제 변경이 그 선을 넘을 때 더 신뢰를 얻습니다.

RFC 9991이 된 문서의 파이널 리뷰 동안, 저자들은 BCP 14 키워드를 추가하자고 제안했습니다. 대문자로 쓰인 요구 사항 언어는 기술적 의미에 영향을 줄 수 있으며, 보통의 문장부호가 아닙니다.공개된 파이널 리뷰 교환에서 RPC는 담당 에어리어 디렉터에게 추가를 검토·승인해 달라고 요청했고, AD는 승인되었다고 답했습니다.

기록의 가치는 동사에 있습니다. 저자들은제안했습니다. RPC는 더 높은 권한이 필요한 변경을식별하고 검토를요청했습니다. 에어리어 디렉터가승인했습니다. RPC는 이후 RFC를게시했습니다. 그 어떤 동사도 다른 동사로 대체될 수 없습니다.

모니터링 시스템이 최종 텍스트만 기록한다면, 늦은 규범적 변경이 편집자에 의해 단순히 복사된 것인지, 저자들이 동의한 것인지, 스트림이 허가한 것인지 보여줄 수 없습니다. AD의 승인만 기록한다면, 승인된 문구가 어떤 최종 산출물에 들어갔는지 여전히 증명할 수 없습니다. RFC 번호만 기록한다면 관리 사슬 전체를 잃습니다.

이 사례는 RPC를 허위 비난에서도 보호합니다. 에스컬레이션은 편집자들이 입법을 시도했다는 증거가 아닙니다. 편집 권한의 한계를 인식하고 지정된 경로를 사용했다는 증거입니다.

48은 결코 기한이 아니었다

옛 이름은 또 다른 범주 오류를 부추겼습니다.AUTH48은 최종 저자 검토가 48시간 동안 지속된다는 약속처럼 보였습니다. 그렇지 않았습니다.

RFC 8963은 2018년에 생산된 RFC 표본에 대한 평가로, 편집 시간, AUTH48 시간, 최종 합의에서 출판까지의 구간을 분리했습니다. 이 표본에서 AUTH48은 평균 한 달 이상이었으며 편차가 컸습니다. 보고서는 이 단계를 이론상 최종 검증, 즉 저자가 편집된 문서를 승인하거나 마지막 수정을 요청하는 단계로 묘사했습니다. 저자 간·시간대 간 조율, 편집 논의, 경쟁하는 우선순위가 이를 길게 만들 수 있었습니다.

RFC 8700, 즉 RFC 시리즈의 역사는 AUTH48이 48일 또는 48주를 뜻한다는 오래된 농담을 기록합니다. 더 중요하게는 현재 경계의 배후에 있는 제도적 교훈을 기록합니다. 이 단계에서의 기술적 변경은 관련 에어리어 디렉터 또는 스트림 관리자의 승인을 필요로 합니다.

이 증거는 긴 모든 검토를 실패라고 부를 근거가 되지 않습니다. 복잡한 문서는 세밀한 검토를 받을 가치가 있을 수 있고, 연락 불가능한 저자는 대체 경로를 필요로 할 수 있으며, IANA 조치, 참조 의존성, 스트림 보류 또는 도구 문제가 실제 제약일 수 있습니다. 기간은 질문을 던지는 지표이지, 그것에 답하는 판정이 아닙니다.

파이널 리뷰로의 이름 변경은 오해를 부르는 시계를 라벨에서 제거합니다. 그렇다고 똑같이 오해를 부르는 정치적 은유를 초대해서는 안 됩니다. 이 단계는 이틀짜리 타이머도, 두 번째 선거도 아닙니다. 통제된 최종 마무리입니다.

파이널 리뷰 영수증

유용한 실사 기록은 색깔 배지에 권위를 읽어들이지 않고 완전한 인수인계를 재구성할 수 있어야 합니다.

필드보존할 증거중요한 이유
승인된 원본정확한 인터넷 초안 이름, 개정판, 바이트 및 해시스트림이 수용한 콘텐츠 기준선을 정의
스트림 결정스트림, 승인 기구, 날짜 및 결정 URL출판을 승인할 권한이 누구에게 있었는지 식별
대기열 인수인계RPC 접수 시각 및 현재 상태승인과 생산 관리를 분리
편집 집합RPC 브랜치, diff 또는 편집 집합 해시승인 이후 무엇이 바뀌었는지 보여줌
리뷰 항목질문, 행위자, 응답 및 아카이브 URL불확실성과 해결을 귀속 가능하게 만듦
변경 분류편집, 형식, 기술 또는 그 외 편집을 넘어서는 변경스트림 승인이 필요한지 결정
저자 승인신원, 범위 및 타임스탬프최종 콘텐츠와 출력에 대한 검토를 증명
스트림 승인실질적 변경에 대한 AD 또는 다른 스트림 관리자 접수생산 관리가 콘텐츠 권위로 변하는 것을 방지
외부 보류IANA, 참조 클러스터, 스트림 또는 도구 상태다른 의존성 때문에 저자를 탓하는 일을 방지
최종 산출물HTML, PDF, TXT, XML 해시승인을 독자가 받게 될 것에 결합
출판발표, RFC URL 및 출판 시각RFC-to-be가 RFC가 되었음을 증명
도입구현, 테스트 및 배포 증거문서적 권위와 실행 현실을 분리

이 영수증은 편집 판단을 기계로 축소하지 않습니다. 각 판단이 그것을 행사한 역할에 책임을 지도록 만듭니다. 검토자는 무엇이 열려 있는지 정확히 말할 수 있습니다. 한 저자가 출력을 승인하지 않았거나, RPC 질문이 답변을 기다리거나, AD가 기술적 추가를 승인해야 하거나, IANA 조치가 미완료이거나, 최종 출판 발표가 아직 없다는 식으로요.

이 언어는 "거부권"이나 "두 번째 투표"보다 덜 극적입니다. 그러나 명세를 인용, 구현, 구매 또는 의존할 수 있는지 판단하는 사람에게 훨씬 더 유용합니다.

출처

RFC 10025 관측은 2026년 8월 27일로 고정됩니다. 이슈 수는 결함 수로 취급되지 않으며, 출판 날짜나 결과도 예측하지 않습니다.