캐시 읽기(Cache read) 관련 질문

나도 여러 번 겪은 일이야.

정상임. davidXCVI가 메커니즘을 잘 설명했네. 숫자로 따지자면 200k 컨텍스트에서 140M 캐시 읽기는 대략 700번의 호출인데, 매번 모든 걸 다시 읽는 셈이지.

가장 먼저 볼 건 루프가 돌 때 컨텍스트가 얼마나 큰지야. 모든 버그가 같은 무거운 세션에서 시작되면, 도구 호출할 때마다 그게 다 따라오거든. 나한테 도움 됐던 건: 버그 하나당 새 세션을 쓰거나(아니면 버그 사이에 /clear 사용), MCP 도구 정의가 얼마나 무거운지 확인하는 거였어. 도구 호출 안 할 때도 요청마다 포함되거든. 안 쓰는 MCP 두 개 뺐더니 턴당 캐시 읽기가 눈에 띄게 줄었어.

캐시 읽기가 저렴하긴 해도 비용 최적화할 때 무시할 순 없지. 큰 컨텍스트를 계속 유지하기보다는 핸드오프 문서를 작성하고 거기서부터 다시 시작하는 게 나았을 수도 있어.

워크플로우에 따라 다르지만, 작업을 일련의 태스크로 구조화하면 완료된 태스크의 컨텍스트까지 들고 다닐 필요는 없거든. 140M 토큰 캐시 읽기는 API 비용 가중치를 고려하면 대략 6.2M 토큰 정도의 입력+캐시 쓰기와 맞먹어.

균형이 중요하지만, 10번 넘는 턴 동안 불필요한 컨텍스트를 들고 다니는 게 그냥 다시 읽는 것보다 더 나빠질 수 있어.

도움 됐던 팁들:

1. Claude가 반복적으로 수행하는 작업은 레포지토리에 명령어로 만들어둬. 나는 Make를 쓰는데 npm이나 Just 같은 것도 가능해. 이러면 턴 수가 줄어서 캐시 읽기도 줄어들어. 수동으로 할 때도 편하고.

2. 로그 레벨 필터링 같은 기능은 기본값으로 설정해둬. 1번처럼 API를 써서 필터 플래그를 넣은 명령어를 호출하게 하면 돼. Claude가 필요하면 덮어쓸 수 있게 플래그는 노출해두고. 이러면 컨텍스트가 작아져서 입력 토큰과 캐시 읽기가 줄어들어.

3. 검색할 때 sed, grep 같은 걸 쓰라고 지시해. 내 Claude는 필터링 없이 cat을 쓰길 좋아하더라고. 입력 토큰을 줄여줘.

4. 캐시가 커지면(> 40%) 핸드오프 문서를 쓰게 하고 새 세션에서 다시 시작해.

RTK, Headroom, caveman cli 같은 압축 도구도 살펴볼 수 있어. 나는 RTK를 쓰는데 지금은 튜닝 중이라 오히려 손해인 상태야. 사람마다 다를 수 있어.

Claude한테 세션 로그를 분석하게 해서 어떤 추천이 도움 될지 확인하고, 프로젝트 내 명령어 API를 제안받아봐.

수정: 입력도 캐시 쓰기 비용이 청구된다는 걸 깜빡했네. 최악의 경우를 고려해서 토큰 등가치를 조정했어.

수정2: 4번 추가함.

이거 9월 1일부터 Claude에서 계속 발생하던 버그임. 나도 계속 글 올렸는데 멍청한 레딧 유저들이 내 탓이라고만 하더라. 사실 너는 지금 러그풀 당한 거임. 경쟁사들은 계속 발전하면서 무료로 좋은 거 퍼주는데, 얘네는 어떻게든 살아남으려고 기능 계속 너프하고 줄이고 있음.