기업의 AI 비용은 모델이 아니라 현장이 결정한다

하나의 순위로는 모델을 고를 수 없다

1위는 왜 계속 바뀌나

2026년 8월 현재, 코딩 모델의 순위를 하나로 정하기는 어렵다. 평가하는 작업에 따라 선두 모델이 달라지기 때문이다.

프론트엔드 코드 생성 능력을 겨루는 Code Arena에서는 오픈웨이트(가중치를 공개해 누구나 내려받아 쓸 수 있는) 모델 Kimi K3가 Claude Fable 5를 제치고 1위를 차지했다. WebDev Arena에서는 Claude Opus 5가 1,704 Elo로 앞서지만, Kimi K3와의 격차는 29점에 불과하다. 반면 저장소 전체를 수정하는 능력을 평가하는 SWE-bench Verified에서는 GPT-5.6 Sol이 96.2%로 1위이고, Fable 5가 95.0%로 뒤를 잇는다.

벤치마크	1위	기록
Code Arena (프론트엔드 코드 생성)	Kimi K3	Claude Fable 5 제침
WebDev Arena	Claude Opus 5	1,704 Elo (Kimi K3와 29점 차)
SWE-bench Verified (저장소 전체 수정)	GPT-5.6 Sol	96.2% (Fable 5는 95.0%)

이처럼 순위가 엇갈리는 현상은 학습이 덜 끝나서 생긴 단순한 잡음이 아니다. 핵심 원인은 사후학습(post-training)에 있다. 사후학습은 사전학습을 마친 모델의 특정 능력과 행동을 다듬는 과정이다. 연구소마다 사용하는 데이터와 강화학습 방식이 다르기 때문에, 같은 기반 모델에서도 서로 다른 강점이 발달한다.

BAR 연구는 이러한 분화가 실제로 성능을 높일 수 있음을 보여준다. 연구진은 수학, 코딩, 도구 사용 전문가를 각각 학습한 뒤, 이를 전문가 혼합(MoE, 여러 전문가 모듈 중 일부만 골라 쓰는 구조) 모델로 결합했다. 강화학습의 영향은 개별 전문가층에 그치지 않고, 모든 전문가가 함께 사용하는 어텐션층까지 변화시킬 만큼 컸다. 베이스 모델 단계에서 전문가 간 성능 차이는 15%였으며, 이들을 조합한 모델은 가장 뛰어난 단일 전문가보다도 7.5% 높은 성능을 기록했다. 능력의 분화가 결함이 아니라 자산이 된 사례다.

하지만 공개 벤치마크만으로는 이런 차이를 충분히 포착하기 어렵다. AI 연구기관 Epoch AI의 분석에 따르면 같은 분야에 속한 벤치마크끼리의 순위상관 중앙값은 0.79였다. 서로 다른 분야끼리도 0.68이었고, 종합 역량 지수와의 상관은 0.90에 달했다. 공개 평가만 놓고 보면 “수학을 잘하는 모델은 코딩도 잘한다”는 결론에 도달하기 쉽다.

실제 업무 환경에 모델을 배치하면 양상이 달라진다. EnterpriseOps-Gym은 164개 데이터베이스 테이블과 512개 도구, 접근 통제 체계를 갖춘 환경에서 1,150개 업무를 평가했다. 14개 프런티어 모델 가운데 최고 성공률은 37.4%에 그쳤다.

반면 외부 상태의 변화가 적은 WorkBench Revisited에서는 Fable 5가 98%를 기록했다. 2024년 3월 GPT-4가 기록한 43%보다 크게 향상된 수치다.

결국 모델의 성능은 모델 자체의 능력만으로 결정되지 않는다. 업무 중 상태가 얼마나 자주 바뀌는지, 어떤 도구를 사용해야 하는지, 접근 권한이 어떻게 설정되어 있는지에 따라 결과가 크게 출렁인다. 공개 벤치마크에서는 비슷해 보이던 모델들도 실제 환경에서는 강점과 약점이 뚜렷하게 갈린다. 따라서 코딩 모델을 평가할 때는 하나의 종합 순위보다, 어떤 환경에서 어떤 업무를 얼마나 안정적으로 수행하는지를 살펴봐야 한다.

프롬프트만으로 난이도를 알 수 없다

프롬프트만 보고 작업의 난이도를 정확히 판단하기는 어렵다. 똑같은 오류 보고라도 실제로는 오타 하나만 고치면 될 수 있고, 여러 모듈을 수정해야 할 수도 있다. 저장소를 직접 살펴보기 전에는 이 둘을 구분할 정보가 부족하기 때문이다.

SWE-Router는 이를 프롬프트 단계에서 피하기 어려운 ‘베이즈 오류율의 하한’으로 설명한다. 아무리 좋은 라우터라도 입력에 필요한 정보가 없다면 판단 정확도를 일정 수준 이상 높일 수 없다는 뜻이다. 반면 부분적인 실행 기록을 판단 근거로 추가하면 기대효용이 떨어지지 않는다. 탐색 과정에서 새로운 정보를 얻을수록 더 나은 결정을 내릴 가능성도 커진다.

