요약

  • RFC Production Center는 저자가 선택할 수 있는 GitHub 기반 최종 검토를 시험하고 있다. 2026년 9월 30일 보낸 공식 보고서에는 참여에 동의한 저자의 문서 31건이 대기 중이며 월별 수용 한도는 5건이라고 적혀 있다. 현재 대기 수나 개별 문서의 대기 기간을 뜻하는 숫자는 아니다.
  • 공식 로드맵은 제안된 편집을 pull request로 검토하고 문제를 해결해 병합한 뒤, 저자의 최종 승인을 이메일로 받고, 승인된 원본을 센터의 파일 시스템에 복사해 출판한다고 설명한다. 공개 문서는 이 세 기록을 관통하는 단일 판본 식별자를 명시하지 않는다.

마지막 쉼표에도 주인이 있다

RFC가 출판을 앞두면 편집자는 표현과 형식을 손보고 저자는 최종 문서가 자신이 승인한 내용인지 확인한다. RFC Production Center의 10월 보고서는 이 검토에 GitHub를 쓰는 선택형 시험을 소개한다. 보고서는 9월 30일에 발송됐다. 기존 이메일 방식의 최종 검토도 계속 제공된다.

센터의 GitHub 로드맵에 따르면 먼저 수용된 문서의 원본을 approved 브랜치에 놓는다. 편집자가 제안한 수정은 별도 브랜치와 pull request에 올라간다. 저자는 바뀐 줄을 보고 해당 자리에서 질문할 수 있다. 쟁점이 풀리면 수정 사항을 병합한다. 여기서 끝이 아니다. 저자는 완성 문서에 대한 최종 승인을 이메일로 보내며, 센터는 최종 원본을 자기 파일 시스템으로 복사해 출판 절차를 밟는다.

이 순서는 권한을 분리한다. PR의 병합은 편집안의 처리 기록이다. 이메일은 저자가 어떤 최종 문서에 동의했는지를 남긴다. 복사된 파일은 독자가 결국 읽을 자료의 출발점이다. 셋이 같은 판본을 가리키면 한 문장의 수정 이유부터 저자의 승인까지 거슬러 올라갈 수 있다. 공개된 로드맵에는 세 단계에 공통으로 기록되는 해시나 불변 개정 번호가 적혀 있지 않다. 그 빠진 설명만으로 실제 RFC에 잘못된 문장이 실렸다고 말할 수는 없다. 다만 검증할 때 무엇을 맞춰 봐야 하는지는 선명하다.

월 다섯 자리와 신청한 서른한 건

센터는 GitHub 최종 검토 시험에 월 5건만 받아들이기로 했다. 9월 30일 보고서에는 대기 중인 31개 문서의 저자가 참여에 동의했고, 10월에는 5건을 받을 수 있다고 나온다. 이는 특정 날짜의 참여 의사와 시험 수용 능력이다. 10월 28일의 대기 건수를 보여 주지 않으며, 31을 5로 나눠 문서별 대기 개월 수를 낼 근거도 없다. 접수 순서, 추가 유입, 완료 수가 공개되지 않았기 때문이다.

같은 보고서에는 23건과 월 5건이라는 다른 숫자도 있다. 이는 원본 형식인 kramdown-rfc를 다루는 별도의 시험이다. GitHub 최종 검토 시험의 31건에 23건을 더하면 문서가 두 시험에 모두 속하는지 알 수 없어 허구의 합계가 된다. 전자는 검토 방법의 문제, 후자는 입력 형식의 문제다. 숫자를 섞으면 각 시험이 무엇을 배웠는지도 흐려진다.

월 5건은 절차를 천천히 고칠 수 있는 규모다. 그러나 성공을 PR 개수로 셀 수는 없다. 다음 보고서에서 참여 동의, 실제 시험 편입, 저자 검토 완료, 최종 출판을 각각 세면 병목 위치가 보인다. 입구에 선 사람 수만으로 작업장의 흐름을 판단할 수 없다.

변환 뒤에 한 번 더 열리는 PR

로드맵은 kramdown-rfc 원본을 RFCXML로 바꾼 뒤 별도의 pull request를 열어 형식 차이를 검토하도록 한다. 첫 PR에서 글의 수정 사항을 승인받았더라도, 변환된 최종 형태를 저자가 다시 확인할 이유가 있다. 문장 자체와 문서 구조가 서로 다른 단계에서 바뀔 수 있기 때문이다. 출판 파일을 가리키는 판본 기록에는 이 두 번째 비교도 들어가야 한다.

저자가 센터의 편집 제안과 무관한 변경을 원할 때는 별도의 PR을 내도록 되어 있다. 경우에 따라 해당 문서 흐름의 관리자에게 이메일 승인을 받아야 할 수도 있다. 표현을 다듬는 과정에 새 기술 결정을 몰래 끼워 넣지 않으려는 경계다. 누가 어떤 내용을 바꿀 권한이 있는지 알려면 변경 요청의 출처와 승인된 판본이 함께 남아야 한다.

로드맵의 뒷부분에는 비공개 내부 저장소와 추가 출판 절차가 계획돼 있다. 저자 승인과 IANA 관련 조치는 GitHub 자동 동작보다 Purple이라는 제작 관리 도구에서 처리하는 것으로 서술된다. 저자의 직접적인 GitHub 협업은 미래 단계의 할 일로 남아 있다. 계획된 단계 전체가 현재 가동 중이라는 증거는 아니다. 지금 확인되는 운영 사실은 선택형 시험과 그 월별 수용 한도다.