원티드랩 장수지 PO가 AI타임스 인터뷰에서 한 줄을 남겼습니다.

“AI 시대 PO/PM은 정답을 찾는 사람이 아니라 시험지를 설계하는 사람입니다.”

이 말이 나온 뒤 며칠 사이에 같은 방향을 가리키는 신호가 세 곳에서 더 도착했습니다. GeekNews에서 “AI 서비스 PM, 이제 평가를 설계하라”가 상위권에 올랐고, MIT 연구는 AI 도입에 성공한 조직의 5%가 중앙 AI 랩이 아니라 현장 관리자 주도로 평가 구조를 직접 만든 팀이었다는 결과를 발표했습니다. Andrew Ng도 JetBrains 세션에서 Spec-Driven Development를 강조하며 같은 방향을 확인했습니다.

정답을 찾으려 하면 생기는 일

기존 PM의 역할은 요구사항을 정의하고 우선순위를 정하는 것이었습니다. 좋은 PM은 좋은 질문에 좋은 답을 냈습니다. 에이전트가 들어오면 이 구조가 흔들립니다.

에이전트는 실행 속도가 너무 빠릅니다. PM이 답을 정의하기 전에 코드가 만들어지고, 기능이 붙고, 배포가 됩니다. 검증 없이 나간 기능이 실패하면 PM은 사후에 “왜 이렇게 됐지”를 설명하는 자리에 서게 됩니다. 기획자가 사후 해석가로 밀립니다.

Salesforce가 11개 휴리스틱 평가 체계를 공개하면서 기록한 수치가 있습니다. 정확도 92%를 달성한 에이전트가 실제 운영에서는 유령 성공으로 분류됐습니다. 도달률 숫자는 높은데 사용자 문제는 그대로였기 때문입니다. 에이전트가 빠르게 만든 것이 옳은 것인지를 검증하는 기준이 없었던 결과입니다.

시험지를 먼저 설계한다는 뜻

장수지 PO의 표현이 정확한 이유가 여기 있습니다. 시험지는 결과를 판단하는 기준입니다. 정답보다 먼저 있어야 합니다.

에이전트 시대 PM의 1차 산출물은 기능 명세서가 아닙니다. 이 에이전트가 올바른 결과를 냈는지 판단하는 기준서입니다. 어떤 경우에 성공이고, 어떤 경우에 실패인지, 경계가 어디에 있는지를 미리 정의합니다.

메르카리 NFT 팀이 AI-native 전환에서 내린 결론이 같습니다. 실행 환경(훅, 권한, 샌드박스)은 외부 플랫폼에서 가져오고, 정답과 위험 판단 기준은 팀이 직접 수집하고 문서화했습니다. 그 문서가 평가 기준서 역할을 했고, 에이전트의 출력이 그 기준에 맞는지를 먼저 확인하는 루프를 만들었습니다.

OpenAI의 세금 처리 에이전트 사례도 같은 구조입니다. 6주 만에 정확도를 25%에서 86%로 올린 핵심은 모델 교체가 아니었습니다. 운영 트레이스를 쌓고, 실패 케이스에 태그를 붙이고, 그것을 평가 세트로 만든 루프가 성과를 냈습니다. PM이 만든 것은 기능이 아니라 개선이 가능한 측정 구조였습니다.

시험지 설계의 실제

PM이 평가 기준서를 만드는 방식은 다음 세 가지로 압축됩니다.

성공 조건을 먼저 씁니다. 에이전트가 어떤 결과를 냈을 때 이 작업이 완료됐다고 볼 수 있는지를 기능 개발 전에 정의합니다. 모호한 “잘 작동한다”는 기준서가 아닙니다. “고객 문의 중 80% 이상을 사람 개입 없이 해결하되, 해결 실패 시 3초 내에 담당자에게 전달한다”처럼 계측 가능한 형태로 씁니다.

실패 케이스를 수집합니다. 운영 중 에이전트가 잘못 답한 케이스, 사용자가 다시 묻거나 취소한 케이스를 로그로 남기고 태그를 붙입니다. 이것이 쌓이면 어떤 유형의 입력에서 에이전트가 취약한지가 보입니다. 다음 버전의 평가 세트가 여기서 만들어집니다.

개선 티켓의 단위를 바꿉니다. “기능 A를 추가해 주세요”가 아니라 “실패 케이스 유형 B에서 정확도를 현재 40%에서 70%로 올려 주세요”로 씁니다. 개발팀이 무엇을 해야 하는지가 명확해지고, 완료 여부를 검증하는 기준도 처음부터 있습니다.

지금 만들지 않으면

MIT 연구가 기록한 5%는 낮은 숫자가 아닙니다. 에이전트를 도입한 100개 팀 중 95개가 측정 구조 없이 실행했다는 뜻입니다. 그 95개 팀의 PM이 게으른 게 아닙니다. 시험지를 먼저 만들어야 한다는 사실을 몰랐거나, 만드는 방법을 배운 적이 없는 겁니다.

에이전트가 빠르게 실행하는 환경에서 PM의 희소성은 속도 관리가 아닙니다. 빠르게 실행된 결과가 옳은지 아닌지를 판단하는 기준을 미리 갖고 있는 것입니다.

지금 당신 팀의 에이전트 출력이 ’좋은 결과’를 냈는지 판단하는 기준이 어디에 있습니까?