제품 로드맵 계획: 5단계, 3개의 시간 지평, 그리고 템플릿

최종 업데이트: 2026년 9월 15일

로드맵은 만들어진 그날 아침에는 정확했습니다. 출시 2주 차가 되자 한 기능은 조용히 규모가 두 배로 커졌고, 두 기능은 아무도 기록해두지 않은 결정을 기다리고 있었지만, 슬라이드는 여전히 다섯 개 모두 같은 줄에 나란히 도착하는 것처럼 보여주고 있었습니다.

아무도 거짓말을 하지 않았습니다. 단지 그 문서는 무언가가 바뀌었다는 사실을 알아낼 방법 자체가 없을 뿐입니다.

좋은 제품 로드맵 계획이란 더 나은 슬라이드가 아닙니다. 계획과 실제 업무 사이의 간격을 좁혀서, 다른 모든 사람이 무언가를 알게 될 때 계획도 함께 그것을 알게 만드는 일입니다. 아래에서는 그 간격이 숨어 있는 다섯 단계, 우선순위 논쟁을 정직하게 진행하는 방법, 그리고 이 구조를 그대로 가져다 쓸 수 있는 실제 작동하는 Quire 프로젝트를 다룹니다.

제품 로드맵 계획이란 무엇인가요?

제품 로드맵 계획이란 제품이 무엇을 대략 어떤 순서로 출시할지 결정하고, 그 순서를 실제로 그 결과물을 만들어내는 업무와 계속 연결해 두는 일입니다. 앞부분은 가치에 관한 논쟁입니다. 뒷부분은 배관 작업 같은 것이며, 6주 후에도 그 논쟁이 여전히 의미가 있을지를 결정하는 것은 바로 이 뒷부분입니다.

대부분의 조언은 앞부분에서 멈춥니다. 우선순위 프레임워크, 이해관계자용 템플릿, 테마 대 기능 논쟁이 전부입니다. 모두 유용하지만, 실제로 문제가 터지는 지점은 건드리지 않습니다.

제품 로드맵은 왜 현실과 어긋나기 시작할까요?

로드맵이 어긋나는 이유는 그것이 설명하는 업무와 별도로 저장되기 때문입니다. 산출물은 두 개, 진실은 하나, 그런데 그 둘을 일치시킬 장치가 없습니다. 그래서 둘은 약 일주일 정도만 일치합니다.

이 간격은 정확히 세 가지 대가를 치르게 만듭니다.

정직한 답변을 잃게 합니다. 누군가 다음에 무엇이 나오는지 물으면, 답을 아는 사람은 다섯 명에게 물어보고 답변을 모아 슬라이드를 다시 만들어야 합니다. 발표될 즈음에는 이미 지난 목요일 상황을 설명하고 있는 셈입니다.

결정의 흔적을 잃게 합니다. 한 기능이 늦어지고 로드맵은 새 날짜를 보여주지만, 누가 그 결정을 내렸는지, 공간을 확보하기 위해 무엇을 뺐는지는 아무 데도 기록되지 않습니다.

예측력을 잃게 합니다. Kevin Thomas와 Cornelius König이 Frontiers in Psychology에 기고한 연구에 따르면, 예측자가 이전에 이미 끝낸 업무와 비슷한 작업일수록 기간 예측이 실제와 더 가까웠습니다.

여러분이 직접 출시해 온 이력이야말로 가장 좋은 견적 도구입니다. 출시가 끝나는 순간 그것을 보관해 버리는 로드맵은 매 분기 그 자산을 그대로 버리는 셈입니다.

한동안 Quire에서도 스프레드시트로 출시를 운영했습니다. 누군가 회의 없이는 답할 수 없는 질문을 던지기 전까지는 그럭저럭 굴러갔습니다.

이 문제의 보고 쪽 절반에는 별도의 해법이 있습니다. 상태 회의 없이 이해관계자에게 업데이트하는 방법은 누군가의 기억이 아니라 실제 업무에서 곧바로 뽑아내는 비동기 패턴을 다룹니다.

아이디어에서 출시까지 다섯 단계는 무엇인가요?

