타임라인 로드맵

Timeline Roadmap

산출물

분기나 월로 칸을 만들고 그 안에 만들 것의 이름을 넣어, 다른 팀이 자기 일정을 맞출 수 있게 그린 계획표입니다.

등장 배경

제품 팀 밖에서는 언제 무엇이 나오는지 알 방법이 없었습니다. 영업은 고객에게 "곧 나올 겁니다" 라고 말하고, 마케팅은 발표 준비 시점을 몰라 짐작으로 캠페인을 잡고, 고객 성공은 문의가 올 때마다 개발자에게 개별로 물었습니다. 같은 기능을 두고 회사 안에 세 가지 시점이 돌아다녔습니다.

그래서 분기 시작 회의는 이런 모양이었습니다. 마케팅이 "그 기능 언제 나와요" 하고 물으면 제품 팀이 "아마 여름쯤" 하고 답했고, 마케팅은 그 말로 6월 캠페인을 잡았습니다. 6월에 기능이 없으면 잡아 둔 예산과 준비한 자료가 버려졌습니다. 대답한 쪽은 약속한 적이 없다고 생각했고, 들은 쪽은 약속을 받았다고 생각했습니다.

타임라인 로드맵은 그 대화를 문서로 옮긴 것입니다. 달력이라는 공통 언어를 쓴다는 점이 이 형식의 값입니다. 제품 팀의 말로 적으면 밖에서 못 읽지만, 3분기 칸에 항목 이름이 들어 있으면 영업도 마케팅도 채용 담당도 거기에 자기 일정을 맞출 수 있습니다. 대신 달력은 실제보다 정확해 보입니다. 그래서 이 형식은 어디까지가 아는 것이고 어디부터가 짐작인지를 함께 표시해야 합니다.

구성 항목

가로축은 시간이고 칸의 굵기는 아는 만큼으로 정합니다. 가까운 구간은 월로 잘게, 먼 구간은 분기로 굵게 묶습니다. 아는 것이 가장 적은 4분기 항목을 1분기와 같은 정밀도로 그리면 읽는 쪽이 둘을 같은 무게로 받아들입니다.

칸 안의 항목 하나에는 다섯 가지가 붙습니다.

  1. 이름과 해결할 문제 — 이름만 적으면 왜 하는지가 사라집니다. "권한 관리" 옆에 "관리자가 외부 협력사에게 특정 문서만 열어 줄 수 없다" 를 붙여 두면 더 싸게 푸는 방법이 나왔을 때 항목을 바꿀 수 있습니다.
  2. 시기 구간 — 날짜 하나가 아니라 구간으로 적습니다. 착수도 안 한 일에 9월 18일이라고 적으면 읽는 쪽은 그 하루를 믿고 자기 일정을 겁니다.
  3. 목표와 확인 방법 — 끝났을 때 무엇이 달라져야 하고 어떤 숫자로 볼지입니다. 없으면 만들었다는 사실만 남습니다.
  4. 확신도 — 이 시기에 이대로 나올 가능성을 높음·중간·낮음으로 적습니다. 이 한 칸이 날짜를 약속으로 읽는 오해를 가장 크게 줄입니다. 4분기 항목에 낮음이 붙어 있으면 영업이 계약서에 쓰지 않습니다.
  5. 담당과 상태 — 누가 들고 있고 어디까지 왔는지입니다. 상태는 아직 안 봄, 살펴보는 중, 만드는 중 셋이면 충분합니다. 잘게 나누면 갱신하는 사람이 지쳐 아무도 손대지 않는 칸이 됩니다.

구간 중간에는 기준점을 박아 둡니다. 진척을 판정하려고 세우는 기준점을 마일스톤이라 하는데, 날짜만 적으면 소용이 없습니다. "8월 말" 이 아니라 "8월 말까지 사내 팀 다섯 곳이 권한 설정을 직접 마치는 것" 처럼 무엇이 되어 있어야 하는지를 적어야 지났는지를 말할 수 있습니다.

작성자와 독자

쓰는 사람은 제품 매니저이고 읽는 사람은 대부분 제품 팀 밖에 있습니다. 이 비대칭이 문서의 성격을 정합니다. 쓰는 쪽은 불확실한 것을 정직하게 적고 싶고, 읽는 쪽은 자기 일정을 걸 수 있는 확정된 값을 원합니다.

