LangChain 창업자 Harrison Chase가 올해 선언했습니다. “2026 is the year of evals.”

에이전트를 가장 많이 프로덕션에 올려본 사람 중 하나가 한 말입니다. 화려한 수식 없이 그냥 한 문장이었습니다. 그리고 이 문장이 맞아떨어지고 있습니다.

신호 하나: OpenAI 세무 에이전트, 6주 만에 25% → 86%

OpenAI가 올해 공개한 내부 사례입니다. 세무 에이전트의 정확도가 6주 만에 25%에서 86%로 올랐습니다.

비결은 프롬프트 개선이 아니었습니다. 세 단계로 이뤄졌습니다. production trace를 쌓아 어디서 틀리는지 파악하고, 전문가 피드백을 수집해 eval 데이터로 변환하고, 그 루프를 반복했습니다. 모델은 그대로였습니다. 평가와 피드백 구조를 바꿨더니 성과가 뛰었습니다.

PM의 관점에서 이 사례는 명확한 메시지를 담고 있습니다. 에이전트를 배포하는 것보다 배포 이후를 설계하는 것이 실제 성과를 결정한다는 것입니다.

신호 둘: 메르카리의 AI-native 팀, 판단 기준 먼저

메르카리가 최근 AI-native 팀의 운영 원칙을 공개했습니다. 핵심이 흥미로웠습니다.

“하네스, 권한, 샌드박스 같은 기술 인프라는 외부에서 가져온다. 하지만 무엇이 정답이고 무엇이 위험한지 판단 기준은 팀이 직접 수집하고 축적한다.”

기능 개발 능력이 아니라 평가 기준을 설계하고 관리하는 능력을 팀의 핵심 자산으로 정의한 것입니다. 이 판단 기준 문서는 외부에서 살 수 없고, 운영 경험이 없으면 만들 수 없습니다.

왜 지금 PM이 eval을 설계해야 하는가

에이전트는 훈련이 아니라 운영에서 개선됩니다.

기존 소프트웨어는 기능을 만들면 그것이 유지됐습니다. 에이전트는 배포 이후에도 계속 변해야 합니다. 어떤 출력이 성공이고 어떤 것이 실패인지, 어디서 반복적으로 틀리는지를 관찰하고 반영해야 합니다. 이 루프가 없으면 에이전트는 초기 정확도에 고착됩니다.

이 루프를 누가 설계하는가. 모델팀이 아닙니다. 도메인을 알고 무엇이 성공인지 판단할 수 있는 사람이 해야 합니다. 팀 내에서 그 역할을 맡기에 가장 자연스러운 포지션이 PM입니다.

Amazon도 비슷한 신호를 보냈습니다. 내부 AI 코딩 도구의 한계를 공식 인정하면서, 데모에서 작동하는 것과 실제 운영에서 신뢰가 쌓이는 것이 다르다는 점을 드러냈습니다. 빅테크가 스스로 “데모 통과 ≠ 운영 신뢰”를 인정한 것입니다.

CLAUDE.md를 활용한 두 팀의 연구도 같은 구조를 보여줬습니다. 같은 방법을 썼는데 결과가 28% 저하와 20% 향상으로 정반대였습니다. 방법론 자체보다 그것을 운영하는 방식이 결과를 갈랐습니다. eval 루프가 있는 팀과 없는 팀의 차이였습니다.

PM이 지금 만들어야 할 것

기능 명세서 이전에 평가 인프라입니다. 세 가지부터 시작하면 됩니다.

성공 기준 문서를 먼저. 에이전트가 무엇을 했을 때 통과인지, 어떤 출력이 실패인지 기준을 텍스트로 정리하십시오. 코드로 구현하기 전에 인간 검토자가 판단할 수 있는 기준이 먼저 있어야 합니다. 이것이 없으면 dev 완료가 곧 운영 성공이라는 착각을 반복하게 됩니다.

production trace 파이프라인을 초기 설계에 넣으십시오. 로그가 없으면 어디서 틀리는지 알 수 없습니다. trace가 없는 에이전트는 개선할 수 없고, 개선할 수 없는 에이전트는 초기 정확도가 곧 천장이 됩니다.

피드백이 eval 데이터로 변환되는 주기를 정하십시오. 전문가 피드백이 구조화된 eval 데이터로 바뀌는 주기가 짧을수록 에이전트의 개선 속도가 빠릅니다. 이 주기를 설계하는 것이 에이전트 시대 PM의 운영 업무입니다.

Harrison Chase가 맞습니다. 2026은 evals의 해입니다.

에이전트가 팀에서 돌고 있다면, 그것의 성공 기준을 지금 누가 정의하고 있는지 확인하십시오. 기능 명세서는 있는데 eval 기준이 없다면, 절반만 만든 것입니다.