하나의 기능은 인테이크, 트리아지, 스코핑, 빌드, 출시를 거치지만, 일반적인 로드맵은 마지막 두 단계만 보여줍니다. 차트를 그리기에는 충분하지만 한 분기를 설명하기에는 턱없이 부족합니다. 흥미로운 일은 전부 아무 흔적도 남기지 않는 세 단계에서 일어나기 때문입니다.

그러니 기능이 실제로 머무는 다섯 곳과, 한 단계를 건너뛰지 않고 그냥 지나갔을 때 나중에 청구되는 비용을 살펴보겠습니다. 아래 각 단계는 Quire의 제품 로드맵 템플릿에서 어디에 해당하는지 함께 표시했으며, 이 템플릿은 이 글 뒷부분에서 전체를 열어 보여드립니다.

• 1. 인테이크는 Idea intake 섹션에 있습니다. 이 단계를 건너뛰면 요청은 다이렉트 메시지 속에 머물다가 6개월 후 불만으로 돌아옵니다.
• 2. 트리아지는 Later로 가거나 종료됩니다. 이 단계를 건너뛰면 목록이 계속 불어나 아무도 신뢰하지 않게 되고, 결국 모두가 조용히 각자의 개인 목록을 따로 유지하게 됩니다.
• 3. 스코핑은 Next에서 상태 Scoped로 존재합니다. 이 단계를 건너뛰면 엔지니어링이 티켓을 열면서, 여러분이 미뤄둔 결정을 그 주의 자기 일정 안으로 그대로 물려받게 됩니다.
• 4. 빌드는 Now에서 하위 업무와 함께 이루어집니다. 이 중첩 구조를 건너뛰면 불투명한 항목 하나가 2주 동안 80% 완료로 표시되면서도 아무도 그 이유를 말할 수 없게 됩니다.
• 5. 출시는 Ship checklist 하위 목록으로 진행됩니다. 이 단계를 건너뛰면 지원팀이 존재조차 모르는 상태에서 고객이 먼저 그 기능을 만나게 됩니다.

어떤 단계가 흔적을 남기는지 주목하세요. 일반적인 로드맵에는 마지막 두 단계만 나타납니다. 처음 세 단계는 받은 편지함과 복도 대화 속에서 일어나기 때문에, 차트는 항상 그 분기가 실제로 느껴졌던 것보다 더 평온해 보입니다.

제품 로드맵과 백로그의 차이는 무엇인가요?

백로그는 아직 순서가 정해지지 않은, 할 수도 있는 모든 일입니다. 로드맵은 그중 대략적인 시기와 함께 이미 커밋한 작은 부분입니다. 팀들이 곤란해지는 이유는 하나의 목록만 유지하면서 그것을 둘 다라고 부르기 때문입니다. 그러면 목록 안의 모든 아이디어가 마치 약속처럼 읽히게 됩니다.

이 둘은 하나의 프로젝트 안에, 서로 다른 섹션에 두세요. 같은 업무, 같은 필드, 다른 의미입니다.

여기서 얻는 유용한 결과는 승격이 하나의 사건이 된다는 점입니다. 업무를 Later에서 Next로 옮기는 것은 아무도 보지 않는 사이 위로 스르르 올라간 항목이 아니라, 특정 날짜에 누군가가 내린 결정입니다.

그 후보 목록을 무덤이 아니라 계속 쓸 수 있는 상태로 유지하는 방법: 제품 백로그가 전체 이야기를 들려주게 만드는 방법.

Quire의 제품 로드맵 템플릿에는 무엇이 들어 있나요?

다섯 단계가 이미 배선되어 있는, 어떤 요금제에서도 무료로 복사할 수 있는 실제 작동 프로젝트입니다. 샘플 데이터는 가상의 v2.0 출시 버전이므로, 여러분의 데이터로 교체하기 전에 이 구조가 실제로 작동하는 모습을 먼저 확인할 수 있습니다.

빈 프로젝트에서 이걸 처음부터 만드는 대신 Quire의 제품 로드맵 템플릿을 사용하세요. 여덟 가지가 함께 제공됩니다.

