MS Project 기준선(초기 계획) 저장과 지연 비교: 계획과 실제를 나란히 보는 법

요지

• 기준선은 승인된 계획을 그대로 찍어 둔 사본이다. 진행 입력을 시작하기 전에 저장해야 나중에 「처음 약속보다 며칠 늦었나」를 답할 수 있다.
• 한국어판 MS Project 화면은 기준선(Baseline)을 「초기 계획」이라고 적는다. 저장은 [프로젝트] 탭의 「초기 계획 설정」에서 한다.
• 늦어진 작업은 「차이」 테이블의 「완료 날짜 차이」 열과 「진행 상황 Gantt」 보기로 찾는다.
• 같은 기준선에 다시 저장하면 앞의 값이 지워진다. 변경이 승인되어 다시 저장할 때는 앞의 기준선을 다른 번호에 먼저 옮겨 둔다. 「차이」는 번호 없는 「초기 계획」과만 견주기 때문이다.

먼저 할 일 세 가지

1. 계획이 승인되면 그날 [프로젝트] 탭 → 「초기 계획 설정」 → 「초기 계획 설정…」에서 「프로젝트 전체」로 저장한다.
2. 진행을 입력한 뒤에는 [보기] 탭 → 「테이블」 → 「차이」를 열고 「완료 날짜 차이」가 0보다 큰 줄을 본다.
3. 계획을 다시 승인받았으면 지금의 「초기 계획」을 「초기 계획 1」에 옮겨 둔 다음, 「초기 계획」에 새 계획을 저장한다.

아래는 이 세 가지를 하나씩 풀어 쓴 것이다.

화면에서는 「초기 계획」이다

프로젝트 관리 용어로는 기준선이고, 한국어판 MS Project 화면에서는 「초기 계획」이다. 메뉴, 창 제목, 열 이름이 모두 이 말을 쓴다. 책이나 강의에서 기준선이라고 배웠다면 화면에서는 「초기 계획」으로 찾는다.

표는 가로로 밀어서 볼 수 있습니다.

이 글에서는 개념을 말할 때는 기준선, 화면에서 누를 것을 말할 때는 「초기 계획」이라고 쓴다.

언제 저장하나

계획이 승인된 때, 그리고 진행 상황을 입력하기 전이다. 기준선은 저장하는 순간의 일정을 복사해 두는 것이라, 실제 날짜를 몇 개 입력한 뒤에 저장하면 이미 밀린 날짜가 「처음 계획」으로 굳는다. 그러면 차이가 실제보다 작게 나온다.

저장하기 전에 확인할 것은 세 가지다.

• 작업이 빠짐없이 들어 있는가. 기준선을 저장한 뒤에 넣은 작업은 기준선 값이 비어 있다.
• 작업 사이의 연결과 기간이 승인받은 계획과 같은가.
• 자원과 비용까지 관리할 계획이면 배정이 끝났는가. 기준선은 날짜만이 아니라 작업 시간과 비용도 함께 저장한다.

저장하는 순서

1. [프로젝트] 탭의 [일정] 그룹에서 「초기 계획 설정」을 누르고, 펼쳐진 메뉴에서 「초기 계획 설정…」을 고른다.
2. 「초기 계획 설정」 창에서 위쪽 「초기 계획 설정」이 선택된 채로 목록에서 「초기 계획」을 고른다. 목록에는 「초기 계획」과 「초기 계획 1」부터 「초기 계획 10」까지 열한 개가 있다.
3. 「대상」에서 「프로젝트 전체」를 고르고 「확인」을 누른다.

기준선은 파일 안에 들어가므로 파일을 저장해야 남는다.

저장되는 값은 시작 날짜, 완료 날짜, 기간, 작업 시간, 비용의 다섯 갈래다. 저장한 직후에는 기준선 날짜와 지금 일정의 날짜가 같다. 그 뒤로 지금 일정은 진행에 따라 움직이고, 기준선 날짜는 저장한 값 그대로 남는다.

늦어진 작업 찾기 1: 「차이」 테이블

[보기] 탭에서 「테이블」을 누르고 「차이」를 고른다. 이 테이블은 지금 일정의 시작과 완료, 기준선의 시작과 완료, 그리고 둘의 차이를 나란히 보여 준다. 필드 이름으로는 지금 일정이 「시작」, 「완료」이고, 기준선이 「초기 계획 시작 날짜」, 「초기 계획 완료 날짜」, 차이가 「시작 날짜 차이」, 「완료 날짜 차이」다.

가상의 예를 보자. 사내 교육 과정 하나를 만드는 일정이고, 계획을 승인받은 날 기준선을 저장했다. 2주 뒤 진행을 입력하고 「차이」 테이블을 열었더니 아래와 같았다.

