기업들은 가장 강한 생성형 AI 모델을 얼마나 많이 쓰느냐에 성능 경쟁의 초점을 맞춰 왔다. 실제 운영에서는 모델의 능력보다 어느 단계에 배치하느냐가 비용과 결과를 함께 좌우했다.
최고급 모델은 검토에 쓴다
Harvey와 Fireworks가 법률 과제 100개를 시험했다.
| 구성 | 비용 | 통과 |
|---|---|---|
| Claude Opus 4.7 단독 | 954달러 | 14개 |
| GLM 5.1 단독 | 121달러 | 12개 |
| GLM 작업 + Opus 검토 | 368달러 | 18개 |
정확도는 더 높이면서 비용은 61% 낮춘 결과였다.
이때 Opus는 과제당 평균 0.83회만 호출됐다. 직접 작업하지 않고 결과와 변경 내역을 검토했다. 계획과 검토에 두 번 부르는 것보다 마지막에 한 번 부르는 편이 대체로 나았고, 신뢰도 80 이상인 지적만 반영 하자 재작업도 줄었다.
반면 자기 검토나 추론량 확대는 효과가 뚜렷하지 않았다. 이 사례에서 최고급 모델은 모든 일을 맡을 때보다 작업 모델에 없는 판단을 보탤 때 더 값어치를 했다.
평균 점수보다 완전 통과율
Legal Agent Benchmark는 여러 문서를 검토해 의견서 등을 만드는 법률 과제 1,250개로 구성된다. 모든 기준을 충족해야 통과한다.
위험 열 개 중 여덟 개만 찾은 보고서는 실무에서 완성본이 아니다.
GLM 5.1, Opus 4.7, GPT-5.5의 평균 점수는 0.89~0.91로 비슷했지만 완전 통과 과제는 각각 12개, 14개, 11개였다. 평균보다 완주율이 더 중요하지 않은가. 공개 벤치마크는 편법과 실행 편차에 취약하므로 일관성도 따로 확인해야 한다.
그래서 실무 평가는 과거 이력에서 난이도별로 50~100개 사례를 골라 실제 권한과 도구, 문서 상태를 재현한다. 성공, 실패 과정과 사람의 수정 내용도 회귀 시험(코드나 프로세스를 바꾼 뒤에도 기존 기능이 정상 작동하는지 반복 확인하는 검증)으로 남긴다. 무엇이 오류이고 어디까지가 완성인지 정해야 검토와 파인튜닝의 효과를 제대로 잴 수 있다.
오픈 모델의 진짜 비용은 운영 역량이다
Kimi K2.6에 성공한 법률 작업 과정만 학습시키자 완전 통과가 11개에서 15개로 늘었다. 비용은 Opus 단독의 약 11분의 1 이었다. 별도의 리워드 모델(결과물의 품질을 점수로 매겨 학습 신호로 쓰는 채점 모델) 없이도 잘 끝난 사례부터 활용한다. 다만 강화 파인튜닝은 성과가 늦게 나타나므로 성급하게 중단하지 않는다.
새 능력을 배우며 기존 능력을 잃는 문제도 있다. 실제로 새 과제를 학습한 뒤 초등 수학 정답률이 29%에서 2%로 떨어진 사례 가 있다. 도메인 평가만으로 충분할까. 수학, 코드, 일반 추론 회귀 시험도 함께 돌린다.
학습과 서빙 환경의 차이도 결과를 바꾼다. 커널과 수치 정밀도가 다르면 같은 모델도 다르게 작동한다. 연산을 비트 단위로 맞추자 더 적은 학습으로 높은 보상에 도달했다. 그만큼 오픈 모델은 학습뿐 아니라 배포와 유지 관리 역량까지 필요하다.
오픈 모델과 API의 손익분기점
반복 업무가 많고 데이터 반출이 어렵다면 오픈웨이트(모델의 가중치 파일을 공개해 내려받아 직접 구동할 수 있게 한 방식) 모델을 자체 운영할 만하다. 기본 작업은 오픈 모델에 맡기고 최고급 API는 검토에만 쓴다. 반대로 업무가 자주 바뀌거나 호출이 월 수백 회라면 프론티어 API가 더 경제적이다.
모델은 공개 순위보다 실제 환경에서 고른다. 상업적 배포가 가능한지, 보유 GPU로 목표 속도와 동시성을 맞추는지, 파인튜닝 뒤 자체 평가가 얼마나 좋아지는지가 기준이다. 검토 호출률은 과제당 0.8회 안팎에서 시작해 완전 통과율이 낮으면 올리고, 충분하면 내린다.
여기에 규제 대응 비용도 운영비에 포함된다. EU AI Act 위반 제재는 최대 1,500만 유로 또는 세계 매출의 3% 다. 로그와 기술 문서를 내부에서 관리하면 보존과 감사 범위를 통제하기 쉽다. 시장 통계 역시 기업 수, 토큰량, API 지출 중 무엇을 세느냐에 따라 달라진다. 자체 서빙 물량은 API 통계에 잡히지 않는다.
정리하면 운영은 실제 업무를 닮은 완전 통과 평가에서 시작한다. 오픈 모델의 기준 성능을 잰 뒤 읽기 전용 검토자와 신뢰도 기준을 붙인다. 호출률을 조절하고 성공 사례가 쌓이면 파인튜닝한다. 학습, 서빙 환경을 맞추고 일반 능력 회귀 시험도 함께 돌린다. 새 프론티어 모델은 전체 시스템을 바꾸기 전에 검토자 후보로 시험하면 된다.
결국 모델이 바뀌는 속도보다 업무의 합격 기준과 검토 기록이 늘어나는 속도가 경쟁력을 더 크게 좌우한다. 시간이 지날수록 경쟁력은 특정 모델의 이름보다 작업자와 검토자의 조합을 얼마나 쉽게 교체할 수 있는지에 달려 있다.