AI 에이전트 비용 95% 절감 사례: 프롬프트 캐시 적중률과 서브에이전트 설계의 실제

핵심 메시지

• 출시 2주 전부터 출시일까지 비용을 90~95% 줄였고, 절감분의 대부분은 토큰 비용과 낭비된 도구 호출을 걷어낸 데서 나왔다.
• 프롬프트 캐시는 있으면 좋은 최적화가 아니라 제품의 생존 조건이며, 이 회사는 캐시 적중률 약 95%를 유지한다.
• 캐시 키는 프롬프트 앞부분을 해시해 서버로 라우팅하는 구조라 초당 요청 수 상한에 걸리므로, 사용자 ID 해시와 난수를 섞어 캐시를 하루 종일 분산해 데워 둔다. 요청 분포를 아는 쪽은 서비스 개발자라 모델 제공자가 이 문제를 대신 풀어 주기도 어렵다.
• LLM을 심판으로 쓸 때는 반드시 다른 회사 모델을 써야 한다. 같은 분포끼리 평가하면 사람의 집단사고에 해당하는 모드 붕괴가 생긴다.
• 스킬 파일은 엔지니어에게 익숙한 형식일 뿐이고, 회사 고유의 지식은 차라리 메모리로 다루는 편이 일반 사용자에게 맞을 수 있다.

쉽게 이해하기

랭체인 팟캐스트에 나온 코너 헤기는 영업·마케팅용 에이전트를 만드는 유니파이의 공동창업자이자 최고기술책임자다. 이들은 영업을 설득이 아니라 검색 문제로 정의한다. 우리 제품이 유독 잘 푸는 문제를 가진 회사를 인터넷 전체라는 비정형 데이터에서 찾아내는 일이라는 것이다. 3년 전에는 도구 호출과 반성을 반복하는 웹 리서치 에이전트를 만들어, 예컨대 어떤 회사가 본인 확인 절차를 수행하는지를 이용약관과 페이지 HTML까지 뒤져 판별했다. 최근에는 이 역량을 채팅 제품으로 옮겨, 영업 담당자 한 명이 필요할 때 엔지니어를 옆에 둔 것처럼 쓰게 만드는 방향으로 갔다.

가장 실전적인 대목은 비용이다. 출시 2주 전 시점과 출시일 사이에 비용을 90~95% 줄였는데, 서브에이전트를 지나치게 많이 돌린 것이 주된 원인이었다. 절감의 대부분은 토큰 비용을 낮춘 데서 나왔고, 결과를 실제로 쓰지도 않을 벤더 API를 호출하는 낭비된 도구 호출을 줄인 것도 컸다. 헤기는 낭비된 도구 호출을 줄이는 것이 자신들이 가장 먼저 잡는 지표라고 말한다. 정작 체감 효과가 가장 컸던 조치는 의외로 단순했다. 사용자의 요청을 받으면 곧장 실행하지 말고 잠시 멈춰 계획을 세우고, 몇 가지 확인 질문을 던진 뒤 후보 경로를 미리 정찰하게 하는 계획 단계를 앞에 붙인 것이다.

프롬프트 캐시 이야기는 이 대담의 핵심이다. 도구 호출 결과를 다시 모델에 넣을 때 이전에 계산한 키·값 캐시를 재사용하면 비용이 크게 내려가는데, 헤기는 이것을 제품이 되느냐 안 되느냐를 가르는 이진 조건이라고 표현한다. 문제는 캐시 키가 프롬프트 앞부분 몇십 글자를 해시해 서버로 보내는 방식이라, 같은 키로 초당 15개 정도를 넘기면 나머지는 다른 기계로 흩어진다는 점이다. 100개를 한 번에 보내면 15개 남짓만 캐시에 맞고 85개는 각자의 기계를 데운다. 그래서 이들은 사용자 ID를 16개 해시로 나누고 여기에 1부터 30까지의 난수를 붙여 캐시 키를 분산시켰고, 하루 동안 여러 기계를 골고루 데워 두는 방식으로 적중률 약 95%를 유지한다. 제공자가 언젠가 알아서 해 줄 문제 아니냐는 질문에 헤기는 단호하다. 들어오는 요청의 분포를 아는 쪽은 서비스 개발자다. 이 사용자가 어떤 테넌트에 속하는지, 지금 서브에이전트 배치의 일부인지, 같은 테넌트 사용자들의 프롬프트 앞부분이 어디까지 겹치는지는 개발자만 안다. 그리고 제공자 입장에서는 캐시가 맞든 안 맞든 요금은 청구된다. 결국 어려운 엔지니어링은 개발자 몫이라는 것이다. 응답 API가 이전 사고 과정을 다음 호출로 넘겨 주지 않으면 품질의 20~30%를 잃는다는 지적, 이전 턴의 사고 토큰이 제거되면서 캐시가 통째로 빗나가던 문제가 최근 이를 유지하는 옵션으로 완화됐다는 이야기도 같은 맥락에서 나온다.

