프롬프트 캐싱 90% 할인, AI 요금도 90% 줄까? 에이전트 비용 최적화의 함정

 

프롬프트 캐싱은 여러 AI 요청에서 동일한 입력 앞부분을 다시 계산하는 일을 줄여 비용과 응답 지연을 낮추는 기술이다. 긴 지침, 반복되는 문서, 도구 정의를 계속 보내는 AI 에이전트에 특히 유용할 수 있다. 하지만 캐시 읽기 토큰의 할인율과 서비스 전체 요금의 절감률은 같은 숫자가 아니다.

 

“최대 90% 절감”이라는 문구를 보고 전체 AI 예산을 10분의 1로 잡으면 계산이 어긋날 수 있다. 캐시에 적중하지 않는 입력, 최초 쓰기 비용, 새로 생성하는 출력, 검색과 도구 호출, 재시도 비용이 남기 때문이다. 캐시를 재사용하기 전에 만료되거나 프롬프트 앞부분이 바뀌면 기대한 효과도 나오지 않는다.

 

이 글은 프롬프트 캐싱의 원리와 접두사 설계, 비용 계산, 캐시 적중률, RAG와 에이전트 적용, 보안과 평가 방법을 정리한다. AWS의 한국어 기술 블로그와 관련 인프라 글, 확인 시점의 OpenAI 공식 문서를 비교해 오래된 요금 설명을 그대로 적용할 때 생기는 문제도 살펴본다.

 

먼저 읽는 핵심 요약

 

• 프롬프트 캐싱은 입력의 중간 계산을 재사용하는 기능이며 과거 답변을 그대로 반환하는 응답 캐시와 다르다.

 

• 같은 뜻의 문장보다 실제로 일치하는 접두사와 관련 설정이 중요하다.

 

• 할인되는 입력만 보지 말고 캐시 쓰기·읽기·일반 입력·출력과 도구 비용을 합쳐야 한다.

 

• 첫 토큰까지의 시간과 전체 업무 완료 시간은 구분해서 측정해야 한다.

 

• 모델과 세대, 서비스에 따라 최소 길이·요금·유지 조건이 다르므로 현재 문서를 확인해야 한다.

 

이 글에서 다루는 내용

 

① 캐싱 원리와 블로그 수치의 해석

② 안정적인 접두사와 데이터 배치

③ 비용 계산과 적중률의 함정

④ 에이전트·RAG·보안·관측 설계

⑤ 도입 체크리스트와 FAQ

 

1. 프롬프트 캐싱은 무엇을 재사용할까

 

 

언어 모델은 입력을 처리하면서 앞선 토큰을 참고하는 데 필요한 중간 상태를 계산한다. 흔히 KV 상태라고 부르는 이 정보를 재사용하면 같은 입력 앞부분을 다시 처리하는 연산을 줄일 수 있다. OpenAI 공식 문서는 프롬프트 캐시가 이런 KV 텐서를 저장하며 새 입력과 새 응답의 생성은 여전히 필요하다고 설명한다.[1]

 

예를 들어 제품 설명서와 응답 규칙이 같고 질문만 달라지는 상황을 생각해 보자. 설명서와 규칙이 반복되는 접두사로 유지된다면 그 부분의 처리 결과를 재사용할 여지가 있다. 새로운 질문을 해석하고 그 질문에 맞는 답을 생성하는 과정까지 생략하는 것은 아니다.

 

따라서 캐싱이 적용돼도 답변이 매번 동일해지는 것은 아니다. 출력은 현재 요청과 모델의 생성 과정에 따라 달라질 수 있다. 프롬프트 캐싱을 결정적 응답을 만드는 기능이나 사실 정확도를 보증하는 장치로 이해하면 안 된다.

 

어떤 계산을 어디에 저장하고 어느 요청이 재사용할 수 있는지는 제공자의 구현과 정책에 달려 있다. API 사용자는 내부 구조를 추측하기보다 지원 모델과 사용량 필드, 요금, 보관 조건을 확인해야 한다. 같은 기능 이름이 붙어 있어도 서비스 계약은 서로 다를 수 있다.

 

2. 응답 캐시와 의미적 캐시는 다른 문제를 푼다

 

응답 캐시는 이전에 만든 답을 저장했다가 조건에 맞는 요청에 다시 반환하는 방식이다. 정확히 같은 요청을 키로 사용할 수도 있고, 의미가 비슷한 질문을 찾아 재사용하는 의미적 캐시를 구성할 수도 있다. 적중하면 모델 호출 자체를 줄일 수 있다는 점에서 입력 계산을 재사용하는 프롬프트 캐시와 다르다.

 

 

하지만 의미가 비슷하다고 답까지 같아도 되는 것은 아니다. “내 주문은 취소됐나요?”라는 질문은 문장이 같아도 사용자와 주문, 조회 시점에 따라 결과가 달라진다. 임베딩 유사도가 높다는 사실은 권한이나 최신 상태가 같다는 증거가 아니다.

 

Introl의 한국어 인프라 글은 제공자 측 접두사 캐싱과 애플리케이션 수준 의미적 캐싱을 구분해 설명한다.[2] 계층을 나눠 생각하는 데 유용하지만 각 계층의 절감률을 그대로 더할 수는 없다. 응답 캐시가 적중해 호출을 생략한 요청은 그 호출 안의 프롬프트 캐시 비용을 다시 절감하는 대상이 아니기 때문이다.

 

응답 재사용에는 별도의 정답성 기준과 만료 정책이 필요하다. 공통 FAQ처럼 조건이 안정적인 항목과 개인화된 현재 상태 조회를 구분한다. 이 글의 중심은 입력 접두사의 계산을 재사용하는 프롬프트 캐싱이며, 응답 캐시의 정확성 문제는 따로 평가해야 한다.

 

3. 한국어 기술 블로그의 “최대 90%”를 읽는 방법

 

AWS는 2025년 6월 한국어 글에서 Amazon Bedrock의 프롬프트 캐싱을 소개하며 비용과 지연의 최대 개선 가능성을 설명했다. 반복되는 프롬프트 접두사의 처리 상태를 저장하고, 후속 요청이 일치하면 입력 처리 연산을 줄이는 구조다.[3]

 

같은 글은 재사용하는 토큰 수와 요청 빈도, 요청 사이의 시간을 추정해야 한다고 강조한다. 캐시 쓰기·읽기 메트릭과 모델별 가격으로 비용을 계산하고, 첫 토큰까지의 시간을 관측하라고 안내한다. 제목과 최대 수치만 읽으면 이런 조건을 놓치기 쉽다.

 

 

Introl 글 역시 여러 공급자와 캐싱 계층을 폭넓게 소개한다.[2] 다만 블로그의 가격과 지원 모델, 캐시 수명은 작성 당시의 정보다. 확인 시점의 OpenAI 공식 문서는 모델 세대별 캐시 쓰기 요금과 보관 옵션의 차이를 별도로 설명하고 있다.[1]

 

따라서 “OpenAI는 항상 쓰기 추가 비용이 없다”, “모든 모델의 읽기 할인율은 같다”처럼 오래된 요약을 보편 규칙으로 사용하면 안 된다. 서비스·모델·요청 설정·확인 날짜를 함께 남기는 편이 정확하다. 본문에서는 특정 모델의 달러 가격을 고정해 견적처럼 제시하지 않고 계산 구조를 중심으로 설명한다.

 

4. 같은 의미보다 실제 접두사 일치가 중요하다

 

접두사는 프롬프트의 시작부터 이어지는 동일한 부분이다. 첫 부분이 같다가 중간에서 달라지면 그 뒤에 같은 내용이 다시 나와도 기존의 긴 접두사를 그대로 재사용할 수 있다고 가정하면 안 된다. 제공자 문서가 정한 경계와 일치 조건이 적용된다.

 

규칙이 같은 뜻이어도 표현과 순서가 바뀌면 입력이 달라진다. 도구 정의의 배열 순서, 예시 배치, 문서 버전, 요청마다 바뀌는 메타데이터가 영향을 줄 수 있다. 모델과 API가 실제로 구성하는 전체 문맥을 기준으로 판단해야 한다.

 

