프롬프트 캐싱 실전 가이드: 긴 시스템 프롬프트 비용 줄이는 구조화 방법

긴 시스템 프롬프트를 쓰는 팀이라면 지금 가장 먼저 챙겨야 할 최적화는 새 모델 교체보다 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토큰을 넘습니다. 문제는 이 정적인 내용을 매 요청마다 새로 계산하면 비용과 지연이 그대로 반복된다는 점입니다.

prompt caching이 실제로 뭘 줄여주나

OpenAI 문서 기준으로 prompt caching은 반복되는 프롬프트 prefix를 자동으로 재사용해서 지연을 최대 80%, 입력 토큰 비용을 최대 90%까지 줄일 수 있습니다. 별도 코드 변경 없이 켜지는 부분도 장점이지만, 그렇다고 아무 구조에서나 잘 되는 건 아닙니다.

핵심은 단 하나입니다. 정확히 같은 prefix가 반복돼야 합니다.

즉 아래처럼 생각하면 됩니다.

• 앞부분: 거의 안 바뀌는 시스템 프롬프트, 정책, 예제, 툴 설명
• 뒷부분: 사용자 질문, 세션 데이터, 현재 문서, 이번 요청만의 변수

이 순서를 어기면 캐시가 있어도 못 씁니다.

왜 많은 팀이 캐시를 켜놓고도 효과를 못 보나

대개 이유는 기능 문제가 아니라 프롬프트 구조 문제입니다.

실수 1. 사용자 정보를 앞에 넣는다

예를 들어 첫 줄부터 고객 이름, 계정 상태, 최근 주문 내역을 붙이면 prefix가 매번 바뀝니다. 공통 지시문이 뒤에 있어도 이미 늦었습니다.

실수 2. 공통 지시문을 매번 조금씩 바꾼다

“친절하게 답해라”가 어떤 요청에서는 “간결하고 친절하게 답해라”로 바뀌고, 다른 요청에서는 예제가 하나 더 붙습니다. 이 작은 차이가 캐시 적중을 깨뜨립니다.

실수 3. tool 설명을 동적으로 생성한다

도구 목록과 설명을 매 요청마다 재조합하면 prefix 일관성이 무너집니다.

실수 4. few-shot 예제를 섞어 넣는 기준이 흔들린다

가끔은 예제 2개, 가끔은 4개, 순서도 매번 다르면 캐시가 거의 맞지 않습니다.

실수 5. 프롬프트 버전 관리가 없다

팀원이 시스템 프롬프트를 슬쩍 수정하면 그 순간부터 캐시 패턴이 바뀝니다. 성능 저하 원인을 찾기도 어렵습니다.

캐시 친화적인 프롬프트 구조는 이렇게 짠다

실무에서는 아래 4단 구조가 가장 단순하고 효과적입니다.

1단: 고정 시스템 정책

절대 자주 바뀌지 않는 규칙만 모읍니다.

• 역할 정의
• 금지사항
• 응답 형식 원칙
• 공통 안전 정책

이 블록은 가장 앞에 둡니다.

2단: 고정 도메인 컨텍스트

같은 업무군에서 반복되는 정보입니다.

• 제품 설명
• 팀 공통 용어
• 데이터 스키마 요약
• tool 사용 규칙

이 블록도 최대한 고정합니다.

3단: 버전 고정 예제

few-shot이 필요하다면 예제를 자주 바꾸지 말고 버전 단위로 묶습니다. support-v3-example-set처럼 관리하면 좋습니다.

4단: 요청별 가변 데이터

맨 뒤에 이번 요청만의 정보를 붙입니다.

• 사용자 질문
• 첨부 문서 요약
• 최근 대화 맥락
• 세션 메타데이터

이렇게 해야 앞의 큰 덩어리가 재사용됩니다.

실제 리팩터링 예시

나쁜 구조

1. 고객 이름/등급
2. 최근 주문 정보
3. 시스템 규칙
4. 출력 스키마
5. 예제
6. 질문

이 구조는 앞부분이 매번 바뀌기 때문에 캐시 효율이 낮습니다.

좋은 구조

1. 시스템 규칙
2. 출력 스키마
3. tool 사용 규칙
4. 예제
5. 고객 이름/등급
6. 최근 주문 정보
7. 질문

같은 정보를 써도 순서만 바꿔서 효과가 크게 달라집니다.

prompt_cache_key를 언제 고려해야 하나

OpenAI 문서에는 prompt_cache_key를 제공하면 라우팅 효율을 높여 캐시 적중 가능성을 더 끌어올릴 수 있다고 나옵니다. 특히 긴 공통 prefix를 여러 요청이 공유하는 환경에서 유리합니다.

