Prompt Caching 을 실제 워크로드에 적용해본 회고

결제·자동화 팀에게 API 비용이 다른 이유

HEDVION은 결제 처리, 정산 조정, 자동화 파이프라인을 외부에 위탁하지 않고 직접 운영하는 작은 팀이다. 이 말의 실질적 의미는 하나다—Claude API 호출 비용이 월말 인보이스에 직접 찍힌다. "AI 도입 비용이 좀 있더라"는 막연한 인식이 아니라, 증가 추이가 보이면 즉시 구조를 손봐야 하는 운영 숫자다.

결제·정산 파이프라인의 특성상 반복 호출은 구조적으로 피하기 어렵다. 가맹점 온보딩 가이드라인, 정산 규정, 카드사별 수수료 정책, 환불 처리 룰—이 문서들은 매주 바뀌지 않는다. 하지만 이를 참조하는 API 호출은 영업 시간 중 하루에 수백~수천 건 발생한다. 시스템 프롬프트에 5,000토큰짜리 정책 문서를 매번 실어 보내면, 비용이 호출 횟수에 선형으로 곱해진다. 이게 Prompt Caching을 실험하게 된 직접적인 계기였다.

실제로 적용한 두 가지 파이프라인

우리가 시험한 시나리오는 구체적으로 두 가지다.

첫 번째: 가맹점 문의 자동 분류 및 응답 초안 생성. 시스템 프롬프트에 결제 정책 문서와 답변 가이드라인이 포함돼 있었고, 이 블록이 약 3,500토큰이었다. 매 요청마다 달라지는 부분은 유저 메시지(평균 200~400토큰)뿐이었다. Claude Sonnet 기준, 입력 토큰 기본 단가는 $3/M이고 캐시 읽기 단가는 $0.30/M—90% 할인이다. 캐시 쓰기는 $3.75/M으로 첫 호출 비용이 소폭 오르지만 두 번째 호출부터 회수된다. 일 800건, 캐시 히트율 85%를 가정하면 일일 시스템 프롬프트 비용이 $8.40에서 $2.30 수준으로 내려간다. 절감액 약 $6/일, 월 $180. 작은 팀 입장에선 무시하기 어려운 숫자다.

두 번째: 월말 정산 배치 분석. PDF에서 추출한 정산 리포트 텍스트가 약 15,000~20,000토큰이다. "이 기간 환불 건 중 수수료 산정 오류를 찾아라", "카드사별 정산 차이가 $50 이상인 항목을 뽑아라" 등 10개 내외의 질문을 같은 문서에 연속으로 던진다. 캐싱 없이는 20,000토큰 × 10회 = 200,000 입력 토큰. 캐싱 적용 후엔 최초 쓰기(25,000토큰 환산) + 이후 9회 읽기(18,000토큰 환산) = 실질 43,000토큰 환산, 약 78% 절감. 배치 한 회당 비용이 눈에 띄게 달라진다.

효과가 난 이유와 숨겨진 전제

두 시나리오 모두에서 효과가 난 이유는 단순하다. "고정된 긴 블록 + 높은 호출 빈도 + TTL 내 재사용" 세 조건을 동시에 충족했기 때문이다. Anthropic의 프롬프트 캐시는 cache_control 마커 이전 블록이 이전 호출과 동일할 때 히트한다. 현재 공개된 TTL은 약 5분이다.

가맹점 문의 파이프라인은 영업 시간 중 연속 호출되기 때문에 TTL 문제가 없었다. 정산 배치는 10개 질문이 수초 내에 연속 발사되므로 마찬가지로 문제없었다. 실제 히트율은 API 응답의 usage.cache_read_input_tokens 필드로 직접 확인했고, 가맹점 파이프라인에서 82~88%를 유지했다.

중요한 교훈은 여기에 있다. 캐싱 자체가 아니라 **"파이프라인이 이 세 조건을 갖추고 있는가"**가 먼저다. 구조가 맞으면 코드 변경은 사실상 cache_control 마커 한 줄 추가다.

기대를 밑돈 케이스: 동적 프롬프트와 간헐적 호출

솔직하게 말하면, 두 케이스에서 캐싱이 거의 역효과를 냈다.

동적 프롬프트 파이프라인. 트랜잭션 이상 탐지 파이프라인에서는 규칙셋, 최근 패턴 요약, 유저별 히스토리를 매 호출마다 새로 조합했다. "고정된 앞부분"이 전체 프롬프트의 30%도 안 됐다. 캐시 히트율이 10~15%에 그쳤고, 매번 쓰기 오버헤드(+25%)만 추가로 쌓였다. 이 파이프라인에서는 캐싱을 끄는 것이 실제로 비용을 낮췄다.

