Spring AI 2.0에서 LLM 비용을 줄이는 방법: 10가지 실질적인 제어 방법
요약
Spring AI 2.0을 활용하여 LLM 서비스 운영 시 발생하는 토큰 비용을 효과적으로 제어하는 10가지 방법을 소개합니다. 관찰성 기능을 통한 비용 측정부터 프롬프트 캐싱, RAG 및 도구 호출 최적화까지 실질적인 절감 전략을 다룹니다.
핵심 포인트
- Spring AI 2.0의 관찰성 기능을 통한 모델별 비용 측정 및 최적화
- 프롬프트 캐싱과 대화 기록 범위 제한을 통한 토큰 소모 방지
- RAG 및 도구 호출 시 불필요한 컨텍스트 전송 최소화
- 입력 및 출력 토큰 사용량을 제어하는 프레임워크 차원의 전략
Spring AI의 기본 설정은 빠른 시작을 위해 구축되었습니다. 이는 낮은 월간 비용을 보장하지는 않습니다. LLM 기능을 출시하는 것은 쉽지만, 이를 비용 효율적으로 만드는 것은 쉽지 않습니다. 이 시리즈는 비용이 누수되는 지점과 각 지점을 차단할 수 있는 제어 방법을 보여줍니다.
Spring AI 2.0은 2026년 6월 12일에 GA(General Availability)에 도달했습니다. 이는 Spring Boot 4가 필요하며, 도구 호출(tool-calling) 루프를 ChatModel에서 분리하고, 도구 검색(tool search)을 추가하며, 구조화된 출력(structured outputs)을 확장했습니다. 도구 검색과 확장된 구조화된 출력 제어는 동일한 방향을 가리킵니다. 즉, 애플리케이션이 얼마나 많은 토큰을 보내고 받는지를 결정합니다.
청구 금액은 조용히 늘어납니다. 2,000토큰의 시스템 프롬프트(system prompt)를 가진 챗봇을 한 달에 100,000번 실행하면, 동일한 텍스트 2억 토큰을 전송하게 됩니다. 입력 토큰 100만 개당 1달러라는 예시 요율을 적용하면, 단 한 개의 사용자 메시지가 전달되기도 전에 월 200달러가 발생합니다. 여기에 매 턴마다 전체가 전송되는 대화 기록(conversation history)을 더하십시오. 검색된 RAG(Retrieval-Augmented Generation) 문서와 등록된 모든 도구의 JSON 스키마(JSON schema)를 더하십시오. 입력 측면은 트래픽에 아무런 변화가 없더라도 10배까지 늘어날 수 있습니다. 출력 토큰은 입력 토큰보다 토큰당 비용이 몇 배 더 높으며, 추론 모델(reasoning models)은 숨겨진 "사고(thinking)" 과정도 출력으로 청구합니다.
가격은 제공업체(provider)가 설정합니다. 프레임워크는 여러분이 지불해야 하는 토큰 수를 줄일 수 있는 제어 수단을 제공합니다.
이 시리즈는 #0부터 #9까지 번호가 매겨진 10가지 비용 동인(cost drivers)을 다룹니다. 각 동인은 누군가 의도하지 않았음에도 토큰이 반복되거나 증가하는 지점이며, 각각에는 이를 절감하는 Spring AI 제어 기능이 포함되어 있습니다. 이들은 네 부분으로 나뉩니다. 파트 1은 현재 공개되었습니다. 파트 2에서 4는 2026년 8월에 이어집니다.
파트 1 — 토큰 사용량: 모델을 선택하기 전에 비용을 측정하십시오 (동인 #0–#2)
제공업체(Provider)의 대시보드는 지출 금액은 보여주지만, 어떤 기능이 그 비용을 발생시켰는지는 보여주지 않습니다. Spring AI의 관찰성 (Observability) 기능은 그 간극을 메워주며, 이를 통해 각 모델을 적절한 작업에 매칭하고, 불필요한 기본값을 유지하며 비용을 낭비하는 기능들을 차단할 수 있습니다.
파트 2 — 프롬프트 캐싱 (Prompt Caching) 및 채팅 메모리 (Chat Memory): 토큰이 소모되는 곳 (동인 #3–#5)
이 파트에서는 응답 길이 제한, 재전송되는 대화 기록 (Conversation History)의 범위 제한, 그리고 제공업체의 캐싱 (Caching)이 실제로 작동할 수 있도록 프롬프트를 구조화하는 방법을 다룹니다.
파트 3 — RAG 및 도구 호출 (Tool Calling): 사용하지 않는 컨텍스트에 대한 비용 지불 (동인 #6–#7)
검색된 문서 (Retrieved documents)와 도구 정의 (Tool definitions)는 모델의 필요 여부와 관계없이 모든 요청에 추가됩니다. 이 파트에서는 검색량을 줄이고, 검색된 내용을 정제하며, 도구 스키마 (Tool schemas)가 관련이 있을 때만 전송하는 방법을 다룹니다.
파트 4 — 재시도 (Retries) 및 임베딩 (Embeddings): 실패한 답변과 전체 재인덱싱 (동인 #8–#9)
실패한 응답도 전체 비용이 청구되며, 이를 재시도하면 전체 컨텍스트 (Context)를 다시 전송하게 됩니다. 이 파트에서는 제공업체 수준에서 잘못된 출력 (Malformed output)을 방지하는 방법과 인덱싱 (Indexing) 측면의 방법, 즉 임베딩 모델 선택, 벡터 크기 (Vector size), 배치 처리 (Batching), 그리고 변경된 부분만 재임베딩 (Re-embedding)하는 방법을 다룹니다.
파트 1부터 시작하세요. 이후의 모든 동인은 컨텍스트, 메모리, 응답 길이와 같은 무언가를 절충(Trade-off)할 것을 요구하며, 기능별 지표 (Per-feature metrics)는 어떤 절충이 가치 있는지를 알려줍니다. 파트 1은 또한 가장 저렴하게 변경할 수 있는 방법인 일상적인 작업을 더 작은 모델로 보내는 방법을 다루며, 이는 보통 속성 (Property) 변경만으로 가능합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기