마일스톤 정하는 법 — 일정에서 '점'으로 찍어야 할 순간 고르기

프로젝트·일정 · 실용 가이드 · 2026. 09. 25 · 작성 rohan

일정표를 만들다 보면 "마일스톤을 넣으라"는 말을 듣는데, 막상 무엇을 마일스톤으로 삼아야 할지는 아무도 알려주지 않습니다. 그래서 작업 끝마다 점을 찍어 20개가 되거나, 반대로 '출시' 하나만 덩그러니 남습니다. 이 글은 마일스톤이 작업과 어떻게 다른지, 좋은 마일스톤의 조건 세 가지, 몇 개를 어떻게 이름 붙일지, 그리고 마일스톤이 위태로울 때 무엇을 먼저 조정할지를 실제 프로젝트 예시 두 개와 함께 정리합니다. 간트차트 도구에서 표시하는 요령도 솔직하게 적었습니다. 막대와 기호를 읽는 일반적인 방법은 간트차트 보는 법, 마일스톤을 주간 보고에 올리는 양식은 주간 업무 보고서 쓰는 법에 있고, 이 글은 무엇을 마일스톤으로 고를지에 집중합니다.

마일스톤이란 — 기간이 0인 '사건'

작업(task)은 기간이 있습니다. "화면 설계, 10월 12일부터 23일까지"처럼 시작과 끝이 있고, 그 사이에 사람이 일을 합니다. 마일스톤(milestone)은 기간이 없는 시점입니다. "설계 승인 완료, 10월 23일"처럼 어느 날 일어나거나 일어나지 않는 사건이고, 그 자체로는 아무도 작업하지 않습니다. 간트차트에서 막대 대신 점(◆)으로 찍히는 이유가 이것입니다.

둘의 차이를 실무에서 가장 쉽게 가르는 질문은 "이게 50% 진행될 수 있는가"입니다. 화면 설계는 절반쯤 할 수 있습니다. 하지만 설계 승인은 절반만 받을 수 없습니다. 받았거나 못 받았거나 둘 중 하나입니다. 이렇게 0 아니면 100으로만 판정되는 것이 마일스톤입니다.

구분	작업(Task)	마일스톤(Milestone)
기간	있음(예: 영업일 8일)	없음(날짜 하나)
진행율	0~100% 사이 값	0% 또는 100%
담당	실행하는 사람	확인·승인하는 사람
질문	"얼마나 했나요?"	"됐나요, 안 됐나요?"
보고에서 역할	진척 설명	일정 판단의 기준점

마일스톤을 두는 이유는 단순합니다. 작업 30개의 진행율을 매주 읽는 것보다, 마일스톤 6개가 제 날짜에 찍히는지 보는 쪽이 경영진도 팀도 훨씬 빠르게 상황을 파악하기 때문입니다.

좋은 마일스톤의 세 가지 조건

1. 검증 가능해야 한다

"개발 대략 마무리"는 마일스톤이 아닙니다. 누가 봐도 됐다/안 됐다를 말할 수 있어야 합니다. "코드 프리징(더 이상 기능 추가 없음) 선언", "QA 통과 보고서 서명", "스토어 심사 제출 완료"처럼 확인할 수 있는 증거가 있어야 합니다. 검증 방법을 한 줄로 못 쓰면 마일스톤 이름을 다시 고민해야 합니다.

2. 팀 밖에서도 의미가 있어야 한다

마일스톤은 프로젝트 안팎이 같은 날짜를 보게 하는 장치입니다. "DB 스키마 3차 수정 완료"는 개발팀 안에서는 중요해도 대표나 고객에게는 의미가 없습니다. 반면 "베타 테스터 100명에게 초대 발송"은 마케팅·CS·경영진이 모두 반응하는 사건입니다. 외부(고객·경영진·다른 팀)가 알아들을 수 있는 말로 표현되는지가 기준입니다.

3. 의사결정 지점이어야 한다

좋은 마일스톤은 통과 여부에 따라 다음 행동이 갈립니다. 설계 승인이 나면 개발 착수, 안 나면 재설계. 베타 결과가 기준 이상이면 출시, 아니면 2주 연장. 이런 갈림길이 없다면 그냥 작업의 끝일 뿐이고, 굳이 점으로 찍을 이유가 약합니다.

흔한 마일스톤 유형

유형	예시 이름	검증 산출물	승인자
킥오프	프로젝트 착수 승인됨	킥오프 회의록, 범위·예산 합의서	스폰서(의뢰인·임원)
요구사항 확정	요구사항 명세 동결됨	서명된 요구사항 문서 v1.0	고객 또는 PO
설계 승인	화면·아키텍처 설계 승인됨	설계 리뷰 회의록, 승인 메일	기술 리더·디자인 리더
알파	내부 알파 배포됨	내부 테스트 환경 URL, 배포 로그	PM
베타	외부 베타 시작됨	베타 초대 발송 기록, 피드백 채널 개설	PM·CS 리더
출시	정식 출시됨	스토어 게시·서비스 오픈 공지	스폰서
회고	회고 완료 및 개선안 확정됨	회고 문서, 다음 프로젝트 반영 항목	팀 전체

업종이 달라도 구조는 같습니다. 건축이면 "인허가 취득됨·골조 완료 검사 통과됨·준공 승인됨", 행사면 "장소 계약 완료됨·초청장 발송됨·리허설 완료됨"이 됩니다. 공통점은 모두 외부 확인이 붙는 시점이라는 것입니다.

몇 개가 적당한가 — 개수 기준

너무 적으면 몇 주 동안 신호가 없고, 너무 많으면 작업 목록과 다를 게 없어집니다. 실무에서 통하는 기준은 월 1~2개, 프로젝트 전체로 5~10개입니다. 3개월 프로젝트면 5~7개, 6개월이면 8~10개 정도가 됩니다. 이보다 많아지면 마일스톤을 두 등급으로 나눕니다. 스폰서에게 보고하는 주요 마일스톤 5개 안팎과, 팀 내부에서만 쓰는 내부 마일스톤으로 구분하면 보고 자료가 깔끔해집니다.

• 2주 스프린트로 일하는 팀은 스프린트 종료를 전부 마일스톤으로 찍지 않습니다. 릴리스가 나가는 스프린트 끝만 찍습니다.
• 6주 이상 마일스톤이 비는 구간이 있으면 중간 검증 지점(예: 핵심 기능 데모)을 하나 넣습니다. 그 구간에서 지연이 생기면 6주 동안 아무도 모릅니다.
• 첫 마일스톤은 착수 후 2~3주 안에 둡니다. 초반에 팀이 실제로 굴러가는지 빨리 확인하는 효과가 큽니다.

이름 짓기와 산출물·승인자 묶기

이름은 완료형 동사로

마일스톤 이름은 "~됨", "~완료", "~승인"처럼 이미 일어난 상태로 씁니다. "설계 리뷰"는 작업 이름이고, "설계 승인됨"이 마일스톤 이름입니다. 이렇게 쓰면 보고서에서 "설계 승인됨 — 10/23 예정 → 10/27 달성"처럼 상태 문장이 자연스럽게 만들어지고, 검증 조건이 이름에 드러납니다.

• 좋은 예: "요구사항 동결됨", "베타 초대 100명 발송됨", "심사 제출 완료", "1차 납품 검수 통과"
• 고칠 예: "요구사항 정리"(작업), "베타"(무엇이 됐다는 건지 불명), "테스트"(기간이 있는 일)
• 숫자를 넣을 수 있으면 넣습니다. "베타 테스터 모집"보다 "베타 테스터 100명 확보됨"이 검증하기 쉽습니다.

산출물과 승인자를 반드시 묶는다

