코드 편집기는 오랫동안 정액제이거나 무료였다. 오후 내내 테스트 하나를 고치든 쉰 개를 고치든 도구 값은 같았고, 그래서 개별 작업에는 따로 가격표가 붙지 않았다. Claude Code 같은 에이전트형 코딩 도구는 이 전제를 바꿔 놓는다. 같은 작업을 끝내더라도 어떻게 진행했느냐에 따라 비용이 달라진다. 한 세션에서는 Claude가 테스트 파일과 대상 파일만 읽고 몇 번의 턴 만에 수정을 끝낸다. 다른 세션에서는 저장소를 grep으로 뒤지고 열두 개의 파일을 거쳐 결국 같은 두 파일에 도달하는데, 그 모든 턴이 아침부터 대화에 쌓인 내용을 매번 함께 끌고 다닌다. 결과물은 같은 수정이지만 소모한 토큰이 다르고, 그동안 모델은 쓰지도 않을 열 개의 파일을 계속 신경 써야 한다.
핵심은 토큰을 적게 쓰는 것이 아니라, 쓰는 토큰이 실제로 요청한 작업에 향하도록 만드는 데 있다. 그러려면 토큰 한 개의 값이 무엇으로 정해지는지, 그리고 한 세션이 얼마나 많은 토큰을 보내는지를 나눠서 볼 필요가 있다.
토큰 한 개의 값은 추론 시간이 정한다
청구는 토큰 단위지만 실제로 값을 치르는 대상은 추론, 즉 GPU가 모델을 토큰 위에서 돌리는 데 드는 시간이다. 이 시간은 세 가지가 좌우한다. 어떤 모델을 쓰는지, 입력 토큰인지 출력 토큰인지, 그리고 캐시되었는지다. 요청은 GPU를 두 단계로 지나간다. 프리필 단계에서는 시스템 프롬프트, CLAUDE.md, 사용자 메시지, 그리고 그간 대화에 더해진 파일과 명령 출력을 읽는다. 이것이 입력 토큰이다. 디코드 단계에서는 모델의 사고 과정, 도구 호출, 화면에 보이는 텍스트 같은 출력 토큰을 한 번에 하나씩 써 내려간다. 200 토큰짜리 응답은 모델을 200번 연속으로 돌리는 셈이라, 출력 토큰은 입력의 약 5배 가격이 매겨진다. 출력의 상당 부분은 사고 토큰이며, 턴마다 얼마나 사고할지는 /effort로 조절하는 노력 수준이 결정한다. 모델과 마찬가지로 이 설정은 다음 세션의 기본값으로도 이어진다.
프롬프트 캐시는 켤 것이 아니라 깨지 않는 것
요청이 서버가 방금 본 요청과 정확히 같은 토큰으로 시작하면, 그 공유되는 앞부분의 상태는 동일하게 나오므로 서버가 이를 재활용하고 그 뒤만 새로 프리필한다. 이것이 프롬프트 캐싱이다. 캐시에서 읽으면 입력 가격의 0.1배, 캐시에 쓰면 상태를 보관해야 하므로 최대 2배가 든다. 다만 쓰기는 토큰당 한 번뿐이고 0.1배 읽기는 그 뒤 모든 턴에서 반복된다. Claude Code는 이 캐시를 매 요청마다 알아서 관리하므로 따로 켤 것은 없지만, 깨뜨릴 수는 있어 비용 급등을 피하려면 원리를 알아야 한다. 요청은 늘 같은 순서로 나간다. 도구 정의, 시스템 프롬프트, 그다음 대화(맨 앞에 CLAUDE.md)다. 이 접두부에서 무언가 바뀌면 그 뒤 전부가 다시 프리필된다. 대화 끝에 붙는 도구 결과가 이상적인 경우이고, 앞쪽을 건드리는 변경이 캐시를 버린다. 그래서 모델이나 노력 수준을 바꾸는 값싼 순간은 세션 시작 직후나 /clear 직후이고, 비싼 순간은 긴 대화의 한복판이다.
무엇이 컨텍스트를 채우는가
기억할 점은 어떤 것도 한 번만 보내지지 않는다는 것이다. 대화에 들어간 파일과 명령 출력은 세션이 끝날 때까지 이후 모든 턴에 다시 실려 간다. 캐시 덕에 재전송은 싸지만 싼 것이 공짜는 아니고, 모델이 매 턴 그 주위를 돌며 사고해야 할 자리를 차지한다. Claude가 얼마나 읽느냐는 스스로 얼마나 알아내야 하느냐에 달려 있다. "테스트가 실패한다"고만 하면 grep 몇 번과 파일 몇 개를 열어 어느 것이 관련 있는지 찾아야 하고, 그 결과는 쓸모가 사라진 뒤에도 컨텍스트에 남는다. "utils.test.ts의 실패 테스트를 고쳐줘"는 탐색을 건너뛰어 Read 한 번으로 끝나고, @로 파일을 직접 지정하면 그 Read 비용마저 없앤다. 명령 출력도 마찬가지다. 3만 자를 넘는 출력은 파일로 저장되고 짧은 미리보기와 경로만 대화에 남지만(BASH_MAX_OUTPUT_LENGTH로 조정 가능), 문제는 그 아래다. 통과한 테스트 400개를 한 줄씩 찍는 러너는 한도에 못 미친 채 400줄을 남은 모든 턴에 눌러앉힌다. Claude가 플래그나 tail로 알아서 정리하는 경우가 많고, 원치 않으면 시끄러운 명령을 실행 전에 다듬는 훅이 문서에 나와 있다.
긴 세션 하나는 같은 작업을 짧은 세션 몇 개로 나눈 것보다 비싸며, 40번째 턴이 앞선 39개 턴을 다시 읽는 만큼 생각보다 더 비싸다. 새 작업을 시작할 때 /clear, 같은 작업의 앞부분이 끝났을 때 /compact로 컨텍스트를 짧고 관련성 있게 유지하는 것이 핵심이다. 내가 타이핑하지 않을 때 일어나는 턴도 살펴야 한다. /loop는 설정한 세션에서 전체 대화를 매번 끌고 도는 온전한 턴으로 발화되고, 직전 턴에서 한 시간이 지났으면 그 위에 캐시 미스까지 얹힌다. 별도 터미널에서 새 세션을 열어 루프를 돌리는 편이 낫다. 또 다른 방법은 아예 다른 컨텍스트에서 일이 벌어지게 하는 서브에이전트다. 서브에이전트는 자체 시스템 프롬프트, 도구, CLAUDE.md를 가진 독립 컨텍스트 창을 받되 내 대화는 받지 않으며, 끝나면 답만 돌아오고 나머지는 버려진다. 작은 작업엔 그저 부담이지만 로그를 훑는 것처럼 남길 필요 없는 출력이 많은 작업에서 값을 한다. "이 로그를 서브에이전트로 훑어줘"처럼 직접 요청할 수 있고, 다만 메인 세션은 서브에이전트가 보고하기로 한 것만 돌려받는다는 점을 기억해야 한다.
한국 실무자 입장에서 이 원리는 몇 가지 습관으로 정리된다. 파일 경로를 처음부터 짚어 탐색을 줄이고, 노력 수준과 모델 전환은 세션 초입이나 /clear 직후에 몰고, 작업이 바뀌면 컨텍스트를 비우고, 무인 루프는 대화가 무거운 세션에서 떼어내는 것이다. 다만 이 글이 다루는 것은 어디까지나 세션 운용의 비용 구조이지, 어떤 모델이 어떤 문제에 값하는지에 대한 판단은 아니다. 라우팅은 별개의 주제로 남아 있고, 결국 무거운 모델과 깊은 사고가 정말로 필요한 어렵고 모호한 문제와 그렇지 않은 routine 작업을 스스로 구분하는 감각이 절약의 전제가 된다는 점은 도구가 대신해 주지 않는다.