호출 간격이 긴 파이프라인. 주 1회 실행되는 파트너 리포트 생성기는 TTL 5분 안에 재사용 호출이 없다. 매주 월요일 아침에 한 번 돌고 끝이다. 캐시 블록을 쓰고 읽는 구간 자체가 없으니, cache_control을 달아봤자 쓰기 비용 +25%만 붙는다.

트레이드오프를 한 줄로 정리하면: 호출 빈도 × 고정 블록 비율 × TTL 내 재사용 가능성—이 세 값의 곱이 작으면 캐싱은 비용을 올린다. 이 중 하나라도 0에 가까운 파이프라인에는 적용하지 않는 것이 맞다.

설계 단계에서 바꿔야 할 구조

캐싱 효과를 안정적으로 내려면, 프롬프트를 "캐시되는 블록"과 "캐시되지 않는 블록"으로 명시적으로 분리하는 설계가 필요하다. 나중에 리팩터링도 가능하지만, 처음부터 이 구조로 짜는 것이 훨씬 쉽다. 우리가 초기에 실수한 부분도 여기였다—"이것도 넣으면 더 풍부하겠지"라고 유저별 최근 거래 요약을 시스템 프롬프트 블록 안에 넣었다가 히트율이 절반 이하로 내려갔다. 동적 컨텍스트는 반드시 캐시 마커 밖으로 분리해야 한다.

우리가 정착한 패턴은 다음과 같다.

import anthropic

client = anthropic.Anthropic()

# 정적 블록: 결제 규정, 역할 정의, 가이드라인 (~3,500 토큰)
STATIC_SYSTEM = load_payment_guidelines()

def call_with_cache(user_message: str):
    response = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        system=[
            {
                "type": "text",
                "text": STATIC_SYSTEM,
                "cache_control": {"type": "ephemeral"}  # 여기까지만 캐시
            }
        ],
        messages=[
            {"role": "user", "content": user_message}  # 동적 부분: 캐시 밖
        ]
    )
    # 히트율 모니터링
    usage = response.usage
    print(f"cache_read={usage.cache_read_input_tokens}, "
          f"cache_write={usage.cache_creation_input_tokens}")
    return response

배치 문서 분석의 경우, 문서를 첫 번째 턴에서 캐시해두고 질문을 멀티턴으로 이어붙이는 구조가 효과적이다. Anthropic API는 어시스턴트 턴도 캐시 가능하므로, 긴 문서 분석에서는 이 패턴을 적극적으로 활용할 수 있다.

지금 당장 쓸 수 있는 판단 기준

아래 기준으로 파이프라인별 캐싱 도입 여부를 판단하길 권한다. 이론이 아니라 우리 팀이 실제로 사용하는 체크리스트다.

도입하기 좋은 조건 (셋 다 해당하면 즉시 적용):

시스템 프롬프트 또는 공통 문서 블록이 2,000토큰(Sonnet 기준) 이상이고 변경 빈도가 낮다
동일 파이프라인에서 하루 100회 이상 또는 배치 내 10회 이상 연속 호출이 발생한다
연속 호출 간격이 5분 이내로 모이는 구간이 있다

쓰지 말아야 할 조건 (하나라도 해당하면 보류):

프롬프트 앞부분에 유저별·요청별 동적 컨텍스트가 포함된다
파이프라인 호출이 하루 1~2회 수준으로 간헐적이다
전체 프롬프트에서 고정 블록 비중이 50% 미만이다

첫 단계 실행 순서:

운영 중인 파이프라인의 API 호출 로그에서 시스템 프롬프트 토큰 수와 일 호출 횟수를 뽑는다.
절감 예상치($/월) = 시스템 프롬프트 토큰 × 일 호출 수 × 30 × $2.7/M 공식으로 1차 필터링한다 (Sonnet 기준 읽기/쓰기 혼합 절감 단가 근사값).
월 $50 이상 절감이 예상되는 파이프라인부터 cache_control 마커를 추가하고, usage.cache_read_input_tokens 필드로 실제 히트율을 모니터링한다.
히트율이 60% 미만이면 동적 블록이 캐시 범위에 섞인 건 아닌지 프롬프트 구조를 재검토한다. 히트율 70% 이상이 나오면 구조가 맞다.

Prompt Caching은 설정 한 줄로 비용을 줄이는 마법이 아니다. 하지만 결제·정산처럼 반복 규칙 기반의 파이프라인을 운영한다면, 설계 단계에서 "어느 부분이 변하지 않는가"를 먼저 정의하는 습관 하나로 월 수백 달러 단위의 절감이 현실이 된다. 적용 복잡도는 낮고, 효과는 측정 가능하고, 실패해도 cache_control 한 줄 지우면 원복된다. 조건이 맞는 파이프라인이 하나라도 있다면, 내일 당장 해볼 수 있다.