당신의 오픈 소스 프로젝트도 아마 지난 몇 달 사이에 AI 기여 정책 (AI-contribution policy)을 추가했을 것입니다. Apache도 있고, Linux Foundation도 있습니다. OpenSSF 기술 자문 위원회(Technical Advisory Council)는 현재 재단 전체에 적용될 정책을 마무리하고 있습니다. Bitcoin Core, ripgrep, uv, 그리고 수십 개의 더 작은 프로젝트들도 이 패턴을 복제했습니다. 만약 당신이 인기 있는 프로젝트를 관리하고 있다면, 이미 정책을 작성했거나 곧 작성하게 될 것입니다.

거의 모든 정책은 다음과 같은 세 가지 내용의 변형된 버전을 담고 있습니다: AI를 사용할 때 공개할 것; 인간이 모든 변경 사항을 검토하고 책임을 져야 함; 완전히 자율적인 에이전트(agent)의 PR(Pull Request) 금지.

이것들은 좋은 규범입니다. 하지만 저는 불편한 점을 지적하고 싶습니다: 작성된 그대로라면, 이들 중 실행 가능한(enforceable) 정책은 거의 없다는 것입니다. 이들은 CONTRIBUTING.md에 적힌 산문(prose)일 뿐이며, 산문은 신사협정(honor system)에 불과합니다. 그래서 저는 그 격차가 실제로 얼마나 큰지 찾아보았습니다.

에이전트 PR이 대규모로 수행하는 실제 작업

저는 공개 GitHub 저장소(Devin, Copilot coding agent, Codex, Claude Code, Cursor)에서 최근 병합된, 에이전트가 작성한 2,204개의 풀 리퀘스트(pull requests)를 스캔했습니다. 이 스캔은 결정론적(deterministic)이며 체크아웃이 필요 없는(checkout-free) 방식입니다. GitHub API를 통해 PR 메타데이터와 파일 내용을 읽으며, PR 코드를 절대 실행하지 않고 LLM을 호출하지도 않으므로 모든 결과는 재현 가능합니다. 세 가지 결과가 이러한 정책을 작성하는 모든 이에게 직접적으로 관련이 있습니다:

2,204개 중 변경 사항에 대해 기계로 확인 가능한 범위(machine-checkable scope)를 선언한 사례는 0건이었습니다. 낮은 수치가 아니라, 0건입니다. 당신의 정책이 "인간이 모든 변경 사항을 검토하고 이해해야 한다"라고 말할 수는 있지만, 에이전트 PR을 여는 검토자가 갖게 되는 것은 인간의 PR을 검토할 때와 정확히 같습니다: diff(차이점)와 산문으로 작성된 설명뿐입니다. 에이전트는 자신에게 주어진 작업이 무엇인지 정확히 알고 있었습니다. 하지만 그러한 의도(intent) 중 그 어떤 것도 기계가 대조하여 확인할 수 있는 형태로 PR에 남아있지 않습니다. 따라서 "모든 변경 사항을 검토하라"는 실현 가능하지만, "변경 사항이 의도와 일치하는지 확인하라"는 아직 당신에게 불가능한 영역입니다.

