로드맵을 그릴수록 제품이 늦어진다

분기 시작에 잘 그려진 로드맵을 들고 회의에 들어갔던 날을 기억합니다. 색깔별로 정리된 트랙, 월 단위 마일스톤, 분기 끝에 박힌 출시 라벨. 그날 회의실의 공기는 무거웠지만 어쩐지 안심되는 무게였습니다. 모두가 같은 그림을 보고 있다는 안도감이었지요.

분기가 끝날 무렵, 그 그림은 거짓말이 되어 있었습니다. 어느 줄은 두 달 밀렸고, 어느 줄은 아예 사라졌고, 새로 끼어든 줄들이 색깔 없이 흩어져 있었습니다. 흥미로운 점은 이것이었습니다. 로드맵을 더 정교하게 그린 분기일수록, 출시는 더 늦어졌다. 오늘은 이 역설에 대해 함께 이야기해보려 합니다.

정교한 로드맵이 출시를 늦추는 이유

스탠디시 그룹의 CHAOS 리포트는 오랫동안 같은 결론을 반복해왔습니다. 평균적으로 IT 프로젝트의 약 29%만이 약속한 시간, 예산, 범위 안에 출시되고, 48%는 어딘가에서 지연되거나 축소됩니다. 폭포수에서 애자일로 옮겨가도 이 비율은 극적으로 바뀌지 않았습니다. 스탠디시 2020 리포트에 따르면 애자일 프로젝트의 성공률은 폭포수보다 약 세 배 높지만, 여전히 절반은 일정에서 미끄러집니다.

흥미로운 사실은 이 지연이 실행 역량의 문제가 아니라는 점입니다. 1979년 다니엘 카너먼과 아모스 트버스키는 “Intuitive Prediction: Biases and Corrective Procedures”에서 계획 오류(planning fallacy)를 처음 정의했습니다. 사람은 자신의 미래 과업을 예측할 때 체계적으로 시간을 과소평가합니다. 과거에 비슷한 일이 늦게 끝났다는 사실을 알고 있을 때조차 그렇습니다. 카너먼은 이를 “내부 관점”의 함정이라 불렀습니다. 우리는 이번 프로젝트의 디테일만 보고, 다른 비슷한 프로젝트들의 분포는 외면한다는 것입니다.

문제는 로드맵이라는 도구가 이 편향을 증폭시킨다는 데 있습니다. 칸을 채워야 하는 순간 우리는 “이번에는 다를 것”이라는 감각으로 미래를 그리고, 그 그림이 공유되는 순간 약속이 됩니다. 멜리사 페리는 『Escaping the Build Trap』에서 이 함정을 빌드 트랩이라 명명했습니다. 조직이 아웃풋(기능을 출시한 개수)을 성과로 측정하기 시작하면, 정작 그 기능이 어떤 결과를 만들었는지 묻지 않게 된다는 진단이지요. 페리의 표현을 빌리면, “로드맵은 전략이 아니다. 전략은 의사결정의 사슬이다.”

로드맵이 아니라 무엇이 깨졌는가

관점을 바꿔보겠습니다. 정말 로드맵 자체가 문제일까요? 저는 그렇게 생각하지 않습니다. 깨진 것은 도구가 아니라 로드맵에 담는 약속의 종류입니다.

마티 케이건은 SVPG의 “The Alternative to Roadmaps”에서 두 가지 불편한 진실을 제시합니다. 첫째, 제품 아이디어의 최소 절반은 실패한다. 둘째, 가치 있는 아이디어조차 기대 수준에 도달하기까지 여러 번의 반복이 필요하다. 그럼에도 전형적인 로드맵은 마치 모든 기능이 성공할 것처럼, 모든 추정치가 정확할 것처럼 그려집니다. 그래서 케이건은 단호하게 말합니다. “전형적인 로드맵은 제품 팀의 가장 큰 낭비 원천 중 하나다.”

심리학적으로 이 낭비는 약속 일관성(“escalation of commitment”)과 매몰비용 효과가 결합되어 발생합니다. 로드맵이 공개되는 순간, 그 안의 줄들은 단순한 가설이 아니라 사회적 약속이 됩니다. 데이터가 부정적으로 바뀌어도 우리는 방향을 바꾸기보다 더 깊이 파고듭니다. 자신의 결정이 틀렸다고 인정하는 비용이 잘못된 길을 계속 가는 비용보다 크게 느껴지기 때문입니다. 결국 두꺼운 로드맵일수록 빠져나오기 어려운 덫이 됩니다.

