DevLog

엔지니어링 블로그를 한 곳에서 탐색하고, 최근 발행 흐름을 빠르게 파악할 수 있는 서비스 입니다.

Quick Links

  • Latest Feed
  • Engineering Directory

Support

  • 소개
  • 개인정보처리방침

Contribute

  • 원하는 블로그 추가 (준비 중)
  • Feedback

© 2026 DevLog Inc. All rights reserved.

본 사이트는 공개 RSS 피드를 통해 콘텐츠를 수집하며, 모든 콘텐츠의 저작권은 원저작자에게 있습니다.

Back to Feed
Read Original

Contents

Continue Reading

  • More from 무신사
  • Related reads#AWSBedrock
#Backend

LLM 비용 64% 절감, 캐시 히트율 98% 달성기

LLM 비용 64% 절감, 캐시 히트율 98% 달성기
01

Summary

15K 시스템 프롬프트의 늪에서 탈출하기: 29CM의 LLM 비용 64% 절감기

가시성 확보부터 Prompt Caching 도입, 그리고 오픈소스 기여까지 이어진 똑똑한 비용 최적화 여정

이 아티클은 AWS Bedrock 기반 LLM 서비스를 운영하며 기하급수적으로 늘어나는 비용 문제를 해결한 실전 기술 스택을 소개합니다. 프로메테우스와 그라파나를 통해 API별 메트릭 가시성을 먼저 확보한 뒤, 비용의 주범이었던 프롬프트 중복 전송 문제를 Prompt Caching을 통해 해결하고 실제 64%의 비용 절감을 이루어낸 생생한 과정을 담고 있습니다.

  • 01API별 토큰 사용량을 추적하기 위해 LangChain4j 기반의 메트릭 수집 파이프라인과 그라파나 대시보드 구축
  • 02비용의 92%를 차지하는 원인이 15K 크기의 동일한 시스템 프롬프트가 매번 반복 전송되는 설계적 한계임을 파악
  • 03AI 비용 시뮬레이션을 통해 여러 최적화 옵션 중 Prompt Caching이 최우선 해결책임을 데이터 기반으로 입증
  • 04고정 영역(시스템 프롬프트)과 동적 영역(메시지)을 정교하게 분리하고 Bedrock Converse API의 캐시 마커 설정
  • 05LangChain4j 라이브러리의 캐시 TTL 설정 한계를 극복하기 위해 직접 오픈소스 PR을 작성하고 병합 성공

+RECOMMENDATION

LLM 비용이 우상향하고 있으나 정확도 저하 우려로 모델 교체나 파인튜닝이 망설여지는 백엔드 및 AI 엔지니어에게 추천합니다. 반복적으로 사용되는 대용량 시스템 프롬프트가 있다면 Prompt Caching 도입과 프롬프트 구조화 작업을 즉시 고려해 보세요.

The Problem

AWS Bedrock에서 발생하는 구체적인 API별 LLM 비용과 토큰 사용량에 대한 가시성이 부족하여 최적화 대상을 식별하기 어려웠습니다. 가시성 확보 후 분석 결과, 속성 추출 단일 API가 대용량 시스템 프롬프트(15K)를 반복 전송하여 전체 토큰 사용량의 92%를 차지하는 문제가 발견되었습니다.

The Solution

LangChain4j의 ChatModelListener와 프로메테우스/그라파나를 연동하여 API별 실시간 토큰 메트릭 대시보드를 구축하였습니다. 이후 시스템 프롬프트(고정)와 메시지 프롬프트(변동)를 물리적으로 분리하고, AWS Bedrock Converse API에 TTL 1시간의 Prompt Caching 마커를 추가 적용하였습니다.

The Result

속성 추출 API의 캐시 히트율 98%를 달성하였으며, 이를 통해 29CM 서비스 전체 LLM 청구 비용의 64%를 절감하였습니다. 또한 사전에 실행한 AI 기반 비용 시뮬레이션의 예측값과 실제 결과값이 1%p 오차 내로 정확하게 일치함을 검증하였습니다.

Trade-off

