AI 코딩 에이전트 정확도: Opus 4.7 vs 4.8

당신은 기본 에이전트 모델을 Opus 4.7에서 4.8로 전환할지 고민하고 있습니다. 릴리스 노트(release notes)는 개선 사항을 약속하고, 리더보드(leaderboard) 점수는 아주 미세하게 움직였기에, 당신은 대수롭지 않게 여기며 한가한 금요일로 업그레이드를 예약하고 넘어가 버립니다.

우리는 두 버전 모두에 대해 동일한 기술 평가(skills evaluation)를 실시했습니다. 약 850개의 시나리오를 각각 두 번씩 해결하도록 했으며, 헤드라인 지표(headline metric)상으로는 두 모델이 대등한 결과를 보였습니다. 하지만 무승부 결과 아래를 들여다보면, 4.8 버전은 4번 더 적은 턴(turns)으로 동일한 정답에 도달했으며 측정 가능한 수준으로 비용도 더 적게 들었습니다. 따라서 점수판에서는 별일 아닌 것처럼 보이는 업그레이드가, 실제로 비용이 청구되는 지점인 에이전트 루프(agent loop)에서는 실질적인 효율성 이득으로 나타났습니다.

AI 에이전트 평가(AI agent evaluation)는 단순히 최종 답변에 점수를 매기는 것이 아니라, 에이전트가 실제 작업에서 어떻게 행동하는지를 측정하며, 쌍으로 실행된 결과 전반에 걸쳐 비용, 턴(turns), 신뢰성(reliability)을 추적합니다. 이렇게 번거로운 과정을 거치는 이유는, 두 모델이 동일한 점수를 기록하더라도 그 점수에 도달하기 위해 투입하는 작업량이 매우 다를 수 있기 때문입니다.

두 가지 버전, 하나의 평가 하네스 (eval harness)

두 모델 모두 동일한 설정을 사용하여 실행되었습니다. 모든 시나리오는 도움 없이 한 번, 그리고 관련 기술(skill)이 설치된 상태로 한 번, 총 두 번씩 해결됩니다. 이를 통해 기술이 기여하는 부분과 베이스 모델(base model)이 이미 알고 있는 부분을 분리할 수 있습니다. 우리는 세 가지 항목을 측정합니다: 지시 이행(instruction following, 에이전트가 기술이 지시하는 대로 수행했는가), 작업 완료(task completion, 목표에 도달했는가), 그리고 지시 이행에 가중치를 둔 종합적인 혼합 점수입니다. 또한 에이전트가 작업을 해결하는 대신 채점 기준표(grading rubric)를 훔쳐보는 것과 같은 무결성(integrity) 문제도 표시합니다.

Opus 4.7은 기존 모델입니다. 우리의 테스트 결과, 이 모델은 자신의 한계치에 도달하기 위해 기술에 크게 의존하며, 그곳에 도달하기 위해 많은 경로를 탐색하는 강력한 에이전트였습니다.

Opus 4.8은 포인트 릴리스(point release)입니다. 기술이 설치되었을 때 동일한 한계치(ceiling)를 보여주지만, 기술이 없는 상태에서의 시작점(floor)이 더 높으며, 눈에 띄게 적은 방황으로 정답에 도달합니다.

AI 코딩 에이전트 정확도가 전부가 아닌 지점

다음은 공유된 시나리오 세트에 대한 일대일 비교 결과입니다. 별도의 언급이 없는 한 모두 관련 기술이 설치된 상태로 진행되었습니다.

차원 (Dimension)	Opus 4.7	Opus 4.8
전체 점수 (Overall score)	91.9	92.1
...

전체적인 정확도 격차는 0.2점입니다. 만약 "전체 점수 (overall score)"라고 표시된 행을 읽다가 멈췄다면, 아무것도 변하지 않았다고 결론 내렸을 것입니다. 하지만 다른 세 개의 행이 그 양상을 복잡하게 만듭니다.

첫 번째는 베이스라인 (baseline)입니다. 아무런 기술 (skill)이 없는 상태에서 4.8은 74.1점을 기록하여 4.7의 71.4점보다 2.6점 높았으며, 기술이 없는 상태에서의 지시 이행 (instruction following) 능력은 50점대 후반에서 60점대 초반으로 상승했습니다. 두 버전 모두 기술에 의해 거의 비슷한 수준까지 끌어올려지기 때문에 천장 (ceiling)은 공유됩니다. 4.8이 실제로 개선된 지점은 바닥 (floor)이며, 이는 실질적인 결과를 가져옵니다. 즉, 4.8은 좋은 작업을 수행하기 위해 기술에 대한 의존도가 약간 더 낮습니다. 이는 이전에 기술에만 존재했던 지식의 일부가 모델 가중치 (model weights)에 학습되었음을 시사합니다.

