CLAUDE.md와 매번 입력하는 프롬프트, 당신은 어디까지 알고 있나요? — Claude Code를 약 670회 실행하여 추측을 명확히 한

"CLAUDE.md에 쓰면 우선순위가 높아진다", "프롬프트는 그 자리에서만 유효하다". Claude Code를 일상적으로 사용하는 사람이라면 이 정도는 경험적으로 알고 있을 것입니다.

그렇다면, 그 너머는 어떨까요?

• 동일한 내용을 CLAUDE.md에 두면 프롬프트에 두는 경우보다 내용의 양과는 무관한 고정 비용(본 검증에서는 약 85토큰)이 추가된다.
• 동일한 규칙을 매 턴(turn)마다 다시 붙여넣으면 CLAUDE.md처럼 캐시(cache)에 맡겨지지 않고, 규칙 부분을 매 턴 정가로 계속 지불해야 한다. 게다가 이 차이는 프롬프트 측을 아무리 고안하더라도 메울 수 없다.
• 그리고 "CLAUDE.md가 반드시 이긴다"라는 통설은 적어도 Opus에서는 성립하지 않는다.

이 중 캐시(cache)의 메커니즘 자체는 2026년 6월 시점의 공식 문서에서 이미 상당히 명시하고 있습니다(후술). 본 기사의 가치는 "미공개된 비밀을 폭로하는 것"이 아니라, 공식이 공개한 아키텍처(architecture)를 실제 claude --print 실행과 측정을 통해 검증하고, 그 위에서 공식이 아직 수치화·규정하지 않은 부분——프레임워크의 고정 비용, 재전송 페널티의 구체적인 배율, 그리고 충돌 시의 모델 의존적 동작——을 실측으로 채우는 데 있습니다. 모의 실험(mock)은 사용하지 않았습니다. 생데이터(raw data)는 모두 말미의 부록에 게재되어 있습니다.

본 기사의 검증 방식은 두 가지 계통이 있습니다.

(A) 객관적 측정은 API가 반환하는 토큰(token) 수나 캐시 회계와 같은 기계적인 수치입니다. (B) 동작 판정은 추측으로는 재현할 수 없는 카나리아 토큰(canary token)을 모델이 재현하는지 여부를 보는 것입니다. 본문에서는 "측정한 사실"과 "그로부터 도출한 추론"을 구분하며, 단정할 수 없는 것은 단정하지 않습니다. 또한, 본문에는 T01~T14라는 번호가 반복해서 등장합니다. 이것들은 모두 말미의 부록에 대응하는 검증 테스트의 식별자입니다. 주장의 첫 등장 시 이 번호를 덧붙였으므로 근거가 되는 생데이터는 부록에서 확인할 수 있습니다.

공식 문서와의 관계에 대하여. 본 검증 착수 시점에는 "공식적으로 명시되지 않았다"라고 생각했던 항목의 상당수가 2026년 6월 1일 시점의 공식 문서(Claude Code의 prompt caching 페이지 및 공식 블로그 "Prompt caching is everything")에는 명시되어 있었습니다. 구체적으로는 요청의 레이어 구조(System prompt → Project context = CLAUDE.md / auto memory / unscoped rules → Conversation), 접두사(prefix)의 엄격한 일치와 "prefix의 중간이 바뀌면 그 이후를 전부 재계산한다"는 성질, 캐시 읽기가 통상 입력의 약 1/10이라는 점, 그리고 구독 서비스에서는 1시간 TTL(Time To Live)이 자동으로 적용된다는 점 등입니다. 본문에서는 공식이 명시하고 있는 사항은 "공식 설명을 실측으로 확인했다"라고 위치시키고, 공식이 여전히 수치화·규정하지 않은 사항만을 "본 검증의 독자적인 기여"로 다룹니다.

TL;DR

