개발 도구가 직접 작업을 수행하는 환경에서는 사내 규정의 위치보다 작동 방식이 중요해진다. 사람이 필요할 때 찾아 읽는 지침만으로는 빠르게 이어지는 변경을 일관되게 다루기 어렵다.
AGENTS.md 하나로는 부족하다
AI가 코드를 빠르게 만들수록 개발의 병목은 작성에서 검토로 옮겨간다. Anthropic은 2026년 5월 자사 코드의 90% 이상을 Claude가 작성한다고 밝혔고, Microsoft의 사티아 나델라도 일부 저장소와 프로젝트에서는 코드의 20~30%가 AI 생성물이라고 추정했다. 코드가 늘면 설계 원칙과 보안 기준을 확인할 일도 함께 늘어난다.
DORA는 이를 ‘검증 부담’이라고 부른다. AI가 만든 코드를 검토하고 검증하는 데 드는 추가 시간과 비용을 가리키는 말이다. 개발자의 약 30%는 AI 생성 코드를 신뢰하지 않는다고 답했다. 결국 기준과 절차가 잘 잡힌 팀은 AI로 더 빨라지지만, 그렇지 않은 팀은 검토와 재작업만 늘어난다.
예컨대 Cloudflare에도 표준은 있었다. 다만 문서, 저장소, 채팅, 개인의 경험에 흩어져 무엇이 최신인지 알기 어려웠다. 저장소 안의 AGENTS.md가 이 문제를 일부 줄인다. AGENTS.md는 코딩 에이전트가 저장소를 열 때 자동으로 읽는 지침 파일이다. 10개 저장소와 124개 PR(코드 변경, 병합 요청)을 비교한 실험에서는 작업 시간 중앙값과 출력 토큰이 모두 감소했다.
하지만 파일 하나에 모든 규칙을 담기는 어렵다. 파일이 길어지면 효과가 줄고 추론 비용이 늘어난다는 관찰도 있다. 저장소마다 파일을 따로 두면 소유자와 발효 시점, 유효 여부를 관리하기도 어렵다. 사람이 찾기 힘든 규칙을 AI가 제대로 쓰겠는가.
경고할 규칙과 차단할 규칙
이에 Cloudflare는 각 문서에 담당 영역과 상태를 표시하고 요구사항을 MUST와 SHOULD로 나누는 방식으로 사내 표준을 RFC 형식으로 통합했다. MUST는 의무이며 SHOULD는 합당한 이유가 있으면 예외를 허용하는 권고다.
RFC는 초안, 승인, 강제의 세 단계를 거치며 승인된 규칙은 위반만 알려준다. 담당자가 강제 단계로 올린 MUST만 머지를 막는다. 규칙을 확정한 뒤에는 오탐과 현장 영향을 살펴볼 시간을 둔다.
도입 후 약 4개월 동안 리뷰 에이전트는 약 23만 건을 지적했지만 실제로 머지를 막은 건 1만6,000건이었다. 차단 비율은 약 7%에 불과했다. 모든 지적을 차단 규칙으로 만들면 오탐까지 장애가 된다. 예를 들어 한 AI 리뷰 도구 업체는 주당 200~400개 코멘트 중 70~90%가 무시되고, PR 머지 시간이 6시간에서 2~3일로 늘어난 사례를 보고했다.
Cloudflare는 규칙마다 고유한 식별자도 붙였다. 이 식별자로 위반과 예외 승인을 추적한다. 프론트엔드, 보안, 신뢰성, 언어별 표준에는 각각 오너가 있으며, 강제 전환도 이들이 직접 결정한다.
긴 문서 대신 필요한 규칙만
Cloudflare는 리뷰할 때 RFC 전문을 모델에 넣지 않는다. MUST와 SHOULD 문장만 뽑아 식별자, 위치, 강도, 원문 링크를 담은 JSON 목록으로 만든다. 리뷰 에이전트는 관련 항목부터 확인하고 설명이 더 필요할 때만 원문을 읽는다. 형식은 달라도 원본은 하나다.
입력이 길다고 판단이 정확해질까. 핵심 정보가 긴 글 중간에 있으면 정확도가 떨어진다. 18개 주요 모델을 분석한 연구에서도 입력 한계에 닿기 전부터 모델마다 성능이 불규칙하게 낮아졌다. 필요한 영역과 요구사항만 먼저 좁히는 편이 비용과 누락을 줄인다.
또한 기계적으로 판정 가능한 규칙은 LLM에서 뺀다. Cloudflare는 TypeScript 규칙을 oxlint 기반 린터로 옮겼고 Rust 지원도 개발 중이다. 수 분이 걸리는 에이전트 리뷰와 달리 린터는 밀리초 안에 같은 검사를 반복한다. 로컬과 CI(지속적 통합 과정)에 같은 판정을 적용하면 코드를 올리기 전에 문제를 고칠 수 있다.
이 표준은 코드에만 쓰이지 않는다. 스펙과 사고 보고서 리뷰어도 필요한 규칙을 골라 쓴다. 스펙 600건에는 3,200회 넘게 호출됐고 사고 보고서도 200건 이상 평가했다. 규칙 하나를 고치면 설계, 구현, 사고 분석의 기준이 함께 바뀐다.
예외의 기록이 운영 수준을 말한다
정책은 여전히 사람이 정한다. 에이전트는 승인된 결정을 여러 저장소와 검토 과정에서 반복할 뿐이다. RFC 저장소를 상태, 오너, 변경 이력을 담은 단일 원본으로 두고 AGENTS.md와 도구별 규칙 파일은 어댑터로 써야 한다. 도구가 바뀌면 어댑터만 교체하면 된다.
규칙의 식별자는 예외 승인, 감사 기록, 오탐 집계, 효과 측정을 연결한다. 새 규칙은 먼저 경고로 운영한다. 위반 빈도와 오탐률, 머지 시간을 확인한 뒤 차단으로 바꾼다. 린터나 타입 시스템(코드의 값과 연산 종류를 검사하는 체계)으로 옮길 만한 규칙도 계속 분리한다.
이때 성과를 코멘트 수로 재면 될까. 수정 수용률, 오탐률, 머지 시간으로 봐야 한다. 각 조직은 최소 30일 동안 자체 지표를 측정한 뒤 차단 범위를 정하는 편이 안전하다.
규제 요구도 같은 방식으로 관리한다. EU AI Act의 부속서 III 독립형 고위험 시스템 의무는 원래 2026년 8월 2일 적용 예정이었지만 2026년 5월 잠정 합의에서는 2027년 12월 2일로 미루는 방안이 제시됐다. 이 유예 방안은 2026년 7월 Regulation (EU) 2026/1744로 정식 채택됐다. 규제 항목에도 식별자와 상태, 승인 이력을 붙이면 일상적인 검토 기록이 감사 자료가 된다.
자동화가 늘어도 규칙 작성자와 도메인 오너, 강제 전환 책임자, 예외 승인자는 필요하다.
누가 만들고 언제 적용하며 어디까지 강제할지를 관리하는 실행 체계가 AI 시대의 사내 표준을 지탱한다.
결국 도구의 성능이 달라져도 조직이 어떤 결정을 유효한 규칙으로 인정했는지는 별개의 문제다. 자동화의 범위가 넓어질수록 규칙의 수보다 변경과 예외가 남긴 기록이 조직의 운영 수준을 더 잘 보여준다.