마일스톤을 설정하고 관리하는 방법 - 일정이 흔들리지 않는 기준 만들기

프로젝트가 중반 정도에 접어들면 일정이 틀어지는 상황을 한 번쯤은 경험해보셨을 겁니다. 초반에는 계획대로 진행되는 것처럼 보이지만, 어느 순간부터 일정과 품질이 동시에 흔들리기 시작합니다.

일정이 틀어지는 순간, 지연은 곧바로 비용 증가로 이어지고 결국 프로젝트 리스크로 남게 됩니다. 그래서 프로젝트를 이끄는 PM과 기획자에게 일정 관리는 선택이 아니라 반드시 갖춰야 할 기본 역량으로 요구됩니다.

물론 프로젝트를 진행하다 보면 변화는 피할 수 없습니다. 중요한 것은 변화 속에서도 최선의 선택을 하며 프로젝트를 완성으로 이끄는 것입니다. 이를 위해 일 잘하는 기획자들이 공통적으로 관리하는 핵심 포인트, 바로 ‘마일스톤 관리’입니다.

마일스톤(Milestone)이란 무엇인가?

마일스톤(Milestone)은 프로젝트 진행 상황을 판단하기 위한 ‘의사결정 기준점’입니다. 지금 상태를 ‘완료로 볼 것인지, 보완이 필요한지, 다음 단계로 넘어갈 수 있는지’를 결정하는 지점을 의미합니다. 일을 얼마나 했는지를 확인하는 장치가 아니라, 판단을 내려야 하는 시점을 구조화한 개념입니다.

마일스톤은 ‘일의 양’을 말하지 않습니다

많은 프로젝트에서 마일스톤이 일정표의 날짜나 단계 이름으로만 사용됩니다. 하지만 이 표현만으로는 중요한 질문에 답할 수 없습니다.

• 무엇이 완료된 상태인가?
• 누가 그 완료를 승인하는가?
• 이 상태에서 다음 단계로 넘어가도 되는가?

이 질문에 답하지 못한다면, 해당 마일스톤은 실제로는 존재하지 않는 것과 다르지 않습니다. 마일스톤은 작업의 종료 시점이 아니라, 판단의 시작이기 때문입니다.

마일스톤과 WBS와 마일스톤의 차이

마일스톤을 이해하려면 WBS와의 차이를 먼저 구분할 필요가 있습니다.

• WBS(Work Breakdown Structure)

→ 해야 할 일을 작업 단위로 쪼개는 구조
→ “무엇을, 누가, 언제까지 할 것인가”에 집중합니다.
 

• 마일스톤(Milestone)

 → 그 결과를 어떻게 판단할 것인지 정하는 기준점
→ ‘이제 다음 단계로 넘어가도 되는가’를 결정합니다.

WBS가 실행을 관리하는 도구라면, 마일스톤은 판단을 관리하는 도구입니다. 프로젝트가 중반 이후 흔들리는 이유는 대부분 판단 기준이 되는 마일스톤이 구조화되어 있지 않기 때문입니다.

▶ 프로젝트 일정를 관리하는 도구 WBS 작성 방법 보러가기

왜 마일스톤이 없으면 일정이 흔들릴까?

초반에는 모든 것이 비교적 단순합니다. 해야 할 일이 명확하고, 진행 여부도 눈에 보입니다. 하지만 프로젝트가 진행될수록 상황은 달라집니다.

• 일부는 끝났고, 일부는 덜 끝났고
• 수정이 필요한 부분과 넘어가도 되는 부분이 섞이기 시작합니다.

이 시점부터 필요한 것은 더 많은 작업이 아니라, 명확한 판단입니다. 마일스톤이 없는 프로젝트에서는 이 판단을 시스템이나 구조가 아니라 사람의 감각과 경험이 대신하게 됩니다. 그 결과, 일정은 ‘관리’되지 않고 ‘버텨지는’ 상태가 됩니다.

마일스톤을 관리한다는 것은 무엇을 의미할까?

단순 체크가 아닌 판단 시점 관리

마일스톤을 관리한다는 것은 일정표에 표시된 날짜를 지키는 일이 아니라, 프로젝트 진행 중 반드시 내려야 하는 판단을 제때 내리도록 구조를 만드는 일을 의미합니다. 

