Everyone''s shipping more. Does any of it matter?

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Everyone’s shipping more. Does any of it matter를 중심으로, AI로 구현 능력이 커지면서 병목이 이동한다. 발표자가 경험한 제약은 개발 인력 부족에서 ‘무엇이 만들 가치가 있는가’에 대한 확를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. AI로 구현 능력이 커지면서 병목이 이동한다. 발표자가 경험한 제약은 개발 인력 부족에서 ‘무엇이 만들 가치가 있는가’에 대한 확신 부족으로 바뀌었다.
2. 출시량과 사업 성과는 별개다. 코드, 기능, 처리한 요청이 늘어도 고객 문제 해결이나 매출 증가가 뒤따르는지는 따로 확인해야 한다.
3. 기존 로드맵과 빠른 실행의 결합에는 세 가지 함정이 있다. 백로그 소진을 진전으로 착각하고, 경쟁사와 비슷한 제품을 만들며, 출시 후 학습하기 전에 다음 제품으로 넘어갈 수 있다.
4. 대안은 신념과 증거를 중심으로 운영하는 것이다. 추구하는 미래와 성공·중단 기준을 먼저 정하고, AI 개발 역량을 실험에 투입한 뒤 결과에 따라 자원을 재배분한다.
5. 문제에 대한 신념은 유지하되 해결책은 바꿀 수 있어야 한다. 탐색, 본격적인 검증 실험, 고객이 의존해도 되는 약속을 구분하고, 출시 속도에서 더 큰 도전과 학습으로 평가의 중심을 옮겨야 한다.

🧩 배경과 문제 정의

클레어 보는 이전 발표에서 던졌던 ‘제품 관리는 끝났다’는 도발적인 주장을 되짚으며, 제품 관리가 사라진 것이 아니라 크게 달라졌다고 설명한다. 이번 발표의 대상은 로드맵이다. 개발 역량이 희소하던 시기에 로드맵은 아이디어를 선별하고 실행 순서를 정하는 핵심 도구였다.

발표자는 코딩 에이전트와 개발 도구 덕분에 이전보다 훨씬 많이 만들 수 있지만, 정작 만들 가치가 있는 아이디어에 대한 확신은 부족하다고 고백한다. 이 경험에서 출발해 ‘더 많이 출시하면 더 중요한 일을 하게 되는가’를 묻는다. 논의는 실행량과 가치의 차이, 기존 로드맵의 함정, 증거 중심의 실험 운영, 고객에 대한 약속, 더 큰 도전으로 이어진다.

🕒 시간순 섹션별 상세정리

1. 제품 관리의 변화와 로드맵에 대한 문제 제기

• 인사와 전날 행사 이야기를 마친 뒤, 지난해의 ‘제품 관리는 끝났다’는 발언을 되짚어 본다. 제품 관리가 사라지지는 않았지만 그 역할은 크게 달라졌다는 것이 출발점이다. [01:04]
• 로드맵은 방향과 다음 작업, 중요한 일을 알려주는 핵심 도구였지만, 이제 많은 팀이 마지막 전통적 로드맵을 작성하게 될 수 있다고 주장한다. [01:47]

2. 실행 능력이 좋은 아이디어를 앞지르다

• 코딩 에이전트, 개발 도구, 모델, 고객 맥락에 접근하는 수단이 늘어 거의 무엇이든 만들 수 있게 됐지만, 좋은 아이디어는 고갈됐다고 고백한다. [02:46]
• 단순히 작업할 요청이 없다는 뜻은 아니다. 구현 속도가 가치 있고 시장성이 있는 제품을 발견하는 능력을 앞질렀다는 설명이다. [03:08]

3. 희소한 개발 인력에서 희소한 확신으로

• 과거에는 아이디어와 수요에 비해 개발 인력이 부족했다. 제품 관리자는 우선순위를 정하고 요청을 거절했으며, 개발과 디자인도 제한된 역량에 맞춰 범위를 줄였다. [04:34]
• 이제 발표자에게는 실행 능력보다 무엇을 만들어야 하는지에 대한 확신이 부족하다. 병목은 구현 가능성에서 구현할 가치에 대한 판단으로 이동했다. [04:55]
• AI 활용과 속도를 요구하는 압력 속에서 출시량은 늘지만, 그 증가에 비례해 매출도 늘었는지를 묻는다. [06:00]

