긴 시스템 프롬프트를 쓰는 팀이라면 지금 가장 먼저 챙겨야 할 최적화는 새 모델 교체보다 prompt caching입니다. 검색 의도가 분명한 키워드로 보면 prompt caching, LLM cost optimization, long system prompt, cache-friendly prompt design이 핵심입니다. 이유는 단순합니다. 실제 운영에서는 사용자의 질문보다 내부 지시문이 더 길어지는 경우가 많고, 그 비용과 지연이 눈덩이처럼 커지기 때문입니다.
Datadog의 State of AI Engineering 2026 보고서는 입력 토큰의 69%가 시스템 프롬프트, 정책 정의, 툴 안내 같은 내부 지시문에서 나왔다고 설명합니다. 이 숫자는 꽤 충격적이지만, 현업에선 낯설지 않습니다. 브랜드 가이드, 응답 정책, 구조화 출력 규칙, tool schema, example 몇 개만 붙여도 금방 1,000토큰을 넘습니다. 문제는 이 정적인 내용을 매 요청마다 새로 계산하면 비용과 지연이 그대로 반복된다는 점입니다.
OpenAI 문서 기준으로 prompt caching은 반복되는 프롬프트 prefix를 자동으로 재사용해서 지연을 최대 80%, 입력 토큰 비용을 최대 90%까지 줄일 수 있습니다. 별도 코드 변경 없이 켜지는 부분도 장점이지만, 그렇다고 아무 구조에서나 잘 되는 건 아닙니다.
핵심은 단 하나입니다. 정확히 같은 prefix가 반복돼야 합니다.
즉 아래처럼 생각하면 됩니다.
이 순서를 어기면 캐시가 있어도 못 씁니다.
대개 이유는 기능 문제가 아니라 프롬프트 구조 문제입니다.
예를 들어 첫 줄부터 고객 이름, 계정 상태, 최근 주문 내역을 붙이면 prefix가 매번 바뀝니다. 공통 지시문이 뒤에 있어도 이미 늦었습니다.
“친절하게 답해라”가 어떤 요청에서는 “간결하고 친절하게 답해라”로 바뀌고, 다른 요청에서는 예제가 하나 더 붙습니다. 이 작은 차이가 캐시 적중을 깨뜨립니다.
도구 목록과 설명을 매 요청마다 재조합하면 prefix 일관성이 무너집니다.
가끔은 예제 2개, 가끔은 4개, 순서도 매번 다르면 캐시가 거의 맞지 않습니다.
팀원이 시스템 프롬프트를 슬쩍 수정하면 그 순간부터 캐시 패턴이 바뀝니다. 성능 저하 원인을 찾기도 어렵습니다.
실무에서는 아래 4단 구조가 가장 단순하고 효과적입니다.
절대 자주 바뀌지 않는 규칙만 모읍니다.
이 블록은 가장 앞에 둡니다.
같은 업무군에서 반복되는 정보입니다.
이 블록도 최대한 고정합니다.
few-shot이 필요하다면 예제를 자주 바꾸지 말고 버전 단위로 묶습니다. support-v3-example-set처럼 관리하면 좋습니다.
맨 뒤에 이번 요청만의 정보를 붙입니다.
이렇게 해야 앞의 큰 덩어리가 재사용됩니다.
이 구조는 앞부분이 매번 바뀌기 때문에 캐시 효율이 낮습니다.
같은 정보를 써도 순서만 바꿔서 효과가 크게 달라집니다.
OpenAI 문서에는 prompt_cache_key를 제공하면 라우팅 효율을 높여 캐시 적중 가능성을 더 끌어올릴 수 있다고 나옵니다. 특히 긴 공통 prefix를 여러 요청이 공유하는 환경에서 유리합니다.
실무적으로는 아래 상황에서 검토할 만합니다.
예를 들어 support-enterprise-v2, code-review-ruby-v1 같은 단위로 캐시 키 전략을 세울 수 있습니다.
유연해 보여도 캐시에 불리합니다. 특히 문자열 템플릿이 많을수록 미세 차이로 prefix가 깨집니다.
디버깅에는 편하지만 비용엔 나쁩니다. 메타는 뒤로 보내거나 별도 구조화 필드로 분리하는 편이 낫습니다.
few-shot 성능이 좋아질 수도 있지만 캐시 이득을 잃을 수 있습니다. 자주 쓰는 몇 개의 예제 세트로 표준화하는 게 더 실용적일 때가 많습니다.
단순히 지원 여부만 아는 걸로는 부족합니다. 아래 항목을 같이 보면 좋습니다.
공식적으로 캐시 hit metric을 직접 받지 못하더라도, 프롬프트 구조와 지연/비용 변화를 비교하면 충분히 개선 방향을 잡을 수 있습니다.
특히 아래 팀은 우선순위가 높습니다.
이 팀들은 모델 교체보다 prompt layout만 손봐도 체감 개선이 큽니다.
이 작업은 거창하지 않습니다. 그런데 잘 하면 비용, 속도, 운영 일관성이 같이 좋아집니다.
많은 팀이 prompt caching을 “플랫폼이 알아서 해주는 최적화” 정도로 봅니다. 반은 맞고 반은 틀립니다. 기능은 자동이어도, 효과는 설계에 달려 있습니다. 정적 prefix를 얼마나 안정적으로 유지하느냐가 성패를 가릅니다.
긴 시스템 프롬프트를 매번 새로 계산하는 팀은 모델 성능보다 먼저 프롬프트 배치를 봐야 합니다. 특히 long system prompt가 많은 서비스라면 prompt caching은 옵션이 아니라 기본기입니다.
좋은 프롬프트는 답을 잘 뽑는 프롬프트이기도 하지만, 반복 요청에서 싸고 빠르게 재사용되는 프롬프트이기도 합니다.
참고 소스:
