
가시성 확보부터 Prompt Caching 도입, 그리고 오픈소스 기여까지 이어진 똑똑한 비용 최적화 여정
이 아티클은 AWS Bedrock 기반 LLM 서비스를 운영하며 기하급수적으로 늘어나는 비용 문제를 해결한 실전 기술 스택을 소개합니다. 프로메테우스와 그라파나를 통해 API별 메트릭 가시성을 먼저 확보한 뒤, 비용의 주범이었던 프롬프트 중복 전송 문제를 Prompt Caching을 통해 해결하고 실제 64%의 비용 절감을 이루어낸 생생한 과정을 담고 있습니다.
LLM 비용이 우상향하고 있으나 정확도 저하 우려로 모델 교체나 파인튜닝이 망설여지는 백엔드 및 AI 엔지니어에게 추천합니다. 반복적으로 사용되는 대용량 시스템 프롬프트가 있다면 Prompt Caching 도입과 프롬프트 구조화 작업을 즉시 고려해 보세요.
AWS Bedrock에서 발생하는 구체적인 API별 LLM 비용과 토큰 사용량에 대한 가시성이 부족하여 최적화 대상을 식별하기 어려웠습니다. 가시성 확보 후 분석 결과, 속성 추출 단일 API가 대용량 시스템 프롬프트(15K)를 반복 전송하여 전체 토큰 사용량의 92%를 차지하는 문제가 발견되었습니다.
LangChain4j의 ChatModelListener와 프로메테우스/그라파나를 연동하여 API별 실시간 토큰 메트릭 대시보드를 구축하였습니다. 이후 시스템 프롬프트(고정)와 메시지 프롬프트(변동)를 물리적으로 분리하고, AWS Bedrock Converse API에 TTL 1시간의 Prompt Caching 마커를 추가 적용하였습니다.
속성 추출 API의 캐시 히트율 98%를 달성하였으며, 이를 통해 29CM 서비스 전체 LLM 청구 비용의 64%를 절감하였습니다. 또한 사전에 실행한 AI 기반 비용 시뮬레이션의 예측값과 실제 결과값이 1%p 오차 내로 정확하게 일치함을 검증하였습니다.
Trade-off
프롬프트 캐싱은 prefix matching 방식으로 동작하기 때문에 시스템 프롬프트 내에 타임스탬프, 사용자 ID 등의 동적 데이터가 포함되거나 JSON 키 순서가 일관되지 않을 경우 캐시가 무효화되는 안티패턴에 취약합니다. 또한, 동시에 병렬 요청이 발생할 경우 첫 쓰기가 완료되기 전까지 캐시 미스가 발생할 수 있어 캐시 워밍(Cache Warming) 등의 추가 관리가 필요합니다.
LLM 요청 시 변경되지 않는 공통 프롬프트 부분을 캐시에 저장해두고 재사용함으로써 입력 토큰 비용과 대기 시간을 줄이는 기술입니다.
캐시 시스템이 요청 프롬프트의 시작 부분부터 해시 값을 비교하여 일치하는 구간까지만 캐시를 적용하는 메커니즘입니다.
LLM 프레임워크인 LangChain4j에서 제공하는 리스너 인터페이스로, LLM API 요청 및 응답 시점의 메타데이터를 가로채 처리할 수 있습니다.









