LangChain CEO 해리슨 체이스(Harrison Chase)가 올해를 한 문장으로 규정했습니다.

“2026 is the year of evals.”

저는 이 말이 어떤 모델 발표나 기능 업데이트보다 PM에게 더 직접적인 신호라고 봅니다.

지금 현장에서 일어나고 있는 일

아마존은 최근 자사 AI 코딩 도구가 충분하지 않다고 공개적으로 인정했습니다. 데모는 인상적이었지만 내부 직원의 실제 사용 통과율이 기대에 미치지 못한다는 것입니다. 세계에서 가장 많은 엔지니어를 보유한 회사가, 자기 제품을 직접 쓰다가 한계를 먼저 발견했습니다.

같은 시기 HuggingFace에서 공개된 ITBench-AA 벤치마크 결과를 보면, 프론티어 모델들의 IT 운영 업무 평균 성과가 50% 미만으로 나왔습니다. IBM과 American Airlines가 함께 설계한 실제 업무 기준입니다. “더 좋은 모델이 나오면 다 해결된다”는 기대와 달리, 현장 업무에서 모델은 아직 절반 이상을 처리하지 못합니다.

삼성SDS AX센터가 발표한 국내 수치는 더 냉정합니다. 에이전트를 실제 프로덕션에 올린 기업은 전체의 5%에 그칩니다. 검토는 많아도 실행으로 이어지는 비율이 낮은 겁니다.

세 신호는 같은 방향을 가리킵니다. 문제는 모델이 아니라 검증 설계가 없다는 것입니다.

에이전트 도입 현장의 공통 패턴

에이전트를 도입했지만 효과가 안 나오는 조직에서 반복적으로 등장하는 패턴이 있습니다.

“동작은 하는데 아무도 안 쓴다.” 기술적으로는 작동하지만 실무자들이 믿고 맡기지 않습니다. 이유를 물어보면 “가끔 이상한 답을 내놓아서요”라는 말이 나옵니다. 오류 빈도를 측정한 적도, 어떤 케이스에서 실패하는지 체계적으로 파악한 적도 없습니다.

“처음엔 좋았는데 지금은 모르겠다.” 파일럿 단계에서는 정확도가 높았지만, 운영 데이터가 쌓이면서 성과가 떨어집니다. 어디서 왜 틀리는지 추적 체계가 없으니 개선도 못합니다.

“ROI를 어떻게 증명하나.” SAS가 글로벌 기업을 조사한 결과에서 확인된 것처럼, 기술 지표만으로는 AI 예산 확보가 어렵습니다. 벤치마크 점수보다 “이 에이전트가 우리 업무에서 얼마나 잘하고 있나”를 보여줄 수 있어야 합니다.

세 가지의 공통점은 하나입니다. eval이 없습니다.

eval 설계가 PM의 책임이 되는 이유

eval은 엔지니어가 만들고 PM은 요구사항만 주면 되는 게 아닙니다.

eval의 기준을 누가 정하느냐의 문제입니다. “이 에이전트가 잘하고 있다”는 판단은 업무 맥락에서만 나올 수 있습니다. 어떤 케이스가 P0(절대 틀리면 안 된다)이고, 어떤 케이스가 P1(허용 가능한 오류 범위)인지는 비즈니스를 아는 PM이 결정해야 합니다.

세일즈포스가 공개한 AI 에이전트 성과 측정 프레임워크는 11개 휴리스틱을 P0/P1/P2 세 단계로 나눕니다. 핵심은 “정확도 92%를 달성했다”가 아니라 “어떤 유형의 오류를 어느 수준까지 허용할 수 있는가”를 먼저 정의하는 것입니다. 92%는 숫자지만, P0 오류가 0건인지 아닌지는 운영에서 차이가 나는 판단입니다.

OpenAI가 회계법인 30곳과 진행한 Tax AI 프로젝트가 이 구조를 잘 보여줍니다. 초기 정확도는 25%였습니다. 6주 후 86%가 됐습니다. 모델을 교체한 게 아닙니다. PM 역할의 팀이 매일 오류를 태깅하고, 실패 케이스를 재현해 eval set에 추가했습니다. 이 피드백이 프롬프트 수정과 파인튜닝으로 이어졌습니다.

이 프로젝트에서 PM의 주요 산출물은 기능 명세가 아니었습니다. “정정 로그 + 반복 오류 태깅 + eval set + 개선 티켓”이었습니다. Spec을 쓰는 역할에서 검증 루프를 운영하는 역할로 이동한 것입니다.

지금 당장 시작할 수 있는 것

eval 설계를 처음 도입하는 PM에게 진입점 세 가지를 제안합니다.

1. 실패 케이스부터 수집하세요. 잘 되는 케이스가 아니라 실패하는 케이스를 먼저 파악합니다. 에이전트가 틀린 답을 냈을 때 어떤 입력이었는지, 어떤 조건이었는지 기록합니다. 이것이 eval의 첫 번째 재료입니다. 특히 “가끔 이상해요”라고 실무자가 말하는 그 케이스를 반드시 잡아두세요.

2. P0 케이스 세 개를 팀과 합의하세요. “이것만큼은 절대 틀리면 안 된다”는 케이스를 세 개만 정합니다. 이 세 케이스가 초기 eval set입니다. 배포 전에 이 세 케이스를 통과하는지 확인하는 것만으로 최소한의 품질 게이트가 생깁니다.

3. 지표를 기술과 업무로 나누어 추적하세요. 정확도·지연시간 같은 기술 지표와, 처리 시간 단축·담당자 개입 횟수 같은 업무 지표를 분리해 측정합니다. 예산 확보 자리에서는 업무 지표가 훨씬 강력합니다. SAS의 조사가 확인한 것처럼, 기술 지표만으로는 경영진의 AI 투자 결정을 움직이기 어렵습니다.

hwchase17이 “2026 is the year of evals”라고 했을 때, 이건 예측이 아닙니다. 이미 현장에서 벌어지고 있는 일을 한 문장으로 압축한 것입니다.

에이전트가 기능을 갖추는 것만으로 가치를 증명하는 시대는 지났습니다. 그 기능이 우리 업무에서 얼마나 신뢰할 수 있는지를 PM이 설계하고 데이터로 보여줘야 하는 시대가 시작됐습니다.

당신의 에이전트에는 지금 어떤 eval이 있습니까?