"커밋하기 전에 전체 테스트 스위트를 실행하라"와 같은 규칙은 AI 코딩 에이전트가 마지막 테스트 실행 후 소스 파일을 수정하고 git commit을 호출하기 전까지는 단순해 보입니다. 커널(Kernel)은 커밋 객체를 작성하는 일반적인 프로세스를 보는 반면, 하네스(Harness)는 또 하나의 도구 호출(Tool call)을 봅니다. 하지만 그 결정은 어떤 테스트 결과가 여전히 최신인지, 어떤 수정이 테스트를 무효화했는지, 그리고 현재 이 커밋이 허용되는지에 달려 있습니다.

ActPlane 논문은 개발자가 작성한 행동 규칙(Behavioral rules)과 시스템이 실제로 확인할 수 있는 하위 집합 사이의 간극을 측정합니다. 2,116개의 명령(Instruction)에 대한 문장 수준 분석(Statement-level analysis) 결과, 개발자들에게 규칙이 부족한 것이 아님을 보여줍니다. 어려움은 자연어 요구사항을 시스템이 시간에 따라 관찰하고 평가할 수 있는 상태(State)로 전환하는 데 있습니다. 많은 규칙이 파일, 프로세스 또는 네트워크 활동과 관련이 있지만, 여전히 저장소 구조, 작업 진행 상황 또는 이전 이벤트에 의존하므로 단일 OS 훅(OS hook)만으로는 정책 세트의 일부만 커버할 수 있습니다.

개발자들은 이미 정책을 작성했습니다

AI 에이전트 안전성에 관한 대부분의 논의는 위협 모델(Threat models)이나 공격 표면(Attack surfaces)에서 시작됩니다. ActPlane은 다른 질문에서 시작합니다. 개발자들이 이미 에이전트에게 무엇을 하고 무엇을 하지 말라고 지시하고 있는지, 그리고 그 지시사항을 집행(Enforce)하려면 무엇이 필요한가 하는 점입니다.

이 연구는 CLAUDE.md 및 AGENTS.md 파일을 포함하는 64개의 인기 있는 저장소(GitHub 스타 중앙값 20K, 2026-05-23 스냅샷)를 조사하며, 84개의 명령 파일과 2,116개의 개별 문장을 다룹니다. 명령 파일을 파일 또는 섹션 헤딩 수준에서 분석했던 이전 연구와 달리, ActPlane은 모든 문장을 독립적으로 분류합니다. 이 연구는 세 가지 질문을 던집니다. 명령 파일은 주로 행동 정책(Behavioral policies)인가 아니면 기술적 컨텍스트(Descriptive context)인가? 어떤 정책이 OS 수준의 집행을 필요로 하며, 어떤 종류의 OS 수준 체크가 필요한가? 이러한 정책을 구체적이고 집행 가능한 규칙으로 인스턴스화(Instantiate)하기 위해 어떤 컨텍스트가 필요한가?

문장(Statements)들은 소스 라인 범위와 문장당 4가지 레이블(콘텐츠 유형, 주제, 집행 수준, 컨텍스트 요구사항)을 기록하는 2단계(two-pass) LLM 에이전트 지원 파이프라인을 통해 추출되었습니다. 검증 스크립트를 통해 전체 소스 커버리지와 축자적 범위 일치(verbatim span matching)를 확인하였으며, 이후 두 개의 독립적인 에이전트(Claude 및 Codex)가 결과를 교차 검증했습니다. 100개의 문장으로 구성된 층화 표본(stratified sample)에 대해 독립적인 인간 검토를 수행하였으며, 이를 통해 레이블이 정확함을 확인했습니다.

이 2,116개의 문장 중 64%는 특정 에이전트 동작을 요구, 금지 또는 조건화하는 정책(policies)입니다. 나머지 36%는 아키텍처 노트나 프로젝트 배경과 같은 기술적 컨텍스트(descriptive context)입니다. 정책 밀도는 리포지토리(repositories)에 따라 0%에서 97%까지 매우 다양하게 나타나며, 리포지토리의 70.1%가 기술적 문장보다 정책 문장을 더 많이 포함하고 있습니다. 파일 또는 헤딩(heading) 수준의 연구들은 이러한 문장 수준의 분포를 보고하지 않으므로, 더 세밀한 분류가 중요합니다.

