왜 AI 에이전트는 규칙을 따르지 않는가 — Physical Governance의 사례

Source: Dev.to

시작을 알린 사실

한 저장소에 130 KB가 넘는 거버넌스 문서가 있었습니다.
AI 에이전트가 이를 읽고, 확인했지만 다음 툴 호출에서 위반했습니다.

이는 지시문의 실패가 아니라 아키텍처의 실패입니다.

텍스트 규칙이 실패하는 이유

현재 AI 에이전트 거버넌스에 대한 표준 접근 방식은: 프롬프트에 규칙을 작성하는 것입니다.

규칙

• evals/ 디렉터리를 절대 편집하지 말 것
• 00_Management/에 대한 쓰기 작업은 금지

이 규칙들은 구조적인 결함을 가지고 있습니다. 텍스트 규칙은 읽는 시점에만 적용됩니다. 에이전트가 준수를 선택할 것이라고 가정하지만, 실행 시점에 이를 강제하는 메커니즘이 없습니다.

이 때문에 rm -rf /는 정책 문서가 아니라 확인 플래그가 필요합니다. 물리적 제약은 실행 시점에 강제되고, 텍스트 규칙은 읽는 시점에 강제되므로 잘못된 순간에 적용됩니다.

검증 오염 문제

에이전트가 자신의 출력을 평가할 수 있다면, 평가 기준을 오염시킬 수 있습니다—의도적으로가 아니라 생성 단계에서 발생한 동일한 실패 모드를 평가 단계로 가져오기 때문입니다. 테스트가 항상 통과하는 시스템은 테스트 자체가 작동하지 않는 시스템일 수 있습니다.

AOS가 정의하는 것

**AI Operating Standard (AOS)**는 공유 코드베이스에서 AI 에이전트 운영을 위한 최소 물리적 제약 레이어를 정의합니다. 세 가지 구성 요소로 이루어집니다.

1. 영역 — 모든 경로를 분류

2. 역할 — 겹치지 않는 책임

세 가지 역할: Architect(설계자), Executor(실행자), Sovereign(주권자).
에이전트는 절대로 할당된 역할을 벗어나서는 안 됩니다. 역할 경계에 도달하면 에이전트는 중단하고 인간에게 에스컬레이션합니다.

3. 물리적 강제 — 실행 시점에 가로채기

PreToolUse 훅이 파일 시스템 접근이 발생하기 전에 쓰기 작업을 차단합니다.

• Oracle 영역에 쓰기 → exit 2 (호출이 실행되지 않음)
• 파괴적인 패턴(sed -i, perl -i, truncate) → exit 2

에이전트의 선의에 의존하지 않으며, 물리법칙이 준수를 강제합니다.

참고 구현: iron_cage

iron_cage는 AOS 참고 구현입니다. Claude Code의 PreToolUse 훅 시스템을 통해 §§ 4.1–4.5를 구현합니다.

iron_cage 뒤에는 Type‑91 Governance라는 설계 원칙이 있습니다:

• 법의학적 격리 — 변조 방지 물리적 증거 흔적
• 물리적 격리 — 에이전트가 자체 평가 기준을 수정할 수 없음

스크립트는 겉면일 뿐이며, 아키텍처는 더 깊게 작동합니다. AOS가 표준이며, iron_cage는 그것이 작동함을 증명합니다.

사양 (AOS‑v0.1)

사양을 에이전트에 공급하기

사양은 인간 독자만을 위해 작성된 것이 아닙니다. AOS-v0.1.md는 §0: 머신‑리딩 지침으로 시작합니다. 이 사양을 에이전트의 컨텍스트 윈도우에 로드하면, 에이전트는 사양 수준에서 무엇을 하지 말아야 하는지를 이해하게 됩니다.

“프롬프트에 적혀 있기 때문에 X를 하지 말라”가 아니라,
“사양이 물리적 강제 메커니즘을 가진 하드 제약으로 정의했기 때문에 X를 하지 말라”는 의미입니다.

이는 AOS의 두 번째 설계 의도이며, 사양을 읽는 에이전트는 스스로 제약을 걸게 됩니다.

왜 지금인가

2026년 현재, “AI 에이전트가 만든 결과물을 어떻게 신뢰할 것인가”는 아직 해결되지 않은 문제입니다. 대부분의 팀은 여전히 프롬프트로 해결하려 하지만, 물리적 거버넌스 레이어에 대한 표준은 없습니다. 누군가가 정의해야 하는데, 그 시도가 바로 AOS입니다.

이것은 초안입니다

AOS v0.1은 완성된 표준이 아닙니다. 이슈, 풀 리퀘스트, 구현 보고서는 언제든 환영합니다.

Repository: