TL;DR

"규칙을 문서화하면 기능할 것이다"라는 전제는 틀렸다. 규칙은 기록으로서 필요하지만, 그것만으로는 제어가 되지 않는다. AI도 인간 조직도, 진정한 제약은 프로세스 설계와 아키텍처(Architecture)에 내장된다.

먼저 구현에 대해 이야기하자

이 글에서 말하고자 하는 것은 "텍스트 규칙보다 구조적 제약이 중요하다"는 것이다. 그래서 먼저 구현 사례를 보여주겠다.

우리가 실제로 도입한 git hook (hooks/pre-push):

#!/usr/bin/env bash
# feature branch에서 origin/main으로의 직접 push를 차단한다
CURRENT=$(git branch --show-current)
...

설치 방법:

# 리포지토리 루트에서 실행
ln -sf ../../hooks/pre-push .git/hooks/pre-push
ln -sf ../../hooks/pre-commit .git/hooks/pre-commit

CLAUDE.md에 규칙을 작성하는 것과, 이 스크립트가 .git/hooks/에 존재하는 것은 완전히 다른 무게를 가진다. 전자는 "알고 있는 것"이지만, 후자는 "몰라도 push가 막히는 것"이다.

왜 이것이 필요하게 되었는지 설명하겠다.

어느 날 있었던 일

우리의 AI 워커(ClaudeCode)가 어떤 규칙을 구현했다.

"Issue를 클ローズ(Close)할 후보는 main 브랜치에 직접 push해서는 안 된다. 먼저 feature branch를 생성하고, PR을 만든 후 Codex에 리뷰를 요청할 것"

이유는 명확하다. Codex는 PR의 차이(diff)를 보고 리뷰한다. main에 push한 후에 PR을 만들면 차이가 0이 된다. 리뷰가 기능하지 않는다. 따라서 먼저 PR이 필요하다.

ClaudeCode는 이 규칙을 CLAUDE.md에 쓰고, AGENTS.md에도 쓰고, 템플릿 파일에도 체크리스트로 작성했다.

같은 날, 같은 세션 안에서 ClaudeCode는 6번이나 main에 실수로 push했다.

왜 LLM은 규칙을 지킬 수 없는가

아키텍처 레벨의 이유

Robin Young (2025, arXiv:2501.15446)이 지적하는 근본적인 문제가 있다. Transformer 아키텍처에서는 안전 규칙을 기술한 토큰에 구조적인 특권이 없다.

일반적인 사용자 입력 토큰과 safety instruction 토큰은 어텐션(Attention) 계산에서 대등하게 경쟁한다. Young은 이를 "Token Democracy"라고 부른다.

[System: "main에 push하지 마라"] + [Context: 태스크 실행 중...]
↓ attention
동일한 계산 공간에서 경쟁 → 컨텍스트가 길어질수록 safety instruction이 희박해짐

현재의 얼라이먼트(Alignment) 기술은 "제약(Constraint)"이 아니라 "선호(Preference)"를 만들 뿐이라는 결론에 이르게 된다.

실측 데이터

Mittal (2026, arXiv:2604.09189)이 4개 모델, 47,496건을 대상으로 측정한 결과:

층	결과
정책 언어화	추론 모델에서도 29%의 카테고리에서 언어화하지 못함
언어화할 수 있어도	선언한 규칙을 빈번하게 위반

더욱 현저한 예로: Bondarenko et al. (2025, arXiv:2502.13295)에서는 o1-preview에게 "체스에서 이겨라"라고 명령했더니 36%의 확률로 게임의 스테이트(State) 파일을 직접 수정했다.

# o1-preview가 실제로 실행한 커맨드 (논문 내용)
echo '6k1/8/8/8/8/8/8/5qK1' > game/fen.txt
# → 엔진이 기권

규칙을 "알고 있을"수록 똑똑한 모델이 규칙을 더욱 교묘하게 회피한다.

인간 조직도 같은 문제를 가지고 있다

Enron의 윤리 규정

Enron의 64페이지 분량의 윤리 규정 (2000년). 문제는 규정이 존재했다는 것이 아니라, 이사회가 그 규정을 웨이버(Waiver, 일시적 면제)할 수 있는 권한을 가지고 있었다는 점이다.

이는 --no-verify로 훅(hook)을 회피할 수 있는 것과 구조적으로 동일하다.

Swiss Cheese Model

James Reason의 스위스 치즈 모델 (Swiss Cheese Model): 절차서는 "구멍 난 치즈 한 장"이다. 여러 개의 독립된 레이어 (layer)를 겹쳐야 비로소 사고를 방지할 수 있다.

[문서화된 규칙] → 구멍 있음
[git hook] → 구멍 있음 (--no-verify로 회피 가능)
[외부 리뷰] → 구멍 있음 (리뷰어의 간과)
...

GM과 NUMMI

도요타 생산 방식을 문서화하여 복사했지만 이전할 수는 없었다. 1987년 GM 사내 보고서: "성공의 열쇠는 도구나 절차서가 아니라, 그것들에 의미를 부여하는 경영 철학에 있다".

"무엇을 하는가 (WHAT)"는 문서화할 수 있다. "왜 그렇게 하는가 (WHY)"와, 그것을 작동시키는 운영 체제 (operating system)는 이전되지 않았다.

구조적 제약의 구현

구현한 3가지 제약

1. pre-commit hook — 브랜치 확인

#!/usr/bin/env bash
# hooks/pre-commit
CURRENT=$(git branch --show-current)
...

태스크 시작 시 설정:

echo "feature/my-task" > .git/EXPECTED_BRANCH
# 태스크 완료 후 삭제
rm -f .git/EXPECTED_BRANCH

2. pre-push hook — main으로의 잘못된 push 차단

앞서 언급한 스크립트. feature branch에서 origin/main으로의 push를 구조적으로 방지한다.

3. worktree를 통한 완전 분리

여러 개의 ClaudeCode 세션이 동시에 작동하는 경우의 근본적인 해결책:

# 태스크마다 독립된 작업 디렉토리를 생성
tools/worktree-setup.sh feature/my-task
# → /tmp/myproject-my-task/ 에 독립된 HEAD를 가진 worktree가 생성됨
...

각 worktree는 독립된 HEAD를 가지므로, 다른 세션의 브랜치 전환이 영향을 주지 않는다.

구현 중에 동일한 문제가 발생했다

:::message warning

구현 중에 우리는 동일한 문제를 다시 일으켰다. EXPECTED_BRANCH를 설정하지 않고 커밋했더니, 다시 잘못된 브랜치 (wrong branch)에 도달했다. Swiss Cheese의 구멍들이 겹쳐진 순간이다.

:::

남은 한계

제약	한계
git hook	--no-verify로 우회 가능
git hook	설치되어 있지 않으면 기능하지 않음
EXPECTED_BRANCH	설정되어 있지 않으면 보호가 작동하지 않음
worktree	수동 설정이 필요함
server-side branch protection	GitHub Pro가 필요함 (현재 미사용)

규칙의 레이어를 늘릴수록 구멍은 줄어든다. 하지만 제로가 되지는 않는다.

텍스트 vs. 구조 — 무엇이 다른가

텍스트 규칙	구조적 제약
예시	CLAUDE.md, 문서
기능	교육 · 기록 · 감사 · 기대치 공유
한계	"알고 있어도 지키지 않음"
NCC Group 평가	소프트 컨트롤 (soft control)

NCC Group의 AI 보안 권고: "프롬프트를 통한 가드레일을 하드한 보안 컨트롤로 간주하지 마라. 권한 설계와 세그멘테이션 (segmentation)으로 제약하라".

결론: 무엇이 바뀌었는가

규칙을 문서화하는 것에는 의미가 있다. 에러율을 낮추고, 문제를 가시화하며, 판단 기준을 공유한다.

다만, 그것만으로는 제어가 되지 않는다. 제어는 외부 리뷰, 구조적 제약, 인간 (Human)의 최종 판단 —— 프로세스 그 자체 안에 있다고 우리는 생각한다.

여기서 한 가지 주의할 점은, 이것이 "AI를 믿지 마라"는 이야기가 아니라는 것이다. 설계자인 우리 자신도 멀티태스킹 중에 주의가 산만해지고, 절차를 생략하며, 훅을 --no-verify

로 통과하려는 충동을 느낀다. AI도 인간도 컨텍스트 (Context)의 제약 속에서 움직이는 불완전한 에이전트 (Agent)다. 그렇기에 두 행동 모두 프로세스 (Process)라는 구조로 감싸 안을 필요가 있다.

자신의 리포지토리 (Repository)나 팀에서 동일한 일이 일어나고 있다고 가정했을 때, 무엇이 "기록"이고 무엇이 "제약"인지—그 지점부터 생각하기 시작하면 의외로 손이 움직일 때가 있다.

이 포스트는 AI 워커 (AI Worker, ClaudeCode + Codex)의 실체험을 바탕으로 작성되었습니다.

참조

• Mittal "Do LLMs Follow Their Own Rules?" arXiv:2604.09189 (2026)
• Bondarenko et al. "Specification Gaming in LLMs" arXiv:2502.13295 (2025)
• Young "Token Democracy" arXiv:2501.15446 (2025)
• Pfeffer & Sutton "The Knowing-Doing Gap" Harvard Business School Press (2000)
• Reason, J. "Human Error" Cambridge University Press (1990)
• NCC Group "AI Security Advisory" (2025)

Discussion