가상의 나쁜 배치를 보자. 현재 시각과 요청 식별자를 맨 앞에 넣고 그 뒤에 긴 공통 지침을 붙이면 첫 부분부터 달라진다. 매번 바뀌는 정보를 뒤로 옮기고 공통 규칙을 안정적으로 유지하면 재사용 가능한 앞부분을 늘릴 수 있다. 이는 원리를 설명하는 예시이며 모든 API가 같은 순서로 입력을 구성한다는 뜻은 아니다.

 

 

공백이나 직렬화 변경의 영향을 임의로 단정하는 것도 피하자. 실제 일치 여부와 적중 토큰은 사용량으로 확인해야 한다. 프롬프트 텍스트를 사람이 봤을 때 비슷하다는 사실보다 최종 요청의 구조와 제공자의 캐시 진단 결과가 중요하다.

 

5. 프롬프트 구조는 안정적인 부분과 변하는 부분으로 나눈다

 

비교적 안정적인 후보는 시스템 역할, 응답 형식, 고정된 업무 규칙, 검증된 예시, 반복해서 쓰는 문서와 도구 스키마다. 자주 변하는 후보는 현재 질문, 새로 조회한 상태, 요청별 식별자, 최신 검색 결과다. 다만 어떤 항목이 고정적인지는 실제 서비스의 변경 빈도로 판단해야 한다.

 

개념적인 배치 예시는 “공통 규칙 → 안정적인 도구·예시·문서 → 현재 대화와 질문”이다. 실제 API에서는 도구와 개발자 메시지 등이 별도 필드로 전달되고 제공자가 다시 문맥을 구성할 수 있다. 따라서 이 순서는 설계 원칙이며 그대로 붙여 넣는 만능 프롬프트가 아니다.

 

자주 쓰지 않는 도구 수십 개를 적중률 때문에 항상 넣는 것은 신중해야 한다. 입력이 길어지고 모델의 도구 선택이 어려워질 수 있다. 업무에 필요한 도구 집합을 정하고 그 안에서 정의와 순서를 안정적으로 유지하는 접근을 검토할 수 있다.

 

정확한 업무 규칙이 바뀌었는데 캐시를 유지하려고 예전 내용을 계속 쓰면 최적화의 목적이 뒤집힌다. 최신성과 품질이 우선이고 캐시 재사용은 그 조건 안에서 개선해야 한다. 변경이 필요한 정보를 억지로 고정하는 방식은 올바른 비용 절감이 아니다.

 

6. 최소 길이를 맞추려고 문장을 채우면 손해일 수 있다

 

 

프롬프트 캐싱에는 모델별 최소 입력 길이와 캐시 조회 경계가 있을 수 있다. 짧은 요청은 자격 조건을 충족하지 못할 수 있고, 어느 지점까지 재사용되는지도 모델과 설정에 따라 달라진다. OpenAI 문서는 확인 시점에 이런 차이를 모델 세대별로 나눠 설명한다.[1]

 

이 조건을 보고 의미 없는 문장을 추가해 최소 길이를 채우는 방식은 대개 먼저 계산해 봐야 한다. 추가 입력을 최초로 처리하고 저장하는 비용이 생기고, 실제 반복 요청이 충분하지 않으면 회수하지 못할 수 있다. 모델에 불필요한 내용도 더해진다.

 

같은 이유로 항상 전체 문서와 전체 대화를 넣는 것이 최선은 아니다. 필요한 부분만 검색하거나 요약하는 방식과 긴 공통 문맥을 재사용하는 방식은 비용·품질·최신성의 조건이 다르다. 짧아진 요청이 캐시에 덜 적중해도 총비용은 더 낮을 수 있다.

 

목표는 캐시 적중 토큰의 절대량을 최대로 만드는 것이 아니다. 요구한 품질을 유지하며 완료한 업무당 총비용과 시간을 줄이는 것이다. 적중률을 올리기 위해 필요 없는 입력을 늘리는 최적화는 이 목표와 어긋날 수 있다.

 

7. 캐시 쓰기·읽기·일반 입력·출력을 모두 계산한다

 