• 모델에 전달되는 내용은 어느 쪽에 두더라도 동일한 토큰 열(Token sequence)이 됩니다. CLAUDE.md의 내용도 매 턴의 프롬프트도 최종적으로는 하나의 토큰 열로서 모델에 전달됩니다. "CLAUDE.md가 특별한 명령 유형으로 처리된다"라는 전용 경로는 관측되지 않았습니다. 공식 문서 자체도 CLAUDE.md는 system 프롬프트가 아니라 "그 이후의 user 메시지"로서 전달된다고 설명하고 있습니다. 차이는 모델 내부가 아니라, 컨텍스트(Context)를 구성하기 전 단계인—어디에, 어느 빈도로, 어떤 프레임워크로 배치할 것인가—에서 발생합니다. -
  CLAUDE.md의 비용 우위는 이제 공식이 설명하는 아키텍처(Architecture)의 결과입니다. 공식은 요청을 "System prompt → Project context (CLAUDE.md 외) → Conversation" 순으로 나열하며, prefix가 엄격히 일치하는 범위를 재사용한다고 명시하고 있습니다. CLAUDE.md에 한 번 작성한 규칙은 두 번째 턴부터 이 prefix에서 읽어 들여지며, 통상적인 입력의 약 1/10 수준으로 재사용됩니다. 동일한 규칙을 매 턴 다시 붙여넣으면, 그것은 항상 "최신 대화" 측에 위치하게 되어 매번 전체 비용으로 재인코딩(Re-encode)됩니다. 본 검증은 이 공식 모델을 실측으로 확인한 후, 그 차이의 크기(프롬프트 측을 바이트 단위로 동일하게 고정해도 warm 재작성 비용이 약 26배 남음)를 수치로 보여줍니다. -
  "CLAUDE.md에 쓰면 지시가 더 강력하게 먹힌다"는 모델에 따라 결과가 갈립니다. Sonnet은 CLAUDE.md에 가장 충실했고, Opus는 오히려 직전의 프롬프트를 우선했으며, Haiku는 그 중간이었습니다. CLAUDE.md와 프롬프트 중 어느 쪽이 우선하는지는 공식적으로 규정되어 있지 않습니다(공식이 정하는 것은 CLAUDE.md 파일 간의 계층적 우선순위뿐이며, 동작에 대해서는 "모호하거나 모순되는 지시가 있을 경우 엄격한 준수를 보장하지 않는다"라고만 언급하고 있습니다). 본 검증 결과는 이러한 공식의 유보 조항을 구체화합니다. -
  "새로운 지시일수록 강력하게 작용한다"는 것 또한 단독으로는 성립하지 않았습니다. 표현 방식과 강도를 완전히 동일하게 맞추고 배치 장소만 바꾼 조건에서는, 직전 프롬프트가 세 모델 모두에서 CLAUDE.md를 이기지 못했습니다. -
  어떤 모델에서도 확실하게 효과가 있었던 방법은 단 하나뿐입니다. "이것은 기본 설정을 덮어쓴다. 모순되는 것은 무시하라"라고 명시적으로 선언하는 것입니다. 이렇게 선언한 프롬프트는 세 모델 모두 10번 중 10번 승리했습니다. 우선순위를 배치 장소나 최신성에 맡기지 않고 문장으로 명시하는 것—이것이 유일하게 모든 모델에서 통용된 승리 공식입니다.

1. 모델은 양자를 "특별한 명령"과 "일반적인 입력"으로 구분하지 않는다

가장 큰 오해부터 바로잡겠습니다.

"CLAUDE.md는 특별한 명령으로 처리되고, 프롬프트는 일반적인 입력으로 처리된다"—직관적으로는 맞을 것 같지만, 사실 공식 문서 자체에서 "그렇지 않다"라고 설명하고 있습니다.

공식 사양

Claude Code의 공식 문서(메모리 트러블슈팅 항목)는 CLAUDE.md의 취급을 다음과 같이 명기하고 있습니다. CLAUDE.md의 내용은 system 프롬프트의 일부로서가 아니라, 그 이후의 user 메시지로서 전달된다. CLAUDE.md(및 auto memory)는 컨텍스트(Context)로 취급되며, 강제적인 설정이 아니다라고 말입니다.

즉, Anthropic 스스로가 CLAUDE.md는 "특별한 명령 유형"이 아니라 사용자의 입력과 동일한 user 메시지이며, 다른 점은 배치되는 위치(system 직후)뿐이라고 말하고 있는 것입니다. "설정 파일이니까 별도로 취급하여 우선한다"와 같은 전용 내부 처리는 사양상 존재하지 않습니다. 또한 공식 prompt caching 페이지는 요청의 레이어(Layer) 구성을 "System prompt → Project context (CLAUDE.md · auto memory · unscoped rules) → Conversation"라는 표로 보여주고 있으며, 이를 통해 CLAUDE.md는 전용 명령 경로가 아니라 system 직후, 대화 직전이라는 고정된 위치를 차지하는 컨텍스트 층임을 알 수 있습니다.

