[PMP Study -13Days] 통합 관리 & 변경 관리 – 베이스라인, 변경요청, CCB(변경통제위원회)

1장. 통합(Integration) 관리란 뭐 하는 건가?

지금까지 우리는 범위/일정/비용/품질/리스크/조달/팀/이해관계자 등
“개별 영역(knowledge area)” 를 따로 공부했어요.

통합 관리(Integration Management) 는 한 줄로 말하면:

“이 모든 것들을 한 방향으로 맞추고,
프로젝트 전체를 하나로 조율하는 일”

1-1. 왜 ‘통합’이 필요할까?

현실에서 흔히 이런 일이 생깁니다.

• 일정 맞추려고 범위를 몰래 줄이거나
• 품질 올리려고 비용을 몰래 늘리거나
• 특정 이해관계자 눈치 보느라 갑자기 우선순위를 바꾸거나…

각 영역을 따로따로 관리하면:

• 한쪽 맞추면 다른 쪽이 깨지고
• 누가 어디서 뭘 바꿨는지 알 수 없게 됩니다.

그래서 PMP에서 PM의 가장 중요한 역할 중 하나는:

“각 영역을 연결해서, 전체 관점에서 균형을 맞추는 사람”

이라고 보는 거예요.

---

1-2. 통합 관리 프로세스(이름만 잡기)

PMBOK(6판 기준)에서 통합 관리는 보통 이렇게 구성돼요. (이름 정도만 익혀두기)

1. Develop Project Charter – 프로젝트 헌장 만들기
2. Develop Project Management Plan – 통합 프로젝트 계획서
3. Direct and Manage Project Work – 실제 작업 지휘/관리
4. Manage Project Knowledge – 교훈/노하우 관리
5. Monitor and Control Project Work – 전체 진행 상황 모니터링/통제
6. Perform Integrated Change Control – 통합 변경 관리 (오늘 핵심)
7. Close Project or Phase – 프로젝트/단계 종료

이 중 오늘 집중할 부분이 바로 6번:
**Perform Integrated Change Control (통합 변경 관리)**입니다.

---

2장. 베이스라인(Baseline)과 변경(Change)의 개념

2-1. 베이스라인이 뭐야?

베이스라인 = 공식적으로 승인된 기준선

조금 더 풀면:

• “이 기준을 기준점으로 삼아,
  이후 변경 여부를 판단하는 값/계획”이에요.

대표적인 3가지 베이스라인:

1. Scope Baseline (범위 기준선)
   • 어떤 일을 할지에 대한 기준
   • 범위 명세서 + WBS + WBS Dictionary
2. Schedule Baseline (일정 기준선)
   • 언제 무엇을 할지에 대한 기준
   • 승인된 일정(간트 차트, 마일스톤 계획 등)
3. Cost Baseline (비용 기준선)
   • 얼마를 쓸지에 대한 기준
   • 시간 축에 따라 언제 얼마를 쓸지 포함된 예산 곡선

시험 포인트

• “베이스라인이 설정되었다” =
  이제부터는 이 기준을 바꾸려면 공식적인 변경 승인이 필요하다는 뜻.

---

2-2. 변경(Change)과 Scope Creep

변경(Change) 자체는 나쁜 게 아닙니다.

• 시장 변화, 고객 요구, 법·규제 변경 등으로
  바꾸지 않으면 안 되는 상황이 더 많죠.

문제는 “어떻게 바꾸느냐” 입니다.

Scope Creep(스코프 크립) 이란?

공식 절차 없이,
슬금슬금 일이 늘어나 버리는 현상

예:

• “이왕 하는 김에 이 기능도 넣어주세요.”
• “그거 별 거 아닌데 그냥 같이 해주세요.”

이렇게 비공식적으로 들어오는 요구들을 계속 받아주면:

• 일정/비용은 늘어남
• 팀은 지치고
• 나중에 누구 책임인지도 모호해짐

PMP가 말하는 바람직한 방식은:

“변경 자체를 막는 게 아니라,
모든 변경을 공식적인 변경 관리 프로세스를 통해 처리하자.”