여기서부터가 흥미로운 지점입니다. 로드맵이 늦어지는 이유는 그 안의 약속이 너무 구체적이고 너무 멀리까지 그려져 있기 때문입니다. 시간이 멀어질수록 불확실성은 기하급수적으로 커지는데, 로드맵의 가독성은 모든 칸을 똑같은 굵기로 그리도록 요구합니다. 3개월 뒤의 가설과 9개월 뒤의 가설이 같은 시각적 무게를 갖는 순간, 우리는 둘 다 같은 정도로 믿게 됩니다. 그리고 둘 다 같은 정도로 어긋납니다.

약속 대신 학습을 약속하는 프레임워크

로드맵의 자리를 어떻게 다시 설계할 수 있을까요. 최근 몇 년간 가장 잘 작동한다고 평가받는 세 가지 접근을 묶어 정리해보겠습니다.

Now-Next-Later 로드맵. 2012년 ProdPad의 잰나 배스토우가 제안한 단순한 구조입니다. 시간을 날짜가 아닌 세 칸으로 나눕니다. Now는 지금 만들고 있는 것, Next는 다음 차례, Later는 그 다음입니다. 핵심은 칸이 멀어질수록 디테일이 줄어든다는 점입니다. Now 칸의 항목은 문제, 가설, 측정할 결과까지 적지만, Later 칸은 해결하고자 하는 문제만 적습니다. 시간의 불확실성을 시각적으로 인정하는 구조이지요.

GIST 프레임워크. 구글과 마이크로소프트에서 20년 이상 PM으로 일한 이타마르 길라드가 정리한 구조로, Goals(목표) → Ideas(아이디어) → Step-projects(스텝 프로젝트) → Tasks(태스크)의 네 단위로 쪼갭니다. 길라드의 핵심 주장은 이렇습니다. 큰 베팅 몇 개가 아니라, 10주 안에 검증 가능한 작은 스텝 여러 개로 일하라. 아이디어는 가설일 뿐이고, 스텝은 그 가설을 빠르게 죽이거나 살리기 위한 실험입니다. 실패하는 아이디어를 빨리 끝내는 것이 늦지 않게 만드는 가장 확실한 방법이라는 것입니다.

Outcome-based Roadmap. 케이건이 가장 강조하는 형태입니다. 로드맵의 각 줄에 기능이 아니라 이번 분기에 움직이고 싶은 결과 지표를 적습니다. “결제 전환율을 X% 개선한다”, “신규 가입자의 7일 잔존을 Y% 끌어올린다” 같은 식이지요. 그리고 그 결과를 어떻게 만들지는 팀에 위임합니다. 결과가 약속되면 기능은 가설이 됩니다. 가설은 틀려도 부끄럽지 않습니다.

세 프레임워크의 공통점은 단순합니다. 약속의 단위를 산출물에서 결과로, 측정의 단위를 출시 개수에서 학습 횟수로 옮긴다는 것입니다.

작게 시작해서 빠르게 학습한 경험들

이 원칙을 머리로 받아들이는 것과, 손으로 일하는 것은 다른 문제입니다. 제가 직접 경험한 사례 몇 가지를 나눠보겠습니다.

몇 해 전, 작은 매장의 운영 데이터를 통합하는 대시보드 프로젝트를 맡은 적이 있습니다. 처음 그렸던 로드맵은 거창했습니다. 3개월 안에 표준화된 데이터 마트를 설계하고, Tableau로 연간 분석 대시보드까지 완성한다는 계획이었지요. 분기 시작 한 달 만에 그 계획은 무너졌습니다. 매일 CSV를 수동으로 업로드하는 방식이 운영자의 시간을 너무 많이 잡아먹었고, 정작 봐야 할 지표가 늦게 도착했기 때문입니다. 그때 결정한 것은 로드맵을 다시 그리는 일이 아니라, 그 안의 약속을 잘라내는 일이었습니다. Google Sheets와 Looker Studio로 임시 대시보드를 먼저 띄우고, 운영진이 실시간으로 매출을 보는 경험을 한 달 만에 만들었습니다. 표준 데이터 마트는 그 다음 분기로 미뤘습니다. 결과적으로, 원래 로드맵의 4개월보다 2개월 빠르게 운영진이 의사결정에 데이터를 쓰기 시작했습니다. 큰 베팅 하나를 작은 베팅 여러 개로 쪼갠 결정이 일정을 앞당긴 셈입니다.