지금 결과물을 승인할 것인지, 일부 보완 후 진행할 것인지, 아니면 방향 자체를 수정해야 하는지와 같은 선택지가 명확히 존재해야 합니다. 

이 판단이 내려지지 않으면 프로젝트는 계속 ‘진행 중’ 상태로만 유지되고, 결정은 뒤로 미뤄집니다. 문제는 미뤄진 판단이 사라지는 것이 아니라 누적된다는 점입니다.

승인 · 보류 · 수정 결정의 기준

마일스톤 관리는 애매한 상태를 허용하지 않는 구조를 만드는 일입니다. 어떤 상태를 승인으로 볼 것인지, 어떤 경우에 보류해야 하는지, 수정 후 재검토는 어떻게 이뤄지는지 기준이 있어야 마일스톤이 의사결정 도구로 기능합니다.

다음 단계로 넘어갈 수 있는 조건

마일스톤의 본질은 언제까지 끝났는지가 아니라, 어떤 상태여야 다음 단계로 넘어갈 수 있는지입니다. 이 구조가 갖춰지면 프로젝트는 훨씬 안정적으로 움직이기 시작합니다. 

일정이 흔들릴 때도 어느 마일스톤에서 어떤 조건이 충족되지 않았는지를 기준으로 대화할 수 있게 됩니다. 

마일스톤은 어떻게 관리할까?

마일스톤은 하나의 도구로 관리하기보다, 문서와 상태를 보여주는 툴을 함께 사용합니다. 

마일스톤을 관리하는 서류 '마일스톤 승인 기준표’

마일스톤 관리의 핵심은 이 시점에서 판단이 실제로 내려졌는지입니다. 이를 위해 가장 기본적으로 사용되는 문서가 마일스톤 승인 기준표입니다.

• 해당 마일스톤의 목적과 판단 이유
• 완료로 인정하기 위한 기준
• 승인 / 보류 / 수정 중 어떤 상태인지
• 판단 결과와 사유
• 승인 주체 및 결정 일자

마일스톤 승인 기준표는 다음 단계로 넘어가도 되는지 판단했음을 기록으로 남기는 문서입니다. 

이 문서가 없으면 마일스톤 판단은 사람의 기억에 의존하게 되고, 프로젝트가 길어질수록 해석은 서로 달라집니다.

마일스톤을 관리에 사용하는 툴, 'Jira’

프로젝트에서 마일스톤 관리에 주로 사용되는 툴은 ‘Jira’입니다. Jira를 사용하면 마일스톤을 단순 일정 이벤트가 아니라 판단 단위로 묶어 관리할 수 있습니다.

• 마일스톤 → Version 또는 Epic
• 작업 단위 → Task / Story
• 마일스톤 도달 여부 → 개별 작업이 아니라 마일스톤 단위로 판단

Jira 외에 함께 사용되는 도구들

프로젝트 성격에 따라 다음과 같은 도구들이 보조적으로 사용되기도 합니다.

• MS Project / Primavera

: 일정·의존성·마일스톤 관리에 강점, 판단 기록에는 한계

• Notion / Confluence

: 승인 기준·결정 이력 정리에 유리, 실행 상태와는 분리

• Asana / Monday / ClickUp

: 마일스톤 시각화에 적합, 복잡한 SI 의사결정에는 제한적

각 툴은 저마다의 특색을 가지고 있어 문서로는 ‘판단 기준과 승인 기록’을 남기고 툴로는 ‘현재 상태를 한눈에 보여주는 역할’을 분리해서 사용합니다.
 

마일스톤은 어떻게 설정해야 할까?

프로젝트에서 마일스톤은 일정 관리용 구분선이 아니라, 리스크를 조기에 드러내기 위한 판단 장치로 설계되어야 합니다.

단계 기준 마일스톤 (기획 / 개발 / 테스트 / 오픈)

단계 기준 마일스톤에는 반드시 단계 종료 조건이 함께 정의되어야 합니다.

• 기획 단계에서는 요구사항 범위와 제외 항목이 명확히 정리되어 있는가
• 개발 단계에서는 구현 완료가 아니라 테스트 가능한 상태인가
• 테스트 단계에서는 주요 시나리오 기준으로 검증이 완료되었는가

