AI가 몇 시간 안에 꽤 그럴듯한 앱을 만든다. 기획 아이디어를 입력하면 화면이 생기고, 데이터베이스가 연결되고, 클릭 가능한 프로토타입이 완성된다. 예전에는 이런 결과물을 만드는 것 자체가 기술력과 실행력의 증거처럼 보였다. 이제는 제품처럼 보이는 무언가가 존재한다는 사실만으로 시장이 존재한다고 말하기 어려워졌다.
주제를 설명하는 일러스트레이션입니다.
이 변화는 제품관리자(Product Manager, PM)의 역할을 없애지 않는다. 오히려 무엇을 만들어야 하는지, 누구의 문제부터 해결해야 하는지, 어떤 결과를 성공으로 인정할지 결정하는 일을 더 선명하게 드러낸다. 실행 가능한 선택지가 많아졌기 때문이다. AI가 '만들 수 있는 것'의 범위를 넓힐수록, PM은 '지금 만들지 않을 것'을 설명할 책임을 더 많이 진다.
이 글은 AI 도구의 성능 순위를 매기려는 이야기가 아니다. 제품을 만드는 비용이 달라질 때 의사결정의 구조와 검증의 기준을 어떻게 다시 설계해야 하는지에 관한 분석이다.
좋은 제품이란 '완성된 화면'이 아니라 '검증된 선택'에 가깝다
제품팀은 늘 선택을 해왔다. 어떤 고객군을 먼저 공략할지, 어떤 기능은 뒤로 미룰지, 어떤 품질을 확보해야 출시할지, 누가 운영 위험을 받아들일지 결정해야 했다. 달라진 것은 이러한 선택의 비용과 속도다.
예전에는 기능 하나를 구현하는 데 시간이 걸렸기 때문에 팀이 선택에 신중할 자연스러운 이유가 있었다. 디자이너와 개발자가 여러 주 동안 투입되어야 했다면 한 번의 잘못된 결정이 곧바로 일정과 예산에 흔적을 남겼다. 그러나 AI가 구현의 초기 비용을 낮추면 팀은 상충하는 아이디어를 동시에 실험할 수 있다. 그만큼 '코드를 더 작성할까'보다 '어떤 가설을 먼저 틀렸다고 판정할까'가 중요해진다.
Steve Blank는 2026년 9월 Lean LaunchPad 교육과정을 재설계하면서, AI로 첫날부터 만들 수 있는 완성도 높은 초기 제품을 IUP(Initial Untested Product)라고 불렀다.[^1] 보기 좋은 제품이 고객 발견이나 사업모델 검증의 증거로 간주되는 착시를 막기 위해서다. 그는 9월 30일 공개한 후속 설계에서 전체 데모를 앞세우는 대신 작은 제품 조각(snippet)으로 구체적인 가설을 시험하고, 디자인 파트너의 실제 시간·데이터·업무 접근을 검증 근거로 사용하도록 바꿨다.[^2]
이 기준은 PM에게도 유효하다. '작동한다'는 제품의 속성이고, '필요하다'는 고객 문제에 관한 주장이다. 서로 다른 주장은 서로 다른 증거로 확인해야 한다.
개념 설명용 일러스트레이션입니다.
AI가 빠르게 만드는 것과 PM이 책임져야 할 것은 다르다
AI 도구가 초안, 코드, 반복적인 편집과 프로토타이핑을 도울 수 있다는 사실을 부정할 필요는 없다. 그러나 이것을 모든 개발자의 생산성이 동일한 비율로 개선된다는 확정적 숫자로 바꿔서는 안 된다. METR는 2026년 후속 개발자 생산성 실험에서 AI를 쓰지 않고 참여하려는 개발자가 줄어드는 선택편향, 복수 에이전트를 사용하는 작업의 측정 어려움 등을 이유로 현재 속도 향상 효과를 신뢰성 있게 추정하기 어렵다고 밝혔다.[^3]
그렇더라도 생성과 배포의 일부 단계가 빠르게 자동화되는 방향은 실무에서 관찰된다. 문제는 속도를 무엇을 위해 사용할지다.
AI는 하나의 요구사항에서 여러 화면과 기능 후보를 내놓을 수 있다. 하지만 그 기능이 누구에게 가장 필요한지, 도입을 막는 조직적 제약이 무엇인지, 가격을 지불할 사람과 실제 사용하는 사람이 같은지까지 자동으로 확정해주지는 않는다. 좋은 제품팀은 이 부분을 뒤늦은 검수로 남기지 않고 처음부터 결정해야 한다.
예를 들어 한 팀이 회의록을 요약하는 앱을 만든다고 해보자. AI는 요약 기능과 검색 화면을 만들 수 있다. 그러나 고객이 불편해하는 것은 '회의 내용을 읽는 데 오래 걸린다'는 사실이 아닐 수 있다. 회의 후 결정 사항이 담당자에게 전달되지 않는 것, 담당자와 마감일이 바뀌는 것, 중요한 합의의 원본을 찾기 어려운 것이 실제 문제일 수 있다. 문제 정의가 틀리면 요약 속도가 빨라져도 유의미한 고객 가치는 생기지 않는다.
PM이 해야 할 첫 질문은 '어떤 기능을 만들까'가 아니라 '어떤 행동을 바꾸려는가'다.
결정의 질은 '무엇을 만들지 않을지'에서 드러난다
제품 로드맵은 기능의 목록이 아니다. 제한된 시간에 무엇을 먼저 학습하고 무엇을 의도적으로 뒤로 미룰지를 적은 판단의 기록이다. AI가 많은 후보를 제시할수록 포기할 이유를 설명할 필요가 커진다.
좋은 선택에는 최소한 세 가지 조건이 필요하다. 첫째, 문제가 실제 존재한다는 증거다. 둘째, 그 문제가 우선적으로 해결할 가치가 있다는 근거다. 셋째, 새 해결책이 기존 대안보다 낫다는 판단 기준이다. 이 셋이 없으면 제품팀은 구현할 수 있는 기능을 수집하는 데 많은 시간을 쓰고 정작 사용자 경험은 바꾸지 못할 수 있다.
후보가 네 개 있다면 네 개의 앱을 전부 출시하기보다, 각 후보가 검증해야 할 핵심 가설 하나를 고르는 편이 빠를 수 있다. 고객 인터뷰, 업무 흐름 관찰, 가격 제시, 실제 사용 로그와 파일럿에서 반대 증거를 먼저 찾는다. AI를 더 많이 사용하라는 조언이 아니라, AI가 줄여준 제작비를 더 정직한 학습에 사용하라는 뜻이다.
PM의 결정 스택: 고객 → 문제 → 행동 → 지표 → 가드레일
제품 의사결정을 다섯 층으로 나눠 생각해볼 수 있다. 이 순서는 모든 제품에서 불변인 공식이 아니라, 빠른 제작 때문에 중요한 질문이 뒤로 밀리는 것을 막기 위한 실무용 점검 틀이다.
고객. 누가 가장 먼저 제품의 가치를 느끼는가. 실제 사용자, 승인권자, 예산 담당자, 보안 담당자가 다른 B2B 제품에서는 특히 중요하다. '모든 사람'을 대상으로 한 설계는 종종 명확한 첫 사용자를 찾지 못한다.
문제. 고객은 지금 무엇을 하고 있으며, 어디서 시간·비용·오류가 발생하는가. 고객의 말뿐 아니라 우회 방법과 포기한 행동을 살핀다. 좋아 보이는 기능보다 반복적인 불편이 더 좋은 출발점일 수 있다.
행동. 해결책을 도입하면 고객의 어떤 행동이 달라지는가. 첫 클릭보다 과업을 끝내는 흐름이 중요하다. 다른 도구에서 기존 업무로 다시 돌아가는 일이 많다면 그 이유를 알아야 한다.
지표. 팀은 무엇을 성공으로 볼 것인가. 가입자 수만 늘고 반복 사용이 없다면 문제 해결과는 거리가 있을 수 있다. 과업 완료율, 반복 사용률, 완료 시간, 오류 복구, 유료 전환처럼 제품의 성격에 맞는 관찰값이 필요하다. 서로 다른 제품에 같은 지표를 강제로 적용하지 않는다.
가드레일. 자동화할 수 있는 것과 자동화해도 되는 것은 다르다. 개인정보, 데이터 권한, 브랜드 품질, 설명 가능성, 잘못된 결과의 수정·복구 범위를 정해야 한다. 특히 에이전트가 외부 상태를 바꾸는 경우, 기능 성공률과 실행 권한은 다른 판단이다.
이 순서를 정리해두면 빠른 구현 중에도 왜 어떤 기능을 만들었는지 추적할 수 있다. 반대로 순서를 생략하면 팀은 사후에 결과를 합리화하기 쉬워진다.
의사결정 흐름을 설명하는 개념도입니다.
MVP가 쉬워졌다면 검증은 더 엄격해야 한다
아이디어에서 동작하는 화면으로 가는 시간이 줄었다면 PM은 그 시간을 새로운 기능을 추가하는 데만 써서는 안 된다. 빠른 실험이 빠른 학습으로 이어지려면 처음부터 실패 기준을 적어야 한다.
실험은 다섯 단계로 간단히 구조화할 수 있다.
- 가설 설정: 누가 어떤 상황에서 어떤 문제를 반복해서 겪는지 진술한다.
- 빠른 프로토타입: 그 가설을 시험하는 데 필요한 최소 기능만 구현한다.
- 실사용 관찰: 실제 고객이 어떤 경로로 작업하고 어디서 막히는지 본다.
- 핵심 지표 확인: 예정된 성공·실패 기준과 관찰 결과를 비교한다.
- 학습 후 재결정: 지속할지, 수정할지, 중단할지를 정하고 그 이유를 남긴다.
이 과정에서 회의에서 받은 긍정적인 반응이나 가상 고객(persona)의 답변을 실제 사용 검증으로 취급해서는 안 된다. Blank의 후속 커리큘럼에서도 생성형 합성 인터뷰는 실고객 인터뷰와 비교해 검증하는 대상으로 남아 있다.[^2]
예시 화면입니다. 실제 사용 지표를 표시하지 않습니다.
특히 출시 속도가 빨라진 팀일수록 지표의 정의가 흔들릴 위험이 있다. 기능을 출시한 뒤 보기 좋은 숫자만 골라 제시하면 팀은 무엇이 개선됐는지 알기 어렵다. 실험 전에 기준을 기록하고, 비슷한 사용자 집단을 비교하고, 일회성 호기심과 반복적인 사용을 구분해야 한다.
고객이 실제 업무의 일부를 맡기고 데이터를 공유하거나 시간을 들여 제품을 사용한다면 단순한 칭찬보다 더 강한 수요 신호일 수 있다. 그러나 이것 역시 모든 산업에서 동일한 구매 증거는 아니다. B2B 도입 허들과 소비자 앱의 유지율, 규제 산업의 안전성은 각각 다른 검증 설계를 요구한다.
AI 에이전트 시대에는 자동화의 경계도 제품 결정이다
제품이 단순히 정보를 보여주는 단계를 넘어 행동을 실행하기 시작하면 PM의 선택은 UI를 넘어간다. 언제 사람의 승인이 필요한지, 어떤 실패를 자동 재시도해도 되는지, 결제나 외부 게시처럼 되돌리기 어려운 작업을 누가 승인하는지 정해야 한다.
가령 고객지원 에이전트가 답변 초안을 작성하는 것과 고객에게 환불을 실행하는 것은 위험의 성격이 다르다. 작업의 효용뿐 아니라 되돌릴 수 있는 정도, 피해 범위, 데이터 접근권한을 함께 생각해야 한다. 같은 AI 기술을 쓰더라도 승인 흐름은 다르게 설계하는 편이 합리적일 수 있다.
이 기준은 PM의 일이 기술을 몰라도 된다는 뜻이 아니다. 오히려 모델의 실패 형태, 데이터 구조, 도구 사용의 제약, 운영 비용을 이해하고 개발자·디자이너·보안팀과 대화할 수 있어야 한다는 의미다. 다만 제품의 정당성을 모델 점수 하나로 대체하지 않는 것이다.
제작 속도가 경쟁력을 결정하지 않는 영역도 있다
모든 제품의 구현 비용이 동일하게 줄어들지는 않는다. 의료기기, 로봇, 반도체, 물류 설비처럼 물리적 제약이나 인증이 큰 비중을 차지하는 산업에서는 현장 실험과 운영 안정성이 여전히 큰 병목이다. B2B에서는 조직 내부 승인과 정보보안 검토가 신규 기능보다 훨씬 긴 시간을 차지할 수 있다.
또 모든 의사결정이 PM에게 집중되는 구조가 좋은 것도 아니다. 개발팀의 기술적 판단, 현업 사용자의 지식, 법무·보안 담당자의 제한은 서로 다른 권한과 책임에 속한다. PM의 역할은 정답을 혼자 소유하는 것이 아니라 서로 다른 판단을 일관된 우선순위와 검증 기준으로 연결하는 데 있다.
따라서 'AI가 PM을 대체한다' 또는 '이제 PM만 중요해진다'는 이분법은 모두 과장이다. 제품을 만드는 사람들의 역할은 바뀔 수 있지만 고객을 이해하고 시장에서 실제로 작동하는 가치를 만드는 책임은 사라지지 않는다.
끝까지 붙잡아야 할 다섯 가지 질문
AI 도구를 더 많이 도입하기 전에 제품팀이 함께 답해야 할 질문은 다음과 같다.
의사결정에 참고할 질문을 정리한 개념도입니다.
- 누구를 위한 제품인가? 가장 먼저 가치가 생기는 고객을 실제로 만났는가.
- 무슨 행동이 바뀌는가? 고객의 습관과 업무 흐름에서 무엇이 달라지는가.
- 무엇을 성공으로 볼 것인가? 숫자를 세기 전에 어떤 결과를 기대하는지 합의했는가.
- 어디까지 자동화할 것인가? 잘못된 판단의 책임과 사람의 개입 경계는 어디인가.
- 다음 학습은 무엇인가? 오늘의 결과로 어떤 가설을 버리고 어떤 결정을 바꿀 것인가.
AI가 제품을 빠르게 만들 수 있다는 사실은 좋은 출발점이다. 그러나 그것만으로 좋은 제품이 보장되는 것은 아니다. AI 시대의 제품 경쟁력은 더 빨리 기능을 쌓는 능력보다, 더 나은 질문을 던지고 더 나은 결정을 반복하는 능력에서 드러날 수 있다.
[^1]: Steve Blank, “AI Killed the MVP – Long Live the IUP,” 2026-09-25. https://steveblank.com/2026/09/25/ai-killed-the-mvp-long-live-the-iup/ [^2]: Steve Blank, “Lean LaunchPad – The Next Generation,” 2026-09-30. https://steveblank.com/2026/09/30/lean-launchpad-the-next-generation/ [^3]: METR, “We are Changing our Developer Productivity Experiment Design,” 2026-02-24. https://metr.org/blog/2026-02-24-uplift-update/