LLM Token Optimization: 9 Techniques in the Order to Apply Them

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

LLM 토큰 비용은 가장 큰 입력부터 줄이고 프롬프트 캐시와 출력 제한을 적용하되, 과제별 사용량과 결과 품질을 함께 평가해야 한다.

📌 핵심 요약

• 모델 API는 매 턴 전체 대화를 다시 전송하므로 입력 비용이 누적된다. Longju Bai 등의 SWE-bench Verified 연구에서는 8개 프런티어 모델의 에이전트 코딩 과제가 코드 채팅·추론보다 1,000배 많은 토큰을 사용했고, 비용 대부분은 입력에서 발생했다.
• 2026년 10월 13일 기준으로 제시된 OpenAI와 Anthropic의 가격표에서 출력 단가는 입력의 5배이며, 캐시 읽기는 신규 입력의 1/10~1/40 수준이다. 최상위 모델과 최저가 모델의 입력 단가 차이는 두 제공사 모두 100배다.
• 입력은 정적 프리픽스, 도구 정의, 대화 이력, 검색·수집 콘텐츠로 나누고 출력과 함께 과제별로 측정해야 한다. 글은 큰 입력 축소, 캐시 친화적 프롬프트 배치, 출력·추론 제한을 먼저 적용하고 라우팅·배치·압축을 뒤에 검토하도록 권한다.
• Firecrawl의 자체 측정에서는 실제 페이지 15개의 원시 HTML을 정리된 마크다운으로 바꾸자 GPT 토큰이 4,103,706개에서 190,817개로 줄었다. Openbenchmarks 검색 전용 비교에서는 Firecrawl이 과제당 중앙값 7,456토큰·완료율 70.3%, Perplexity가 8,765토큰·77.3%를 기록해 비용과 성공률의 상충 관계를 보였다.
• 단일 사실은 직접 답변이나 JSON으로, 전체 문맥을 추론해야 하는 자료는 마크다운으로 전달하는 것이 권장된다. 프롬프트 캐시는 동일한 프리픽스를 재사용하며, 제공된 본문은 OpenAI의 1,024토큰 이상 자동 캐싱 설명 도중 잘려 있어 제목의 9개 기법 전체와 누적 절감 계산은 확인할 수 없다.

🧩 주요 포인트

1. 대화 이력과 검색·수집 콘텐츠의 반복 전송 → 한 번 줄인 도구 결과가 후속 턴의 입력 비용도 줄이므로 큰 입력 축소의 효과가 누적된다.
2. 출력의 5배 단가와 캐시 읽기의 낮은 단가 → 토큰 총량뿐 아니라 출력 비중과 프롬프트 프리픽스의 재사용 여부가 비용을 좌우한다.
3. Firecrawl과 Perplexity의 토큰 사용량·완료율 차이, 요약의 정보 손실 → 절감 효과는 과제 성공률과 필요한 문맥의 보존 여부를 함께 평가해야 한다.

🧠 상세 정리

1. 최적화의 정의와 적용 순서

글은 LLM 토큰 최적화를 결과 품질을 낮추지 않으면서 모델에 보내고 받는 토큰 수와 토큰당 비용을 줄이는 작업으로 정의한다. 수량을 줄이는 방법은 입력과 생성을 축소하는 것이고, 단가를 낮추는 방법은 캐시·배치·저렴한 모델로의 라우팅이다. 적용 순서는 가장 큰 입력을 먼저 줄이고, 제공사가 캐시할 수 있도록 프롬프트를 배치한 다음, 필요 이상의 출력과 추론을 제한하는 방향이다. 라우팅·배치·압축은 그다음에 검토하며, 실패하는 저가 요청이 성공하는 고가 요청보다 비쌀 수 있으므로 모든 변경에 평가가 필요하다고 강조한다. 서두의 표에는 도구 정의 85% 이상 축소, 배치 50% 할인, 월 10,000개 연구 과제의 비용을 11,648달러에서 425달러로 줄이는 계산 예시도 제시된다. 다만 제공된 본문에는 이러한 후반 기법의 상세 설명과 누적 비용 계산 과정이 포함되지 않는다.