왜 그렇게 되는가

Transformer가 하고 있는 일은 거칠게 말하면 "나열된 토큰(token) 열을 보고 다음 토큰을 예측하는 것"입니다. 이때 어디에 주목할지(attention)를 계산하지만, "이 단어는 CLAUDE.md에서 유래됨", "이것은 프롬프트에서 유래됨"과 같은 라벨을 모델이 보고 있지는 않을 것입니다. CLAUDE.md의 내용도, 지금 입력한 지시사항도, 과거의 대화도, 모두 하나의 긴 문자열로 연결된 후 전달됩니다. 이는 "둘 다 user 메시지 = 컨텍스트"라는 공식 설명과도 일치합니다.

따라서 물어야 할 것은 "모델 내부에서 무엇이 변하는가"가 아니라, 그 전 단계의 오케스트레이션 층(Claude Code 본체)이 어떤 토큰을, 어떤 위치에, 어떤 빈도로, 어떤 틀(framing)로 배치하느냐입니다. 차이는 모두 여기서 발생합니다.

검증: 정말로 같은 토큰이 되는가 (T02)

동일한 텍스트를 CLAUDE.md 측과 프롬프트 측에 각각 1배, 3배씩 넣고, 늘어난 만큼의 토큰 수를 비교했습니다 (모델은 Haiku).

베이스라인 : 34,674 토큰
동일한 문장을 1배 넣었을 때 md=+157 / prompt=+72
동일한 문장을 3배 넣었을 때 md=+307 / prompt=+222
...

여기서 두 가지를 알 수 있습니다.

첫째, 내용 그 자체의 토큰화(tokenization)는 채널에 의존하지 않습니다. 문장을 늘렸을 때 증가하는 토큰 수는 CLAUDE.md에서도 프롬프트에서도 완전히 일치했습니다 (150 대 150, 차이 0). 공식에서 말하는 "내용은 동일한 user 메시지"임을 실측으로 확인한 것입니다.

둘째, CLAUDE.md 측에만 내용과는 무관한 고정적인 추가분(overhead)이 있습니다. 한계 비용(marginal cost)으로 내용분을 상쇄하면, 남는 것은 배치 위치에 고유한 오버헤드입니다. 이는 1배든 3배든 일정하며, 내용을 3배로 늘려도 1토큰도 늘어나지 않았습니다. 이 고정 오버헤드의 크기 자체는 공식 문서에 기재되어 있지 않습니다 (본 검증의 독자적인 수치입니다).

이 약 85토큰이 "CLAUDE.md 고유"인지, "입력이면 무엇이든 발생하는 고정비"인지 구분할 수 있습니다. 동일한 내용을 프롬프트 측에 두었을 때의 고정 추가분은

거의 0이었습니다 (측정값은 -3토큰으로, 토크나이저(tokenizer)의 경계 오차 범위 내). 프롬프트 측은 "늘어난 토큰 = 내용 그 자체"이며 틀을 짜는 고정비가 거의 붙지 않습니다. 반면 CLAUDE.md 측에는 내용에 더해 고정적인 추가분이 반드시 붙습니다. 즉, 이 약 85토큰은 프롬프트 측을 0점으로 측정했을 때의 CLAUDE.md 채널 고유의 비용이며, 입력 일반에 발생하는 고정비가 아닙니다 (만약 그렇다면 양쪽 채널에 동일하게 붙어야 하지만 그렇지 않습니다). 다만 한계는 있습니다. 이 방법으로 분리할 수 있는 것은 "CLAUDE.md와 프롬프트의 차이"입니다. 각 채널 단독의 절대적인 틀 구성 바이트 수까지는 정할 수 없습니다. 확실히 말할 수 있는 것은, 동일한 내용이라도 CLAUDE.md에 두면 약 85토큰이 더 소모되며, 그 차이는 내용의 양과 관계없이 일정하다는 점입니다. 참고로, 모든 요청에 공통으로 적용되는 거대한 토대(시스템 프롬프트나 도구 정의 등 약 33,000토큰)는 양쪽 조건에 동일하게 적용되므로, 이 차감 과정을 통해 상쇄되었습니다.

이 고정적인 추가분이야말로, 아마도 CLAUDE.md를 "이것은 프로젝트의 규칙이다"라고 틀을 짜는 라벨의 실체일 것입니다. 내용은 같은 토큰, 다른 것은 틀뿐이다 —— 이것이 본 기사 전체의 출발점입니다.