4. 제품 그래프 사례가 드러낸 차별화의 공백

• 고객과 회사의 작업 정보를 모아 더 나은 제품 판단과 PRD 작성을 돕는 제품 그래프를 구상한다. 인사이트 엔진, 의미 기반 그래프, 자동 생성 위키를 구현했고 에이전트도 활용할 수 있었다. [06:50]
• 제품은 작동하고 경쟁사 기능도 따라잡았지만, 발표자는 차별성이 부족하다고 느꼈다. 고객의 관심 표현만으로 고객의 시간을 받을 가치나 투자수익이 확실해지지는 않았다. [07:29]
• 인터페이스와 에이전트 중심 접근도 확신하지 못했다. 코드와 실행 로드맵을 늘리는 일이 제품에 대한 신념을 검증하거나 강화하지는 못했다. [07:54]

5. 자동화된 생산과 사라진 아이디어 필터

• 고객 요청 수정, 기술 부채 처리, 반복적인 재설계가 자동화되면서 개발 체계가 스스로 돌아가기 시작했다. 그러나 발표자는 그 작업들이 얼마나 중요한지 확신하지 못했다. [08:39]
• 기존 로드맵은 개발 자원의 희소성 아래에서 순서와 이정표를 정했고, 실행되지 못한 아이디어를 걸러내는 역할도 했다. 이제는 좋지 않은 아이디어까지 모두 구현할 수 있다. [09:50]
• 실행 비용이 낮아져도 엄격한 판단은 필요하다. 발표자는 기존 로드맵과 사실상 무제한처럼 느껴지는 실행 능력이 결합할 때 생기는 세 가지 함정을 보여준다. [10:07]

6. 백로그, 기능 동등성, 출시 후 포기의 함정

• 첫째는 백로그의 함정이다. AI가 목록의 작업을 모두 처리해도 사업이 전진하거나 고객 문제가 해결됐다는 뜻은 아니다. [10:40]
• 둘째는 기능 동등성의 함정이다. 경쟁사들이 비슷한 고객과 정보를 바탕으로 같은 결론에 도달하면, 비슷한 제품을 빠르게 만드는 데 머물 수 있다. [11:29]
• 셋째는 출시 후 포기의 함정이다. 또 다른 제품을 쉽게 만들 수 있어 기존 제품의 반응에서 배우고 개선하지 않는다. 내부적으로는 생산적으로 보여도 결과는 평범해질 수 있다. [12:07]

7. 로드맵 제로가 바꾸는 우선순위의 의미

• ‘로드맵 제로’는 백로그가 비었다는 뜻이 아니다. 눈에 보이는 모든 기능과 작업을 구현할 수 있게 된 상태를 가리킨다. [12:41]
• 이런 상태에서는 구현 가능성과 예상 노력이 중요한 일을 가려내는 기준으로서 힘을 잃는다. 작업 순서를 정하는 것만으로 전략을 대신하기 어렵다는 주장이다. [13:07]
• 낡은 로드맵에 AI를 결합하면 중요한 도전과 단순 아이디어를 구분하지 못한 채 세 가지 함정으로 더 빨리 들어갈 수 있다고 경고한다. [13:41]

8. 남은 제약은 고객 현실에서 얻는 증거

• 대안의 출발점은 ‘무엇을 충분히 믿기에 그것을 입증하려 하는가’라는 질문이다. 발표자는 남은 제약을 코드가 아니라 고객과 현실에서 확인하는 진실로 보여준다. [14:00]
• AI는 미검증 가정을 사실로 바꿀 수 없다. 실제 고객, 실제 데이터, 반복 테스트와 함께 독자적인 관점과 높은 품질 기준이 필요하다. [14:20]
• AI가 현실과 더 빨리 접촉하게 할수록 결과를 받아들일 책임도 커진다. 기능과 날짜의 목록에서 벗어나 ‘구축’에서 ‘입증’으로 이동하자고 제안한다. [15:16]

