당신의 문서는 토큰을 낭비하지 않습니다 — 낭비하는 것은 당신의 툴링입니다

📝 원래 제 블로그에 게시되었습니다 → https://kanfu-panda.github.io/blog/2026/06/16/tokens-not-docs.html

사람들은 PDLC(Product Development Life Cycle)로 프로젝트를 운영하는 것에 대해 저에게 계속해서 같은 질문을 합니다. PRD(제품 요구사항 문서), 설계, 매 단계의 리뷰 등 그 모든 문서들 때문에 토큰을 엄청나게 낭비하고 있는 것 아니냐는 질문 말이죠.

타당한 질문입니다. 프로세스가 세분화된 단계로 나뉘어 있고, 각 단계마다 결과물(artifact)이 남기 때문에, 단순히 "AI에게 코드를 쓰게 하는 것"보다 더 비용이 많이 드는 것처럼 보일 수 있습니다. 하지만 저는 토큰 비용의 책임을 문서에 돌려서는 안 된다고 주장합니다.

결론부터 말씀드리겠습니다. 첫째, 많은 문서를 보유하는 것과 많은 토큰을 사용하는 것은 별개의 문제입니다. 둘째, 진정으로 토큰을 줄이고 싶다면 정답은 문서를 줄이는 것이 아니라 도구(tool)를 올바르게 사용하는 것입니다.

저는 토큰을 정확하게 측정하지는 않았습니다. 깨끗한 백분율을 얻기 위해 문서가 있는 경우와 없는 경우로 동일한 프로젝트를 두 번 실행해 보지는 않았기 때문입니다. 제가 가진 것은 실전 경험과 방법론입니다.

토큰 비용은 PDLC의 잘못이 아닙니다

청구서를 결제하기 전에, 올바른 채무자를 찾아야 합니다.

대부분의 경우, 토큰 낭비는 PDLC 때문에 발생하는 것이 아니라 도구(tooling)를 잘못 사용해서 발생합니다. 그리고 그 "잘못된 사용"은 다음 세 가지 지점에서 구체적으로 나타납니다:

• 컨텍스트 (Context): 지워야 할 때 지우지 않는 것. 하나의 대화가 아침부터 밤까지 이어지며, 매 턴마다 수만 개의 토큰에 달하는 히스토리가 재계산됩니다. 당신은 새로운 질문을 던지면서 과거의 부채를 갚고 있는 셈입니다.
• 프롬프트 (Prompts): 너무 모호한 경우. AI는 당신이 실제로 원하는 것이 무엇인지 계속 추측해야 합니다. 한 번에 말할 수 있었던 것을 세 번의 라운드에 걸쳐 말하게 됩니다.
• 도구 호출 (Tool calls): 파일 하나만 수정하고 있는데 저장소(repo) 전체를 읽게 만드는 것.

그리고 가장 흔한 경우: 토큰 절약 방법을 전혀 사용하지 않으면서, 프로세스가 무겁다고 프로세스를 탓하는 것입니다.

이 중 그 어떤 것도 "PDLC는 문서가 너무 많다"는 이유로 책임을 물을 수 없습니다. 문서는 docs/ 폴더에 조용히 놓여 있을 뿐이며, 그 자체로는 단 하나의 토큰도 소모하지 않습니다. 토큰을 태우는 것은 위에서 언급한 사용 방식들입니다.

실제로 토큰을 태우는 것은 재작업(rework)입니다

제 경험상, 가장 큰 토큰 소모원(token sink)은 문서를 생성하는 것이 아니라 바로 재작업(rework)이었습니다.

방향이 틀려서 다시 쓰는 것, 요구사항을 잘못 읽어서 전부 허무는 것, 하나를 고치려다 다른 것이 망가져서 되돌아가는 것 — 이 모든 왕복 과정(round-trips)이 실제 토큰입니다. PRD(제품 요구사항 문서)를 생성하는 것은 일회성 비용이지만, 잘못된 방향으로 인한 재작업은 복리로 쌓입니다.

이렇게 무거워 보이는 PDLC(제품 개발 생명 주기) 프로세스는 정확히 "초기에 조금 더 작성하는 것"을 대가로 "나중에 재작업을 훨씬 덜 하는 것"을 얻는 거래입니다. 일단 이 방식을 사용하면 전체 흐름이 더 안정적이고 최종 결과물도 안정적입니다. 즉, 왔다 갔다 하는 과정이 없어집니다. 재작업이 줄어든다는 것은 그 자체로 소모되는 토큰이 줄어든다는 뜻입니다.

그래서 저는 이렇게 생각합니다. 문서는 비용이 아니라 자산입니다. 문서는 설계 결정 사항과 그 이유(why)에 대한 흔적을 남기므로, 나중에 추적하고 감사(audit)할 수 있습니다. 다음에 AI가 이를 가져갈 때, AI는 문서를 읽고 바로 이해합니다. 저는 처음부터 다시 설명할 필요가 없습니다. 그렇게 절약된 과정 또한 다시 말하지만, 토큰입니다.

그렇다면 실제로 어디에서 토큰을 아껴야 하는가

