OpenAI Codex 팀의 리드 Andrew Ambrosino가 Lenny’s Podcast에 나왔습니다.

긴 인터뷰 중에 이 한 줄이 남습니다.

“the new shape of product work.”

제품 업무의 형태가 바뀐다는 겁니다. 기능이 바뀌는 것이 아니라, PM이 하는 일의 구조 자체가 달라진다는 말입니다.

기존 PM 루프의 구조

지금까지 PM의 핵심 루프는 이랬습니다.

사용자 요구 파악 → 기능 스펙 정의 → 개발팀 전달 → QA → 출시 → 지표 측정

이 구조에서 PM의 산출물은 명확했습니다. PRD, 유저 스토리, 우선순위 백로그. PM은 “무엇을 만들지”를 정의하고, 엔지니어가 “어떻게 만들지”를 결정했습니다.

에이전트가 바꿔놓은 것은 이 분업 구조 자체입니다.

에이전트가 코드를 쓰고, 테스트를 돌리고, PR을 생성하는 일이 가능해지면, PM이 “무엇을 만들지”를 정의하는 방식도 달라집니다. 에이전트에게 어떤 컨텍스트를 주고, 어디까지 자율적으로 실행하게 할지, 그 산출물을 어떤 기준으로 검증해 사용자에게 전달할지를 설계하는 일이 PM의 새 핵심 루프가 됩니다.

99% 자동화의 이면

OpenAI가 내부적으로 Codex를 통해 업무 자동화를 추진한다고 밝혔을 때, 외부 반응 대부분은 “이제 개발자가 필요 없다”로 흘렀습니다.

Ambrosino의 메시지는 다릅니다.

자동화 비율이 높아질수록, 나머지 부분 — 에이전트가 실수한 케이스, 엣지 케이스, 예외 처리, 검증 루프 — 에 대한 판단이 더 정밀하게 요구됩니다. 에이전트가 스스로 “이건 내가 판단해도 되는 범위인가, 아니면 사람이 개입해야 하는가”를 알지 못할 때, 그 경계를 설계하는 것이 PM의 일입니다.

이것은 실무에서 이미 나타나고 있습니다. Anthropic이 직원들을 위해 출시한 Claude Skills는 엔지니어링, 마케팅, 법무 직무별로 플레이북을 분리했습니다. AI 활용이 “도구를 쓰는 것”에서 “직무별 스킬과 플레이북을 내재화하는 것”으로 진화한다는 신호입니다. 한 팀이 Claude Skills를 콘텐츠 분업에 적용해 수익화 루프를 만든 것은 이 전환을 가장 빠르게 실천한 사례 중 하나입니다.

”에이전트를 시스템으로 이해해야 제품화된다”

IBM은 에이전트 교육에서 이 문장을 반복합니다.

에이전트를 채팅 인터페이스나 자동화 스크립트로 이해하는 PM과, 계획·실행·검증·피드백이 순환하는 시스템으로 이해하는 PM 사이에는 산출물의 질이 다릅니다.

전자는 “에이전트에게 질문을 잘 던지는 사람”입니다. 후자는 “에이전트가 언제 멈춰야 하는지, 어떤 상황에서 사람을 불러야 하는지, 오류가 발생했을 때 어떤 경로로 수정되는지”를 설계하는 사람입니다.

프로덕션에서 에이전트가 실패하는 패턴은 대부분 이 설계가 없어서입니다. 데모에서 잘 되던 에이전트가 실제 사용자 데이터를 만나면 엣지 케이스에서 멈추거나, 잘못된 판단을 해도 알아챌 방법이 없거나, 오류가 발생했을 때 재현이 되지 않거나. 이 세 가지가 에이전트 제품의 가장 흔한 프로덕션 실패 원인입니다.

PM이 설계해야 할 새 루프

Ambrosino의 “새로운 업무 형태”를 실무에서 구체화하면 이 세 축입니다.

위임 설계: 에이전트에게 맡기는 작업 중 자동 통과되는 범위와 PM이 직접 검토하는 범위를 명확하게 구분합니다. 이 경계가 없으면 에이전트가 틀렸을 때 책임 소재가 불분명해집니다.

검증 기준: 에이전트가 만든 산출물을 사용자에게 전달하기 전, “제품 수준”을 판단하는 기준을 만듭니다. 벤치마크 점수가 아니라, 실제 사용 맥락에서 어떤 오류가 용납되고 어떤 오류는 용납되지 않는지를 정의합니다.

피드백 루프: 에이전트가 실수한 케이스가 다음 버전을 개선하는 데이터로 쌓이는 구조를 만듭니다. 실패가 학습으로 이어지지 않는 에이전트 운영은 영원히 같은 오류를 반복합니다.

이 세 가지는 PM이 기존에 하던 기능 설계와는 다른 종류의 일입니다. 하지만 에이전트 제품이 데모를 넘어 프로덕션에서 작동하려면, 이 설계가 기능 스펙보다 먼저 있어야 합니다.

기능을 정의하는 PM과 에이전트 워크플로우를 설계하는 PM의 차이는 지금 당장 제품의 완성도에서 드러납니다. Ambrosino가 관찰한 것은 미래의 PM 역할이 아닙니다. 지금 Codex를 실제로 운영하는 팀에서 이미 일어나고 있는 현실입니다.

당신의 팀에서 에이전트가 만든 산출물의 검증 기준은 누가, 어떤 근거로 정하고 있습니까?