평가 방식도 흥미롭다. 자율주행 회사에서 일했던 경험 때문에 그는 지표만 보지 않는다. 팀이 모여 여러 체크포인트의 예측 영상을 한 시간 넘게 함께 보던 방식처럼, 지금도 사용자 의도별로 분류한 실제 대화 수백 건을 직접 들여다본다. 그 위에 회귀 테스트용 데이터셋을 따로 쌓아 두고, 도구 호출 수와 비용 같은 지표로 개선을 측정한다. 특히 강조하는 원칙이 하나 있다. 심판 역할의 모델은 평가 대상과 절대 같은 분포일 수 없다는 것이다. 자사 에이전트가 한 회사 모델을 쓴다면 심판은 다른 회사 모델을 써야 한다. 같은 분포끼리 대화하면 사람의 집단사고에 해당하는 모드 붕괴가 생기므로, 오히려 적대적일 만큼 다른 쪽이 낫다는 설명이다.

메모리 설계도 구조적이다. 사용자의 메일함을 분석해 어떤 제품을 어떤 사람에게 어떻게 설명하는지를 미리 뽑아 두는 초기 추출 단계가 있고, 그 뒤로는 대화 서너 건마다 후보 메모리를 과하게 많이 제안한 다음 백그라운드 작업이 이를 정리한다. 정리 단계에서는 초안을 활성으로 승격하거나, 두 메모리를 병합해 새 메모리를 만들거나, 오래된 것을 폐기하거나, 특정 메모리가 다른 것을 대체했다고 표시하는 식으로 조작 이력을 남긴다. 이력을 남기는 이유는 관측 가능성이다. 석 달 뒤에 이상한 동작을 발견했을 때 왜 그렇게 됐는지 되짚을 근거가 필요하기 때문이다. 키는 여섯일곱 개로 고정했다. 에이전트가 분류 체계까지 스스로 늘리게 하면 복잡도가 더해지는 것이 아니라 곱해진다는 판단이다. 스킬 파일에 대한 견해도 남는다. 이들은 이미 데이터 공급사별 접근 방식 등을 담은 스킬 파일을 수십 개 관리하고 있지만, 회사마다 다른 관행, 예컨대 각자의 세일즈포스 인스턴스를 다루는 방법 같은 것을 굳이 스킬 파일로 만들어야 하는지에는 회의적이다. 엔지니어는 런북 쓰듯 스킬 파일 쓰는 것을 좋아하지만 다른 직군은 그렇지 않다. 그렇다면 우리 회사의 세일즈포스는 이렇게 돌아간다는 사실은 그냥 회사에 대한 메모리로 두면 된다는 것이다. 지시문을 쓸 때는 항상 하라거나 절대 하지 말라는 표현을 피하고 이유를 설명하는 쪽을 택한다. 모델은 지시를 문자 그대로 따르기 때문에, 예외가 3%만 있어도 그 3%에서 영영 옳은 행동을 못 하게 된다는 이유에서다.

주요 인사이트

• 에이전트 비용은 모델 단가보다 낭비된 토큰과 호출에서 결정된다. 결과를 쓰지도 않을 도구 호출을 줄이는 것이 모델 교체보다 먼저 손댈 지점이다.
• 프롬프트 캐시는 켜고 끄는 스위치가 아니라 분산 시스템 설계 문제다. 캐시 키가 어떻게 라우팅되는지 모르면 적중률은 통제 밖에 놓이고, 요청 분포를 아는 쪽은 서비스 개발자뿐이라 제공자에게 기대하기도 어렵다.
• 심판 모델을 대상 모델과 다른 계열로 두라는 원칙은 평가 설계의 기본으로 삼을 만하다. 같은 분포끼리 평가하면 틀린 방식으로 사이좋게 수렴한다.
• 메모리에 병합·폐기·대체 같은 조작 이력을 남기는 것은 성능이 아니라 관측 가능성을 위한 투자다. 몇 달 뒤 이상 동작을 설명할 수 있어야 한다.
• 오픈소스 모델은 토큰 단가가 싸도 도구 호출 효율이 낮으면 총비용에서 손해일 수 있다. 단가가 아니라 작업당 비용으로 비교해야 한다.

자주 묻는 질문

관련 AI 소식