요약

  • 2026년 8월 6일, IETF Tools Team은 유지보수자가 제출된 모든 줄을 계속 읽는다면 대규모 AI 지원 풀 리퀘스트가 팀의 처리 역량을 소진시킬 수 있다고 경고했습니다. 기여 요건, 기여자 신뢰, 그리고 저영향 코드를 위한 축소 리뷰 경로 가능성을 논의했지만, 그 모델은 아직 논의 중이라고 밝혔습니다.
  • 8월 25일 병합된 조직 전체 가이드는 보수적인 선택을 했습니다. 모든 기여는 여전히 큐에 들어가 한 명 이상의 유지보수자가 제출된 코드의 모든 줄을 읽으며, AI 생성 코드도 설명, 리뷰 가능한 커밋, 테스트, 의존성, 정책 적합성에 관한 동일한 요건을 충족해야 합니다.
  • 가이드는 거짓된 저작 표시 없이 인간의 지속적 책임을 부과합니다. AI 기여의 배후 인물은 그 코드의 목적과 적합성을 이해하고, 사람이 읽을 수 있는 설명을 이해하며, 이후 발생하는 문제의 수정에 헌신해야 합니다.
  • IETF Tools가 나중에 영향 등급별로 인간 리뷰를 축소한다면, 분류자, 영향받는 시스템, 근거, 실제 리뷰 깊이, 기계의 역할, 병합 권한, 유지보수 책임자, 에스컬레이션 및 롤백 조건을 밝히는 리뷰 경계 영수증을 공개해야 합니다.

경고 속에서 살아남은 규칙

IETF Tools Team의 8월 소식에서 가장 영향력 큰 문장은 방어 수단이 취약점이 되는 상황을 묘사합니다.

Team은 대부분의 시스템에 대해 대규모이고 야심찬 풀 리퀘스트가 AI 지원과 함께 도래할 것으로 예상했습니다. 확립된 관행은 제출된 모든 줄을 읽는 것이었습니다. 기여의 물량과 규모가 충분히 빠르게 증가하면, 그 관행이 리뷰어 자신들에 대한 서비스 거부 공격이 될 수 있다고 소식은 말했습니다.

이것은 공격에 대한 보고가 아닙니다. 악의적 기여가 서비스를 마비시켰다거나, AI 패치가 IETF 데이터를 훼손했다거나, 유지보수자들이 이미 코드 읽기를 중단했다는 말도 없습니다.8월 6일 Tools 소식이 확인하는 것은 역량 비대칭입니다. 기여자에게는 생성이 저렴할 수 있지만, 결과를 운영하고 유지보수하게 될 기관에게는 안전한 흡수가 여전히 비용이 크다는 것입니다.

3주 후, 공개 규칙은 사라지지 않았습니다.

8월 25일 커밋에 고정된 기여 가이드는 모든 IETF Tools 기여가 한 명 이상의 유지보수자가 제출된 코드의 모든 줄을 읽는 큐에 들어간다고 명시합니다. 이 규칙은 모든 기여에 적용됩니다. AI 생성 코드는 별도 경로에 놓이지도, 금지되지도 않으며, 동일한 기여 요건을 충족하면 수용됩니다.

커밋 기록은 변경일을 8월 25일로 표기하고, 추가된 내용을 Tools 리트리트에서 합의된 요건으로 설명합니다. 본 아티클의 근거 기준 시점에main브랜치의 조직 전체 가이드는 그 고정 버전과 동일한 바이트였습니다. 따라서 현재 확인된 상태는 전 라인 리뷰 약속을 그대로 보존합니다.

9월 1일 사무총장 보고서는 마지막 사실 공백 하나를 메웁니다. 가이드라인이 갱신되어 Team이 대부분의 시간을 리뷰에 소비하지 않고도 대규모 및 AI 생성 기여를 검토하고 안전하게 통합할 수 있게 되었다고 합니다. 그러나 제안된 저리뷰 등급이 채택되었다고는 말하지 않습니다. 공개 기록을 함께 읽으면 문제, 논의, 그리고 첫 실현된 대응이 보입니다. 인간 리뷰가 기계 리뷰로 조용히 대체되었다는 증거는 없습니다.

