LLM API 비용 90퍼센트 절감하는 토큰 최적화와 캐싱 아키텍처 구축 방법

상용 LLM API를 서비스에 붙이면 초기에는 편리하지만, 사용자가 늘어나는 순간 비용 구조가 빠르게 부담으로 바뀝니다. 특히 고객 문의, 문서 검색, 사내 챗봇처럼 비슷한 질문이 반복되는 서비스에서는 매번 대형 모델을 호출하는 방식이 비효율적입니다. 이 글에서는 시맨틱 캐싱, 프롬프트 압축, 동적 변수 분리, TTL 관리, 불필요한 데이터 필드 제거를 조합해 LLM API 비용을 크게 낮추는 아키텍처를 정리합니다. 조건이 맞는 반복 질의 환경에서는 전체 요청 중 상당수를 캐시로 처리하고, 남은 요청의 입력 토큰까지 줄여 최대 90% 수준의 비용 절감도 노려볼 수 있습니다.

이 글에서 다루는 구축 흐름

1. 사용자 질문을 정규화하고 날짜, 시간, 위치, 상품명 같은 동적 변수를 분리합니다.
2. 정제된 질문을 임베딩 모델로 변환해 벡터 저장소에서 유사한 과거 요청을 검색합니다.
3. 유사도 점수가 기준 이상이면 LLM 호출 없이 검증된 캐시 답변을 반환합니다.
4. 캐시 미스가 발생하면 프롬프트 압축과 컨텍스트 정리를 거쳐 입력 토큰을 줄입니다.
5. 상용 LLM API 호출 후 답변 품질과 캐시 가능 여부를 판단해 저장 대상을 선별합니다.
6. TTL, 도메인별 임계값, 오답 캐시율을 모니터링하며 운영 기준을 조정합니다.

1. LLM API 비용이 빠르게 증가하는 구조

LLM API 비용은 단순히 요청 수만으로 결정되지 않습니다. 대부분의 상용 모델은 입력 토큰과 출력 토큰을 기준으로 과금되기 때문에, 같은 요청 수라도 프롬프트가 길거나 대화 이력이 누적되면 비용이 크게 늘어납니다. 특히 RAG 기반 챗봇은 검색된 문서 조각을 프롬프트에 함께 넣기 때문에 입력 토큰이 쉽게 커집니다.

예를 들어 하루 5만 건의 요청이 들어오고, 요청 1건당 평균 입력 2,500토큰과 출력 700토큰이 사용된다고 가정해 보겠습니다. 단순 계산으로도 하루에 약 1억 6천만 개 이상의 토큰이 발생합니다. 여기에 사용자가 늘고 대화 이력이 길어지면 비용은 선형이 아니라 체감상 훨씬 빠르게 증가합니다.

비용을 줄이는 핵심 방향

LLM 비용 최적화는 모델 단가를 낮추는 것만으로 해결되지 않습니다. 먼저 호출하지 않아도 되는 요청을 캐시로 처리하고, 호출이 필요한 요청은 입력 토큰을 줄이며, 실시간성이 필요한 데이터는 캐시 대상에서 분리해야 합니다. 즉, 비용 절감의 핵심은 “모델 호출 수 감소”와 “호출당 토큰 수 감소”를 동시에 달성하는 것입니다.

2. 시맨틱 캐싱이 필요한 이유

일반적인 Key-Value 캐싱은 완전히 같은 문자열이 들어왔을 때만 작동합니다. 하지만 실제 사용자는 같은 의도를 여러 방식으로 표현합니다.

• 비밀번호 바꾸는 방법 알려줘
• 패스워드 변경은 어디서 하나요?
• 로그인 비번을 수정하고 싶어요

세 문장은 표현이 다르지만 의도는 거의 같습니다. 문자열 기준 캐싱에서는 모두 다른 요청으로 처리되지만, 시맨틱 캐싱은 문장을 벡터로 변환한 뒤 의미적으로 가까운 질문인지 판단합니다. 유사한 질문이 이미 처리된 적 있다면 LLM을 다시 호출하지 않고 기존 답변을 재사용할 수 있습니다.