정책이 관심사별로 어떻게 분포하는지 이해하기 위해, 본 연구는 이전의 지침 파일(instruction-file) 연구에서 조정된 12가지 주제 카테고리에 각 문장을 할당하였으며, 이를 파일 단위가 아닌 문장 단위(statement granularity)로 적용했습니다. 개발 프로세스(Development Process)와 구현 세부 사항(Implementation Details)이 각각 87%와 85%로 정책 환경을 지배하고 있습니다. 아키텍처(Architecture)는 대부분 23%의 기술적 성격을 띠는데, 이는 디렉토리 레이아웃과 설계 요약이 해당 섹션의 대부분을 차지하기 때문입니다. 가져온 소스(imported source)는 정책 문장을 지시 사항(directives)이라 부르고, 시스템 관찰 가능 정책(system-observable policy) 하위 집합을 시스템 수준 지시 사항(system-level directives)이라 부릅니다. 본문은 논문의 정책 및 시스템 관찰 가능(system-observable) 용어를 따릅니다.

데이터셋에서 추출한 5개의 실제 문장은 집행 요구사항의 범위를 잘 보여줍니다:

집행 격차는 컨텍스트에서 시작된다

각 정책은 집행 폭포 (enforcement waterfall)의 첫 번째로 일치하는 계층(tier)에서 실행됩니다. Semantic-only (의미론적 전용)는 추론, 통신 또는 출력 스타일을 다루며, content (콘텐츠)는 파일 내용에 대한 술어 (predicates)를 다룹니다. per-event (이벤트별)는 단일 명령, 파일 액세스 또는 네트워크 연결을 다루고, cross-event (이벤트 간)는 작업 전반에 걸친 시간적 순서나 데이터 계보 (data lineage)에 의존하는 정책을 다룹니다. content, per-event, cross-event 계층의 합집합을 system-observable (시스템 관찰 가능)이라고 부릅니다.

데이터셋의 1,361개 정책 중 semantic-only는 17%에 불과합니다. 나머지 83%는 system-observable이며, 이 중 38%는 콘텐츠 검사 (content inspection)가 필요하고, 29%는 하나의 OS 이벤트를 매칭하며, 16%는 cross-event 상태를 필요로 합니다. per-event와 cross-event 클래스, 즉 합계 45%만이 OS-enforceable (OS 집행 가능) 하위 집합을 형성합니다. cross-event 정책은 Development Process (개발 프로세스)에 집중되어 있으며, 이는 모든 cross-event 정책의 39.5%를 차지합니다.

이러한 cross-event 정책들은 네 가지 반복되는 패턴을 따릅니다. Temporal ordering (시간적 순서)은 시퀀싱을 제한합니다: "커밋하기 전에 테스트를 실행하라"는 단순히 이전 시점에 무언가가 발생한 것이 아니라, 한 이벤트가 다른 이벤트 이후에 발생해야 함을 요구합니다. Cross-file consistency (파일 간 일관성)는 아티팩트(artifacts) 간의 변경 사항을 연결합니다: "동작이 변경되면 문서를 업데이트하라"는 소스 편집을 문서 업데이트와 결합합니다. Multi-step workflows (다단계 워크플로우)는 검증 게이트 (verification gates)가 있는 릴리스 체크리스트를 집행하며, 여기서 각 단계는 다음 단계가 시작되기 전에 반드시 완료되어야 합니다. Conditional triggers (조건부 트리거)는 작업을 결합합니다: "사양(specs)을 변경하면 SDK도 업데이트하라"는 전제 조건이 충족될 때만 실행됩니다.