이 순서가 중요합니다. 거버넌스 오류는 흔히 제안된 통제가 이미 정책인 것처럼 서술되거나, 갱신된 정책이 정확한 텍스트 수준이 아니라 지향 수준으로 묘사될 때 시작됩니다. 여기서 그 구분은 유난히 명확합니다. 8월에 논의된 것은 Team이 결국 가이드에 쓴 것보다 많았습니다.

채택된 답은 제출의 비용을 바꾼다

희소한 리뷰 역량에 대한 가이드의 첫 대응은 조직 작업의 더 많은 부분을 제출자에게 이전하는 것입니다.

풀 리퀘스트에는 규모에 비례하는, 사람이 읽을 수 있는 설명이 필요합니다. 개별적으로 리뷰 가능할 만큼 작은 커밋으로 분할되어야 합니다. 프로젝트의 기존 스타일을 따르고, 프로젝트의 테스트 전략에 맞는 테스트로 완전히 커버되어야 하며, 새 의존성을 공개하고 정당화해야 합니다. 커뮤니티 정책 결정을 필요로 하는 코드는 그 결정이 해소될 때까지 기다려야 합니다.

이것들은 장식적 조건이 아닙니다. 리뷰 수요를 만드는 행위자에게 작업을 이전시킵니다.

대규모 생성된 diff는 제공자가 줄마다 부담하는 한계비용이 작아 보기에 저렴해 보일 수 있습니다. 유지보수자에게는 다른 가격표가 보입니다. 각 줄은 오래된 가정, 데이터 모델, 운영 트래픽, 보안 경계, 향후 유지보수가 얽힌 시스템 안에 자리해야 합니다. 테스트는 통과하더라도 데이터베이스 쿼리가 확장성 문제를 일으킬 수 있습니다. 의존성 하나가 기능 하나를 해결하면서 새로운 업데이트·취약점 부담을 들여올 수 있습니다. 국소적으로 깔끔한 추상화가 다른 곳의 핵심 로직을 복제할 수 있습니다. 가이드는 유지보수성, 효율성, 보안, 데이터 무결성, 로직 배치라는 리스크를 이름으로 지목합니다.

작은 커밋이 정확성을 증명하지 못합니다. 테스트가 악의적 동작의 부재를 증명하지 못합니다. 세련된 설명이 틀릴 수도 있습니다. 그러나 이 요건들은 기여를 생성물의 덩어리가 아니라 일련의 주장으로 리뷰 가능하게 만듭니다. 또한 유지보수자가 이해만으로 과도한 노력을 요구하는 작업을 거절할 정당한 근거를 줍니다.

그 거절 권한은 통제의 일부이며, 개방성의 실패가 아닙니다. 개방적 기여가 무제한의 리뷰 비용을 외부에 전가할 권리를 만들지는 않습니다. IETF의 기관적 이해관계는 환영했다고 말할 수 있는 풀 리퀘스트의 수가 아니라, 기여자가 떠난 뒤에도 계속 운영해야 하는 시스템의 신뢰성입니다.

이름이 붙은 인간은 유지보수 채권이다

가이드의 AI 섹션은 책임에 대해 신중하지만, 정확히 읽어야 합니다.

기여의 배후 인물이 코드가 무엇을 하도록 의도되었는지, 그것이 관련 IETF Tool에 어떻게 맞는지 이해하도록 요구합니다. 사람이 읽을 수 있는 설명의 모든 줄을 읽고 이해했는지를 특별히 요구합니다. 또한 에이전트 생성 설명 특유의 전문 용어가 아니라平이한 기술 언어를 요구합니다.

가이드는 기여자가 모든 줄을 직접 작성했다고는 말하지 않습니다. 해당 조항에서 기여자가 생성 코드의 모든 줄에 대한 이해를 증명했다고도 말하지 않습니다. 이 규칙을 어느 쪽 주장으로 바꾸면 공개 기록이 텍스트보다 강하게 읽히게 됩니다.

더 중요한 요건이 그 다음에 옵니다. 그 사람은 이름만 빌려주는 것이 아니라, 코드에서 발생하는 문제를 수정할 것을 약속합니다. 그렇지 않으면 코드가 제거되고 이후 기여가 거부될 수 있습니다.

