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

Prompt caching 기능이 공개됐을 때, 우리 팀은 꽤 빠르게 시험 적용을 해봤다. 반복 호출이 많은 파이프라인이 있었기 때문이다. 몇 주 동안 사용해보면서 얻은 관찰을 솔직하게 공유한다.

어떤 상황에서 써봤나

우리가 적용한 시나리오는 두 가지였다. 첫째는 공통 시스템 프롬프트를 매 요청마다 반복 전송하는 파이프라인이었다. 긴 가이드라인 문서나 역할 정의가 포함된 프롬프트가 여기에 해당했다. 둘째는 같은 문서를 참조하면서 여러 질문을 연속으로 처리하는 배치 작업이었다.

효과가 있었던 것

공통 시스템 프롬프트 캐싱은 비용 절감이 눈에 띄었다. 프롬프트가 길고 호출 빈도가 높을수록 효과가 컸다. 입력 토큰 비용이 캐시 히트 시 크게 낮아지기 때문에, 반복성이 높은 구조라면 도입 가치가 충분하다.

# 캐싱 가능한 구조 (단순화된 예시)
system_prompt = load_static_guidelines()  # 길고 변하지 않는 부분
user_context = build_user_context(request)  # 매 요청마다 달라지는 부분

messages = [
    {"role": "system", "content": system_prompt},  # 캐시 대상
    {"role": "user", "content": user_context}
]

응답 지연도 캐시 히트 시 줄어드는 경향이 있었다. 전체 프롬프트를 처음부터 처리하지 않기 때문에 자연스러운 결과다.

기대보다 효과가 낮았던 것

프롬프트 구조가 자주 바뀌는 경우에는 캐시 히트율이 낮았다. 캐싱은 프롬프트가 동일할 때 작동하기 때문에, 동적으로 조합되는 프롬프트가 많으면 캐시가 거의 쓸모가 없었다. 설계 단계에서 “어느 부분을 고정으로 둘 것인가”를 의식적으로 정해야 캐싱 효과를 볼 수 있다.

또한 캐시 유효 기간이 있기 때문에 호출 간격이 길면 캐시 미스가 발생한다. 우리 워크로드 중 간헐적으로만 호출되는 파이프라인에서는 체감 효과가 거의 없었다.

지금의 결론

Prompt caching 은 공짜 최적화가 아니다. 호출 빈도가 높고, 공통 부분이 길고 고정적인 파이프라인에서는 비용과 속도 양쪽으로 효과가 있다. 하지만 이 조건이 맞지 않으면 적용 복잡성 대비 이득이 크지 않다.

프롬프트 설계 단계에서부터 “캐시 가능한 부분”을 앞에 두는 구조를 의식하면 나중에 적용하기 훨씬 쉬워진다. 이 점이 이번 경험에서 얻은 가장 실용적인 교훈이었다.

— by mings