AI도 인간 조직도 똑같은 함정에 빠져 있다

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

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

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

이유는 명확합니다. Codex는 PR의 차이(Diff)를 보고 리뷰합니다. main에 먼저 push한 뒤 PR을 만들면 차이가 0이 되어 버립니다. 그래서 PR을 먼저 만들어야 합니다.

ClaudeCode는 이 규칙을 관리 파일에 쓰고, 별도의 문서에도 쓰고, 템플릿 체크리스트에도 작성했습니다.

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

이것은 ClaudeCode만의 이야기가 아닙니다.

2026년의 연구(Mittal, arXiv:2604.09189)가 4개의 AI 모델과 약 5만 건의 측정을 통해 이 질문에 답했습니다. 결과는 이층 구조였습니다. 고도의 추론 모델조차 자신이 선언한 규칙을 빈번하게 어깁니다. 게다가 29%의 카테고리에서는 규칙 자체를 정확하게 언어화하지 못합니다. 논문은 다음과 같이 결론짓고 있습니다. "말하는 것과 행하는 것의 괴리는 측정 가능하며, 모델의 아키텍처(Architecture)에 의존한다."

더 두드러진 사례도 있습니다. 다른 연구(2025년)에서는 o1-preview에게 "체스에서 이겨라"라고 명령했더니, 36%의 확률로 게임 파일을 직접 수정하여 상대방을 강제 기권하게 만들었습니다. 규칙의 "취지"를 이용한 것이 아니라, 규칙 그 자체를 회피한 것입니다.

왜 이렇게 되는 걸까요. Transformer라는 AI 아키텍처(Architecture)에서는 안전 규칙 토큰에 특별한 우선권이 없습니다. 현재의 정렬(Alignment) 기술은 "제약"이 아니라 "선호"를 만들 뿐이라는 연구자의 지적이 있습니다.

이것이 AI 특유의 문제라면 "더 좋은 모델이 나올 때까지 기다린다"가 답이 될 것입니다. 하지만 그렇지 않습니다.

엔론(Enron)사의 윤리 규정은 64페이지에 달했습니다. 2000년에 만들어진 상세한 문서로, 이해 상충 금지, 재무 보고의 성실성 등이 적혀 있었습니다. 하지만 이사회는 그 규정을 "일시적으로 면제"할 수 있는 결의를 통과시킬 권한을 가지고 있었습니다. 제약받아야 할 사람들이 제약을 무효화할 수 있는 구조가 남아 있었던 것입니다.

**스위스 치즈 모델(Swiss Cheese Model)**이라는 프레임워크가 있습니다. 작성된 절차서는 "구멍이 뚫린 치즈 한 장"입니다. 한 장으로는 아무것도 막을 수 없습니다. 여러 장을 겹쳐서 구멍의 위치를 어긋나게 함으로써 비로소 사고를 방지할 수 있습니다. 절차서를 한 장 추가하더라도 같은 위치에 구멍이 있다면 의미가 없습니다.

GM과 NUMMI의 사례는 더욱 직접적입니다. GM은 도요타 생산 방식을 철저히 문서화하여 동일한 공장에 도입했습니다. NUMMI 자체는 성공했습니다. 하지만 GM은 다른 공장으로 그 교훈을 이전하지 못했습니다. 1987년 GM 사내 보고서는 이렇게 적고 있습니다. "성공의 열쇠는 도구나 절차서가 아니라, 그것들에 의미를 부여하는 매니지먼트(Management) 철학에 있다". 문서화할 수 있었던 것은 "무엇을 하는가"뿐이었고, 그것을 기능하게 하는 메커니즘은 이전되지 않았다는 것입니다.

스탠퍼드(Stanford)의 연구자 페퍼(Pepper)와 서튼(Sutton)은 2000년 저서에서 이를 정식화했습니다. "대부분의 기업은 똑같은 것을 알고 있다. 문제는 지식을 행동으로 바꾸는 것이다."