그림 1. 시맨틱 캐싱 흐름: 질문의 의미를 벡터로 비교해 LLM 호출 여부를 결정하는 구조

이 방식은 고객센터 FAQ, 사내 문서 검색, 제품 사용법 안내, 반복되는 기술 지원 질문에서 특히 효과가 좋습니다. 반대로 실시간 가격, 재고, 날씨, 금융 시세처럼 값이 계속 바뀌는 데이터는 캐시 처리에 주의해야 합니다.

이러한 백엔드 최적화와 트래픽 제어 메커니즘은 앞서 다룬 AI API 게이트웨이 관리 전략에서 설명한 게이트웨이 설계와 함께 적용하면 더 안정적으로 운영할 수 있습니다.

3. 비용 90% 절감이 가능한 조건과 계산 예시

LLM API 비용을 90% 줄인다는 표현은 모든 서비스에 그대로 적용되는 숫자는 아닙니다. 다만 반복 질문 비중이 높고, 긴 프롬프트를 자주 사용하는 서비스라면 현실적인 목표가 될 수 있습니다. 핵심은 캐시 히트율과 프롬프트 압축률을 함께 보는 것입니다.

항목	최적화 전	최적화 후 예시
월 요청 수	1,000,000건	1,000,000건
캐시 히트율	0%	70%
LLM 실제 호출 수	1,000,000건	300,000건
평균 입력 토큰	2,500토큰	1,200토큰
입력 토큰 사용량	25억 토큰	3억 6천만 토큰

위 예시에서는 캐시만 적용해도 LLM 호출 수가 70% 줄어듭니다. 여기에 프롬프트 압축으로 남은 요청의 입력 토큰을 2,500토큰에서 1,200토큰으로 줄이면 입력 토큰 기준 사용량은 약 85% 이상 감소합니다. 출력 토큰 절감, 중복 문서 제거, 모델 라우팅까지 함께 적용하면 전체 비용 기준으로 90%에 가까운 절감도 가능합니다.

중요한 점은 절감률을 캐시 히트율 하나로만 판단하면 안 된다는 것입니다. 실제 운영에서는 캐시 히트율, 오답 캐시율, 평균 입력 토큰, 평균 출력 토큰, 모델별 단가, 임베딩 비용까지 함께 계산해야 합니다.

4. 시맨틱 캐싱 기본 아키텍처

시맨틱 캐싱은 단순히 벡터 저장소를 붙이는 것으로 끝나지 않습니다. 질문 정규화, 동적 변수 탐지, 유사도 검색, 캐시 가능성 판단, TTL 관리가 하나의 흐름으로 묶여야 합니다.

권장 처리 순서

1. 사용자 질문에서 불필요한 공백, 특수문자, 반복 문장을 정리합니다.
2. 날짜, 시간, 위치, 주문번호, 사용자명, 상품명 같은 변수를 탐지합니다.
3. 실시간성이 높은 정보는 캐시 키 또는 메타데이터로 분리합니다.
4. 정제된 질문을 임베딩 벡터로 변환합니다.
5. Redis Vector Search, Milvus, Qdrant, Pinecone 같은 벡터 저장소에서 유사 질문을 찾습니다.
6. 유사도 점수와 도메인 규칙을 함께 확인해 캐시 반환 여부를 결정합니다.
7. 캐시 미스라면 프롬프트 압축 후 LLM을 호출합니다.
8. 답변 품질, 저장 조건, TTL 기준을 통과한 결과만 캐시에 저장합니다.

이 흐름에서 가장 중요한 단계는 동적 변수 분리입니다. 예를 들어 “오늘 서울 날씨 알려줘”와 “어제 부산 날씨 알려줘”는 문장 구조가 비슷해 벡터 유사도가 높게 나올 수 있습니다. 하지만 두 질문은 답변이 완전히 달라야 합니다. 이런 요청을 그대로 캐싱하면 빠르지만 틀린 답변을 반환하는 문제가 생깁니다.