9. 신념과 검증 기준을 먼저 세우는 운영 방식

• 먼저 어느 미래를 향할지 정하고, 그 신념을 지지하는 증거와 중단을 요구하는 증거를 사전에 명시한다. [15:46]
• 빠른 개발 체계는 계속 필요하다. 이를 검증 과정의 적절한 위치에 놓고, 현실에서 얻은 결과에 따라 투자와 노력, AI 사용량을 재배분한다. [16:16]
• 유지할 것은 핵심 신념이고 바꿀 수 있어야 하는 것은 기능이다. 고객과 팀이 비전과 팀의 방향에 동의하되, 구체적인 기능은 달라질 수 있는 관계를 전망한다. [17:08]

10. 좋은 고집과 나쁜 고집을 구분하기

• 좋은 고집은 문제에 집중하면서 해결책을 수정하는 것이다. 나쁜 고집은 계속 만들 수 있다는 이유로 목표를 바꾸며 출시를 반복하는 것이다. [17:34]
• 기능의 변화를 수용하면서도 품질과 학습 기준을 유지할 운영 방식이 필요하다. 고객에게 영향을 주기 때문에 어렵지만, 출시하는 모든 것을 영구적인 약속으로 볼 수는 없다고 드러낸다. [17:58]
• 제품 출시는 틀릴 수 있는 가설이자 실험일 수 있다. 시장과 기술 변화까지 고려하면, 고정된 기능과 날짜를 약속하던 방식과 다른 소통이 필요하다. [18:41]

11. 탐색과 검증 실험, 고객 약속의 구분

• 가볍게 탐색하는 단계, 신념을 본격적으로 시험하며 결과를 추구하는 단계, 고객이 의존해도 되는 지속적인 약속을 구분해 보여준다. [19:07]
• 새로운 로드맵에서는 구현 난도와 예상 영향뿐 아니라 신념의 강도와 약속의 지속성을 솔직하게 드러내야 한다. [19:22]
• 코드는 풍부하지만 고객 신뢰는 희소하다. 제품 그래프 사례에서도 고객이 기능을 사용하고 의존하기 시작한 뒤에는 잘못된 판단이 신뢰 손실로 이어질 수 있음을 고민했다. [19:49]

12. 속도 경쟁 다음에는 더 큰 도전

• 로드맵 자체는 여전히 필요하지만 더 넓은 미래상과 증거를 담아야 한다. 무엇이 진전을 보여주고, 무엇이 틀렸음을 입증하며, 무엇이 고객의 시간을 얻는지 물어야 한다. [20:18]
• 지난 12~18개월을 프로토타입과 PR, 빠른 피드백을 늘린 속도 경쟁의 시기로 돌아본다. 그러나 같은 방식이 다음 시기의 전략은 아니라고 드러낸다. [21:02]
• 다음 경쟁은 더 큰 도전이다. 과거에 1년 걸렸을 실험을 2~3주에 수행할 수 있다면 어떤 근본적 변화를 시험할지 생각해야 한다. [21:29]

13. AI 전환의 지표와 마지막 전통적 로드맵

• AI 전환의 OKR을 묻는 질문에 PR 수나 직원당 매출 대신, 매달 얼마나 큰 실험과 대담한 시도를 하는지 되묻는다. 다수가 실패할 수 있음을 전제로 한 제안이다. [22:00]
• 큰 목표를 갖되 세부 구현은 열어두는 방식으로 제품 계획을 바꾸자고 한다. ‘마지막 로드맵’은 마지막 계획이 아니라, 기능·예상 영향·날짜를 고정한 목록을 끝내자는 뜻이다. [22:43]
• 신념과 목표를 높이고, 1~2년 뒤 성공의 모습을 그리며 큰 결정을 내리라고 요청한다. 동시에 1~2주 뒤조차 정확히 예측하기 어렵다는 점을 인정한다. [23:00]

14. 버릴 수 있는 코드와 높아져야 할 기준

