프롬프트를 읽기도 전에 3만 토큰 — 코딩 에이전트의 '보이지 않는 청구서'

여러분이 코딩 에이전트에게 “이 버그 좀 고쳐줘"라고 한 줄 입력했다고 해봅시다. 그런데 그 한 줄이 모델에 도착하기도 전에, 이미 3만 개가 넘는 토큰이 소리 없이 청구되고 있었다면 어떨까요. 요즘 개발자 커뮤니티에서 조용히 번지고 있는 논쟁이 바로 이겁니다. AI 코딩 도구의 ‘보이지 않는 시작 비용’ 문제인데요.

먼저 솔직하게 말씀드리면, 이 주제는 최근 30일 사이 대형 커뮤니티에서 폭발적으로 다뤄진 ‘핫한’ 논쟁은 아닙니다. 오히려 헤비 유저들 사이에서 꾸준히 곱씹어지는 ‘만성 통증’ 같은 이슈에 가깝습니다. 그래서 오늘은 실시간 반응 중계보다는, 이 문제가 왜 중요한지 그 구조를 뜯어보는 데 집중해보겠습니다.

질문을 읽기도 전에 3만 토큰

핵심부터 짚죠. 코딩 에이전트는 여러분의 프롬프트만 모델에 보내지 않습니다. 그 앞에 어마어마한 양의 ‘사전 지시서’를 함께 붙여 보냅니다. 시스템 프롬프트, 도구(tool) 정의, 안전 규칙, 파일 편집 포맷 설명, 그리고 각종 컨텍스트가 그 정체입니다.

Claude Code의 경우 이 사전 지시서가 대략 33,000 토큰 규모라는 이야기가 돌고 있습니다. 무슨 뜻이냐면, 여러분이 “안녕"이라고만 쳐도 모델은 이미 원고지 수백 장 분량의 배경 설명을 읽은 뒤에야 그 “안녕"을 마주한다는 겁니다.

왜 이렇게 무거울까요. 이유는 단순합니다. 도구가 많고 똑똑할수록 설명서가 길어지기 때문입니다. 파일을 읽고, 쓰고, 검색하고, 터미널을 돌리고, 서브 에이전트를 부르고, 스킬을 불러오는 이 모든 기능 하나하나가 “이럴 땐 이렇게 써라"는 설명을 필요로 합니다. 기능의 풍부함이 곧 토큰의 무게가 되는 구조입니다.

미니멀 진영의 반격, “우린 7천이면 된다”

이 지점에서 반대편 목소리가 등장합니다. OpenCode 같은 미니멀 지향 도구들인데요. 이들의 주장은 명확합니다. “시스템 프롬프트를 7,000 토큰 수준으로도 충분히 유지할 수 있다.”

숫자만 놓고 보면 4배가 넘는 차이입니다. 이 차이가 왜 중요할까요. 세 가지 관점에서 살펴보겠습니다.

첫째는 돈입니다. 토큰은 곧 비용입니다. 매 요청마다 3만 토큰이 얹힌다면, 하루에 수백 번 대화하는 헤비 유저에게는 무시할 수 없는 청구서가 쌓입니다. 캐싱으로 상당 부분 완화된다고는 하지만, 캐시가 깨지는 순간 그 비용은 고스란히 돌아옵니다.

둘째는 컨텍스트 예산입니다. 모델의 컨텍스트 창은 유한합니다. 시작부터 3만 토큰을 오버헤드로 깔고 가면, 정작 여러분의 코드베이스를 담을 공간이 그만큼 줄어듭니다. 큰 프로젝트를 다룰수록 이 ‘자리싸움’은 치명적입니다.

셋째는 집중력입니다. 이게 의외로 핵심인데요. 프롬프트가 길수록 모델의 주의가 분산될 수 있습니다. 지시가 많으면 그중 일부를 흘려버리는 현상이 생깁니다. 미니멀 진영은 “적게 지시할수록 모델이 더 또렷하게 움직인다"고 주장합니다.

그런데 정말 미니멀이 이기는 걸까

여기서 한쪽 편만 들면 안 됩니다. 무거운 데는 무거운 이유가 있습니다.

Claude Code가 3만 토큰을 쓰는 건 방만해서가 아니라, 그만큼 많은 일을 ‘알아서’ 해주기 때문입니다. 상세한 도구 정의는 에이전트가 헛발질하지 않도록 잡아주는 안전장치입니다. 파일을 어떻게 편집할지, 언제 확인을 받을지, 위험한 명령을 어떻게 거를지 — 이 모든 규칙이 사용자가 매번 설명하지 않아도 되게 해주는 ‘내장된 경험치’인 셈입니다.

미니멀 도구는 가볍지만, 그 가벼움의 대가를 사용자가 치를 때가 있습니다. 모델이 맥락을 몰라 엉뚱한 짓을 하거나, 결국 사용자가 직접 더 많은 지시를 타이핑해야 하는 상황이 생기죠. 시스템 프롬프트에서 아낀 토큰을 대화 중에 다시 토해내는 겨입니다.

결국 이건 선불이냐 후불이냐의 문제에 가깝습니다. 무거운 에이전트는 시작할 때 비용을 미리 냅니다. 가벼운 에이전트는 그 비용을 대화 도중에 나눠 냅니다. 어느 쪽이 이득인지는 여러분이 어떤 작업을 하느냐에 따라 완전히 갈립니다.

진짜 문제는 ‘보이지 않는다’는 것

제가 이 논쟁에서 가장 흥미롭게 본 지점은 숫자 자체가 아닙니다. 이 비용이 보이지 않는다는 사실입니다.

대부분의 사용자는 자기가 쓰는 에이전트의 시작 오버헤드가 3만인지 7천인지 전혀 모릅니다. 알 방법도 마땅치 않습니다. 청구서에는 뭉뚱그려진 토큰 총량만 찍힐 뿐, “이 중 얼마가 당신 질문에 도달하기 전에 소진됐는지"는 알려주지 않습니다. 정보 비대칭이 발생하는 지점입니다.

그래서 이 논쟁의 진짜 가치는 “누가 더 가볍냐"를 가리는 데 있지 않습니다. 사용자가 자기 도구의 숨은 비용 구조를 들여다보기 시작했다는 것, 바로 그 자체에 있습니다. 도구를 고를 때 기능 목록만 볼 게 아니라 “이 녀석은 시작부터 얼마를 태우는가"를 묻는 시대가 온 겁니다.

앞으로 코딩 에이전트를 고르실 때 한 번쯤 이 질문을 던져보시길 권합니다. 이 도구는 내 질문을 읽기 전에 이미 얼마를 쓰고 있을까요. 그리고 그 무게는, 나에게 값어치를 하고 있을까요. 여러분의 워크플로우에서는 선불과 후불, 어느 쪽이 더 남는 장사일지 궁금합니다.