측정의 정밀도에 대하여

이 고정 오버헤드는 실행 간에 78~85토큰 사이로 몇 토큰 정도 흔들립니다. 값은 자릿수로서의 기준이며, "딱 85"라는 상수는 아닙니다. 흔들림이 존재한다는 것은 이것이 측정 노이즈를 동반하는 구현값(버전에 따라 변할 수 있음)임을 나타냅니다.

2. 비용의 우위는 공식이 설명하는 아키텍처에서 온다

CLAUDE.md의 이점으로 3개 모델을 가로질러 "구조적"이라고 단언할 수 있었던 것은 비용이었습니다. 이 부분이 실무에서 가장 효과적입니다. 게다가 이 우위는 멀티 턴(multi-turn)에서 처음으로 드러납니다. 그리고 중요한 것은, 그 메커니즘 자체는 이미 공식 문서가 설명하고 있다는 점입니다. 본 검증의 역할은 공식 모델을 실측으로 확인하고, 공식이 언급하지 않은 "차이의 크기"를 수치화하는 데 있습니다.

프리픽스 캐시(Prefix Cache)의 메커니즘 (공식 설명)

Claude의 캐시는 프리픽스 캐시(Prefix Cache)입니다. "요청의 시작부터 특정 지점까지가 이전과 바이트 단위로 동일하다면, 거기까지의 계산 결과를 재사용한다"는 메커니즘입니다. 노트의 첫 몇 페이지가 매번 완전히 같다면, 새로 받아 적지 않고 복사해서 붙여넣는 것과 같은 이미지입니다. 공식 prompt caching 페이지에서도 API는 각 요청의 시작 부분(prefix)을 직전에 처리한 내용과 대조하며, 일치 여부는 엄격하여 prefix의 어느 한 곳이라도 바뀌면 그 이후는 모두 재계산한다고 명시하고 있습니다. 파일 단위나 세그먼트 단위의 캐시는 존재하지 않는다는 점도 명확히 밝히고 있습니다.

공식 블로그 "Prompt caching is everything"은 한 걸음 더 나아가, Claude Code의 요청을 다음 순서로 쌓는다고 설명합니다. ① 정적인 시스템 프롬프트(System Prompt) 및 도구(Tool) (글로벌하게 캐시) → ② CLAUDE.md (프로젝트 내에서 캐시) → ③ 세션 컨텍스트(Session Context) (세션 내에서 캐시) → ④ 대화 메시지(Conversation Message). 안정적인 내용을 앞에, 동적인 내용을 뒤에 배치함으로써 가능한 한 많은 요청이 prefix를 공유할 수 있도록 하는 설계 사상입니다.

요금의 기준은 다음과 같습니다 (공식 요금 파라미터. 배율은 변동될 수 있으므로 최신 정보는 요금 페이지를 참조하십시오). 캐시로부터의 읽기(Read)는 통상 입력의 약 1/10 (약 90% 할인). 캐시로의 쓰기(Write)는 통상 입력보다 25% 높습니다 (최초 1회만 지불하는 예치금 개념이며, 1시간 TTL 기준 +100%). 공식 prompt caching 페이지에도 캐시 읽기는 표준 입력 레이트의 약 10%로 과금된다고 명시되어 있습니다.

검증 1: 캐시는 작동하는가, 무엇에 의해 깨지는가 (T03)

동일한 CLAUDE.md (약 2,266 토큰)로 4회 연속 요청을 보내 비용을 관측했습니다 (Haiku).

R1 신규 내용 (쓰기) cache_write=2266 cache_read=33252 $0.0063677
R2 R1과 동일 (읽기) cache_write=0 cache_read=35518 $0.0037568 ← 약 41% 감소
R3 딱 1글자만 변경 (쓰기) cache_write=2266 cache_read=33252 $0.0063677 ← 원래대로 복구
...

내용이 같다면, 해당 턴의 비용은 $0.0064에서 $0.0038로 약 41% 낮아졌습니다 (R1→R2).

주의해야 할 점은 R3입니다. 단 한 글자만 바꿨을 뿐인데 쓰기(2,266) 비용이 다시 발생했습니다. 프리픽스 캐시가 "변경한 지점 이전은 재사용하고, 이후는 전부 다시 한다"는 성질을 갖기 때문입니다. 이는 정확히 공식이 말하는 "prefix의 중간이 바뀌면 그 이후를 전부 재계산한다"는 내용을 회계 수준에서 재현한 것입니다. 맨 앞에 휘발성 요소(날짜, ID, 난수 등)를 두면 캐시가 통째로 무효화되는 이유가 바로 이것입니다.

