AI 개발도구
코드 편집기는 한 달에 얼마였고 작업 하나에는 값이 붙지 않았다. 인공지능이 코드를 읽고 고치는 도구에서는 같은 수정도 진행 방식에 따라 청구액이 갈린다. 그 값이 무엇으로 정해지는지, 그리고 널리 유통되는 절약 요령이 겨냥하는 것이 실제로 무엇인지 따져 본다.
비주얼 스튜디오 코드나 인텔리제이 같은 통합 개발 환경은 값이 사용량과 무관했다. 그날 오후에 시험 코드 하나를 고치든 쉰 개를 고치든 편집기 값은 같았다. 그래서 개발자는 작업의 단가를 생각할 일이 없었다.
에이전트 코딩 도구는 그 전제를 깼다. 이런 도구는 사람이 편집기에서 코드를 직접 치는 대신, 자연어 지시를 받아 인공지능이 저장소를 뒤지고 파일을 읽고 수정을 적용하고 시험 명령까지 실행한다. 앤트로픽의 클로드 코드, 오픈AI의 코덱스, 구글의 제미나이 CLI가 같은 계열이다. 사람이 하는 일은 무엇을 할지 정하고 결과를 받아 보는 쪽으로 옮겨 간다.
값은 토큰 단위로 매겨진다. 토큰은 언어 모델이 글을 다루는 최소 조각으로, 앤트로픽은 영어 기준 4글자 남짓을 1토큰으로 잡는다고 안내한다. 언어와 내용에 따라 이 비율은 달라진다. 청구서에는 모델이 읽어들인 토큰과 써낸 토큰이 따로 집계된다.
여기서 같은 작업의 값이 갈린다. utils.test.ts의 실패한 시험 하나를 고치라고 지시했다고 하자. 파일 두 개만 읽고 몇 번 만에 끝나는 진행이 있고, 어느 시험이 문제인지부터 찾느라 저장소 전체를 검색하고 파일 열두 개를 열어 본 끝에 같은 두 개에 닿는 진행이 있다. 결과는 같은 수정이지만 쓰인 토큰이 다르다. 게다가 뒤의 경우에는 필요 없는 열 개 파일이 그 세션이 끝날 때까지 모델의 머릿속에 남는다.
청구되는 것은 토큰이지만 값을 치르는 대상은 연산이다. 그래픽 처리 장치가 그 토큰을 놓고 모델을 돌리는 시간이 값의 실체다. 그 시간을 좌우하는 것은 셋이다. 어느 모델인가, 들어가는 토큰인가 나오는 토큰인가, 그리고 캐시에 있었는가.
모델 크기는 설명이 필요 없다. 큰 모델은 입력에도 출력에도 더 많은 연산을 쓰므로 아래의 모든 값이 모델 가격에 곱해진다. 나머지 둘은 사정이 다르다.
요청 하나는 두 단계를 거친다. 앞 단계는 사전 채우기다. 시스템 프롬프트, 프로젝트 지침 파일, 사용자 메시지, 그때까지 읽어들인 파일과 명령 출력이 모두 여기서 처리된다. 시스템 프롬프트는 도구 사용법과 행동 규칙을 적어 둔 지시문으로, 사용자 눈에 보이지 않은 채 모든 요청 앞에 붙는다. 프로젝트 지침 파일은 저장소마다 따로 두는 규칙 문서이며 클로드 코드에서는 CLAUDE.md라는 이름을 쓴다. 이 단계는 입력 전체를 한꺼번에 병렬로 돌릴 수 있어서 연산 능력이 병목이 되고, 그래픽 처리 장치의 계산 유닛이 거의 놀지 않는다.
뒤 단계는 디코딩이다. 모델이 사고 과정과 도구 호출과 사용자에게 보이는 문장을 한 토큰씩 만들어 낸다. 다음 토큰은 앞 토큰이 정해져야 정해지므로 병렬화가 되지 않는다. 200토큰짜리 응답은 모델을 200번 차례로 돌리는 일이다. 매 단계마다 지금까지 쌓인 상태를 메모리에서 통째로 읽어 와야 하므로 병목이 연산에서 메모리 대역폭으로 옮겨 가고, 계산 유닛의 활용률은 크게 떨어진다. 이 비대칭은 추론 시스템 연구에서 오래전부터 정리된 사실이며, 사전 채우기와 디코딩을 아예 다른 장비 묶음에 나눠 돌리는 분리 서빙 구조가 나온 이유이기도 하다.
가격표는 그 물리적 사정을 그대로 옮겨 놓았다. 앤트로픽 공개 가격 기준으로 오퍼스 5는 입력 100만 토큰당 5달러, 출력 25달러다. 소네트 5는 2달러와 10달러, 하이쿠 4.5는 1달러와 5달러, 페이블 5는 10달러와 50달러다. 네 모델 모두 출력이 입력의 정확히 5배다. 어림한 비율이 그대로 가격 정책의 상수로 박혀 있다.
이 5배가 중요한 이유는 세션 출력의 상당 부분이 사고 토큰이기 때문이다. 모델이 답을 내기 전에 스스로 굴리는 추론 과정도 생성되는 토큰이고 출력 가격으로 계산된다. 클로드 코드의 /effort 명령이 조절하는 것이 턴마다 쓸 사고량이다. 단순 반복 작업이라면 MAX_THINKING_TOKENS=0으로 그 세션의 사고를 아예 끌 수도 있다.
언어 모델을 부르는 접속 규약에는 기억이 없다. 서버는 지난 대화를 들고 있지 않고, 요청이 올 때마다 그때까지의 대화 전체가 다시 실려 온다. 앞서 든 시험 파일 수정이 실제로 몇 번의 요청으로 처리되는지 따라가 보면 구조가 드러난다.
시험 하나를 고치는 데 오가는 요청
1 도구 정의가 포함된 시스템 프롬프트, 프로젝트 지침 파일, 사용자 메시지를 묶어 첫 요청을 보낸다.
2 모델이 시험 파일을 읽겠다는 도구 호출을 내놓는다. 도구가 파일을 읽어 대화에 덧붙이고, 대화 전체를 다시 보낸다.
3 모델이 시험 대상 파일도 읽겠다고 한다. 같은 일이 한 번 더 일어난다.
4 모델이 수정안을 내놓는다. 수정을 적용한 결과를 붙여 또 보낸다.
5 모델이 시험 명령을 돌린다. 그 출력을 붙여 또 보낸다.
6 시험이 통과했고 모델이 짧은 요약으로 답한다. 도구 호출이 없으니 덧붙일 것도 없고 요청도 더 없다.
한 줄짜리 수정 하나에 요청이 다섯 번 나갔고, 다섯 번 모두 그 시점까지의 대화 전체를 담고 있었다. 일반적인 턴은 심하게 한쪽으로 기운다. 들어가는 것이 수만 토큰이고 나오는 것은 수백 토큰이다.
이 구조를 그대로 정가로 계산하면 세션이 길어질수록 청구액이 제곱으로 불어난다. 40번째 턴은 앞의 39개 턴을 통째로 다시 실어 나른다. 그래서 프롬프트 캐시는 이 방식이 성립하기 위한 전제가 된다.
프롬프트 캐시를 사람의 기억에 빗대는 설명이 흔하다. 모델이 앞에서 본 것을 기억하고 있으니 다시 읽을 필요가 없다는 식이다. 이 비유는 결과만 맞고 작동 방식은 틀리며, 그 어긋남에서 실제 비용이 발생한다.
사전 채우기 단계에서 모델은 입력 토큰마다 중간 상태를 만들어 쌓아 둔다. 이것을 키·값 캐시라고 부른다. 어떤 요청이 직전 요청과 처음부터 똑같은 토큰으로 시작한다면, 그 겹치는 앞부분의 중간 상태는 계산해 봐야 똑같이 나온다. 서버는 그 상태를 잠시 들고 있다가 다시 꺼내 쓰고, 뒤에 새로 붙은 부분만 계산한다.
값은 이렇게 매겨진다. 캐시에서 읽으면 정가 입력의 0.1배다. 계산하지 않고 불러오기만 하기 때문이다. 캐시에 써 넣을 때는 5분짜리가 1.25배, 1시간짜리가 2배다. 서버가 그 상태를 붙들고 있어야 하는 값이 붙는다. 쓰기는 토큰당 한 번뿐이고 읽기는 이후 매 턴 일어나므로, 5분짜리는 한 번만 읽혀도 본전을 넘고 1시간짜리는 두 번이면 넘는다.
요청은 언제나 이 순서로 나간다. 왼쪽 어느 칸이든 한 글자가 달라지면 그 오른쪽 전부를 다시 계산해야 한다. 대화 맨 끝에 도구 결과가 붙는 것이 캐시에 가장 유리한 경우다. 뒤에 영향을 받을 것이 없기 때문이다.
대조는 의미가 아니라 해시로 이뤄진다. 앤트로픽 문서는 캐시 적중에 100퍼센트 동일한 구간이 필요하다고 못박는다. 주석 한 줄, 타임스탬프 한 개, 심지어 프로그래밍 언어에 따라 무작위로 뒤바뀌는 JSON 키 순서만으로도 대조가 어긋난다. 캐시는 무엇이 안정된 내용인지 알아보지 못한다. 앞선 요청이 그 자리에 실제로 써 놓은 항목만 찾는다.
여기서 도구 사용자가 가장 자주 걸리는 대목이 나온다. 대화 도중 모델을 바꾸거나 사고 수준을 바꾸면 캐시가 통째로 날아간다. 모델마다 캐시가 따로 있으니 앞엣것은 당연하다. 사고 수준 쪽은 왜 그런지 덜 분명한데, 앤트로픽 기술 문서에 답이 적혀 있다. 사고 설정값은 프롬프트 안에 문자로 새겨 넣어진다. 설정을 바꾸는 행위가 곧 프롬프트를 고치는 행위다. 응답 속도를 올리는 패스트 모드도 시스템 프롬프트를 바꾸므로 같은 결과를 낳는다.
조건은 더 있다. 프롬프트가 일정 길이에 못 미치면 아예 캐시되지 않고, 오류도 나지 않은 채 조용히 넘어간다. 그 최소 길이는 모델마다 다르다. 오퍼스 5와 페이블 5, 미토스 5는 512토큰, 오퍼스 4.8과 소네트 5는 1,024토큰, 오퍼스 4.7은 2,048토큰이며, 오퍼스 4.6과 4.5, 그리고 하이쿠 4.5는 4,096토큰이다. 값이 가장 싼 하이쿠가 문턱이 가장 높다. 짧은 작업을 싼 모델로 돌리려는 판단과 캐시가 걸리는 조건이 서로 반대 방향을 가리킨다.
캐시 수명도 짧다. 기본은 5분이고 추가 요금을 내면 1시간이다. 수명은 응답이 끝난 시점이 아니라 요청이 시작된 시점부터 재기 때문에, 응답을 4분 동안 흘려 보낸 요청 뒤에는 1분 남짓 안에 다음 요청이 시작돼야 적중한다. 클로드 코드는 구독 사용자에게 1시간, 접속 키 사용자에게 5분을 적용한다.
이 모든 조건이 얼마나 다루기 까다로운지는 앤트로픽이 붙여 놓은 기능 하나가 말해 준다. 캐시 진단이라는 베타 기능은 연속된 두 요청을 서버에서 대조해 접두사가 정확히 어디서 갈라졌는지 알려 준다. 사용자가 자기 요청의 어느 바이트가 달라졌는지 스스로 찾아내지 못한다는 전제 위에 만들어진 기능이다.
가격 인하 발표는 단가로 이뤄진다. 소네트 4.6의 입력 100만 토큰당 3달러가 소네트 5에서 2달러가 되었으니 33퍼센트 인하다. 그런데 같은 문서의 다른 대목에 이런 안내가 붙어 있다. 4.7 이후 모델은 새 토크나이저를 쓰며, 토크나이저는 글을 토큰으로 쪼개는 규칙이고 모델 세대마다 갈린다. 같은 글이 대략 30퍼센트 더 많은 토큰으로 쪼개진다. 소네트 4.6 이전 모델이 옛 토크나이저를 쓴다고 명시돼 있으니 소네트 5는 새 쪽이다.
두 숫자를 곱해 보면 실제 인하 폭이 나온다. 옛 토크나이저에서 1,000토큰으로 세어지던 코드는 새 쪽에서 1,300토큰이 된다. 앞은 1,000에 100만분의 3달러를 곱해 0.003달러, 뒤는 1,300에 100만분의 2달러를 곱해 0.0026달러다. 같은 코드를 처리하는 값이 13퍼센트 남짓 내려갔다. 발표된 33퍼센트가 아니다.
토큰당 가격과 같은 글이 몇 토큰으로 세어지는지는 별개의 변수이며, 둘은 같은 세대에서 반대 방향으로 움직였다.
30퍼센트라는 수치 자체가 내용에 따라 달라지는 근사값이므로 13퍼센트도 정확한 값은 아니다. 짚을 것은 비교의 단위다. 토큰은 모델이 정하는 단위이고, 그 단위가 바뀌면 단가 비교는 성립하지 않는다. 컨텍스트 창의 크기도 같은 함정을 안고 있다. 컨텍스트 창은 모델이 한 번에 붙들 수 있는 토큰의 상한이고, 대화가 그 상한에 닿으면 앞부분을 덜어 내야 한다. 창을 토큰으로 재는 이상, 토큰이 잘게 쪼개지면 같은 숫자의 창에 들어가는 코드 분량이 줄어든다.
여기서 정면으로 부딪치는 두 조언이 있다. 하나는 새 작업을 시작할 때마다 대화를 지우라고 한다. 40번째 턴이 앞의 39개 턴을 다시 읽어야 하니 하나의 긴 세션은 같은 일을 여러 짧은 세션으로 나눌 때보다 비싸다는 것이다. 다른 하나는 잦은 초기화가 오히려 손해라고 한다. 캐시를 버리고 같은 파일을 정가로 다시 읽게 만들기 때문이다.
두 조언은 각각 조용한 전제를 깔고 있다. 앞엣것은 이어지는 맥락이 다음 작업에 쓸모없다고 전제하고, 뒤엣것은 쓸모있다고 전제한다. 전제를 밝히면 계산은 간단해진다.
오퍼스 5 기준으로 따져 보자. 다음 작업과 무관한 50,000토큰을 안고 20턴을 더 가면 캐시 읽기로만 100만 토큰이 흐르고 0.5달러가 든다. 대화를 지우고 시작 프리픽스 20,000토큰을 다시 써 넣으면 5분 캐시 기준 0.125달러다. 이 경우에는 지우는 쪽이 이긴다. 그러나 지운 뒤 같은 파일 50,000토큰을 다시 읽어야 한다면 정가로 0.25달러가 붙고 쓰기 값이 추가된다. 이때는 안고 가는 쪽이 낫다.
두 조언이 모두 조건부로 옳다는 결론이 나온다. 더 눈여겨볼 것은 어느 쪽이든 차이가 한 세션에 수십 센트 수준이라는 점이다. 청구서를 좌우할 크기가 아니다.
같은 계산에서 도구 명령들의 값도 정리된다. 대화 끝의 몇 턴만 잘라 내는 되감기는 앞부분 캐시를 그대로 두므로 값이 들지 않는다. 대화를 짧은 요약으로 갈아 끼우는 압축은 시스템 프롬프트 뒤의 모든 것을 새로 쓰므로 언제나 값이 든다. 다만 옛 대화가 아직 캐시에 살아 있을 때 요약하는 편이 싸므로, 자리를 오래 비우기 전에 미리 압축해 두는 순서가 유리하다. 이 정도가 캐시 산수로 정당화할 수 있는 조언의 전부다.
앞의 계산에는 빠진 항목이 있다. 캐시에서 0.1배로 다시 읽히는 토큰도 모델이 매 턴 헤아려야 하는 재료로는 그대로 남는다. 값이 싸진 것과 방해가 되지 않는 것은 다른 문제다.
이 지점을 재려는 실증 작업이 몇 갈래 있다. 스탠퍼드의 넬슨 리우 연구진이 2024년 학술지 Transactions of the Association for Computational Linguistics에 실은 논문은 여러 문서를 놓고 답을 찾는 과제와 키·값 검색 과제에서 정답 문서의 위치만 바꿔 가며 정확도를 쟀다. 결과는 U자 곡선이었다. 정답이 입력의 맨 앞이나 맨 뒤에 있을 때 성적이 가장 좋고 가운데로 갈수록 크게 떨어졌으며, 긴 맥락을 겨냥해 만든 모델도 예외가 아니었다.
데이터베이스 기업 크로마가 2025년 7월 공개한 기술 보고서는 다른 각도에서 접근했다. 과제 난이도를 고정하고 입력 길이만 늘려 가며 18개 최신 모델을 시험했더니, 검색이나 텍스트 복제처럼 단순한 과제에서도 입력이 길어질수록 신뢰도가 떨어졌다. 창을 다 채우지 않아도 나타나는 현상이었다. 크로마가 검색 기반 생성 도구를 파는 회사라는 점은 감안할 필요가 있으나, 결과의 방향은 리우 연구진의 관찰과 어긋나지 않는다.
에이전트 코딩은 이 열화가 나타나기 좋은 조건을 세 겹으로 갖추고 있다. 읽은 파일과 명령 출력이 계속 쌓이기만 하고, 코드 검색은 의미가 비슷하면서 답이 아닌 결과를 다량으로 게워 내며, 작업 하나가 수십 분씩 이어진다.
여기서 값의 구조가 뒤집힌다. 흐려진 판단은 잘못된 수정을 낳고, 잘못된 수정을 되돌리려면 턴이 몇 번 더 필요하다. 그 턴은 사고 토큰과 도구 호출을 새로 생성하므로 출력 가격, 즉 입력의 5배로 계산된다. 무관한 컨텍스트를 하루 종일 0.1배로 다시 읽는 값보다, 그 컨텍스트 때문에 어긋난 판단 하나를 되돌리는 값이 크다.
같은 처방을 두 가지 근거로 정당화했을 때
절약으로 정당화하면. 대화 초기화, 서브에이전트 위임, 명령 출력 줄이기, 파일 첨부는 모두 조건부 이득이다. 계산해 보면 몇십 센트가 오간다.
판단 품질로 정당화하면. 같은 처방이 조건 없이 성립한다. 컨텍스트에서 무관한 것을 덜어 내는 일은 언제나 이득이고, 그 이득의 크기는 되풀이 턴을 몇 번 막았느냐로 정해진다.
서브에이전트가 그 예다. 서브에이전트는 자기만의 컨텍스트 창과 도구를 가지고 일을 처리한 뒤 최종 답만 본 세션에 돌려준다. 그 과정에서 생긴 턴과 중간 결과는 일이 끝나면 버려진다. 본 세션의 대화를 물려받지 않으니 이미 읽은 자료를 다시 읽는 일이 생기고 자기 턴 값도 따로 든다. 작은 일에는 순전한 낭비다. 로그 수천 줄을 훑는 것처럼 출력이 많고 결론 몇 줄만 남기면 되는 일에서 값을 한다. 절약으로만 보면 이 도구는 계산이 애매하다. 창을 깨끗하게 유지하는 장치로 보면 쓰임이 분명해진다.
명령 출력도 같다. 30,000자를 넘는 출력은 클로드 코드가 파일로 빼내고 대화에는 짧은 미리보기와 경로만 남긴다. 정작 문제는 그 문턱 아래다. 통과한 시험 400개를 한 줄씩 찍는 시험 실행기의 출력은 문턱에 걸리지 않고, 그 400줄이 남은 모든 턴에 따라다닌다. 조용한 옵션을 붙이라는 조언의 값어치는 절약한 돈이 아니라 그 400줄이 모델의 주의에서 사라진다는 데 있다.
이 요령들을 정리해 내놓은 쪽은 도구를 파는 회사다. 앤트로픽은 2026년 8월 14일 리디아 할리의 이름으로 세션 운용 안내를 공개했다. 사용량을 줄이라는 권고로 시작할 법한 글인데, 방향을 이렇게 잡았다.
Being efficient with tokens doesn't mean using fewer of them overall.
토큰을 효율적으로 쓴다는 것이 전체 사용량을 줄인다는 뜻은 아니다.
앤트로픽, 「Maximizing the value of your Claude Code sessions」, 2026년 8월 14일
이어지는 문장은 쓴 토큰이 실제로 요청한 일에 가도록 하는 것이 요점이라고 정리한다. 판매자가 사용량 절감을 안내하는 구도는 이해관계가 어긋나 보이지만, 구독제에서는 사정이 다르다. 구독 사용자에게는 토큰 가격이 보이지 않고 한도 소진으로만 나타나며, 한도에 대한 불만은 해지로 이어진다. 컨텍스트가 깨끗해야 출력 품질이 올라간다는 점에서도 방향이 같다. 그래서 안내의 프레이밍이 배분에 놓인다.
같은 프레이밍에는 배경으로 밀려나는 사실도 있다. 열거된 항목들은 도구가 아직 자동으로 처리하지 못하는 일을 사용자 습관으로 옮겨 놓은 목록이다. 접두사가 어디서 갈라지는지, 어떤 명령이 몇 줄을 게워 내는지, 어느 시점에 대화를 갈아 끼워야 하는지를 사람이 판단해야 한다.
다만 그 목록은 세대마다 짧아지고 있다. 기술 문서에서 확인되는 변화가 몇 가지 있다. 페이블 5와 미토스 5, 오퍼스 4.8과 5, 소네트 5에서는 대화 도중에 시스템 지시를 추가해도 시스템 캐시와 메시지 캐시가 살아남는다. 그전까지는 시스템 프롬프트를 건드리면 그 뒤의 캐시가 함께 무효가 됐다. 최소 캐시 길이도 오퍼스 4.6과 4.5의 4,096토큰에서 오퍼스 5의 512토큰으로 내려갔다. 오퍼스 4.5 이후와 소네트 4.6 이후 모델에서는 사고 블록이 기본으로 보존되어, 도구 결과가 아닌 사용자 입력이 끼어들어도 캐시가 깨지지 않는다. 명령 출력의 자동 파일화, 자동 압축, 캐시 진단도 같은 방향의 장치다.
흐름이 이어진다면 지금 남아 있는 항목들, 특히 모델 전환과 사고 수준 전환이 캐시 키에서 빠지는 일도 가능하다. 사고 설정을 프롬프트에 문자로 새기지 않는 방식이 도입되면 뒤엣것은 원리상 풀린다. 이 관측이 틀렸다고 볼 조건은 분명하다. 다음 세대에서 캐시 키에 들어가는 설정 항목이 오히려 늘거나, 최소 캐시 길이가 다시 올라가거나, 무효화 항목을 정리한 문서가 길어지면 흐름이 뒤집힌 것으로 봐야 한다.
세션의 값을 이루는 항목 가운데 사용자가 손댈 수 없는 것부터 갈라 두면 남는 것이 분명해진다. 출력이 입력의 5배인 것은 디코딩이 순차적이고 메모리 대역폭에 묶여 있다는 물리적 사정에서 나오며, 캐시 읽기가 0.1배인 것은 계산을 다시 하지 않는다는 사정에서 나온다. 둘 다 가격 정책의 상수다. 모델 선택도 작업 난이도가 정하지 사용자의 절약 의지가 정하지 않는다.
사용자가 실제로 움직일 수 있는 변수는 하나로 좁혀진다. 컨텍스트에 무엇이 들어가고 얼마나 오래 남는가. 그런데 이 조정을 청구액으로 정당화하려 들면 계산이 갈린다. 긴 세션과 짧은 세션 가운데 무엇이 비싼가 하는 논쟁이 결론에 이르지 못하는 이유가 그것이고, 어느 쪽으로 결론이 나든 금액이 수십 센트 수준이라는 것도 같은 계산에서 나온다. 같은 조정을 판단 품질로 정당화하면 조건이 사라진다. 입력이 길어질수록 모델의 정확도가 떨어진다는 결과가 위치를 바꾼 실험과 길이를 바꾼 실험 양쪽에서 나왔고, 에이전트 코딩은 축적·방해물·장시간이라는 세 조건을 모두 갖춘 작업이다.
그래서 쟁점은 컨텍스트 관리의 본체를 어디에 두느냐로 좁혀진다. 청구액에 두면 요령들은 조건부 이득이고 금액도 사소하다. 출력 품질에 두면 같은 요령들이 조건 없이 성립하며, 값어치는 막아 낸 되풀이 턴으로 계산된다. 되풀이 턴이 출력 가격으로 매겨진다는 사실을 넣으면 두 계산은 결국 한 곳에서 만나지만, 도달하는 순서가 다르고 그 순서가 어떤 요령을 우선할지를 바꾼다.
캐시가 접두사 해시인 이상 정합성을 지키는 일은 기계가 대신할 수 있는 종류의 일이고, 무효화 항목이 세대마다 줄어드는 것을 보면 실제로 넘어가는 중이다. 그 이관이 끝나면 남는 것은 무엇을 컨텍스트에 넣을지 정하는 판단이다. 어느 파일이 이 문제와 관련 있는지, 어디까지 읽혀야 답이 나오는지를 정하는 일은 접두사 문제가 아니라 문제를 정의하는 문제이며, 캐시 정책이 바뀌어도 그대로 남는다. 도구가 값싸질수록 그 판단의 몫이 상대적으로 커진다.
본문에 언급된 자료: 앤트로픽 클로드 플랫폼 기술 문서의 가격 항목과 프롬프트 캐시 항목, 앤트로픽 「Maximizing the value of your Claude Code sessions」(2026년 8월 14일), Nelson F. Liu 외, 「Lost in the Middle: How Language Models Use Long Contexts」, TACL 12권(2024), 157~173쪽, 크로마 기술 보고서 「Context Rot」(2025년 7월).