• 세 개의 시간 지평 섹션과 인테이크 섹션 하나. Now는 실제 날짜가 있는 현재 출시 버전, Next는 대략적인 형태로 정리된 다음 버전, Later는 날짜가 없는 후보들이며, Idea intake는 아직 아무것도 약속되지 않은 미분류 요청입니다.
• 5단계 상태 파이프라인: Idea, Scoped, In Progress, In Review, Shipped. Scoped가 별도로 존재하는 이유는, "아직 시작 안 함"과 "이것이 무엇인지 아무도 결정하지 않음"이 서로 다른 문제이기 때문입니다.
• 여섯 개의 로드맵 필드: Release, Impact, Effort, Customer requests, Source, 그리고 Needs release note 체크박스.
• 실제 업무로 이어지는 기능들. Notifications center는 하나의 할 일이 아닙니다. 스펙, 디자인, 패널 빌드, 음소거 설정, 다이제스트 이메일까지 각각 담당자와 일정이 정해져 있습니다.
• 마일스톤 형태의 출시 게이트: feature freeze, code freeze, GA가 의존 관계로 연결되어 있어, 반드시 지켜야 할 순서가 눈에 보입니다.
• 트리 전체를 가로지르는 세 개의 하위 목록: 현재 출시 버전, 특정 고객에게 약속된 모든 항목, 그리고 출시 체크리스트.
• How we prioritize 문서, 항목에 대해 의견이 갈릴 때마다 방법론을 다시 논쟁하지 않도록 기준을 한 번만 적어둔 것입니다.
• 두 개의 업무 보고 탭: 주간 점검용 대시보드, 그리고 담당자별 예상 시간을 합산해 이 출시 버전이 배정된 인원에 맞는지 물어볼 수 있는 Effort by owner.

중첩 구조는 기능이 2주 동안 80% 완료 상태로 멈춰 있는 것을 막아주는 장치입니다. Notifications center가 담당자가 정해진 다섯 개의 하위 업무일 때, "80%"는 "다이제스트 이메일은 아직 시작 안 했고 Ana가 맡고 있다"로 바뀝니다.

나머지 부분을 건드리지 않더라도 출시 체크리스트만큼은 그대로 가져다 쓰세요. 각각 담당자가 지정된 일곱 개의 질문이 있고, 이들이 모두 답변되기 전까지는 GA 마일스톤이 닫히지 않습니다.

1. 출시 버전에 포함된 모든 기능이 Shipped 상태이거나, 명시적으로 제외되어 다음 버전으로 이동됨.
2. Needs release note가 체크된 모든 항목에 대해 출시 노트가 작성됨.
3. 변경된 모든 영역에 대해 문서와 API 레퍼런스가 갱신됨.
4. 지원팀이 브리핑됨: 알려진 이슈, 우회 방법, 에스컬레이션 기준.
5. 마이그레이션이 프로덕션 데이터 사본에서 테스트되고 롤백이 리허설됨.
6. 출시 대상 코호트에 맞춰 기능 플래그가 설정되고 기본값이 확인됨.
7. 상태 페이지 공지와 인앱 변경 로그가 출시 시각에 맞춰 예약됨.

다섯 번째 항목은 "문서화됨"이 아니라 "리허설됨"이라고 말합니다. 아무도 실행해보지 않은 롤백 계획은 파일명만 있는 바람일 뿐입니다.

사본 생성하기는 프로젝트 전체에 작동하므로, 트리 구조가 업무 하나씩이 아니라 통째로 그대로 넘어옵니다. 템플릿 제목 옆 드롭다운에서 More를 열고 사본 생성하기를 선택하세요.

사본에 이름을 붙이고, 소속될 조직을 선택한 뒤 Create를 누르세요. 1분 정도면 모든 단계의 중첩 구조까지 함께 넘어오며, 이것이 바로 다시 만드는 것보다 복사하는 편이 더 나은 유일한 이유입니다.

그다음에는 가차 없이 정리하세요. 구조 자체가 유용한 부분이고, 샘플 기능들은 단순한 뼈대일 뿐이며, 그대로 남겨두는 항목 하나하나가 나중에 11월쯤 되면 왠지 모르게 찜찜하게 느껴질 존재가 됩니다.

다음 출시 버전에 무엇을 넣을지는 어떻게 결정하나요?

가치와 비용을 비교하고, 그 근거를 하나로 뭉개버리지 말고 화면에 그대로 남겨두세요. 우선순위 정하기는 예측 가능한 방식으로 잘못됩니다. 누군가 점수 계산식을 만들고, 그 계산식이 7.4라는 숫자를 뱉어내면, 모두가 그 숫자에 고개를 끄덕이지만 사실 그 숫자는 해결해야 할 이견을 해결한 게 아니라 조용히 묻어버린 것뿐입니다.

