AI 에이전트/LLM 제품의 성장 병목은 기능 부족이 아니라 COGS(추론비) 통제 실패에서 터집니다. 월말에 API 청구서가 $180→$1,800로 불어도, “어느 작업이 돈을 먹는지”를 모르면 팀은 감으로 최적화하다가 정작 ROI가 높은 기능을 잘라버립니다. dev.to의 AskPatrick이 말한 ‘Cost Attribution Gap(비용 귀속의 공백)’이 여기서 시작합니다.
문제의 핵심은 집계 비용(aggregate)만 보는 순간 의사결정이 뒤집힌다는 점입니다. 소스의 사례처럼 문서 리뷰 에이전트(비싸 보이지만 실제론 $0.12/run)가 아니라, 라우팅 에이전트가 설정 오류로 1번이면 될 모델 호출을 8번 반복해 $0.38/run에 200회/일로 새는 구조가 더 위험합니다. “깎아야 할 비용”이 아니라 “새는 지점”을 찾아야 합니다.
velog 글이 정리하듯 LLM 비용은 결국 토큰 단가 × 토큰 총량이며, 총량은 ‘요청당 토큰’과 ‘트래픽’이 곱해질 때 폭발합니다. 특히 출력 토큰은 생성 지연(레이트시)과 비용을 동시에 밀어 올립니다. max_tokens는 UX 옵션이 아니라 비용 상한 스위치입니다. 즉, COGS 계측은 재무가 아니라 운영(traffic·latency) 그 자체입니다.
AskPatrick이 제안하는 해결은 과하게 거창하지 않습니다. task_id/task_type에 더해 cost_estimate·cost_actual, tool_calls_estimate·tool_calls_actual 두 쌍만 per-run 로그로 남기면 됩니다(dev.to). 이 20분짜리 ‘두 필드’가 중요한 이유는, 2주만 쌓아도 (1) 단위 가치 대비 과금이 큰 작업, (2) 프롬프트/루프 변경으로 인한 비용 회귀(regression), (3) 모델 라우팅 기준을 데이터로 확정할 수 있기 때문입니다.
여기서 그로스 관점의 레버가 열립니다. per-task COGS가 보이면 가격 실험이 가능해집니다. 예를 들어 “고비용 작업(>$0.20/run)이면서 빈도가 높은” 구간은 (a) 더 작은 모델로 라우팅, (b) 출력 길이 제한, (c) 실패 시 재시도 정책 축소 같은 운영 실험으로 원가를 깎고, 절감된 마진을 유료 전환(Conversion) 인센티브나 더 공격적인 CAC 상한으로 재투자할 수 있습니다. 반대로 “저비용·고빈도”는 기본 플랜에 묶고, “고비용·저빈도”는 프리미엄 기능으로 가격 차별화하는 설계가 깔끔해집니다.
비용은 모델만 바꿔서 줄지 않습니다. 또 다른 dev.to 글이 강조하는 ‘Tool Minimalism(도구 미니멀리즘)’은 COGS와 신뢰도를 동시에 개선합니다. 도구가 많아질수록 에이전트의 선택 조합이 기하급수로 늘고(20개 도구면 190가지 2-step 조합), “무엇을 할지 고민하는 토큰”이 늘어나며 디버깅 비용도 폭발합니다. 5개 내외(read/write/search/execute/escalate)로 툴 스택을 정리하면, 의사결정 토큰이 줄어 per-run 비용이 내려가고 실패율도 함께 떨어집니다(기사 사례에선 토큰 41%↓, 에러 67%↓).
시사점은 명확합니다. 에이전트 제품팀은 ‘기능 로드맵’보다 먼저 작업 단위 원가표를 만들어야 합니다. ① 모든 에이전트 실행을 task_type으로 분류하고 ② estimate vs actual 갭을 디버그 신호로 쓰며 ③ 기능별 max_tokens/툴콜 상한을 걸고 ④ “툴 추가는 ROI 문서화 후 승인”으로 운영 규칙을 바꾸는 순간, COGS는 통제 가능해집니다. 그러면 LTV를 해치지 않으면서도 가격/패키징 실험의 폭이 넓어지고, CAC 한계선이 뒤로 밀립니다.
전망: AI 에이전트 시장이 성숙할수록 경쟁력은 ‘더 똑똑한 데모’가 아니라 ‘예측 가능한 단위경제’로 수렴합니다. 사용자 수가 늘수록 토큰 비용은 선형으로 따라오지만, 비용 귀속과 툴/토큰 상한이 잡힌 팀은 원가 곡선을 눌러 마진을 방어합니다. 결국 다음 승자는 모델 선택보다 per-task 비용 계측 → 비용 회귀 알림 → 라우팅/툴 스택 최적화를 표준 운영 루프로 만든 팀입니다.