이것은 유지보수 채권으로 이해하는 것이 가장 좋습니다. 미래의 가용성이나 책임 이행을 보장할 수 없고, 최종 책임을 Team으로부터 이전하지도 않습니다. 그러나 하나의 비대칭을 숨기기 더 어렵게 만듭니다. 기여자는 야심찬 기능의 상방을 취하면서 장기적 복잡성이라는 하방 전체를, 그것을 요청한 적 없는 유지보수자들에게 떠넘길 수 없습니다.

가이드는 또한 정기적인 AI 기여자가 알려지고 신뢰받게 되기를 기대합니다. 기여 이력은 유용한 증거가 될 수 있습니다. 이해 가능하고 테스트가 잘 된 변경을 반복 제출하고 결함 수정을 위해 돌아오는 사람은, 거대한 diff 하나만 남긴 신규 계정보다 더 많은 정보를 제공한 것입니다.

그러나 신뢰는 코드의 기술적 속성이 아닙니다. 관계에 관한 증거입니다. 현재 가이드는 점수, 재직 기간 기준, 라인 리뷰 면제, 자율 병합 권한을 정의하지 않습니다. 모든 기여가 동일한 공개 리뷰 규칙 아래 있는 한, 그 부재들은 결함이 아닙니다. 신뢰가 나중에 병합에 필요한 증거를 바꾼다면 그때 비로소 중요해집니다.

8월에 문서화되지 않은 것

8월 소식은 병합된 가이드가 아직 실현하지 않은 두 번째 대응을 검토했습니다.

AI 유지보수 코드베이스에 대해, 고영향 코드와 저영향 코드를 구분했습니다. 고영향 코드는 계속 완전한 인간 리뷰를 받습니다. 더 낮은 영향의 코드는 대신 테스트 품질 및/또는 다른 AI에 의한 적대적 코드 리뷰를 통해 검증될 수 있습니다. 소식은 이 접근 전체를 여전히 논의 중으로 표현했습니다.

논의할 가치가 있는 합리적 주제입니다. 모든 저장소, 구성요소, 변경이 동일한 하방을 만들지는 않습니다. 빠른 롤백이 가능한 표시 전용 페이지는, 인증, 비공개 회의 자료, 표준 메타데이터, 메일링 리스트 상태, 재무 데이터, 특정 시점에 IETF 직책을 누가 가졌는지의 기록과 다릅니다. 모든 변경에 동등한 인간 노력을 쓰는 것은 낭비일 수 있고 훨씬 큰 결과를 가진 작업을 지연시킬 수 있습니다.

그러나 '저영향'은 저절로 나타나는 사실이 아닙니다. 누군가 분류 단위를 선택합니다. 누군가 어떤 결과를 계산에 넣을지 결정합니다. 누군가 테스트 품질을 판단합니다. 누군가 AI 리뷰를 충분히 적대적이라고 받아들입니다. 누군가 롤백이 이론이 아니라 실제라고 판단합니다. 그리고 누군가 병합을 승인합니다.

그것이 다음 거버넌스 경계입니다.

결정은 단순히 인간 대 기계가 아닙니다. 사람이 불완전한 설명으로부터 취약한 분류를 내릴 수 있습니다. AI 시스템이 지친 리뷰어가 놓친 파일 간 결함을 찾을 수 있습니다. 테스트 스위트가 수동 읽기보다 한 동작에 대해 더 강한 증거를 줄 수 있습니다. 관련 질문은 어떤 증거가 어떤 결정을 지지하는가, 그 결정을 누가 소유하는가, 분류가 틀린 것으로 드러나면 무슨 일이 일어나는가입니다.

기록이 없으면 라벨이 전체 체인을 흡수합니다. 이후 사건은, 실제 오류가 사람이 데이터 기록 마이그레이션을 되돌릴 수 있는 것으로 분류했거나, 오래된 테스트 환경이 운영 부하를 놓쳤거나, 유지보수자가 리뷰 큐가 차서 예외를 승인한 것임에도, '저영향 AI 코드가 실패했다'로 서술될 수 있습니다.

리뷰 경계 영수증

Team은 저리뷰 결정을 판독 가능하게 만들기 위해 프롬프트, 자격 증명, 익스플로잇 지침을 공개할 필요가 없습니다. 불변의 기여에 묶인, 간결하고 버전화된 영수증이 필요합니다.