이 조건이 빠지면 단계는 넘어가지만, 문제는 그대로 다음 단계로 이월됩니다.

산출물 기준 마일스톤

프로젝트에서는 산출물이 많아질수록 ‘작성됨’과 ‘완료됨’이 혼용되기 쉽습니다. 산출물 기준 마일스톤은 이 차이를 분명히 구분하기 위한 장치입니다.

• 산출물이 검토 · 승인 가능한 수준인가
• 수정 사항이 반영된 최종본인가
• 이후 변경 발생 시 기준 문서로 사용할 수 있는가

이 기준이 없으면, 산출물은 쌓이지만 기준은 남지 않습니다.

의사 결정 기준 마일스톤

프로젝트에서 자주 빠지는 것이 바로 의사결정 기준 마일스톤입니다. 불확실성을 더 키우기 전에 결정하도록 만드는 구조를 가지고 있습니다.

• 이 시점에서 범위를 확정할 것인가
• 변경 요청을 받아들일 것인가, 이후로 미룰 것인가
• 일정 조정을 할 것인가, 범위를 조정할 것인가

프로젝트에서 마일스톤을 잘 설정했다는 것은, 리스크가 언제, 어디서, 어떤 판단 부족 때문에 발생했는지를 설명할 수 있는 상태를 만들었다는 의미에 가깝습니다. 이 상태가 되어야 일정은 구조적으로 관리되기 시작합니다.

마일스톤은 어떻게 작성해야 할까?

프로젝트에서 마일스톤 작성은 이미 존재하는 기획 문서 · 일정표 · 산출물 정의서에 '판단 기준'을 명확히 적어주는 작업에 가깝습니다. 

특히 발주처와 수행사가 함께 움직이는 SI 프로젝트나 여러 이해관계자가 관여하는 프로젝트에서는 언제 멈춰서 승인을 받아야 하는지, 무엇을 기준으로 다음 단계로 넘어갈지가 명확해야 합니다. 

1) 마일스톤은 '완료 선언'이 아니라 '판단 문장'으로 작성한다

마일스톤은 상태를 선언하는 문장이 아니라, 판단이 가능한 문장으로 작성되어야 합니다. 

• X ‘기획 완료’ 
• V 요구사항 범위와 제외 항목이 확정되어, 개발 단계로 넘어갈 수 있는 상태

2) 실제 문서에서는 이렇게 표현된다

IT 프로젝트에서 마일스톤은 보통 아래 문서들에 나뉘어 작성됩니다.

• 프로젝트 계획서 / 제안서 → 단계별 마일스톤과 각 단계의 판단 목적을 서술
• 산출물 정의서 → 마일스톤별 필수 산출물과 승인 기준 명시
• 일정표(WBS) → 마일스톤 시점 표시
• 회의록 · 의사결정 기록 → 실제 승인·보류·수정 결정 내용 기록

문서가 여러 개로 나뉘더라도, 각 마일스톤에는 판단에 필요한 정보가 빠지지 않고 들어가야 합니다. 구체적으로는 아래 요소들이 포함되어야 합니다.

• 이 마일스톤의 목적 (왜 이 지점에서 판단이 필요한가)
• 완료로 판단하기 위한 기준
• 승인 주체
• 승인 이후 가능한 다음 단계
• 보류 · 수정 시 재검토 조건

이 항목들이 작성되어 있으면, 마일스톤을 보고 어떤 단계인지를 판단할 수 있습니다.

3) IT 프로젝트에서 자주 쓰는 마일스톤 작성 예시

[마일스톤 예시 – 기획 단계 종료]

• 마일스톤 명: 요구사항 확정 마일스톤
• 판단 목적: 개발 착수 가능 여부 결정
• 완료 기준:
• 기능 요구사항 목록 승인
• 제외 범위 명시
• 변경 관리 기준 합의
• 승인 주체: 발주처 PM / 내부 PM
• 승인 결과: 승인 / 보류 / 수정 후 재검토

이렇게 작성하면 ‘기획이 끝났다’는 추상적 표현 대신, 무엇이 확정되었고 누가 승인했으며 다음 단계 진입 조건이 무엇인지가 명확해집니다. 

