요약

  • 2026년 7월 1일에 게시된draft-ietf-procon-2026bis-11은 8월 27일 기준으로도 워킹 그룹 라스트콜(WG Last Call) 단계에 머물러 있었다. 이 초안은 RFC 2026의 예외(variance) 아키텍처를 계승하지만, BCP 9를 대체하는 승인된 문서가 아니라 아직 통합 초안이다.
  • 책임 있는 워킹 그룹, 또는 담당 그룹이 없는 경우 임시 위원회가, 절차적 지침의 공백이나 교착 상태에 직면한 한 가지 명세에 대한 예외를 권고할 수 있다. 그 권고는 검토를 개시할 뿐, 예외 자체를 부여하지는 않는다.
  • IESG는 기술적 타당성, 통상 절차, 대안, 비용, 부수 효과, 선례 효과, 그리고 가능한 한 가장 좁은 범위를 함께 검토해야 한다. 제안은 별도의 인터넷 초안(Internet-Draft)이 되어 최소 4주의 연장 라스트콜을 받고, 승인되면 BCP로서 출판을 위해 보내진다. 상소 경로도 계속 열려 있다.
  • 명시된 지연 기간, 개방성, 공정성, 합의, 회의 및 메일링 리스트 기록 보존, 그리고 몇 가지 핵심 절차 장치는 면제할 수 없다. 따라서 정당한 예외는 한 명세에 묶인 버전 관리된 영수증이지, 무언의 일반 개정도, 자동 상속되는 선례도, 배포 명령도 아니다.

근거가 사라진 뒤에도 남는 행

정책 대장은 하나의 답을 선호한다. 요구사항은 필수이거나 선택이다. 문서는 통과했거나 실패했다. 게이트는 열려 있거나 닫혀 있다. 예외는 이런 편의성에 저항하는데, 두 명제가 동시에 참이어야 하기 때문이다. 즉, 요구사항은 통상 사례를 계속 지배하며, 이름이 지정된 한 명세는 통상적 방식으로 그 요구를 충족하지 않았음에도 진행이 허용되었다.

이 두 명제를 하나의 필드로 압축하는 순간, 예외는 스스로 입법을 시작한다. 관리자가 요구사항을waived로 표시한다. 템플릿이 그 값을 복사한다. 이후 다른 명세가 같은 워크플로우에 들어와 이미 비활성화된 요구사항을 발견한다. 그 이후 텍스트에 대해 책임 있는 워킹 그룹의 예외 권고는 없었다. 대안은 검토되지 않았고, 연장 라스트콜은 부수 효과를 드러내지 않았으며, 그것에 귀속되는 IESG 결정은 존재하지 않는다. 그런데도 운영 시스템은 일반 규칙이 변경된 것처럼 동작한다.

사람의 기억도 같은 실수를 한다. 어려운 결정이 익숙한 관행이 되고, 관행이 선례가 되며, 선례는 조건을 잃고 다시 전해지고, 줄인 이야기가 체크리스트에 들어간다. 형식적인 BCP는 그대로 있지만 조직의 작업 모델은 이제 다른 규칙을 적용한다. 이것이 데이터 소실을 통한 거버넌스 드리프트다.

올바른 모델은 두 개의 객체를 유지한다. 일반 절차 규칙은 자체적으로 텍스트, 버전, 권한, 개정 경로를 갖는다. 예외 기록은 대상 명세와 개정판, 정확한 조항, 권고 기구, 분석, 협의 기간, 제약 조건, 결정 및 상소를 명시한다. 두 번째 객체는 이후 사례에 참고가 될 수 있다. 그러나 데이터베이스가 찾을 수 있다는 이유만으로 이후 사례를 결정해서는 안 된다.

선례를 이해하는 올바른 방식도 여기에 있다. RFC 2026은 IESG에게 제안된 예외의 선례 효과를 고려하도록 지시한다. 이 지시는 하나의 사례가 기대, 협상 지점, 미래 비용을 바꿀 수 있음을 인정한다. 그러나 다음 명세에 대해 자동 실행되는 허가를 만들지는 않는다. 선례 효과는 평가해야 할 리스크이지, 상속 함수가 아니다.