첫 블록은 저장소, 구성요소, 영향받는 서비스 또는 기록 표면, 풀 리퀘스트와 정확한 커밋을 밝혀야 합니다. 기여가 사람 저작, AI 지원, 또는 유용한 수준에서 주로 에이전트 생성인지를 공개해야 하며, 기계 저작의 백분율이 완벽히 측정될 수 있다고 가장해서는 안 됩니다.

두 번째 블록은 책임 있는 인간 기여자와 지원 약속을 명명해야 합니다. 이어서 영향 등급, 고려된 결과, 분류자를 명시해야 합니다. 보안, 데이터 무결성, 프라이버시, 성능, 가용성, 표준 기록 보관, 되돌릴 가능성은 하나의 설명 없는 점수가 아니라 명시적 차원이어야 합니다. 영수증은 분류일과 그 경로를 가능하게 한 정책 버전을 담아야 합니다.

세 번째 블록은 요구된 근거와 제공된 근거를 나열해야 합니다. 변경에 따라 사람의 계획, 테스트와 커버리지, 의존성 변경, 성능 결과, 보안 점검, 데이터 마이그레이션 증명, 배포 단계, 입증된 롤백이 포함될 수 있습니다. 중심 결정이 라인 리뷰보다 테스트에 더 크게 의존하는 것이라면 '테스트 통과'는 너무 거칩니다. 독자는 테스트가 실제로 어떤 리스크 주장을 다루었는지 알아야 합니다.

네 번째 블록은 의도된 리뷰가 아니라 수행된 리뷰를 기록해야 합니다. 어떤 부분이 줄 단위 인간 검사를 받았는가? 누가 검사했는가? 어떤 표면은 받지 못했는가? 다른 AI가 적대적 분석을 수행했다면, 어떤 부류의 도구였고 어떤 입력을 볼 수 있었으며 어떤 발견이 미해결로 남았는가? 기계는 근거 생산자입니다. 병합 권한의 보유자가 아닙니다.

마지막 블록은 인간 병합 승인자, 배포 책임자, 유지보수 책임자를 식별해야 합니다. 예외 및 에스컬레이션 경로, 완전한 인간 리뷰를 강제하는 조건, 모니터링 기간, 롤백 또는 제거의 트리거를 서술해야 합니다. 기여가 나중에 재분류되더라도 원래 결정은 계속 보여야 합니다.

기존의 완전한 리뷰를 받는 정상적 기여는 짧은 영수증을 만들 수 있습니다. 전체 버전은 예외에 속합니다. 이렇게 하면 공개가 비례를 유지하고 감사 메커니즘 자체가 유지보수자에 대한 또 하나의 서비스 거부가 되는 일을 막습니다.

다른 AI는 도전할 수 있지만, 하방을 물려받을 수는 없다

적대적 AI 리뷰는 생성과 함께 확장되는 것처럼 보이기에 매력적입니다. 한 모델이 코드를 쓰고, 다른 모델에게 그것을 깨뜨리도록 요청합니다. 이 배치는 불일치, 누락된 테스트, 수상한 의존성, 위험한 엣지 케이스를 노출할 수 있습니다. 사무총장 보고서는 이런 도구를 무시하지 말아야 할 구체적 이유를 제시합니다. AI 지원은 두 건의 어려운 Datatracker 성능 문제 진단을 몇 주 혹은 몇 달 걸렸을 작업에서 몇 시간으로 줄였고, 완화와 이후의 실질적 수정으로 이어졌습니다.

그 보고서는 AI가 사건을 일으켰다고 말하지 않습니다. 성공적 진단 활동이 AI가 병합을 승인할 수 있음을 증명하지도 않습니다. 진단과 책임은 다른 기능입니다.

두 시스템은 같은 사각지대를 공유할 수 있습니다. 유사한 코드 패턴, 불완전한 저장소 맥락, 동일한 잘못된 요건에 의존할 수 있습니다. 적대적 프롬프트는 유용한 마찰을 만들 수 있지만 독립된 주체를 만들지는 못합니다. 결과가 틀리면 모델은 서비스를 유지보수하지 않고, 인시던트에 응답하지 않고, 데이터를 복구하지 않고, 커뮤니티에 승인을 설명하지도 않습니다.

