Harrison Chase(LangChain CEO)가 올해 초 이렇게 썼습니다.

“2026 is the year of evals.”

에이전트를 직접 운영해 본 사람이라면 이 말이 왜 기술 선언이 아니라 PM 선언인지 바로 압니다.

에이전트는 이제 코드를 짜고, 보고서를 쓰고, 고객 문의에 답하고, 심지어 다른 에이전트를 지휘합니다. 그런데 이 에이전트들이 “올바르게” 동작하는지 확인하는 방법은 아직도 대부분의 팀에서 인간의 직관에 의존합니다. 에이전트가 잘하고 있는지, 어디서 실패하는지, 어떤 조건에서 판단이 흔들리는지를 아는 팀이 거의 없습니다.

여기서 PM의 다음 역할이 정해집니다.

PM의 역할이 바뀌고 있다

SVPG(실리콘밸리 프로덕트 그룹)는 최근 PM 역할을 이렇게 재정의했습니다. “무엇이 존재해야 하는지 아는 사람.”

이 정의가 에이전트 시대에 구체적으로 의미하는 것은 무엇일까요.

예전 PM은 기능을 설계했습니다. “사용자가 이 버튼을 누르면 이런 결과가 나와야 한다”는 스펙을 씁니다. 개발자가 구현하고, QA가 검증하고, 배포합니다. 명확한 역할 분담이 있었습니다.

에이전트 시대에는 이 흐름이 바뀝니다. 에이전트는 명세 없이도 실행합니다. 하지만 “올바른 실행”의 기준은 여전히 사람이 정해야 합니다. 더 정확히는, 어떤 결과가 좋은 결과인지 판단하는 체계를 만드는 사람이 PM이어야 합니다.

이것이 Evaluation(이하 eval) 설계입니다.

삼성SDS AX센터가 발표한 수치를 보면 현실이 드러납니다. 에이전트 도입을 시도한 기업 중 실제 프로덕션 수준으로 운영되는 비율은 5%였습니다. 나머지 95%는 POC 단계에서 멈췄습니다. 이유가 기술 부족이 아닙니다. 무엇이 성공인지 모르기 때문입니다.

eval 없이 에이전트는 표류한다

OpenAI Codex 팀이 실제 세무 에이전트를 프로덕션에 올린 사례가 있습니다. 첫 6주 동안 정확도는 25%였습니다. PM이 “프로덕션 트레이스 + 실무자 피드백 + eval set”를 구성하고 반복 개선 루프를 돌렸더니 6주 만에 86%로 올라갔습니다.

기술은 처음부터 있었습니다. 달라진 것은 측정 체계였습니다.

PM이 이 과정에서 한 일은 세 가지였습니다.

  1. 어떤 답변이 정답인지 기준을 만들었습니다 (eval set 구성)
  2. 에이전트가 어디서 실패하는지 추적했습니다 (프로덕션 트레이스)
  3. 반복 오류에 태그를 달고 개선 티켓을 운영했습니다 (feedback loop)

이것이 PM의 1차 산출물이 “기능 명세”에서 “평가 운영 루프”로 이동하는 이유입니다.

ITBench-AA 연구에서도 같은 패턴이 확인됩니다. 프론티어 모델들의 실제 IT 운영 작업 성공률은 50% 미만이었습니다. 표준 작업절차와 관측 레이어를 갖춘 시스템이 없으면 아무리 좋은 모델도 운영 환경에서 흔들립니다. 관측 레이어를 설계하는 사람이 없기 때문입니다.

Hugging Face의 표현을 빌리면, PM이 먼저 정의해야 할 것은 “어디까지 자동이고 어디서 사람이 끊어야 하는지”입니다. 이 경계를 누군가 그어야 에이전트가 방향을 잡습니다.

평가 설계, 실전에서 어떻게 시작하나

처음부터 완벽한 eval 체계를 갖출 필요는 없습니다. 세 가지 질문에서 출발할 수 있습니다.

“좋은 결과”를 한 문장으로 정의할 수 있는가?

에이전트가 고객 문의에 답한다면, “좋은 답변”은 어떤 조건을 만족해야 하는가? 정확성, 간결성, 톤, 추가 정보 요청 여부… 이 기준을 명시하지 않으면 에이전트를 개선할 방향이 사라집니다. “왠지 잘 못하는 것 같다”는 인상만 남습니다.

실패 케이스를 쌓고 있는가?

에이전트가 틀리는 경우, 사용자가 재질문하는 경우, 답을 거부하는 경우를 어딘가에 기록하고 있는가? 이 로그가 없으면 개선 방향을 잡을 수 없습니다. Hugging Face 사례처럼, 틀린 케이스가 없으면 다음 버전의 eval set도 만들 수 없습니다.

개선 루프가 있는가?

평가 결과를 보고 수정하고, 다시 평가하는 주기가 돌아가고 있는가? 이 루프가 없으면 에이전트는 초기 배포 상태로 굳어버립니다. 세무 에이전트 사례에서 6주 만에 25%→86%로 개선된 것은 모델이 좋아져서가 아니라 루프가 있었기 때문입니다.

이 세 가지 중 하나라도 없다면, 지금 운영 중인 에이전트는 통제 없이 돌아가고 있습니다. 잘되고 있다면 운이 좋은 것이고, 안되고 있다면 이유를 알 방법이 없는 상태입니다.

PM은 이제 측정 설계자다

“2026 is the year of evals”는 단순한 기술 트렌드가 아닙니다. PM 직무의 재정의입니다.

코드를 만드는 것은 에이전트가 점점 잘합니다. 그러나 무엇이 좋은 결과인지, 언제 실패하는지, 어떤 기준으로 개선할지는 여전히 사람이 정해야 합니다. 그 사람이 PM이어야 한다는 것이 지금 업계가 실전에서 확인하고 있는 교훈입니다.

Stripe의 Staff Engineer가 최근 말했습니다. “에이전트 병렬 조율이 이제 직급 기대치가 됐다.” 이 말이 맞다면, PM에게 요구되는 것도 “기능을 기획하는 능력”에서 “에이전트가 올바르게 작동하는지 설계하고 검증하는 능력”으로 이동하고 있습니다.

에이전트가 잘하고 있는지 아는 팀과 모르는 팀의 격차는 6개월 후 예상보다 훨씬 클 겁니다.

당신의 에이전트에는 평가 루프가 있습니까?