이러한 정책들 중 어느 것도 단일 이벤트만으로는 결정될 수 없기 때문에, 강제(enforcement) 시스템은 무엇이 실행되었는지, 어떤 순서로 실행되었는지, 그리고 그 이후로 무엇이 변경되었는지를 기록해야 합니다. 이러한 정책들은 광범위하게 사용되는데, 리포지토리의 81%가 최소한 하나의 교차 이벤트 정책을 포함하고 있으며, 43%는 네 가지 강제 계층 전체에 걸쳐 적용됩니다.

컨텍스트 의존성은 강제 시스템의 난이도를 더욱 높입니다. 총 1,127개의 시스템 관찰 가능(system-observable) 정책 중 자체적으로 완결된(self-contained) 것은 26.4%에 불과합니다. 대다수인 64.2%는 프로젝트 컨텍스트를 필요로 합니다. 즉, 정책이 구체적인 규칙이 되기 위해서는

프롬프트 지침 (Prompt instructions)은 모델 자체의 준수 여부에 의존하지만, 프롬프트 인젝션 (prompt injection)에 취약하며 긴 컨텍스트 창 (context window) 내에서 사용자의 작업 프롬프트와 주의력 (attention)을 두고 경쟁합니다. 별도의 에이전트나 LLM 가드 (LLM guards)는 런타임 (runtime)에 프롬프트, 응답 또는 행동 궤적 (action trajectories)을 확인할 수 있지만, 이러한 검사는 본질적으로 확률적 (probabilistic)입니다.

도구 호출 가드레일 (Tool-call guardrails)과 애플리케이션 수준의 정보 흐름 제어 (IFC, information-flow control) 시스템은 하네스 경계 (harness boundary)에서 결정론적 (deterministically)으로 가로채지만, 이들은 하네스를 통해 매개된 요청만을 관찰할 뿐, 도구가 실행을 시작한 이후의 시스템 수준의 효과는 관찰하지 못합니다. 간접적인 서브프로세스 (subprocess), 쉘 아웃 (shell-out), 또는 컴파일된 바이너리 (compiled binary)는 도구 경계를 우회할 수 있습니다. subprocess.run(["git", "push"])를 포함하는 Python 스크립트를 작성하고 이를 실행하는 에이전트를 가정해 봅시다. 도구 호출 계층은

두 가지 설계 요구사항이 뒤따릅니다. 정책 명세(policy specification)는 에이전트가 작성할 수 있으면서도 운영체제(OS)에 의해 강제될 수 있어야 합니다. 그래야 에이전트가 최소한의 전문 지식만으로 자연어 정책으로부터 구체적인 규칙을 생성할 수 있고, 위반 사항을 이해하고 복구하기 위한 의미론적 피드백(semantic feedback)을 받을 수 있기 때문입니다. 또한 집행(enforcement)은 안전하고, 격리되어 있으며, 효율적이어야 합니다. 즉, 에이전트가 작성한 정책이 상위 권한에 의해 설정된 제약 조건을 약화시켜서는 안 되며, 다른 에이전트의 정책에 영향을 주어서도 안 되고, 에이전트의 정상적인 작업 부하를 저하시켜서도 안 됩니다.

의도를 강제 가능한 상태로 컴파일하기

각 ActPlane 규칙은 다섯 가지 구성 요소를 가집니다: 무엇을 관리할지 식별하는 소스(source), 대상 작업(target operation, 예: exec, write, 또는 connect), 효과(effect), 선택 사항인 시간 게이트(temporal gate), 그리고 의미론적 피드백을 위한 이유 문자열(reason string)입니다. 논문의 실행 예시는 이를 구체적으로 보여줍니다:

kill exec "git" "commit" unless after exec "go" "test" exits 0 since write "**/*.go"

이 규칙은 가장 최근의 관련 소스 수정 이후 go test가 성공적으로 종료되지 않았다면 모든 git commit을 중단(kill)시킵니다. 간결함을 위해 여기서는 생략되었지만, 이유(reason) 필드는 규칙이 발동될 때 에이전트에게 구조화된 설명을 제공합니다.