비용은 적어도 네 부분으로 나눠 볼 수 있다. 새로 처리한 일반 입력, 캐시를 만드는 입력, 기존 캐시에서 읽은 입력, 새로 생성한 출력이다. 어떤 서비스가 쓰기를 별도 요율로 청구하는지, 요금 항목이 서로 배타적인지, 저장 비용이 있는지는 각 문서에 따라 확인해야 한다.

 

개념적인 계산식은 “일반 입력량 × 해당 단가 + 캐시 쓰기량 × 해당 단가 + 캐시 읽기량 × 해당 단가 + 출력량 × 해당 단가”다. 여기에 검색과 외부 도구, 저장·운영 비용이 더해질 수 있다. 실제 사용량 필드의 정의를 확인하지 않고 토큰을 중복 합산하면 견적이 틀어진다.

 

 

OpenAI 공식 문서는 확인 시점에 캐시 쓰기 가격을 일반 입력 가격에 무조건 더하는 추가 수수료로 해석하지 않도록 설명한다.[1] 토큰이 어떤 요율로 계산되는지 구분해야 한다는 뜻이다. 공급자마다 계정에 표시되는 항목과 API 사용량의 대응 관계를 점검하는 것이 좋다.

 

할인율은 보통 특정 종류의 토큰에 적용된다. 전체 호출 비용에서 그 토큰이 차지하는 비중이 작으면 전체 절감도 작다. 출력이 길고 검색·도구 비용이 큰 에이전트라면 입력 캐싱만으로 줄일 수 있는 비용의 범위를 먼저 추정해야 한다.

 

8. 숫자로 보는 90% 할인과 전체 요금의 차이

 

다음 계산은 실제 모델 가격이나 벤치마크가 아닌 가상의 비용 단위 예시다. 같은 접두사를 한 번 일반 처리하는 비용을 1로 두자. 최초 캐시 쓰기는 1.25, 캐시 읽기는 0.1이라고 가정한다. 접두사를 총 네 번 사용하고 최초 한 번 쓴 뒤 세 번 모두 적중한다고 하자.

 

캐시를 사용하지 않으면 접두사 처리 비용은 4다. 이 가정에서 캐시를 쓰면 1.25 + 0.1 × 3 = 1.55다. 접두사 비용은 61.25% 줄어든다. 읽기의 단가가 일반 처리보다 90% 낮더라도 최초 쓰기를 포함한 네 번 전체의 절감률은 90%가 아니다.

 

여기에 요청마다 출력 비용이 2씩 발생한다고 가정해 보자. 네 번의 출력 비용은 8로 같다. 전체 모델 비용은 캐시 미사용 시 12, 사용 시 9.55가 된다. 이 조건에서 전체 절감률은 약 20.4%다. 검색과 외부 도구 비용이 추가되면 전체 서비스 예산에서 차지하는 절감 비중은 또 달라진다.

 

 

반대로 같은 접두사를 더 많이 재사용하고 입력이 비용의 큰 부분을 차지하면 효과가 커질 수 있다. 중요한 것은 광고 문구를 부정하는 것이 아니라 비교 대상을 맞추는 일이다. 읽기 단가 할인, 반복 접두사 비용 절감, 요청 전체 절감, 서비스 전체 절감은 서로 다른 지표다.

 

첫 쓰기 이후 한 번도 재사용하지 못했다면 이 예시에서는 1 대신 1.25를 지출한다. 쓰기 프리미엄이 있는 계약에서는 낮은 재사용률이 비용 증가로 이어질 수 있다는 뜻이다. 실제 손익분기점은 사용하는 모델과 요금, 적중량으로 다시 계산해야 한다.

 

9. 높은 요청 적중률이 높은 토큰 절감을 뜻하지는 않는다

 

캐시가 조금이라도 적중한 요청의 비율과 전체 입력 중 재사용된 토큰의 비율은 다르다. 긴 프롬프트에서 앞부분 몇 줄만 적중해도 요청 기준 적중으로 셀 수 있다. 이 수치만 보면 실제 재사용 범위를 과대평가할 수 있다.

 

