[Lobsters 요약] 에이전트에서의 프롬프트 캐싱: LLM 응답 속도 및 비용 최적화 전략
49
설명
대규모 언어 모델(LLM)을 활용하는 코딩 에이전트에서 프롬프트 캐싱은 응답 속도와 비용 효율성을 결정하는 핵심 요소입니다.
2026년 7월 22일 Earendil Engineering에서 발표한 내용에 따르면, LLM은 함수처럼 작동하지만 실제 에이전트 환경에서는 이전 입력의 대부분이 반복된다는 점을 간과하기 쉽습니다.
이러한 반복적인 입력 처리를 효율화하기 위한 프롬프트 캐싱의 중요성과 작동 방식, 그리고 다양한 제약 조건 및 최적화 방안을 심층적으로 다룹니다.
### 배경 설명
대규모 언어 모델(LLM)은 텍스트 입력을 받아 텍스트 출력을 생성하는 함수와 유사하게 생각될 수 있습니다. 하지만 코딩 에이전트와 같이 복잡한 시스템에서는 이러한 단순한 모델링이 실제 운영의 핵심적인 부분을 놓치게 됩니다. 에이전트는 시스템 프롬프트, 도구 정의, 프로젝트 지침, 대화 기록, 도구 호출 및 결과 등 방대한 정보를 LLM에 입력으로 제공합니다. 특히 세션이 수만에서 수십만 토큰으로 확장될 경우, 매번 전체 프롬프트를 다시 계산하는 것은 시간과 비용 측면에서 매우 비효율적입니다.
프롬프트 캐싱은 이러한 비효율성을 완화하는 주요 기술이지만, 그 구현과 활용에는 여러 가지 복잡성과 취약성이 존재합니다. 도구 정의의 변경, 모델 전환, 또는 제공업체의 라우팅 결정 등 사소한 변화만으로도 예상치 못한 캐시 무효화가 발생할 수 있습니다. 따라서 코딩 에이전트에서 캐시 동작은 단순한 최적화 기법을 넘어, 지연 시간, 비용, 도구 설계, 세션 설계, 나아가 제품 기능 제공 방식에까지 영향을 미치는 근본적인 요소로 작용합니다. LLM의 KV 캐시 메커니즘을 이해하고 이를 효과적으로 활용하는 것이 에이전트 성능 최적화의 핵심 과제입니다.
### KV 캐시의 구성 요소와 작동 원리
트랜스포머 모델은 프롬프트 처리를 크게 두 단계로 나눕니다. 첫 번째는 '프리필(prefill)' 단계로, 입력 토큰을 읽고 어텐션 상태를 계산합니다. 두 번째는 '디코드(decode)' 단계로, 새로운 토큰을 하나씩 생성합니다. 각 어텐션 레이어에서 처리된 토큰은 '키(key)'와 '값(value)'이라는 두 가지 정보를 생성합니다. 이 키와 값은 해시 테이블의 키-값 조회와는 다릅니다. 이들은 숫자로 이루어진 배열이며, 모델은 새로운 토큰의 쿼리를 이전 토큰들의 키와 비교하여 관련성을 판단합니다. 이 관련성 점수를 바탕으로 해당 토큰들의 값들을 가중 평균하여 사용합니다. 즉, 키는 모델이 매칭하는 대상이고, 값은 검색되는 정보입니다. 이러한 키와 값 정보는 다음 토큰 생성 시 이전 토큰들을 다시 계산할 필요 없이 참조할 수 있도록 저장되며, 이것이 바로 KV 캐시입니다. KV 캐시는 특정 토큰 접두사에 대응되며, 의미는 같더라도 토큰화 방식이 다르면 KV 캐시를 공유할 수 없습니다. 또한, 중간 토큰이 변경되면 그 이후의 모든 토큰 시퀀스는 새로운 것으로 간주됩니다.
### KV 캐시 저장 위치 및 접근 방식
KV 캐시를 효과적으로 활용하기 위해서는 저장 위치와 접근 방식이 중요합니다. 크게 두 가지 접근 방식이 있습니다. 첫 번째는 '세션 어피니티(session affinity)' 방식입니다. 이 방식은 KV 캐시를 계산한 GPU 근처에 유지하고, 다음 요청을 동일한 워커로 라우팅합니다. 세션 ID나 프롬프트 캐시 키를 사용하여 로드 밸런서 수준에서 간단하게 라우팅 힌트로 활용할 수 있습니다. 이 방식은 대용량 캐시를 네트워크로 이동시키는 오버헤드를 줄여 빠르지만, 스케줄링에 제약을 줍니다. 워커가 과부하되거나 재시작될 경우 캐시가 유실될 수 있으며, 라우터가 트래픽 분산을 위해 세션 캐시 유지를 우선순위에서 밀어낼 수도 있습니다. 두 번째는 '분산 캐시(distributed cache)' 방식입니다. KV 블록을 다른 메모리 계층에 저장하거나 여러 워커에 걸쳐 공유하여, 요청이 특정 GPU에 덜 종속되도록 합니다. 이 방식은 스케줄링 유연성과 복구 능력을 향상시키지만, KV 블록의 이동, 인덱싱, 유지 관리가 새로운 시스템 문제로 대두됩니다. 실제 구현에서는 GPU 메모리, 호스트 메모리, 로컬 스토리지, 원격 스토리지, 접두사 기반 라우팅, 제거 정책 등이 복합적으로 사용됩니다. KV 캐시는 크기가 클 수 있지만, 다양한 최적화 기법을 통해 수 기가바이트 수준으로 줄일 수 있습니다.
### 세션 구조와 캐시 관리의 복잡성
Pi와 같은 에이전트의 세션은 선형적인 목록이 아닌 트리 구조를 가집니다. 이는 사용자가 대화의 특정 시점으로 돌아가 다른 분기를 따라 대화를 이어갈 수 있음을 의미합니다. 이러한 분기 구조는 캐시 관리의 복잡성을 증가시킵니다. 예를 들어, 'D' 지점에서 'F' 지점으로 이동할 때 'root'부터 'C'까지의 공통 접두사를 재사용할 수 있습니다. 하지만 캐시가 재사용 가능한 접두사 블록만 유지하거나, 공유 블록이 이미 제거되었거나, 다른 워커로 라우팅될 경우 캐시 히트율은 크게 감소할 수 있습니다. 반대로, 새로운 세션을 시작하면서도 이전 세션의 많은 컨텍스트를 그대로 가져오는 경우도 있습니다. 이러한 상황에서 세션 키만으로 캐시를 격리하는 라우팅 시스템은 유용한 중복성을 놓칠 수 있습니다. 결국 재사용 가능한 접두사가 캐싱의 핵심이며, 세션 ID는 인프라가 잠재적인 캐시 내용을 찾는 데 도움을 주는 역할을 합니다. 일부 시스템에서는 라우팅 키가 캐시 관리에 결정적이지만, 다른 시스템에서는 단순한 최적화 수단에 불과합니다.
### 도구 로드아웃 변경이 캐시에 미치는 영향
도구 정의는 일반적으로 대화 시작 부분에 위치하며 시스템 프롬프트에 통합됩니다. 도구의 이름, 설명, JSON 스키마는 모델 입력의 일부이므로, 도구를 하나 추가하거나 제거하거나 스키마를 변경하는 것만으로도 프롬프트의 앞부분에서 불일치가 발생할 수 있습니다. 이는 캐시된 대화 내용 전체를 무효화시킬 수 있습니다. 예를 들어, 'deploy'라는 새 도구를 추가하면 이전 대화 내용이 캐시 무효화의 원인이 될 수 있습니다. 이러한 문제는 플러그인 시스템이나 동적 도구 카탈로그에서 흔히 발생합니다. 적은 수의 스키마 토큰을 절약하기 위해 도구를 필요할 때만 로드하는 것이 효율적으로 보일 수 있지만, 대부분의 모델에서는 변경된 도구 목록이 후속 대화 내용을 다시 처리하게 만듭니다. 일부 최신 모델 API는 '추가적 도구 로딩(additive tool loading)'을 지원합니다. 이를 통해 도구를 대화 기록의 특정 지점에서 사용 가능하게 하여 기존 접두사를 변경하지 않고 캐시를 유지할 수 있습니다. Pi는 이러한 기능을 지원하는 모델에서 'setActiveTools()'를 사용하여 도구를 추가할 때, 추가된 도구 이름을 도구 결과에 기록합니다. 하지만 모든 확장 기능이 캐시 효율성을 고려하는 것은 아니며, 종종 캐시 효율성은 부차적인 문제로 취급됩니다.
### 캐시 만료(TTL)와 비용 문제
일부 프롬프트 캐시는 기본적으로 짧은 수명(TTL)을 가집니다. 예를 들어, Anthropic의 기본 5분 캐시는 일반적인 코딩 활동 시간보다 짧을 수 있습니다. 사용자가 잠시 자리를 비우고 돌아왔을 때, 짧은 메시지 하나가 예상보다 더 많은 비용을 초래할 수 있습니다. 이는 추론 제공업체가 사용자의 연속적인 세션을 독립적인 요청 시퀀스로 보기 때문입니다. 긴 빌드 시간, 테스트 실행, 점심 식사, 회의 등은 캐시 수명을 초과할 수 있으며, 다음 요청 시 동일한 프롬프트라도 저장된 KV 상태가 사라져 다시 입력으로 처리되어야 합니다. Pi는 현재 Anthropic의 구독 모델에 포함되지 않아 5분 기본값을 따르고 있지만, Claude Code는 자체 구독 사용자에게 캐시 타임아웃을 1시간으로 늘리고 있습니다. 하지만 API 토큰 가격을 고려할 때 이러한 장기 캐시의 비용이 항상 합리적인 것은 아닙니다. 일부 제공업체는 더 긴 보존 제어를 지원하며, Pi 사용자도 특정 설정을 통해 이를 요청할 수 있습니다. 그러나 Pi는 게이트웨이가 캐시 항목을 유지하거나, 메모리 압박 하에서 제거를 방지하거나, 모델 요청이 없을 때 캐시를 활성화 상태로 유지하도록 강제할 수는 없습니다. 캐시 미스는 단순히 비용 증가뿐만 아니라, 제공업체와 사용자 간의 인센티브 불일치를 야기할 수도 있습니다. 입력 토큰에 대한 요금을 부과하는 게이트웨이나 리셀러는 캐시 미스가 발생했을 때 더 많은 수익을 얻을 수 있습니다. 이는 제공업체가 캐시를 의도적으로 방해한다는 의미는 아니지만, 캐시 성능은 투명하게 관찰 가능해야 합니다.
### Pi의 캐시 관리 전략과 가시성 확보
Pi는 안정적인 입력을 유지하기 위해 노력합니다. 일관된 세션 ID와 제공업체별 캐시 힌트를 전달하고, API가 요구하는 경우 명시적인 캐시 지점을 설정하며, 캐시 읽기/쓰기 사용량을 기록하고, 모델이 지원하는 경우 메시지 기반 추가 도구 로딩을 지원합니다. 또한 기본 전사(transcript) 동작은 오래된 컨텍스트를 불필요하게 재작성하는 것을 피합니다. 하지만 Pi는 요청이 기기를 벗어난 후의 모든 계층을 제어할 수는 없습니다. 제공업체의 제거 정책을 선택하거나, API가 허용하는 범위를 넘어 캐시를 확장하거나, 특정 GPU를 활성화 상태로 유지하거나, 게이트웨이가 어피니티를 준수한다고 보장할 수 없습니다. 또한 확장 기능이 변경하는 접두사를 보존할 수도 없습니다. Pi는 캐시 상태를 사용자가 볼 수 있도록 하는 데 중점을 둡니다. 대화 인터페이스의 푸터는 누적 캐시 읽기/쓰기 횟수(R, W)와 최신 요청의 캐시 히트율(CH)을 표시합니다. '/session' 명령은 총 캐시 및 비캐시 입력, 누적 히트율, 비용, 그리고 주요 캐시 미스로 인해 재청구된 토큰 및 비용 추정치를 제공합니다. 사용자는 설정을 통해 캐시 미스 알림을 활성화하여, 주요 미스가 발생했을 때 재청구된 토큰 및 비용 추정치를 포함한 경고를 받을 수 있습니다. 모델 전환이나 짧은 TTL을 초과하는 유휴 시간 등이 감지되면 관련 정보를 제공합니다. 기타 미스에 대해서는 제공업체 내부 사정을 알 수 없으므로 사실만 보고합니다.
### 가치와 인사이트
프롬프트 캐싱은 LLM 기반 에이전트의 성능과 비용 효율성에 직접적인 영향을 미치는 핵심 기술입니다. KV 캐시의 작동 원리를 이해하고, 세션 구조, 도구 관리, 캐시 만료 시간 등 다양한 요인이 캐시 히트율에 미치는 영향을 파악하는 것이 중요합니다. 특히, 도구 로드아웃 변경이나 세션 분기 시 캐시 무효화 가능성을 인지하고, 이를 최소화하기 위한 전략을 수립해야 합니다. 또한, 제공업체의 캐시 정책 및 비용 구조를 이해하고, Pi와 같이 캐시 상태를 투명하게 제공하는 도구를 활용하여 최적의 성능을 달성해야 합니다. 캐시 미스의 비용을 정확히 파악하고, 이를 줄이기 위한 노력이 LLM 에이전트 운영의 경제성을 좌우할 것입니다.
### 향후 전망
향후 LLM 에이전트의 발전은 프롬프트 캐싱 기술의 고도화와 밀접하게 연관될 것입니다. 더 정교한 캐시 관리 알고리즘, 모델 간 KV 캐시 호환성 확보, 그리고 분산 환경에서의 효율적인 캐시 공유 메커니즘 개발이 중요해질 것입니다. 또한, 확장 기능 개발자들이 캐시 효율성을 기본적으로 고려하도록 하는 생태계 조성도 필요합니다. 제공업체들은 더 긴 캐시 수명과 유연한 캐시 제어 기능을 제공하며, 사용자에게는 캐시 성능에 대한 더 명확한 인사이트를 제공해야 할 것입니다. 궁극적으로는 캐시 미스 비용을 최소화하면서도 에이전트의 유연성과 기능을 극대화하는 방향으로 기술 발전이 이루어질 것으로 예상됩니다.
📝 원문 및 참고
- Source: Lobsters
- 토론(Lobsters): [lobste.rs](https://lobste.rs/s/kq9oh7/prompt_caching_agents)
- 원문: [링크 열기](https://earendil.com/posts/prompt-caching/)
---
출처: Lobsters · [원문 링크](https://earendil.com/posts/prompt-caching/)
이 글에 대한 한 줄 의견
신고 · 불법·유해·아동 안전(CSAE) 관련 콘텐츠
댓글 0
아직 댓글이 없습니다. 로그인하면 바로 의견을 남길 수 있습니다.