5. 임계값 튜닝 기준

임계값은 시맨틱 캐싱의 성능과 안전성을 동시에 좌우합니다. 기준을 너무 높게 잡으면 캐시가 거의 작동하지 않고, 너무 낮게 잡으면 다른 질문에 과거 답변이 잘못 매칭될 수 있습니다.

서비스 유형	초기 유사도 기준	운영 포인트
일반 FAQ	0.85~0.90	반복 질문이 많아 캐시 효과가 크지만, 신규 질문 샘플을 함께 검수해야 합니다.
기술 문서 검색	0.88~0.92	버전, 라이브러리명, 환경 차이를 메타데이터로 분리해야 합니다.
금융·법률·의료 보조 정보	0.93 이상 또는 별도 검수 후 적용	오답 비용이 크므로 캐시 적용 범위를 보수적으로 제한해야 합니다.
재고·가격·날씨·시세	캐시 제한	실시간 API 호출 영역과 일반 설명 영역을 분리하는 편이 안전합니다.

처음부터 완벽한 임계값을 정하기는 어렵습니다. 운영 초기에는 실제 질문 로그를 샘플링해 캐시 후보와 실제 정답의 일치 여부를 검수해야 합니다. 이때 캐시 히트율만 높이는 것은 위험합니다. 반드시 오답 캐시율을 함께 추적해야 합니다.

6. 구현 흐름을 이해하기 위한 간단한 의사코드

아래 예시는 실제 서비스 코드를 그대로 대체하기 위한 것이 아니라, 시맨틱 캐싱 게이트웨이가 어떤 순서로 동작하는지 이해하기 위한 간단한 구조입니다. 실제 파라미터명은 사용하는 벡터 데이터베이스나 클라이언트 라이브러리에 따라 달라질 수 있습니다.

def handle_user_query(user_query, user_context):
    normalized_query = normalize_text(user_query)
    variables = extract_dynamic_variables(normalized_query)

    if requires_realtime_lookup(normalized_query, variables):
        prompt = build_prompt_without_cache(normalized_query, user_context)
        compressed_prompt = compress_prompt(prompt)
        return call_llm_api(compressed_prompt)

    query_vector = embed_text(normalized_query)

    cached_item = vector_store.search(
        vector=query_vector,
        top_k=1,
        metadata_filter={
            "domain": user_context.domain,
            "language": "ko"
        }
    )

    if cached_item and cached_item.score >= get_threshold(user_context.domain):
        if not is_expired(cached_item) and is_variable_compatible(cached_item, variables):
            return cached_item.answer

    prompt = build_prompt(normalized_query, user_context)
    compressed_prompt = compress_prompt(prompt)

    answer = call_llm_api(compressed_prompt)

    if is_cacheable(answer, normalized_query, variables):
        vector_store.upsert({
            "vector": query_vector,
            "question": normalized_query,
            "answer": answer,
            "domain": user_context.domain,
            "ttl": decide_ttl(user_context.domain),
            "created_at": now()
        })

    return answer

이 구조에서 눈여겨볼 부분은 캐시를 무조건 저장하지 않는다는 점입니다. 실시간 값이 포함된 답변, 사용자 개인 정보가 들어간 답변, 품질이 낮은 답변, 모델이 불확실하게 답한 결과는 캐시 저장 대상에서 제외하는 편이 안전합니다.

7. 프롬프트 압축과 토큰 트리밍

캐시 미스가 발생하면 결국 LLM API를 호출해야 합니다. 이때 비용을 줄이는 두 번째 축이 프롬프트 압축입니다. 특히 RAG 시스템에서는 검색된 문서를 그대로 프롬프트에 넣는 경우가 많은데, 이 방식은 정확도 개선보다 비용 증가가 먼저 문제가 될 수 있습니다.

그림 2. 프롬프트 압축 파이프라인: 불필요한 문장을 줄이고 핵심 컨텍스트만 모델에 전달하는 구조