두 번째는 턴 (turns)입니다. 4.8은 평균적인 작업을 15.0턴 만에 완료하여 4.7의 19.2턴 대비 21% 감소했습니다. 에이전트 루프 (agent loop)에서 1턴은 컨텍스트 (context), 추론 (reasoning), 도구 사용 (tool use)이 이루어지는 전체 왕복 과정을 의미합니다. 평균 작업에서 4턴을 줄이면 지연 시간 (latency)이 낮아지고, 에이전트가 잘못된 경로로 스스로를 몰아넣을 확률이 줄어들며, 앞으로 살펴보겠지만 비용 (cost)도 낮아집니다.

세 번째는 무결성 (integrity)입니다. 평가 (eval) 과정에서 에이전트가 채점 루브릭 (grading rubric)을 읽거나 작업 공간 (workspace) 외부로 접근하는 것과 같이 지름길을 택한 실행 건수를 플래그 (flags)로 표시했습니다. 이러한 플래그는 공유된 실행 건수의 10.2%에서 7.9%로 감소했습니다. 4.8은 정답에 도달하는 방식에 있어 약간 더 절제된 모습을 보입니다. 이는 4.8이 더 정직하다는 Anthropic의 주장과 일치합니다.

비용 읽기: 토큰이 아닌 턴

서로 모순되어 보이는 두 행을 다시 살펴보십시오. 4.8은 작업당 7,820 토큰 대비 9,763 토큰을 생성하여 더 많은 출력을 만들어내지만, 비용은 약 5% 더 저렴합니다.

이는 출력량 (output volume)이 에이전트 비용 (agentic cost)을 지배하지 않기 때문입니다. 지배적인 항은 매 턴 (turn)마다 다시 재생되는 컨텍스트 (context)입니다. 각 턴마다 누적된 대화와 도구 결과 (tool results)가 다시 전송되며, 에이전트 실행이 길어질수록 캐시된 입력 (cached input)이 모델이 작성하는 새로운 출력 (fresh output)을 압도하게 됩니다. 턴 수가 적다는 것은 재생 (replays)이 적다는 것을 의미하므로, 4.8은 수렴 (converge)하는 데 4번의 턴을 덜 소모하기 때문에 각 턴 내에서 더 상세하게(verbose) 작성하더라도 여전히 비용 면에서 앞설 수 있습니다.

모델 카드 (Model cards)는 작업 단위의 가격을 결정하는 토큰당 요율 (per-token rate)만을 보여주지만, 턴 수 (turn count)는 모델이 얼마나 많은 단위를 소비하기로 결정하는지를 결정합니다. 정확도를 유지하면서 턴 수를 21% 줄인 포인트 릴리스 (point release)는 사용량에 따라 확장되는 두 번째 항, 즉 턴 수의 최적화에 집중하고 있는 것입니다.

동일한 역학 관계가 각 버전이 기술 (skill)을 흡수하는 방식에서도 나타납니다. 관련 기술을 추가하는 것은 공짜가 아닙니다. 에이전트가 처리해야 하는 지침 (instructions)과 참조 자료 (reference material)를 끌어들이기 때문이며, 문제는 모델이 이러한 오버헤드 (overhead)를 얼마나 효율적으로 결과로 전환하느냐 하는 것입니다.

| 기술 설치의 효과 |
| --- | --- | --- |
| 전체 점수 상승 |
| Opus 4.7 | Opus 4.8 |
| +20.5 | +18.0 |
| ... |

4.7의 경우, 기술을 활성화하면 20점의 정확도 이득을 얻기 위해 41% 더 많은 턴이 추가되었습니다. 4.8에서는 동일한 범주의 기술을 통해 훨씬 적은 턴과 비용 오버헤드로 거의 동일한 이득을 얻을 수 있습니다. 4.8은 기술을 탐색을 위한 초대라기보다는 일종의 지름길 (shortcut)처럼 취급합니다. 에이전트 기술을 대규모로 실행한다면, 이 낮은 기술세 (skill tax)는 배포하는 모든 작업에 걸쳐 복리로 작용합니다.

4.8이 퇴보한 단 한 곳