2. 에이전트에서 입력 비용이 누적되는 구조

모델 API는 상태를 보존하지 않으므로 각 턴에서 시스템 프롬프트, 도구 정의, 이전 응답, 가져온 페이지를 포함한 대화 전체를 다시 보낸다. 따라서 8턴 과제의 첫 턴에서 읽은 페이지는 총 8번 과금되며, 이미 전달한 콘텐츠가 비용의 큰 부분을 차지할 수 있다. 입력은 정적 프리픽스, 도구 정의, 대화 이력, 검색·수집 콘텐츠로 나뉘고, 여기에 답변과 추론 토큰으로 구성되는 출력이 더해진다. 정적 프리픽스와 도구 정의는 반복 사용되어 캐시에 적합하지만, 이력과 수집 콘텐츠는 턴마다 커져 비용 증가의 원인이 된다. 글의 예시에서는 12,000토큰 프리픽스에 매 턴 12,000토큰 페이지를 읽고 800토큰을 쓰는 8턴 에이전트가 한 과제에서 입력 550,400토큰을 처리하며, 새 페이지 내용은 그중 96,000토큰에 불과하다. Longju Bai 등의 SWE-bench Verified 연구도 8개 프런티어 모델에서 에이전트 코딩의 토큰 사용량이 코드 채팅·추론보다 1,000배 많고, 비용 대부분이 입력에서 발생했다고 보고했다.

3. 입력·출력·캐시와 모델별 가격 차이

글이 인용한 2026년 10월 13일 가격표는 토큰 수가 같아도 입력·출력·캐시 중 어느 항목으로 청구되는지에 따라 비용이 크게 달라짐을 보여준다. 표준 단문맥 기준 100만 토큰당 GPT-6 Astra와 Claude Fable 5.1은 입력 10달러·출력 50달러이고, GPT-6.1 Sol과 Claude Sonnet 5.5는 입력 2달러·출력 10달러다. GPT-6 Luna와 Claude Haiku 5.5는 입력 0.10달러·출력 0.50달러로, 두 제공사 모두 최상위와 최저가 모델의 입력 단가 차이가 100배다. 표의 모든 모델에서 출력은 입력의 5배이며, 캐시 읽기는 신규 입력의 1/10~1/40, 두 중간 가격대 모델에서는 1/20 수준이다. 장문맥에서는 OpenAI 입력 단가가 2배, 출력 단가가 1.5배가 되고, Haiku 5.5는 100,000토큰을 넘는 프롬프트에서 입력 0.50달러·출력 2.50달러로 오른다고 설명한다. 동일한 텍스트도 제공사에 따라 토큰 수가 때로 2배 이상 달라지므로, 단가와 실제 토큰 수를 함께 봐야 한다.

4. 과제별 사용량 측정이 우선인 이유

최적화를 시작하려면 총사용량을 과제별로 나누고, 입력이 어느 계층에서 발생하는지부터 파악해야 한다. 글은 제공사가 각 응답에 반환하는 사용량을 요청마다 기록하면서 기능, 과제 ID, 모델을 함께 표시하도록 권한다. Anthropic에서는 input_tokens, output_tokens, cache_creation_input_tokens, cache_read_input_tokens를 읽고, OpenAI에서는 사용량 상세의 cached_tokens를 확인한다. 검색 콘텐츠가 입력의 80%라면 이를 먼저 줄이며, 출력은 입력의 5배 단가이므로 장황한 응답이 긴 프롬프트보다 비쌀 수 있다는 점도 살펴야 한다. 캐시 적중률은 캐시 읽기 토큰을 전체 입력 토큰으로 나누어 보며, 여러 턴을 사용하는 작업에서 이 값이 낮으면 프롬프트 배치가 캐시를 깨뜨리는지 점검할 근거가 된다. 전송 전 계산에는 OpenAI용 tiktoken, Anthropic의 /v1/messages/count_tokens, Gemini의 countTokens를 제시하며, 문자 수에 의존한 추정에는 유의미한 오차가 있다고 설명한다.