예를 들어 많은 요청이 짧은 공통 지침을 공유하지만 대부분은 매번 다른 긴 문서를 읽는다면 요청 적중률은 높아도 입력 비용 절감은 제한적일 수 있다. 반대로 요청 수는 적어도 매우 긴 공통 문서를 반복 사용한다면 토큰 기준 효과가 클 수 있다.

 

대시보드에는 요청 기준 적중률, 토큰 기준 캐시 읽기 비중, 캐시 쓰기량, 일반 입력량을 구분해서 표시하는 편이 좋다. 각 비율의 분모도 명시한다. “캐시 히트율 80%”라는 숫자에 어떤 정의를 썼는지 모르면 팀 간 비교가 어렵다.

 

AWS 글은 캐시 읽기와 쓰기 사용량을 관찰하고 가격표와 연결하라고 안내한다.[3] 실제 절감은 동일한 업무를 캐시 없이 처리했을 때와의 비교가 있어야 판단할 수 있다. 적중률은 원인 분석 지표이고 최종 사업 지표는 비용과 품질, 시간이다.

 

10. 첫 토큰이 빨라져도 업무가 빨리 끝나는 것은 아니다

 

 

프롬프트 캐싱은 주로 입력 처리 연산을 줄인다. 따라서 응답이 시작되기까지의 시간, 즉 TTFT가 중요한 관측 지표다. 긴 공통 입력을 많이 재사용하는 대화형 서비스에서 사용자가 체감하는 대기 시간을 줄일 여지가 있다.

 

하지만 긴 답변을 생성하는 시간과 외부 검색, 데이터베이스 조회, 도구 실행까지 모두 사라지는 것은 아니다. 입력 처리가 전체 지연의 작은 부분이라면 TTFT가 좋아져도 업무 완료 시간의 변화는 작을 수 있다. 병목이 어디인지 알아야 한다.

 

예를 들어 자료 분석 후 여러 외부 시스템을 조회하는 에이전트에서는 각 API 응답 시간이 더 큰 비중일 수 있다. 이 경우 캐싱과 함께 불필요한 호출, 중복 검색, 과도한 출력, 순차 의존성을 검토해야 한다. 캐시 하나로 모든 지연을 해결하려고 하면 다른 병목이 남는다.

 

평균 시간뿐 아니라 느린 요청의 분포를 확인하자. 따뜻한 캐시에 적중한 실험 몇 건만 측정하면 첫 요청과 만료 후 요청의 지연이 빠진다. 캐시를 처음 쓰는 상황과 재사용하는 상황을 나눠 측정한 뒤 실제 트래픽 비중으로 합쳐야 한다.

 

11. 캐시는 만료되고 같은 세션도 적중을 보장하지 않는다

 

프롬프트 캐시는 영구적인 기억이 아니다. 유지 시간과 갱신 방식, 요청을 처리하는 위치와 모델 지원 조건이 존재한다. 요청 사이의 간격이 길거나 라우팅 조건이 달라지면 같은 접두사가 있어도 적중하지 않을 수 있다.

 

OpenAI 문서는 세션을 유지한다는 사실만으로 캐시 적중을 보장하지 않는다고 설명한다. 또한 캐시가 저장된 처리 위치와 조직·리전 경계, 모델별 유지 조건을 안내한다.[1] 애플리케이션의 대화 기록 보관과 추론 캐시의 가용성을 혼동하지 않아야 한다.

 

 

주기적으로 캐시를 데우는 사전 호출도 비용이 발생할 수 있다. 다음 사용 시점을 알 수 없는 문서를 계속 재처리하면 실제로 줄인 비용보다 유지 비용이 커질 수 있다. 사용 빈도와 요청 간격의 분포를 먼저 확인해야 한다.

 

유지 시간을 길게 선택할 수 있더라도 무조건 길게 설정하는 것이 정답은 아니다. 요금과 데이터 정책, 문서 갱신 주기, 해당 옵션을 지원하는 모델을 함께 검토한다. 수명과 최소 길이 같은 숫자는 오래된 블로그보다 사용하는 서비스의 현재 문서를 기준으로 삼아야 한다.

 

