[LLM] 캐싱 전략(Prompt Caching): 중복 프롬프트 비용을 0원으로 만드는 법

LLM을 서비스에 붙이고 나면 처음에는 기능이 잘 동작하는지만 보게 됩니다. 그런데 트래픽이 조금만 붙기 시작하면 갑자기 눈에 들어오는 숫자가 하나 있습니다. 바로 API 비용입니다. 

Prompt Caching 캐싱 전략으로 LLM 프롬프트 비용 줄이기

Prompt Caching 전략은 LLM 서비스를 운영할 때 생각보다 큰 비용을 절약할 수 있는 방법입니다. 특히 동일한 프롬프트가 반복적으로 호출되는 서비스라면 Prompt Caching만으로도 비용이 크게 줄어드는 경우가 있습니다. 

 

Real world Issue

LLM 기반 FAQ 챗봇을 하나 운영한 적이 있습니다. 처음에는 트래픽이 많지 않았습니다. 하루 요청이 2천 건 정도였습니다. 그래서 비용도 크게 신경 쓰지 않았습니다.

그런데 서비스에 사용자들이 붙기 시작하면서 상황이 조금 달라졌습니다. 하루 요청이 2천 건에서 3만 건 수준으로 올라갔습니다. 체감상 그렇게 큰 숫자는 아니라고 생각했습니다.

문제는 같은 질문이 계속 반복된다는 점이었습니다. 예를 들어 환불 정책이나 배송 기간 같은 질문이 계속 들어왔습니다. 운영하면서 로그를 보면 같은 프롬프트가 계속 반복됩니다. 생각보다 자주 발생합니다.

 

Pain Point

당시 LLM API 호출 비용을 분석해보니 조금 흥미로운 결과가 나왔습니다. 하루 요청은 약 3만 건이었는데 실제 질문 패턴은 약 800개 정도였습니다.

즉 동일한 질문이 계속 반복되고 있었습니다. 같은 질문인데도 매번 LLM API를 호출하고 있었습니다.

당시 비용을 계산해보니 하루 비용이 약 35달러 정도였습니다. 한 달로 계산하면 약 천 달러 수준입니다. 트래픽이 더 올라가면 비용이 꽤 빠르게 증가할 것 같았습니다.

LLM 서비스 운영을 해보면 여기서 고민이 시작됩니다. 기능은 잘 동작하지만 비용이 점점 올라가기 시작합니다. 체감상 대부분 이 지점에서 캐싱 전략을 고민하게 됩니다.

 

Decision Process

문제를 해결하기 위해 두 가지 방법을 고민했습니다.

첫 번째 방법은 단순 캐싱 전략입니다. 프롬프트를 그대로 키로 사용해서 Redis에 결과를 저장하는 방식입니다.

장점은 구현이 매우 간단합니다. Redis 캐시를 하나 두고 프롬프트를 키로 사용하면 됩니다.

단점도 있습니다. 프롬프트가 조금만 달라도 캐시가 동작하지 않습니다. 예를 들어 띄어쓰기 하나만 달라도 다른 요청으로 인식됩니다.

두 번째 방법은 Prompt Hash 기반 캐싱입니다. 프롬프트를 정규화한 뒤 해시 키를 만들어 캐싱하는 방식입니다.

장점은 중복 프롬프트를 훨씬 잘 잡아낼 수 있다는 점입니다. 약간 다른 표현도 동일 질문으로 처리할 수 있습니다.

단점은 구현이 조금 복잡합니다. 프롬프트 정규화 로직이 필요합니다.

결국 두 번째 방식을 선택했습니다. 이유는 단순합니다. 실제 운영에서는 질문이 완전히 동일하지 않은 경우가 많습니다.

 

Practical Implementation

실제 구현은 Redis 캐시를 기반으로 구성했습니다. 핵심은 프롬프트를 그대로 사용하지 않고 해시 키로 변환하는 것입니다.

import java.security.MessageDigest;

public String generatePromptKey(String prompt) {

    // 공백 제거 및 소문자 변환
    String normalized = prompt.trim().toLowerCase();

    // 운영에서 같은 질문을 잡기 위해 기본 정규화
    normalized = normalized.replaceAll("\\s+", " ");

    return sha256(normalized);
}

Redis 캐시는 다음과 같은 구조로 사용했습니다.

String key = "prompt_cache:" + generatePromptKey(prompt);

String cached = redis.get(key);

if(cached != null){
    return cached;
}

// 캐시 없으면 LLM 호출
String result = llmClient.generate(prompt);

// 결과 캐싱
redis.setex(key, 86400, result);

// 하루 캐시
// 운영 경험상 FAQ는 하루 캐시로도 충분했습니다

이 방식으로 변경한 이후 결과가 꽤 흥미로웠습니다. 전체 요청의 약 72퍼센트가 캐시에서 처리되었습니다.

LLM API 호출 수가 하루 3만 건에서 약 8천 건 수준으로 줄었습니다. 비용도 하루 35달러에서 약 9달러 수준으로 떨어졌습니다.

이거 운영에서 한번 적용해보면 체감이 확실합니다. 캐시 하나로 비용이 크게 줄어드는 경험을 하게 됩니다.

 

Cold Truth

다만 Prompt Caching이 모든 문제를 해결해 주는 것은 아닙니다. 질문이 매우 다양한 서비스에서는 캐시 히트율이 낮을 수 있습니다.

또한 캐시된 응답이 오래되면 정보가 틀릴 수도 있습니다. 특히 정책이나 가격 정보가 자주 변경되는 서비스에서는 주의해야 합니다.

결국 캐싱 전략은 서비스 특성에 맞게 조정해야 합니다. TTL 설정이나 캐시 무효화 전략도 같이 고민해야 합니다.

그래도 한 가지는 분명합니다. LLM 서비스를 운영한다면 Prompt Caching은 거의 필수 전략입니다. 생각보다 많은 비용이 중복 프롬프트에서 발생합니다.