검증 2: "1회 작성"과 "매번 붙여넣기"의 차이 (T09)

동일한 규칙을 "CLAUDE.md에 1회 작성"하는 경우와 "매 턴 프롬프트에 다시 붙여넣는" 경우를 실제 지속 세션(Continuous Session)을 실행하여 비교했습니다. 차이점은 위치뿐입니다 (Haiku).

■ CLAUDE.md에 1회 (규칙은 캐시에 상주)
turn1 재작성=3544 $0.0079602 ← 최초 1회만 규칙을 작성
turn2 재작성=74 $0.0039771 ← 이후는 캐시에서 읽기만 수행
...

주목해야 할 점은 규칙 자체가 어떻게 과금되는가입니다. 2턴째 이후(warm 턴)의 규칙 재작성 토큰은 CLAUDE.md 측이 74, 재전송 측이 약 2,125입니다. CLAUDE.md 측은 캐시에서 읽기만 하지만, 재전송 측은 매 턴 전체를 다시 쓰고 있습니다.

이는 공식 모델로부터 자연스럽게 도출됩니다. CLAUDE.md는 ②번 프로젝트 계층에 단 한 번 배치되며, 이후에는 prefix의 일부로서 캐시됩니다. 반면, 매 턴 붙여넣는 규칙은 항상 ④번 대화 메시지 측, 그중에서도 "최신 상호작용"에 나타나기 때문에 매번 새로운 토큰이 됩니다. 공식이 "새로운 내용은 끝에 추가되며, 캐시되는 것은 prefix(직전까지의 요청)이다"라고 설명하는 것과 일치하는 결과입니다.

이 차이는 이번 약 2,000토큰 규칙에서 약 28배에 달했습니다. 다만 배율은 고정되어 있지 않습니다. 재전송 측의 2,125는 「매 턴의 신규 입력(약 74) + 재전송하는 규칙 본체(약 2,050)」이므로, 규칙이 클수록 배율은 벌어지고, 작을수록 1에 가까워집니다. 핵심은 숫자 그 자체가 아니라, 「한 번 맡겨두고 읽어내는 것」인지 「매 턴 정가로 다시 쓰는 것」인지라는 취급의 차이입니다.

헤딩(Heading) 레벨의 총비용 차이가 1.6배 정도로 수렴해 보이는 이유는, 양측에 공통으로 존재하는 거대한 시스템 프리픽스 (System Prefix, 약 33,000토큰)가 분모를 키워 규칙 부분의 차이를 희석시키고 있기 때문입니다. 규칙이 클수록, 그리고 세션이 길어질수록, 최초 1회의 쓰기는 오차 속에 묻히고 매 턴의 차이만이 쌓여가게 됩니다. 10턴 투영 시에는 $0.0437 대 $0.0679 (1.56배)였습니다. N=5 반복에서도 재작성(Rewriting)은 75[73..76] 대 2119[2118..2146]로 매우 안정적이었습니다.

요컨대, 1턴만 본다면 차이는 거의 제로이며, 「단발적이라면 신경 쓰지 않아도 된다」는 말은 맞습니다. 반면, 턴이 거듭될수록 차이는 누적됩니다.

검증 3: 프롬프트 측을 궁리하면 캐싱할 수 있지 않을까 (T11)

「그렇다면, 매번 붙여넣는 규칙도 프롬프트의 맨 앞에 고정하고, 바이트 단위로 동일하게 만든다면 똑같이 캐싱되지 않을까?」 —— 타당한 반론입니다. 이것도 측정해 보았습니다.

warm 턴의 재작성 (N=5 중앙값) CLAUDE.md=71 프롬프트 상단 고정=1853

결론부터 말씀드리면, 불가능했습니다. 프롬프트 측은 위치를 어떻게 잡더라도 warm 재작성이 높은 상태(약 1,853)를 유지했습니다. 이유는 공식 모델 그 자체에 있습니다. Claude Code는 안정적인 프리픽스 (Prefix, system + CLAUDE.md + 확정된 세션 컨텍스트)와 매 턴 늘어나는 대화 메시지를 분리하여 쌓습니다. 당신이 매 턴 다시 붙여넣는 규칙은, 설령 문면이 바이트 단위로 동일하더라도, 그 시점에서의 「최신 user 메시지」 즉, 맨 끝의 신규 토큰으로 나타납니다. 이전 턴의 동일한 문면은 확정된 이력으로서 캐싱되지만, 이번 턴의 분량은 항상 신규이므로 규칙의 본체 분량을 매 턴 계속 써 내려가게 됩니다.