프롬프트 압축은 단순히 문장을 짧게 만드는 작업이 아닙니다. 모델 답변에 필요한 정보는 남기고, 비용만 증가시키는 중복 문장과 낮은 관련도의 문서를 제거하는 과정입니다.

또한 API로 전달하는 JSON 데이터에서도 불필요한 필드는 제거하는 것이 좋습니다. 화면 표시용 문구, 중복 메타데이터, 이미 검색 단계에서 사용된 내부 점수값까지 모두 프롬프트에 포함하면 토큰 사용량만 늘어납니다. 모델이 실제 답변에 참고해야 하는 필드만 남기면 입력 토큰을 더 안정적으로 줄일 수 있습니다.

압축 대상	처리 방식	주의할 점
중복 문서 조각	유사 문단 제거	서로 다른 버전의 문서가 섞이지 않도록 메타데이터를 확인합니다.
낮은 관련도 컨텍스트	검색 점수 기준 하위 문서 제외	점수만 보지 말고 질문 키워드 포함 여부를 함께 봅니다.
긴 대화 이력	최근 대화와 요약본만 유지	사용자 요구사항, 금지 조건, 안전 지시문은 삭제하면 안 됩니다.
불필요한 서식	마크다운, HTML, 반복 공백 정리	표나 코드처럼 구조가 중요한 정보는 무리하게 압축하지 않습니다.
불필요한 JSON 필드	답변 생성에 필요한 필드만 유지	모델이 판단에 써야 하는 식별자나 상태값은 삭제하지 않습니다.

전체 인프라의 리소스 가용성을 높이고 낭비되는 연산 비용을 통제하는 전략은 AX 운영 비용 40% 절감법에서 다룬 인프라 효율화 방식과도 연결됩니다. 긴 대화 이력은 슬라이딩 윈도우와 요약 저장 방식을 함께 사용하면 토큰 누적을 효과적으로 줄일 수 있습니다.

8. 벡터 저장소에 저장할 데이터 구조

시맨틱 캐싱을 안정적으로 운영하려면 질문과 답변만 저장해서는 부족합니다. 나중에 캐시를 재사용해도 되는지 판단할 수 있도록 도메인, 생성 시점, TTL, 변수 정보, 답변 품질 점수 같은 메타데이터를 함께 보관해야 합니다.

필드명	데이터 타입	운영 목적
question_vector	Embedding Vector	정규화된 질문을 임베딩한 벡터입니다. 차원 수는 사용하는 임베딩 모델에 따라 달라집니다.
normalized_question	String	공백, 표현 차이, 불필요한 문자를 정리한 질문 원문입니다.
cached_answer	String 또는 JSON	재사용 가능한 답변입니다. 화면 렌더링 구조가 필요하면 JSON 형태로 저장할 수 있습니다.
similarity_threshold	Float	캐시 반환을 허용하는 최소 유사도 기준입니다. 도메인별로 다르게 설정하는 편이 안전합니다.
dynamic_variables	Object	날짜, 위치, 상품명, 버전 정보처럼 답변을 바꿀 수 있는 요소를 저장합니다.
ttl_seconds	Integer	캐시 유효 시간을 관리합니다. 변동성이 큰 정보일수록 짧게 설정합니다.
quality_score	Float 또는 Integer	답변 품질 검수 결과를 저장합니다. 낮은 점수의 답변은 캐시 반환에서 제외합니다.

서버 자원의 실시간 모니터링과 병목 진단은 AX 시스템 관측성 구축 방법에서 다룬 지표 설계와 함께 적용하면 좋습니다. 캐싱 시스템도 결국 운영 지표가 없으면 성능을 개선하기 어렵습니다.

9. TTL과 캐시 제외 기준

시맨틱 캐싱에서 가장 위험한 문제는 오래된 답변을 너무 자신 있게 반환하는 것입니다. 따라서 모든 답변을 같은 기간 동안 저장하면 안 됩니다. 정보의 변동성에 따라 TTL을 다르게 설정해야 합니다.