5. 페이지 전체에서 필요한 답과 필드로 입력 축소

검색·수집 콘텐츠는 대부분의 에이전트에서 가장 큰 입력 계층이며, 필요하지 않은 내용이 많아 줄이기 쉬운 대상으로 제시된다. Firecrawl의 자체 토큰화 비교에서는 실제 페이지 15개가 원시 HTML일 때 GPT 토큰 4,103,706개였으나 정리된 마크다운에서는 190,817개로, 21.5배 차이를 보였다. 문서 질의응답이나 RAG 수집처럼 전체 페이지가 필요한 경우에는 마크다운으로 정리하는 수준에서 멈추는 것이 적절하다고 설명한다. 반면 단일 사실만 필요한 에이전트라면 페이지를 전달하지 않고 직접 답을 반환할 수 있으며, AAPL 주가 조회 사례에서는 Claude Code WebFetch의 295문자 결과와 Firecrawl의 6문자 결과를 비교한다. Replit 요금제의 여러 필드는 산문 942문자 대신 스키마 기반 JSON 338문자로, 주식 5개의 가격은 도구 호출 5회·약 1,100문자 대신 호출 1회·114문자로 전달했다. 이렇게 줄인 결과는 이후 대화 이력에서도 반복 전송되므로, 최초 호출뿐 아니라 후속 턴에서도 절감 효과가 이어진다.

6. 검색 제공사 비교와 성공률의 상충 관계

글은 최신 가격, 최근 출시된 라이브러리의 문서, 뉴스처럼 학습 시점 이후의 정보가 필요한 경우 웹 검색을 중요한 입력 경로로 본다. 동시에 검색 결과에 전체 페이지가 포함될 수 있어, 제공사가 반환하는 형식 자체가 비용을 결정하는 요인이 된다고 설명한다. 2026년 9월 26일 갱신된 Openbenchmarks 검색 전용 비교에서 동일한 코딩 에이전트를 사용했을 때 Firecrawl은 과제당 중앙값 7,456토큰과 완료율 70.3%를 기록했다. Perplexity는 8,765토큰과 77.3%로, 약 18% 많은 토큰을 사용하면서 더 많은 과제를 완료했다. 다른 제공사의 수치는 Parallel fast 12,460토큰·66.7%, Brave 14,103토큰·38.0%, Tavily basic 16,299토큰·51.0%, Exa instant 22,423토큰·61.3%, Linkup fast 24,057토큰·43.3%였다. 검색과 가져오기를 결합한 별도 비교에서는 Firecrawl의 중앙값 17,379토큰이 Exa·Parallel·Tavily·Perplexity보다 낮았지만, 글이 제시한 수치만으로 모든 작업에서 비용과 품질의 우위를 일반화할 수는 없다.

7. 정보 손실을 고려한 반환 형식 선택

입력을 줄이는 과정에서 직접 답변과 요약은 본질적으로 정보를 잃을 수 있으며, 글은 Claude Code의 WebFetch 요약을 포함한 모든 도구에 이 한계가 적용된다고 명시한다. 따라서 코드로 검증할 수 있는 사실은 직접 답변이나 JSON 스키마로 받고, 모델이 전체 내용을 추론해야 하는 자료는 마크다운으로 유지하는 구분을 제안한다. 여러 필드가 필요할 때는 스키마가 있는 JSON 형식으로 해당 필드만 자료형을 갖춘 값으로 반환받아 검증할 수 있다고 설명한다. SEC 공시나 경제 시계열처럼 공식 출처가 있는 데이터에는 Firecrawl Alexandria가 100개 이상의 데이터 제공사에서 형식이 지정된 레코드를 같은 검색 호출로 반환한다고 소개한다. 이러한 원칙은 웹 외에도 데이터베이스에서 전체 테이블 대신 일치하는 세 행을 반환하거나, 파일 도구에서 변경분을 제공하거나, 테스트 실행기에서 전체 로그 대신 실패한 테스트를 반환하는 방식으로 확장된다. 핵심은 가장 짧은 결과를 무조건 택하는 것이 아니라, 과제에 필요한 근거를 보존하면서 불필요한 전달량을 줄이는 데 있다.