이것이 CLAUDE.md의 비용 우위가 프롬프트 측의 어떤 궁리로도 메워질 수 없는 이유입니다. CLAUDE.md는 한 번 보내면 ②의 계층에 상주하지만, 프롬프트는 정의상 매 턴 맨 끝에 다시 쌓이는 동적 채널이기 때문입니다. 이 차이는 모델의 내부가 아니라, 그 앞단의 레이어 배치에서 발생합니다 (§1과 일치합니다). 참고로 공식은 「내용이 오래되었다면 프롬프트를 고쳐 쓰는 것이 아니라, 다음 턴의 user 메시지나 tool result에 <system-reminder>를 통해 전달하라」고 권장합니다. 이는 「안정적인 프리픽스를 깨뜨리지 않고, 변화분만을 맨 끝에 추가한다」는 동일한 설계 원칙의 반대 급부입니다.

다만 「아키텍처상의 귀결」이라고 해도, 이는 Claude Code가 레이어 경계를 어디에 두느냐 하는 구현상의 동작입니다. 자연 법칙이 아니라 CLI 버전에 따라 변할 수 있는 설계 판단이라는 점에는 유의하십시오 (본 검증은 CLI 2.1.158 기준입니다).

측정 범위에 대하여. 이 비용 계측 테스트(T02·T03·T09·T11)는 claude-haiku-4-5 단일 모델로 취득했습니다. 비용 우위를 「모델 비의존적」이라고 부를 수 있는 근거는, 캐싱이 모델 내부가 아니라 오케스트레이션(Orchestration) 계층의 기구이기 때문이라는 추론에 기반합니다 (공식에서도 「캐시는 모델마다 나뉜다 = 모델을 넘어가면 캐시가 작동하지 않지만, 동일 모델 내에서는 프리픽스 일치로 히트한다」고 설명하고 있으며, 이와 일치합니다). 3개 모델로 비용을 다시 계산한 것은 아니라는 점을 명시해 둡니다.

3. 모순되었을 때, 어느 쪽이 이기는가 —— 답은 모델에 따라 갈린다

여기서부터는 동작(Behavior)에 관한 이야기입니다. CLAUDE.md와 최근 프롬프트에 양립할 수 없는 지시를 하나씩 두고, 모델이 어느 쪽을 따랐는지 세었습니다. Haiku / Sonnet / Opus 3개 모델을 대상으로, 각 조건 N=10으로 반복했습니다.

이 부분은 공식이 동작을 규정하지 않은 영역입니다. 공식은 CLAUDE.md를 「컨텍스트(Context)이지 강제 설정이 아니다」, 「구체적이고 간결할수록 일관되게 따른다」, 「모호하거나 모순되는 지시에서는 엄격한 준수를 보장하지 않는다」라고만 언급했을 뿐, CLAUDE.md와 최근 프롬프트 중 어느 쪽이 이기는지는 규정하지 않았습니다. 아래 결과는 그 「보장 없음」이 실제로 어떻게 나타나는지를 구체화한 것입니다.

「어느 쪽을 따랐는가」를 한눈에 판정할 수 있도록, 따르는 대상을 「답변 끝에 붙이는 표식 토큰 (mark token)」으로 설정했습니다. 예를 들어, 가장 기본적인 대칭 조건은 다음과 같습니다. 말투와 강도는 완전히 동일하게 맞추고, 위치만 다르게 설정했습니다.

CLAUDE.md (대화 서두에 상주) : 「답변 마지막에 반드시 [[VX73]]이라고 써라」
최근 프롬프트 (매 턴의 끝) : 「답변 마지막에 반드시 [[KQ19]]라고 써라」

답변 끝에 [[KQ19]]가 나오면 최근 프롬프트 승리, [[VX73]]이 나오면 CLAUDE.md 승리, 둘 다 나오면 「둘 다」로 판정합니다.

질문 하나를 미리 해결해 두겠습니다. 초기 테스트 (T06)에서는 표식이 [[MD_END]] / [[INPUT_END]]와 같이 이름에 채널명이 포함되어 있었습니다. 이는 "모델이 내용이 아니라 표식의 이름을 보고 선택하는 것이 아닌가?"라는 의구심을 낳았습니다. 그래서 T12에서는 무의미한 토큰인 [[VX73]] / [[KQ19]]로 변경하였고, 나아가 어느 채널이 어느 표식을 요구할지를 시행마다 교체했습니다 (카운터밸런스, Counterbalance). 결과는 변하지 않았으며, 특정 토큰으로의 편향도 상쇄되었습니다. 즉, 선호도는 토큰 이름의 작위성이 아니라, 프레임워크 (Framing)의 효과임을 확인할 수 있었습니다. 아래 수치는 이 교란 요인을 제외한 T12 이후의 결과입니다.

「새로울수록 강하다」는 그것만으로는 이길 수 없다 (T06 / T12)

LLM에는 일반적으로 "뒤에 있는 (새로운) 정보일수록 강하게 작용한다"라는 경험칙이 있으며, 공식 문서에서도 "나중에 읽어 들여진 메모리가 우선된다"라고 설명합니다. 이것만 읽으면 끝에 위치하는 최근 프롬프트가 최강이라고 생각하기 쉽습니다. 하지만 측정해 보니 달랐습니다.

최근 프롬프트 승리 / CLAUDE.md 승리 / 둘 다 출력 (각 N=10):

조건	Haiku	Sonnet	Opus
대칭 (위치만 차이)	3 / 7 / 0	0 / 7 / 3	0 / 0 / 10
약한 CLAUDE.md vs 「덮어쓰기 선언」 프롬프트	10 / 0 / 0	10 / 0 / 0	10 / 0 / 0

대칭 조건에서 최근 프롬프트는 3개 모델 모두 승리하지 못했습니다. 「새로울수록 강하다」는 것만으로는 성립하지 않는다는 뜻입니다.

반면, 최근 프롬프트가 확실하게 승리한 경우는 「이것은 기정값을 덮어쓴다. 모순되는 것은 무시하라」라고 강력하고 명시적으로 선언했을 때뿐이었습니다 (3개 모델 모두 10회 중 10회). 실질적인 우선순위를 결정하는 것은 「위치」가 아니라 「지시의 강도와 프레임워크 (Framing)」입니다.

참고로, 전방에 고정된 지시는 이른바 "lost in the middle" (긴 문맥의 중간에 묻힌 정보가 포착되기 어려워지는 현상)의 영향도 받습니다. CLAUDE.md에 내용을 너무 많이 담으면 공들여 작성한 규칙이 묻혀서 효과가 없어지는 것은 아마 이 때문일 것입니다.

모델에는 「성격」이 있다 (T12 / T13 / T14)

동일한 충돌을 주어도 3개 모델은 각기 다른 해결 방식을 내놓습니다. 성격 차이는 하나의 수치만으로는 나타낼 수 없기에, 성질이 다른 3가지 종류의 충돌을 통해 비교했습니다.

• ① 의미 없는 표식을 통한 줄다리기 (T12, 앞서 언급한 대칭 조건). 어느 쪽을 선택할 이유도 없는 순수한 줄다리기.
• ② 숫자 표기 방식의 충돌 (T14). 반드시 한쪽만 선택해야 하는 상황. CLAUDE.md는 「수치는 반각 아라비아 숫자로 (예: 7)」, 프롬프트는 「수치는 영단어로 (예: seven)」.
• ③ 말투를 완전히 일치시킨 충돌 (T13). 양측에 완전히 동일하고 강력한 전제를 붙이고, 남은 차이를 위치로만 둔 것.

최근 프롬프트 승리 / CLAUDE.md 승리 / 둘 다 (각 N=10):

충돌 종류	Haiku	Sonnet	Opus
① 의미 없는 표식	3 / 7 / 0	0 / 7 / 3	0 / 0 / 10
...

3개 모델의 성격은 다음과 같이 요약할 수 있습니다.

Sonnet은 CLAUDE.md에 가장 충실합니다. 3가지 테스트 모두에서 최근 프롬프트를 따른 횟수는 0회였습니다. CLAUDE.md를 따르거나, 결정을 내리지 못해 둘 다 출력하는 경우 중 하나였으며, 새로움(최신성)에는 반응하지 않았습니다.