초안은 제품 매니저가 잡고 둘이 검토합니다. 개발 리드는 시기 구간이 현실적인지 보고, 대표는 분기 순서가 회사 방향과 맞는지 봅니다. 한정된 자원으로 무엇을 먼저 할지 정하는 우선순위 결정이 이 검토에서 일어납니다. 갱신은 2주에 한 번 상태만 고치고 분기에 한 번 칸을 다시 배치합니다.

독자마다 보는 칸이 다릅니다. 영업은 확신도부터 봅니다. 그 칸이 낮음이면 고객에게 말하지 않습니다. 마케팅은 시기 구간을 보고 준비 일정을 거꾸로 셉니다. 고객 성공은 항목 이름으로 문의에 답할 말을 찾고, 대표는 목표 칸을 봅니다.

그래서 많은 팀이 두 벌을 둡니다. 안쪽 판에는 확신도와 담당과 상태가 다 들어 있고, 밖에 보여 주는 판에는 확신도가 낮은 칸을 지우고 분기만 남깁니다. 한 벌로 버티면 밖에 못 보여 줄 내용 때문에 안쪽 판이 점점 무해해지고, 결국 아무 정보도 없는 문서가 됩니다.

실무 용례

"4분기 칸은 확신도 낮음이에요. 계약서에 쓰지 말아 주세요."

그 항목은 아직 방향일 뿐이니 고객에게 약속하지 말라는 말입니다.

"6월로 박혀 있는데 아직 착수도 안 했어요. 구간을 다시 잡아야 합니다."

문서가 현실과 벌어졌으니 갱신하자는 요청입니다.

"3분기까지만 날짜로 쓰고 그 뒤는 세 칸으로 바꿨어요."

먼 구간에는 날짜를 적지 않고 형식을 섞어 쓰기로 했다는 뜻입니다.

페이지덱은 분기가 시작될 때 지현이 이 문서를 다시 그립니다. 지난 분기에는 4분기 칸의 권한 관리 항목이 문제가 됐습니다. 확신도가 낮음이었는데 수아가 그 칸을 보고 도입을 검토하던 고객에게 연말이라고 답했고, 고객은 그 답으로 일정을 잡았습니다.

규원이 규칙을 하나 만들었습니다. 고객에게 보여 주는 판에는 확신도가 높음인 항목만 남기고 낮음은 칸째로 지웁니다. 지현이 다음 분기에 그 판을 따로 만들면서 지워진 칸은 아예 비웠습니다. 비어 있는 칸보다 회색으로 남은 칸이 더 많은 기대를 만들기 때문입니다.

흔한 오해

칸에 적힌 시기를 약속으로 읽는 일이 가장 흔합니다. 달력 위에 놓여 문서로 공유됐으니 확정된 것처럼 보입니다. 하지만 이 문서는 지금 아는 것을 적은 계획이고, 4분기 칸은 정보가 가장 적을 때 그렸습니다. 약속으로 읽히면 두 가지가 같이 일어납니다. 밖에서는 못 지킨 약속이 쌓여 신뢰가 깎이고, 안에서는 제품 팀이 먼 칸을 비워 두거나 지킬 수 있는 작은 항목만 적습니다. 그러면 문서는 안전해지지만 밖에서 일정을 맞출 수 없게 됩니다.

이 형식 자체가 낡았다고 보는 시각도 자주 나옵니다. 날짜를 박는 방식이 변화에 약하다는 비판이 널리 알려져 있으니 그렇게 들립니다. 하지만 문제는 정밀도를 아는 만큼만 표시하지 않았을 때 생깁니다. 밖에 맞출 일정이 있는 조직에는 이 형식 말고 대안이 없습니다. 하드웨어 출시나 계약된 도입 일정처럼 날짜가 먼저 정해진 일을 세 칸짜리 형식으로 전달하면 받는 쪽이 다시 날짜를 묻고, 결국 문서 밖에서 날짜가 오갑니다.

자주 헷갈리는 용어

용어가로축에 두는 것타임라인 로드맵과의 차이
나우-넥스트-레이터시급도 세 칸날짜를 쓰지 않아 뒤쪽 칸의 확신이 낮다는 사실이 형태에 드러납니다. 대신 밖에서 일정을 맞추기는 어렵습니다

같이 보면 좋은 페이지

마지막 업데이트 2026-09-16