따라서 처음부터 비싼 모델을 투입할 필요는 없다. 먼저 저렴한 모델을 몇 차례 실행해 관련 파일의 위치와 오류의 범위를 파악하게 한다. 그런 다음 별도의 평가 모델이 지금 모델로 계속 진행할지, 더 강한 모델로 넘길지를 결정한다.

이 방식은 SWE-bench Verified의 500개 과제에서 임베딩 기반 라우터보다 Route-AUC가 12~15.3% 높았다. 특히 DeepSeek V3.2로 시작해 필요할 때 Gemini 3 Pro로 넘긴 조합은 0.780을 기록해 임베딩 라우터의 0.627을 크게 앞섰다. 일부 비용 구간에서는 모든 요청에 처음부터 강한 모델을 사용한 방식보다도 좋은 결과를 냈다.

라우팅의 판단 단위 역시 개별 모델 호출이 아니라 과제 전체가 되어야 한다. 중간 호출마다 모델을 바꾸면 처음의 잘못된 선택이 뒤 단계까지 영향을 미치고, 이를 복구하기 위한 호출도 늘어난다. TRACE-Router는 한 과제가 끝날 때까지 선택한 모델을 유지한 뒤, 최종 결과를 바탕으로 라우팅 정책을 갱신한다. 이를 통해 에이전트 평가 비용을 20~40% 줄였다.

기업 환경에서는 문제가 더 복잡해진다. 기업이 사용하는 SaaS는 평균 118개다. 직원이 5,000명 이상인 기업에서는 371개, 1만 명 이상인 기업에서는 473개로 늘어난다. 이 가운데 65%는 IT 부서가 관리하지 않는 ‘섀도 IT(승인 없이 쓰이는 비공식 시스템)‘다.

이 때문에 겉보기에 같은 업무라도 실제 난이도는 회사마다 크게 다르다. 예를 들어 경쟁사 분석이 어떤 회사에서는 문서 하나를 확인하는 것으로 끝날 수 있다. 다른 회사에서는 이메일, 메신저, 영업 시스템은 물론 관리 밖의 도구까지 찾아봐야 할 수 있다. 프롬프트만으로는 이런 차이를 알기 어렵다.

EnterpriseOps-Gym에서는 사람이 작성한 계획을 에이전트에 제공했을 때 성공률이 14~35% 상승했다. 성과를 높인 핵심은 추가적인 추론 능력이 아니었다. 어느 시스템을 어떤 순서로 확인해야 하는지에 관한 조직 지식이었다.

기업의 작업 기록을 학습하는 과정에서도 중요한 것은 개별 도구의 사용법만이 아니다. 어떤 도구를 병렬로 호출하고 어떤 도구를 순서대로 호출할지, 집계 수치와 개별 레코드를 확인할 때 각각 어느 시스템을 신뢰할지를 함께 배워야 한다. 한 기업용 제품이 40개가 넘는 모델을 업무별 성능, 비용, 역량에 맞춰 배치하는 것도 같은 전제에 따른다.

결국 효과적인 라우팅은 프롬프트만으로 난이도를 맞히는 문제가 아니다. 저렴하게 탐색해 정보를 얻고, 과제 전체의 진행 상황을 기준으로 모델을 배정하며, 조직마다 다른 시스템 구조와 업무 절차까지 반영하는 문제다.

승인한 순간과 실행할 순간은 다르다

기업 환경에서는 여러 사람과 에이전트가 예산, 재고 같은 공유 상태를 동시에 변경한다. 따라서 요청 당시에는 승인할 수 있었던 구매도 실행 직전에는 예산 소진이나 재고 변동으로 허용할 수 없게 될 수 있다. 이를 ‘오래된 권한 승인’이라고 한다.

이 문제를 막으려면 권한을 요청 시점에만 확인해서는 안 된다. 실제 효과가 확정되기 직전의 최신 상태를 기준으로 다시 검사해야 한다. 이것이 ‘정책 상태 직렬화 조건’이다. 공유 예산과 재고를 활용한 조달 실험에서는 이 조건을 적용해 기존 가드레일이 걸러내지 못한 잘못된 승인을 차단했다.

에이전트의 기억에도 같은 위험이 있다. 저장 당시에는 유효했던 정보가 지식 간 충돌, 현실의 변화, 맥락의 소실로 더는 쓸 수 없게 될 수 있기 때문이다. STALE 평가는 에이전트가 이러한 정보의 무효화를 감지할 수 있는지 측정한다. 어제의 실행 기록에서 학습한 라우팅 규칙이 오늘 아무런 경고 없이 틀릴 수 있는 것도 이 때문이다.