---

3장. 통합 변경 관리(Perform Integrated Change Control)

이제 핵심 파트입니다.
“변경이 들어왔을 때 PM이 어떻게 움직여야 하는가?”

3-1. 변경 관리의 전형적인 흐름

아주 중요한 6단계 흐름을 텍스트 플로우로 정리해볼게요.

1. 변경 요청 발생 (Change Request 제출)
   • 누가 “이걸 바꾸자”고 제안
   • 구두 말고, 공식 Change Request로 문서화하는 게 원칙
2. 변경 요청 기록 (Change Log에 등록)
   • 언제, 누가, 어떤 변경을 요청했는지
   • 요청 상태(접수/분석 중/승인/기각) 관리
3. 영향 분석 (Impact Analysis)
   • 이 변경이 범위/일정/비용/품질/리스크/자원에 어떤 영향을 주는지 분석
   • 예:
     • 일정 +2주, 비용 +1000만 원, 리스크 상승 등
   • PM이 직접 하거나, 팀에 분석 요청
4. CCB 등에서 승인/기각 결정
   • CCB(Change Control Board) 또는 승인 권한자들이
   • 분석 결과를 보고 승인/보류/기각 결정
5. PM이 계획/문서/베이스라인 업데이트
   • 승인된 경우:
     • 관련 계획서(범위, 일정, 비용, 리스크 등) 업데이트
     • 필요 시 베이스라인도 갱신
   • 기각된 경우:
     • 그 사유를 기록하고, 요청자에게 설명/커뮤니케이션
6. 변경사항 커뮤니케이션 & 실행
   • 어떤 변경이 확정되었는지
   • 누구에게 어떤 영향이 있는지
   • 담당자/팀에게 알리고 실제 작업 반영

시험에서 자주 나오는 패턴:

• “영향 분석 없이 바로 변경을 적용했다” → 오답
• “먼저 영향 분석을 하고, 공식 승인 후에 반영했다” → 정답

---

3-2. “복도에서 만난 지원요청” 문제

시험에 정말 자주 나오는 패턴 하나를 예로 들어볼게요.

운영팀장이 복도에서 PM을 붙잡고 말합니다.
“그 화면에 필터 하나만 더 넣어주세요. 별 거 아니에요.”

선택지에서 PMP스럽지 않은 행동:

• “별것 아니라고 하니 바로 개발팀에 이야기해서 넣어준다.”
• “운영팀과 친하니까 그냥 몰래 넣어준다.”
• “일단 넣고, 나중에 문서 정리한다.”

PMP 답에 가까운 행동:

• “좋은 의견이라 생각되면,
  공식 변경요청(Change Request) 를 제출해 달라고 요청”
• 변경으로 인한 영향 분석 후,
  CCB/승인권자가 승인하면 일정/비용/우선순위를 조정해 수행

키워드:
“공식 절차 + 영향 분석 + 승인 후 반영”

---

3-3. CCB(Change Control Board)란?

변경 요청을 검토하고 승인/기각하는 역할을 가진 사람들의 그룹

• 구성:
  • 스폰서, 주요 이해관계자 대표, PM 등
  • 프로젝트 규모/조직에 따라 다름
• 역할:
  • 중요한 변경 요청들을 합리적으로 심의
  • 프로젝트 전체 목표/비즈니스 가치 관점에서 판단

시험 포인트:

• PM이 혼자서 모든 변경을 독단적으로 결정하는 것은 아님
• 특히 범위/일정/비용/품질 베이스라인에 영향이 큰 변경은
  → CCB 또는 적절한 승인 권한자가 결정해야 함

---

3-4. 통합 변경 관리에서 자주 하는 실수 vs PMP 정답

잘못된 행동 (오답 쪽)

• “고객이니까 무조건 들어준다.”
• “작아 보이는 변경이라 영향 분석 없이 바로 진행한다.”
• “먼저 구현해놓고, 잘 되면 나중에 보고한다.”
• “문서는 귀찮으니 구두로만 합의했다.”

바람직한 행동 (정답 쪽)

