AI 시대의 프로덕트 매니저 되기 02 | 기술을 모르는 것이 왜 오히려 강점인가

먼저 코드를 쓸 줄 모르는 사람이 만든 것 하나를 보겠습니다.

Marcus Rush는 주거용 부동산 중개 회사를 운영하지만 본인은 프로그래머가 아닙니다. 그는 Claude와 Zapier로 Russ라는 AI agent를 하나 엮어냈습니다. 매일 아침 11,000명이 넘는 연락처에서 리드에 점수를 매기고, 휘하의 중개인 한 명 한 명에게 그날의 후속 조치 계획을 써주고, 덤으로 자기 일정까지 관리합니다. 중개 회사 사장 한 명이 손으로 코드 한 줄 건드리지 않고 일상 운영을 굴리는 내부 시스템을 만들어낸 것입니다.

이건 예외적인 사례가 아닙니다. 2026년의 한 통계에서, vibe coding 활성 사용자 중 63%는 개발자가 아니었습니다. 프로그래밍 배경이 없는 어느 디자이너는 Replit과 AI로 직접 프로덕트를 출시해 월 2만 달러를 벌어들였는데, 이는 원래 월급의 두 배가 넘는 금액입니다.

이것들을 나란히 놓고 보면 직관에 반하는 한 가지가 보입니다. 「아이디어를 실제로 굴러가는 것으로 바꾸는」 이 길 위에서는, 기술을 모르는 사람이 엔지니어보다 더 수월하게 갈 때가 있다는 것입니다.

엔지니어는 먼저 한 가지를 내려놓아야 한다

베테랑 엔지니어가 AI로 일하는 모습을 관찰한 사람이 있습니다. 그들은 구현의 세부 하나하나에 따지고 드는 데 익숙해서 「왜 X를 안 쓰지」 「Y는 고려해봤나」 하고 되묻는데, 모델의 기본 반응은 「알겠습니다, 그럼 넣겠습니다」입니다. 이십 년 동안 단련된, 코드 한 줄 한 줄에 책임지려는 본능을, AI와 협업하는 이 자리에서는 먼저 내려놓아야 합니다.

이건 그들에게 어려운 일입니다. 내려놓아야 하는 것은 「모든 줄을 내 손으로 직접 쓰고 내 눈으로 직접 검토해야 한다」는 그 집착입니다. METR의 그 실험에서, 베테랑 프로그래머 16명이 자기가 여러 해 유지보수해온 프로젝트에서 AI를 썼는데 실제로는 19% 느려졌고, 그런데도 본인은 20% 빨라졌다고 믿었습니다. 익숙한 사람일수록 도구와 엇나가기 쉽습니다.

기술을 모르는 사람에게는 이 짐이 없습니다. 그에게는 내려놓을 것 자체가 없습니다.

「이건 너무 어렵다」, 기술을 모르는 사람은 꺼내지 못한다

예전 프로덕트 매니저의 판단 일부는 「이 기능을 구현하기가 얼마나 어려운가」에서 나왔습니다. 이 지식에는 부작용이 있습니다. 어떤 아이디어 뒤에 얼마나 많은 것을 고쳐야 하는지, 얼마나 많은 함정을 헤쳐야 하는지를 잘 알수록, 입 밖에 꺼내기도 전에 먼저 그것을 죽여버리기 쉽습니다. 아는 사람일수록 자기 검열이 가장 혹독합니다.

기술을 모르는 사람은 자신에게 이 문턱을 두지 않습니다. 그는 어렵다는 걸 모르기 때문에, 우선 원하는 것을 분명하게 말해놓고 구현 난이도라는 그 부분은 AI에게 먹어치우게 합니다. doaipm이 말하는 言出法随가 바로 이것입니다. 분명하게 말하면 AI가 만들어준다는 것. Marcus는 11,000건의 연락처를 가로지르는 점수 로직을 짜는 것이 「얼마나 어려운지」 몰랐고, 자기가 무엇을 원하는지만 알았고, 그걸 말로 꺼냈습니다.

희소한 것은 아이디어를 분명하게 말하는 것이지, 코드를 써내는 것이 아니다

Russ라는 agent가 굴러가는 것은 Marcus가 Python을 쓸 줄 알아서가 아니라, 그가 비즈니스를 잘 알기 때문입니다. 리드를 무엇을 기준으로 점수 매길지, 후속 조치 계획에 어느 항목을 써야 할지, 어느 연락처를 앞에 둘지. 이것들은 판단이지 기술이 아닙니다.

AI는 생략에서 의미를 추론해주지 않습니다. 당신이 분명히 말하지 않으면, 기본값대로 한 버전을 만들어주는데 십중팔구 당신이 원하던 것이 아닙니다. 규칙과 경계와 상태를 다 분명하게 설명할 수 있는 사람은, 산출물이 남들과 한 자릿수 차이로 벌어집니다. 이 능력은 프로그래밍을 할 줄 아느냐와는 상관이 없습니다. a16z가 프로덕트 매니저에게 주는 조언에는 이런 항목이 있습니다. 순수한 프로세스 매니저는 도태되고, 「만드는 사람의 사고방식」을 가진 사람만 지렛대를 갖는다는 것. 여기서 말하는 만드는 사람의 사고방식이란, 아이디어를 직접 손으로 만들어내 검증하러 가는 것을 마다하지 않는 태도이고, 코드를 쓸 줄 아느냐는 그 안에 들어 있지 않습니다.

강점은 거저 주어지지 않는다

기술을 모른다는 것이 아무것도 몰라도 된다는 뜻은 아닙니다. Marcus가 쓴 Zapier, 그 디자이너가 쓴 Replit, 그 뒤에는 익숙해져야 할 한 벌의 손기술이 있습니다. 요구를 AI가 한입에 받아낼 수 있는 작은 단계로 쪼개는 법, AI가 내놓은 것이 맞는지 가늠하는 법, 어디서 멈추고 진짜 사람에게 넘겨야 하는지.

기술을 모르는 사람이 가장 빠뜨리기 쉬운 것은 안전망입니다. 프로토타입에 진짜 고객 데이터를 넣지 말 것. 출시, 삭제, 결제처럼 한번 누르면 되돌릴 수 없는 버튼은 사람이 누르도록 남겨둘 것. Marcus의 Russ는 중개인에게 후속 조치 계획을 「써」주지만, 누군가에게 그것을 대신 「보내」지는 않게 했습니다. 그 한 번은 여전히 사람이 누르는 것입니다.

오늘 해볼 수 있는 한 가지. 줄곧 「이건 엔지니어를 찾아야지」 하고 생각해온 작은 아이디어를 하나 고르고, 먼저 어려운지부터 묻지 말고, 원하는 것을 한 줄 한 줄 분명하게 적어 AI에게 던져 첫 버전을 만들게 하십시오. 그것이 어디까지 해내는지 먼저 보고 나서 판단하십시오.

더 읽어보기

• Zapier 「Vibe coding examples: Real projects from non-developers」 (Marcus Rush / Rush Home 사례): https://zapier.com/blog/vibe-coding-examples/
• a16z 「5 Principles for PMs in the AI Era」 (만드는 사람의 사고방식 vs 프로세스 매니저): https://a16z.com/stay-relevant-in-ai/
• 이 시리즈의 01편 프로덕트 매니저의 어떤 일이 AI에게 넘어갔고, 어떤 일이 오히려 더 비싸졌나