에이전트 모델 갈아타니 절감은 68%

미국 개발자 도구 회사 언블록드(Unblocked)가 자사 AI 에이전트 트래픽의 대부분을 클로드 오퍼스(Claude Opus)에서 오픈 웨이트 모델 GLM 5.2로 옮긴 기록을 공개했다. 데니스 필라리노스(Dennis Pilarinos)가 8월 13일 회사 기술 블로그에 올린 글이다. 요점은 하나로 압축된다. 요금표가 약속한 절감률은 95%였지만, 실제 청구서에 찍힌 절감률은 68%였다.

무슨 일인가 / 배경

언블록드는 코드·대화·이슈·문서에 흩어진 조직 지식을 모아 에이전트에게 물려주는 제품을 만든다. 질문 응답, 코드 리뷰, 사내 지식 검색이 전부 에이전트 루프로 돌아가는 구조다. 지난 2년간 그 루프의 바깥쪽은 거의 전부 오퍼스가 맡고 있었다.

문제는 지출 감사에서 드러났다. AI 비용의 80% 이상이 메인 에이전트 루프의 프런티어 모델 호출 한 군데서 나왔다. 회사는 손댈 수 있는 손잡이를 다섯 개로 정리했다. 모델, 턴 수, 도구, 캐싱, 프롬프트. 이 가운데 캐싱은 턴 간 캐시 적중률을 95% 이상으로 이미 끌어올려 더 짜낼 게 없었고, 프롬프트 최적화도 세대가 바뀔수록 효과가 줄고 있었다. 기능을 지우는 선택지는 애초에 없었다. 남은 손잡이는 모델 하나였다.

핵심 짚어보기

먼저 서류상 숫자는 화려했다. 엔지니어 한 명이 서빙 사업자 파이어웍스(Fireworks) 대시보드에서 실사용량을 뽑아보니, 23억 5천만 토큰을 처리하고도 같은 물량을 오퍼스로 돌렸을 때의 약 5% 비용만 나왔다. 양쪽 모두 캐싱을 반영한 값이다.

그런데 같은 커밋, 같은 PR, 같은 프롬프트로 코드 리뷰를 한 번은 오퍼스로 한 번은 GLM으로 돌려보니 실제 절감은 68%에 그쳤다. 저자가 제시한 산식은 단순하다. 실효비용은 '토큰 단가 × 과제당 필요 토큰'인데, 요금표에는 둘 중 앞의 한 항만 적혀 있다. 단가로만 보면 20배 개선이지만 청구서에서는 3.1배였다.

격차의 원인은 모델의 행동 습관이었다. GLM은 도구를 더 많이 부르고, 탐색을 더 공격적으로 하고, 실수가 잦아 왕복 턴을 잡아먹고, 도구 결과를 크게 삼킨 뒤 그것을 두고 더 길게 추론했다. 실측치도 붙었다. 검색 플로우의 호출당 평균 토큰이 이전 약 1만 8,500에서 약 2만 4,700으로 3분의 1가량 늘었는데, 그 시점에 GLM이 담당한 호출은 전체의 45% 정도였다.

품질 검증 방식도 눈여겨볼 만하다. 회사는 공개 벤치마크도 내부 감각도 믿지 않고, 제품 안에 이중 파이프라인을 심었다. 같은 PR에 두 모델의 리뷰 코멘트를 나란히 게시하고, 사용자는 어느 쪽이 어느 모델인지 알 수 없게 했다. 코멘트에 달리는 반응을 파이프라인별로 집계하니 반응 하나하나가 블라인드 투표가 됐다. 수천 건의 실제 리뷰를 모은 결과 오퍼스는 리뷰 3,708건에 코멘트 1,146개(리뷰당 0.31개), GLM 5.2는 3,384건에 1,568개(0.46개), GPT 계열 대안은 722건에 617개(0.85개)였다. 정밀도에서는 오퍼스가 1위, GLM이 바로 뒤를 따랐고, GPT 계열 대안은 코멘트를 세 배 가까이 쏟아내고도 크게 뒤처졌다. 저자는 약한 지적을 남발하는 리뷰어는 개발자에게 '무시해도 되는 알림'으로 학습된다는 점을 위험 신호로 짚었다.

1인기업 실전 적용 포인트

• 요금표 대신 청구서로 판단하라. 모델을 바꿀지 결정할 때는 같은 작업 10건을 두 모델에 끝까지 돌려보고 총 비용을 비교한다. 1,000토큰당 단가 비교는 의사결정 근거로 쓰지 않는다.
• 원가 단위를 '토큰당'에서 '과제당'으로 바꿔라. 기사 초안 1건, PR 리뷰 1건, 고객 문의 1건처럼 자기 사업의 최소 작업 단위를 정하고 그 단위 원가를 기록한다. 이 표 하나만 있어도 도구 교체 판단이 감이 아닌 숫자가 된다.
• 품질은 블라인드로 채점하라. 두 모델 산출물에서 라벨을 떼고 파일명을 A·B로 바꿔 하루 뒤에 본인이 채점한다. 방금 고생해서 붙인 모델에 점수를 후하게 주는 편향을 이 방법으로 막을 수 있다.
• 양 지표와 정밀도 지표를 같이 본다. 산출물 개수(코멘트 수, 초안 분량)만 늘어나는 모델은 절감이 아니라 검수 시간 청구서를 보내는 셈이다. '내가 실제로 채택한 비율'을 함께 기록한다.

전망 / 주의점

저자는 이전 과정이 매끄럽지 않았다고 적었다. 이른바 'OpenAI 호환' API가 실제로는 세부에서 어긋나는 일이 몇 주간 이어졌고, 장애 시 회로를 끊는 멀티 프로바이더 서빙 풀도 직접 구성해야 했다. 단가가 3분의 1이어도 그 인프라를 짜는 사람의 시간은 따로 청구된다.

1인기업 관점에서 교훈은 반대 방향으로도 읽힌다. 서빙 풀을 직접 굴릴 수 없는 규모라면 오픈 웨이트 모델 직접 운영보다 정액 구독형 도구를 쓰는 편이 총원가에서 유리할 수 있다. 다만 절감 여부를 '느낌'이 아니라 과제당 원가로 관리하는 습관 자체는 규모와 무관하게 그대로 통한다.

출처: getunblocked.com (https://getunblocked.com/blog/moving-agent-loops-from-anthropic-to-glm/)