프롬프트 캐싱은 prefix matching 방식으로 동작하기 때문에 시스템 프롬프트 내에 타임스탬프, 사용자 ID 등의 동적 데이터가 포함되거나 JSON 키 순서가 일관되지 않을 경우 캐시가 무효화되는 안티패턴에 취약합니다. 또한, 동시에 병렬 요청이 발생할 경우 첫 쓰기가 완료되기 전까지 캐시 미스가 발생할 수 있어 캐시 워밍(Cache Warming) 등의 추가 관리가 필요합니다.

03

Key Concepts

Concept · 01

Prompt Caching (프롬프트 캐싱)

LLM 요청 시 변경되지 않는 공통 프롬프트 부분을 캐시에 저장해두고 재사용함으로써 입력 토큰 비용과 대기 시간을 줄이는 기술입니다.

  • 매번 전송되던 15K 크기의 고정 시스템 프롬프트를 캐싱 영역으로 지정하여 반복 연산을 방지함
  • AWS Bedrock Converse API의 CachePointBlock을 사용해 캐시 마커 및 1시간 TTL 설정
Concept · 02

Prefix Matching (접두사 매칭)

캐시 시스템이 요청 프롬프트의 시작 부분부터 해시 값을 비교하여 일치하는 구간까지만 캐시를 적용하는 메커니즘입니다.

  • 동적 변수가 시스템 프롬프트 앞단에 오면 캐시가 무효화되므로 고정값과 변동값의 위치를 물리적으로 분리함
  • 타임스탬프, 사용자 ID 등을 유저 메시지로 이동시키는 Relocation Trick 적용의 핵심 원리
Concept · 03

ChatModelListener (LangChain4j)

LLM 프레임워크인 LangChain4j에서 제공하는 리스너 인터페이스로, LLM API 요청 및 응답 시점의 메타데이터를 가로채 처리할 수 있습니다.

  • Bedrock API 호출 시 발생하는 실시간 토큰 사용량(input, output, cache_read, cache_write)을 가로채 프로메테우스 메트릭으로 기록함
  • Servlet Filter와 결합하여 어떤 API 경로에서 LLM 요청이 발생했는지 추적하는 가시성 인프라 구축
Continue reading · same source

무신사More from 무신사

View all posts from 무신사
  • VLM을 쓰지 않은 이유: Geometric Prior로 25배 빠른 의류 디테일컷 자동화

    Object DetectionAWS LambdaComputer Vision
    1개월 전
  • AI 스페셜리스트와 자동사냥 — 하네스로 제어하는 AI 파이프라인

    AI AgentHarness EngineeringQuery Optimization
    1개월 전
  • 무신사 메가스토어 성수: 보이지 않는 기술, 선명해지는 경험

    RFIDPOSESL
    2개월 전
  • The Human: 점수 너머의 판단

    LLMTechnical InterviewPrompt Engineering
    2개월 전
  • The Machine: AI가 AI 활용 코드를 평가하다

    LLMMulti-AgentEvaluation Pipeline
    2개월 전

Related reads#AWSBedrock

Explore #AWSBedrock
우아한형제들

우아한공방의 새로운 동료, 시스템 맥락을 가진 챗봇서비스 개발기(feat. RAG)

#AWSBedrock1개월 전
포스타입·Claude

포스타입 캐릭터톡 출시기 1부

#AWSBedrock2개월 전
우아한형제들·LLM

5년 동안 못 푼 배민 다국어 숙제, AI와 함께 한 달 만에 끝내기

#AWSBedrock3개월 전
포스타입

"알아서 정확하게 응답줬으면.." RAG부터 에이전트까지 사내 AI 챗봇 구축기 2부

#AWSBedrock5개월 전
포스타입·RAG

"스펙 문서에 없는데요?" 최신 스펙 갱신을 위한 사내 AI 챗봇 도입기 1부

#AWSBedrock5개월 전

Source

무신사
무신사
Engineering Blog

Published · July 7, 2026

Topics

AWS BedrockPrompt CachingLangChain4jPrometheusGrafana