정보 유형	권장 TTL	운영 기준
제품 사용법, 계정 설정 안내	7~30일	정책이나 UI가 바뀌면 수동으로 캐시를 무효화합니다.
사내 문서 기반 답변	1~7일	문서 버전과 수정일을 메타데이터로 함께 관리합니다.
가격, 재고, 배송 상태	수초~수분 또는 제외	실시간 API 조회 결과와 일반 설명을 분리합니다.
사용자 개인화 답변	공유 캐시 제외	개인 정보가 섞일 수 있으므로 전역 캐시에 저장하지 않습니다.

특히 사용자별 정보가 들어가는 답변은 전역 캐시에 저장하면 안 됩니다. 주문 내역, 계정 상태, 결제 정보, 개인 설정처럼 특정 사용자에게만 해당되는 내용은 세션 캐시나 사용자 단위 캐시로 분리해야 합니다.

10. 운영 전에 반드시 확인할 검증 기준

시맨틱 캐싱은 비용을 줄이는 데 효과적이지만, 잘못 적용하면 틀린 답변을 빠르게 반환하는 시스템이 될 수 있습니다. 배포 전에는 아래 기준을 반드시 점검해야 합니다.

1. 질문 정규화 과정에서 핵심 단어가 삭제되지 않는지 확인합니다.
2. 날짜, 시간, 위치, 버전, 상품명 같은 변수를 캐시 판단에 반영합니다.
3. 임베딩 처리 지연이 길어질 경우 원본 LLM 호출로 우회하는 페일세이프 경로를 둡니다.
4. 유사도 점수가 기준보다 낮은 요청은 절대 캐시로 반환하지 않습니다.
5. 답변 품질이 낮거나 불확실한 결과는 캐시에 저장하지 않습니다.
6. 개인 정보가 포함된 답변은 전역 캐시에서 제외합니다.
7. 캐시 히트율, 오답 캐시율, 평균 토큰 수, 평균 응답 시간을 함께 모니터링합니다.

배포 전 체크리스트

• ✅ 질문에서 날짜, 시간, 위치, 버전 정보를 분리하고 있나요?
• ✅ 캐시 히트율뿐 아니라 잘못 반환된 답변 비율도 확인하고 있나요?
• ✅ 프롬프트 압축 과정에서 안전 지시문과 핵심 조건이 삭제되지 않도록 보호하고 있나요?
• ✅ 오래된 캐시를 자동으로 제거하거나 무효화하는 기준이 있나요?
• ✅ 실시간 API 조회가 필요한 요청을 캐시 대상에서 분리하고 있나요?

11. 실제 운영에서 자주 생기는 문제

시맨틱 캐싱을 처음 도입할 때 가장 흔한 실수는 캐시 히트율만 보고 성공 여부를 판단하는 것입니다. 캐시 히트율이 높아도 오답이 섞이면 고객 경험은 더 나빠질 수 있습니다. 따라서 비용 지표와 품질 지표를 반드시 함께 봐야 합니다.

문제 상황	원인	해결 방법
비슷하지만 다른 질문에 같은 답변 반환	임계값이 낮거나 변수 분리가 부족함	임계값을 올리고 날짜, 위치, 버전 정보를 필터에 반영합니다.
캐시가 거의 작동하지 않음	임계값이 너무 높거나 질문 정규화가 부족함	표현 차이를 줄이는 정규화 과정을 추가하고 임계값을 실험합니다.
오래된 정책 답변이 계속 노출됨	TTL 또는 문서 버전 관리 부재	문서 수정일 기준으로 캐시를 무효화합니다.
토큰 절감 효과가 작음	검색 문서와 대화 이력을 그대로 전달함	중복 문서 제거, 요약본 유지, 관련도 낮은 컨텍스트 제외를 적용합니다.

12. 토큰 비용 절감 및 캐싱 실무 Q&A

Q. 시맨틱 캐싱을 쓰면 답변 정확도가 떨어질 수 있나요?