실무적으로는 아래 상황에서 검토할 만합니다.

• 같은 업무군 요청이 분당 여러 건 들어온다
• 대규모 고객사별로 공통 시스템 프롬프트가 다르다
• 팀/테넌트별 정책 블록이 길다
• 사용자 질문만 바뀌고 나머지는 거의 같다

예를 들어 support-enterprise-v2, code-review-ruby-v1 같은 단위로 캐시 키 전략을 세울 수 있습니다.

캐시를 잘 쓰기 위해 버려야 할 습관

“한 요청마다 프롬프트를 예쁘게 조합하자”

유연해 보여도 캐시에 불리합니다. 특히 문자열 템플릿이 많을수록 미세 차이로 prefix가 깨집니다.

“세션 메타를 앞에 다 넣자”

디버깅에는 편하지만 비용엔 나쁩니다. 메타는 뒤로 보내거나 별도 구조화 필드로 분리하는 편이 낫습니다.

“예제를 요청마다 맞춤화하자”

few-shot 성능이 좋아질 수도 있지만 캐시 이득을 잃을 수 있습니다. 자주 쓰는 몇 개의 예제 세트로 표준화하는 게 더 실용적일 때가 많습니다.

prompt caching을 지표로 관리하는 방법

단순히 지원 여부만 아는 걸로는 부족합니다. 아래 항목을 같이 보면 좋습니다.

• 프롬프트 총 토큰 수
• 정적 prefix 토큰 수
• 가변 suffix 토큰 수
• 프롬프트 버전별 평균 latency
• 요청 유형별 평균 입력 비용
• 캐시 적중 가능성이 높은 요청 비율

공식적으로 캐시 hit metric을 직접 받지 못하더라도, 프롬프트 구조와 지연/비용 변화를 비교하면 충분히 개선 방향을 잡을 수 있습니다.

어떤 팀이 가장 먼저 이걸 해야 하나

특히 아래 팀은 우선순위가 높습니다.

• customer support agent 운영 팀
• 긴 시스템 정책을 쓰는 RAG 팀
• 구조화 출력과 tool 설명이 많은 workflow 팀
• 코드 리뷰/문서 분석처럼 큰 컨텍스트를 자주 다루는 팀
• 멀티테넌트 SaaS에서 계정별 정책이 다른 팀

이 팀들은 모델 교체보다 prompt layout만 손봐도 체감 개선이 큽니다.

오늘 바로 할 수 있는 리팩터링 절차

1. 현재 가장 비싼 프롬프트 3개를 뽑습니다.
2. 각 프롬프트를 고정 부분과 가변 부분으로 색칠해봅니다.
3. 고정 부분을 앞쪽으로 몰아넣습니다.
4. few-shot 예제를 표준 세트로 버전화합니다.
5. 사용자별 데이터는 뒤로 보냅니다.
6. 변경 전후 평균 latency와 입력 비용을 비교합니다.

이 작업은 거창하지 않습니다. 그런데 잘 하면 비용, 속도, 운영 일관성이 같이 좋아집니다.

결론: prompt caching은 비용 절감 기능이 아니라 프롬프트 설계 원칙이다

많은 팀이 prompt caching을 “플랫폼이 알아서 해주는 최적화” 정도로 봅니다. 반은 맞고 반은 틀립니다. 기능은 자동이어도, 효과는 설계에 달려 있습니다. 정적 prefix를 얼마나 안정적으로 유지하느냐가 성패를 가릅니다.

긴 시스템 프롬프트를 매번 새로 계산하는 팀은 모델 성능보다 먼저 프롬프트 배치를 봐야 합니다. 특히 long system prompt가 많은 서비스라면 prompt caching은 옵션이 아니라 기본기입니다.

좋은 프롬프트는 답을 잘 뽑는 프롬프트이기도 하지만, 반복 요청에서 싸고 빠르게 재사용되는 프롬프트이기도 합니다.

실행 체크리스트

• 시스템 정책, 도메인 컨텍스트, 예제, 사용자 입력 순서를 재점검했다
• 정적인 prefix를 최대한 고정했다
• 가변 데이터는 프롬프트 뒤쪽으로 이동했다
• few-shot 예제를 버전 단위로 표준화했다
• 요청 유형별 평균 입력 비용과 지연을 비교했다
• 긴 시스템 프롬프트를 쓰는 플로우부터 우선 리팩터링했다

참고 소스:

• OpenAI API Docs, Prompt caching
• Datadog, State of AI Engineering 2026