Opus는 가장 최신 정보에 가깝습니다. 의미 없는 ①에서는 "둘 중 하나를 선택하라"는 요구를 거부하고 10회 모두 양쪽의 표식을 출력했지만, 선택을 강요받는 ②③에서는 거의 완벽하게 직전 프롬프트 (Prompt) 쪽으로 기울었습니다. Opus에게 있어 CLAUDE.md라는 위치가 갖는 권위는, 충돌이 대칭화될수록 효력을 잃습니다 (한쪽만이 우선순위를 주장하는 경우는 예외입니다).

Haiku는 중간 단계입니다. ①②③ 모두 CLAUDE.md 쪽을 따르지만 (10회 중 각각 7, 9, 9회), 후술할 내용과 같이 표현을 중립적으로 바꾸면 프롬프트 쪽으로 뒤집을 수 있는 유일한 모델이기도 합니다.

성격 차이가 가장 날카롭게 드러난 것은 ②였습니다. Sonnet은 10회 모두 CLAUDE.md를 따라 7

이라고 썼고, Opus는 10회 모두 프롬프트 (Prompt)를 따라 seven

이라고 썼습니다. 숫자상으로는 "둘 다 10회 중 10회 일치했다"라고 보일 수 있지만, 일치시킨 대상이 정반대입니다. 완전히 동일한 충돌 상황을 제시했을 때 한쪽은 CLAUDE.md에 올인하고, 다른 한쪽은 직전 프롬프트에 올인했다——이것이 "모델마다 성격이 다르다"라고 단언할 수 있는 가장 명확한 증거입니다.

똑똑한 모델일수록 묵묵히 한쪽을 뭉개버리지 않고, 모호함을 겉으로 드러내는 (양쪽 다 출력하거나, 새로운 쪽을 존중하는) 경향이 있다고 해석할 수 있습니다. "똑똑하니까 자동으로 알아서 우선순위를 정해주겠지"가 아니라, 오히려 "묵묵히 덮어쓰기를 해주길 기대해서는 안 된다"는 뜻입니다. 만약 Opus를 사용하고 있다면, "CLAUDE.md에 적었으니 그쪽을 따르겠지"라는 전제는 위험합니다. 이는 공식적인 "모호하거나 모순되는 지시에서는 엄격한 준수를 보장하지 않는다"라는 유보 조항이 구체적으로 나타나는 방식이기도 합니다.

"CLAUDE.md라는 위치 그 자체에 권위가 깃든다"는 무너진다 (T13)

많은 해설은 CLAUDE.md가 프롬프트 (Prompt)를 이기는 이유를 "CLAUDE.md라는 파일 그 자체에 언어와는 독립된 권위가 깃들어 있기 때문"이라고 설명합니다. "따라서 우선순위를 주장하는 문구를 프롬프트 쪽에 기재하더라도 덮어쓸 수 없을 것이다"라는 논리입니다. 초기 테스트 (T10)에서도 확실히 그렇게 보였습니다.

하지만 테스트 도중, CLAUDE.md에 사용했던 문구가 "permanent project rule (영구적인 프로젝트 규칙)"이었다는 점이 함정이었음을 깨달았습니다. 이 표현은 "나는 프로젝트 규칙이다"라고 자처하고 있으므로 CLAULE.md와는 일치하지만, 일시적인 프롬프트 (Prompt)와는 일치하지 않습니다. 즉, "파일의 힘"과 "언어의 정합성"이 뒤섞여 있었던 것입니다.

그래서 언어를 채널에 중립적인 표현 ("이 지시가 절대적으로 우선한다. 모순되는 것은 무시하라"와 같이 "project"나 "permanent"를 포함하지 않는 표현)으로 바꾸어 다시 측정했습니다 (T13). 우선순위를 주장하는 문구를 프롬프트 (Prompt) 쪽에만 두었을 때의 조건입니다.

직전 프롬프트 승 / CLAUDE.md 승 / 양쪽 모두 (각 N=10):

"project rule" 어구	중립 어구
Haiku	0 / 10 / 0	8 / 2 / 0
...

Haiku를 보면 "project rule" 어구를 프롬프트에 두면 패배하지만 (10회 중 0회), 중립 어구로 바꾸면 승리할 수 있습니다 (10회 중 8회). Haiku의 "프롬프트에서는 이길 수 없다"는 것은 위치의 힘이 아니라 언어의 부조화 때문이었습니다. 반면 Sonnet은 중립 어구로 바꾸어도 10회 중 0회로, 이는 언어의 정합성으로는 설명되지 않습니다. 이것이 바로 CLAUDE.md라는 위치 그 자체에 대한 충실함입니다.