에이전트 트래픽의 실제 반복률은 얼마나 되나요? 캐싱하기 전에 측정하세요

트래젝토리 캐싱(trajectory caching)은 에이전트가 동일한 문제를 계속 해결할 때만 가치가 있습니다. 따라서 이를 도입하기 전 — 저희 것이든 다른 누군가의 것이든 — 트래픽이 실제로 반복되는지 측정해야 합니다. 이 글은 엔지니어가 가장 먼저 실행해 보았으면 하는 체크리스트이며, 정직한 답변이 '신경 쓸 필요가 없다'인 경우도 포함합니다.

불편한 진실부터 시작하기

Pomerene의 경우 모든 작업이 고유하다면 얻는 이득은 적습니다. 만약 에이전트들이 일회성 버그 수정(one-off bug fixing)을 하거나, 각 티켓이 새로운 조사인 경우, 또는 인식 가능한 형태로 재발하지 않는 고객별 맞춤형 작업을 한다면, 재생할 안정적인 데이터가 없습니다. 고유한 트래픽에 대한 캐시는 항상 적중하지 못하는 조회 테이블과 같습니다. 즉, 거의 0%에 가까운 적중률을 얻기 위해 모든 요청마다 인프라, 스토리지, 그리고 매칭 단계를 추가했다는 의미입니다. 저희는 도움이 되지 않는 키트를 판매하기보다는 이 사실을 명확하게 말씀드리고 싶습니다.

트래젝토리 캐싱이 제 역할을 하는 워크로드는 정반대의 형태를 가집니다. 동일한 의도(intent)를 다루는 지원 에이전트, 예약 흐름(booking flows), FAQ 에이전트, 스케줄링된 작업 등 — 단어는 다르더라도 목표(goal)가 반복되는 모든 곳입니다.

무엇을 측정해야 하는가

첫 번째 분석을 위해 새로운 도구가 필요하지 않습니다. 기존의 트레이스(traces)와 로그만으로 네 가지 수치를 얻기에 충분합니다:

1. 목표 반복률 (Goal repeat rate). 완료된 실행들을 달성하려 했던 '목표'별로 그룹화해야 합니다 — 문자 그대로의 프롬프트가 아니라, 의도(intent)를 기준으로요. 이번 주 실행 중 어떤 비율이 지난주에도 나타났던 목표를 가지고 있었나요? 이것이 최대치입니다. 캐시는 목표가 반복되는 횟수보다 더 자주 적중할 수 없으며, 만약 반복률이 트래픽의 약 5분의 1 미만이라면 경제성이 빠르게 떨어집니다.

2. 구문 재구성 클러스터링 (Paraphrase clustering). 단순 문자열 중복 제거(Raw string deduplication)는 오해를 불러일으킬 수 있습니다. “환불은 언제 되나요?”와 “빚진 돈에 대한 업데이트가 필요해요”라는 문구는 공통 토큰이 전혀 없음에도 불구하고 동일한 목표를 가집니다. 요청들을 임베딩 유사도(embedding similarity)로 클러스터링하고 클러스터 크기를 확인하세요. 단일 항목으로 이루어진 긴 꼬리 분포(long tail of singletons)는 고유한 작업량을 의미하며, 몇 개의 큰 클러스터(fat clusters)가 있다는 것은 소수의 목표가 트래픽을 지배한다는 뜻입니다. 이는 트래젝토리 캐시(trajectory cache)가 활용하는 전형적인 형태입니다.

3. 실행당 비용 (Cost per run). 최종 호출만 아니라 실행의 모든 단계에 걸쳐 토큰을 합산해야 합니다. 에이전트 비용은 중간 도구 사용(intermediate tool-use) 및 추론 단계(reasoning steps)에 숨어 있습니다. 여기에 반복률(repeat rate)을 곱하면, 실제로 어떤 것을 구축하기 전에 절감할 수 있는 달러 단위의 상한선 값을 얻게 됩니다.

4. 지연 시간 분포 (Latency distribution). 종단 간(end-to-end) 실행 지연 시간과 p50 및 p95를 기록하세요. 다단계로 이루어진 긴 실행에서 리플레이가 가장 큰 도움을 줍니다. 완전히 재현된 트래젝토리(fully replayed trajectory)는 전체 단계 시퀀스를 건너뛰기 때문에, 실행이 길고 반복적일수록 히트당 지연 시간 절감 폭이 커집니다.

