Claude Code가 파일을 통째로 다시 쓰면 출력 토큰이 몇 배가 될까?
204줄 파일의 help 문구 한 줄을 필요한 부분만 고치게 한 경우와 Write로 전체를 다시 쓰게 한 경우를 `claude -p`로 다섯 번씩 돌리고 세션 로그를 분해했습니다. 결과 diff는 같았지만 출력 토큰 중앙값은 736 대 4,055로 약 5.5배였고, 늘어난 몫은 거의 다 Write로 끝난 응답이었습니다.

204줄 파일의 help 문구 한 줄을 필요한 부분만 고치게 한 경우와 Write로 전체를 다시 쓰게 한 경우를 `claude -p`로 다섯 번씩 돌리고 세션 로그를 분해했습니다. 결과 diff는 같았지만 출력 토큰 중앙값은 736 대 4,055로 약 5.5배였고, 늘어난 몫은 거의 다 Write로 끝난 응답이었습니다.

같은 조사 과제와 버그 수정 과제를 haiku, sonnet, opus에 `claude -p`로 다섯 번씩 시키고, sonnet에서는 `MAX_THINKING_TOKENS=0`으로 사고를 꺼 봤습니다. 조사 과제 비용 추정치는 haiku가 opus의 약 31분의 1, 버그 수정의 성공당 비용은 약 22분의 1이었고, 사고를 끄는 환경 변수는 효과가 없었습니다.
같은 한 줄 수정을 지시만 바꿔 `claude -p`로 조건마다 5번씩 시켰더니, 설명 생략은 마지막 보고만 줄여 출력 중앙값이 713에서 598토큰이 됐습니다. 코드 리뷰에 '파일:줄 / 문제 / 수정안' 형식을 걸면 출력은 6,227에서 1,886토큰으로 줄었고, 지적 수도 8개에서 4개로 줄었지만 빠진 것은 주로 테스트·성능·스타일 같은 부차 지적이었습니다.
codebase-memory-mcp 0.12.1을 `claude -p`에 붙여 rich 저장소 질문 4개를 3번씩 물었습니다. 정답은 두 조건 모두 12/12였지만 그래프 도구는 12번 중 2번만 쓰였고 입력 토큰 중앙값은 19% 늘었으며, 늘어난 몫의 약 68%는 요청마다 붙는 1,522토큰이었습니다.
GitNexus 1.6.12 코드 그래프를 붙인 Claude Code와 기본 도구만 쓴 Claude Code에 rich 저장소의 코드 탐색 질문 4개를 `claude -p`로 3번씩 보냈습니다. 자동 판정 정답은 12번 중 12번 대 11번이었고 Read로 연 파일은 줄었지만, 불러온 MCP 도구 설명이 요청마다 다시 실려 입력 토큰 중앙값은 50,988에서 94,520으로 늘었습니다.
graphify 0.9.95를 공식 방법대로 Claude Code에 붙이고 rich 저장소 질문 4개를 `claude -p`로 조건별 12번씩 물었습니다. 매번 graphify를 먼저 불렀고 정답 수도 같았지만, 호출과 턴이 늘어 입력 토큰 중앙값은 51,530에서 86,766으로 68% 늘었습니다.
context-mode 1.0.169를 `claude -p`에 붙여 30번 잰 결과, 도구만 따로 부르면 pytest 출력이 137,851바이트에서 5,936바이트로 줄었지만 세션에서는 잘린 결과를 받은 뒤 다시 실행해 입력 토큰이 줄지 않았고 비용 추정은 2.2배였습니다.
Headroom 0.41.0 프록시를 압축만 끈 같은 프록시와 `claude -p`로 28번 비교했습니다. 실패한 테스트 출력은 Claude Code가 이미 1만 자로 잘라 입력 중앙값이 2.0%만 줄었고, 숨은 원문 재요청까지 더한 합계는 0.8% 늘었으며, 자유 과제에서는 압축할 출력이 거의 없었습니다.
lean-ctx 3.11.4 Bash hook을 `claude -p`로 30번 잰 결과, pytest 출력은 5,524바이트에서 524바이트로 줄었지만 빠진 값을 다시 조회하느라 입력 토큰 중앙값이 29,918에서 47,252로 늘었고, 명령을 맡기면 압축이 한 번도 일어나지 않았습니다.
Token Optimizer 5.13.57 hook을 `claude -p`로 30번 잰 결과, Bash 결과는 44,482자에서 17,093자로 줄었지만 답을 일부러 잘리는 줄에 둔 질문을 다시 찾느라 입력 토큰 중앙값이 8% 늘었고, 명령을 맡기면 압축이 한 번도 일어나지 않았습니다.
응답을 짧게 만든다는 7줄짜리 CLAUDE.md, claude-token-efficient를 빈 디렉터리와 나란히 두고 Claude Code `claude -p`와 Opus 5.5로 버그 원인 질문 3개를 3번씩 돌려 출력 토큰, 단어 수, 입력 토큰, 비용 추정, 답의 품질을 스크립트로 쟀습니다. 출력 토큰은 16.9% 줄고 9개 답 모두 원인과 수정을 담았지만, 요청마다 입력이 325토큰 늘어 처음 보내는 질문의 비용 추정은 11.6% 늘었고, 한 질문에서는 오류 처리 주의가 3번 중 2번 빠졌습니다.
token-optimizer-mcp 7.6.0을 Claude Code `claude -p`에 붙이고 700줄 로그를 질문마다 다시 읽게 해 보니, 도구 정의가 요청마다 10,313토큰을 더했고 smart_read는 5번 중 1번만 불려 입력 토큰 중앙값이 1.6배가 됐으며 다시 읽기 캐시는 한 번도 쓰이지 않았습니다.
함수 단위로 코드를 찾아 주는 Token Savior MCP를 Claude Code `claude -p`에 붙여 보니, 내장 도구와 같이 두면 Claude는 주로 Read와 Grep을 쓰고 요청마다 도구 정의 3,335토큰이 더해졌습니다. Token Savior만 남기면 호출 경로 질문에서 탐색으로 쌓인 입력이 9,142에서 3,462토큰으로 줄었습니다.
같은 주문 데이터를 들여쓴 JSON, 공백 없는 JSON, TOON으로 Claude Code `claude -p`에 넣어 보니 균일한 주문 150건이 차지한 입력 토큰은 13,259, 9,203, 4,872였고 네 질문은 세 형식 모두 매번 맞혔습니다. TOON CLI 추정치와 Claude 실측이 갈린 점, 고정 부분과 프롬프트 캐시가 절감 폭을 어떻게 바꾸는지도 봅니다.
System One 결정 모델 Liquid AI d1-3B와 생성 모델 LFM2.5-1.2B에 고객 문의 200건을 질문 1·3·10개로 보내, 결정 모델은 입력 토큰과 지연이 약 10배, 생성 모델은 지연 4.35배로 느는 것, 예시 한 줄이 JSON 형식 실패를 거의 없애는 것, 확률 보정이 질문마다 다른 것을 잽니다.
버그를 심은 Python 과제 10개를 `claude -p`로 effort low부터 max까지 세 번씩 고치게 했더니 150번 모두 통과했고, 출력 토큰 중앙값은 1,990에서 32,741.5로 늘었습니다. 테스트를 실제로 돌린 실행은 low 20%, medium 이상 100%였습니다.
주문 200건부터 2만 건까지를 MCP 도구로 원본 그대로, 서버에서 거르기, SQLite 파일 + SQL로 돌려주고 `claude -p`로 집계 질문 12개를 풀게 했습니다. 5만 자를 넘는 결과는 잘리지 않고 파일로 빠졌고, 서버에서 거르면 건수와 상관없이 약 1만 5천 토큰으로 모두 맞혔습니다.
MCP 도구를 200개까지 붙이고 `claude -p`로 tool search를 켠 쪽과 끈 쪽의 첫 요청 입력 토큰(36,980 대 6,677)과 도구 선택 정확도를 쟀습니다. 이름이 뜻을 드러내면 두 모드 모두 19/20이었지만, 번호 이름에 한국어 설명이면 켠 쪽이 14~16/20으로 떨어졌습니다.
무관한 팀 규칙 사이에 규칙 5개를 숨긴 CLAUDE.md를 8줄부터 1,499줄까지 만들고 `claude -p`로 코딩 과제 20개를 돌려 준수율과 입력 토큰을 쟀습니다. 1,499줄에서 요청마다 약 6만 4천 토큰이 더 실렸지만 준수율은 떨어지지 않았고, 모든 비교가 천장이라 차이는 판정할 수 없었습니다.
`claude -p`로 같은 대화의 3턴만 모델을 바꾸고 `cache_creation_input_tokens`로 캐시가 깨지는지 쟀습니다. Sonnet으로 바꾼 턴은 1만 토큰을 다시 써 Opus로 계속한 턴의 11배였고, 긴 대화의 Haiku 전환은 10만 토큰 아래와 위에서 결론이 갈렸습니다.