3.9%의 수정된 에이전트 제어 평면 (control-plane) 파일 — AGENTS.md, CLAUDE.md, .mcp.json, .cursor/rules/** 및 이와 유사한 파일들입니다. 이 파일들은 저장소 내에서의 미래 에이전트 실행을 조종하는 파일들입니다. 자신의 지침을 수정하는 에이전트 PR(Pull Request)은 조용한 권한 상승 (privilege-escalation) 경로이며, 정확히 지루한 문서 차이(docs diff)처럼 읽혀 검토 과정을 무사히 통과할 법한 종류의 변경 사항입니다. 대부분의 정책은 이러한 파일 클래스를 전혀 언급하지 않습니다.

CI 워크플로 (workflows)를 건드린 PR 중 약 13%는 GitHub Actions 권한을 상향 조정했으며, 약 17%는 고정되지 않은 액션 (unpinned actions)을 도입했습니다. 귀하의 DCO (Developer Certificate of Origin) 및 저작권 표기 (attribution) 문구는 워크플로 파일 내의 contents: read -> write 변경을 절대 잡아낼 수 없습니다. 이것은 라이선스 문제가 아니라 공급망 (supply-chain) 문제입니다. 또한 저작권에 관한 정책 부분에서는 보이지 않는 영역입니다.

방향을 어디로 정해야 할지 결정하기 위해 한 가지만 더 덧붙이자면: 별(star)이 10,000개 이상인 저장소는 롱테일 (long tail) 저장소의 약 절반 수준의 발견율을 보였습니다 (4.3% 대 8.6%). 기성 프로젝트들은 가드레일 (guardrails)을 갖추고 있습니다. 가장 큰 타격을 입고 있는 프로젝트들은 작고 초보자 친화적인 프로젝트들입니다. 즉, 방금 산문 형태의 정책을 도입했으며 이를 뒷받침할 검토 여력이 가장 적은 바로 그 저장소들입니다.

(전체 방법론, 모든 쿼리, 그리고 가공되지 않은 접근 방식은 공개되어 있습니다: https://github.com/sjh9714/mergewarden/blob/main/docs/study/methodology.md — 발견 사항은 검토 증거일 뿐, 취약점이나 부정행위 주장이 아닙니다. 저는 집계된 데이터만 게시하며 특정 저장소의 이름은 밝히지 않습니다.)

실제로 검토 가능한 정책 조항은 무엇인가

여기 유용한 재구성이 있습니다. 귀하의 정책을 사람들이 따르기를 희망하는 조항과 기계가 검토할 수 있는 조항으로 나누십시오:

마지막 행이 흥미로운 지점입니다. 만약 에이전트 PR이 자신이 수정하려는 의도가 무엇인지에 대해 아주 작은 기계 판독 가능 (machine-readable) 선언을 포함하고 있다면, "범위 내에 머물렀는가"는 검토자의 추측이 아닌 결정론적 (deterministic) 검사 항목이 됩니다.

<!-- ai-contract
version: 1
agent: codex
...

솔직히 말해서, 저는 이것이 특정 도구의 기능이 되기보다는 벤더 중립적인 (vendor-neutral) 관례가 되는 것을 보고 싶습니다. 에이전트 벤더들은 이미 생성 시점에 작업 컨텍스트 (task context)를 가지고 있습니다. 하지만 그 무엇도 이를 PR (Pull Request)로 전달하지 않습니다. 그것이 바로 이 모든 정책들이 가진 공백입니다.

핵심 요점

만약 AI 기여 정책 (AI-contribution policy)을 작성하고 있다면, 산문 형태의 규범 (prose norms)은 그대로 유지하세요. 그것들은 중요합니다. 하지만 명예 시스템 (honor-system)에 의존하는 조항과 저렴하고 결정론적인 (deterministic) 검사로 실제로 강제할 수 있는 조항을 분리하고, 두 번째 그룹을 CI (Continuous Integration)에 연결하십시오. 노력 대비 효과 (bang-for-effort)가 큰 순서대로 우선 추가해야 할 세 가지 검사는 다음과 같습니다: (1) 제어 평면 (control-plane) 편집 (AGENTS.md / .mcp.json / rules 파일)에 대해 필수적인 인간 검토를 위해 플래그 (flag)를 지정할 것; (2) base 대 head의 diff 워크플로 권한을 비교하여 권한 상승 (escalation)이 발생하는 경우 플래그를 지정할 것; (3) 브랜치/작성자별로 자율 에이전트 (autonomous-agent) PR을 감지하여, 이미 제한적인 검토 대역폭 (review bandwidth) 내에서 추가적인 정밀 조사를 받을 수 있도록 할 것.

이 중 그 어떤 것도 LLM (Large Language Model)을 필요로 하지 않으며, PR 코드를 체크아웃할 필요도 없고, 모두 지루하고, 재현 가능하며, 비용이 들지 않습니다. 정책은 사람들에게 무엇이 기대되는지를 알려주지만, 검사는 그것이 지켜지지 않았을 때를 알려줍니다.

저는 이러한 검사들을 GitHub Action으로 수행하는 오픈 소스 도구 (MergeWarden, MIT)를 만들었으며, 이것이 위의 수치들을 만들어냈습니다. 하지만 여러분이 직접 작성한 몇 줄의 CI를 포함하여 무엇을 사용하든 논점은 동일합니다. 핵심은 "내 것을 채택하라"가 아닙니다. 그것은 다음과 같습니다: 당신의 정책은 산문이며, 에이전트 PR은 소방 호스처럼 쏟아져 나오고, 당신의 정책 중 강제 가능한 절반은 생각보다 작고 자동화 비용도 저렴하다는 것입니다.