Pomerene이 작동할 때 보고하는 내용

만약 이 시스템을 배포한다면, Pomerene은 캐시가 이론적으로 계산한 대로 제대로 작동하는지 확인할 수 있는 진단(diagnostics) 뷰를 제공합니다:

• 테넌트별 및 전역 히트율 (Hit rates per tenant and global) — 추적 기록에서 측정한 반복률이 실제 히트로 나타나는지, 그리고 한 테넌트의 트래픽이 다른 테넌트와 다르게 작동하는지 여부를 확인합니다.
• L1 / L2 / 누락 분석 (L1 / L2 / miss breakdown) — 전체 재현(full replays), 부분 재현(partial replays, 에이전트가 캐시된 계획과 일치하지 않는 단계에서 재개한 경우), 그리고 순수 누락(clean misses)을 확인합니다. 건강하게 배포되었다는 것은 모두 L1만 있는 것이 아닙니다. 의미 있는 L2 공유율은 목표가 부분적으로 분기되더라도 캐시가 작업의 공통 접두사(common prefix)를 흡수하고 있다는 것을 의미합니다.
• 히트 경로와 실시간 실행 간의 지연 시간 백분위수 (Latency percentiles).
• 절감된 달러 및 토큰: 재현이 실제로 작동하는 방식에 맞춰 회계 처리가 이루어집니다. L1 히트는 트래젝토리의 모든 토큰을 계산합니다(전체 실행이 건너뜀). 반면, L2 히트는 재현된 부분만 계산합니다. 에이전트가 여전히 실행한 단계는 이중으로 계산하지 않습니다.

품질은 가정하는 것이 아니라 모니터링해야 합니다. /v1/feedback 루프를 사용하면 결과가 캐시로 다시 피드백될 수 있습니다. 재생 품질이 떨어지는 항목은 한 번의 좋은 실행이라는 근거만으로 영원히 서비스되는 대신 제거됩니다.

솔직한 제약 사항 (The honest limits)

설계에 앞서 알아야 할 두 가지 제약 사항이 있습니다. Pomerene은 현재 **단일 작성자 인스턴스(single-writer instance)**로, **메모리 내 벡터 인덱스(in-memory vector index)**와 함께 실행됩니다. 이는 간단하고 빠르지만, 분산 스토리지(distributed store)가 아니라 하나의 프로세스가 캐시를 소유한다는 의미입니다. 또한 저장된 궤적(trajectories)이 임베딩으로 인덱싱되기 때문에, 임베딩 모델을 변경하면 저장된 벡터가 무효화됩니다: 모델을 교체할 경우 인덱스를 제자리에서 마이그레이션하는 대신 다시 구축해야 합니다. 이 두 가지 사항은 숨겨진 조항에 있는 것이 아니므로, 오늘날 배포 환경에 적합한지 여부를 판단할 때 모두 고려해야 합니다.

의사 결정 규칙 (The decision rule)

먼저 목표 반복률(goal repeat rate)과 구문 패러프레이징 클러스터링(paraphrase clustering)을 측정하십시오. 만약 트래픽의 3분의 1 이상이 이미 해결한 목표라면, 궤적 캐싱은 토큰 및 지연 시간 측면에서 스스로 비용을 회수할 가능성이 매우 높으며 — 일주일 안에 진단 도구(diagnostics)를 통해 이를 입증할 수 있습니다. 만약 트래픽 자체가 진정으로 독특한 작업이라면, 캐시 사용을 건너뛰고 그 노력을 다른 곳에 투자하십시오. 어느 쪽이든, 공급업체의 벤치마크가 아닌 자체 데이터로 결정을 내리게 될 것입니다.

Pomerene의 셀프 호스팅 스타터 키트(Self-hosted Starter Kit) — Indie $99 / Pro $249, 일회성 구매, 소스 코드 포함 —에는 위에서 설명한 진단 뷰가 포함되어 있어 측정 과정이 도입 단계에서 멈추지 않습니다. pomerene.io/starter-kit을 확인하십시오.