입력값은 분리해서 눈에 보이게 두세요. 템플릿에서는 모든 후보에 세 개의 필드가 붙습니다.

• Impact: 가치가 얼마나 되는지, High, Medium, Low.
• Effort: 대략적인 S부터 XL까지.
• Customer requests: 실제로 요청한 사람 수.

Impact 기준으로 정렬하고, 그 옆에서 Effort를 확인하고, 요청 수가 가장 목소리 큰 사람의 의견만 반영되지 않도록 막아주게 하세요.

그런 다음 모두를 놀라게 하는 불일치를 찾아보세요. 샘플 데이터에서 Dark mode는 47건의 고객 요청과 함께 출시됐지만 Impact는 Low였습니다.

그래도 여전히 타당한 결정이었습니다. 비용이 저렴했고 반복되는 불만 하나를 없애줬기 때문입니다. 하지만 아무도 그것을 성장을 위한 베팅이라고 착각해서는 안 됩니다. 목록에서 가장 많이 요청받은 항목이 가장 가치 있는 항목은 아닌 경우가 많으며, 단일 종합 점수야말로 바로 그 사실을 숨겨버렸을 도구입니다.

이것이 바로 테이블 뷰입니다. 같은 업무, 여섯 개의 정렬 가능한 열, 별도로 내보낼 것도 없습니다.

Now에 무언가를 넣기 전에 세 가지를 확인하세요. Scoped 상태인가? code freeze 이전에 도착하는가, GA 주간이 아니라? 담당자가 팀이 아니라 이름이 지정된 한 사람인가? 빽빽한 Now는 Now가 없는 것과 다를 바 없습니다.

거절도 이 과정의 절반입니다. 무언가를 Idea에 영원히 방치하는 것은 아무도 소리 내어 말하지 않은 거절입니다. 한 줄짜리 이유와 함께 Later로 옮기거나, 아예 종료하세요. 예외는 Customer-committed 하위 목록입니다. 누군가 특정 고객에게 약속한 것은 이곳에 살아 있으므로, 그것을 빼는 일은 밤 11시의 조용한 수정이 아니라 하나의 논의 거리가 됩니다.

팀이 가장 자주 논쟁하는 열 가지 후보로 직접 시도해보세요. 무료 Quire 프로젝트에서 Impact와 Effort로 점수를 매기고 정렬하세요. 보통 열 개 중 여덟 개는 저절로 정리되고, 회의는 원래부터 진짜 논쟁거리였던 두 개로 줄어듭니다.

로드맵만 보고 "무엇이 언제 나오나요?"라는 질문에 어떻게 답하나요?

시간 지평, 마일스톤, 상태를 그대로 읽으면 됩니다. 이 세 가지 모두 이미 각자 자기 일을 하는 사람들이 관리해주고 있기 때문입니다. 이것이 바로 슬라이드가 존재하는 이유였던 질문이고, 그 슬라이드가 계속 낡아버렸던 이유이기도 합니다.

시간 지평은 대략 언제인지를 답합니다. Now에 날짜가 있는 이유는 업무가 범위가 정해지고 담당자가 있기 때문입니다. Next는 출시 버전은 있지만 일 단위의 정밀함은 없습니다. Later는 의도적으로 둘 다 없습니다. 정돈되어 보이려고 Later에 날짜를 붙이는 것은 여러분이 절대 동의한 적 없는 약속을 스스로 떠안는 방법입니다.

마일스톤은 먼저 무엇이 참이어야 하는지를 답합니다. Feature freeze, code freeze, GA는 문서 속 문장이 아니라 타임라인 위에서 서로 의존 관계로 연결된 실제 객체입니다. 기능 하나가 freeze를 넘겨 지연되면, 타임라인이 그것이 무엇과 충돌하는지 보여줍니다.

상태는 지금 무슨 일이 일어나고 있는지를 답합니다. In Review는 In Progress와 다르게 보이고, In Progress는 Idea와도 다르게 보입니다. 엔지니어가 상태를 바꾸는 것은 자기 일을 하는 과정에서 부수적으로 로드맵을 갱신하는 셈이며, 이것이야말로 항상 최신 상태를 유지하는 유일한 종류의 보고입니다.