따라서 경계가 있는 예외는 절차적 안정성의 실패가 아니라, 안정성의 조건 중 하나다. 출구가 전혀 없는 규칙은 작성자가 예상하지 못한 사례 앞에서 부러질 수 있다. 사용될 때마다 기본값을 바꾸는 출구는 규칙을 파괴한다. 기록을 분리하면 판단과 경계를 모두 보존할 수 있다.

상태 라벨은 증거의 일부다

현재의 통합 작업은 상태를 함부로 요약해서는 안 되는 이유를 보여준다.Datatracker 문서 페이지는draft-ietf-procon-2026bis-11을 PROCON 워킹 그룹의 활성 인터넷 초안으로 표시한다. 이 페이지의Intended RFC status필드는None을 보여주는 반면, 초안 본문의 헤더는 의도된 상태로 Best Current Practice를 명시하고 있다. 이것은 두 개의 기록된 사실이며, 최종 상태 결정이 이미 이루어졌다는 증명이 아니다.

개정판-11은 2026년 7월 1일에 게시되었고, 갱신되거나 진전되지 않으면 2027년 1월 2일에 만료되도록 예정되어 있다.이력 기록에 따르면 문서가 개정판-08이던 5월 21일에 워킹 그룹 라스트콜에 들어갔다. 8월 27일 기준 워킹 그룹 상태는In WG Last Call로 남아 있었고, IESG 상태는I-D Exists로 텔레챗 날짜는 없었다. 이 사실들은 검토 중인 진지한 워킹 그룹 초안을 보여준다. 그러나 IESG 승인, RFC 출판, 또는 효력을 가진 후속 BCP를 보여주지는 않는다.

완성되고 승인되면 2026bis는 RFC 2026을 포함한 여러 절차 RFC를 통합하고 폐기(obsolete)하며, RFC 7475를 갱신하게 된다.PROCON 헌장은 유지보수 문제를 설명한다. 스무 개가 넘는 RFC가 RFC 2026과 RFC 2418이라는 두 기초 텍스트를 갱신해 왔고, 절차가 긴 사슬에 흩어져 있다. 이 워킹 그룹은 그 사슬과 검증된 정오표를 읽을 수 있는 후속 문서로 합치는 임무를 맡았다. 비편집적 변경의 추가 계열은 두 가지만 명시되어 있으며, 그 외의 실질적 추가는 헌장 재수정(rechartering)이 필요하다.

개정판-11의 제11장은 예외 아키텍처를 그대로 유지한다. 2026년에 새로운 권한을 발명한 것이 아니다. BCP 9의 일부인 공개된RFC 2026의 제9장은 1996년부터 이 핵심 구조를 담고 있었다. 새 초안은 통합, 재번호 매기기, 용어 현대화를 수행하며, 변경 로그는 예외를 새로운 정책 실험으로 제시하지 않는다.

따라서 신뢰할 수 있는 거버넌스 대장은 세 개의 상태를 서로 덮어쓰지 않고 함께 담아야 한다. RFC 2026은 현재 공개된 기준선이다.2026bis-11은 워킹 그룹 검토 중인 통합 초안이다. 승인되어 출판될 미래의 후속 RFC는 그 귀속 가능한 출판 이벤트에서 기준선을 바꾼다. 초안은 방향을 보여줄 수 있다. 그러나 그 여정이 이미 끝났다는 증거로 사용될 수는 없다.

권고, 검토, 결정은 서로 다른 주체에 속한다

예외 절차는 명세 가까이에서 시작하지만 거기서 끝나지 않는다. 명세를 담당하는 워킹 그룹이 예외를 권고할 수 있다. 담당 워킹 그룹이 없다면 임시 위원회가 권고할 수 있다. 이 출발점이 중요하다. 기술 문제를 가장 잘 아는 기구가 교착 상태 또는 절차가 지침을 제공하지 못하는 지점을 설명해야 하기 때문이다.