12. RAG에서는 검색 결과의 순서와 최신성이 영향을 준다

 

RAG는 필요한 자료를 검색해 모델 입력에 넣는 방식이다. 질문마다 문서와 청크의 순서가 달라지면 그 부분의 접두사가 달라질 수 있다. 동일 문서를 반복 참조하는 워크로드와 매번 전혀 다른 자료를 검색하는 워크로드는 재사용 조건이 다르다.

 

공통 응답 규칙과 안정적인 도구 정의는 앞부분에 유지하고 검색된 자료는 그 뒤에 배치하는 설계를 생각할 수 있다. 같은 문서 묶음을 재사용한다면 문서 버전과 정렬 기준을 안정적으로 관리할 수 있다. 그러나 검색 관련성과 근거 품질을 희생하면서 순서를 고정하는 것은 피해야 한다.

 

현재 재고와 정책, 주문 상태처럼 바뀌는 정보를 캐시 때문에 오래된 입력으로 남기면 잘못된 결론이 나올 수 있다. 프롬프트 캐싱은 새로 바뀐 입력을 자동으로 알아서 불러오는 기능이 아니다. 애플리케이션이 최신 자료를 요청에 반영해야 한다.

 

긴 문서 전체 캐싱과 필요한 청크만 검색하는 방법도 비교 대상이다. 전자는 반복 질의에 유리할 수 있고 후자는 불필요한 입력을 줄일 수 있다. 문서 길이와 반복성, 근거 누락 위험을 평가해 선택해야 한다. 캐싱이 RAG를 항상 대체한다는 결론은 지나치게 넓다.

 

 

13. 에이전트의 도구와 대화 이력도 캐시 설계 대상이다

 

AI 에이전트는 여러 단계에서 같은 지침과 도구를 반복 사용한다. 이 구조는 캐싱 후보가 될 수 있지만 도구 정의를 매번 생성하거나 정렬을 바꾸면 재사용이 흔들릴 수 있다. 프롬프트 버전과 도구 스키마 버전을 함께 기록하면 원인 추적에 도움이 된다.

 

대화 기록을 매번 새로 요약하거나 앞부분을 재작성하는 경우도 있다. 요약은 문맥 길이를 줄이는 장점이 있지만 기존 접두사를 바꾸므로 캐시 재사용에 영향을 줄 수 있다. 전체 기록 유지와 압축 중 어느 쪽이 더 경제적인지는 입력 길이와 품질을 함께 측정해야 한다.

 

하위 에이전트가 같은 자료를 쓴다고 계산이 자동으로 공유된다고 가정해서는 안 된다. 실제 렌더링된 문맥과 모델, 제공자의 라우팅·격리 정책에 따라 달라진다. 각 작업자의 사용량을 따로 보면서 전체 요청의 합계도 집계해야 한다.

 

또한 캐싱은 도구 호출의 실행 결과를 한 번만 적용하게 하는 멱등성 기능이 아니다. 같은 주문 생성 요청을 다시 보내도 중복이 생기지 않는지는 실행 계층에서 다뤄야 한다. 입력 계산을 재사용하는 것과 실제 행동의 반복을 막는 것은 별개의 설계다.

 

14. 캐시 키는 권한 검사와 데이터 격리를 대신하지 않는다

 

캐시를 잘 공유하면 효율이 높아질 수 있지만 서로 다른 사용자가 같은 자료를 볼 권한이 있는지는 따로 확인해야 한다. 특히 응답 캐시나 검색 결과 캐시를 애플리케이션이 직접 만들 때는 사용자·조직·권한·데이터 버전의 범위를 명확히 정해야 한다.

 

공급자가 조직 간 캐시를 분리한다고 설명해도 같은 애플리케이션 안의 모든 사용자가 같은 권한을 가진다는 뜻은 아니다. 검색 단계와 도구 실행 단계에서 접근 권한을 확인하고, 다른 고객의 개인화된 응답이 재사용되지 않도록 검증해야 한다.

 

 

