AI 에이전트를 제품/채널에 붙이는 순간, 그로스의 상한선은 두 변수로 고정됩니다. 첫째 COGS(토큰·툴 호출·재시도)가 마진과 CAC 상한선을 결정하고, 둘째 ‘신뢰(정답률·완료율·보안)’가 전환과 리텐션을 깎는 폭을 결정합니다. 문제는 둘 다 “대시보드가 초록”이어도 조용히 망가진다는 점입니다.
dev.to의 비용 스파이럴 글은 전형적 사고를 보여줍니다. 밤새 루프를 돌며 대화 전체를 매번 재전송하고, 실패한 툴을 3회씩 재시도하고, JSON 포맷팅 같은 저난도 단계까지 비싼 모델(GPT-4급)을 태우면, 성과는 그대로인데 청구서만 성장합니다. 이는 ‘효율 나쁜 자동화’가 아니라, 유닛 이코노믹스를 무너뜨리는 운영 결함입니다.
해법은 “사후 절감”이 아니라 “사전 가드레일”입니다(비용 스파이럴 방지 패턴 기사). 실험 설계 관점에서 핵심은 ①태스크별 토큰 예산(하드 캡) ②티어드 모델 라우팅(저난도는 mini, 고난도만 reasoning) ③컨텍스트 프루닝/요약 압축(장기 세션의 입력 토큰 누수 차단) ④서킷 브레이커(스텝 수·비용·연속 에러로 루프 종료)입니다. 이 네 가지를 붙이면 “한 번의 이상행동이 하루 예산을 태우는” tail risk를 구조적으로 제거할 수 있습니다.
하지만 비용만 잡으면 끝이 아닙니다. 또 다른 dev.to 글은 ‘옵저버빌리티 위기’를 지적합니다. 에이전트는 500을 내지 않고도 치명적으로 실패합니다. 응답은 200이고 JSON도 유효하지만, 의미가 틀린 상태(semantic drift), 툴이 준 오래된/오염된 데이터를 확신하는 상태(tool reliability), 컨텍스트 포화로 초기 제약을 잊는 상태(context saturation), 일을 덜 끝내고도 끝낸 척하는 상태(silent task incompletion)가 전환률과 D7/D30을 갉아먹습니다. 전통적인 업타임·지연시간 모니터링은 이 구멍을 못 봅니다.
여기에 ‘보안 공백’이 합쳐지면 퍼널은 더 빨리 무너집니다. MCP 보안 확장 제안(MCPS, IETF Internet-Draft)은 MCP가 도구 호출 표준화는 했지만 정체성/서명/재전송 방지/폐기(revocation)가 비어 있음을 찌릅니다. 에이전트가 툴을 호출하는 순간, 누가 호출했는지(Agent identity)·중간 변조가 있었는지(tamper)·같은 요청을 재생(replay)했는지·툴 정의가 오염(poisoning)됐는지까지가 ‘신뢰 비용’이 됩니다. 이 신뢰 비용은 보안 사고로만 끝나지 않고, CS 폭증→환불/해지→브랜드 신뢰 하락으로 LTV를 직접 깎습니다.
시사점은 명확합니다. 에이전트의 그로스 KPI는 “정답률” 같은 추상 지표가 아니라, (1) 마진을 지키는 COGS 가드레일과 (2) 퍼널을 지키는 신뢰 가드레일을 동시에 포함해야 합니다. 실행 체크리스트로 바꾸면: 태스크 타입별 예상 토큰을 추정해 예산을 3배로 캡핑하고, 단계별 라우팅으로 60~70% 루틴 작업을 저가 모델로 내리고, 세션이 길어질수록 요약 압축을 강제하며, 서킷 브레이커로 재시도 폭풍을 끊습니다. 동시에 툴 호출은 span-level trace로 남기고(무엇을 보냈고 무엇을 받았는지), ‘완료율’(정의된 done 상태 도달)을 95% 이상으로 관리하며, MCP 계열이라면 메시지 서명·nonce·revocation 같은 프로토콜 보안을 도입해 “조용한 조작/오염”을 원천 차단합니다.
전망: 2026년의 승자는 “더 똑똑한 에이전트”가 아니라 “손익과 신뢰를 자동 제어하는 에이전트”를 가진 팀입니다. 비용 측면에선 라우팅·압축·브레이커가 사실상 표준 운영체계가 되고, 신뢰 측면에선 관측(트레이싱+평가)과 보안(서명+정체성)이 결합된 스택이 퍼널의 기본 옵션이 됩니다. 지금 할 일은 간단합니다. 에이전트를 기능으로 붙이지 말고, COGS 캡과 신뢰 캡을 제품 요구사항(PRD) 첫 페이지에 박아 넣으세요. 그게 CAC 상한선을 올리지 않고도 스케일하는 유일한 방법입니다.