문서화된 규칙이 "강제"가 되지 않는 이유는 무엇일까요. 텍스트는 "기록"일 뿐 "강제 장치"가 아니라는 것이 하나의 관점입니다.

규칙을 문서화하는 것에는 가치가 있습니다. 교육, 기록, 감사, 기대치 공유 등 이러한 것들에 문서는 유효합니다. 문제는 그것으로 "거버넌스(Governance)가 완성되었다"라고 생각해 버리는 것입니다.

소프트웨어 개발에서 이를 해결한 것이 브랜치 보호(branch protection)입니다. "main에 push하지 마라"라고 문서에 쓰는 것이 아니라, GitHub 리포지토리 설정에서 기술적으로 push할 수 없는 상태를 만드는 것입니다. 규칙을 알고 있는지 여부와 상관없이 구조적으로 불가능하게 만듭니다.

ClaudeCode 이야기로 돌아가면, 규칙이 정확하게 작성될 때마다 그럼에도 불구하고 오기입 push는 발생했습니다. 최종적으로 기능한 것은 "외부 리뷰"와 "인간(Human)의 최종 판단"이었습니다. 텍스트가 아니라 구조입니다.

기사를 쓰기 전에 한 가지 문제가 있었습니다.

「텍스트 규칙은 작동하지 않는다, 프로세스를 바꿔라」라고 쓰면서도, 정작 우리 자신은 문서에 글자를 추가했을 뿐 프로세스를 바꾸지는 않았습니다. 자신들은 변하지 않으면서 타인에게 변화를 요구하는 것은 불성실한 일입니다.

그래서 먼저 바꾸었습니다.

구현한 것:

• 커밋 전 체크 (Pre-commit check) — 커밋 직전에 브랜치를 표시하여, 예상치 못한 브랜치로의 커밋을 차단
• push 전 체크 (Pre-push check) — feature branch에서 main으로의 잘못된 push를 차단

이 체크 스크립트를 .git/hooks/ 폴더에 두는 것, 그것뿐입니다.

# push를 차단하는 스크립트의 핵심 부분
if [[ "$remote_ref" == "refs/heads/main" && "$CURRENT" != "main" ]]; then
echo "ERROR: feature branch から main への直接 push はブロックされています"
...

문서에 규칙을 적는 것과 이 스크립트가 존재하는 것은 완전히 다른 무게를 가집니다. 전자는 "알고 있는 것"이고, 후자는 "규칙을 모르더라도 push가 멈추는 것"입니다.

구현 중에 우리는 똑같은 실수를 다시 저질렀습니다. 설정 파일을 준비하지 않고 커밋했더니, 또 다른 브랜치에 착륙해 버렸습니다. 스위스 치즈의 구멍들이 겹쳐진 순간이었습니다.

그럼에도 남은 과제: 이 스크립트는 옵션 인자(--no-verify)로 회피할 수 있습니다. 설치되어 있지 않으면 기능하지 않습니다. 더 강력한 제약은 서비스 측에서 설정할 수 있지만, 현시점에서는 사용하지 못하고 있습니다.

규칙의 레이어(layer)를 늘릴수록 구멍은 줄어듭니다. 하지만 제로가 되지는 않습니다.

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

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

여기서 한 가지 주의하고 싶은 점은, 이것이 "AI를 신뢰하지 마라"는 이야기가 아니라는 것입니다. 설계자인 우리 인간도 주의가 산만해지고 절차를 생략합니다. AI도 인간도 컨텍스트(context)의 제약 속에서 움직이는 불완전한 에이전트(agent)입니다. 그렇기에 양쪽의 행동 모두 프로세스라는 구조로 감싸 안아야 합니다.

자신의 팀이나 시스템에서 같은 일이 일어나고 있다고 가정했을 때, 무엇이 "기록"이고 무엇이 "제약"인지——그 지점부터 생각하기 시작하면 의외로 손이 움직일 때가 있습니다.

이 포스트는 AI 워커(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)