LLM(거대 언어 모델)을 활용하여 애플리케이션을 개발할 때, 응답 속도(Latency)**와 API 비용(Cost)은 항상 중요한 고려사항이다. 특히 복잡한 시스템 프롬프트, Few-shot 예제, 또는 RAG(검색 증강 생성) 파이프라인의 컨텍스트처럼 반복적이고 긴 프롬프트를 사용하는 경우 이러한 문제는 더욱 두드러진다.
이러한 문제를 해결하기 위해 OpenAI는 **프롬프트 캐싱(Prompt Caching)**이라는 강력한 기능을 제공한다. 이 기능을 활용하면 지연 시간을 최대 80%, 비용을 최대 75%까지 절감할 수 있다. 본 문서는 프롬프트 캐싱의 작동 원리를 심도 있게 분석하고, 개발자가 이점을 극대화할 수 있는 구체적인 전략과 모범 사례를 제시하는 것을 목표로 한다.
프롬프트 캐싱이란 무엇인가?
프롬프트 캐싱은 모델에 전달되는 프롬프트의 반복적인 앞부분(prefix)을 서버에 저장해두고 재사용하는 기술이다. 웹 브라우저가 웹사이트의 이미지나 스크립트 파일을 캐시에 저장하여 다음 방문 시 페이지를 더 빨리 로드하는 것과 유사한 원리다.
API 요청에 포함된 시스템 프롬프트나 공통 명령어와 같은 내용은 대부분의 경우 동일하게 유지된다. OpenAI는 동일한 프롬프트 접두사를 가진 요청을 이전에 해당 프롬프트를 처리했던 서버로 라우팅한다. 이를 통해 처음부터 전체 프롬프트를 처리하는 대신, 캐시된 결과를 즉시 활용하여 나머지 부분만 계산하게 된다.
가장 중요한 점은 이 기능이 gpt-5를 포함한 최신 모델에서 별도의 코드 변경 없이 자동으로 활성화되며, 추가 비용이 발생하지 않는다는 것이다.
프롬프트 캐싱의 작동 원리
프롬프트 캐싱의 효과를 제대로 누리기 위해서는 그 작동 방식을 정확히 이해하는 것이 중요하다. 캐시의 핵심은 정확한 접두사 일치(exact prefix match)이다.
1. 프롬프트 구조화의 중요성
캐시가 적중(hit)하려면 여러 요청에 걸쳐 프롬프트의 시작 부분이 글자 하나 틀리지 않고 완전히 동일해야 한다. 따라서, 캐싱의 이점을 극대화하려면 프롬프트 구조를 전략적으로 설계해야 한다.
•
정적(Static) 콘텐츠: 시스템 명령어, 역할 설정, Few-shot 예제 등 여러 요청에서 변하지 않는 내용은 프롬프트의 가장 앞부분에 배치한다.
•
동적(Dynamic) 콘텐츠: 사용자 질문, 실시간 데이터 등 요청마다 바뀌는 내용은 프롬프트의 가장 뒷부분에 배치한다.
이는 텍스트뿐만 아니라 이미지나 tools 파라미터에도 동일하게 적용된다. 모든 요소가 캐시될 접두사 내에서 완벽하게 일치해야 한다.
OpenAI가 제시하는 이상적인 프롬프트 구조. 정적인 부분을 앞에 두어 캐싱 효율을 높인다.
2. 캐싱 프로세스 3단계
API 요청이 발생하면 다음과 같은 단계를 거친다.
1.
캐시 라우팅 (Cache Routing)
•
요청은 프롬프트 접두사의 해시(hash)값을 기반으로 특정 서버 머신에 라우팅된다. 일반적으로 프롬프트의 첫 256개 토큰이 해시 계산에 사용된다.
•
prompt_cache_key 파라미터를 사용하면 이 라우팅 과정에 직접 영향을 줄 수 있다. 긴 공통 접두사를 공유하는 요청이 많을 때, 이 키를 일관되게 제공하면 특정 서버 그룹으로 요청을 유도하여 캐시 적중률을 크게 향상시킬 수 있다.
•
주의: 동일한 접두사와 prompt_cache_key 조합에 대한 요청이 분당 약 15개를 초과하면, 일부 요청이 다른 머신으로 넘어가 캐시 효율이 저하될 수 있다.
2.
캐시 조회 (Cache Lookup)
•
라우팅된 서버는 해당 머신의 캐시에 요청된 프롬프트의 접두사가 존재하는지 확인한다.
3.
캐시 적중 (Cache Hit) 또는 부재 (Cache Miss)
•
적중(Hit): 일치하는 접두사가 캐시에 있으면, 시스템은 캐시된 결과를 재사용한다. 이는 응답 시간을 획기적으로 단축시키고, 캐시된 부분만큼의 프롬프트 토큰 비용을 절감해 준다.
•
부재(Miss): 일치하는 접두사가 없으면, 시스템은 전체 프롬프트를 처음부터 처리한다. 그리고 이 과정에서 생성된 접두사 정보는 향후 요청을 위해 해당 머신의 캐시에 저장된다.
캐시된 접두사는 일반적으로 5분에서 10분 동안 비활성 상태일 경우 만료되어 삭제된다. 다만, 사용량이 적은 시간에는 최대 1시간까지 유지될 수 있다.
캐싱 효과 극대화를 위한 실용 가이드
이론을 알았다면 이제 실제 적용을 통해 효과를 극대화할 차례다.
요구사항 및 확인 방법
•
최소 토큰 수: 캐싱은 프롬프트가 1024 토큰 이상일 때 활성화된다.
•
캐시 단위: 캐시 적중은 128 토큰 단위로 계산된다. 따라서 캐시되는 토큰 수는 항상 1024, 1152, 1280, 1408, ... 과 같은 128의 배수 시퀀스를 따른다.
•
확인 방법: API 응답 객체(Response object)의 usage.prompt_tokens_details.cached_tokens 필드를 통해 캐시된 토큰 수를 확인할 수 있다. 1024 토큰 미만의 요청에서는 이 값이 항상 0으로 표시된다.
"usage": {
"prompt_tokens": 2006,
"completion_tokens": 300,
"total_tokens": 2306,
"prompt_tokens_details": {
"cached_tokens": 1920 // 2006 토큰 중 1920 토큰이 캐시되었음을 의미
},
...
}
JSON
복사
캐싱 가능한 요소
•
메시지(Messages): system, user, assistant 역할을 포함한 전체 메시지 배열
•
이미지(Images): 사용자 메시지에 포함된 이미지 (URL 링크 또는 Base64 인코딩 데이터)
•
도구 사용(Tool use): tools 파라미터로 제공되는 사용 가능한 도구 목록
•
구조화된 출력(Structured outputs): JSON 모드 등에서 사용되는 출력 스키마
최적화 모범 사례
1.
프롬프트 구조화: 정적 콘텐츠를 앞에, 동적 콘텐츠를 뒤에 배치하는 것이 가장 중요하다.
2.
prompt_cache_key의 전략적 사용:
•
RAG 애플리케이션에서 여러 사용자가 동일한 문서를 참조하는 경우, prompt_cache_key를 해당 문서의 ID(document_id)로 설정하면 캐시 적중률을 높일 수 있다.
•
반대로, user_id나 session_id처럼 고유성이 높은 값을 키로 사용하면 오히려 캐시를 분산시켜 효과를 떨어뜨릴 수 있으니 주의해야 한다. 키의 세분성(granularity)을 잘 조절하여 분당 15회 요청 제한을 넘지 않도록 설계하는 것이 좋다.
3.
성능 모니터링: API 응답의 cached_tokens 값을 꾸준히 모니터링하여 캐시 적중률, 지연 시간 변화, 비용 절감 효과를 추적하고 프롬프트 전략을 지속적으로 개선해야 한다.
4.
안정적인 요청 흐름 유지: 동일한 접두사를 가진 요청을 꾸준히 보내 캐시가 만료되지 않고 활성 상태를 유지하도록 하는 것이 유리하다.
자주 묻는 질문 (FAQ)
Q1. 캐시된 데이터의 개인정보는 어떻게 보호되는가?
프롬프트 캐시는 조직(Organization) 단위로 격리된다. 즉, 다른 조직과 캐시를 공유하지 않으며, 오직 동일한 조직의 구성원만이 동일 프롬프트에 대한 캐시에 접근할 수 있다.
Q2. 프롬프트 캐싱이 모델의 최종 응답 결과에 영향을 주는가?
아니다. 전혀 영향을 주지 않는다. 캐싱은 프롬프트 처리 과정에만 관여하며, 최종 출력 토큰 생성은 캐시 사용 여부와 관계없이 매번 동일한 조건에서 새롭게 계산된다.
Q3. 캐시를 수동으로 지울 수 있는가?
현재 수동 캐시 삭제 기능은 제공되지 않는다. 캐시는 비활성 시간에 따라 자동으로 만료된다.
Q4. 캐시를 사용하는 데 추가 비용이 드는가?
아니다. 캐싱은 추가 비용 없이 자동으로 적용되는 기능이다.
Q5. 캐시된 토큰도 분당 토큰 제한(TPM)에 포함되는가?
그렇다. 포함된다. 캐싱은 API 속도 제한(rate limit)에 영향을 주지 않으므로, 전체 프롬프트 토큰을 기준으로 계산된다.
결론
프롬프트 캐싱은 OpenAI API의 성능과 비용 효율성을 크게 향상시킬 수 있는 강력하고 자동화된 기능이다. 개발자는 캐싱의 핵심 원리인 '정확한 접두사 일치'를 이해하고, 이를 바탕으로 프롬프트를 전략적으로 구조화함으로써 그 잠재력을 최대한 활용할 수 있다.
정적인 시스템 명령어는 앞으로, 동적인 사용자 입력은 뒤로 보내는 간단한 습관만으로도 여러분의 AI 애플리케이션은 더 빠르고 경제적으로 동작할 것이다. 지금 바로 여러분의 프롬프트를 점검하고 최적화를 시작해 보길 바란다.
마지막으로, 다음 질문에 대해 한번 생각해보는 것을 권장한다.
"당신의 애플리케이션에서 가장 반복적으로 사용되는 프롬프트 구성 요소는 무엇이며, 이를 프롬프트의 시작 부분으로 재구성하여 캐싱 효과를 극대화할 수 있는 방법은 무엇인가?"