공정한 비교라면 새 버전이 뒤처지는 부분도 보고해야 합니다. 시나리오별로 기록을 보면 거의 대등한 수준입니다. 2점의 임계값 (threshold)을 기준으로 했을 때, 4.8은 공유된 작업의 23%에서 더 높은 점수를 받았고, 61%에서는 동점이었으며, 17%에서는 더 낮은 점수를 받았습니다. 흥미로운 점은 이러한 손실이 특정 영역에 군집되어 있다는 것입니다.

4.8 버전은 웹 리서치 (web research) 및 스크래핑 (scraping) 기술군에서 퇴보했습니다. Firecrawl 작업은 72개 시나리오 전체에서 평균 3.3포인트 하락했습니다. LangChain은 48개 시나리오에서 2.9포인트 하락했습니다. Tavily 및 Apify와 같은 더 작은 기술군은 수행 작업 수는 적었지만, 각각 10.4포인트와 7.6포인트로 더 크게 하락했습니다. 반면, 4.8 버전은 인프라 (infrastructure), 인증 (auth), 코드 툴링 (code tooling) 분야에서 개선되었습니다. Cloudflare는 38개 시나리오에서 4.5포인트 상승했고, Auth0는 18개 시나리오에서 4.3포인트 상승했으며, Mastra는 10개 시나리오에서 10.1포인트 상승했습니다.

이러한 이득과 손실이 거의 상쇄되었기 때문에, 전체 합계 수치는 이를 완전히 숨겼습니다. 오직 도메인별 세부 분석 (per domain breakdown)만이 이를 드러냅니다. 이것이 단일 리더보드 수치보다 쌍을 이룬 기술 평가 (paired skill evals)를 수행해야 하는 전체적인 이유입니다. 즉, 헤드라인은 동점으로 나타날 수 있지만, 그 이면에서는 두 가지 일관된 변화가 서로 반대 방향으로 진행될 수 있습니다.

언제 4.8 버전으로 업데이트해야 하는가

만약 귀하의 에이전트가 턴 수 (turn count), 지연 시간 (latency), 비용 (cost)이 중요한 긴 멀티 턴 (multi-turn) 작업을 수행한다면(이는 대부분의 프로덕션 에이전트 작업에 해당합니다), 4.8 버전으로 업데이트하십시오. 귀하는 동일한 정확도 상한선, 기술 적용 전의 더 높은 하한선, 21%의 턴 감소, 더 저렴한 기술 비용 (skill tax), 그리고 더 적은 무결성 플래그 (integrity flags)를 얻게 됩니다. 만약 귀하의 워크로드가 인프라, 인증, 또는 일반적인 코드 툴링에 의존한다면, 4.8 버전은 비슷하거나 확실히 더 낫습니다.

만약 귀하의 에이전트가 스크래핑 (scrape), 크롤링 (crawl), 요약 (summarize) 환경에서 작동한다면, 업데이트하기 전에 테스트하십시오. 웹 리서치 퇴보는 절대적인 수치로는 작지만, 우리가 측정한 기술군 전반에서 일관되게 나타납니다. 먼저 귀하의 주요 스크래핑 워크플로우에 대해 자체적인 A/B 테스트를 실행해 보십시오.

핵심 요약: 변경 로그가 아닌 동작을 측정하라

회의론자들은 두 가지 합리적인 이의를 제기할 수 있습니다. 첫째, 점수가 그대로라면 개선이 없는 것이니 왜 신경 써야 하는가? 두 모델이 정확도에서 동점을 기록하더라도, 한 모델은 그 결과에 도달하기 위해 21% 더 많은 턴과 약 5% 더 많은 예산을 소비할 수 있습니다. 둘째, 이것들은 우리의 평가 하네스 (eval harness) 비용일 뿐이다. 하지만 턴, 토큰, 비용의 상대적 차이는 일반화될 수 있는 모델의 동작 (behavior)을 반영합니다.

각 릴리스를 측정할 때, 기술이 설치된 상태와 제거된 상태 모두에서 귀하의 자체 작업에 대한 동작을 측정해야 하며, 평균치를 신뢰하기 전에 반드시 도메인별 세부 분석을 확인하십시오.

모델 업그레이드에 따라 귀하의 스택이 어떻게 동작하는지 확인하고 싶으십니까? Tessl Registry를 탐색하여 에이전트가 의존하는 기술(skills)을 찾은 다음, 실제로 무엇이 변했는지 측정하기 위해 저희가 여기서 사용한 것과 동일한 쌍체 평가(paired evaluations)를 실행해 보십시오.