새 모델이 나오면서 토큰 단가는 내려가고 벤치마크 점수는 올라갑니다. 그래서 바꿔 씁니다. 그런데 일주일 뒤, 왜 에이전트가 같은 작업에 토큰을 12배나 더 쓰면서 결과물은 더 나빠졌는지 묻는 사람이 생깁니다.

마이크로소프트의 개발자 애드보케이트 Waldek Mastykarz가 자사 블로그에 실험 결과를 공개했습니다. VS Code의 GitHub Copilot Chat에서 Claude Sonnet 4.6과 Sonnet 5를 나란히 놓고, 애저 아키텍처 설계 12개 시나리오와 SharePoint Framework(SPFx) 프로젝트 업그레이드 3개 시나리오, 총 150회 실행을 비교한 것. 토큰당 가격이 모든 항목에서 33% 저렴한 Sonnet 5가 실제로도 더 나은 선택인지 확인하려는 실험이었습니다.

출처: Not all model upgrades are upgrades – Microsoft for Developers

싼 토큰이 비싼 청구서로 돌아온 이유

요금표만 보면 Sonnet 5가 모든 항목에서 이깁니다. 입력 토큰 100만 개당 3달러였던 게 2달러로, 출력은 15달러에서 10달러로 내려갔죠. 문제는 청구서를 결정하는 게 단가가 아니라 실제 소비량이라는 것. 아키텍처 작업에서 Sonnet 5는 중간값 기준으로 토큰을 12배 더 썼습니다. 한 시나리오에서는 평소보다 47배를 쓴 실행도 나왔죠. 코드 업그레이드 작업에서도 격차는 10배에 달했습니다. 33%의 할인폭은 이 정도의 소비 증가를 버티지 못합니다. 실제로 코드 업그레이드에서 Sonnet 5는 실행당 2.01달러, Sonnet 4.6은 0.55달러로 오히려 3.7배 비쌌습니다. 반대로 아키텍처 작업에서는 토큰 증가폭이 상대적으로 완만해서 Sonnet 5가 12% 더 저렴하게 나왔죠. 어느 쪽으로 갈지는 직접 측정해보기 전에는 알 수 없다는 게 이 실험의 첫 번째 결론입니다.

품질도 함께 나아지지는 않았다

가격은 그렇다 쳐도 결과물의 질은 더 나아졌을까요. 아키텍처 작업에서는 그렇지 않았습니다. 두 모델 모두 “애초에 맞는 작업을 시도했는가”를 보는 Select 게이트는 75%로 동일했지만, 결과물이 기존 관례와 패턴을 따르는지 보는 Idiomatic 점수에서 Sonnet 4.6이 90%, Sonnet 5가 78%를 기록했습니다. 둘 다 쓸 만한 결과물을 낸 9개 시나리오 중 8개에서 이전 모델이 같거나 더 나은 품질을 보인 것. IoT 분석 아키텍처를 설계하는 한 시나리오에서는 둘 다 매번 작업을 끝내긴 했지만, Idiomatic 검사 통과율이 Sonnet 4.6은 5번 중 4번, Sonnet 5는 5번 중 1번에 그쳤습니다. 같은 프롬프트로 토큰은 더 쓰고 품질은 떨어진 셈이죠.

반대로 신모델이 확실히 앞서는 영역도 있다

코드 업그레이드 작업에서는 이야기가 뒤집힙니다. SPFx 프로젝트를 gulp에서 Heft로, 구형 ESLint 설정에서 flat config로 마이그레이션하는 시나리오에서 Sonnet 4.6은 Select 게이트를 60%만 통과했지만 Sonnet 5는 100% 통과했습니다. 가장 뚜렷한 사례는 SPFx를 v1.21.1에서 v1.22.0으로 올리는 작업. Sonnet 4.6은 5번 모두 실패하며 사용자가 요청한 1.22.0 대신 Microsoft Learn 문서에서 발견한 1.22.1을 계속 채택했지만, Sonnet 5는 매번 지시받은 버전을 정확히 따랐습니다. 맥락에서 발견한 정보보다 명시적 지시를 우선해야 하는 작업에서는 신모델이 더 신뢰할 만했다는 것. 한 실행에서는 6900만 토큰을 쓰며 웹 탐색까지 나서서 문서화되지 않은 마이그레이션 단계를 찾아내 30개 평가 기준 중 21개를 충족하기도 했습니다. 다만 이런 실행은 재현되지 않았습니다. 같은 시나리오에서 5번 중 4번은 그 정도 깊이에 도달하지 못했죠.

진짜 병목은 모델이 아니라 문서였다

두 모델 모두 같은 지점에서 막혔습니다. SPFx 시나리오 전체에서 설정 정확도는 두 모델 다 0%. gulp에서 Heft로, 혹은 구형 ESLint에서 flat config로 넘어가는 구조적 전환은 둘 다 완료하지 못했습니다. 마이그레이션 가이드는 보통 의존성 버전이나 API 변경 사항을 다루지만, 빌드 시스템이나 설정 형식 자체를 바꾸는 구조적 변화는 한곳에 정리돼 있지 않기 때문입니다. 연구팀이 SPFx 시나리오에서 확인한 것만 해도 빌드 도구 플래그, 패키지 매니페스트 재구성, 파일 삭제, 설정 형식 전환 등 일곱 가지 변경 사항이 문서 어디에도 없었습니다. 문서화되지 않은 내용은 어떤 모델도 스스로 발견하지 못하고, 더 비싼 모델로 바꾼다고 이 격차가 메워지지도 않습니다.

예측 불가능성 자체가 비용이다

Sonnet 5의 토큰 소비는 양만 많은 게 아니라 편차도 컸습니다. Sonnet 4.6은 단순한 아키텍처 작업에서 대부분 1만 4천에서 4만 5천 토큰 사이로 몰려 있어 예산을 짜기 쉬웠던 반면, Sonnet 5는 같은 IoT 분석 시나리오에서 한 실행이 660만 토큰을 쓰는 동안 다른 실행은 1만 6천 토큰에 그쳤습니다. 같은 시나리오, 같은 프롬프트인데도요. 실행 하나의 이상치가 Sonnet 4.6 여러 배치를 합친 비용을 넘어설 수 있다는 뜻입니다. 복잡한 작업에서는 두 모델 다 편차가 있었지만, Sonnet 4.6의 이상치는 가끔이었고 Sonnet 5의 이상치는 흔한 축에 속했습니다.

모델 업그레이드는 “이 작업, 이 콘텐츠에서 신모델이 더 낫다”는 가설일 뿐이라는 게 이 실험이 남기는 메시지입니다. Sonnet 5는 코드 업그레이드에서 완료율을 60%에서 100%로 끌어올린 동시에 아키텍처 품질은 90%에서 78%로 낮췄죠. 어느 쪽에 속하는 작업인지는 직접 재보기 전엔 알 수 없습니다. 무작정 모델부터 바꾸기 전에, 에이전트가 애초에 필요한 정보를 갖고 있는지부터 확인하는 편이 나을 수 있습니다.