마일스톤
Milestone
개념
계획이 제때 가고 있는지 중간에 확인하려고, 그 시점에 무엇이 되어 있어야 하는지까지 함께 못 박아 둔 기준점입니다.
등장 배경
분기 계획에는 시작과 끝만 있는 경우가 많았습니다. 1월에 "이번 분기에 권한 관리를 만든다" 고 정하고, 3월 말에 모여 됐는지 안 됐는지를 확인했습니다. 문제는 그 사이 두 달 반 동안 계획이 어떻게 가고 있는지 말할 방법이 없었다는 것입니다.
주간 회의에서 오가는 말은 대개 이랬습니다. "잘 되고 있어요." "거의 다 됐습니다." 듣는 쪽은 이 말을 반박할 근거가 없습니다. 무엇이 되어 있어야 지금 정상인지가 어디에도 적혀 있지 않으니, 남은 것은 담당자의 체감뿐입니다. 그리고 그 체감은 대체로 낙관적입니다. 만든 것이 눈에 보이고 남은 것은 아직 안 보이기 때문입니다.
페이지덱에서도 같은 일이 있었습니다. 2월 내내 순조롭다고 공유되던 과제가 3월 둘째 주에 갑자기 한 달 밀린다는 소식으로 바뀌었습니다. 되짚어 보니 2월 초에 이미 막혀 있었는데, 막혔다는 사실을 판정할 기준이 없어서 담당자도 자기가 늦은 줄 몰랐습니다. 수아가 그 일정을 믿고 기업 고객 두 곳에 3월 말을 이야기해 둔 뒤였습니다.
마일스톤은 이 두 달 반 사이에 판정 지점을 박아 두는 장치입니다. 계획이 밀렸다는 사실을 끝나는 날이 아니라 중간에 알게 만드는 것이 전부입니다.
작동 방식
마일스톤 하나는 날짜와 상태를 한 쌍으로 묶어 둔 문장입니다. 날짜만 적으면 그날 무엇을 보고 판정할지가 비어 있어서, 결국 담당자에게 어떻게 되어 가느냐고 묻게 됩니다. 상태만 적으면 언제까지인지가 없어 확인하는 날이 오지 않습니다.
쓸 만한 마일스톤에는 세 가지가 들어 있습니다.
- 시점 — 언제 확인하는지입니다. 분기 계획이면 보통 2주에서 4주 간격입니다. 더 촘촘하면 확인 자체가 일이 되고, 더 성기면 밀린 것을 알았을 때 손쓸 시간이 남지 않습니다.
- 그때 되어 있어야 할 상태 — 판정할 수 있는 문장이어야 합니다. "8월 말" 이 아니라 "8월 말까지 사내 팀 다섯 곳이 권한 설정을 직접 마치는 것" 처럼 씁니다. 앞은 날짜가 지났는지만 알려 주고, 뒤는 계획이 지났는지를 알려 줍니다.
- 판정하는 사람 — 됐는지 안 됐는지를 누가 말하는지입니다. 만든 사람이 스스로 판정하면 앞서 말한 낙관이 그대로 들어옵니다. 보통 그 결과를 받아 쓰는 쪽이 봅니다.
판정은 둘 중 하나입니다. 됐거나 안 됐거나입니다. 80퍼센트 됐다는 답을 허용하면 마일스톤은 다시 체감으로 돌아갑니다. 조건 중 하나라도 비어 있으면 안 된 것으로 놓고, 대신 그 자리에서 무엇이 남았는지와 그것이 며칠어치인지를 적습니다. 다음 마일스톤을 조정할 때 쓸 재료가 그 숫자이기 때문입니다.
안 됐을 때 하는 일도 미리 정해 둡니다. 선택지는 셋입니다. 범위를 줄이거나, 날짜를 미루거나, 사람을 더 붙이는 것입니다. 마일스톤을 박아 두는 실익은 이 셋 가운데 하나를 고를 시간이 남아 있을 때 고르게 된다는 데 있습니다. 3월 마지막 주에는 고를 것이 미루는 것 하나뿐입니다.
쓰이는 곳
가장 흔한 자리는 로드맵입니다. 달력 위에 일정을 못 박는 타임라인 로드맵에서는 분기 칸 안에 중간 점으로 찍히고, 날짜 대신 시급도 세 칸으로 나눈 나우-넥스트-레이터에서는 지금 칸에 들어간 항목에만 붙습니다. 뒤 칸의 항목은 아직 시작하지 않아 판정할 상태를 적을 수 없기 때문입니다.
여러 스토리로 쪼개지는 큰 작업 덩어리인 에픽 안에서도 같은 역할을 합니다. 두 달짜리 에픽을 통째로 두면 중간 점검이 불가능하니, 안에 서너 개를 박아 두고 지날 때마다 확인합니다.
밖을 향한 약속에도 쓰입니다. 기업 고객과 도입 일정을 맞추거나 투자자에게 진척을 보고할 때, 마일스톤은 상대가 자기 일정을 걸 수 있는 유일한 지점입니다. 이 자리에서는 모든 기능에 모든 사람이 접근할 수 있는 정식 출시 날짜 하나만 주는 것보다, 그 앞의 확인 지점을 함께 주는 편이 신뢰를 얻습니다. 밀렸을 때 상대도 같이 조정할 시간이 생깁니다.
목표와 핵심 결과로 나눠 관리하는 OKR과는 층이 다릅니다. OKR 이 이번 분기에 무엇을 달성할지를 정한다면, 마일스톤은 거기 닿는 길 위에 놓인 확인 지점입니다. 둘을 같은 칸에 적으면 목표와 일정 중 하나가 밀려납니다.
실무 용례
"다음 마일스톤이 이번 주 금요일인데, 지금 상태로 통과할까요?"
정해 둔 조건이 그날까지 채워질지를 미리 묻는 말입니다.
"이건 마일스톤이 아니라 그냥 날짜예요. 뭐가 되어 있어야 하는지 적어 주세요."
판정할 상태가 빠져 있어 지났는지를 확인할 수 없다는 지적입니다.
"두 번째 마일스톤을 놓쳤으니 범위를 줄일지 날짜를 미룰지 지금 정합시다."
밀린 것을 확인했으니 셋 중 하나를 고르자는 제안입니다.
페이지덱이 권한 관리를 만들던 분기에 마일스톤은 셋이었습니다. 2월 둘째 주에 설정 화면에서 역할을 만들고 지울 수 있는 것, 3월 첫째 주에 사내 팀 다섯 곳이 스스로 설정을 마치는 것, 3월 셋째 주에 기업 고객 한 곳이 실제 데이터로 쓰는 것입니다. 두 번째에서 막혔고, 지현이 그 자리에서 외부 협력사 초대 기능을 다음 분기로 넘겨 세 번째를 지켰습니다. 수아는 고객에게 날짜를 바꿔 말하지 않아도 됐습니다.
흔한 오해
마일스톤을 마감일과 같은 말로 쓰는 경우가 가장 많습니다. 둘 다 달력에 찍히는 점이라 자연스러운 혼동입니다. 하지만 마감일은 그날까지 끝내라는 요구이고, 마일스톤은 그날 무엇이 되어 있는지 보자는 약속입니다. 방향이 반대입니다. 마감일로 읽히기 시작하면 팀은 그날 통과하는 데 필요한 최소한만 만들어 놓고 통과 판정을 받으려 하고, 다음 마일스톤에 그만큼의 빚이 넘어갑니다.
많이 박을수록 좋다고 보는 오해도 있습니다. 확인 지점이 촘촘하면 안심이 되니 주 단위로 쪼개고 싶어집니다. 하지만 하나를 지날 때마다 상태를 모으고 판정하고 어긋나면 조정하는 일이 따라붙습니다. 일주일 간격이면 그 일이 매주 돌아오고, 몇 주 지나면 판정 없이 지나가는 마일스톤이 생깁니다. 한 번 그렇게 되면 나머지도 장식이 됩니다. 분기에 셋에서 다섯이면 대체로 충분합니다.
같이 보면 좋은 페이지
- 제품 로드맵
마일스톤이 어느 문서 안에 찍히는 점인지 먼저 봅니다
- 나우-넥스트-레이터
날짜를 쓰지 않는 로드맵에서 마일스톤이 어디에 붙는지 볼 수 있습니다
마지막 업데이트 2026-09-16