• 변경은 항상 Change Request → Change Log로 기록
• 먼저 영향 분석: 범위/일정/비용/리스크 등
• 적절한 승인 권한자/CCB 통해 승인/기각 결정
• 승인되면 베이스라인/계획/문서 업데이트 후 실행
• 결과와 변경 사항을 이해관계자에게 명확히 커뮤니케이션

---

4장. 오늘 내용 5줄 요약

1. 통합 관리는 범위/일정/비용/품질/리스크/조달/팀/이해관계자를 전체 관점에서 조율하는 영역이며, 그중 통합 변경 관리가 핵심 역할이다.
2. 베이스라인(Baseline) 은 공식 승인된 기준선으로, 변경 시에는 반드시 공식적인 변경 승인 절차를 거쳐야 한다.
3. 변경 관리는 보통 요청 접수 → Change Log 기록 → 영향 분석 → 승인/기각 → 계획/문서/베이스라인 업데이트 → 커뮤니케이션 & 실행 순서로 진행된다.
4. CCB(Change Control Board)는 중요한 변경 요청을 검토·승인하는 대표 그룹으로, PM이 독단적으로 모든 변경을 결정하는 것은 PMP 관점에서 바람직하지 않다.
5. PMP 문제에서는 “공식 변경요청 + 영향 분석 + 승인 후 반영”을 정답으로, “몰래/구두/바로 구현”을 오답으로 보는 경우가 많다.

---

5장. 연습문제 (Day 13 Check)

객관식·O/X 8문제 + 서술형 2문제

문제 1

다음 중 베이스라인(Baseline) 에 대한 설명으로 가장 적절한 것은?

A. 프로젝트 초기에 대략 잡아보는 초안 계획이다.
B. 프로젝트 도중 아무 때나 자유롭게 바꿀 수 있는 임시 값이다.
C. 공식적으로 승인된 계획/기준으로, 변경 시에는 승인 절차가 필요하다.
D. 실제 실행 결과를 의미하며, 변경 관리와는 관련이 없다.

---

문제 2

다음 중 통합 변경 관리(Perform Integrated Change Control) 의 핵심 목적은?

A. 모든 변경 요청을 최대한 빨리 승인해서 고객을 만족시키는 것
B. 변경 요청 없이도 PM이 필요하다고 생각하는 변경을 바로 적용하는 것
C. 변경 요청을 체계적으로 접수·분석·승인/기각하고, 베이스라인과 계획을 일관되게 관리하는 것
D. 리스크를 변경 요청으로 모두 대체하는 것

---

문제 3

다음 중 PMP 관점에서 가장 적절한 PM의 행동은?

운영팀에서 “화면 필터 하나만 추가해달라, 별 것 아니다”라는 요청이 구두로 들어왔다.

A. 별 것 아니라고 하니 개발 팀에 바로 전달해 구현한다.
B. 스폰서에게 알리지 않고 조용히 반영한다.
C. Change Request로 공식 접수를 요청하고, 영향 분석 후 승인되면 일정/비용을 조정해 반영한다.
D. 귀찮으니 무시한다.

---

문제 4 (O/X)

“Scope Baseline, Schedule Baseline, Cost Baseline은
공식 승인된 기준이므로, 변경하려면 반드시 적절한 승인 절차를 거쳐야 한다.”

---

문제 5

다음 중 CCB(Change Control Board) 에 대한 설명으로 옳지 않은 것은?

A. 중요한 변경 요청을 검토하고 승인/기각하는 역할을 한다.
B. 스폰서, 주요 이해관계자, PM 등으로 구성될 수 있다.
C. PM이 혼자서 모든 변경을 독단적으로 결정하지 않도록 견제하는 기능도 한다.
D. 모든 프로젝트에서 반드시 CCB라는 이름의 조직을 구성해야 한다.

---

문제 6

다음 중 변경 관리의 일반적인 흐름을 올바르게 나열한 것은?

① 영향 분석
② 변경 요청 기록(로그)
③ 변경 요청 접수
④ 승인/기각 결정
⑤ 계획/문서/베이스라인 업데이트
⑥ 변경 사항 커뮤니케이션 및 실행