8. 프리픽스 캐싱의 조건과 본문 범위의 한계

글은 프롬프트 캐싱을 가장 큰 단가 할인 수단으로 설명하면서, 요청 앞부분이 바뀌면 오류 없이 캐시 재사용이 무산될 수 있다고 경고한다. 두 주요 제공사는 프리픽스를 기준으로 처리 상태를 저장하므로, 재사용 지점 이전의 내용이 바이트 단위로 같아야 한다. Anthropic에서는 cache_control로 최대 네 개의 경계점을 지정하거나 자동 캐싱을 사용할 수 있으며, 5분 캐시 쓰기는 기본 입력의 1.25배, 1시간 쓰기는 2배로 제시된다. 읽기 비용은 Opus 5.5와 Sonnet 5.5에서 기본 입력의 0.05배, Fable 5.1에서 0.025배이며, 글은 현재 모델의 최소 캐시 가능 프롬프트를 512토큰으로 설명한다. OpenAI는 1,024토큰 이상 프롬프트에서 자동 캐싱을 제공한다고 서술하지만, 제공된 본문은 그다음 설명 도중에 끊긴다. 따라서 제목에 나온 9개 기법 전체, 후반의 에이전트 예산 전략과 역효과 논의, 서두에 제시된 누적 절감 예시의 상세 근거까지 이 자료에서 확인했다고 볼 수는 없다.

🧾 핵심 주장 / 시사점

• 입력 축소의 가치는 최초 요청에서 끝나지 않는다. 도구 결과가 대화 이력에 남는 에이전트에서는 후속 턴마다 같은 절감이 반복될 수 있다.
• 토큰 수 감소와 비용 감소는 동일하지 않다. 출력과 캐시 읽기의 단가 차이가 크므로, 어떤 종류의 토큰을 줄이거나 재사용하는지가 중요하다.
• 검색 결과를 짧게 만드는 효과는 과제 성공률과 함께 판단해야 한다. Firecrawl과 Perplexity 비교는 토큰이 적은 선택이 항상 완료율도 높은 선택은 아님을 보여준다.

✅ 액션 아이템

• 과제별 사용량을 정적 프리픽스·도구 정의·대화 이력·검색·수집 콘텐츠와 출력으로 구분해 측정하고, 가장 큰 입력부터 축소 검토.
• 프롬프트 캐시의 동일한 프리픽스 재사용 여부와 출력의 5배 단가를 함께 고려해 캐시 배치와 출력 제한 적용.
• 단일 사실의 직접 답변·JSON과 전체 문맥의 마크다운을 과제에 맞게 선택하고, Firecrawl과 Perplexity 비교처럼 토큰 사용량과 과제 성공률을 함께 평가.

❓ 열린 질문

• 현재 과제별 입력에서 정적 프리픽스·도구 정의·대화 이력·검색·수집 콘텐츠 중 가장 큰 비중을 차지하는 항목은 무엇인가?
• 동일한 프리픽스를 재사용하는 프롬프트 캐시와 출력 제한을 적용했을 때 비용과 결과 품질은 각각 어떻게 달라지는가?
• 단일 사실의 직접 답변·JSON과 전체 문맥의 마크다운 중 과제 성공률을 유지하면서 토큰 사용량을 줄이는 형식은 무엇인가?