로드맵은 일정표가 아니다
로드맵을 일정 약속이 아니라 방향 문서로 다시 짠 기록. 과제를 고객 상태 전이로 묶고, 성과를 완료율이 아니라 관문 통과율로 바꿨다.
실제 업무 문서에서 발췌했습니다. 서비스·프로젝트 이름과 단계별 판정 수치는 모자이크로 가렸고, 판단의 구조만 남겼습니다.
로드맵의 첫 번째 일은 일정을 약속하는 것이 아니다. 서비스가 어디로 가는지를 고정하는 것이다.
이 순서가 뒤집히면 문서는 반드시 같은 모양으로 망가진다. 방향이 비어 있는 자리를 과제 목록이 채우고, 그때부터 조직은 "무엇을 만들 것인가"만 논의하고 "우리가 무엇이 되려는가"는 논의하지 않는다. 목록은 계속 길어지는데 제품은 어디로도 가지 않는다.
서른 개 과제를 팀별로 모아 분기에 배치한 판이 있었다. 항목은 다 맞았다. 그런데 그 한 장을 놓고 다음 세 질문 중 어느 것에도 답이 안 됐다.
- 둘이 동시에 늦으면 무엇을 포기하는가
- 이 과제가 끝났다는 것을 무엇으로 아는가
- 앞이 밀리면 뒤가 왜 못 가는가
셋 다 방향이 있어야만 답할 수 있는 질문이다. 무엇을 포기할지는 어디로 가는지를 알아야 정해지고, 끝났다는 판정도 그 방향에 얼마나 다가갔는지로만 내릴 수 있다. 답이 없는 문서는 로드맵이 아니라 과제 재고 목록이고, 재고 목록은 우선순위를 만들지 못한다. 우선순위가 없으면 모든 것이 P1이 되며, 모든 것이 P1이면 조직은 가장 목소리 큰 순서로 움직인다.
그래서 판을 다시 짰다. 바꾼 것은 항목이 아니라 문서의 축이다.
0. 방향 한 줄을 먼저 세웠다
과제를 손대기 전에 한 문장을 먼저 확정했다.
구축 도구에서, 운영 플랫폼으로. 판매자가 쉽게 시작하고 → 첫 주문을 만들고 → 반복 운영하고 → 유료로 전환하는 흐름을 하나로 잇는다.
한 문장이라 시시해 보이지만, 이 줄이 있고 없고에 따라 아래 서른 개의 성격이 통째로 바뀐다. 이 줄이 있으면 모든 과제가 **"이 흐름의 어느 마디를 잇는가"**로 평가된다. 잇는 마디가 없는 과제는 아무리 잘 만들어도 이번 반기에 있을 이유가 없다.
이 줄을 세우면서 같이 버린 것이 있다. 기능 경쟁이다.
경쟁사가 무엇을 냈는지로 다음 과제를 정하면 로드맵은 대응 목록이 된다. 대응 목록에는 방향이 없다. 우리가 확인한 것은 경쟁사마다 강한 축이 이미 분명하다는 것이었고, 그 축을 각각 따라가서 이길 수 있는 자리가 아니었다. 우리가 노릴 자리는 축 사이에서 끊기는 구간이었다. 그래서 문서에 이렇게 못박았다.
기능 수로 겨루지 않는다. 끊긴 운영 흐름을 잇는다.
이건 겸손한 표현이 아니라 범위 선언이다. 이 줄이 있으면 "저기도 저거 하던데요"가 들어올 때 문서를 가리키며 아니라고 말할 수 있다. 없으면 매번 회의에서 다시 싸운다.
1. 과제 단위로만 보면 반드시 지엽적이 된다
방향을 세운 다음 제일 먼저 경계한 것이 이것이다.
과제 단위로 관리하면 각 팀은 자기 과제를 잘 끝내는 데 최적화된다. 그건 성실한 태도이고, 대부분의 조직에서 실제로 그렇게 한다. 문제는 그 합이 제품이 되지 않는다는 것이다.
전부 제때 끝났는데 고객은 여전히 같은 자리에서 막히는 일이 생긴다. 개별 과제는 전부 성공이고 전체는 실패다. 원인은 실력이 아니라 보는 단위에 있다. 과제만 보면 시야가 자기 칸에 갇히고, 칸과 칸 사이는 아무도 안 본다. 사고는 늘 칸 안이 아니라 칸 사이에서 난다.
그래서 이 문서에서는 과제를 일의 단위로는 쓰되, 판단의 단위로는 쓰지 않기로 했다. 판단의 단위는 고객이 통과하는 구간이다.
같은 이유로 회의에서 쓰는 질문도 바꿨다.
| 지엽적으로 만드는 질문 | 방향으로 되돌리는 질문 |
|---|---|
| 그 기능 언제 나와요 | 그게 나오면 고객이 어디까지 가나요 |
| 이번 스프린트 몇 개 했어요 | 어느 구간의 막힘이 줄었나요 |
| 저쪽은 이거 있던데요 | 그게 우리 흐름의 어느 마디인가요 |
왼쪽 질문에는 늘 답이 나온다. 답이 나오기 때문에 일하고 있다는 착각이 유지된다. 오른쪽 질문은 자주 답이 막히는데, 막히는 그 자리가 실제로 문제인 자리다.
2. 단위를 기능에서 "고객 상태 전이"로 바꿨다
과제를 부서가 아니라 고객이 통과하는 구간으로 다시 묶었다. 유입·가입 → 첫 운영·주문 → 반복 운영 → 수익화 → 확장.
이렇게 묶으면 칸 하나가 새로 생긴다. "다음 단계에 넘기는 것" 이다. 이 칸이 이 문서에서 가장 많은 일을 한다. 칸 사이를 아무도 안 보던 문제를, 칸 사이를 문서의 항목으로 만들어 푼 것이다.
앞 구간이 만드는 산출물은 기능만이 아니다. 정책·데이터 규격·운영 기준도 같이 만들고, 그것이 뒤 구간의 입력값이 된다. 고객 타입과 권한 체계가 확정되지 않으면 뒤의 고객관리도 청구도 착수 자체가 불가능하다. 인력을 더 넣어도 안 된다. 리소스가 모자란 게 아니라 결정을 기다리는 중이기 때문이다.
이걸 구분하지 않으면 매번 같은 회의를 한다. "왜 안 끝났죠"에 "사람이 없어서요"로 답하고, 사람을 넣어도 그대로다.
의존성은 날짜가 아니라 산출물로 건다. "11월에 시작"은 일정 선언이고, "타입·권한 규격이 확정되면 시작"은 계약이다. 앞엣것은 지켜지지 않아도 아무 일이 안 일어나고, 뒤엣것은 안 지켜지면 그 자리에서 드러난다.
3. 성과 정의를 완료율에서 통과율로 바꿨다
구간을 나눈 다음, 고객이 실제로 통과하는 지점을 셌다. 여섯 개가 나왔다.
기능은 완료/미완료의 이진값이지만, 관문은 통과율로만 말할 수 있다. 그래서 성과 정의를 이렇게 바꿨다.
프로젝트의 성과는 기능 완료가 아니라, 다음 관문으로 넘어간 고객 비율이다.
정의 하나를 바꾸면 시야의 크기가 바뀐다. 완료율은 내 칸 안에서 답할 수 있는 숫자다. 통과율은 앞뒤 칸이 같이 움직여야만 오른다. 지표를 이렇게 잡으면 지엽적으로 일하는 것이 지표상 유리하지 않게 된다. 사람의 태도를 고치는 것보다 이 편이 확실하다.
실질적 이득이 하나 더 있다. 관문 통과율은 선행지표이고 매출은 후행지표다. 후행지표만 보면서 분기를 운영하면 결과가 나왔을 때는 이미 조향할 시점이 지나 있다.
다만 이 모델이 모든 제품에 듣지는 않는다. 여정이 하나로 수렴하는 제품에서만 관문이 선형으로 정리된다. 페르소나마다 다른 여정을 타면 관문이 갈라지고, 그때는 관문 하나에 통과율 하나가 아니라 세그먼트별 통과율로 봐야 한다. 우리도 파트너·에이전시 축은 이 여정에 안 들어와서 따로 뺐다.
4. 목표값보다 계측이 선행한다
관문을 세면 다음 질문이 자동으로 온다. 지금 몇 명이 그 관문을 통과하고 있나.
그 숫자가 없었다. 없는 상태에서 목표를 정하면 목표가 아니라 협상 결과가 된다. 그래서 목표값을 정하기 전에 무엇을 계측할지부터 확정했다.
순서를 지켰다. 이벤트를 심는다 → 기준선을 잰다 → 그다음에 목표를 정한다.
3번을 먼저 하는 조직이 많다. 그러면 두 가지가 동시에 망가진다. 목표 수치가 방어의 대상이 되어 아무도 하향 조정을 제안하지 못하고, 기준선이 없으니 달성하든 못 하든 무엇이 원인이었는지 사후에 분리되지 않는다. 개선을 증명할 방법이 없는 목표는 관리 도구가 아니다.
그래서 문서의 모든 숫자를 출발 가설로 명시하고, 기준선 측정 후 조정한다고 못박았다. 이 한 줄이 실제로 값을 했다. 숫자를 방어할 필요가 없어지니 숫자를 정직하게 다시 놓을 수 있었다.
5. 게이트는 단계당 하나
가장 논쟁이 길었던 지점이다. 다음 단계를 열어도 되는지 무엇으로 판정하는가.
처음엔 단계마다 점검 항목을 열 개씩 달았다. 아무도 안 봤다. 열 개를 동시에 만족하는 시점은 오지 않고, 여덟 개쯤에서 "그래서 연 건가 만 건가"로 회의가 한 번 더 생긴다. 다지표 게이트는 게이트가 아니라 판정 유예 장치다.
그래서 단계당 대표 지표를 하나로 줄였다.
여기서 중요한 건 지표를 줄였다는 사실이 아니라, 판정 기준이 과제 완료가 아니라 방향 진척이라는 점이다. "과제 네 개가 끝났다"로는 다음 단계를 못 연다. "고객이 스스로 첫 주문까지 간다"여야 연다. 게이트를 이렇게 걸면 과제를 다 끝내고도 단계가 안 열리는 상황이 정상적으로 발생하는데, 그 상황이야말로 문서가 제 일을 하고 있다는 신호다.
작성 순서에서 배운 것도 하나 있다. "끝났다"를 먼저 문장으로 쓰면 지표가 따라 나온다. "열린 상태가 흔들리지 않는다"를 쓰면 장애 건수가 나오고, "스스로 첫 주문까지 도달한다"를 쓰면 가입 후 N일 내 첫 주문 비율이 나온다. 반대로 지표부터 고르면 재기 쉬운 것을 고르게 되는데, 재기 쉬운 것과 중요한 것은 대체로 다르다.
단일 게이트의 대가는 게이밍 위험이다. 지표가 하나면 그 하나만 맞추는 방향으로 일이 굽는다. 그래서 점검 항목을 없애지는 않았다. 옆에 남기되 통과 조건으로 쓰지 않는다고 명시했다. 판정은 하나로, 관찰은 여러 개로. 둘을 섞는 순간 앞의 문제가 돌아온다.
마지막 칸은 비웠다. "아직 정의하지 않는다". 앞 단계 결과를 보고 정하겠다는 뜻이다. 미정을 미정이라고 적는 편이 그럴듯한 숫자를 채우는 것보다 낫다. 다만 언제 누가 정할지는 같이 적었다. 그게 없으면 미정이 아니라 방치다.
6. 조직 인터페이스를 문서로 고정했다
하나의 과제는 한 부서에서 끝나지 않는다. 단계마다 책임자가 바뀐다.
이 표의 목적은 R&R 분장이 아니다. 인계 계약이다. 각 칸은 "이 팀이 이 단계에서 무엇을 받아 무엇을 넘기는가"를 적은 것이고, 표를 채우다 보면 비는 칸이 보인다.
그 빈칸이 사고가 나던 자리와 정확히 겹쳤다. 기획이 정책을 확정했는데 고객지원이 그 기준을 못 받은 자리, 개발이 데이터를 쌓는데 마케팅이 그 존재를 모르던 자리. 둘 다 누구의 잘못도 아니었다. 인계 지점이 문서에 없었을 뿐이다. 각자 자기 칸만 보고 있었으니 보일 리가 없다.
같은 프로젝트 이름을 공유하는 것보다, 같은 인계 기준을 공유해야 전사가 같은 순서로 움직인다.
프로젝트 이름은 모두가 알고 있었다. 모르던 것은 "내가 다음 사람에게 무엇을 넘겨야 하는가"였다.
이 구조가 해결하지 못하는 것
정직하게 적어 둔다.
순서를 정해도 용량 문제는 안 풀린다. 이 문서는 "무엇을 먼저"에는 답하지만 "동시에 몇 개까지"에는 답하지 않는다. 그건 WIP 상한을 따로 걸어야 하는 문제다.
가장 큰 리스크는 개발이 아니라 의사결정이었다. 가격·권한·과금·환불 기준이 서기 전에는 청구 시스템을 만들 수가 없다. 이건 일정 문제가 아니라 결정 부채고, 로드맵 문서로는 못 갚는다. 그래서 별도로 판정일과 책임자를 박아 뒀다.
게이트는 조직이 지킬 때만 게이트다. 판정 기준을 아무리 잘 써도, 한 번 "이번만 예외로"가 통과하면 그다음부터는 기준이 아니라 참고 자료가 된다.
그리고 방향은 한 번 쓴다고 유지되지 않는다. 문서를 덮는 순간부터 조직은 다시 과제 단위로 돌아가려 한다. 그게 훨씬 편하기 때문이다. 방향을 지키는 일은 문서를 잘 쓰는 일이 아니라 회의마다 같은 질문을 반복하는 일에 가깝다.
남긴 다섯 가지
- 방향이 과제에 선행한다. 어디로 가는지를 한 문장으로 못 쓰면, 과제 목록은 아무리 길어도 로드맵이 아니다.
- 과제는 고객 흐름 순서로 연결한다. 개발은 겹쳐도 되지만, 여는 것은 앞 단계 인계 기준을 확인한 뒤 결정한다.
- 무엇을 얼마에 팔지 먼저 정한다. 상품·가격·권한·과금·환불 기준이 청구 개발에 선행한다.
- 목표값보다 계측과 기준선이 먼저다. 기준선 없는 목표는 관리 도구가 아니다.
- 미정도 책임자와 판정일을 적는다. "미정"은 괜찮다. "언제 정할지도 미정"이 문제다.
로드맵을 일정 약속으로 쓰면 반기마다 틀린다. 실제로 늘 틀렸다.
지금 이 문서에 기대하는 역할은 다르다. 우리가 무엇이 되려 하는지, 그러려면 무엇을 먼저 해야 하는지, 무엇이 준비되어야 다음으로 넘어가는지를 여러 팀이 같은 그림으로 보는 것.
방향이 먼저다. 그다음이 순서고, 일정은 그 결과다. 이 순서를 거꾸로 밟으면, 일정부터 맞추고 순서를 끼워 넣고 방향을 나중에 붙이면, 맞춘 것은 일정뿐이다.