LangChain의 CEO Harrison Chase가 지난달 이렇게 선언했습니다.

“Gall’s law… 2026 is the year of evals.”

자율성보다 먼저 evals(평가), observability(관측성), feedback loops(피드백 루프)가 와야 한다는 말입니다. LangChain이 수천 개 에이전트 팀을 관찰한 결과에서 나온 결론입니다.

같은 시기 HuggingFace에 공개된 ITBench-AA 벤치마크가 이 선언을 숫자로 뒷받침했습니다. 프론티어 모델들조차 IT 운영 자동화 태스크에서 정확도 50% 미달을 기록했습니다. 기술의 한계가 아닙니다. 평가와 관측 레이어 없이 에이전트를 배포했을 때 생기는 결과입니다.

에이전트 도입 5%의 이유

삼성SDS AX센터가 공유한 수치가 있습니다. 실행형 AI 에이전트 전환에 실제로 성공한 기업은 전체 도입 조직의 5% 수준입니다. 기술은 있고, 예산도 있고, 팀도 있는데 이 비율이 이렇게 낮은 이유가 있습니다.

가장 흔한 패턴은 이렇습니다. 데모는 성공했습니다. 그런데 프로덕션에 올리자 에이전트가 무엇을 실수하고, 어디서 막히고, 왜 결과가 달라지는지를 알 수가 없습니다. 오류가 나도 재현이 안 됩니다. 개선을 해도 좋아졌는지 확인이 안 됩니다.

Amazon조차 내부 AI 코딩 도구를 두고 인정했습니다. “데모는 강하다. 하지만 내부 실제 업무 통과율은 기준에 미달이다.” 빅테크가 자사 도구의 한계를 공개적으로 시인한 드문 사례입니다. 그 이유도 같습니다. eval 없이는 어디가 왜 안 되는지 알 방법이 없습니다.

Salesforce가 6월 Fin을 36억 달러에 인수하며 에이전트 프로덕션 체계를 강화한 것도 같은 맥락입니다. 에이전트가 데모를 넘어 실무 투입 단계로 이동하면, 운영과 평가 체계가 곧 제품의 경쟁력이 됩니다.

자율성과 신뢰성은 다른 문제다

에이전트가 자율적으로 행동할수록 내부에서 무슨 일이 일어나는지 알기 어려워집니다. 단순 API 호출이라면 로그로 추적할 수 있습니다. 하지만 멀티스텝 에이전트가 도구를 선택하고, 하위 에이전트를 호출하고, 컨텍스트를 조합해 판단할 때는 추적이 복잡해집니다.

Salesforce가 공개한 에이전트 평가 체계 11 heuristics의 핵심이 바로 여기 있습니다. 에이전트가 “정확도 92%“를 달성해도, 평가 방식이 잘못 설계되어 있으면 유령 성공이 됩니다. 사람이 보기엔 성공처럼 보이지만 실제 업무에서는 오류인 케이스가 섞여 있는 경우입니다.

arXiv 논문 “Why Global LLM Leaderboards Are Misleading”도 같은 방향을 가리킵니다. 단일 벤치마크 점수는 도메인별 업무 성과를 예측하지 못합니다. 같은 모델이라도 평가 방식과 태스크 설계에 따라 결과가 완전히 달라집니다. PM이 모델을 선택하는 기준이 벤치마크 순위에서 업무별 도메인 스코어카드로 바뀌어야 하는 이유입니다.

PM이 설계해야 할 eval 3층

평가를 설계한다는 것은 테스트 케이스를 만드는 일이 아닙니다. 에이전트가 어떤 상황에서 실패하는지, 어떤 패턴이 반복되는지를 보는 운영 루프를 만드는 일입니다.

1층 — 태스크 eval (성능 검증)

에이전트가 요청한 태스크를 올바르게 수행하는지 측정합니다. 정확도, 완료율, 오류 유형 분류가 기본입니다. LLM-as-judge 또는 사람 검토를 혼합해 설계합니다. 처음부터 완벽한 벤치마크를 만들려 하지 말고, 오류가 발생한 케이스를 쌓는 것에서 시작하는 것이 현실적입니다.

2층 — 운영 eval (관측성)

실제 프로덕션에서 에이전트가 어떤 도구를 쓰고, 어디서 지연이 생기고, 비용이 어떻게 발생하는지를 관측합니다. 이 층 없이는 문제를 재현할 수 없고, 개선이 효과가 있는지도 알 수 없습니다. LangSmith, Datadog 같은 관측 도구가 여기서 필요해집니다.

3층 — 피드백 루프 (지속 개선)

운영 데이터와 사람 피드백을 eval 세트에 반영해 에이전트를 개선하는 루프입니다. OpenAI가 Tax AI 에이전트를 개발한 방식이 좋은 사례입니다. 정확도 25%에서 시작한 에이전트가 6주 만에 86%까지 올라갔습니다. 매 스프린트마다 실패 케이스 태깅, eval 추가, 프롬프트 수정 또는 fine-tuning의 루프를 반복한 결과입니다.

LangChain의 deepagents 레포가 GitHub에서 25k 스타를 넘기며 주목받는 이유도 여기 있습니다. 에이전트 하니스에 eval suite를 핵심 모듈로 포함시킨 설계가 실무에서 평가 루프의 필요성을 정확히 반영하고 있습니다.

PM의 산출물이 바뀐다

에이전트 시대 PM의 1차 산출물은 기능 명세(PRD)에서 멈추지 않습니다. 기능 명세 + eval 세트 + 오류 분류 기준 + 피드백 루프 설계까지 포함해야 프로덕션에서 에이전트가 개선됩니다.

OpenAI의 Tax AI 팀이 6주 동안 매주 쌓은 것은 코드가 아니었습니다. 실패 케이스 로그, 재현 스크립트, eval 세트, 개선 기록이었습니다. PM이 이 루프를 설계하고 돌리지 않았다면 25%에서 86%로의 도약은 없었습니다.

Harrison Chase의 선언은 그래서 단순한 연도별 트렌드 예측이 아닙니다. 자율성을 주기 전에 evals를 먼저 깔아라. 에이전트 운영의 순서를 말하는 겁니다.

2026년에 에이전트를 잘 운영하는 팀과 그렇지 못한 팀의 차이는 모델 선택이 아닐 가능성이 높습니다. eval 루프가 있느냐 없느냐의 차이일 것입니다.

당신의 에이전트는 오늘 무엇을 틀렸고, 그 오류가 다음 eval 세트에 반영되고 있습니까?