토큰을 아낀다는 것은 문서를 쓰지 않는 것이 아니라, 아껴야 할 곳에서 아끼는 것을 의미합니다. 제가 실제로 제 환경에서 사용하는 것들은 대략 다음과 같습니다:

• 컨텍스트 트리밍 (Trim context): 적절한 시점에 컨텍스트를 비우세요. 매 턴마다 수만 개의 토큰이 담긴 히스토리를 계속 끌고 가지 마세요.
• 모델 계층화 (Tier your models): 모기를 잡는 데 대포를 쓰지 마세요. 탐색, 검색, 파일 읽기와 같은 단순 작업(grunt work)은 저렴한 소형 모델 (small model)에 맡기고, 실제 사고, 분석 및 코딩이 필요한 경우에만 가장 강력한 계층의 모델을 사용하세요.
• 정밀한 파일 읽기 (Read files precisely): 이번 변경 사항과 관련된 내용만 읽으세요. 반사적으로 "프로젝트 전체 읽기"를 수행하지 마세요.
• 프롬프트 캐싱 (Prompt caching): 캐싱된 부분은 할인된 가격으로 청구되며, 이는 1:1 선형 관계가 아닙니다. 잘 활용하면 절감 효과가 눈에 띕니다.
• 일상적인 명령 앞에 토큰 프록시 배치: git status와 같이 빈도가 높은 작업의 경우, 출력값을 압축하세요. 이 차이가 쌓이면 큽니다.
• 병렬화 (Parallelize): 독립적인 작업들을 동시에 실행하여 왕복 시간 (round-trips)을 줄이세요.

이 중 그 어느 것도 "문서를 적게 쓰라"는 뜻이 아닙니다.

모든 변경 사항에 전체 프로세스가 필요한 것은 아닙니다

그렇다고 해서 PDLC가 모든 변경 사항에 대해 전체 프로세스를 실행해야 한다는 의미는 아닙니다.

한 줄짜리 버그 수정에 PRD(제품 요구 사항 문서)나 디자인 리뷰가 필요할까요? 상황에 따라 다릅니다. 대부분의 경우 무거운 프로세스는 필요하지 않으므로 생략하세요. 기준은 간단합니다. 이 변경 사항이 자산(asset)으로 남길 가치가 있는가? 만약 그렇다면 전체 프로세스를 수행하세요. 일회성 소규모 수정의 경우, 몇 단계를 건너뛴다고 해서 아무도 당신을 비난하지 않습니다.

그리고 "토큰 절약 = 비용 절약"이라는 말은 과금 모델에 따라 구분해서 말해야 합니다. 그렇지 않으면 오해를 불러일으킬 수 있습니다.

• 고정 할당량이 있는 월정액 구독 (flat monthly subscription) 모델에서는, 절약하는 것이 **할당량 여유분 (quota headroom)**입니다. 즉, 같은 돈으로 더 많은 작업을 할 수 있게 됩니다.
• 종량제 API (pay-as-you-go API) 모델에서는, 실제 현금을 절약하게 됩니다. 모든 토큰이 청구서에 반영되기 때문입니다.

저는 두 가지를 모두 사용합니다. 먼저 자신이 어떤 모델을 사용 중인지 파악하세요. 그래야 "토큰 절약"이 당신에게 실제로 무엇을 의미하는지 알 수 있습니다.

결론 (Finally)

요약하자면: 많은 문서가 곧 토큰을 낭비하는 것은 아닙니다. 정말로 절약하고 싶다면, 문서가 아니라 도구를 사용하는 방식에서 절약해야 합니다.

제가 가장 강조하고 싶은 한 가지는 이것입니다: 문서는 비용이 아니라 자산입니다. "문서를 작성하지 않고 AI가 코드만 생성하게 함으로써" 토큰을 아끼려는 시도는 단기적으로는 절약처럼 보일 수 있지만, 프로젝트는 멀리 가지 못할 것입니다. 흔적이 남지 않고, 추적 가능성 (traceability)이 없으며, 두 달 뒤에는 왜 그렇게 설계했는지조차 설명할 수 없게 됩니다. 결국 그때 발생하는 재작업 비용은 당신이 아낀 문서 토큰보다 훨씬 더 많은 것을 태워버릴 것입니다.

오늘 바로 할 수 있는 한 가지: 당신이 토큰 절약 방법들을 활성화했는지 되돌아보세요. 컨텍스트 (context)가 다듬어져 있나요? 모델 계층화 (tiering)를 하는 대신 여전히 모든 것을 가장 강력한 모델에 보내고 있지는 않나요? 줄일 수 있는 비용을 줄였나요? 그리고 이와 함께, PDLC (Product Development Life Cycle)를 잘 활용하고 있는지도 자문해 보세요.

토큰을 절약하는 방법에는 더 많은 내용이 있습니다. 모델을 정확히 어떻게 계층화할지, 언제 컨텍스트를 비울지, 캐싱 할인 (caching discount)을 실제로 어떻게 적용할지 등 말이죠. 다음번에는 그중 하나를 골라 더 깊이 있게 다뤄보겠습니다.