4) 결국 작성의 핵심은 '누가 읽고 판단할 수 있느냐'다

IT 프로젝트 문서는 사람이 읽고 판단하기 위해 존재합니다. 마일스톤을 보고, 지금 다음 단계로 넘어가도 되는지 판단할 수 있다면, 형식이 무엇이든 그 마일스톤은 제대로 작성된 것입니다.

기획자가 마일스톤 관리를 위해

반드시 챙겨야 할 체크리스트

기획자는 각 마일스톤마다 무엇을 확인해야 하는지를 명확히 알고 있어야 합니다. 개발이 아무리 빠르게 진행되더라도, 판단 기준이 정리되어 있지 않으면 프로젝트는 중반 이후부터 흔들리기 시작합니다.  

1) 완료 기준이 문서로 정의되어 있는가?

마일스톤이 존재하려면 ‘완료’라는 말의 의미가 문서로 남아 있어야 합니다. 특히 여러 역할이 동시에 움직이는 프로젝트에서는 기준이 문서로 정리되지 않으면, 각자 다른 완료 시점을 떠올리게 됩니다.

• 완료로 판단하는 최소 조건이 정리되어 있는가
• 포함 범위와 제외 범위가 명확히 정의되어 있는가
• 이후 변경 발생 시 기준으로 참조할 수 있는 문서인가
   

2) 승인 주체가 명확한가?

기획자는 각 마일스톤마다 누가 최종 판단을 내리는지를 분명히 정리해야 합니다. 결과물이 준비되어 있어도 승인 주체가 명확하지 않으면 판단은 계속 미뤄지고 일정은 자연스럽게 밀립니다. 

• 승인 책임자가 개인 또는 역할 단위로 명확한가
• 대체 승인 경로가 정의되어 있는가
• 승인 여부가 기록으로 남는 구조인가
   

3) 일정 · 인력 · 범위 변경 시 연결 구조는 있는가?

프로젝트에서 변경은 불가피합니다. 중요한 것은 변경이 발생했을 때, 그 영향이 어떤 마일스톤에 연결되는지 판단할 수 있어야 합니다.

• 변경 요청이 어느 마일스톤에 영향을 주는지 명확한가
• 변경으로 인해 재검토가 필요한 마일스톤이 정의되어 있는가
• 변경 승인 여부가 이후 일정에 어떻게 반영되는가

이 체크리스트를 통해 프로젝트가 ‘진행 중’인지, ‘다음 단계로 넘어가도 되는 상태’인지 명확히 판단할 수 있습니다.

마일스톤 관리가 어려운 이유,

결국 사람과 경험의 문제

마일스톤 관리가 잘 안 되는 이유를 툴이나 프로세스에서 찾는 경우가 많습니다. 하지만 실제 현장에서 반복되는 문제를 보면, 원인은 훨씬 단순합니다. 

언제 멈춰야 하는지, 어디서 판단해야 하는지를 경험으로 체득한 사람이 부족하기 때문입니다. 

일정 관리 경험 부족

마일스톤 관리가 어려운 가장 큰 이유는, 프로젝트를 여러 번 끝까지 끌고 가본 경험이 부족하기 때문입니다. 

프로젝트 초반에는 대부분의 판단이 쉽습니다. 하지만 중반 이후부터는 애매한 상태가 늘어나고, 어떤 지점에서 반드시 멈춰야 하는지 판단하지 못하면 일정은 눈에 띄지 않게 무너지기 시작합니다.

• “조금 더 진행해보자”라는 말이 반복됨
• 판단을 다음 회의로 미루는 구조가 고착화됨
• 문제를 인지했을 때는 이미 되돌리기 어려운 시점이 됨
   

여러 프로젝트를 겪어보지 않으면 놓치기 쉬운 포인트

마일스톤 관리에는 매뉴얼로 정리하기 어려운 영역이 존재합니다. 여러 프로젝트를 겪어보지 않으면 쉽게 판단하기 어렵습니다. 그래서 마일스톤 관리가 문서대로 진행되고 있음에도, 실제로는 계속 흔들리는 상황이 발생합니다.

• 문서상 기준은 충족했지만 불안한 지점이 남아 있음
• 문제의 ‘조짐’을 감지하지 못한 채 넘어감
• 후반부에 같은 유형의 이슈가 반복됨
   