마일스톤마다 무엇을 보고 판정하는지(산출물)와 누가 판정하는지(승인자)를 미리 정해 둡니다. 이것을 정하지 않으면 마일스톤 날짜에 "됐다고 봐도 되나요?"라는 회의가 열리고, 결국 애매하게 넘어갑니다. 위 유형 표의 오른쪽 두 열이 그 역할입니다. 승인자가 외부인(고객·심사기관)이면 그 사람의 일정도 미리 잡아야 합니다. 산출물은 다 됐는데 승인자가 휴가라서 마일스톤이 일주일 밀리는 일이 실제로 가장 흔한 지연 원인입니다.

WBS를 만들 때 각 단계의 마지막 작업 산출물이 곧 마일스톤의 검증 산출물이 되도록 맞추면 관리가 쉽습니다. WBS를 산출물 중심으로 쪼개는 방법은 WBS 작성법에 정리되어 있습니다.

마일스톤이 위태로울 때 — 날짜를 밀지 말고 범위를 조정한다

마일스톤 앞 작업이 늦어지면 첫 반응은 "마일스톤을 일주일 미루자"입니다. 그런데 마일스톤은 외부와 약속한 날짜라서, 한 번 밀면 그 뒤 마일스톤이 줄줄이 밀리고 팀 밖의 신뢰가 깎입니다. 그래서 원칙은 마일스톤 날짜는 고정하고 그 안에 들어갈 범위를 조정하는 것입니다.

1. 마일스톤 통과 조건에서 꼭 필요한 것과 있으면 좋은 것을 나눕니다. 베타 시작에 결제 기능이 꼭 필요한지, 다음 마일스톤으로 넘겨도 되는지 묻습니다.
2. '있으면 좋은 것'을 다음 마일스톤으로 넘기고, 그 변경을 승인자에게 미리 알립니다. 당일에 알리는 것과 2주 전에 알리는 것은 전혀 다르게 받아들여집니다.
3. 범위를 줄여도 안 되면 그때 날짜를 조정하되, 한 번에 충분히 밉니다. 사흘씩 세 번 미는 것이 열흘 한 번 미는 것보다 신뢰를 더 깎습니다.
4. 어느 쪽이든 마일스톤 뒤에 붙은 작업들의 시작일을 다시 계산합니다. 재계획 순서는 프로젝트 일정 관리 방법의 '변경이 생겼을 때' 부분을 참고하세요.

어떤 작업이 늦어지면 마일스톤이 실제로 밀리는지는 핵심경로에 있는 작업인지에 달렸습니다. 여유가 있는 작업이면 마일스톤은 안전합니다. 이 판단은 크리티컬 패스 계산법에서 다뤘습니다.

간트차트에 마일스톤 표시하기 — 도구별 요령

전용 프로젝트 관리 소프트웨어는 기간을 0으로 두면 자동으로 다이아몬드(◆)를 그려 줍니다. 엑셀에서는 마일스톤 행의 시작일과 종료일을 같은 날짜로 두고 조건부 서식 색을 다르게 주거나, 셀에 ◆ 문자를 넣는 규칙을 추가합니다.

이 사이트의 WBS·간트차트 도구에는 마일스톤 전용 기능이 따로 없습니다. 솔직히 적어 두는 편이 낫겠습니다. 대신 아래 요령으로 충분히 같은 효과를 냅니다.

• 기간 1일짜리 행으로 만듭니다. 시작일과 종료일을 같은 날로 넣으면 업무량 1일의 짧은 막대가 됩니다. 그 날짜가 공휴일이면 영업일이 0이 되므로 근무일로 잡습니다.
• 이름 앞에 ◆ 기호를 붙입니다. "◆ 설계 승인됨"처럼 쓰면 표와 간트 양쪽에서 한눈에 구분됩니다. 도구 안에 검색 기능은 없지만, 엑셀로 내려받아 과제명 열을 '◆'로 필터하면 마일스톤 목록만 따로 뽑을 수 있습니다.
• 단계의 마지막 하위 행으로 둡니다. 상위 항목의 종료일은 하위의 마지막 날짜로 집계되므로, 마일스톤을 단계 끝에 두면 상위 막대 끝이 곧 마일스톤 날짜가 됩니다.
• 담당자 칸에는 승인자, 비고 칸에는 검증 산출물을 적습니다. 진행율은 통과 전 0%, 통과 후 100%만 씁니다.
• 마일스톤 날짜가 지났는데 진행율이 0%면 도구가 지연으로 판정하므로, 지연만 보기 필터에서 밀린 마일스톤이 바로 드러납니다. 마일스톤 당일에는 아직 "진행중"으로 표시되고, 다음 날부터 지연으로 바뀝니다.
• 이 방식의 부작용도 알아 두세요. 마일스톤 행도 업무량 1일로 계산되어 단계 업무량과 진행율 가중치에 조금씩 섞입니다. 마일스톤 6개면 6일분입니다. 작업이 20~30개인 프로젝트에서는 무시해도 될 정도지만, 작업이 몇 개 안 되는 단계에 마일스톤을 여러 개 넣으면 단계 진행율이 마일스톤 통과 여부에 크게 흔들립니다.

예시 프로젝트 2개의 마일스톤 목록

예시 1. 모바일 앱 신규 기능 출시 (12주)

주차	마일스톤	검증 산출물	승인자
1주	◆ 킥오프 완료·범위 합의됨	범위 문서 v1.0, 회의록	PO
3주	◆ 화면 설계 승인됨	디자인 리뷰 통과 기록	디자인 리더·PO
7주	◆ 핵심 기능 내부 데모 완료	데모 영상, 남은 이슈 목록	PM
9주	◆ 코드 프리징 선언	브랜치 잠금, 릴리스 노트 초안	기술 리더
10주	◆ 베타 200명 배포됨	배포 기록, 피드백 채널	PM·CS
12주	◆ 스토어 정식 출시됨	스토어 게시 확인, 공지	스폰서

예시 2. 100명 규모 사내 워크숍 (8주)

주차	마일스톤	검증 산출물	승인자
1주	◆ 예산·날짜 확정됨	결재 문서	경영지원 임원
2주	◆ 장소 계약 완료	계약서, 계약금 이체 확인	총무 리더
4주	◆ 프로그램·연사 확정됨	확정 시간표, 연사 수락 메일	기획 리더
5주	◆ 참가 신청 마감(90명 이상)	신청 명단	기획 리더
7주	◆ 리허설 완료	체크리스트 점검 결과	총괄
8주	◆ 행사 종료·정산 완료	정산서, 만족도 결과	경영지원 임원

두 예시 모두 월 2개 안팎, 전체 6개이고, 이름이 완료형이며, 산출물과 승인자가 붙어 있습니다. 5주 차 "참가 신청 마감(90명 이상)"처럼 숫자 기준을 넣으면 통과 판정에 논쟁이 사라집니다.

보고에서 마일스톤 쓰는 법

주간 보고의 첫 줄은 마일스톤으로 씁니다. "다음 마일스톤: ◆ 코드 프리징(11/6) — 정상 / 위험 / 지연"처럼 다음 마일스톤 이름·날짜·신호 세 가지만 있으면 읽는 사람이 30초 안에 상황을 파악합니다. 그 아래에 근거로 작업 진행율 표를 붙입니다. 표 양식은 주간 업무 보고서 쓰는 법에 있습니다.

• 정상: 마일스톤 앞 핵심 작업들의 진행율이 기간진행율 이상.
• 위험: 핵심 작업 중 하나 이상이 기간진행율보다 10%p 넘게 뒤처짐. 아직 날짜는 지킬 수 있으나 범위 조정을 검토 중.
• 지연: 날짜를 지킬 수 없음이 확정. 새 날짜와 조정된 범위를 함께 제시.