A. ③ → ② → ① → ④ → ⑤ → ⑥
B. ② → ③ → ① → ④ → ⑤ → ⑥
C. ③ → ① → ② → ④ → ⑤ → ⑥
D. ① → ② → ③ → ④ → ⑤ → ⑥

---

문제 7 (O/X)

“Scope Creep(스코프 크립)은 공식 변경 관리 절차를 통해 승인된 변경들이 누적되어
프로젝트 범위가 합리적으로 확장되는 것을 의미한다.”

---

문제 8

다음 중 PMP 관점에서 좋은 PM 행동으로 보기 어려운 것은?

A. 모든 변경 요청을 Change Log에 기록하고 상태를 추적한다.
B. 변경 요청이 들어오면 먼저 범위/일정/비용/리스크에 대한 영향을 분석한다.
C. 작은 변경이므로 영향 분석과 승인 없이 바로 일정에 반영한다.
D. 승인된 변경에 따라 관련 계획서와 베이스라인을 업데이트하고 이해관계자에게 알린다.

---

서술형

문제 9 (서술형)

최근(또는 가상의) 프로젝트를 떠올리고,
실제로 있었거나 있을 법한 변경 요청 2가지를 써보세요.

각각에 대해:

• 변경 요청 내용
• 어떤 베이스라인/계획에 영향을 주는지 (Scope/Schedule/Cost 등)
• PM 입장에서 어떤 영향을 분석해야 할지 간단히 적어보세요.

---

문제 10 (서술형)

다음 문장을 자신의 상황에 맞게 완성해보세요.

“내가 앞으로 수행할 프로젝트에서
변경 관리에서 가장 신경 쓰고 싶은 부분은 ____ 이고,
이를 위해 모든 변경은 먼저 ____ 과(와) 같은 형식으로
공식 Change Request를 받도록 해보려고 한다.”

(예: “문서로, 영향 분석 항목 포함”, “Jira 티켓 템플릿”, “변경 사유/영향/우선순위 포함 양식” 등)

---

6장. 정답 & 짧은 해설

문제 1 정답: C

• 베이스라인은 공식 승인된 기준이며, 변경 시 승인 절차 필요.
• A/B/D는 모두 불완전하거나 잘못된 설명.

---

문제 2 정답: C

• 통합 변경 관리의 핵심:
  → 변경 요청을 체계적으로 처리하고,
  → 베이스라인/계획의 일관성을 유지하는 것.

---

문제 3 정답: C

• PMP스러운 답:
  공식 Change Request → 영향 분석 → 승인 후 반영.
• A/B는 비공식, D는 무시라서 모두 부적절.

---

문제 4 정답: O

• 세 가지 베이스라인은 승인된 기준이므로,
  변경 시에는 반드시 승인 절차(변경 관리)를 거쳐야 합니다.

---

문제 5 정답: D

• “반드시 CCB라는 이름의 조직”은 필요 없음.
  규모/환경에 따라 형태는 달라질 수 있음.
• A/B/C는 모두 올바른 설명.

---

문제 6 정답: A

올바른 순서:

• ③ 변경 요청 접수
• ② 변경 요청 기록(로그)
• ① 영향 분석
• ④ 승인/기각 결정
• ⑤ 계획/문서/베이스라인 업데이트
• ⑥ 변경 사항 커뮤니케이션 및 실행

---

문제 7 정답: X

• Scope Creep = 공식 절차 없이 슬금슬금 범위가 늘어나는 것.
• 승인된 변경들이 합리적으로 반영된 건 정상적인 범위 관리입니다.

---

문제 8 정답: C

• C는 “작아 보이니 그냥 한다” 류의 행동 → PMP에서 가장 싫어하는 패턴.
• A/B/D는 모두 좋은 변경 관리 행동.

---

문제 9·10 (서술형)

• 정답은 없고,
  • 실제/가상의 사례를 변경 관리 흐름에 대입해 보는 연습,
  • “어떤 양식/도구로 Change Request를 받을지”를 구체화해 보는 게 핵심입니다.