에이전트의 가치를 설득해야 하는 자리에서 벤치마크 점수가 통하지 않기 시작했습니다. Mozilla가 공개한 숫자가 새로운 기준입니다. Claude Mythos Preview가 4월 한 달 동안 발견한 Firefox 코드베이스 버그가 이전 15개월치 합산과 같았습니다.

이 숫자의 중요성은 버그 개수에 있지 않습니다. 에이전트 ROI가 처음으로 기업 의사결정자가 이해하는 언어로 표현됐다는 데 있습니다.

벤치마크는 조달 언어가 되지 못한다

“정확도 87%“나 “MMLU 92점”은 CFO에게 예산 승인의 근거가 되지 않습니다. “한 달 = 이전 15개월”은 됩니다.

Anthropic의 alexalbert는 에이전트가 실제로 일하는 조직일수록 자체 코드베이스와 업무에 맞춘 평가셋을 만든다고 지적했습니다. 외부 벤치마크는 조달 결정의 첫 번째 언어가 될 수 없습니다. 조달 결정이 이루어지는 회의실에서 비교군은 언제나 “우리가 같은 일에 쓴 이전 기간”입니다.

Mozilla-Mythos 사례는 이 측정법이 작동한 공개 데이터 중 하나입니다. 보안 도메인에서 이 비율이 나왔을 때, 그것은 동시에 재계약 근거가 됩니다.

측정 단위를 다시 설계해야 한다

AI 투자 정당화의 병목은 기술이 아닙니다. 성과를 어떤 단위로 잡느냐입니다.

PM이 에이전트 도입을 설계할 때 측정 단위를 바꾸지 않으면, 실제로 성과가 나와도 설득이 되지 않습니다. 에이전트가 맞힌 비율보다 특정 업무에서 처리 시간이 얼마나 줄었는지가 더 직접적인 수치입니다. 오류 발견율이나 검수 절감 시간은 팀 전체의 부담을 수치로 보여줍니다. 비교군은 단순합니다 — 에이전트 투입 전 같은 기간의 실적과 비교하면 됩니다.

이 세 가지 측정 방식이 나오는 순간, 에이전트의 가치는 기술 스펙에서 업무 성과로 이동합니다.

성과 측정이 먼저인 이유

에이전트를 먼저 만들고 성과를 나중에 측정하는 순서로는 조직 설득이 어렵습니다. 어떤 성과를 어떤 단위로 볼 것인지를 도입 전에 확정해야 나중에 그 데이터가 나왔을 때 의미 있는 언어가 됩니다.

Anthropic의 emollick이 강조한 것도 같은 맥락입니다. 벤치마크로 시작하면 벤치마크로 끝납니다. 실제 업무 흐름 안에서 비교 가능한 측정값을 만드는 것이 에이전트 PM의 1차 설계 과제입니다.

Mozilla가 보안 에이전트에서 꺼낸 숫자는 우연이 아닙니다. 15개월이라는 비교 기간이 설정되어 있었고, 같은 유형의 취약점을 같은 기준으로 세고 있었기 때문에 그 비율이 나올 수 있었습니다.

여러분의 에이전트는 지금 어떤 비교 기간과 기준으로 성과를 측정받고 있습니까?