AI 에이전트가 프로덕션에서 망가지는 순간은 대개 두 가지입니다. 첫째, “생각보다 비싸다”(모든 요청이 비싼 모델로 감). 둘째, “생각보다 자주 터진다”(JSON 깨짐, 필드 누락, 타입 오류). 비용은 운영 마진을 갉아먹고, 실패는 온보딩/결제/CS 퍼널에서 유저를 떨어뜨립니다. 결국 CAC가 올라가고 리텐션은 내려가요. 그래서 오늘의 주제는 딱 하나: 에이전트의 비용·실패율을 함께 줄이는 구조입니다.
dev.to의 두 흐름이 이 문제를 정면으로 찌릅니다. 하나는 NadirClaw 사례(자동 프롬프트 분류로 모델 라우팅)이고, 다른 하나는 Pydantic 기반 Structured Outputs(스키마로 출력 강제)입니다. 둘 다 “프롬프트 엔지니어링 더 열심히”가 아니라, 시스템 설계로 안정성과 비용을 ‘기계적으로’ 개선하는 접근이라 바로 그로스 실험 재료가 됩니다.
먼저 비용. 많은 팀이 라우팅을 YAML/정규식 규칙으로 시작합니다. “번역이면 저가 모델, 코드면 고가 모델” 같은 방식이죠. 그런데 NadirClaw 글이 말하듯, 프롬프트는 예측 불가입니다. 규칙은 금방 비대해지고 충돌하며, 무엇보다 ‘대충 맞을 것 같은’ 패턴이 실제로는 비싼 모델 호출을 늘리거나(과잉 라우팅), 싼 모델에 보내 실패를 만든다(과소 라우팅)는 게 함정입니다(출처: dev.to, Why Automatic Prompt Classification Beats Manual Routing Rules).
여기서 “와 이거다!” 포인트는 자동 분류(경량 DistilBERT 등)입니다. 실사용 프롬프트를 학습해 “이 요청을 어떤 모델이 성공할 확률이 높은지”를 점수화하고, 임계치 이상이면 가장 싼 모델로 라우팅합니다. 글의 실험에서는 1,000개 코딩 프롬프트에서 수동 규칙 대비 저가 모델 라우팅 비율 58%→71%, 실패율 12%→3%, 비용 절감 47%→64%로 개선됐습니다. 이건 단순 비용 절감이 아니라, 실패율까지 같이 내려가니 퍼널 지표가 움직일 각이 나옵니다.
다음은 안정성. 에이전트가 “의미는 맞는데 형식이 깨진 출력”을 내는 순간, 백엔드는 JSON.parse에서 터지고 재시도는 토큰을 태우며, 최악은 조용한 데이터 오염입니다. dev.to의 Pydantic 구조화 출력 글은 해결책을 명확히 제시합니다. LLM 응답을 문자열이 아니라 ‘Pydantic 모델(스키마)’로 받으라는 것. OpenAI/Anthropic SDK의 parse 계열, 또는 Instructor/LangChain의 structured output으로 스키마에 맞는 JSON을 강제해 파싱/정규식/기도를 없앤다고요(출처: dev.to, Stop Parsing JSON by Hand: Structured LLM Outputs With Pydantic).
또 다른 글은 미들웨어로 “깨진 JSON을 수리+스키마 검증”하는 신뢰성 레이어(llm-json-guard)를 소개합니다. 여기서 중요한 인사이트는 기술 자체보다 제품 메트릭입니다. 파싱 실패/스키마 불일치 = 유저에게는 ‘작동 안 함’이고, 그 순간이 보통 Activation 구간(온보딩 입력, 첫 자동화 실행, 첫 리포트 생성)에 집중됩니다. 즉, 구조화 출력/검증 레이어는 단순한 개발 편의가 아니라 온보딩 마찰 제거 장치예요(출처: dev.to, Stop using regex to fix LLM JSON...).
그로스 관점에서 이 조합(자동 라우팅 + 구조화 출력)이 좋은 이유는 “바로 A/B가 된다”는 점입니다. 예를 들어: - CAC: 라우팅으로 inference 비용이 내려가면, 동일 예산으로 더 많은 무료 체험/데모 요청을 처리 → 유효 리드당 비용이 하락. 특히 AI 기능이 acquisition hook인 제품(‘AI로 3분 만에 문서/광고/리포트’)은 서버비가 곧 CAC에 붙습니다. - 전환율(Activation/Conversion): 구조화 출력으로 첫 실행 성공률이 오르면, “첫 결과 화면까지 도달” 비율이 뛸 확률이 큽니다. 유저가 여기서 이탈할 것 같은데… 대개 깨진 출력/재시도 지연/에러 토스트에서 떨어지거든요. - 리텐션(D7/D30): 실패율이 낮으면 ‘AI가 믿을 만하다’는 학습이 생깁니다. 반대로 한 번 크게 깨지면 유저는 다음부터 중요한 작업을 안 맡겨요. 신뢰는 리텐션의 숨은 변수입니다.
실험 설계는 이렇게 가면 빠릅니다. (1) 라우팅 전/후 요청당 평균 비용, 고가 모델 호출 비율, fallback 비율을 트래킹. (2) 구조화 출력 전/후 파싱 실패율, 스키마 검증 실패율, 재시도 횟수, 첫 응답까지 시간(TTFR)을 트래킹. (3) 제품 지표로는 온보딩 완료율, 핵심 액션 성공률, 결제 전환율을 붙이세요. 이거 바이럴 될 것 같은데? “AI가 ‘항상’ 결과를 준다”는 메시지는 공유 포인트가 됩니다. 다만 바이럴의 전제는 안정성입니다.
전망은 명확합니다. 라우팅은 규칙 기반에서 데이터 기반으로 이동하고, 출력은 텍스트에서 스키마 계약으로 이동합니다. 앞으로는 여기에 두 가지가 더 붙을 가능성이 큽니다. 하나는 온라인 러닝(프로덕션 실패를 학습해 라우팅 자동 개선), 다른 하나는 멀티 모델 fallback(싼 모델 실패 시 자동 승급)입니다. 이 두 가지가 붙는 순간, 비용은 더 내려가고 실패율은 더 ‘0에 수렴’합니다. 빨리 테스트해봐야 돼요. 에이전트의 “비용 곡선”과 “신뢰 곡선”을 동시에 꺾는 팀이, 결국 CAC를 가장 싸게 만들 겁니다.