근접성이 권고를 승인으로 바꾸지는 않는다. 워킹 그룹은 라벨을 바꾸는 것으로 자신의 어려움을 승인된 출구로 전환할 수 없다. 그 권고는 문제를 IESG로 보낸다. IESG는 그때 인터넷 커뮤니티에 기대되는 이익이 절차 요구를 준수하지 않는 비용을 초과하는지 검토한다.

요구되는 검토는 명세가 기술적으로 좋은지를 넘어선다. 여기에는 기술적 타당성, 예외 없이 통상 절차의 목표를 여전히 달성할 수 있는지, 다른 대안들, 각 경로의 비용, 부수적 결과, 선례 효과, 더 좁은 예외로 가능한지가 포함된다. IESG는 일부 조항에만 완화를 부여할 수 있고 제약을 추가할 수도 있다.

이 아키텍처는 여러 지름길을 차단한다. 수년간의 유용한 엔지니어링이 통상 검토가 불가능해졌음을 증명하지 않는다. 단기 마일스톤만으로 덜 공개적인 검토가 정당화되지 않는다. 강한 워킹 그룹 지지가 모든 외부 효과를 식별해 주지 않는다. 표면적으로 유사한 과거 사례가 새 사례의 입증 부담을 소멸시키지 않는다. 기술적 품질은 관련이 있지만 절차 분석의 대체물이 아니다.

권한은 모든 단계에서 경계를 유지한다. 권고는 워킹 그룹의 것이고, 평가와 결정은 IESG의 것이며, 논거는 참여자들의 것이다. 이후 상소에는 그 자체의 신청자, 질문, 결과가 있다. 이 역할들은예외 승인됨이라는 단일 상태로부터 정확히 재구성될 수 없다.

이 구분은 인터넷 거버넌스 전반의 원칙을 반영한다. 참여는 지식과 증거를 제공하지만 권한을 자동으로 만들지는 않는다. 투표나 대략적 합의는 그 기구의 실제 권한 범위 안에서만 승인한다. 기술적 결정의 신뢰성은 회의실의 크기가 아니라 역량과 절제에서 나온다. 예외는 이 권한 범위를 넓히지 않는다. 오히려 그 경계를 더 중요하게 만든다.

공개성은 증거 연쇄다

예외적 결정은 발표하기 쉽고 감사하기 어렵다. RFC 2026은 기록을 일련의 공개적 행위에 분산 배치하여 이 간극을 줄인다.

제안된 예외는 지각된 문제를 기술하고, 어려움을 만드는 정확한 조항을 특정하고, IESG의 검토를 제시해야 한다. 그것은 인터넷 초안으로 발행되어 제안에 공개 식별자, 본문, 버전 이력을 부여한다. IESG는 이어서 최소 4주의 연장 라스트콜을 공표한다. 그 기간이 지나면 최종 판단을 내리고 그 결과를 IETF에 알린다. 승인되면 예외는 BCP로서 출판을 위해 보내진다. 상소 절차도 계속 적용된다.

각 단계는 서로 다른 것을 증명한다. 워킹 그룹 권고는 누가, 어떤 명세에 대해 검토를 요청했는지 보여준다. 인터넷 초안은 제안된 내용을 고정한다. 라스트콜은 최소한의 공개 검토 기간이 존재했음을 증명하며, 침묵을 동의로 증명하지는 않는다. IESG 발표는 결정을 귀속시킨다. 출판은 승인된 사례를 안정화한다. 상소가 제기되면 그 자체의 주장, 검토자, 결과를 담은 또 하나의 기록이 만들어진다.

4주 최소 기간은 의례적인 대기가 아니다. 즉시 작성 서클 바깥의 사람들이 정확한 예외 지점을 검사하고, 대안을 시험하고, 파급 효과를 식별할 기회를 준다. 예외가 긴급해 보일수록, 그 긴급성 주장 자체에 대한 검토를 제거하는 장치로 긴급성이 쓰이지 않는 것이 더욱 중요하다.