A. 잘못 설계하면 정확도가 떨어질 수 있습니다. 특히 유사도 기준이 낮거나 날짜, 위치, 버전 같은 변수를 분리하지 않으면 다른 질문에 과거 답변이 잘못 붙을 수 있습니다. 그래서 초기에는 임계값을 보수적으로 잡고, 실제 질문 로그를 보면서 오답 캐시율을 확인하는 방식이 안전합니다.

Q. 실시간 재고나 가격 정보도 캐싱할 수 있나요?

A. 가능은 하지만 매우 짧은 TTL을 두거나 캐시 대상에서 제외하는 편이 안전합니다. 재고, 가격, 배송 상태, 금융 시세처럼 자주 바뀌는 값은 실시간 API 조회와 연결하고, 변하지 않는 설명 문구나 사용 방법만 캐시하는 구조가 좋습니다.

Q. 프롬프트 압축을 하면 모델 답변 품질이 낮아지지 않나요?

A. 무리하게 줄이면 품질이 낮아질 수 있습니다. 압축의 목적은 정보를 없애는 것이 아니라 중복과 낮은 관련도 문맥을 제거하는 것입니다. 시스템 지시문, 사용자 요구사항, 안전 조건, 핵심 근거 문서는 보호 대상으로 두고 나머지 부분을 줄이는 방식이 안정적입니다.

Q. 비용 절감을 위해 더 저렴한 모델만 쓰면 안 되나요?

A. 저렴한 모델로 바꾸는 것도 방법이지만, 그것만으로는 한계가 있습니다. 반복 질문을 계속 모델에 보내면 단가가 낮아져도 비용은 계속 쌓입니다. 먼저 캐싱으로 호출 수를 줄이고, 그다음 요청 난이도에 따라 소형 모델과 고성능 모델을 나누어 쓰는 방식이 더 효율적입니다.

결론: 비용 최적화는 모델 호출 전에 결정됩니다

LLM API 비용을 줄이려면 모델을 호출한 뒤에 고민해서는 늦습니다. 사용자 질문이 들어오는 순간부터 캐시로 처리할 수 있는지, 실시간 정보가 포함되어 있는지, 프롬프트를 줄일 수 있는지 판단해야 합니다. 시맨틱 캐싱은 반복 질문의 모델 호출을 줄이고, 프롬프트 압축은 어쩔 수 없이 호출해야 하는 요청의 토큰 사용량을 낮춥니다.

가장 안정적인 구조는 캐싱, 압축, TTL, 동적 변수 분리, 모델 라우팅을 함께 적용하는 방식입니다. 캐시 히트율이 높은 서비스라면 LLM 호출 수 자체가 크게 줄고, 긴 문서를 다루는 RAG 서비스라면 입력 토큰 최적화 효과가 큽니다. 여기에 오답 캐시율과 응답 지연 시간을 함께 모니터링하면 비용 절감과 품질 관리 사이의 균형을 맞출 수 있습니다.

결국 LLM 비용 최적화의 핵심은 단순합니다. 매번 대형 모델을 호출하지 않고, 호출해야 할 때도 꼭 필요한 정보만 보내는 것입니다. 이 원칙을 게이트웨이 단계에서 체계화하면 트래픽이 늘어나도 비용이 같은 속도로 폭증하지 않는 운영 구조를 만들 수 있습니다.

🔀 토큰 최적화를 넘어 난이도 기반 멀티 모델 라우팅 계층으로

시맨틱 캐싱과 토큰 압축 정제로 1차 과금 방어선을 세팅했다면, 이제는 캐시 미스가 발생한 나머지 트래픽의 경로를 교통정리 할 차례입니다. 다음 리포트 오픈소스 LLM 전환과 비용 기반 멀티 모델 라우팅 아키텍처 구축 방법에서 유입 질문의 난이도를 실시간 평가하여 사내 프라이빗 GPU 자원과 상용 API 엔드포인트로 동적 분기하는 하이브리드 인프라 설계법을 확인해 보세요.

디지털 아키텍트 (Digital Architect)