🤖 AI 시대, PM의 일은 '번역'에서 '의도 설계'로 바뀌었다

 

PM의 역할이 완전히 달라졌어요

예전 PM의 일은 번역이었어요. 고객과 대화하고, 문제를 정리하고, 스펙 문서를 쓴 다음 엔지니어에게 전달하는 거였죠. "사람들이 필요한 것"과 "실제로 만들어지는 것" 사이의 다리 역할이었어요. 그 번역 레이어에 가치가 있었고요.

그런데 지금 그 레이어가 압축되고 있어요. AI 에이전트가 잘 정리된 문제를 받아서 작동하는 코드를 만들어낼 수 있게 되면서, PM의 일이 바뀌었어요. 더 이상 엔지니어를 위해 번역하는 게 아니라, 에이전트가 바로 행동할 수 있을 만큼 명확하게 의도를 형성하는 거예요.

스펙 자체가 제품이 되어가고 있어요. 정말이에요.

개발 사이클이 몇 주에서 한 시간으로

저를 포함해 수십 명의 PM들을 보면서 이런 변화를 목격했어요. 예전엔 PM이 상세한 스펙을 쓰고, 넘기고, 질문을 기다리고, 명확히 하고, 구현을 기다리고, 검토하고, 피드백 주고, 반복하는 과정이 몇 주씩 걸렸거든요.

지금은 제약사항이 담긴 명확한 문제 정의서를 쓰고, 에이전트에게 던지면, 한 시간 안에 작동하는 코드를 검토하고 있어요. "뭘 만들어야 하는지 안다"에서 "여기 있습니다" 사이의 시간이 무너졌어요.

하지만 뭘 만들어야 하는지 아는 작업이 쉬워진 건 아니에요. 오히려 더 중요해졌죠. 코드를 직접 작성할 필요는 없어요. 하지만 에이전트가 만들 수 있을 만큼 명확하게 원하는 걸 알아야 해요. 스펙과 프로토타입이 같은 것이 되어가고 있어요. 그냥 원하는 걸 설명하고, 형태를 잡아가는 걸 보고, 방향을 조정하고, 반복하면 되거든요.

병목은 더 이상 구현이 아니에요.

출시 속도는 계속 가속화되고 있어요

제가 구글에서 3~4개월 정도 있었는데, 몇 년치의 AI 발전을 출시한 것 같아요. 그 짧은 기간에만 Gemini 3 Pro와 Flash, 멀티모달 Live API, Nano Banana Pro, Deep Research Agent, Google Interactions API, ADK Java/Go/TypeScript 등등 정말 많은 게 나왔거든요.

모든 대형 AI 기업과 작은 스타트업들이 이런 속도로 출시하고 있어요. AI 코딩 에이전트 덕분이죠. 분기별 계획, 월간 스프린트, 주간 릴리스로 정의되던 제품 개발 사이클이 거의 아이디어의 연속 배포에 가까운 수준으로 압축되고 있어요.

가트너의 2024년 조사에 따르면, AI 코드 생성 도구를 도입한 기업의 63%가 개발 속도가 30% 이상 향상됐다고 답했어요. 구현 장벽이 이렇게 빠르게 낮아지면, 병목이 상류로 이동해요. 부족한 자원은 더 이상 엔지니어링 역량이 아니에요.

진짜 만들 가치가 있는 게 뭔지 아는 거예요.

새로운 PM 스킬셋: 문제 형성 능력

제가 아는 최고의 PM들은 항상 이걸 잘했어요. 하지만 예전엔 여러 스킬 중 하나였죠. 지금은 THE 스킬이에요. 애매한 고객 페인 포인트를 에이전트나 에이전트 팀이 행동할 수 있을 만큼 명확하게 형성할 수 있나요? 실제로 중요한 제약사항을 식별할 수 있나요? 성공이 어떤 모습인지 명확히 표현할 수 있나요?

스펙은 더 이상 문서가 아니에요. 명확한 경계를 가진 잘 형성된 문제예요.

맥킨지 디지털의 최근 보고서에서도 이를 뒷받침하는데요, AI 도구를 활용하는 제품팀의 생산성이 40% 이상 향상됐지만, 정작 성공률의 차이는 '문제 정의 역량'에서 나타났다고 해요. 같은 도구를 쓰더라도, 문제를 명확하게 정의한 팀과 그렇지 않은 팀의 결과물 품질 차이가 3배 이상 벌어졌다는 거죠.

컨텍스트 큐레이션: 아무도 말하지 않는 핵심 스킬

이건 아무도 말하지 않는 스킬인데, 에이전트와 효과적으로 일하는 모든 PM이 개발한 능력이에요. 에이전트가 만들어내는 결과물의 품질은 당신이 제공하는 컨텍스트에 정비례해요.