표는 가로로 밀어서 볼 수 있습니다.

읽는 법은 이렇다.

• 차이가 0보다 크면 기준선보다 늦은 것이다. 「완료 날짜 차이」는 지금 일정의 완료에서 초기 계획 완료 날짜를 뺀 값이고, 달력 날짜가 아니라 작업일로 센다. 위 표에서 교안 초안은 달력으로 닷새 뒤지만 주말을 빼면 3일이다.
• 「시작 날짜 차이」가 0인데 「완료 날짜 차이」만 있는 줄을 먼저 본다. 교안 초안은 제때 시작했는데 3일 늦게 끝난다. 이 예에서는 여기서 늦어졌다.
• 두 차이가 같은 줄은 대개 밀려난 것이다. 교안 검토와 시범 강의는 시작부터 3일 밀렸다. 앞 작업을 기다리느라 늦은 것이고, 그 작업 자체가 길어진 것은 아니다. 다만 늦게 시작한 까닭이 앞 작업이 아닐 수도 있으니, 선행 작업을 따라가 확인한다.
• 실습 환경 준비는 교안과 따로 가는 작업이라 그대로다.

보고할 때 「세 작업이 늦었다」와 「교안 초안이 3일 늦어 뒤의 둘이 따라 밀렸다」는 다른 말이다. 「차이」 테이블에서 두 열을 함께 보면 뒤쪽으로 말할 수 있다.

「완료 날짜 차이」가 큰 순서로 정렬하면 많이 늦은 작업이 위로 온다. 요약 작업의 차이는 그 아래 작업들을 묶은 값이므로, 원인을 찾을 때는 요약 작업을 펼쳐 맨 아래 작업까지 내려가 본다.

늦어진 작업 찾기 2: 「진행 상황 Gantt」

같은 것을 그림으로 보려면 「진행 상황 Gantt」 보기를 쓴다. [보기] 탭의 「다른 보기」에서 「기타…」를 누르고, 목록에서 「진행 상황 Gantt」를 골라 「적용」을 누른다.

이 보기는 작업마다 막대를 두 줄로 그린다. 한 줄은 지금 일정이고 다른 한 줄은 기준선이다. 두 막대가 어긋난 만큼이 차이다. 표는 며칠인지를 정확히 보여 주고, 그림은 어디서부터 어긋나기 시작했는지를 한눈에 보여 준다. 회의 자료로는 그림이, 원인을 따질 때는 표가 낫다.

프로젝트 전체 숫자만 빨리 보려면 [프로젝트] 탭의 「프로젝트 정보…」를 열고 「통계…」를 누른다. 지금 일정과 기준선, 실제 값, 그 차이가 한 창에 나온다.

기준선을 다시 저장하면 생기는 일

같은 이름에 다시 저장하면 앞서 저장한 값이 덮어써진다. 일정이 2주 밀린 뒤에 「초기 계획」에 다시 저장하면 차이는 모두 0이 되고, 처음 약속이 며칠이었는지는 파일에서 사라진다. 차이가 0이 된 것은 따라잡아서가 아니라 기준을 옮겨서다.

그렇다고 새 계획을 「초기 계획 1」에만 저장해 두면 다른 문제가 생긴다. Microsoft 문서에 따르면 기준선이 여러 개여도 차이를 계산할 때는 처음 것, 곧 번호 없는 「초기 계획」의 값만 쓴다. 「초기 계획 1」에 저장한 새 계획은 「차이」 테이블에 반영되지 않는다.

그래서 변경이 승인되어 계획을 다시 세웠을 때는 두 단계로 한다.

1. 앞의 기준선을 옮겨 둔다. 「초기 계획 설정」 창에서 「임시 계획 설정」을 고르고, 「복사」에 「초기 계획」, 「붙여넣기」에 「초기 계획 1」을 고른 뒤 「확인」을 누른다. 양쪽 모두 기준선을 고르면 날짜만이 아니라 기준선 값 전체가 옮겨진다.
2. 새 계획을 「초기 계획」에 저장한다. 이제 「차이」 테이블은 새로 승인된 계획과 견주고, 처음 약속은 「초기 계획 1」에 남는다.

상황별로 정리하면 아래와 같다.

표는 가로로 밀어서 볼 수 있습니다.

「초기 계획 설정」 창의 목록에는 이미 저장한 기준선 이름 옆에 저장한 날짜가 붙는다. 다시 저장하기 전에 이 날짜를 보고, 고른 번호가 비어 있는 번호인지 확인한다.

