에이전트 트레이스로 35B 모델을 파인튜닝했더니 더 큰 judge보다 비용은 훨씬 적으면서 성능은 비슷하거나 앞섰다

LangChain과 Fireworks는 실제 에이전트 실행 기록으로 35B 모델을 파인튜닝하면 에이전트 출력 평가에서 큰 프런티어 모델급 judge와 비슷하거나 일부 앞설 수 있음을 확인했다. 중요한 건 성능만이 아니다. 추론 비용이 크게 줄었다는 점이 실전에서 의미가 크다.

좁은 평가 작업에서 큰 모델과 맞먹으면 경쟁 구도가 달라진다

두 팀은 Qwen-3.5-35B를 기반으로 두 가지 에이전트 구성에서 나온 멀티턴 트레이스를 학습에 썼다. 라벨링은 모델 보조와 사람 리뷰를 섞어 진행했고, 오류를 놓치지 않게 검수 단계도 넣었다. 결과적으로 파인튜닝된 35B 모델은 더 큰 judge 모델과 비교해도 밀리지 않으면서 추론 비용은 확 줄었다.

이런 전문화는 평가 작업에서 특히 효과적이다. 에이전트 평가의 핵심은 범용 추론이 아니라 에이전트가 사용자·도구·응답 흐름에서 어떤 식으로 실패하는지를 알아채는 데 있다. 그래서 범용 프런티어 모델이 가진 과도한 일반성은 이 좁은 용도에서는 비효율적이다.

자체 트레이스 데이터를 가진 팀이 실질적 우위를 갖기 시작했다

| 시장의 통념 | 데이터가 보여준 것 | 관점의 변화 | 실무적 시사점 | |---|---|---|---| | 오픈 모델도 좁은 작업에서는 격차를 줄일 수 있다 | 35B 모델이 chat-langchain과 Fleet의 트레이스만으로 프런티어 judge와 유사한 성능을 냈다 | 모든 벤치마크에 프런티어급 스케일이 꼭 필요한지 다시 보게 된다 | 특화 모델은 observability 속도를 높이고 API 의존도가 높은 공급자에게 압박을 준다 | | 평가 작업에서는 모델 크기보다 데이터 품질이 더 중요하다 | 필터링과 하이브리드 라벨링으로 18~24%의 positive error rate에서 쓸 만한 ground truth를 확보했다 | 기업들은 모델 쇼핑보다 자체 트레이스 수집에 더 집중하게 된다 | 라이브 유저 루프를 가진 플랫폼은 연구 랩이 쉽게 따라오기 어려운 우위를 만든다 | | 비용 하락은 모니터링 범위를 바꾼다 | 프로덕션 트레이스 기준 추론 비용이 경우에 따라 최대 100배 저렴했다 | 작은 팀도 전체 트레이스 모니터링을 감당할 수 있다 | Fireworks 같은 추론 레이어가 원천 모델 빌더로부터 일부 가치를 가져온다 | | 범용적 성능 주장은 도메인별 검증이 필요하다 | 서로 다른 두 에이전트 제품의 홀드아웃 세트로 전이 가능성을 점검했다 | 단일 환경 judge 결과에 대한 검증 압력이 커진다 | 좋은 오류 탐지기는 해자가 아니라 기본 인프라에 가깝다 |

• 프로덕션 트레이스가 많아질수록 judge는 더 정교해지고, 그 judge는 다시 더 나은 개선 신호를 찾아낸다.
• 프런티어 API judge에 계속 의존하는 팀은 누적 비용 부담을 빠르게 떠안게 된다.
• 학습에서 tool call을 빼도 사용자-어시스턴트 상호작용 패턴만으로 핵심 오류 신호를 상당 부분 잡을 수 있었다.

단순 벤치마크 점수만 보면 큰 흐름을 놓치기 쉽다. 여기서 중요한 변화는 특정 도메인에 맞춘 distillation과 파인튜닝이 평가 인프라의 경제성을 다시 쓰고 있다는 점이다.

실무적 결론은 명확하다. 이미 프로덕션 트레이스를 보유하고 있고 파인튜닝 역량이 있는 팀은 에이전트 신뢰성을 더 빠르게 개선할 수 있다. 반대로 차별화되지 않은 스케일만 추구하는 전략은 비용 구조가 이렇게 벌어지면 설득력이 떨어진다.

Verdict: 지금은 이 내러티브에 늦지 않았다. 가장 유리한 쪽은 자체 프로덕션 트레이스와 파인튜닝 파이프라인을 가진 에이전트 빌더와 AI 인프라 팀이며, 단순히 프런티어 API judge를 빌려 쓰는 팀은 비용과 데이터 해자 양쪽에서 불리하다.