클레어 보는 AI가 소프트웨어 개발을 엄청나게 빠르게 만들었지만, 무엇을 만들어야 하는지 판단하는 일은 오히려 더 어려워졌다고 말한다. 기존의 기능·일정 중심 로드맵은 AI의 무한에 가까운 실행력과 결합될 때 백로그 소진, 경쟁사 모방, 학습 없는 반복 출시라는 함정으로 이어질 수 있다. 그녀가 제안하는 새로운 로드맵은 기능 목록 대신 큰 야망, 검증 가능한 확신, 고객 현실과의 빠른 접촉, 그리고 명확한 약속의 수준을 중심에 둔다.
1. 제품 관리는 끝나지 않았지만 완전히 달라졌다
클레어 보는 지난해 이 자리에서 "제품 관리는 끝났다"고 선언했다고 회상하며 가볍게 이야기를 시작한다. 물론 실제로 제품 관리가 사라진 것은 아니며, 방 안에는 훌륭한 제품 리더와 PM, 임원들이 가득하다. 다만 지난 Lenny and Friends Summit 이후의 짧은 시간 동안 제품 관리의 환경은 근본적으로 변했다고 강조한다.
그녀는 이번에는 제품 관리자 자체가 아니라, 제품 조직의 가장 중심적인 도구였던 로드맵을 이야기하겠다고 말한다. 로드맵은 원래 팀이 어디로 향하는지, 다음에 무엇을 할지, 무엇이 중요한지를 정리해 주는 문서였다. 그러나 20년 넘게 제품 일을 해온 그녀는 많은 팀이 이제 "마지막 로드맵"을 쓰게 될지도 모른다고 본다.
"로드맵은 우리 분야와 커리어에서 가장 핵심적인 도구였습니다. 어디로 가는지, 다음은 무엇인지, 무엇이 중요한지를 알려줘야 했죠."
"저는 이 방의 많은 사람이 이제 마지막 로드맵을 쓰게 될 것이라고 생각합니다."
2. 실행 능력은 넘치는데 좋은 아이디어는 부족하다
클레어는 지금 자신이 역사상 가장 많은 제품을 출시하고 있다고 고백한다. 뛰어난 코딩 에이전트, 개발 도구, 고성능 모델, 고객 맥락 데이터, API와 CLI, MCP 등 개발과 제품화에 필요한 수단을 풍부하게 갖추고 있기 때문이다. 심지어 자신이 만든 Grok 봇이 40개나 된다고 말하며, 이제는 거의 무엇이든 만들 수 있는 상태라고 표현한다.
하지만 바로 여기서 핵심 고백이 나온다. 만들 수 있는 능력은 폭발적으로 늘었는데, 만들 가치가 있는 좋은 아이디어는 바닥났다는 것이다.
"저는 무엇이든 거의 만들 수 있습니다. 그런데 솔직한 고백을 하자면, 좋은 아이디어가 떨어졌어요."
"만들 수는 있습니다. 하지만 그중 어느 것이 정말 좋은 아이디어인지는 모르겠습니다."
그녀가 말하는 문제는 고객 요청이나 구현할 기능이 없다는 뜻이 아니다. 오히려 요청은 넘친다. 문제는 실행 능력이 가치 있는 제품을 발견하는 능력보다 앞질러 버린 것이다. 예전에는 엔지니어링 인력이 가장 희소한 자원이었기에 제품팀의 일은 수많은 아이디어 중 무엇을 하지 않을지 결정하는 일이었다. PM은 회의, 슬랙, 스프레드시트에서 끊임없이 "아니요"라고 말해야 했다.
"예전에는 엔지니어링 역량이 진짜 희소 자원이었습니다. 아이디어는 사람보다 많았고, 수요는 우리가 감당할 수 있는 것보다 훨씬 컸죠."
"PM의 일은 우선순위를 정하고, 대부분의 시간을 '아니요'라고 말하는 데 쓰는 것이었습니다."
반면 이제는 AI 덕분에 개발 역량이 훨씬 덜 제한적이다. 클레어는 자신의 병목이 "무엇을 만들 수 있는가"에서 "무엇이 정말 만들 가치가 있다고 믿는가"로 옮겨갔다고 말한다. 즉, 핵심 제약은 코드나 기능의 생산 속도가 아니라 제품에 대한 확신과 진실 검증 능력이 되었다.
"이제 제 실행 능력은, 무엇을 만들어야 하는지에 대한 진짜 확신보다 커졌습니다."
"남아 있는 제약은 코드도, 빌드도, 기능도 아닙니다. 그것은 진실입니다."
3. 직접 만든 제품이 보여 준 불편한 진실
클레어는 자신의 실제 사례를 든다. 그녀는 고객 정보, 회사가 진행 중인 일, 제품 관련 지식을 한데 모으고 AI 모델과 에이전트가 이를 활용하도록 하는 제품을 만들었다. PM이 더 나은 결정을 내리고 더 좋은 PRD를 작성하도록 돕는 일종의 제품 인텔리전스·제품 그래프 도구였다.
그녀는 이 제품을 빠르게 만들었다. 인사이트 엔진과 정교한 의미론적 제품 그래프, 자동 생성 위키까지 구축했다. 작동도 했고, 보기에도 좋았으며, 경쟁사가 제공하는 기능과도 충분히 비슷했다. 시장은 존재했고 고객도 흥미롭다고 말했다.
그런데 제품을 만들 때마다 그녀는 속으로 이렇게 느꼈다고 한다.
"이건 쓰레기통에 들어가야 해요. 이 모든 작업과 이 멋진 제품은 쓰레기통에 들어갈 자리입니다."
이유는 단순했다. 경쟁력 있는 제품일 수는 있어도, 독특한 제품은 아니었기 때문이다. 고객이 원할 만하고 시장도 있어 보였지만, 고객의 시간을 받을 만큼 가치 있는지 확신할 수 없었다. 인터페이스가 맞는지, 에이전트 중심 경험이 맞는지, 정말 경쟁사가 상상하지 못할 무언가를 만들고 있는지 의문이 계속 들었다.
"시장은 분명 있었고 고객도 흥미롭다고 했습니다. 그런데도 제 고객의 관심을 받을 가치가 있는지 확신이 들지 않았어요."
"저는 경쟁사가 상상조차 못 할 무언가를 만들고 싶었습니다."
그녀의 문제는 로드맵과 코드가 자신의 '베팅'을 뒷받침할 만큼 검증되지 않았다는 점이었다. 확신을 테스트하거나 강화하기 전에 계속 코드를 쌓고, 더 많은 소프트웨어를 출시하고 있었던 것이다.
AI가 반복적인 고객 수정, 기술 부채 해소, 리디자인, PR 생성 등을 자동화해 주면서 조직은 마치 자동으로 돌아가는 "AI 공장"처럼 보였다. 그러나 그 모든 생산성이 실제로 중요한 일을 하고 있는지는 확신할 수 없었다.
"AI 공장은 우리가 원했던 일을 해냈습니다. 마법 같았죠. 그런데 비밀은 이겁니다. 그중 무엇이 중요한지 저는 확신하지 못했습니다."
4. AI와 기존 로드맵이 만드는 세 가지 함정
클레어는 로드맵이 엔지니어링 자원이 희소했던 시대에는 합리적이었다고 인정한다. 당시에는 기능 개발에 드는 노력, 순서, 마일스톤, MVP 범위를 치밀하게 따져야 했고, 그 제약이 형편없는 아이디어를 자연스럽게 걸러 주기도 했다. 뒤쪽 우선순위의 아이디어는 엔지니어가 부족해서 아예 출시되지 못했다.
그러나 이제는 AI가 거의 모든 아이디어를 만들 수 있게 한다. 그래서 예전에는 실행 제약이 막아 주던 나쁜 아이디어까지도 손쉽게 세상에 나오게 된다.
"이제 우리는 나쁜 아이디어도 전부 출시할 수 있습니다. 축하할 일이죠."
"값싼 실행력일수록 더 엄격한 판단이 필요합니다."
그녀는 전통적 로드맵과 과도한 실행력이 결합될 때 특히 세 가지 함정이 생긴다고 설명한다.
백로그 소진의 함정
첫 번째는 백로그 함정이다. 백로그가 있으면 AI는 그것을 전부 구현할 수 있다. 그래서 팀은 백로그가 줄고, 요청이 처리되고, 기능이 출시되는 것을 진전처럼 느낀다. 하지만 요청을 많이 완료하는 것과 사업이 성장하는 것, 혹은 고객 문제를 실제로 해결하는 것은 전혀 같은 일이 아니다.
"요청이나 아이디어를 끝냈다고 해서 사업에서 진짜 진전을 이루거나 고객 문제 해결에서 진짜 진전을 이룬 것은 아닙니다."
경쟁사와 똑같아지는 함정
두 번째는 동질화의 함정이다. 경쟁사들은 같은 고객에게서 비슷한 정보를 듣고, 비슷한 AI 도구를 사용하며, 결국 비슷하게 '명백한' 답을 도출한다. 모두가 품질을 조금 높이고, 인터페이스를 다듬고, 경계를 없애며, 같은 제품을 더 빨리 만들어 낸다.
"모든 경쟁사가 서로를 복제하고, 같은 고객에게서 같은 정보를 얻고, 같은 뻔한 결론에 도달해 같은 제품을 만듭니다."
이 환경에서 중요한 질문은 여전히 "우리만의 차별점은 무엇인가?"다. 실행력이 평준화될수록 차별화는 기능 목록보다 관점, 고객 이해, 품질 기준, 장기적 베팅에서 나와야 한다.
출시하고 버리는 함정
세 번째는 포기의 함정이다. 어떤 제품을 출시했는데 혼란스럽거나 기대만큼 잘되지 않으면, 팀은 개선하거나 배울 대신 곧바로 다음 제품을 내놓을 수 있다. AI가 너무 빨라서 실패를 마주하고 학습하는 과정조차 건너뛰기 쉬운 것이다.
"우리는 언제든 다른 제품을 출시할 수 있으니, 제품을 버립니다. 그러면 배우지도 않고, 우리가 만든 것을 발전시키지도 못합니다."
이 모든 상황은 조직 내부에서는 매우 생산적으로 보일 수 있다. 백로그는 줄고 기능 수는 늘며 출시 빈도는 높아진다. 그러나 클레어는 이것이 결국 모두를 평범함의 한가운데로 빠르게 몰고 갈 수 있다고 경고한다.
5. '제로 로드맵' 시대에는 우선순위가 전략이 아니다
클레어가 말하는 제로 로드맵은 로드맵이 비어 있다는 뜻이 아니다. 오히려 눈에 보이는 거의 모든 기능이 이제는 실행 가능해진 상황을 뜻한다. 목록에 있는 모든 것을 만들 수 있다면, 단순히 목록의 순서를 정하는 일이 전략일 수 있을까?
"백로그의 모든 것이 실행 가능하다면, 백로그가 무슨 의미가 있나요?"
"실행 가능성과 노력은 더 이상 무엇이 중요한지를 알려주는 유효한 신호가 아닙니다."
과거에는 개발 난이도와 투입 노력 자체가 우선순위를 정하는 강력한 기준이었다. 하지만 AI가 구현 난이도를 크게 낮추면, '쉬운 것부터 하기' 혹은 '효과 대비 노력으로 정렬하기'는 전략적 판단을 대신하지 못한다. 기존 로드맵에 AI를 붙이면, 중요한 베팅과 단순한 아이디어를 구분하지 못한 채 잘못된 판단을 훨씬 빠르게 실행하게 된다.
"이 시스템은 중요한 베팅과 그냥 아이디어를 구별하지 못합니다. AI는 그 나쁜 판단의 결과를 더 빨리 보여 줄 뿐입니다."
그래서 클레어는 기능·날짜 중심의 로드맵이 지금은 위험할 수 있다고 주장한다. 기능 목록은 강력한 AI 실행 엔진에 넣는 탄약이 될 수 있으며, 잘못된 방향의 실행 속도만 폭발적으로 높일 수 있기 때문이다.
6. 구축에서 증명으로: 확신을 검증하는 새 운영 방식
클레어가 제안하는 전환은 명료하다. 팀은 이제 단순히 더 많이 구축(build)하는 데서 멈추지 말고, 자신들의 믿음을 증명(prove)하는 체계로 이동해야 한다.
"우리는 구축에서 증명으로 옮겨가야 합니다."
그녀가 제시한 흐름은 다음과 같다.
-
강한 확신을 세운다.
단기 분기 계획이 아니라, 자신들이 믿는 미래의 방향을 정의한다. 3개월이나 6개월 뒤의 기능이 아니라 "이 모든 것이 궁극적으로 어디로 갈 것인가?"를 묻는다. -
확신을 지지하거나 반박할 증거를 미리 정한다.
무엇을 보면 올바른 방향이라고 판단할지, 무엇을 보면 멈출지를 사전에 명확히 해야 한다. -
빠르게 만들 수 있는 공장을 유지한다.
AI 기반 개발 공장을 버리자는 뜻은 아니다. 오히려 현실에 빠르게 대응하기 위해서는 강력한 실행 엔진이 필요하다. 단, 그 공장은 전략을 결정하는 주체가 아니라 검증을 돕는 수단이어야 한다. -
현실을 만난 뒤 자본과 노력을 재배분한다.
고객 반응과 실제 데이터를 통해 더 강해진 확신에 돈, 시간, 인력, 코드, 관심을 집중한다.
"무엇을 봐야 내가 옳다는 것을 알 수 있을까요? 무엇을 보면 멈춰야 할까요?"
"AI가 주는 것은 현실과 더 빨리 연결되는 능력입니다. 하지만 그만큼 현실을 마주할 의무도 더 커집니다."
여기서 가장 중요한 것은 실제 고객, 실제 데이터, 반복적인 실험이다. AI는 테스트되지 않은 가정을 진실로 바꿔 주지 못한다. 여러 반대 검토를 거친다고 해도, 고객과 시장이 주는 현실을 대신할 수는 없다.
7. 확신에는 끈질기되 해결책에는 유연하라
새로운 환경에서는 "강한 확신과 변경 가능한 기능"이 동시에 필요하다. 팀과 고객은 특정 기능 하나에 베팅하는 것이 아니라, 그 팀이 가진 문제 정의, 방향성, 시장에 대한 관점, 장기 비전에 베팅해야 한다. 기능은 나타났다 사라질 수 있고, 실험에 따라 바뀔 수 있다.
"여러분이 보여 줘야 하는 것은 확신을 향한 분명한 진전이지, 해결책에 대한 자존심이 아닙니다."
클레어는 이를 좋은 고집과 나쁜 고집으로 나눠 설명한다.
- 좋은 고집은 문제와 장기적 확신에는 단단히 붙들려 있으면서, 해결책은 계속 수정하는 태도다.
- 나쁜 고집은 이미 작성된 코드나 계획에 집착해 목표 자체를 바꾸거나, "거의 다 왔으니 조금만 더 출시하자"고 반복하는 태도다.
"좋은 고집은 문제에는 충실하고 해결책은 바꾸는 것입니다."
"나쁜 고집은 코드가 있다는 이유로 목표를 바꾸는 것입니다."
그녀는 모든 출시가 즉시 영구적인 약속일 필요는 없다고 말한다. 제품이 시장에 나갔을 때 이것이 가설인지, 실험인지, 더 진지한 베팅인지, 고객이 의존해도 되는 약속인지 솔직히 구분해 소통해야 한다.
- 탐색 단계: 조금 살펴보는 가설 또는 초기 베팅
- 실험 단계: 핵심 확신을 시험하는 보다 진지한 시도
- 약속 단계: 고객이 의존할 수 있고, 회사가 계속 발전시키겠다고 책임지는 제품
"이것은 가설입니다. 실제 실험이고, 제가 틀릴 수도 있습니다. 시장도 바뀔 수 있고 기술도 크게 바뀔 수 있습니다."
"약속이란 고객이 그 위에 자신의 고객 기반을 만들 수 있고, 우리가 계속 발전시킬 것이라고 믿는 제품입니다."
특히 클레어는 코드는 풍부하지만 고객 신뢰는 희소하다고 강조한다. 자신이 만든 제품 인텔리전스 기능을 섣불리 고객에게 보여 주지 않은 이유도 여기에 있다. 고객은 기능을 보고 자신의 업무와 조직을 그 위에 구축할 수 있는데, 자신이 그 기능을 끝까지 지지할 확신이 없다면 고객 신뢰를 잃게 된다.
"코드는 풍부하지만 고객 신뢰는 희소합니다."
"제가 그 기능을 고객에게 보여 주는 순간, 고객은 그 위에 무언가를 만들 겁니다. 제가 그것을 확신하지 못한다면 고객 신뢰를 완전히 잃게 됩니다."
8. 다음 경쟁은 속도전이 아니라 야망의 경쟁이다
클레어는 지난 12~18개월을 '속도'의 시기라고 부른다. PM이 직접 PR을 쓰고, 프로토타입이 넘쳐나며, 고객에게 더 빨리 보여 주고 피드백을 더 빨리 받는 시대였다. 이는 분명 중요했고, 팀들이 AI를 통해 실제 속도를 얻었다는 점도 인정한다.
하지만 다음 해의 전략까지 단순한 속도 경쟁이어서는 안 된다고 말한다. 이제는 야망의 경쟁으로 옮겨가야 한다.
"지난 12~18개월은 진짜 속도전이었습니다. 하지만 그것이 다음 해에 우리가 해야 할 전략이라고는 생각하지 않습니다."
"다음 해는 야망의 경주입니다."
그녀가 말하는 야망은 AI를 활용해 이전에는 1년이 걸렸을 실험을 2~3주 만에 할 수 있는 가능성을 뜻한다. 그 가능성을 단순히 기능 출시 속도를 높이는 데 쓰지 말고, 훨씬 더 크고 근본적인 변화를 만드는 실험과 프로젝트에 투자해야 한다.
OKR도 PR 수, 직원당 매출, 기능 출시량 같은 지표만으로 AI 전환을 측정하지 말아야 한다. 그녀는 조직이 매달 얼마나 많은 대담한 실험을 하는지 물어야 한다고 제안한다. 대부분이 실패할 것이라는 사실을 전제한 채 말이다.
"저는 매달 얼마나 많은 거대한 실험을 하느냐고 묻고 싶습니다."
"대부분이 성공하지 않을 것이라는 전제 아래, 얼마나 많은 대담한 시도를 하고 있나요?"
새 로드맵의 핵심은 세부 기능을 촘촘히 약속하는 것이 아니라, 큰 야망과 세부 사항의 유연성을 결합하는 데 있다.
9. 마지막 로드맵을 쓰라는 요청
클레어의 마지막 요청은 "마지막 로드맵을 쓰라"는 것이다. 이것은 더 이상 계획을 세우지 말라는 뜻이 아니다. 아이디어와 기능을 스프레드시트에 줄 세우고, 예상 효과를 추정하고, 날짜를 박아 놓고, 이후에는 바꾸지 않겠다고 약속하는 방식의 로드맵을 멈추라는 뜻이다.
대신 팀은 1~2년 뒤의 성공이 어떤 모습일지를 더 대담하게 정의해야 한다. 그 과정에서는 추정과 불확실성을 받아들여야 하며, 시스템이 예상 밖의 사실을 알려 주도록 열어 두어야 한다.
"기능 목록과 날짜가 적힌 스프레드시트를 멈추세요. 영향력을 추정하고, 날짜를 정하고, 절대 바꾸지 않겠다고 합의하는 방식은 끝났습니다."
"여러분의 확신과 야망을 강화하세요. 위대한 아이디어를 만들고, 1~2년 뒤 성공이 어떤 모습인지 정의하세요."
AI 시대에는 많은 코드를 쓴 뒤 버리게 될 수도 있다. 하지만 이는 낭비가 아니라, 낮은 품질의 제품을 고객에게 떠넘기지 않기 위한 정상적인 비용일 수 있다. AI가 팀보다 더 나은 아이디어를 제안할 수도 있고, 미래의 제품 모습은 지금 상상하는 것보다 좋아질 수도 있다. 따라서 중요한 것은 AI를 억제하는 것이 아니라, AI가 만들어 내는 결과물에 아주 높은 기준을 적용하는 일이다.
"많은 코드를 쓰고 버리게 될 겁니다. 괜찮습니다. 고객은 형편없는 제품을 필요로 하지 않습니다."
"여러분의 AI가 팀보다 더 좋은 아이디어를 낼 수도 있습니다. 괜찮습니다. 우리에게는 좋은 아이디어가 필요합니다."
"내년이 어떤 모습일지 팀이나 고객에게 약속하지 못해도 괜찮습니다. 아마 지금 상상하는 것보다 더 나을 테니까요."
마무리
클레어 보의 핵심 메시지는 AI 시대의 제품 리더십이 더 많이 만드는 능력보다 무엇을 믿고, 어떻게 검증하며, 어디까지 고객에게 약속할지를 판단하는 능력에 달려 있다는 것이다. 로드맵은 기능과 일정의 목록이 아니라, 팀의 큰 확신과 야망, 이를 반증하거나 강화할 증거, 그리고 고객 신뢰에 대한 책임을 담아야 한다. 결국 가장 좋은 제품 조직은 가장 많은 기능을 출시하는 조직이 아니라, 현실에서 배우며 가장 중요한 베팅에 과감하게 집중하는 조직이다.
