많은 PM이 이렇게 생각합니다. 모델이 좋아지면 내 일이 쉬워진다고.

그 생각이 반만 맞습니다.

실제로는 이렇습니다. 에이전트가 작업을 끝내는 쪽으로 갈수록, PM이 설계해야 할 것이 더 어려워집니다.

세 가지 신호가 같은 방향을 가리켰다

첫 번째. Anthropic Opus 4.8이 수백 개의 서브에이전트를 조율하며 복잡한 작업을 완수하는 수준에 도달했습니다. “모델이 코드를 잘 짠다”는 이야기가 아닙니다. “에이전트가 맡은 작업을 끝까지 끌고 간다”는 이야기입니다. 완수율이 핵심 지표로 등장하기 시작했습니다.

두 번째. swyx가 공개적으로 비판했습니다. “허술한 RL 환경을 그만 내라.” 에이전트의 품질이 모델 자체보다 환경 설계에 달려 있다는 진단입니다. 환경이 허술하면 모델이 아무리 좋아도 에이전트는 허술합니다.

세 번째. OpenAI의 Tax AI 사례입니다. 세금 신고 자동화 에이전트가 첫 달 정확도 25%에서 시작해 6주 만에 86%에 도달했습니다. 그 개선을 만든 것은 더 좋은 모델이 아니었습니다. production trace, 실무자 피드백, eval 루프였습니다.

세 신호가 말하는 것은 같습니다. 에이전트가 실행을 맡을수록, 그 실행의 품질은 환경과 평가 설계가 결정한다는 것입니다.

왜 PM의 craft가 지금 바뀌는가

PM이 spec을 쓰던 시대가 있었습니다. “사용자가 X를 누르면 Y가 일어난다.” 기능을 정의하고, 개발팀이 구현하고, 테스트해서 배포하는 흐름입니다.

에이전트 시대에 이 흐름이 바뀝니다. 에이전트는 spec을 읽는 게 아니라 작업을 받아 스스로 실행합니다. 이때 PM의 질문이 달라집니다.

전에는 “이 기능이 맞게 작동하는가?”를 물었습니다. 이제는 “이 에이전트가 올바른 결과를 냈는가?”를 물어야 합니다.

그리고 이 두 번째 질문이 첫 번째보다 훨씬 어렵습니다.

“올바른 결과”를 정의하는 것, 그 정의를 측정 가능한 eval로 만드는 것, 에이전트가 학습할 수 있는 환경을 설계하는 것 — 이것이 에이전트 시대 PM의 핵심 craft입니다.

hwchase17(LangChain CEO)이 같은 말을 합니다. 에이전트 인프라의 다음 질문은 “어떤 모델을 쓰는가”가 아니라 “어떻게 지속적으로 개선하는가”입니다. 그 개선 루프의 설계는 PM의 몫입니다.

지금 당장 실천할 세 가지 전환

첫째, PRD보다 eval set를 먼저 씁니다.

에이전트에게 작업을 맡기기 전에, “이 작업이 잘 끝났는지 판단하는 기준”을 먼저 정의합니다. 세금 신고 에이전트라면 세율이 정확한가, 공제 항목이 빠지지 않았는가처럼 검증 가능한 기준이 있어야 합니다. 이 기준 없이는 에이전트를 개선할 수 없습니다.

둘째, 기능 리뷰 대신 작업 완수율을 봅니다.

“기능이 배포됐는가”를 보던 자리에, “에이전트가 맡은 작업을 완수했는가”를 봅니다. 완수율, 오류 유형, 어느 단계에서 실패했는지 — 이 데이터가 PM의 1차 운영 지표입니다. Opus 4.8 수준의 에이전트를 쓰더라도 완수율 없이는 개선 방향을 잡을 수 없습니다.

셋째, 에이전트 환경 설계를 제품 설계만큼 진지하게 다룹니다.

허술한 RL 환경은 허술한 에이전트를 만듭니다. 에이전트가 어떤 피드백을 받고, 어떤 오류를 학습하고, 어떤 상황에서 사람의 검토를 요청하는가 — 이 흐름 설계가 제품의 품질을 결정합니다.

PM 20년의 관점에서 본 것

20년 동안 PM으로 일하면서 가장 많이 들은 말이 “더 좋은 기술이 나오면 PM의 일이 쉬워진다”는 것이었습니다.

그 말이 틀린 것은 아닙니다. 실행이 자동화될수록 판단의 부담이 커진다는 게 더 정확합니다.

AI가 코드를 짜기 전에는 코드 리뷰가 PM의 영역 밖이었습니다. 에이전트가 코드를 쓰고 배포까지 하면, PM이 그 코드가 올바른지 판단하는 구조 자체를 설계해야 합니다.

에이전트가 작업을 완수하는 세상이 오고 있습니다. 그 세상에서 PM의 가치는 더 많은 작업을 에이전트에게 시키는 것이 아닙니다. 에이전트가 올바로 끝냈는지 판단하는 기준을 설계하는 것입니다.

당신의 팀이 지금 에이전트에게 맡기는 작업, 그 작업의 완수 기준을 측정하고 있습니까?