요청 라우팅이나 회계 구분에 쓰는 캐시 키도 인증 토큰으로 간주하면 안 된다. 키를 안다는 이유로 문서를 읽거나 외부 동작을 수행하게 해서는 안 된다. 캐시의 격리 정책과 업무의 권한 모델은 별도로 설명할 수 있어야 한다.

 

민감한 자료를 모델에 제공할 때는 캐시 보관과 처리 지역, 로그, 삭제·보존 정책을 실제 서비스 계약에 맞춰 확인한다. 적중률을 측정한다는 이유로 프롬프트 전문을 불필요하게 수집할 필요는 없다. 필요한 사용량과 버전 정보로 관측 범위를 설계할 수 있다.

 

15. 실제 도입은 같은 품질을 유지하는 비교 실험부터

 

먼저 대표 업무를 고르고 캐시 적용 전의 입력·출력·도구 비용과 TTFT, 전체 완료 시간을 기록한다. 요청별로 문서와 도구, 프롬프트 버전을 남긴다. 모델과 출력 길이가 동시에 바뀌면 캐싱의 효과를 분리하기 어려워진다.

 

그다음 동일한 업무 조건에서 접두사 구조만 개선한 구성을 비교한다. 첫 요청과 반복 요청, 긴 공백 뒤의 요청, 문서 갱신 뒤의 요청을 포함한다. 일정하게 반복하는 실험과 실제 요청 간격은 다를 수 있으므로 운영 트래픽의 패턴을 반영해야 한다.

 

품질 평가도 빠지면 안 된다. 답변이 근거를 제대로 사용했는지, 최신 정보가 반영됐는지, 필요한 도구를 올바르게 골랐는지 확인한다. 비용이 줄었어도 잘못된 답변과 사람의 재작업이 늘면 업무당 비용은 오히려 높아질 수 있다.

 

모델 요금표와 사용량을 연결한 추정 비용이 실제 청구와 맞는지도 확인한다. 할인 계약, 서비스 수수료, 저장과 검색 비용이 있으면 별도로 반영한다. 최종 지표는 입력 토큰당 비용 하나보다 성공한 업무 한 건당 총비용이 적절할 수 있다.

 

 

변경을 한꺼번에 배포하기보다 대표 범위에서 확인하고 넓히면 이상 징후를 찾기 쉽다. 캐시 쓰기가 갑자기 늘면 접두사 변경과 만료, 트래픽 분산, 모델 설정을 살펴본다. 적중량이 떨어졌다는 이유만으로 무조건 유지 시간을 늘리기보다 원인을 먼저 구분해야 한다.

 

16. 비용 최적화 전에 확인할 체크리스트

 

• 프롬프트 캐시와 응답 캐시를 구분하고 있는가?

• 실제로 반복되는 접두사의 길이와 빈도를 알고 있는가?

• 요청별 시각과 식별자가 공통 입력 앞부분을 바꾸지 않는가?

• 모델별 일반 입력·쓰기·읽기·출력 요율을 확인했는가?

• 최초 요청과 만료 후 요청을 비용 계산에 포함했는가?

• 요청 기준 적중률과 토큰 기준 재사용 비중을 구분하는가?

• TTFT와 전체 업무 완료 시간을 따로 측정하는가?

• 문서 최신성과 접근 권한이 캐싱 때문에 약해지지 않는가?

• 도구 실행의 중복 방지를 캐싱과 별도로 설계했는가?

• 같은 품질을 유지하며 업무당 총비용이 줄었는가?

 

프롬프트 캐싱은 반복되는 긴 입력을 가진 서비스에서 강력한 최적화 수단이 될 수 있다. 다만 이득을 만드는 것은 기능을 켰다는 사실보다 실제로 재사용되는 입력과 요금 구조, 트래픽 패턴의 조합이다.

 

모든 토큰을 없애는 방법을 찾기보다 어떤 계산을 반복하고 있는지 관찰해 보자. 공통 문맥은 안정적으로 유지하고 현재 정보는 제때 갱신하며 품질과 전체 비용을 함께 측정하면, 할인 문구를 실제 운영상의 개선으로 연결할 수 있다.

 

자주 묻는 질문

 