RFC 7282는 대략적 합의에 관한 유용한 경고를 더한다. 지지 메시지의 수가 결정적 사실은 아니다. 반대의 실질과 그것이 어떻게 처리되었는지가 중요하다. 열 개의 짧은 찬성이 하나의 구조적 반대에 자동으로 답이 되지 않으며, 하나의 반대가 자동적 거부권이 되지도 않는다. 예외 영수증은 메시지 수만이 아니라 논거와 그 처리 결과를 보존해야 한다.

이 공개 사슬은 의도적으로 비용이 크다. 예외 경로가 통상 경로보다 저렴하다면, 그것은 병렬적인 또 하나의 정상 절차가 되어 버린다. 버전 관리된 텍스트, 긴 검토 기간, 명시된 이유, 최종 발표, 상소 가능성은 신청자가 출구가 왜 필요한지, 그리고 왜 자신이 말하는 지점에서 멈추는지를 둘 다 보여주도록 만든다.

예외가 제거할 수 없는 바닥선

예외 메커니즘의 가장 강한 부분은 그것이 제공하는 재량이 아니다. 그 재량이 넘을 수 없는 바닥선이다.

RFC 2026에 따르면, 예외는 절차가 명시적으로 규정한 지연 기간을 줄일 수 없다. 개방성, 공정성, 합의를 면제할 수 없다. 회의와 메일링 리스트 논의의 적정한 기록을 유지할 의무를 제거할 수 없다. 또한 BCP 검토, 조치 개시, IESG 검토, 출판, 갈등 해결, 상소, 그리고 예외 메커니즘 자체를 다루는 명명된 핵심 조항들을 보호한다.2026bis-11은 이 보호되는 바닥선을 재번호 매겨진 구조로 그대로 옮긴다.

그 논리는 실용적이다. 예외 자체를 평가하는 데 필요한 공개성, 기록 보존, 검토를 예외가 면제할 수 있다면, 그것은 제도적 리스크가 가장 큰 지점에서 증거를 파괴한다. 조직은 여전히 형식적인 예외 절차를 사용했다고 주장할 수 있지만, 외부인은 더 이상 경계된 판단과 불투명한 권력 행사를 구분할 수 없다.

바닥선은 합의를 보장하지 않는다. IESG의 판단을 빼앗지도 않고, 모든 참여자를 거부권을 가진 주체로 만들지도 않는다. 그것은 더 좁고 더 유용한 것을 약속한다. 판단의 행사가 보이고, 귀속 가능하고, 기록되고, 도전 가능할 것이며, 예외가 그 점검 수단을 지울 수 없다는 것이다.

따라서 현재 초안의 배제 규정은 무대 설정 문구가 아니라 실행 가능한 요구사항으로 다루어져야 한다. 워크플로우는 라스트콜이 요구되는 최소 기간보다 짧거나, 대상 조항이 명시되지 않았거나, 기록에 책임 있는 권고가 빠져 있거나, 제안이 보호되는 요소 중 하나를 면제하려 든다면 예외를 최종 확정하기를 거부해야 한다. 대응하는 상태 검사가 없는 산문적 약속은 예외 자체와 같은 무언의 드리프트에 취약하다.

예외 영수증

유용한 예외 기록은 범위를 잃지 않고 복제, 색인, 이후 인용을 견뎌야 한다. 그러려면 제목과 결과 이상의 것이 필요하다.

식별 계층은 예외 식별자와 버전, 대상 명세의 이름·개정판·콘텐츠 해시, 책임 있는 워킹 그룹 또는 임시 위원회, 권고 본문과 날짜, 그리고 쟁점이 되는 정확한 BCP 조항을 기록해야 한다. 문제가 교착 상태인지 지침 공백인지를 구분하고, 충족되지 않은 요구사항을 명시하며, 통상 경로로 해결할 수 없는 이유를 설명해야 한다.

추론 계층은 기술적 타당성 평가, 기대 이익과 비용, 검토되고 기각된 대안들, 부수적 결과, 선례 효과, 선택된 범위, 추가 제약을 보존해야 한다. 기각된 대안 없이는, 이후 읽는 사람이 그 예외가 필요했는지 아니면 단지 편리했는지 판단할 수 없다.

공개 절차 계층은 예외 인터넷 초안의 식별자와 해시, 라스트콜의 시작과 끝, 중대한 반대와 그 처리 결과를 포함해야 한다. 결정 계층은 IESG의 판단과 발표, 승인된 경우의 출판된 BCP 식별, 상소 상태와 결정, 한 사례 경계, 종료 조건을 기록해야 한다.

두 가지 부정 진술이 영수증과 함께 다녀야 한다. 첫째, 이것은 다른 명세를 승인하지 않는다. 둘째, 어떤 사업자, 벤더, 공공 기관, 오픈소스 프로젝트가 그 기술을 채택하거나 배포했다는 것을 증명하지 않는다.

그렇지 않으면 BCP로서의 출판이 혼란을 일으킬 수 있다. 출판 형식은 승인된 예외를 안정적이고 공개적이며 인용 가능하게 만든다. 그러나 그 실질을 지정된 명세에서 재사용 가능한 일반 규칙으로 확대하지는 않는다. 일반 절차의 영구 개정은 통상의 BCP 절차를 따른다. 승인된 사례는 BCP 형태의 영수증이지, 절차 BCP의 은밀한 대체물이 아니다.

영수증은 정직한 개혁의 가능성도 보존한다. 실제로 비견 가능한 여러 예외가 누적된다면, 그 패턴은 일반 규칙이 개정될 필요가 있다는 증거가 될 수 있다. 그 결론에는 기록들의 분리가 필요하다. 모든 예외가 이미 기본값을 바꾸어 버렸다면, 조직은 규칙과 규칙을 바꿔야 하는지 판단할 증거를 모두 잃는다.

IETF 절차 상태는 네트워크 채택이 아니다

예외는 한 명세가 IETF 표준 절차에 진입하거나 진전되는 방식을 다룬다. 사업자, 기업, 공공 기관, 소프트웨어 프로젝트, 사용자를 위한 배포 결정을 내리지 않는다.

RFC 9281은 표준화 작업에서 워킹 그룹, IESG, 기타 참여자의 역할을 기술한다. 이 역할들은 외부 행위자에게 예외로부터 새로운 문서 상태를 추론할 권한을 주지 않는다. 반대 방향으로RFC 3935는 IETF 표준이 어떤 당사자가 준수를 주장할 때 어떻게 무언가를 하는지를 규정하며, IETF는 보편적 사용을 강제하거나 감시하려 하지 않는다고 설명한다.

따라서 내부 절차 영수증과 외부 채택 영수증은 분리되어야 한다. 배포 기록에는 자체적인 명명된 결정자, 구현된 버전, 테스트 증거, 배포 범위, 날짜, 대체 조건, 운영 결과가 필요하다. 예외는 이후의 그 판단에 참고가 될 수 있다. 판단을 내리거나, 판단이 이루어졌음을 증명할 수는 없다.

Lu Heng의최소 초기 명세, 지역화된 미래 결정, 자발적 채택프레임워크는 호환되는 거버넌스 관점을 제공한다. 공통 조정은 최소 공유 경계를 명시하고, 이후 행위자들은 자신의 지역적 결정과 증거의 소유권을 유지한다. 이 프레임워크는 여기서 권한을 해석하는 데 사용되며, IETF의 절차적 출처를 대체하지 않는다.

이 구분은 위임 세탁을 막는다. 절차적 예외를 기술적 승인으로 기술하면 IETF의 판단을 과장하게 된다. 배포 요구사항으로 기술하면 IETF가 주장하지 않는 권한을 발명하게 된다. 하류 구현을 예외의 정당성 증명으로 기술하면 증거 연쇄를 뒤집는다. 동작하는 코드는 기술적 현실을 시험할 수 있다. 그러나 결여된 권고, 검토 기간, 결정을 소급하여 채워 넣을 수는 없다.

출처