처음 에이전트와 일할 때, 저는 애매한 프롬프트를 줬어요. "고객 피드백 대시보드 만들어줘" 같은 거요. 기술적으론 작동했지만 요점을 완전히 놓쳤어요. 우리 사용자, 우리 제약사항, 우리에게 "좋은" 게 뭔지 이해하지 못했거든요.

지금은 프로젝트를 시작하기 전에 에이전트에게 제공할 컨텍스트 문서를 유지해요. 시간이 지나면서 이런 문서에서 실제로 중요한 게 뭔지 알아냈어요.

구체적인 사용자. 페르소나가 아니라요. 실제 디테일이 필요해요. 그들이 누구인지, 무엇을 중요하게 생각하는지, 무엇 때문에 포기하는지, 무엇에 주목하는지요.

그들의 언어로 된 문제. 통화, 티켓, 영업 노트에서 직접 인용해야 해요. 당신이 요약한 게 아니라 그들의 언어로요. 이게 에이전트를 추상화된 고통이 아니라 실제 고통에 뿌리내리게 해요.

좋은 게 어떤 모습인지. 당신 팀이 잘 디자인됐다고 생각하는 예시들이요. 당신의 과거 작업, 경쟁사, 인접 제품. 설명하지 말고 보여주세요.

시도했던 것과 실패한 이유. 보통 사람들 머릿속에만 있는 조직 지식이에요. 이미 죽인 접근법들과 그 이유를 명확히 해주세요.

솔루션을 형성하는 제약사항. 모든 제약사항이 아니라요. 실제로 만들어지는 것을 바꿀 제약사항만 골라내야 해요.

어떻게 성공했는지 알 수 있는지. 애매한 게 아니라 구체적으로요. 실제로 측정하거나 관찰할 수 있는 것으로 말이죠.

이제 에이전트에게 뭔가 프로토타입을 만들어달라고 할 때, 제로에서 시작하지 않아요. 누구를 위해 만드는지, 그들이 실제로 뭐라고 했는지, 좋은 게 어떤 모습인지, 뭐가 이미 실패했는지 알고 있어요. 입력이 구체적이었기 때문에 출력이 맞아떨어져요.

평가와 취향: 과소평가된 가장 중요한 능력

취향은 과소평가돼요. 하지만 에이전트가 빠르고 대량으로 결과물을 만들어낼 때, 이게 가장 중요한 스킬이 돼요. 이게 실제로 문제를 해결하고 있나요? 중요한 엣지 케이스를 다루나요? 이게 출시해야 할 버전인가요, 아니면 그냥 돌아가는 버전인가요?

이게 들리는 것보다 어려워요. 에이전트는 자신 있게 정확해 보이지만 요점을 완전히 놓친 것들을 만들어내거든요. 취향을 개발하려면 반복 경험이 필요해요.

스탠퍼드 HAI(Human-Centered AI Institute)의 2025년 연구에 따르면, AI 생성 코드의 약 37%가 기능적으로는 작동하지만 실제 사용자 시나리오에서는 부적합한 것으로 나타났어요. 그래서 결국 '좋은 것'과 '작동하는 것'을 구분할 수 있는 PM의 판단력이 더 중요해진 거죠.

지름길은 없어요. 만들고, 평가하고, "출시하기 충분히 좋은 것"과 "기술적으로 작동하는 것"이 실제로 어떤 느낌인지 배워야 해요.

정신 모델의 전환

이제 이렇게 생각해요.

예전 모델은 이랬어요. PM이 뭘 만들지 파악하고, 스펙을 작성하고, 엔지니어가 구축하고, PM이 검토하고, 반복하는 거였죠.

새 모델은 이래요. PM이 뭘 만들지 파악하고, PM이 에이전트와 함께 구축하고, PM이 평가하고, 빠르게 반복하고, 마음에 들면 엔지니어에게 넘겨 프로덕션 배포하는 거예요.

AI PM은 더 이상 요구사항만 넘기지 않아요. 첫 번째 반복을 직접 만들고, 슬라이드나 피그마 목업이 아니라 작동하는 소프트웨어에 대한 실제 피드백을 받아요. 그러면 엔지니어는 당신 의도의 번역자가 아니라 제품을 더 좋게 만들고 프로덕션 준비를 하는 협력자가 돼요.

이게 제품과의 관계를 바꿔요. 원하는 걸 설명하고 제대로 돌아오길 바라는 게 아니라, 실시간으로 직접 형성하는 거예요.

반복으로 사고하고 애매함을 더 오래 유지하세요

첫 버전이 틀려도 괜찮아요. 시작하기 전에 머릿속에서 완벽하게 만들려고 하지 마세요. 에이전트에게 문제에 대한 풍부한 컨텍스트를 주고, 러프한 첫 시도를 하게 하세요. 뭐가 나오는지 보고, 반응하고, 반복하세요.