지나간 마일스톤은 "계획 10/23(금) → 실제 10/27(화), +2영업일"처럼 계획과 실제를 나란히 남깁니다. 달력으로는 4일 차이지만 주말을 빼면 이틀이므로, 차이는 영업일로 적어야 다음 프로젝트의 버퍼 계산에 그대로 쓸 수 있습니다. 프로젝트가 끝났을 때 이 기록이 회고의 가장 좋은 재료가 되고, 다음 프로젝트에서 버퍼를 얼마나 둘지 정하는 근거가 됩니다. 버퍼 설계는 일정 버퍼와 리스크 관리 기초를 참고하세요.

자주 묻는 질문

마일스톤과 작업(태스크)은 어떻게 다른가요?

작업은 기간이 있고 진행율이 0~100% 사이 값을 가질 수 있는 '일'이고, 마일스톤은 기간이 없는 '사건'으로 통과했거나 못 했거나 둘 중 하나입니다. "이게 50% 진행될 수 있는가"를 물어 봐서 그럴 수 있으면 작업, 그럴 수 없으면 마일스톤입니다. 간트차트에서 작업은 막대, 마일스톤은 점(◆)으로 표시됩니다.

마일스톤은 몇 개가 적당한가요?

월 1~2개, 프로젝트 전체로 5~10개가 실무에서 통하는 기준입니다. 3개월 프로젝트면 5~7개 정도입니다. 6주 이상 마일스톤이 없는 구간이 있으면 중간 검증 지점을 하나 넣고, 반대로 너무 많아지면 스폰서에게 보고하는 주요 마일스톤과 팀 내부용 마일스톤으로 등급을 나눕니다.

마일스톤 앞 작업이 늦어지면 마일스톤 날짜를 미뤄야 하나요?

먼저 마일스톤 날짜는 고정한 채 통과 조건의 범위를 조정하는 것이 원칙입니다. 꼭 필요한 것과 있으면 좋은 것을 나누고 후자를 다음 마일스톤으로 넘기되, 그 변경을 승인자에게 미리 알립니다. 범위를 줄여도 안 될 때만 날짜를 옮기고, 그때는 사흘씩 여러 번이 아니라 한 번에 충분히 조정합니다.

WBS·간트차트 도구에 마일스톤 기능이 있나요?

전용 마일스톤 기능은 없습니다. 대신 시작일과 종료일을 같은 날로 넣어 기간 1일짜리 행을 만들고 이름 앞에 ◆ 기호를 붙이면 표와 간트에서 바로 구분됩니다. 단계의 마지막 하위 행으로 두면 상위 항목 종료일이 마일스톤 날짜와 일치하고, 날짜가 지났는데 진행율이 0%이면 자동으로 지연 판정되어 밀린 마일스톤을 쉽게 찾을 수 있습니다.

정리

마일스톤은 기간이 0인 사건이며, 됐다/안 됐다로만 판정됩니다. 좋은 마일스톤은 검증 가능하고, 팀 밖에서도 의미가 있으며, 통과 여부에 따라 다음 행동이 갈리는 지점입니다. 개수는 월 1~2개·프로젝트당 5~10개를 기준으로 하고, 이름은 "~승인됨"처럼 완료형으로 쓰며, 산출물과 승인자를 반드시 붙입니다. 앞 작업이 늦어지면 날짜보다 범위를 먼저 조정하세요. 간트차트 도구에 전용 기능이 없어도 기간 1일 행에 ◆ 기호를 붙이면 충분히 관리되고, 보고서 첫 줄에 다음 마일스톤의 이름·날짜·신호만 적어도 읽는 사람의 이해 속도가 확 달라집니다.

→ 간트차트 보는 법 · → WBS 작성법 · → 프로젝트 일정 관리 방법