Linux Kernel AGENTS.md 제안, AI 에이전트가 인간의 규칙을 따를 수 있는지 시험하다
Linux kernel AGENTS.md 제안은 단 하나의 심볼릭 링크만 추가하지만, AI 지원 코드와 관련해 커져 가는 갈등을 겨냥한다. 2026년 9월 24일 제출된 이 패치는 코딩 에이전트가 커널의 기존 지침을 자동으로 더 쉽게 찾도록 만들 수 있다.
제안된 파일은 자율적인 기여를 승인하거나 커널의 검토 기준을 완화하지 않는다. 대신 AI 도구를 프로젝트의 상세 기여 정책으로 이미 안내하고 있는 README를 에이전트가 찾도록 유도한다. 이 변경은 더 좁은 문제를 다룬다. 에이전트는 주로 사람을 위해 작성된 문서를 읽기 전에 행동하는 경우가 많다.
이 구분은 중요하다. 커널은 이미 AI 도구에 사람을 대신해 패치를 인증하지 말라고 지시하고 있기 때문이다. 또한 인간 검토, 적절한 출처 표기, 테스트, 책임을 요구한다. 따라서 Linux kernel AGENTS.md 제안은 발견 가능한 지침과 더 어려운 현실을 맞세운다. 저장소 파일은 에이전트를 안내할 수는 있어도 신뢰할 수 없는 패치를 신뢰할 만하게 만들 수는 없다.
Linux Kernel AGENTS.md 제안은 하나의 진입점만 바꾼다
이 패치는 규칙 자체가 아니라 에이전트가 기존 규칙을 발견하는 방식을 바꾼다.
커널 메인테이너 Sasha Levin은 “docs: add AGENTS.md as a symlink to README”라는 제목의 패치를 제출했다. 이 제안은 최상위 수준에 저장소의 기존 README 파일을 가리키는 AGENTS.md라는 심볼릭 링크를 만든다.
심볼릭 링크는 하나의 파일 이름을 다른 파일로 연결하는 파일 시스템 참조다. 이 경우 에이전트가 AGENTS.md를 열면 별도의 지침 사본이 아니라 README를 통해 이미 제공되는 동일한 내용을 받게 된다.
이 설계는 메인테이너가 동기화해야 하는 정책 문서 두 개를 만드는 일을 피한다. Levin의 심볼릭 링크 제안에 따르면, 기존 README는 이미 AI 도구를 Documentation/process/coding-assistants.rst로 안내한다. 문제는 이 안내가 도움이 되려면 에이전트가 먼저 README를 열기로 결정해야 한다는 점이다.
많은 코딩 에이전트는 특별히 명명된 지침 파일을 자동으로 검사한다. AGENTS.md는 빌드 명령, 테스트 요구 사항, 코딩 규약, 안전 경계를 포함한 저장소 수준 지침에 쓰이는 일반적인 파일명 중 하나가 됐다.
제안된 커널 파일에는 별도의 문구가 들어가지 않는다. 유일한 내용은 링크 대상인 README다. 이렇게 하면 사람과 기계의 진입 경로가 하나의 유지 관리되는 출처에 연결된 상태로 유지된다.
Levin은 검색 가능성이 중요한 이유를 설명하기 위해 통제된 예시를 포함했다. 두 에이전트는 동일한 요청을 받았다. Makefile에서 커널 릴리스 이름을 “AI Test”로 바꾸는 커밋을 생성하라는 요청이었다.
AGENTS.md가 없는 경우, 한 에이전트는 사용자를 위한 Signed-off-by 줄을 생성했다. 다른 에이전트는 AI 관련 출처 표기를 하지 않았다. 두 결과 모두 커널에 문서화된 기대 사항과 충돌했다.
심볼릭 링크가 있는 경우, 두 에이전트는 보고에 따르면 Assisted-by: LLM 태그를 사용하고 인간 서명을 추가하지 않았다. 또한 프로젝트의 커밋 메시지 규약을 더 충실히 따랐다. 한 에이전트는 설명적인 본문을 추가했고, 다른 에이전트는 기대되는 “subsystem: summary phrase” 제목 구조를 사용했다.
이는 에이전트 신뢰성을 폭넓게 평가한 것이 아니라 제한된 행동 테스트였다. 에이전트가 미묘한 버그를 찾을 수 있는지, 안전한 수정을 만들 수 있는지, 하위 시스템별 제약을 이해할 수 있는지는 측정하지 않았다. 다만 두 에이전트가 기존 지침으로 이어지는 자동 발견 경로를 받은 뒤 다르게 행동했다는 점을 보여 줬다.
보도 당시 이 변경은 여전히 검토 중이었다. 따라서 이를 Linux가 이미 채택한 것처럼 설명하는 것은 사건을 과장하는 표현이다. 정확한 주장은 커널 메인테이너가 이 링크를 제안했고 이를 뒷받침하는 증거를 제공했다는 것이다.
저명한 커널 보안 개발자 Kees Cook은 이에 대한 확인 응답을 보냈다. 그는 별도의 에이전트 전용 정책을 유지하는 대신 README를 사용하는 방안을 지지했다. 그의 검토 응답은 에이전트가 패치를 만들기 전에 기여 문서를 읽도록 하는 것이 바람직하다고도 언급했다.
이 패치는 의례적으로 보일 만큼 작다. 하지만 실용적 목적은 분명하다. AI 도구가 이미 검사하도록 훈련됐거나 설정된 경로에 필수 프로세스 정보를 배치하려는 것이다.
이는 이 제안을 인터페이스 변경으로 만든다. 사람은 문서 트리를 탐색하고 커뮤니티 규범을 해석할 수 있다. 코딩 에이전트는 저장소가 도구가 인식하는 파일명과 경로를 통해 그러한 규범을 노출할 때 더 예측 가능하게 동작한다.
따라서 핵심 질문은 Markdown이 생성된 코드를 개선할 수 있는지 여부가 아니다. 신뢰할 수 있는 진입점이 메인테이너가 직접 잡아내야 하기 전에 반복되는 프로세스 오류를 막을 수 있는지 여부다.
기존 커널 규칙은 여전히 인간에게 책임을 묻는다
Linux kernel의 AI 정책은 에이전트를 기여의 법적 또는 기술적 소유자가 아닌 보조 도구로 취급한다.
기저 규칙은 제안된 심볼릭 링크보다 이미 훨씬 광범위하다. 커널의 AI 기여 가이드는 AI 도구와 그 사용자를 표준 개발 프로세스, 코딩 스타일, 패치 제출 요건, 라이선스 규칙, 생성 콘텐츠 정책으로 안내한다.
가장 중요한 점은 이 가이드가 AI 에이전트에 Signed-off-by 태그를 추가하지 말라고 명시한다는 것이다. 이 줄은 장식적인 커밋 메타데이터가 아니다. 이는 일반적으로 DCO라고 불리는 Developer Certificate of Origin에 따라 사람이 하는 인증을 나타낸다.
DCO는 기여자가 제출한 작업물이 해당 라이선스에 따라 프로젝트에 합법적으로 들어갈 수 있음을 밝히는 방식이다. 언어 모델은 사람을 대신해 이러한 인증을 할 수 없다. 또한 그 사람이 책임을 수용하기 위해 필요한 검토를 완료했는지도 판단할 수 없다.
인간 제출자는 생성된 코드를 검토하고, 라이선스 준수를 확인하며, 서명을 추가하고, 기여에 대한 책임을 져야 한다. 에이전트가 서명을 직접 삽입하면 이 별개의 단계들이 생성된 텍스트로 축소된다.
이 때문에 Levin의 테스트는 범위가 작음에도 중요하다. 에이전트는 단지 선호되지 않는 서식 스타일을 선택한 것이 아니다. 오직 인간만이 정당하게 할 수 있는 진술을 생성했다.
커널 문서는 AI 참여에 다른 표식을 부여한다. AI 도구가 기여했을 때 패치는 Assisted-by 태그를 사용해야 한다. Coccinelle, Sparse, Smatch, Clang-Tidy 같은 선택적 분석 도구도 LLM 표기 뒤에 나타날 수 있다.
이 출처 표기 모델은 지원과 저작, 인증을 구분한다. 모델이 책임을 질 수 있는 것처럼 가장하지 않으면서 검토자에게 유용한 맥락을 제공한다.
문서는 AI 지원 버그 작업에 대해서도 까다로운 프로세스를 수립한다. 에이전트는 관련된 완전한 문서를 읽고, 구체적인 버그를 찾아야 하며, 사소하지 않은 문제는 재현을 시도해야 한다. 검증을 통과하지 못한 발견은 포기해야 한다.
문제가 실제로 보인다면 에이전트는 수정안을 작성하고, 빌드하며, 재현 도구 또는 완전한 분석을 통해 테스트하고, 커널의 패치 검사를 실행해야 한다. 검증하지 못한 모든 사항을 명시해야 한다.
가이드는 에이전트에 관련 메인테이너와 메일링 리스트를 식별하라고도 지시한다. 해당 문제가 일반 버그 프로세스에 속하는지, 비공개 보안 프로세스에 속하는지 평가해야 한다. 실제 제출은 도구를 사용하는 사람에게 맡겨야 한다.
이러한 요건은 AGENTS.md를 그 자체로 해결책으로 취급하는 접근의 한계를 드러낸다. 파일은 에이전트를 올바른 체크리스트로 안내할 수 있다. 하지만 재현 도구가 의미 있는지, 테스트가 충분한지, 인간이 코드를 이해하는지는 확인할 수 없다.
커널 개발은 특수한 기대 사항을 지닌 수천 개의 구성 요소에 걸쳐 있다. 일반 지침에는 모든 아키텍처 제약, 하드웨어 가정, 메인테이너 선호를 담을 수 없다.
에이전트는 눈에 보이는 서식 규칙을 완벽히 준수하면서도 수명 관리, 잠금, 메모리 순서, 장치 동작을 오해할 수 있다. 잘 다듬어진 커밋 메시지는 그러한 패치를 더 쉽게 검토하게 할 수는 있지만, 그 기저 추론을 올바르게 만들지는 못한다.
이것이 유용한 경계를 만든다. 저장소 지침은 피할 수 있는 행정적 실수를 줄일 수 있다. 기술적 확신은 여전히 증거, 테스트, 전문가 검토, 책임 있는 기여자로부터 나와야 한다.
메인테이너에게 이 분리는 중요하다. 잘못된 형식의 제출 하나하나는 그 기술적 실질에 도달하기도 전에 주의를 소모시킨다. 더 나은 지침 발견 방식은 수용 기준을 낮추지 않고도 이러한 오버헤드를 줄일 수 있다.
기여자에게도 정책은 명확하다. 에이전트를 사용한다고 해서 책임이 이전되는 것은 아니다. 개발자는 모든 줄을 직접 작성한 것처럼 결과를 설명하고 방어할 수 있어야 한다.
AI 코딩 에이전트가 계속 README를 놓치는 이유
갈등의 본질은 존재하는 문서와 에이전트의 자동 컨텍스트 안에 나타나는 지침 사이에 있다.
저장소는 전통적으로 사람을 위해 기여자 정보를 구성한다. README는 프로젝트를 소개하고, 기여 파일, 문서 디렉터리, 메일링 리스트 페이지, 스크립트는 더 전문화된 절차를 담는다.
Linux 소스 트리에 도착한 사람은 이 계층을 따를 수 있다. 반면 좁은 프롬프트를 받은 에이전트는 즉시 관련 있다고 판단하는 파일만 검사할 수 있다. 루트 README를 열지 않는다면 README에서 AI 정책으로 연결하는 링크는 보이지 않는다.
이러한 동작은 AI 지원 Qualcomm I2C 수정과 관련한 최근 커널 논의에서 나타났다. 한 메인테이너는 README에서 시작해 coding-assistants.rst로 이어지는 사슬을 통해 프로세스가 문서화돼 있다고 관찰했다. 그러나 도구는 이 사슬을 일관되게 따르지 않았다.
메인테이너 논의는 일반적인 도구가 기본적으로 검사하는 AGENTS.md 또는 CLAUDE.md 파일의 부재를 제기했다. 또한 그러한 파일을 추가한다고 해서 모든 문제가 반드시 해결되는 것은 아니라고 경고했다.
이것이 새 제안의 배경 압력이다. 커널 메인테이너는 저장소가 에이전트를 위해 문서를 최적화하는지 여부와 관계없이 AI 지원 패치를 마주한다. 진입점을 추가하지 않는다고 해서 기여자가 그러한 도구를 사용하는 일을 멈추게 하지는 않는다.
실질적인 선택지는 더 좁다. 메인테이너는 에이전트가 사람 중심 문서를 일관성 없이 발견하도록 내버려 둘 수 있고, 또는 저장소 루트에 익숙한 표지판을 둘 수 있다.
더 광범위한 AGENTS.md 관례는 이 파일을 에이전트를 위한 README로 설명한다. 그 공개 형식 문서는 60,000개가 넘는 오픈 소스 프로젝트가 이 관례를 사용한다고 밝히지만, 이 수치는 활성 에이전트 사용에 대한 감사된 측정치가 아니라 색인화된 사례를 반영한다.
이 형식은 필수 스키마를 강제하지 않는다. 프로젝트는 설정 명령, 코드 스타일 규칙, 테스트, 보안 고려 사항, 더 깊은 문서로의 링크를 나열할 수 있다. 중첩 파일은 하위 디렉터리에 더 구체적인 지침을 제공할 수 있다.
이러한 유연성은 형식이 확산된 이유를 설명하는 데 도움이 된다. 저장소는 독점적인 구성 시스템에 의존하지 않고 여러 도구에 걸쳐 하나의 평범한 Markdown 파일을 사용할 수 있다.
커널 제안은 이 패턴을 유난히 보수적으로 적용한다. 대규모 에이전트 매뉴얼을 만들거나 이미 다른 곳에서 관리되는 정보를 반복하지 않는다. 대신 에이전트가 요청할 가능성이 높은 이름으로 기존 README를 노출한다.
이 접근 방식은 사람과 기계를 위한 가이드 사이의 일관성도 유지한다. Kees Cook는 README가 의도적으로 에이전트도 활용할 수 있도록 설계됐다고 말했다. README로 연결하면 사람 기여자가 보지 못할 수도 있는 비공개 규칙 세트를 새로 만드는 대신, 모두가 공유하는 경로를 강화할 수 있다.
공유된 단일 소스는 정책 표류를 줄인다. 유지관리자가 README 또는 AI 가이드로 연결되는 포인터를 업데이트하면 에이전트는 심볼릭 링크를 통해 그 변경을 받는다. 복사된 AGENTS.md는 아무런 경고 없이 오래된 내용이 될 수 있다.
다만 심볼릭 링크 사용에는 호환성 측면의 고려가 따른다. Unix 계열 시스템은 저장소의 심볼릭 링크를 자연스럽게 처리하지만, 일부 Windows 구성에서는 이를 일반 파일로 체크아웃한다. 그러면 에이전트는 참조된 콘텐츠가 아니라 README라는 단어만 보게 될 수 있다.
특히 이미 정착된 Linux 워크플로를 중심으로 개발되는 프로젝트라면, 이 문제가 제안 자체를 무효화하지는 않는다. 다만 이 패치를 마법 같은 메타데이터가 아니라 인프라로 평가해야 하는 이유를 보여준다.
도구의 동작도 제각각이다. 일부 에이전트는 AGENTS.md를 자동으로 불러오지만, 다른 에이전트는 도구별 파일명을 선호하거나 명시적 설정을 요구한다. 보편적으로 보이는 파일명이라고 해서 보편적으로 읽힌다는 보장은 없다.
따라서 이 패치는 도구 간 차이를 없애지는 않지만, 많은 에이전트가 규칙을 따르게 될 가능성 있는 경로를 개선한다. 그 이점은 클라이언트가 링크를 따라가고, 지침을 준수하며, 작업 전반에 걸쳐 이를 보존하는지에 달려 있다.
이 조건들은 좋은 문서화만 갖추는 것보다 강하다. 그러나 강제 가능한 기술적 통제보다는 약하다.
더 나은 지침이 생성된 패치를 안전하게 만들지는 않는다
AGENTS.md는 준수를 개선할 수 있지만, 정확성·출처·실질적인 사람의 검토를 보장할 수는 없다.
이 제안에 대한 가장 강력한 주장은 운영 측면에 있다. 에이전트는 이미 커널 관련 패치를 만들고 있으므로, 유지관리자는 이들이 규칙에 도달할 예측 가능한 경로를 제공해야 한다. 잘못된 서명과 누락된 기여 표기를 막으면 검토 시간을 절약할 수 있다.
가장 강력한 비판 역시 운영 측면에 있다. 생성된 패치는 눈에 보이는 모든 지침을 따르면서도 탐지하기 어려운 방식으로 여전히 잘못될 수 있다.
지침 준수 평가는 흔히 단순하고 관찰 가능한 결과를 사용한다. 에이전트가 올바른 태그를 추가했는가? 지정된 명령을 실행했는가? 제목 형식을 올바르게 맞췄는가? 이런 점검은 중요하지만, 커널 품질은 더 깊은 속성에 달려 있다.
수정은 컴파일을 통과하고도 경쟁 상태를 도입할 수 있다. 재현기는 하나의 하드웨어 구성을 시험하면서 다른 구성을 놓칠 수 있다. 에이전트는 올바른 문서를 인용하면서도 그 문서가 기여자가 이미 알고 있다고 전제하는 불변 조건을 오해할 수 있다.
더 깔끔한 표현이 부적절한 신뢰를 키울 위험도 있다. 잘 구성된 커밋 메시지, 유효한 기여 표기, 통과한 점검은 AI 지원 패치를 성숙해 보이게 만들 수 있다. 검토자는 여전히 이런 신호를 기술적 건전성의 증거가 아니라 프로세스 준수로 봐야 한다.
커널의 현행 정책은 이 문제를 예상하고 있다. 사람에게 코드를 검토하고 책임을 지도록 요구한다. 또한 기여자에게 자신감 있는 문구로 빈틈을 감추기보다, 누락된 테스트나 실패한 검증을 공개하도록 요구한다.
사람들이 이런 요구 사항을 따를지는 AGENTS.md의 영향권 밖에 있다. 기여자는 기여 표기 태그를 제거하거나, 실패한 테스트를 무시하거나, 이해하지 못하는 코드를 제출할 수 있다. 이 파일에는 사람의 검토가 실제로 이뤄졌는지 독립적으로 확인할 방법이 없다.
다른 오픈소스 프로젝트들도 같은 문제에 서로 다른 전략으로 대응했다. linux-firmware 저장소는 2026년 초 기여 규칙과 기여 표기 지침을 포함한 에이전트 중심 문서를 도입했다. 해당 firmware guidance는 에이전트가 읽을 수 있는 정책의 가까운 선례를 제시했다.
NetworkManager는 AI 정책을 수립한 뒤 더 적대적인 접근 방식을 택했다. 보도에 따르면 그 지침은 정책을 준수하지 않는 에이전트에게 기여자 커뮤니케이션에 특이한 카나리아 단어를 넣도록 지시했다. 그러면 유지관리자는 프로젝트 정책을 우회하면서 숨은 지침을 따른 제출물을 식별할 수 있다.
그 카나리아 메커니즘은 지침 파일의 정반대 활용을 보여준다. 에이전트가 수용 가능한 패치를 만들도록 돕는 대신, 거부해야 할 자동화된 행동을 식별하는 데 파일을 사용한다.
두 접근법은 같은 사실을 인정한다. 에이전트는 저장소 문맥을 읽고 그에 따라 출력을 바꾼다. 차이는 그 행동을 준수로 유도할지, 아니면 탐지 신호로 활용할지에 있다.
커널 제안은 가이드를 택한다. 에이전트를 사용하는 기여자도 다른 모든 사람과 동일한 법적·기술적·검토 의무를 따른다면 계속 참여할 수 있다고 본다.
이는 감독 없는 커널 개발을 지지하는 것이 아니다. 에이전트가 작업을 시작하는 순간, 기존의 경계를 눈에 보이게 하려는 시도다.
이 제안은 기계에만 존재하는 지침을 만드는 일도 피한다. AGENTS.md가 README를 가리키므로, 유지관리자와 기여자는 에이전트가 받는 동일한 소스를 확인할 수 있다.
투명성은 도움이 되지만 프롬프트 인젝션이나 악의적인 저장소 콘텐츠 문제를 해결하지는 않는다. 코딩 에이전트는 일상적으로 파일, 이슈 텍스트, 댓글, 로그, 외부 페이지의 지침을 소비한다. 충돌하거나 적대적인 지시는 신뢰할 수 있는 정책과 경쟁할 수 있다.
최상위 파일은 협조적인 도구를 위한 우선순위를 설정할 수 있다. 그러나 특히 에이전트가 모순된 문구를 담은 하위 파일을 읽을 때, 모든 도구가 그 우선순위를 올바르게 적용한다고 보장할 수는 없다.
관련된 유지보수 위험도 있다. 모든 저장소 가이드는 워크플로가 변하면서 오래될 수 있다. 제안된 심볼릭 링크는 중복을 줄이지만, 연결된 문서 역시 지속적인 검토가 필요하다.
커널의 규모는 이런 유지보수를 특히 중요하게 만든다. 대체로 올바른 지침도 특정 서브시스템에는 불완전할 수 있다. 에이전트와 기여자는 계속해서 로컬 문서, 유지관리자, 빌드 시스템, 테스트 인프라를 참고해야 한다.
따라서 균형 잡힌 관점은 “AGENTS.md가 AI 코드 문제를 해결한다”도, “이 파일은 무의미하다”도 아니다. 가장 어려운 검증 작업은 그대로 남겨 두면서, 예측 가능한 특정 오류 유형을 줄일 수 있다.
이 절제된 주장은 Levin의 사례가 뒷받침한다. 그보다 넓은 주장은 다양한 서브시스템과 도구에서 나온 실제 기여의 증거를 기다려야 한다.
다음에 일어날 일은 심볼릭 링크보다 더 중요하다
이 제안은 채택 이후의 검토 결과, 에이전트 행동, 유지관리자 업무량으로 평가해야 한다.
첫 번째 신호는 패치의 처리 결과다. 승인 표시는 설계를 뒷받침하지만, 변경 사항이 표준 프로젝트 인프라가 되려면 여전히 커널 문서화 절차를 거쳐 메인 저장소에 도달해야 한다.
검토자는 심볼릭 링크를 수정 없이 받아들일 수도 있고, 일반 파일을 요청할 수도 있으며, 호환성 조정을 요구하거나 README 경로가 충분하지 않다고 판단할 수도 있다. 각 결과는 커널이 자동화 도구에 규칙을 어떻게 노출하려 하는지 명확히 해 줄 것이다.
두 번째 신호는 주요 코딩 에이전트가 링크를 일관되게 따르는지 여부다. Levin의 두 에이전트 비교는 유용하지만 규모가 작다. 더 폭넓은 테스트는 다양한 도구, 프롬프트, 작업 디렉터리, 기여 유형을 포괄해야 한다.
성공적인 구현은 더 적은 생성형 서명, 더 일관된 Assisted-by 태그, 더 나은 커밋 제목, 테스트하지 않은 작업에 대한 더 명확한 공개를 만들어낼 것이다. 이는 관찰 가능한 프로세스 개선이다.
실패는 다른 모습으로 나타날 것이다. 에이전트가 심볼릭 링크를 무시하거나, 연결된 자료의 일부만 읽거나, 일반 규칙을 따르면서 서브시스템별 요구 사항을 놓칠 수 있다. 도구별 지침 파일이 계속 필요할 수도 있다.
세 번째이자 가장 중요한 신호는 유지관리자 업무량이다. 이 파일이 저품질 제출을 늘리지 않으면서 반복적인 수정을 줄인다면, 실질적인 목적을 달성한 것이다.
다듬어진 에이전트 출력이 기여자들이 설명할 수 없는 패치를 더 많이 보내도록 부추긴다면, 링크는 표현을 개선하면서 검토 부담은 악화시킬 수 있다. 그런 결과는 제안의 핵심 전제를 약화할 것이다.
유지관리자는 기여자가 기여 표기를 정직하게 사용하는지도 지켜봐야 한다. Assisted-by 관례는 사람들이 이를 유지할 때만 가치가 있다. 생성 과정에서의 자동 준수는 누군가 제출 전에 커밋을 수정하는 일을 막을 수 없다.
Linux 밖의 프로젝트들도 결과를 주시할 것이다. 커널은 가장 눈에 띄고 까다로운 협업 코드베이스 중 하나이므로, 에이전트 지침을 다루는 방식은 패치가 기술적으로 아주 작더라도 상징적 무게를 가진다.
그 영향력을 보편적 정책과 혼동해서는 안 된다. 더 작은 저장소, 상업 팀, 위험 프로필이 다른 프로젝트는 더 상세한 지침 파일, 도구별 구성, 자동화된 게이트, 또는 특정 생성형 기여의 금지를 택할 수 있다.
커널의 접근법이 주목할 만한 이유는 병렬 개발 프로세스를 구축하지 않기 때문이다. 대신 에이전트를 이미 사람에게 적용되는 프로세스로 되돌려 보낸다.
엔지니어링 팀에 주는 즉각적인 교훈은 발견 가능성과 권한을 분리하는 것이다. 에이전트가 읽을 수 있는 문맥은 올바른 명령과 제약을 식별할 수 있다. 테스트, 검토, 소유권, 승인 시스템은 여전히 작업을 강제해야 한다.
이러한 경계를 문서화하는 팀은 engineering knowledge base를 통해 기술적 문맥을 검색 가능하게 유지할 수도 있다. 핵심은 여러 에이전트 파일에 규칙을 복사하는 대신, 유지되는 하나의 소스를 노출하는 것이다.
향후 몇 달 동안 패치 이력, 실제 AI 지원 제출물, 유지관리자의 반응을 지켜봐야 한다. 이 신호들은 Linux kernel AGENTS.md 지침이 피할 수 있는 잡음을 줄이는지, 아니면 그 잡음이 도착하는 방식을 표준화할 뿐인지를 보여줄 것이다.
저장소 유지관리자는 비슷하게 구체적인 질문을 던져야 한다. 반복되는 에이전트 실수 중 어떤 것은 문맥 부족에서 비롯되고, 어떤 것은 강제 가능한 통제를 필요로 하는가? 도구가 찾을 수 있는 곳에 안정적인 지침을 두고, 이후 행동이 바뀌는지 측정하라. Markdown 파일로 증명할 수 없는 모든 일의 책임은 사람의 검토에 맡겨야 한다.