대시보드는 로드맵을 절대 열어보지 않을 사람들을 위해 답해줍니다. 여기서 특히 제 몫을 하는 위젯이 두 개 있습니다.

Tasks Created vs. Completed는 업무가 들어오는 속도와 빠져나가는 속도를 나란히 보여줍니다. 이것이 출시 버전이 진행되고 있는 게 아니라 부풀어 오르고 있다는 사실을 가장 먼저 정직하게 알려주는 신호입니다.

차단된 업무는 정체된 항목 하나하나를 그것을 막고 있는 원인과 함께 짝지어 보여주므로, 로드맵 검토 때마다 늘 나오는 질문에 이미 답이 나와 있는 셈입니다.

템플릿 안에서 출시된 각 기능은 예상했던 소요 시간과 실제 소요 시간도 함께 기록합니다. 그 패턴은 위에서 소개한 연구가 예측한 그대로입니다. 팀이 예전에 만들어본 적 있는 것과 비슷한 업무는 예상에 가깝게 끝났고, 정말로 새로운 업무는 3분의 1가량 초과했습니다.

이 아래에 깔린 두 가지 메커니즘은 따로 읽어볼 가치가 있습니다: Quire에서 마일스톤이 작동하는 방식과 업무 의존 관계가 작업을 연결하는 방식이며, 이것이 바로 지연된 freeze를 이론이 아니라 눈에 보이게 만들어주는 장치입니다.

제품 로드맵 계획은 업무 관리 소프트웨어 안에 있어야 하나요?

네, 그리고 그 판단 기준은 엔지니어가 티켓을 닫을 때 아무도 요청하지 않아도 로드맵이 함께 갱신되는지입니다. 답이 아니라면, 여러분은 두 개의 문서를 관리하며 결국 언젠가는 그만두게 될 주간 조정 습관까지 떠안게 됩니다.

슬라이드 소프트웨어와 전용 로드맵 도구 모두 깔끔한 그림을 만들어냅니다. 하지만 둘 다 패널 빌드가 지연됐다는 사실을 말해줄 수 없습니다. 그 패널 빌드 자체를 담고 있지 않기 때문입니다. 로드맵을 팀이 이미 사용 중인 업무 관리 소프트웨어 안에 두면 복사본이 사라지고, 그와 함께 어긋남도 사라집니다.

아직 그 도구를 고르는 중이라면 이 글이 전체 시장을 훑어줍니다: 최고의 업무 관리 소프트웨어와 트래커, 중첩 업무를 어떻게 다루는지 기준으로 비교했습니다.

이 구조가 맞지 않는 경우도 하나 있는데, 짚고 넘어갈 가치가 있습니다. 아직 제품이 어떤 모습이어야 할지 찾고 있는 팀은 후보는 있지만 커밋된 출시 버전은 없습니다. Now 시간 지평을 열고 날짜를 붙이는 것은 아무도 하지 않은 약속을 만들어내는 일입니다.

무언가가 정말로 범위가 정해지고 담당자가 배정될 때까지는 Later와 Idea intake만 운영하고, 그 주가 되어서야 Now를 여세요. 시간 지평은 커밋된 것을 담기 위한 장치이지, 가득 차 보이려고 있는 게 아닙니다.

이 템플릿은 하나의 세트 중 일부입니다. 나머지는 팀이 실제로 쓰게 될 프로젝트 관리 템플릿 모음에 있으며, 출시, 상태 보고, 리스크용 템플릿도 포함되어 있습니다.

사본을 만들면 무엇부터 바꿔야 하나요?

날짜부터 시작하세요. 나머지 모든 것이 여기에 매달려 있기 때문입니다. 출시 버전 이름을 바꾸고 세 개의 게이트를 여러분의 날짜로 옮기세요.

그다음 샘플 기능들을 실제 기능으로 교체하되, 각각에 팀이 아니라 담당자 한 명을 붙이세요.

마지막으로, 절대 만들어지지 않을 것이라고 개인적으로 확신하는 항목은 잘라내세요. 로드맵은 그 안의 모든 항목이 여전히 사실일 때만 계속 유용합니다.