작업 몇 개만 「선택한 작업」으로 저장할 때는 창 아래쪽의 「초기 계획을 겹쳐서 표시할 항목」을 본다. 「모든 요약 작업」을 켜면 추가한 작업의 값이 위쪽 요약 작업의 기준선에도 반영된다. 켜지 않으면 요약 작업의 기준선은 예전 값 그대로라, 아래 작업을 더한 것과 맞지 않게 된다. 승인된 변경으로 추가한 작업이면 요약 작업까지 반영하는 쪽이 맞다.

여러 번호에 저장해 두었으면 「여러 초기 계획 Gantt」 보기에서 함께 볼 수 있다. Microsoft 문서에 따르면 이 보기는 기본으로 앞의 세 개만 그리고, 그 뒤 번호를 보려면 막대 스타일을 고쳐야 한다.

기준선과 비슷한 것으로 「임시 계획」이 있다. 같은 창의 「임시 계획 설정」에서 저장하고 열 개까지 둘 수 있다. 임시 계획은 시작 날짜와 완료 날짜만 저장하므로, 작업 시간과 비용은 비교할 수 없다. 월말마다 날짜만 찍어 두고 일정이 어떻게 움직였는지 볼 때 쓴다.

자주 하는 실수

• 진행을 입력한 뒤에 저장한다. 이미 밀린 날짜가 처음 계획이 된다.
• 늦어질 때마다 같은 기준선에 다시 저장한다. 차이가 늘 0이라 보기에는 좋지만, 기준선을 둔 까닭이 없어진다.
• 작업을 추가하고 기준선에 넣지 않는다. 그 작업은 기준선 값이 없어 차이를 믿을 수 없다.
• 요약 작업의 차이만 본다. 어느 작업에서 시작됐는지는 맨 아래 작업에 있다.
• 새 계획을 번호 있는 기준선에만 저장한다. 「차이」 테이블은 여전히 번호 없는 「초기 계획」과 견준다.
• 어느 번호가 무엇인지 적어 두지 않는다. 「초기 계획 1」이 언제의 어떤 계획인지 프로젝트 문서에 한 줄 남긴다.

이번 주에 할 일

1. 진행 중인 일정 파일을 열고 「초기 계획 설정」 창의 목록에서 저장한 날짜가 붙은 기준선이 있는지 본다.
2. 없으면, 지금 일정이 승인된 계획과 같은지 확인하고 저장한다. 이미 진행 중이라면 「지금부터의 기준」으로 저장하는 것이고 처음 약속과의 차이는 아니라는 점을 팀에 알린다.
3. 있으면, 「차이」 테이블을 열어 「시작 날짜 차이」는 0이고 「완료 날짜 차이」만 있는 작업을 찾는다. 그 작업이 왜 길어졌는지 확인해 다음 보고에 적는다.

기준선이 왜 일정표의 조건인지는 「간트차트 그리는 법」 글에서, 기준선을 바탕으로 일정과 비용 성과를 숫자로 보는 법은 「MS Project에서 획득가치분석(EVM) 보기」 글에서 이어서 볼 수 있다.

참고

• Microsoft 지원 문서 「Create or update a baseline or an interim plan in Project desktop」(https://support.microsoft.com/en-us/office/create-or-update-a-baseline-or-an-interim-plan-in-project-desktop-7e775482-ac84-4f4a-bbd0-592f9ac91953), 「Set and save a baseline」(https://support.microsoft.com/en-us/office/set-and-save-a-baseline-ac855151-34f2-42e8-8b05-c363dced3089). 기준선 열한 개, 임시 계획 열 개, 저장되는 값의 갈래, 다시 저장하면 덮어쓴다는 점, 차이 계산에는 처음 기준선만 쓴다는 점, 기준선을 다른 기준선으로 옮기는 방법, 「여러 초기 계획 Gantt」가 앞의 세 개만 그린다는 점은 이 문서의 내용이다. 문서에 게시일 표시가 없어 2026-10-13에 본 판을 기준으로 했다.
• 한국어 화면 이름은 Microsoft 365 구독의 한국어판 Project 데스크톱 화면에서 확인했다. 판이나 갱신 시점에 따라 다를 수 있다.
• 예의 일정과 날짜, 차이 값은 설명을 위해 만든 가상의 것이고, 실제 파일에서 뽑은 값이 아니다.
• 언제 저장하고 언제 번호를 나누는지, 자주 하는 실수는 실무 경험칙을 정리한 것이다. Microsoft가 정한 규칙이 아니다.
• 이 글은 Microsoft와 관계가 없는 독립 해설입니다.
• Microsoft, Microsoft 365, Project는 Microsoft 그룹 회사의 상표입니다.