AI 기능을 붙여 데모는 멋지게 나왔는데, 청구서가 제품을 망치는 순간이 옵니다. 에이전트를 퍼널에 심는 팀이 늘수록 LLM 사용량=COGS가 되고, 이는 곧 가격 실험 여력(마진)과 전환율을 동시에 잠식합니다. 문제는 “모델이 비싸서”가 아니라, 어디에서 토큰이 타는지 모른 채 스케일한다는 데 있습니다. dev.to의 토큰 비용 측정/절감 글(Alan West)과 LangChain 에이전트 루프 분석(Gabriel Anhaia)이 같은 결론을 줍니다: 측정 없이는 통제도 없다.
맥락을 해석해보면, 토큰 비용이 무서운 이유는 두 가지입니다. 첫째, 토크나이저는 사람이 보는 ‘단어’ 단위로 움직이지 않아 예상이 틀어집니다. 같은 문장도 모델/토크나이저가 바뀌면 토큰이 10~20% 흔들릴 수 있고(Alan West 사례), 이 흔들림은 곧 CAC 회수기간을 늘립니다. 둘째, 에이전트는 “한 번 호출”이 아니라 반복 호출로 비용을 태웁니다. 특히 툴 루프가 걸리면 정상 트레이스(200 OK)로도 비용이 폭증합니다. 실제로 2025년 공개 사례에선 에이전트 루프가 11일간 지속돼 큰 비용 사고로 이어졌다고 합니다(Anhaia 글 언급).
시사점은 명확합니다. 에이전트 COGS 가드레일은 ‘최적화 팁’이 아니라 제품 지표를 지키는 운영 규칙이어야 합니다. 우선순위는 아래 3단계로 잡는 게 가장 빠릅니다.
1) 실비 트래킹(Observability)부터 박는다: 응답 메타데이터의 input/output token을 요청 단위로 로깅하고, 엔드포인트/기능별로 집계합니다. 여기서 중요한 건 총 토큰이 아니라 (a) 시스템 프롬프트 비중 (b) 캐시 읽기 토큰 (c) 출력 토큰 비중입니다. “하루만 돌려도 60%가 반복되는 입력(시스템+컨텍스트)”이 드러난다는 지적은 현실적으로 자주 맞습니다(Alan West).
2) 큰 돈 새는 곳부터 절감한다(상위 20%): - 시스템 프롬프트: 긴 지시문을 매 호출마다 싣는 순간, 트래픽이 곧 비용입니다. 프롬프트 캐싱(Anthropic 등)으로 정적 프리픽스를 캐시하고, 지시문을 1/3 수준으로 압축하되 품질을 A/B로 확인합니다(Alan West). - 컨텍스트: ‘문서 50페이지’를 그대로 넣는 팀은 결국 가격을 못 올립니다. RAG로 관련 청크만 당겨오면 토큰이 구조적으로 내려가고, 응답 속도도 개선돼 전환율에 긍정적입니다(Alan West). - 출력 토큰: 출력이 비싸고 모델은 장황해집니다. max_tokens 상한, 길이 지시(“100단어 이하”), 구조화(JSON)로 통제해야 합니다. 이건 비용 절감이면서 동시에 사용자가 읽기 쉬운 답변으로 전환 품질을 올리는 UX 개선입니다.
3) 에이전트 루프를 ‘제품 버그’처럼 차단한다: LangChain 류 에이전트의 전형적 병목은 “같은 툴을 다른 말로 계속 호출”하는 루프입니다. 원인은 대체로 (a) 툴 설명에 종료 조건이 없거나 (b) 이전 호출 기록이 프롬프트에 명시적으로 보이지 않거나 (c) done 정의가 없어 max_iterations에만 의존하는 경우입니다(Anhaia). 해결책은 성장 관점에서 이렇게 번역됩니다: - 툴 계약서(termination clause)를 docstring에 박아 “한 질문당 1회” 같은 정책을 명시 - TOOL_CALL_HISTORY를 프롬프트에 노출해 반복 호출을 스스로 억제 - 서킷 브레이커: 동일 툴/유사 입력 N회, 런 토큰 예산 초과 시 즉시 중단(실패도 ‘싸게’)
전망: 앞으로 에이전트가 퍼널 깊숙이 들어갈수록, 토큰 대시보드는 ‘옵션’이 아니라 가격/패키징 실험을 가능하게 하는 재무 인프라가 됩니다. TokenBar처럼 “일하는 자리에서 실시간으로 비용이 보이는” 도구가 등장하는 이유도 여기에 있습니다(dev.to, John S.의 경험담). 결국 승자는 모델을 더 똑똑하게 쓰는 팀이 아니라, (1) 엔드포인트별 토큰 예산을 설정하고 (2) 캐시/RAG/출력 상한으로 변동성을 죽이고 (3) 루프를 구조적으로 차단해 비용 사고를 제로에 가깝게 만드는 팀입니다. 그때부터 에이전트는 비용 센터가 아니라, 전환율을 올리면서도 마진을 지키는 ‘레버’가 됩니다.