Q1. 프롬프트 캐싱을 켜면 이전 답변이 그대로 나오나요?

 

그렇지 않다. 접두사의 중간 계산을 재사용하는 기능이며 현재 입력을 처리하고 새 답변을 생성하는 과정은 남는다. 과거 답변을 그대로 반환하는 응답 캐시와 구분해야 한다.

 

 

Q2. 읽기 토큰이 90% 할인되면 전체 비용도 90% 줄어드나요?

 

반드시 그렇지는 않다. 적중한 입력의 비중과 최초 쓰기, 일반 입력, 출력, 도구 비용에 따라 달라진다. 할인율의 적용 대상과 전체 청구 비용을 구분해 계산해야 한다.

 

Q3. 짧은 프롬프트를 길게 늘려 캐시 조건을 맞추면 좋나요?

 

추가 비용과 재사용 횟수를 계산하기 전에는 권하기 어렵다. 의미 없는 입력을 늘리면 최초 처리 비용과 문맥 부담이 커질 수 있다. 짧고 필요한 입력을 쓰는 쪽이 더 저렴할 수도 있다.

 

Q4. 같은 대화를 이어가면 캐시는 항상 적중하나요?

 

아니다. 일치하는 접두사와 모델·설정, 유지 시간과 처리 위치 등 제공자의 조건이 적용된다. 세션 유지와 추론 캐시 가용성은 같지 않으므로 사용량 지표를 확인해야 한다.

 

Q5. 검색 결과와 도구 응답도 무조건 고정해야 하나요?

 

아니다. 현재 상태와 근거의 최신성이 먼저다. 안정적인 공통 부분을 재사용하되 바뀐 정보는 올바르게 반영해야 한다. 캐시 적중률 때문에 오래된 데이터를 유지하면 품질이 나빠질 수 있다.

 

Q6. 가장 먼저 볼 운영 지표는 무엇인가요?

 

캐시 읽기·쓰기·일반 입력·출력 토큰과 TTFT, 전체 완료 시간, 업무 성공률을 함께 보는 것이 좋다. 이를 현재 요금과 연결해 성공한 업무당 총비용을 비교하면 효과를 판단하기 쉽다.

 

참고 자료와 확인 범위

 

[1] OpenAI API Documentation, Prompt caching.

https://developers.openai.com/api/docs/guides/prompt-caching

Prompt caching | OpenAI API

접두사와 KV 상태, 모델 세대별 요금·수명·최소 길이 차이, 라우팅과 진단에 관한 공식 설명을 확인했다. 구체적인 조건은 모델과 요청 설정, 문서 갱신에 따라 달라질 수 있다.

 

 

[2] Introl Blog, Blake Crosley, 프롬프트 캐싱 인프라: LLM 비용과 지연 시간 절감, 페이지 표기 2026.03.17.

https://introl.com/ko/blog/prompt-caching-infrastructure-llm-cost-latency-reduction-guide-2025

프롬프트 캐싱 인프라: LLM 비용과 지연 시간 절감

접두사 캐시와 의미적 캐시의 계층 구분을 참고했다. 본문에는 별도의 과거 업데이트 표기도 있어 가격과 지원 조건은 현재 공식 문서로 다시 확인했다. 글의 수치를 모든 워크로드의 보장으로 사용하지 않았다.

 

[3] AWS 기술 블로그, Amazon Bedrock에서 프롬프트 캐싱 효과적으로 사용하기, 2025.06.09.

https://aws.amazon.com/ko/blogs/tech/effectively-use-prompt-caching-on-amazon-bedrock-kr/

Amazon Bedrock에서 프롬프트 캐싱 효과적으로 사용하기 | Amazon Web Services

정적·동적 입력 배치, 캐시 읽기·쓰기 사용량, TTFT와 비용 관측의 관점을 참고했다. 당시 지원 모델 목록을 현재 전체 제품 사양으로 일반화하지 않았다.

 

자료 확인일: 2026년 10월 17일. 비용 단위 계산과 적용 흐름은 원리 설명을 위한 가상 예시이며 실제 모델 견적이나 직접 수행한 성능 실험 결과가 아니다.