클로드 코드 MCP 스택 측정: 캐시 친화성 대 바이트 절감 및 프롬프트 캐시를 위한 2줄 수정

Claude Code MCP 스택을 최적화할 때 바이트 절약이라는 하나의 지표에 집중하기 쉽습니다. 그러나 Greg Shevchenko의 새로운 분석에 따르면, 단일 축 벤치마크는 프로덕션에서 엄격히 더 나쁜 시스템을 추천할 수 있습니다. 놓친 축은 바로 캐시 친화성, 즉 동일한 입력이 실행 간에 바이트 단위로 동일한 출력을 생성하여 Anthropic의 프롬프트 캐시가 적중하도록 하는지 여부입니다.

Shevchenko의 가장 큰 바이트 절약 도구(컨텍스트를 60-70% 줄인 검색 MCP)는 실제로 매 호출마다 5분 TTL 프롬프트 캐시를 무력화하고 있었습니다. 동일한 쿼리의 두 실행이 다른 바이트를 생성했는데, 그 이유는 rg --files-with-matches 출력 순서가 Map 삽입 순서를 통해 최종 컨텍스트로 새어 나갔기 때문입니다. 수정은 두 줄이었습니다: 슬라이싱 전에 rg 결과를 정렬하고, Map 항목을 경로별로 정렬하는 것입니다. 변경 후 바이트 절약은 그대로였지만 cache_friendly_score는 ~0%에서 100%로 상승했습니다.

하네스가 측정하는 것

Shevchenko는 오픈소스 벤치마크 하네스(stdlib 전용 Python, 오프라인)를 공개했으며, 이 하네스는 다음을 측정합니다:

• 평균 비율 + CV: 픽스처당 N≥5회 실행 → 바이트 절약 축
• 고유 MD5 개수 == 1 확인 → 캐시 친화성 축 (0–100%)
• 12가지 안티패턴 감사: 도구 정의(DSA 참조)

모든 압축기를 (str) -> str 형태로 연결할 수 있습니다. 하네스는 클러스터 부트스트랩 CI, 윌슨 CI, 사전 등록, 실제 데이터 Cohen's κ를 사용합니다.

조사된 공개 대안

Shevchenko는 공개 문서를 조사했습니다: Cursor 코드베이스 인덱스, Sourcegraph Cody, Aider repo-map, Microsoft LLMLingua/LLMLingua-2, Firecrawl/Jina Reader, RouteLLM/Martian (2026년 5월 기준). 이 중 캐시 친화성 지표를 공개한 곳은 없었습니다.

한계

그는 사전 처리 레이어가 후속 턴에서 더 많은 다운스트림 캐시 적중을 유발할 것이라고 가정했지만, 유의미한 결과는 나오지 않았습니다(Welch p=0.32, Cohen's d≈0.18, N=137). 말뭉치에 대한 두 명의 평가자 간 Cohen's κ는 0.5955(보통 수준, 0.7 임계값 미만)였으며, 5건의 불일치 중 4건이 하나의 모호한 작업에서 발생했습니다. 사양을 수정하면 κ가 ~0.83으로 올라갈 것입니다.

하네스는 MIT 라이선스입니다. Claude Code MCP 스택을 운영 중이라면 cache_friendly_score를 측정하는 것이 이제 구체적이고 실행 가능한 단계입니다.