컨텍스트 파일은 존재하고, 동기화되었으며, 올바른 해시를 가질 수 있지만 모델에 도달하지 않을 수도 있습니다. 또한 모델에 도달했더라도 작업을 개선하는 데 실패할 수도 있습니다.

이러한 구별은 중요합니다. 왜냐하면 AI 코딩 도구는 이제 AGENTS.md, CLAUDE.md, 스킬, 규칙 및 MCP 도구 정의와 같은 파일에 대해 서로 다른 로딩 게이트를 가지고 있기 때문입니다.

최근 Systima 측정은 경계를 구체화했습니다. 로깅 프록시를 사용하여, Claude Code 2.1.207이 72 KB의 AGENTS.md를 무시한 다음, 이 콘텐츠가 CLAUDE.md로 이름을 바꾼 후 동일하게 로드하는 것을 발견했으며, 요청당 20k 이상의 입력 토큰을 추가했습니다. 이 연구는 또한 유용한 반례도 발견했습니다. 즉, 낮은 시작 컨텍스트가 전체 작업 비용이 낮다는 것을 자동으로 의미하지 않는데, 이는 요청 수와 배치(batching)가 결과에 영향을 미쳤기 때문입니다.

따라서 “파일이 존재함”과 “프롬프트가 작음”은 모두 불완전한 성공 기준입니다.

세 가지 경계

모든 지침 소스에 대해 세 가지 별도의 질문을 하십시오:

1. 설정됨 (Configured): 의도된 소스가 도구가 읽어야 하는 경로에 존재하는가?
2. 로드됨 (Loaded): 목적지가 실제로 그것을 받았다는 런타임 승인, 첨부된 소스 레이블 또는 제공자 경계 증거가 있는가?
3. 유용함 (Useful): 반복 실행 전반에 걸쳐 고정된 작업 결과가 개선되었는가?

해시(hash)는 소스의 정체성을 증명합니다. 하지만 전달을 증명하지는 않습니다. 전달 추적(delivery trace)은 관찰을 증명하지만, 준수 또는 유용함을 증명하지는 않습니다.

작은 A/B 테스트

관찰 가능한 효과를 가진 무해한 작업별 지침 하나를 사용하십시오. 예를 들어: “편집하기 전에 정확히 두 개의 대상 파일을 나열하시오.”

그런 다음:

1. 도구 버전(tool version), 모델(model), 저장소 상태(repository state), 작업(task), 그리고 신규 세션 조건(fresh-session condition)을 고정하십시오.
2. 대상이 네이티브하게 로드하지 않는 파일명/경로 아래에서 지침과 함께 한 번 실행하십시오.
3. 동일한 바이트를 가지고 대상의 네이티브 소스 아래에서 다시 실행하십시오.
4. 소스 해시(source hash), 구성된 경로(configured path), 관찰된 로드 증거(observed load evidence), 사용 가능한 요청 횟수/입력 토큰 수, 그리고 작업 결과(task result)를 기록하십시오.
5. 로더 실패(loader failure)와 확률적 비준수(stochastic non-adherence)를 분리할 만큼 충분히 반복하십시오.

loaded_but_outcome_failed라는 세 번째 상태를 유지하십시오. 그렇지 않으면 성공적인 파일 발견 확인(file-discovery check)이 동작 실패(behavior failure)를 숨길 수 있습니다.

소스가 관찰 가능하게 로드되었지만 결과가 여전히 개선되지 않는다면, 프롬프트 확장을 중단하십시오. 강력한 제약 조건(hard constraints)을 결정론적 후크(deterministic hook), 테스트(test), 또는 정책 게이트(policy gate)로 이동시키십시오.

브라우저 전용 테스트 케이스 (fixture)

저는 이 정확한 비교를 Pluribus의 30초 컨텍스트 동기화 데모에 추가했습니다. 여기서는 동일한 소스 해시를 두 개의 합성 레인(synthetic lanes)에서 사용합니다:

• AGENTS.md → 구성되었지만 무시됨 (configured_but_ignored)
• CLAUDE.md → 로드되었고 작업 결과가 수용됨 (loaded_and_task_outcome_accepted)

이 테스트 케이스는 의도적으로 합성(synthetic)으로 표시되었습니다: 측정 형태를 보여줄 뿐, 사용자의 런타임을 포착한다고 주장하지 않습니다.

더 유용한 미해결 질문은 또 다른 범용 규칙 파일 추천보다 더 가치 있습니다. 당신의 도구가 구성되었는지 실제로 로드되었는지를 구별하는 가장 작은 증거 조각은 무엇입니까?

A/B 테스트를 실행했다면, 사용한 도구/버전, 소스 레이블, 그리고 작업 결과가 변경되었는지 여부를 공유해 주십시오. 깨끗한 데모보다 반례(counterexample)가 더 가치 있습니다.