• 예상 밖의 좋은 결과를 만들 수 있는 체계를 구축하고, 불필요한 소프트웨어는 버리며, 제품과 AI에 높은 기준을 적용하라고 권한다. 많은 코드를 작성한 뒤 폐기하는 것도 괜찮다는 입장이다. [23:29]
• 다음 해의 구체적인 제품 모습을 모두 약속할 수는 없지만, 더 나은 결과를 기대하며 기존 방식의 마지막 로드맵을 쓰자는 요청으로 마무리한다. 이어 행사 참석자들에게 인사를 전해진다. [23:52]

🧾 결론

• ‘마지막 로드맵’은 계획을 없애자는 주장이 아니다. 기능과 날짜를 고정한 목록에서 벗어나, 지향하는 미래와 이를 뒷받침하는 증거를 계획의 중심에 놓자는 제안이다.
• AI는 고객과 현실을 더 빨리 만날 수 있게 하지만, 검증하지 않은 가정을 사실로 만들어주지는 않는다. 실제 고객, 실제 데이터, 반복 실험이 필요하다.
• 빠르게 만든 코드도 가치가 입증되지 않으면 버릴 수 있어야 한다. 이미 구현했다는 사실이 고객에게 제공할 이유가 되지는 않는다.
• 코드가 풍부해질수록 고객 신뢰와 판단의 중요성이 커진다. 제품이 무엇을 약속하는지 명확히 하고, 그 약속에 맞는 품질과 지속성을 지켜야 한다.

📈 투자·시사 포인트

• 기업의 AI 활용 성과를 볼 때 PR 수나 출시 빈도만으로 판단하기 어렵다. 발표자가 던진 질문처럼, 산출물 증가가 매출과 고객 가치로 연결되는지 확인필요가 있다.
• 같은 도구와 유사한 고객 정보를 사용하는 경쟁사들이 비슷한 기능에 도달할 수 있다. 제품 평가에서는 기능 수 외에 독자적인 관점, 차별성, 검증된 고객 가치를 살펴볼 이유가 있다.
• 자원 배분의 기준도 달라진다. 발표자는 현실에서 얻은 증거에 따라 투자, 노력, AI 사용량을 재배분하고, 과거에는 오래 걸렸던 큰 실험을 짧은 기간에 시도하자고 제안한다.
• 고객이 의존하는 기능의 철회나 변경은 신뢰에 영향을 준다. 실험적 기능과 지속적으로 제공할 기능을 구분하는 능력이 제품 운영을 평가하는 중요한 관점이 된다.

⚠️ 불확실하거나 확인이 필요한 부분

• 개발 역량이 더 이상 핵심 병목이 아니라는 설명은 발표자의 경험과 전망에 기반한다. 모든 조직에서 개발 자원이 충분해졌다는 통계나 비교 자료는 제시되지 않는다.
• 출시량과 매출의 관계는 청중을 향한 질문으로 제시된다. 출시 증가가 매출에 기여하지 않는다는 정량적 결론이나 인과관계가 입증된 것은 아니다.
• 제품 그래프 사례에는 차별성, 투자수익, 인터페이스에 대한 고민이 나오지만, 최종 고객 성과나 실험별 수치는 제공되지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 현재 로드맵의 각 기능 옆에 해결하려는 고객 문제, 핵심 가설, 필요한 검증 증거를 적는다.
• 실험을 시작하기 전에 계속 투자할 조건과 중단할 조건을 정하고, 결과가 나온 뒤 기준을 바꾸지 않았는지 점검한다.
• 출시량·PR 수와 함께 고객 문제 해결 및 사업 성과를 확인해, 실행 증가와 가치 증가를 구분한다.
• 백로그 처리, 경쟁사 기능 따라잡기, 출시 후 방치 중 어느 패턴에 빠져 있는지 최근 작업을 검토한다.

❓ 열린 질문

• 우리 조직에서 실제로 부족한 것은 구현 역량인가, 고객 문제에 대한 이해인가, 만들 가치가 있다는 증거인가?
• 고객이 흥미롭다고 말하는 수준을 넘어, 제품이 고객의 시간과 신뢰를 받을 가치가 있음을 무엇으로 입증할 것인가?
• 문제에 대한 좋은 고집과 실패를 인정하지 않으려고 목표를 바꾸는 나쁜 고집을 어떻게 구분할 것인가?