시리즈 마지막 편은 돈 이야기입니다. 에이전트를 API로 돌려본 분이라면 청구서에서 이상한 점을 봤을 거예요. 출력보다 입력 토큰 요금이 압도적으로 큽니다. 1편에서 본 구조를 떠올리면 당연한 일입니다. 매 턴 시스템 프롬프트부터 대화 이력 전체를 다시 보내니, 50턴짜리 에이전트 세션이라면 같은 시스템 프롬프트가 50번 과금되는 셈이거든요.
이 반복 비용을 후려치는 장치가 프롬프트 캐시(prompt caching)입니다. 잘 쓰면 입력 비용이 10분의 1로 떨어지고 응답도 빨라지는데, 조건이 하나 있습니다. 컨텍스트를 캐시가 좋아하는 방식으로 쌓아야 해요. 이번 편에서는 그 원리와, 무심코 캐시를 전멸시키는 실수들을 봅니다.
같은 접두사는 다시 계산하지 않는다
원리는 1편에서 이미 절반을 봤습니다. 모델이 입력을 처리하면 토큰마다 어텐션 중간 결과물이 나오고, 이게 KV 캐시로 GPU 메모리에 쌓인다고 했죠. 프롬프트 캐시는 이 KV 캐시를 요청 하나가 끝난 뒤에도 버리지 않고 보관했다가, 다음 요청의 입력이 같은 내용으로 시작하면 그 구간의 연산을 통째로 재사용하는 기능입니다.
에이전트 대화에 이게 얼마나 잘 맞는지 보세요. 10번째 턴의 입력은 “시스템 프롬프트 + 턴 19 + 새 메시지“입니다. 11번째 턴의 입력은 “시스템 프롬프트 + 턴 110 + 새 메시지”고요. 앞부분이 완전히 동일합니다. 캐시가 있으면 서버는 이미 계산해 둔 턴 10까지의 결과를 꺼내 쓰고 새로 붙은 꼬리만 계산하면 됩니다.
과금도 이 구조를 따라갑니다. Anthropic API 기준으로 캐시에서 읽은 입력 토큰은 정가의 10%만 받습니다. 캐시에 새로 쓰는 토큰에 25% 할증이 붙지만 한 번 쓰고 여러 번 읽는 에이전트 패턴에서는 금방 상쇄돼요. 수백 턴짜리 세션이라면 캐시 유무가 비용 몇 배 차이로 벌어집니다. 처리 시간도 캐시 구간만큼 건너뛰니 첫 토큰이 나오기까지의 지연이 눈에 띄게 줄어들고요.
조건은 하나, 접두사가 한 글자도 안 바뀌어야 한다
공짜 점심은 아닙니다. 캐시가 재사용되는 조건은 접두사(prefix) 일치입니다. 입력의 맨 앞에서부터 이어지는 동일 구간까지만 캐시가 적용되고, 내용이 달라지는 첫 지점부터 뒤로는 전부 다시 계산합니다.
이 규칙이 왜 그런지도 1편이 설명해 줍니다. 어텐션에서 각 토큰의 KV 값은 자기 앞의 모든 토큰에 의존합니다. 앞쪽 토큰이 하나라도 바뀌면 그 뒤 모든 토큰의 계산 결과가 달라지니, 캐시를 쓸 수 없는 거예요. 컨텍스트의 앞부분일수록 건드리는 비용이 비싼 이유입니다.
그래서 캐시 친화적인 컨텍스트의 원칙은 한 문장으로 요약됩니다. 안정적인 것은 앞에, 가변적인 것은 뒤에, 그리고 이력은 수정하지 말고 덧붙이기만 할 것(append-only).
캐시를 전멸시키는 무심한 실수들
원칙은 단순한데, 어기는 방법이 교묘하게 많습니다.
첫 번째가 시스템 프롬프트 속 가변 값입니다. 시스템 프롬프트에 현재 시각을 초 단위로 박아 넣으면 어떻게 될까요. 컨텍스트의 맨 앞이 매 요청 달라지니, 캐시 적중률이 0%가 됩니다. 넣더라도 날짜 수준으로 뭉툭하게 넣거나, 컨텍스트 뒤쪽에 배치해야 해요. 세션 ID, 랜덤 값도 같은 지뢰입니다.
두 번째는 도구 정의 변경입니다. 도구 스키마는 보통 컨텍스트 최상단에 들어가서, 세션 중간에 도구를 추가하거나 빼면 그 뒤 전체의 캐시가 무효화됩니다. 4편에서 MCP 서버 정리를 권했는데, 캐시 관점에서 한 줄 더해지는 겁니다. 정리하려면 세션 시작 전에, 중간에는 건드리지 않기.
세 번째는 이력 중간 편집입니다. 지난 턴의 내용을 수정하거나 오래된 턴을 삭제하는 방식으로 컨텍스트를 아끼려는 시도가 있는데, 접두사가 깨지니 그 지점부터 캐시가 날아갑니다. 토큰 몇천 개를 아끼려다 세션 전체 재계산 비용을 무는, 배보다 배꼽이 큰 거래가 되기 쉬워요. 이력에서 뭔가를 지워야 한다면 차라리 매듭을 지어서 통째로 비우는 쪽이 낫습니다.
마지막으로, 3편의 /compact도 캐시 관점에서 다시 보입니다. 압축은 이력 전체를 새 요약본으로 교체하니 캐시가 완전히 리셋됩니다. 물론 이후 턴들이 짧아진 이력 위에 새 캐시를 쌓으니 장기적으로는 이득이지만, “compact는 공짜 청소가 아니라 캐시 재구축 비용이 따르는 이벤트”라는 감각은 가질 필요가 있습니다. 잦은 compact보다 매듭마다 /clear가 비용 면에서도 유리한 경우가 많은 이유예요.
시리즈 총정리, 컨텍스트를 다루는 일곱 가지 감각
7편을 관통한 원칙을 한 줄씩으로 접어봅니다.
- 컨텍스트 윈도우는 유한하고, 그 한계는 어텐션 연산과 KV 캐시라는 물리에서 옵니다.
- 들어간다고 잘 쓰이는 게 아닙니다. 길이 자체가 품질을 깎습니다.
- 작업 경계마다 /clear가 기본값, 맥락을 이어야 할 때만 지시어를 붙인 /compact.
- 시스템 프롬프트·CLAUDE.md·도구 정의는 고정비입니다. 항상 참인 것만 짧게.
- 과정이 무겁고 결론이 가벼운 일은 서브에이전트의 컨텍스트에 격리합니다.
- 세션을 넘어야 할 지식은 파일로 외부화합니다. 계획 파일, 메모리, 크면 RAG.
- 컨텍스트는 append-only로 쌓아야 캐시가 삽니다. 안정적인 것은 앞에, 가변적인 것은 뒤에.
하나로 줄이면 이렇게 되겠네요. 컨텍스트는 모델의 능력이 아니라 사용자가 설계하는 예산이라는 것. 100만 토큰 시대가 와도 이 감각은 유효할 겁니다. 창이 커질수록, 그 안에 뭘 올릴지 고르는 안목이 성능 차이를 만들 테니까요.