모든 엣지 케이스를 미리 생각하려고 하는 것보다 "이건 정확히 맞지 않아 왜냐하면..."에서 더 많이 배울 거예요.

저는 정기적으로 에이전트에게 완전히 다른 두세 가지 접근법을 만들게 해서 사용해볼 때 어떤 게 맞는 느낌인지 봐요. 예전엔 비쌌죠. 지금은 화요일 오후에 몇 개의 병렬 에이전트로 할 수 있어요.

예전 PM 본능은 애매함을 최대한 빨리 스펙으로 해결하는 거였어요. 새로운 본능은 탐색하는 동안 애매한 영역에 머무르는 거예요. 너무 일찍 솔루션으로 수렴하지 마세요. 커밋하기 전에 에이전트가 솔루션 공간을 이해하도록 도와주세요.

시작하는 방법

아직 이런 방식으로 일해보지 않은 PM이라면, 이렇게 시작하세요.

실제로 겪고 있는 작은 문제를 고르세요. 상상의 문제가 아니라요. 지금 당신을 짜증나게 하는 것이요. 수동으로 컴파일해야 하는 보고서. 지루한 워크플로우. 존재했으면 하는 프로토타입.

프롬프트하기 전에 30분 동안 컨텍스트를 작성하세요. 위 컨텍스트 큐레이션 섹션의 전체 리스트를 참고하세요.

에이전트에게 던지고 무슨 일이 일어나는지 보세요. 완벽을 기대하지 마세요. 시작점을 기대하세요. 반응하고, 가이드하고, 반복하세요.

이걸 열 번 하세요. 다른 문제들로요. 다른 복잡도 수준으로요. 무엇이 효과적인지, 어떤 컨텍스트가 중요한지, 결과물을 어떻게 평가하는지에 대한 직관이 생길 거예요. 이 직관이 새로운 PM 스킬이에요.

도구보다 중요한 건 매일 하는 습관

성공할 PM들은 문제를 너무 명확하게 이해해서 솔루션이 자신과 함께 일하는 에이전트들에게 명백해지는 사람들이에요.

저는 작업에 따라 AI Studio, Cursor, Antigravity, Claude Code를 바꿔가며 써요. 도구는 매일 에이전트와 일하는 습관을 만드는 것보다 덜 중요해요. 깃허브의 2024년 개발자 설문조사에서도 AI 코딩 도구 사용자 중 88%가 "도구 자체보다 일상적인 사용 패턴이 생산성에 더 큰 영향을 미쳤다"고 답했거든요.

매일 조금씩이라도 에이전트와 협업하는 경험을 쌓아보세요. 처음엔 서툴 거예요. 그런데 2주만 지나면, 당신이 에이전트에게 무엇을 줘야 하고, 어떤 피드백을 줘야 하는지 감이 오기 시작해요.

한 달이 지나면, 이게 당신 워크플로우의 자연스러운 일부가 돼요.

마지막으로 이걸 남길게요

만약 당신 일이 대부분 고객 니즈를 엔지니어를 위한 문서로 번역하는 거였다면, 그건 워크플로우예요. 워크플로우는 자동화돼요.

만약 당신 일이 "문제를 너무 깊이 이해해서 올바른 솔루션이 명백해지게 하는 것"이었다면, 당신은 그 어느 때보다 가치 있어요. 에이전트는 그 이해를 이전 어떤 팀보다 빠르게 출시된 제품으로 증폭시켜요.

모든 PM이 물어야 할 질문이에요. 번역 레이어가 사라지면, 뭐가 남을까요?

최고의 PM들에게 답은 실제로 중요했던 모든 것이에요. 문제 이해. 사용자 공감. 판단력. 취향.

이것들은 항상 PM 일의 일부였어요. 이제 전체 일이 되어가고 있어요.

핵심 요약

AI 에이전트 시대에 PM의 역할은 근본적으로 변했어요. 더 이상 엔지니어와 고객 사이의 번역자가 아니라, 명확한 문제 정의와 풍부한 컨텍스트 제공을 통해 에이전트와 직접 협업하는 사람이죠. 개발 사이클이 몇 주에서 몇 시간으로 압축되면서, 진짜 중요해진 건 "뭘 만들 것인가"를 아는 능력이에요. 문제 형성, 컨텍스트 큐레이션, 평가 능력이 새로운 핵심 스킬이고요. 작은 문제부터 시작해서 매일 에이전트와 일하는 습관을 만들면, 이 변화의 파도를 탈 수 있을 거예요. 도구가 아니라 문제를 보는 깊이가 당신의 가치를 결정하는 시대가 왔어요.