관측 데이터를 늘리는 것만으로는 올바른 판정 능력이 생기지 않는다. 하루 10만 건이 넘는 트레이스(에이전트가 수행한 호출과 그 결과를 시간순으로 남긴 실행 기록)를 사람이 일일이 검토하는 것은 현실적으로 어렵다. Salesforce는 모든 에이전트 행동을 OpenTelemetry 트레이스 트리로 저장하고 검색할 수 있게 했다. 하지만 행동을 기록할 수 있다는 것과 그 행동의 성공 여부를 판정할 수 있다는 것은 별개의 문제다.

긴 트레이스는 좋은 평가자가 아니다

TRAIL 연구진은 148개 트레이스에서 20여 유형의 오류 구간 841개를 사람이 직접 표시한 뒤, 긴 문맥을 다루는 모델에 탐지를 맡겼다. 그러나 최고 성능을 기록한 Gemini 2.5 Pro조차 탐지율이 11%에 그쳤다. 긴 트레이스 전체를 한 번에 입력하는 것만으로는 신뢰할 만한 평가자를 만들기 어렵다는 뜻이다.

트레이스를 학습에 활용하려면 실행 조건이 다른 결과를 체계적으로 비교해야 한다. 먼저 추론 예산이 큰 교사 실행을 기준으로 삼고, 여기에 추론 예산, 도구, 응답 시간이 다른 학생 실행을 연결한다. 이어 여러 응답에서 사실에 관한 주장을 추출해 서로 일치하는지 확인한다. 주장이 충돌하면 도구를 사용해 추가로 검증한다. 그래도 불일치가 해소되지 않으면 학습 표본을 만들지 않는다. ‘판정 불가’를 실패가 아닌 정상적인 결과로 인정하는 방식이다.

공개 벤치마크 순위도 이러한 평가를 대신할 수 없다. SWE-bench, TAU-bench, MCP-Bench, AssetOpsBench를 분석한 연구에 따르면, 정적인 벤치마크 순위만으로는 실제 배포 환경의 성과를 충분히 예측하기 어렵다. 따라서 모델의 승급 여부는 공개 순위가 아니라, 해당 기업의 최신 실행 기록을 바탕으로 판단해야 한다.

모델 단가보다 실패 총비용을 계산하라

SWE-bench Verified에서 과제당 비용은 최저 0.08달러, 최고 32달러였다. 무려 400배 차이다. 모델 가격뿐 아니라 실행 방식까지 비용에 영향을 미친 결과다. 전체 242회 실행에는 약 4만 6,000달러가 들었다.

같은 업체의 모델끼리도 가격 차이는 크다. Haiku 4.5는 100만 토큰당 입력 1달러, 출력 5달러다. 반면 Fable 5는 각각 10달러와 50달러다. 따라서 저렴한 모델이 과제를 해결하지 못할 때마다 비싼 모델로 넘기는 ‘승급’ 판단이 자주 빗나가면, 절감액보다 추가 비용이 더 커질 수 있다.

저렴한 모델을 효과적으로 활용하려면 초반의 탐색적 시도를 몇 차례 허용해야 한다. 프롬프트만 보고 난이도를 예측하는 데는 한계가 있지만, 실제 실행 기록을 관찰하면 과제의 난이도를 더 정확히 판단할 수 있기 때문이다.

단, 실패를 되돌릴 수 있어야 한다. WorkBench Revisited에서 의도하지 않은 유해 행동의 비율은 GPT-4의 26%에서 Fable 5의 1.9%로 크게 낮아졌다. 그럼에도 복구할 수 없는 실수는 여전히 발생했다. EnterpriseOps-Gym에서도 수행할 수 없는 과제를 정확히 거절한 비율은 최고 53.9%에 그쳤다.

따라서 업무의 성격에 따라 모델 선택 기준도 달라져야 한다. 읽기 전용 업무는 틀려도 다시 실행하면 된다. 반면 결재, 메시지 발송, 레코드 수정처럼 실제 상태를 바꾸는 업무는 복구가 어렵다. 이런 업무에서 비싼 모델에 지불하는 추가 비용은 단순한 성능 비용이 아니라, 실패 가능성을 낮추기 위한 위험 관리 비용에 가깝다.

저렴한 모델을 안정적으로 활용하려면 조직 차원의 안전장치가 필요하다.

승급 여부는 개별 실행이 아니라 과제 단위로 관리해야 한다.
자체 실행 기록에서는 고성능 모델과 저비용 모델의 결과를 비교하고, 판정이 일치하지 않는 표본은 학습 데이터에서 제외해야 한다.
에이전트의 쓰기 권한도 변경 사항을 되돌릴 수 있는 범위로 제한해야 한다.

이런 조건이 갖춰져야 낮은 모델 단가가 실제 비용 절감으로 이어진다. 그렇지 않으면 아낀 비용은 지연과 재작업, 나아가 복구할 수 없는 변경으로 인한 손실로 되돌아온다.

출처

#에이전트 #기업 AI #언어모델