에이전트/LLM 제품에서 요즘 가장 위험한 착각은 “성능만 올리면 된다”입니다. 실제로는 토큰 COGS(고객 1명당 토큰 원가)와 신뢰(안정성/보안)가 먼저 무너지며, 그 순간 CVR과 리텐션이 같이 꺾입니다. 비용이 통제되지 않으면 가격 실험도 못 하고, 신뢰가 깨지면 온보딩을 아무리 다듬어도 회복이 어렵습니다.
dev.to의 「Per-customer cost attribution without a proxy」는 이 문제를 정면으로 다룹니다. 많은 비용 추적 솔루션이 LLM 트래픽을 프록시로 우회시키지만, 그건 그로스 관점에선 전환율을 갉아먹는 지연(50~200ms) + 장애 단일점 + 프롬프트/PII 유출 리스크를 한 번에 얹는 선택입니다. 비용을 보려고 병목을 추가하는 셈이죠.
대신 제안하는 해법은 간단합니다. 요청 단위로 사용 토큰을 받아오고(응답의 usage), 고객 ID에 귀속해 비동기 로깅합니다. 앱은 공급자(OpenAI/Anthropic 등)와 직접 통신하고, 응답을 유저에게 반환한 뒤 백그라운드 잡(BullMQ/Inngest 등)으로 비용을 기록합니다. 비용 트래킹은 “크리티컬 패스 밖”에 두는 게 핵심입니다. 장애가 나도 제품이 느려지거나 멈추지 않습니다.
두 번째 dev.to 글(「I Killed My OpenClaw… Then the Token Bill Arrived」)은 왜 토큰 COGS가 KPI가 되어야 하는지, 실패 사례로 보여줍니다. 문제는 ‘많이 쓰면 비싸다’가 아니라 아무도 안 써도 돈이 새는 구조입니다. 하트비트(주기적 체크), 매 요청마다 풀 컨텍스트 로딩, 도구 체인으로 인한 다단 호출이 합쳐지면 “살아있기만 해도” 비용이 발생합니다. 이건 유저가 체감하기 전에 먼저 마진과 런웨이를 태웁니다.
여기서 중요한 맥락 해석: 토큰 비용은 단순 운영비가 아니라 퍼널 변수입니다. (1) 무료 체험/프리미엄에서 과금 전환을 막는 숨은 마찰이고, (2) 파워유저가 늘수록 적자가 커지는 ‘성장 독’이며, (3) 비용 통제 실패는 결국 속도 저하/제한/에러로 이어져 신뢰를 깎고 리텐션을 떨어뜨립니다. 즉 토큰 COGS는 AARRR 전체를 관통하는 KPI입니다.
세 번째 dev.to 글(BrainDB)은 다른 방향의 시그널을 줍니다. 메모리를 “클라우드 벡터DB+구독”으로 밀어 넣기보다 로컬 퍼스트(SQLite+FTS5+하이브리드 검색)로 단순화하면, 비용·지연·컴플라이언스 리스크를 동시에 줄일 여지가 생깁니다. 특히 ‘밤 사이 팩트체킹/정리’ 같은 배치 작업은 저가 모델/로컬 처리로 분리할수록 토큰 COGS를 KPI로 관리하기 쉬워집니다.
시사점은 실행 프레임으로 정리됩니다. 1) 고객 단위 비용 귀속: user_id/tenant_id 기준으로 모델, prompt_tokens, completion_tokens, 호출 목적(채팅/하트비트/툴체인)을 이벤트로 남깁니다(dev.to의 비동기 로깅 접근). 2) 토큰 폭주 패턴 탐지: ‘무의미 호출(하트비트)’, ‘풀 컨텍스트 반복’, ‘다단 툴체인’ 세 가지를 비용 상위 원인으로 분류하고, 코호트별(신규/활성/파워유저)로 분해합니다(OpenClaw 사례가 경고). 3) 가격·플랜 실험 가능 상태 만들기: 고객별 COGS가 보이면 ‘flat → usage tier/크레딧/가드레일 포함 플랜’ 같은 실험이 가능해지고, 이때야 비로소 LTV/CAC를 맞출 수 있습니다.
전망: 에이전트 시장은 “기능 경쟁” 다음 라운드로 넘어가고 있습니다. 승자는 더 똑똑한 데모가 아니라 토큰 COGS를 매출과 같은 단위로 보고(고객·행동 단위), 비용 트래킹을 시스템 위험 없이 운영하며(프록시 회피), 폭주를 제품 설계로 예방하는 팀입니다. 토큰 COGS를 KPI로 채택하는 순간, 그로스는 ‘성능 개선’이 아니라 ‘지속 가능한 실험 속도’로 전환됩니다.