핵심 요약

로드맵이 낡아버리는 이유는 업무가 닿을 수 없는 곳에서 살고 있기 때문입니다. 각 항목을 실제 업무로 만들면 대부분의 어긋남이 멈춥니다.

즉, 계획됨-완료됨 대신 다섯 단계, 날조된 날짜 대신 세 개의 시간 지평, 의존 관계가 걸린 마일스톤 형태의 출시 게이트, 그리고 점수 뒤에 근거를 숨기지 않고 그대로 보여주는 우선순위 필드가 필요합니다.

이 중 어느 것도 처음부터 만들 필요가 없습니다. 제품 로드맵 템플릿의 사본을 만들고, 후보에 점수를 매기고, Now를 짧게 유지하세요. 그러면 구조가 이미 그 일을 하고 있을 것입니다.

Quire에 가입하기를 하면 업무가 이미 살고 있는 바로 그곳에서 로드맵을 운영할 수 있으므로, 다음에 누군가 무엇이 나올지 물을 때 답은 저녁 시간 통째가 아니라 링크 하나면 됩니다.

자주 묻는 질문

제품 로드맵 계획이란 무엇인가요?

무엇을 대략 어떤 순서로 출시할지 결정하고, 각 약속 뒤의 작업 내용을 보여줄 수 있는 것입니다. Quire의 제품 로드맵 템플릿에서는 모든 항목이 담당자, 출시 버전, 그 아래 중첩된 업무를 갖춘 실제 업무이므로 계획과 실행이 조용히 어긋날 수 없습니다.

제품 로드맵과 백로그의 차이는 무엇인가요?

백로그는 할 수도 있는 모든 일입니다. 로드맵은 대략적인 시기와 함께 이미 커밋한 부분입니다. 템플릿은 이 둘을 하나의 프로젝트 안에, 서로 다른 섹션에 담습니다.

제품 로드맵은 얼마나 먼 미래까지 다뤄야 하나요?

현재 출시 버전에는 실제 날짜를, 다음 버전에는 대략적인 형태를, 그 이후에는 아무 날짜도 부여하지 마세요. Now, Next, Later가 바로 이 목적을 위한 것입니다. 슬라이드를 채우려고 지어낸 날짜는 나중에 그대로 책임지게 되는 날짜이기 때문입니다.

제품 로드맵의 우선순위는 어떻게 정하나요?

가치와 비용을 비교하고, 그 근거를 둘 다 나란히 남겨두세요. Quire의 템플릿은 Impact, Effort, Customer requests를 정렬 가능한 테이블 뷰 열로 제공하며, 의도적으로 하나의 점수로 뭉개지 않습니다. 단일 숫자는 짚고 넘어갈 가치가 있는 이견을 숨기기 때문입니다.

로드맵은 업무를 관리하는 도구와 같은 곳에 있어야 하나요?

네, 그렇지 않으면 두 개의 진실을 각각 유지하며 수작업으로 맞춰야 합니다. 엔지니어들이 이미 사용 중인 업무 관리 소프트웨어에 로드맵을 두세요. 그러면 상태 변경만으로 아무도 별도의 문서를 건드리지 않아도 로드맵이 갱신됩니다.

이 로드맵 구조가 통하지 않는 경우는 언제인가요?

아직 진정으로 커밋된 것이 없을 때입니다. 제품의 형태를 아직 찾고 있는 팀은 후보만 있고 출시 버전은 없으므로, 날짜가 붙은 Now 구간은 약속을 지어내는 셈이 됩니다. 무언가가 범위가 정해지고 담당자가 배정될 때까지는 Later와 Idea intake만 운영하세요.

이런 방식으로 로드맵을 계획하면 팀이 업무 시간을 더 생산적으로 쓰는 데 어떻게 도움이 되나요?

보고라는 계층 자체를 삭제해줍니다. 매주 슬라이드를 다시 만들 필요도, 이해관계자 미팅 전에 여섯 명을 쫓아다닐 필요도, 이미 결정된 것을 다시 물을 필요도 없습니다. 로드맵과 게이트, 실제 업무가 하나의 Quire 프로젝트 안에 모여 있으면, 그 시간은 업무를 설명하는 대신 업무 시간을 생산적으로 쓰는 데 쓰이게 됩니다.