이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
게임 회사의 VIP 고객 지원용 human-in-the-loop ReAct 에이전트는 플레이어 선호도, 계정 상태, 거래 자격, 절차 문서가 매 요청마다 반복 전송되면서 예상보다 높은 비용을 냈습니다. 팀은 먼저 중복 규칙과 불필요하게 장황한 문장을 제거해 프롬프트 토큰을 15% 줄인 뒤, 고정된 시스템 프롬프트와 도구 스키마를 캐시해 남은 비용을 추가로 25% 낮췄습니다. 두 절감률을 연속 적용한 결과 전체 비용은 0.85×0.75=0.64, 즉 36% 감소했으며 출력 품질과 평가 점수에는 측정 가능한 변화가 없었습니다. 티켓별 프로필은 호출 횟수가 1~2회에 그쳐 캐시 쓰기 비용을 상쇄하지 못했기 때문에 제외했고, 캐시 크기보다 만료 전 재사용 횟수가 중요하다는 결론을 얻었습니다.
섹션별 상세
ReAct 에이전트는 사용자가 한 번 메시지를 보낸 경우에도 도구 호출 결과를 반영할 때마다 전체 프롬프트를 다시 전송합니다. 도구를 두 번 호출하면 최소 세 번의 모델 요청이 발생하고, 세 번째 요청에는 전체 시스템 프롬프트와 도구 스키마, 플레이어 프로필, 대화 기록이 함께 들어갑니다. 이 구조에서 입력 비용을 줄이려면 모델 호출 수보다 반복되는 입력 토큰의 구성과 재전송 횟수를 먼저 봐야 합니다.
프롬프트는 모든 티켓에 같은 Tier 1, 티켓마다 고정되는 Tier 2, 매 턴 변하는 Tier 3으로 나뉘었습니다. Tier 1은 약 14,000토큰으로 첫 요청 입력의 76%를 차지했고, Tier 2는 약 3,500토큰, Tier 3은 약 800토큰에서 시작해 계속 늘어났습니다. 안정적인 내용을 앞에 두고 변동 내용을 뒤에 두는 순서가 캐시 접두사의 동일성을 유지하는 기반이 되었습니다.
캐싱 전에 중복 규칙을 하나로 합치고, 장황한 표현을 줄이며, 좁은 상황에만 맞는 예시를 일반 규칙으로 바꿨습니다. 모델에 “remove redundancy and simplify phrasing, change no behavior”를 입력해 초안을 압축한 뒤 사람이 중요한 제약 조건을 대조했고, 이미 간결하다고 여긴 프롬프트에서도 토큰이 15% 감소했습니다. 이 단계는 캐시 저장 비용 없이 이후 모든 최적화의 기준 비용을 낮추므로 가장 먼저 수행할 가치가 있습니다.
Amazon Bedrock의 사례에서 캐시 쓰기는 5분 TTL 기준 일반 입력 비용의 1.25배이고 캐시 읽기는 약 0.1배였으며, 캐시 가능한 접두사는 모델에 따라 512~4096토큰 이상이어야 했습니다. Tier 1은 여러 티켓의 요청이 같은 5분 창 안에서 계속 읽어 높은 재사용률을 만들었지만, Tier 2는 티켓 종료와 함께 사라져 요청 2~3회 중 1~2번만 읽혔습니다. 따라서 팀은 Tier 1 중단점만 유지하고 Tier 2 중단점을 제거했으며, 캐시 크기보다 만료 전 읽기 횟수가 손익을 결정한다고 판단했습니다.
두 최적화는 15%와 추가 25% 절감으로 이어져 원래 비용의 0.85×0.75=0.64가 되었습니다. 이는 절감률을 단순히 더한 40%가 아니라 남은 비용에 두 번째 절감률을 적용한 결과로, 전체 비용 36% 감소를 뜻합니다. 출력 품질과 평가 점수에 측정 가능한 변화가 없었기 때문에 프롬프트 구조를 바꾸면서도 결과 품질을 유지한 사례가 되었습니다.
5분 TTL은 피크 시간에는 요청이 계속 들어와 캐시가 유지되지만, 한산한 시간에는 티켓이 10~15분 간격으로 도착해 매번 새로 쓰고 한두 번 읽은 뒤 만료되는 문제가 있었습니다. 티켓이 12분 간격으로 오고 요청이 티켓당 세 번 발생하는 조건에서 5분 TTL의 상대 비용은 7.25배, 1시간 TTL은 3.40배로 계산되어 긴 TTL이 한산한 시간대에서 유리했습니다. 다만 1시간 TTL은 쓰기 비용이 2배이므로 피크 시간에 적용하면 오히려 손해가 될 수 있어 트래픽 기반 스케줄러와 추가 장애 지점이 필요합니다.
캐시를 적용하기 전에 더 저렴한 모델로 분류, 라우팅, 정보 추출, human escalation 판단을 처리하고 복잡한 추론이 필요한 턴에만 고가 모델을 쓰는 방법이 우선 고려 대상입니다. 플레이어 프로필 전체를 항상 앞에 넣는 대신 get_player_details 도구나 필요할 때 로드하는 skill을 사용하면 모든 티켓에서 발생하는 고정 비용을 드문 추가 왕복으로 바꿀 수 있습니다. 글에서는 이 지연 로딩을 아직 정량 측정하지 않았지만, 거의 읽히지 않는 비싼 내용은 캐시하기보다 애초에 접두사에서 제외하는 편이 유리할 가능성을 제시합니다.
용어 해설
- ReAct
- — ReAct는 언어 모델이 현재 맥락을 읽고 추론한 뒤 도구를 호출하고, 결과를 다시 읽어 다음 행동을 결정하는 에이전트 실행 방식입니다. 한 번의 사용자 상호작용이 여러 모델 요청으로 확장되므로 반복되는 프롬프트 비용이 핵심 문제가 됩니다.
- 프롬프트 캐싱(Prompt Caching)
- — 프롬프트 캐싱은 이전 요청에서 처리한 프롬프트의 동일한 앞부분을 저장해 다음 요청에서 재사용하는 기능입니다. 고정된 시스템 지침이나 도구 스키마를 매번 새로 처리하지 않으므로 입력 토큰 가격과 첫 토큰 지연을 낮출 수 있습니다.
- TTL
- — TTL은 캐시 항목이 유지되는 시간입니다. 이 글의 Amazon Bedrock 사례에서는 5분 TTL과 1시간 TTL을 비교하며, 호출 간격이 긴 트래픽에서는 긴 TTL이 캐시 재사용을 늘리지만 캐시 쓰기 비용은 더 높아집니다.
- 캐시 중단점(Cache Breakpoint)
- — 캐시 중단점은 프롬프트에서 캐시할 접두사의 끝을 지정하는 위치입니다. 중단점 위쪽의 내용이 바뀌면 그 아래의 캐시도 무효화되므로, 변하지 않는 시스템 프롬프트와 티켓별 정보를 순서에 맞게 배치해야 합니다.
- 도구 스키마(Tool Schema)
- — 도구 스키마는 에이전트가 호출할 수 있는 도구의 이름과 입력 형식을 담은 프롬프트 구성 요소입니다. ReAct 루프마다 함께 전송되며, 모든 티켓에서 동일하다면 캐시 가능한 고정 접두사에 포함할 수 있습니다.
기술
- ReAct
- Amazon Bedrock
- Claude
- Anthropic
- OpenAI
- Gemini
- cache_control
활용 사례
- 게임 VIP 고객 지원
- human-in-the-loop 고객 지원 에이전트
- 도구 호출 기반 ReAct 에이전트
- 분류·라우팅·정보 추출 작업
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 09. 02.수집 2026. 09. 02.출처 타입 RSS
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
