수요 믹스, 수요 형성, 그리고 AI라는 기능장애 증폭기
이 글은 제품팀이 다루는 수요 믹스(demand mix) 와 그것을 능동적으로 형성하는 활동들이 팀 운영 방식과 '잘한다'는 것의 의미를 근본적으로 결정한다고 주장합니다. 흔히 AI를 엔지니어링 병목 해소의 수단으로 오해하지만, 저자는 AI가 기존 시스템의 동학을 증폭할 뿐이라고 경고합니다. 결국 핵심은 AI가 아니라, 조직이 어떤 버전의 '퍼널'을 운영하고 있느냐입니다.
1. 수요 믹스란 무엇인가
많은 조직들이 의존성, 예측 가능성, 역량 배분 같은 주제는 열심히 이야기하면서도, 정작 팀이 실제로 어떤 수요 믹스를 다루고 있는지, 그리고 그 수요를 어떻게 능동적으로 형성하고 있는지는 잘 논의하지 않습니다.
제품 개발에서 지배적인 사고방식은 일종의 퍼널(funnel) 입니다. 온갖 것들이 퍼널에 쏟아지고, 걸러지고, 평가되어 결국 변화를 만들어내고, 그 결과가 다시 퍼널로 피드백되는 구조죠.
이 퍼널은 팀과 회사에 따라 극적으로 달라집니다. 한쪽 끝에는 매일 쏟아지는 인입 티켓을 처리하는 지원팀이 있고, 반대편 끝에는 고객 인터랙션을 통해 스스로 수요를 발굴하며, 회사의 높은 수준의 목표에 따라 움직이는 제품팀이 있습니다. 그리고 그 사이에 온갖 팀들이 존재하죠.
정리하자면 두 가지가 핵심입니다.
- 퍼널 안의 구성물: 어디서 왔는지, 누가 관여했는지, 지원 티켓인지 전략적 목표인지 — 그 구성이 팀의 성격을 결정합니다.
- 흐름을 형성하는 방식: 어떤 팀은 고객과 프로토타이핑하며 끊임없이 아이디어를 검증하고 걸러내지만, 어떤 팀은 후반 타당성 검토까지 거의 개입하지 않습니다.
2. 수요 믹스가 팀 운영 방식을 결정한다
수요 믹스와 접근 방식은 당연히 연결되어 있습니다. 믹스에 맞게 접근 방식을 조정하거나, 아니면 믹스 자체를 바꾸려고 노력해야 하죠 💡
조직 전체에서 보면, 팀 간 결합 방식도 크게 달라집니다.
- 높은 인터럽트 환경: 구조화된 인테이크, 우선순위 포럼, 계획 주기에 의존해 혼돈을 관리합니다.
- 자체 수요 발굴 환경: 지속적 학습, 선택적 인테이크, 지속적 정제를 통해 퍼널 상류를 형성합니다.
왼쪽(강하게 결합된) 환경에서는 팀이 집중력을 유지하는 것조차 행운이고, 실제로 뭔가 효과가 있는지 파악하기가 매우 어렵습니다. 반면 오른쪽(느슨하게 결합된) 환경에서는 명확한 우선순위에 맞게 정렬하고, 집중해서 일하며, 지속적으로 배우면서 무엇이 실제로 작동하는지 훨씬 쉽게 파악할 수 있습니다.
우선순위 결정 방식도 달라집니다. 높은 인터럽트 환경(Org A) 에서는 우선순위 논의가 주로 효율성과 지원에 집중됩니다. 노이즈를 줄이고, 물량을 소화하고, 약속을 협상하는 데 급급합니다. 자체 수요 형성 환경(Org B) 에서는 레버리지와 정렬에 훨씬 집중합니다. 어떤 베팅이 중요한지, 전략과 어떻게 연결되는지, 어떻게 하면 에스컬레이션 없이 자신 있게 결정을 내릴 수 있는지를 논의하게 됩니다.
3. 위임 수준과 복잡성의 위치
저자가 이전에 제시한 위임 수준(mandate levels) 개념이 이 맥락에서 구체적으로 드러납니다. '정확히 이것을 만들어라'는 명시적 지시부터 장기적인 비즈니스 아웃컴 창출까지, 조직의 다양한 고도에서 여러 수준이 동시에 작동합니다.
여기서 약간 직관에 반하는 지점이 있습니다. 왼쪽(지시형)은 단순해 보입니다. 이미 형성된 작업이 팀에게 주어지고, 흐름이 표면상 깔끔해 보이죠. 반면 오른쪽(자율형)은 더 복잡해 보입니다. 실험, 피드백 루프, 여러 수준에 걸친 반복이 눈에 보이니까요.
하지만 그 이면을 보면 다릅니다. 왼쪽의 겉보기 단순함은 복잡성을 '하류'로 떠넘긴 결과입니다. 파편화된 인풋, 숨겨진 의존성, 아웃컴을 가리는 사전 형성된 작업이 그 안에 숨어 있습니다. 오른쪽의 복잡함은 그 복잡성을 직접 마주하며, 탐색·실험·정렬을 통해 수요를 능동적으로 형성하는 과정에서 나오는 것입니다.
4. 현실의 두 가지 사례 🔍
이론보다는 실제 사례가 이 차이를 더 잘 설명해줍니다.
첫 번째는 스크럼 방식으로 운영되는 조직의 프로덕트 오너 사례입니다. 그는 자신이 운영하는 것을 "효율적인 피처 팩토리"라고 부릅니다.
- 들어오는 요청에 대해 광범위한 요구사항 탐색을 진행합니다.
- 요청에 역압력(back-pressure)을 가하고, 자주 배포하며, 예측 가능하게 운영합니다.
- 한때 신뢰받지 못했던 팀이 내부 이해관계자들이 '사랑하는' 팀으로 탈바꿈했습니다.
- 이해관계자들을 주기적으로 한 방에 모아 엄격한 '역량 경매'를 진행합니다.
"적어도 제 전 직장과 비교하면, 이렇게 하면 쓸 만한 소프트웨어가 나옵니다. 우리는 자주 배포하고, WIP를 제한하고, 요구사항을 이해하며, 팀을 험담하는 사람이 없습니다."
두 번째는 이론상 "권한 부여된(empowered)" 제품 회사의 PM 사례입니다. 이 회사 리더들은 유명 팟캐스트에도 자주 출연하지만, 실상은 완전히 다릅니다.
"솔직히 말해서, 완전히 엉망진창입니다. 여기서 '권한 부여'란 우리가 수십 개 팀과 서로 경쟁하는 우선순위를 협상할 권한이 주어졌다는 뜻입니다. 각자의 어젠다를 갖고 있죠. 아무도 일을 하는 게 얼마나 힘든지 직시하려 하지 않고, 어느 VP도 자신의 소중한 예산을 다른 그룹에 내주려 하지 않습니다."
"AI 관련 일을 하는 팀들은 날아다니며 다른 사람들에게 도움을 명령합니다. 반면 조직의 실질적인 인프라를 담당하는 팀들은 인력을 구걸해야 합니다."
"우리가 정말 필요한 건 탑다운 우선순위 결정을 시작해서 어려운 결정을 내리는 겁니다. 지금 당장 50% 덜 해야 할 것 같습니다. 그 말을 하면 누군가는 '하지만 당신은 권한이 있잖아요!'라고 답합니다."
두 사례를 합쳐보면 이렇습니다. 수요의 구성과 그것을 형성하는 방식이 팀의 운영 방식, 어떤 관행이 의미 있는지, 그리고 '잘한다'는 것이 무엇인지를 근본적으로 결정합니다.
5. 기존 퍼널 모델의 병리
제품 개발에는 오래된 지배적인 사고방식이 있습니다. 아이디어가 퍼널을 통해 흘러 결국 희소한 엔지니어링 팀이라는 병목에 도달한다는 것입니다. 시스템 전체가 그 병목을 최대한 효율적으로 먹이는 방향으로 조직됩니다.
이 믿음을 가지면 일련의 행동이 따라옵니다. 요구사항이 과도하게 명세화되고, 결정이 일찍 내려지고, 이해관계자들은 줄 서기 위해 치열하게 협상하고, 작업은 패키지화되어 넘겨집니다. '작업이 팀에 닿기 전에 완벽하게 만들어야 한다'는 목표가 생깁니다.
여기서 익숙한 병폐들이 등장합니다 😓
- 조기 수렴이 학습을 대체합니다.
- 연기된 확실성이 호기심을 대체합니다.
- 대용량의 사전 형성된 작업이 시스템을 통과하며 진행의 환상을 만들지만, 실제로 효과가 있는지는 가립니다.
- 노력의 상당 부분이 고객 이해가 아닌 내부 역학 관리로 이동합니다.
이 세계에서 퍼널은 고객에게 의미 있는 변화를 만드는 것이 아니라, 희소한 자원을 배분하는 것을 위한 도구가 됩니다.
6. 더 나은 퍼널 모델
다른 방식으로 퍼널을 생각할 수 있습니다. 퍼널이 팀에서 끝나는 게 아니라, 고객에게 의미 있는 변화에서 끝나는 것이죠. 상류의 모든 것의 목적은 작업을 완벽하게 명세화하는 것이 아니라, 무엇이 할 만한 가치가 있는지를 배우는 것입니다.
이 대안적 모델에서 병목이 이동합니다. 더 이상 엔지니어링 역량만이 아닙니다. 진짜 제약은 시스템이 배우고, 집중하고, 경쟁하는 인풋들 사이에서 일관된 결정을 내리는 능력입니다.
7. AI는 기능장애를 증폭한다 🤖
여기서 AI가 등장합니다. 그리고 쉽게 오해하기 쉽습니다.
첫 번째 모델, 즉 엔지니어링을 병목으로 보는 모델에서 AI는 획기적인 돌파구처럼 보입니다. 코드를 더 빠르게 생성하고, 더 빠르게 프로토타이핑하고, 더 빠르게 배포할 수 있으니까요.
하지만 같은 사고방식을 유지한다면, AI는 아무것도 정리해주지 않습니다. 오히려 이미 가지고 있는 역학을 가속화할 뿐입니다.
- 더 많은 아이디어가 생성됩니다.
- 더 많은 작업이 상류에서 형성됩니다.
- 더 많은 아티팩트가 생산됩니다.
- 협상은 사라지지 않습니다. 연극도 사라지지 않습니다. 과부하도 사라지지 않습니다. 모든 것이 빨라질 뿐입니다.
바이브 코딩으로 만든 프로토타입, 바이브 라이팅으로 쓴 PRD, 더 빠른 요구사항 작성은 문제를 해결하지 못합니다. 그저 문서화와 조기 수렴의 낡은 의식을 더 고속 버전으로 교체할 뿐입니다.
반면 모델을 바꾸면 AI는 완전히 다른 것이 됩니다. 병목에 먹이를 주는 도구가 아니라, 학습을 가속하는 도구가 됩니다. 더 많은 옵션을 탐색하고, 아이디어를 더 빠르게 검증하고, 복잡한 시스템의 연결고리를 발견하는 데 도움을 줍니다.
"AI는 퍼널을 고치지 않습니다. AI는 여러분이 이미 운영하고 있는 퍼널의 버전을 드러내고 증폭합니다."
희소성 관리와 엔지니어링 접근 협상에 맞춰진 시스템이라면, AI는 그 시스템을 더 강렬하게 만들 것입니다. 학습과 의미 있는 아웃컴을 향한 수요 형성에 맞춰진 시스템이라면, AI는 그것을 더 효과적으로 만들 것입니다.
8. 스스로에게 던져야 할 질문들
저자는 마지막으로 조직이 스스로 점검해볼 핵심 질문들을 제시합니다.
- 우리 조직의 퍼널은 실제로 무엇을 위한 것인가? 무엇을 최적화하고 있으며, 얼마나 의도적으로 설계되었는가?
- 팀이 다루는 수요의 형태를 어떻게 설명하겠는가? 어디서 오고, 어떻게 형성되며, 팀이 얼마나 주도권을 갖고 있는가?
- 작업이 흐르는 방식을 관찰할 때, 무엇이 학습처럼 느껴지고 무엇이 협상이나 연기처럼 느껴지는가?
- 어디서 결정이 너무 일찍 내려지고 있는가? 그 결정을 더 오래 열어두면 어떻게 될까?
- 팀이 갑자기 훨씬 더 많은 아이디어를 탐색할 수 있다면, 실제로 무엇이 바뀔까? 무엇이 개선되고 무엇이 조용히 더 나빠질까?
- 시스템에서 진짜 희소한 것은 무엇인가? 엔지니어링 역량인가, 아니면 덜 보이는 것, 즉 집중력, 명확성, 일관된 결정을 내리는 능력인가?
- AI가 워크플로우에 더 깊이 내재될 때, 어떤 기존 행동이나 패턴을 강화할 것인가? 어떤 것을 오히려 도전하길 원하는가?
마치며
이 글의 핵심 메시지는 간단하지만 날카롭습니다. "AI가 문제를 해결해줄 것"이라는 기대는 현재의 퍼널 모델을 바꾸지 않는 한 착각입니다. AI는 조직이 이미 운영하는 방식을 그대로 증폭할 뿐입니다. 더 빠른 배포, 더 많은 아이디어, 더 빠른 문서화가 가능해지더라도, 수요 믹스와 그것을 형성하는 방식이 바뀌지 않으면 혼돈은 더 빠른 속도로 찾아올 뿐입니다.
맥락 없는 '디스커버리'나 '역량' 논의는 의미가 없습니다. 진짜 질문은 언제나 이것입니다. 지금 여러분의 팀은 어떤 수요 믹스를 다루고 있으며, 그것을 얼마나 능동적으로 형성하고 있는가?