또 다른 경험은 CRM 정산 프로세스를 다시 설계하던 시절의 일입니다. 처음에 받은 요구사항은 “정산 시스템 전면 개편”이었습니다. 모든 단계를 한 번에 자동화하는 거대한 로드맵을 그릴 수도 있었지만, 우리는 멈춰서 다른 질문을 던졌습니다. 정산 담당자가 가장 자주 헤매는 단계는 어디인가? 관찰해 보니, 사람들은 “이 건이 지금 어느 상태인지” 알 수 없을 때 가장 많이 멈춰 있었습니다. 우리는 전면 개편 대신 정산 요청 확인 탭 하나를 먼저 신설했습니다. 단계별 상태가 한 화면에 보이게 만든 작은 변화였는데, 반복 문의가 눈에 띄게 줄었습니다. 그 학습 위에서 다음 분기에 자동 생성 기능을 얹었습니다. 만약 처음부터 전면 개편 로드맵을 밀어붙였다면, 같은 결과를 두 배의 시간으로 만들었을 가능성이 큽니다.

돌이켜보면 두 사례의 공통점은 명확합니다. 로드맵의 줄을 짧게 잘랐을 때 우리는 더 빨리 학습했고, 학습이 빨라지자 출시도 빨라졌습니다. 길라드의 표현대로, 빨리 죽일 수 있는 가설은 일정의 적이 아니라 친구입니다.

로드맵을 다시 설계하는 다섯 가지 실천

마지막으로, 실무에서 바로 시도해볼 수 있는 다섯 가지를 정리합니다.

1. 로드맵에서 날짜를 빼고 결과를 넣어보세요. “5월 출시” 대신 “5월까지 검증할 가설”이라고 적으면, 같은 줄이 약속에서 실험으로 바뀝니다. 팀원의 자세도 바뀝니다.

2. Now-Next-Later로 시간의 불확실성을 시각화하세요. Now 칸은 자세히, Later 칸은 모호하게. 모든 칸을 똑같이 정교하게 그리려는 충동을 의식적으로 끊는 것이 핵심입니다.

3. 10주를 넘는 베팅은 쪼개세요. 길라드의 기준입니다. 한 분기를 넘는 단일 프로젝트는 대부분 학습 없이 끝납니다. 분기 안에서 두세 번의 학습 사이클이 돌아가는 구조로 자릅니다.

4. 매몰비용 차단을 위한 종료 기준을 미리 적으세요. “어떤 데이터가 보이면 이 가설을 멈출 것인가”를 시작 전에 적어두는 것입니다. 사후에는 거의 적지 못합니다.

5. 분기 회고에서 출시 개수 대신 학습 횟수를 셉니다. 이번 분기에 우리가 틀렸다고 확인한 가설은 몇 개인가? 이 질문을 던지는 팀은, 다음 분기 로드맵이 자연스럽게 얇아집니다.

다시, 로드맵은 무엇이어야 하는가

결국 좋은 로드맵은 약속의 목록이 아니라 학습의 지도입니다. 어디로 가고 있는지에 대한 방향은 또렷해야 하지만, 어떤 길로 갈지에 대한 디테일은 가까울수록 진하고 멀수록 흐려야 합니다. 두꺼운 로드맵이 우리를 안심시키는 이유는 단순합니다. 미래를 통제하고 있다는 환상을 주기 때문이지요. 그러나 그 환상은 늘 분기 끝의 실망으로 청구서를 보내옵니다.

여러분의 다음 분기 로드맵에서, 가장 두꺼운 줄 하나를 먼저 잘라보시길 권합니다. 그 줄을 가설로 다시 쓰고, 10주 안에 검증 가능한 작은 스텝 두세 개로 쪼개보세요. 처음에는 허전할지도 모릅니다. 하지만 분기 끝에 그 줄이 정말로 학습을 만들어냈는지 확인할 때, 우리는 비로소 로드맵이 일정의 적이 아니라 동료가 되는 순간을 만나게 됩니다. 함께 더 가벼운 로드맵을 그려나가 봅시다.

참고 자료

• Marty Cagan, “The Alternative to Roadmaps”, Silicon Valley Product Group
• Melissa Perri, 『Escaping the Build Trap: How Effective Product Management Creates Real Value』, O’Reilly Media, 2018
• Janna Bastow, “Now-Next-Later Roadmap”, ProdPad, 2012
• Itamar Gilad, “Why you should stop using product roadmaps and try the GIST Framework”, itamargilad.com
• Daniel Kahneman & Amos Tversky, “Intuitive Prediction: Biases and Corrective Procedures”, 1979
• The Standish Group, “CHAOS Report 2020”
• Barry M. Staw, “Knee-deep in the Big Muddy: A Study of Escalating Commitment to a Chosen Course of Action”, Organizational Behavior and Human Performance, 1976