Prompt Caching vs Intelligent Prompt Routing, Bedrock AI 추론 비용 줄이는 두 전략
최종 수정일: 9월 10일
Prompt Caching vs Intelligent Prompt Routing, Bedrock AI 추론 비용 줄이는 두 전략
Written by Minhyeok Cha
목차
여러분들은 Bedrock 쓰시면서 토큰 비용을 얼마나 신경 쓰고 계신가요? 개발할 땐 테스트 호출 몇 번이라 실감이 없는데, 프로덕션에 올리고 나면 하루 수만 건의 API 호출이 쌓이고, 입력 토큰 하나하나가 다 돈이 됩니다. 그리고 이 문제를 풀겠다고 AWS가 내놓은 대표적인 두 가지 도구가 바로 Prompt Caching과 Intelligent Prompt Routing 입니다.
이번 글에서는 두 기능의 작동 원리부터 실무에서 어떤 상황에 어떤 걸 써야 하는지, 그리고 함께 쓸 때 무엇을 챙겨야 하는지까지 정리했습니다. Bedrock 아키텍처를 처음 설계하는 분들께도, 이미 운영 중인데 비용이 예상보다 많이 나오고 있는 분들께도 판단 기준이 되었으면 합니다.
왜 지금 AI 추론 비용이 문제가 되는 건가요?
엔터프라이즈 GenAI 지출은 2025년 기준 전년 대비 76.4% 성장해 6,440억 달러에 달했고, 2026년에도 약 80.8%의 추가 성장이 전망된다는 Gartner 수치가 있는데요, 이 숫자는 단순히 "AI 산업이 크다"는 얘기가 아닙니다. 그 지출의 상당 부분이 바로 토큰 단위로 청구되는 추론 비용이라는 뜻이기도 합니다.
Bedrock은 호출할 때마다 입력 토큰 수와 출력 토큰 수를 따로 계산해서 청구합니다. 그런데 함정은 토큰 증폭에 있습니다. 사용자가 던진 질문 하나가 내부적으로 여러 번의 모델 호출을 유발하고, Agent 워크플로우에서는 실제 입력·출력보다 4~8배 많은 토큰이 소비되는 경우가 흔합니다. 처음엔 "뭐 얼마나 나오겠어"라고 생각하다가, 프로덕션 트래픽이 붙는 순간 청구서가 예상의 몇 배로 날아오는 경험을 하시는 거죠.
왜 이런 일이 생기는 걸까요? 개발 단계에서는 테스트 호출 몇 번이라 실감이 없고, 시스템 프롬프트가 길어도 신경 쓰이지 않습니다. 그런데 같은 긴 프롬프트가 하루 수만 번 반복 입력되거나, 복잡도와 무관하게 모든 요청이 가장 비싼 모델로 향하고 있다면, 비용은 조용히 그리고 빠르게 쌓입니다.
이 문제를 구조적으로 접근하는 방법이 바로 다음 두 섹션에서 다룰 Prompt Caching과 Intelligent Prompt Routing입니다.
Prompt Caching
캐싱 없이는 모든 API 호출이 이 정적 시스템 프롬프트를 매번 정가로 재처리합니다. Prompt Caching을 켜면, 첫 호출에서 한 번 저장해두고 이후 호출은 90% 할인된 가격으로 읽어오는 구조로 바뀝니다. 마치 영수증 계산을 처음 한 번만 하고, 다음 손님들은 그 계산 결과를 복사해서 쓰는 것과 비슷합니다.
비용 구조도 짚고 넘어가야 하는데요, Claude처럼 서드파티 모델의 경우 캐시 최초 기록(Write) 시에는 일반 입력 토큰 가격보다 약 25% 높은 비용이 발생합니다. 하지만 이후 캐시를 재사용(Read)할 때는 일반 입력 토큰 가격의 약 10%만 내면 되니, 90% 할인이 적용되는 셈입니다. Write는 한 번, Read는 수천 번이 되는 구조라면 수지타산이 분명히 맞습니다.
여기서 실무에서 제일 자주 놓치는 게 TTL(Time To Live), 즉 캐시 유효 시간입니다. 캐시의 기본 유효 시간은 5분이며, 캐시 히트가 발생할 때마다 최대 5분씩 연장됩니다. 호출 간격이 5분을 넘기면 캐시가 만료되고 다시 Write 비용이 발생합니다. 트래픽이 고르지 않은 서비스라면 캐시 히트율이 생각보다 낮을 수 있다는 얘기입니다.
Intelligent Prompt Routing
그런데 Prompt Caching이 "반복되는 내용을 어떻게 덜 낼 것인가"의 문제였다면, Intelligent Prompt Routing은 조금 다른 각도에서 출발합니다. "이 질문, 굳이 비싼 모델한테 물어봐야 할까?"라는 질문이죠.
Intelligent Prompt Routing은 같은 모델 패밀리 안에서 요청의 복잡도를 예측해 적절한 모델로 자동 분기해주는 기능입니다. 개발자가 별도로 라우팅 레이어를 짤 필요 없이, 시스템이 각 요청에 대해 모델별 응답 품질을 예측하고 품질과 비용을 동시에 최적화하는 모델을 선택합니다.
AWS 공식 발표 기준으로는 정확도를 타협하지 않고 최대 30%의 비용 절감이 가능하다고 안내하고 있으며, 벤치마크에 따라 최대 30~50%까지 제시되기도 합니다. 물론 실제 절감 폭은 워크로드 특성에 따라 달라집니다.
실무에서 개인적으로 중요하다고 보는 포인트는 라우팅 판단의 투명성입니다. 어떤 요청이 어느 모델로 갔는지 CloudWatch Logs로 확인할 수 있지만, 라우팅 근거 자체는 블랙박스에 가깝습니다. 예측 품질이 실제 품질과 다를 수 있다는 얘기이고, 처음 도입할 때는 A/B 테스트나 품질 모니터링을 함께 설계해두는 편이 낫습니다.
두 기능 모두 "AI 추론 비용 절감"이라는 목표를 가지고 있지만, 접근하는 축이 완전히 다릅니다. Prompt Caching은 토큰 처리 횟수를 줄이는 전략이고, Intelligent Prompt Routing은 모델 선택의 효율성을 높이는 전략입니다. 전자는 "같은 내용을 얼마나 반복 처리하는가", 후자는 "그 요청에 얼마나 비싼 모델을 쓰는가"를 건드리는 거죠.
구분 | Prompt Caching | Intelligent Prompt Routing |
|---|---|---|
핵심 질문 | 같은 컨텍스트를 반복 처리하고 있는가? | 모든 요청에 동일한 모델을 쓰고 있는가? |
절감 방식 | 반복 입력 토큰 비용 제거 | 단순 요청을 저비용 모델로 분기 |
적합한 워크로드 | 문서 Q&A, 코딩 어시스턴트, 긴 시스템 프롬프트 반복 | 챗봇, 고객 서비스처럼 복잡도 편차가 큰 대화형 서비스 |
개발자 개입 | 캐시 포인트 마킹 필요 | 라우터 설정 후 자동 분기 |
최대 절감 효과 | 비용 최대 90%, 레이턴시 최대 85% | 비용 최대 30~50% |
주요 제약 | 캐시 유효시간 5분, 지원 모델 한정 | 영어 프롬프트 최적화, pairwise 모델만 |
실무에서 제일 자주 받는 질문이 "그러면 둘 중 하나만 골라야 하나요?"인데, 사실 배타적인 관계가 아닙니다. 시스템 프롬프트가 길고 반복적인 서비스에 Prompt Caching을 적용하면서, 동시에 그 서비스의 요청 복잡도 편차가 크다면 Intelligent Prompt Routing을 레이어로 얹는 방식도 충분히 가능합니다.
문제는 각 기능이 효과를 발휘하는 조건이 워크로드에 따라 다르기 때문에, 적용 전에 자신의 서비스가 어느 쪽 손실을 더 많이 내고 있는지를 먼저 파악하는 게 순서입니다.
실무에서 함께 쓸 때 고려해야 할 것들
두 기능을 같이 적용할 때 먼저 확인해야 할 게 있습니다.
첫 번째는 캐시 쓰기 비용입니다. 많은 분들이 "Prompt Caching은 무조건 아끼는 기능 아닌가요?"라고 생각하시는데, 그렇지 않습니다. Claude 같은 서드파티 모델은 캐시 쓰기(cache write) 비용이 일반 입력 토큰 요금보다 약 25% 높게 책정됩니다. 처음 캐시를 만드는 시점엔 오히려 약간 더 나가는 거죠. Bedrock에서 Claude를 쓸 때 캐시 히트율 손익분기점은 대략 30% 수준이고, 히트율이 그 아래라면 캐시 쓰기 비용이 절감액을 초과합니다.
두 번째는 라우터 모델 버전 관리입니다. AWS Bedrock GA 이후 Intelligent Prompt Routing은 모델 패밀리에서 원하는 두 모델을 직접 선택하고 라우팅 기준도 설정할 수 있게 됐는데, 이게 유연성이 생긴 대신 관리 포인트가 늘었다는 의미이기도 합니다. 실제로 콘솔에서 현재 사용 가능한 프롬프트 라우터 구성을 사전에 확인하지 않으면 의도하지 않은 모델 조합으로 라우팅될 수 있습니다. 버전이 자동으로 바뀌는 게 아니기 때문에, 신규 모델이 출시될 때마다 라우터 설정을 함께 검토하는 게 좋습니다.
세 번째는 TTL과 트래픽입니다. Claude Haiku 4.5, Sonnet 4.5, Opus 4.5는 5분 또는 1시간 TTL을 선택할 수 있습니다. 트래픽이 특정 시간대에 몰리는 서비스라면 1시간 TTL이 히트율을 크게 끌어올릴 수 있지만, 요청이 드문드문 들어오는 서비스에선 캐시가 만료된 뒤 쓰기 비용만 반복해서 내는 구조가 됩니다. Intelligent Prompt Routing의 라우팅 판단도 결국 실시간 요청 단위에서 이루어지기 때문에, 트래픽 패턴이 불규칙하면 라우팅 정확도가 떨어질 수 있다는 점도 확인해야 합니다.
마무리
본문에서는 Prompt Caching과 Intelligent Prompt Routing에 대해 소개드렸습니다. 중요한 건 이 두 기능을 어떤 순서로, 어떤 워크로드에 어떻게 사용하느냐입니다. 시스템 프롬프트가 길고 반복성이 높다면 캐싱이 먼저입니다. 요청 복잡도가 들쭉날쭉하고 모델 비용 차이가 크다면 라우팅이 유효합니다.
개인적으로는 두 기능을 처음 도입할 때 CloudWatch에서 CacheReadInputTokens, CacheWriteInputTokens 지표와 실제 모델별 호출 비율을 최소 2주는 모니터링한 뒤에 튜닝하는 걸 권장하는 편입니다. 설정은 금방이지만, 효과가 보이는 데는 트래픽 샘플이 쌓일 시간이 필요하거든요.
AWS Bedrock 아키텍처 설계는 기능 하나하나를 아는 것보다, 자기 워크로드의 패턴을 얼마나 정확하게 파악하고 있느냐가 비용 효율을 좌우합니다.
