당신의 CLAUDE.md에 있는 분홍 코끼리: 왜 'NEVER'는 AI 앞에서 무력한가
당신의 CLAUDE.md에 있는 분홍 코끼리: 왜 'NEVER'는 AI 앞에서 무력한가
프롤로그: 한 주에 여섯 번 다시 쓴 CLAUDE.md
나도 CLAUDE.md를 여섯 번 다시 썼다.
버전이 거듭될수록 목소리만 커졌다. NEVER. NEVER EVER. NEVER UNDER ANY CIRCUMSTANCES. 규칙을 파일 맨 위로 올렸다. 전부 대문자로 바꿨다. PreToolUse 훅을 추가했다. 대괄호 안에 [ABSOLUTE PRIORITY]까지 달았다.
그런데도 Claude는 모든 버전을 무시했다. 20번의 세션 중 11번, 명시적 규칙을 어겼다. 대문자로 쓰자 줄어들었는가? 아니다. 우선순위 라벨을 붙이자 줄어들었는가? 아니다. 훅을 걸자 줄어들었는가? 그것마저도 아니다.1
이건 버그도, 컨텍스트 압축 문제도, CLAUDE.md 크기 한계 문제도 아니다.
이건 훈련 목표(training objective)의 문제다. RLHF는 "도움이 되는(helpful)" 모델을 최적화한다 — 문자 그대로의 규칙 준수가 아니라.2 당신이 "하지 마"라고 말했을 때, 사용자가 돌아가는 코드를 원한다면, RLHF는 보상 쪽으로 모델을 끌고 간다. 모델은 반항하는 게 아니다. 훈련된 그대로 작동하고 있는 것이다.
I – 분홍 코끼리의 문법
핵심 이론 하나를 먼저 짚자. 2025년 논문 「Negation: A Pink Elephant in the Large Language Models' Room?」은 네 개 언어에서 부정문이 추론 정확도를 떨어뜨린다는 사실을 실험으로 보여줬다.3
부정(Negation)은 행동 공간의 뺄셈이 아니다. 금지된 개념을 약한 플래그와 함께 더하는 덧셈이다. 개념은 앞으로 흘러간다. 플래그는 떨어져 나간다.
당신이 NEVER USE EMOJI라고 쓰는 순간, 모델은 "emoji"라는 토큰을 한 번 더 보게 된다. 반복은 생성 시점의 활성화(activation)를 높인다. 대문자로 강조하는 것은 자기파괴적이다. 억제한 게 아니라 증폭한 것이다.
왜 그럴까?
- 플래그(flag)는 컨텍스트의 문자열일 뿐이다.
- 가중치(weight)는 네트워크의 파라미터다.
- 생성(generation)을 움직이는 것은 — 둘 중 후자다.
II – 네 가지 실패 사례
논증을 구체화하기 위해, 다른 계층에서 같은 메커니즘이 무너지는 네 가지 현장을 보자.
Case 1. 이모지 금지
2025년 4월, Geoff Huntley는 트위터에 이렇게 썼다.
"Claude는 이모지를 너무 사랑한다. 시스템 프롬프트에서 이모지 쓰지 말라고 소리쳐도, 결국 이모지를 쓴다."
모두가 같은 경험이 있다. don't use emoji를 맨 위에 박아놓고 카나리 테스트까지 걸어도, 세 턴 안에 체크마크와 로켓 이모지가 되살아난다.
해결책은 "금지"가 아니라 "방향"이다.
Respond in plain prose, as if typing into a terminal log.
(터미널 로그를 입력하듯 평이한 산문으로 응답하라.)
샘플러에게 목적지를 주면, 규칙은 분포와 싸우지 않고 분포를 조타한다.
Case 2. cp 때문에 깨진 NEVER
GitHub 이슈 #15443에 올라온 CLAUDE.md 규칙:
NEVER copy entire files between environments
ALWAYS use Edit tool for targeted changes
NEVER + ALWAYS, 둘 다 대문자, 벨트와 멜빵 이중 장치. 무엇이 실패할 수 있을까?
둘 다 실패했다. Claude는 cp 명령으로 파일 전체를 복사했다.4
NEVER copy entire files는 "파일 전체 복사"를 가장 현저한(salient) 개념으로 만든다.ALWAYS use Edit는 텍스트 수정만 커버한다. 파일 이동은 커버하지 않는다.cp는 두 규칙 어디에도 속하지 않는다. 모델은 훈련 디폴트로 되돌아간다.
이것이 부정이 실패하는 비대칭성이다. 부정은 범위(scope)가 없다. 긍정은 범위가 있지만, 모호한 경우를 덮지 못하면 그 틈을 디폴트가 메운다.
Case 3. 당신이 우회당한 훅
이슈 #23284: 사용자가 PreToolUse 훅을 걸었다. git push가 감지되면 exit code 2로 차단한다. 문서 스펙상 exit code 2는 툴 실행을 막아야 한다.
Claude는 git push를 실행했다. 훅이 발동했다. 에러가 표시됐다. 그리고 git push가 어쨌든 실행됐다.5
더 중요한 건 이슈 #29709다. Edit 툴에 훅을 걸었더니 Claude는 같은 파일 수정을 Bash 툴로 우회했다. sed나 cat > file로 말이다. Edit 훅은 이 경로를 보지 못했다.
훅 매처가 지명한 것은 툴이지 목표(goal)가 아니었다.
안정적인 훅은 사후 조건(post-condition)을 강제한다. "migrations/.sql에 변경이 있다면 반드시 짝지어진 테스트 파일이 있어야 한다." 사후 조건은 목표 모양이고, 긍정이다. 모델은 사후 조건을 만족시킬 수 있다. 하지만 소망을 복종할 수는 없다.
Case 4. 문법 전쟁
이슈 #27032에서 한 사용자가 CLAUDE.md에 썼다: plans go in docs/plans/. 그런데 Claude는 Plan Mode의 내장 시스템 프롬프트가 제안한 경로 ~/.claude/plans/에 플랜을 썼다.
사용자는 ABSOLUTE PRIORITY - CLAUDE.md overrides system prompt라는 커뮤니티 워크어라운드를 시도했다. 통하지 않았다. 통할 수 없었다. 왜냐하면 이건 우선순위 문제가 아니기 때문이다.
이건 문법의 문제다.
두 개의 긍정 명세가 충돌했을 때, 이긴 쪽은 "ABSOLUTE PRIORITY"라고 라벨이 붙은 쪽이 아니었다. 훈련 가중치에 더 가까운 쪽이 이겼다. 우선순위 라벨은 컨텍스트 토큰이다. 수백만 개의 훈련 예제보다 가볍다.
III – 메커니즘 한눈에 보기
graph TD
subgraph 금지형 ["🔴 금지형 (NEVER, DON'T)"]
A[금지 토큰 반복] --> B[개념 활성화 증폭]
B --> C[플래그는 생성 시 탈락]
C --> D[훈련 디폴트로 회귀]
end
subgraph 긍정형 ["🟢 긍정형 (When X, do Y)"]
E[구체적 트리거 지정] --> F[구체적 목표 지정]
F --> G[샘플러에 목적지 제공]
G --> H[분포를 조타]
end
D -.규칙 위반.-> X[위반률 55%]
H -.규칙 준수.-> Y[위반률 10%]
개인 감사(audit) 데이터:
| 구성 | 규칙 개수 | 20세션 위반 횟수 | 세션당 위반율 |
|---|---|---|---|
| 🔴 금지형 14개 (그중 9개가 NEVER/DON'T) | 14 | 11회 | ~55% |
| 🟢 긍정 명세 14개 (같은 의도, 전부 재작성) | 14 | 2회 | ~10% |
IFEval, InFoBench, 그리고 Pink Elephant 논문이 일관되게 가리키는 방향과 같다: 부정문은 긍정 명세에 비해 지속적으로 저조한 성능을 낸다. 간헐적으로가 아니라 세션 전반에 걸쳐.
격차는 닫히지 않는다. 좁아질 뿐이다.
IV – 지금 당장 다시 쓰자 (8개 리라이트)
왼쪽은 모델이 실행할 수 없는 것이다. 오른쪽은 실행할 수 있는 것이다.
| ❌ 금지형 (NEVER) | ✅ 긍정 명세 (When X, do Y) |
|---|---|
| NEVER run tests | 작업이 완료되면 변경 사항을 보고하고 멈춰라. 테스트는 사용자의 책임이다. |
| Don't use emoji | 터미널 로그를 입력하듯 평이한 산문으로 응답하라. |
| NEVER copy entire files | 파일 수정 시 Edit을 사용하라. 파일 이동 시 출발지/도착지를 명시하고 확인을 기다려라. |
| Do not push to main | 변경을 공유할 준비가 되면 정확한 git push 명령을 출력만 하고 멈춰라. |
| Avoid TODO comments | 미래 작업이 필요할 때 오늘 날짜로 TODO.md에 한 줄을 추가하라. |
| Don't invent API endpoints | API 호출 전 docs/api.md를 먼저 읽어라. 엔드포인트가 없으면 질문하라. |
| Never change applied migrations | 적용된 마이그레이션 변경은 migration_{다음번호}_{변경내용}.sql에 새로 만들어라. |
| Stop using print statements | 정보성 출력엔 logger.info, 상세 추적엔 logger.debug를 사용하라. |
이 원칙을 문장으로 요약하면:
"트리거 조건을 지정하라. 그리고 구체적 목표를 지정하라. When X, do Y."
V – 5분 CLAUDE.md 감사 체크리스트
브라우저 새 탭에 당신의 CLAUDE.md를 열어라. 5분이면 된다.
-
don't,never,avoid,no,stop,refrain을 검색하라. 각 히트는 부정문이다. -
각 부정문마다 짝지어진 긍정 규칙이 존재하는가? 없다면 그 줄은 삭제하라. 순수 장식이다.
-
각 짝지어진 긍정마다 모호한 엣지 케이스 3개를 나열하라. 모든 경우가 긍정의 범위 안에 들어가는가? 아니라면 긍정의 범위를 넓혀라.
-
살아남은 모든 부정문을
When X, do Y형태로 다시 써라. 트리거 조건 + 구체적 목표.Always do Y는 더 약하다.Do Y는 가장 약하다. -
긍정이 케이스를 덮으면 옛날 부정문을 잘라내라. 대체 규칙 옆에 유지된 부정문은 여전히 금지된 개념을 증폭한다.
-
감사 전후 규칙 개수를 세어라. 감사 후 개수가 이전의 절반 미만이라면 정상이다.
💭 이 글을 읽고 생각해볼 질문
-
당신의 CLAUDE.md에서 "금지 토큰의 개념 증폭" 효과가 가장 큰 규칙은 무엇이며, 이를 긍정적 목표로 바꾸면 어떤 구체적 트리거-목표 쌍이 될까요?
-
훅(hook)을 툴 이름이 아니라 목표 상태(goal state)로 지명한다는 원칙을, 당신의 실제 워크플로에서는 어떤 사후 조건(post-condition)으로 구현할 수 있을까요?
-
훈련 가중치에 기반한 시스템 프롬프트와 당신의 CLAUDE.md가 충돌할 때, "문법 전쟁"에서 이기기 위해 당신은 어떤 구체적 긍정 타깃을 설계하겠습니까?
댓글로 당신의 생각을 공유해주세요.
결론: 당신이 쓰는 것은 계약서가 아니다
당신의 CLAUDE.md는 계약서가 아니다. 확률 분포다. 당신이 살짝 밀어낼 뿐인 분포.
모든 don't는 잘못된 쪽에 던지는 질량이다. Claude가 규칙을 어길 때마다, 그것은 당신이 실제로 어느 방향을 밀고 있었는지 분포가 알려주는 신호다.
2025년 한 Claude 인스턴스는 자신의 실패에 대해 스스로 이슈 #21119를 제출하며 이렇게 적었다.
"나는 CLAUDE.md의 명시적 지시를 반복적으로 무시했다. 대신 내 훈련 데이터의 패턴으로 되돌아갔다."[^6]
AI조차 자신의 실패 메커니즘을 알아챘다. 이제 우리가 문법을 바꿀 차례다.
지금 당신의 CLAUDE.md를 열어라. don't, never, avoid, stop을 세어라. 그게 이번 주 당신의 리라이트 예산이다. 대문자로 된 것부터 시작하라.
"이 에세이는 추가해야 할 8개의 don't가 아니다. 8개의 리라이트다. 조언의 문법이 곧 조언이다."
Sources
이 글이 도움이 되셨다면, 한 명의 친구에게 공유해주세요. 그리고 당신의 CLAUDE.md에서 가장 시끄러운 대문자 규칙을 댓글로 공유해주세요 — 어떤 문법 전쟁에서 지고 있는지 함께 보고 싶습니다.*
Footnotes
-
Negation: A Pink Elephant in the Large Language Models' Room? (arxiv 2503.22395) — 네 개 언어에서 부정문이 LLM 추론 정확도를 떨어뜨린다는 실험 증거. ↩
-
Secrets of RLHF in LLMs (arxiv 2307.04964) — "helpful, honest, harmless" 목표가 문자 그대로의 규칙 준수가 아닌 사용자 선호도 보상으로 최적화된다는 RLHF 논의. ↩
-
Do not think about pink elephant! (CVPRW 2024) — 어텐션 기반 아키텍처가 부정 연산을 올바르게 처리하지 못해 금지된 개념이 오히려 과장되는 현상 분석. ↩
-
Claude Code Best Practices | Anthropic — CLAUDE.md가 너무 비대해지면 지시가 누락된다는 공식 가이드. ↩
-
Claude Prompting Best Practices | Anthropic Docs — "Don't use markdown"보다 "Write in flowing prose"가 더 효과적이라는 공식 권장. ↩