그렇기 때문에 기계 리뷰는 범위가 한정된 근거로 기록되어야 합니다. 인간 의사결정자는 계속 보여야 합니다. 'AI가 검토했다'는 최종 상태일 수 없으며, '테스트 통과'가 운영 리스크의 완전한 설명일 수 없는 것과 마찬가지입니다.

운영 권한은 운영에 머물러야 한다

이해관계가 실재하는 이유는Tools Team이 IETF 작업을 지원하는 응용프로그램을 개발하고 운영하기 때문입니다. 그 시스템은 참가자들이 표준을 작성, 논의, 발행하도록 돕습니다. 결함은 가용성, 데이터 무결성 또는 기관 기록에 영향을 줄 수 있습니다.

그 중요성이 Team을 표준 기구 안의 표준 기구로 만들지는 않습니다.

RFC 8711은 IETF Administration LLC에 지속적 운영 책임을 부여하면서, IETF 표준 개발 활동에 대한 권한은 없다고 명시합니다. 기여 가이드는 커뮤니티 정책 결정을 필요로 하는 코드는 그 결정을 소프트웨어에 먼저 새기지 말고 결정을 기다려야 한다고 말함으로써 같은 경계를 반영합니다.

리뷰 경계 영수증은 이 분리를 보존해야 합니다. 누가 어떤 근거 기준으로 운영적 구현을 승인했는지 보여줄 수 있습니다. 코드 유지보수자, 신뢰받는 기여자, AI 분류자가 구현을 저영향으로 서술함으로써 논쟁 중인 커뮤니티 규칙을 종결하도록 허락해서는 안 됩니다.

여기서Lu Heng의 Running-Code Primacy는 좁게 적용하면 유용합니다. 실행 중인 시스템과 검증 가능한 상태가 기관의 주장을 규율해야 합니다. 그렇다고 실행 중인 코드가 명시적 표준 절차를 자동으로 압도한다는 뜻이 아닙니다. 행정적 라벨이 코드를 실제로 작동하게 만든 운영 상태, 근거, 책임을 가릴 수 없다는 뜻입니다.

인터넷 거버넌스의 대리인 문제에 관한 그의 논의는 인센티브 질문을 더합니다. 기여자는 기능이 수용되는 데 최적화할 수 있습니다. 코딩 에이전트는 그럴듯한 해결책을 만드는 데 최적화할 수 있습니다. 리뷰어는 큐를 비우는 데 최적화할 수 있습니다. 관리자는 백로그 감소에 최적화할 수 있습니다. 장기적 후방은 운영자와 커뮤니티가 물려받습니다. 영수증은 인센티브를 동일하게 만들지는 못하지만, 그 소유자들이 'AI 기여' 같은 한 구절 속으로 사라지는 것은 막습니다.

예외에 이름을 붙일 수 있을 때까지 현재 규칙을 유지하라

확인된 기록 어디에도 IETF Tools가 리뷰를 낮췄거나, 악의적 AI 기여를 입었거나, 자기 가이드를 위반했다는 증거는 없습니다. 공개 증거는 더 절제된 결론을 지지합니다.

Team은 기존 리뷰 경제가 확장 가능하지 않을 수 있음을 인식했습니다. 들어오는 작업의 품질을 높이고 리뷰 비용을 낮추는 요건을 채택했습니다. 줄 단위 유지보수자 리뷰를 유지했습니다. AI 생성 기여에 인간 지원 의무를 붙였습니다. 그리고 더 영향력 큰 위험 등급 모델은 논의 중으로 남겼습니다.

이는 타당한 순서입니다.

다음 단계는 'AI는 계속 인간의 통제 아래 있을 것'이라는 폭넓은 약속이 아니어야 합니다. 인간 리뷰가 축소되는 순간을 위한 정확한 기록이어야 합니다. 무엇이 분류되었는가, 누가, 어떤 버전 아래, 어떤 결과에 대비해, 어떤 증거로, 어떤 기계 지원으로, 누구의 승인으로, 어떤 조건에서 되돌릴 수 있는가.

문제는 희소한 주의력에 대한 가능적 서비스 거부로 시작되었습니다. 그것을 해결하는 일이 더 덜 보이는 책임의 거부를 만들어서는 안 됩니다.