내부 인력만으로 관리하기 어려운 이유

내부 인력은 프로젝트의 맥락을 가장 잘 알고 있지만, 동시에 그 맥락에 가장 깊이 들어가 있는 사람들입니다. 이 때문에 객관적으로 멈춰야 할 지점에서도 “이 정도는 괜찮다”는 판단이 나오기 쉽습니다. 

• 일정 압박으로 판단 기준이 완화됨
• 특정 인력의 경험과 감각에 의존하게 됨
• 기준보다 관계와 상황이 우선되는 구조가 됨

마일스톤은 일정 관리 기법이 아니라, 어떤 시점에서 판단을 내려야하는지를 구조적으로 정리하는 관리 방식입니다. 

이런 경험이 부족한 상태에서 프로젝트를 끌고 가면, 일정은 관리되기보다 지체되는 현상에 머무르게 됩니다.

다양한 프로젝트 경험을 통해 

마일스톤을 안정적으로 관리할 

IT 전문가가 필요하신가요?

마일스톤 기준에서 언제 멈추고, 언제 다음 단계로 넘어가야 하는지를 이해하는 IT 전문가는 각 단계에서 무엇을 승인해야 하는지, 어떤 상태에서 보류하거나 조정해야 하는지 판단하며, 일정 · 산출물 · 의사결정이 프로젝트 흐름에 미치는 영향을 함께 고려해 프로젝트를 안정적으로 운영합니다.

26년의 축적된 노하우를 바탕으로

마일스톤 설계와 운영 경험이 검증된 

IT 프리랜서를 매칭합니다.

이랜서는 대한민국 최대 IT 프리랜서 매칭 플랫폼입니다. 26년간 삼성, 현대, LG, 카카오 등 주요 대기업부터 중견 · 중소기업, 스타트업까지 약 8만 건 이상의 프로젝트에 데이터로 검증된 IT 프리랜서를 매칭하며 프로젝트를 이끌어갈 IT 전문가를 지원해왔습니다.

 

IT 프로젝트, 왜 IT 프리랜서를 투입할까요?

IT 프리랜서는 일반적으로 정규직 인력에 비해 경험이 많습니다. 여러 조직과 환경에서 프로젝트를 진행하며,  어떤 상황에 어떤 판단과 조취를 취해야 하는지 경험으로 체득해 왔습니다. 상황 변화에 따른 현실적이고 안정적인 의사결정을 내릴 수 있습니다.

그래서 중요한 프로젝트에는 IT 프리랜서를 선택해 프로젝트를 성공적으로 이끌어가는 기업들이 늘어나고 있습니다.

이랜서에 기업 회원으로 회원가입만 해도

PM, 기획자, 시니어 개발자 등 프로젝트 단계별로 마일스톤을 직접 다뤄본 경험을 기준으로 선별하며, SI 프로젝트 · 내부 시스템 구축 · 서비스 고도화 과정에서 판단과 의사결정에 실제로 참여해본 전문가를 바로 확인할 수 있습니다.

지금 기업회원으로 가입하면 

20년 경력 IT 전문 기획자가 직접 설계한 

WBS 성공 양식 2종을 무료로 드립니다.

• 시중에서 유료로 판매되고 있는 IT 전문 WBS 성공 양식입니다.
• IT 업계 20년의 노하우를 담은 WBS로 프로젝트를 체계적으로 관리할 수 있습니다.
• 작업 별 일정과 범위를 쉽게 정리할 수 있어 프로젝트 진행이 효율적입니다.

• 작업과 마일스톤을 명확히 설정해 팀원들이 목표를 정확히 이해하고 집중할 수 있습니다.

   

시중가 약 1만 원에 판매 중인  ‘WBS 성공 양식 2종’을 WBS 콘텐츠를 통해 이랜서에 회원 가입한 IT 전문가에게만 무료로 나눠드립니다. (이랜서에 기업 회원으로 가입 후 위의 링크를 통해 신청하신 분들에 한해 전달드립니다.)

▶ 지금 바로 이랜서 기업회원으로 가입하고, 프로젝트를 이끌 IT 프리랜서를 확인해보세요.