테크 랩

PMBOK 완독기 – 02. 통합관리: 프로젝트 헌장과 변경통제 (4장)

2026.10.26

3줄 요약

프로젝트 통합관리(4장)는 범위·일정·원가·리스크 등 나머지 9개 지식영역을 하나의 큰 그림으로 묶는 우산 역할이다.
핵심 산출물인 프로젝트 헌장(Charter)은 프로젝트를 공식 출범시키고 PM에게 실질 권한을 부여하는 계약서다.
현장에서는 무거운 CCB(변경통제위원회) 대신 “기준선에 영향 주는 큰 변경만 명시적 합의”하는 경량 변경관리 프로세스가 현실적이다.

“변경은 어차피 생긴다. 문제는 그 변경이 일정에만 흡수되고, 비용·범위·품질이 조용히 희생되는 줄 아무도 모른다는 거다.”

프로젝트를 맡아보면 한 가지 패턴을 금방 배운다. 개발팀이 “이거 하나 바꿔도 돼요?”라고 물을 때, 그 ‘하나’는 실은 하나가 아니다. 화면 레이아웃을 바꾸면 API 스펙이 바뀌고, API가 바뀌면 테스트 케이스가 무너지고, 테스트가 늘어나면 릴리즈 일정이 밀린다. PMBOK 4장 통합관리(Project Integration Management)는 바로 이 연쇄 반응을 관리하기 위한 장이다.

📖 정석이 말하는 것: 프로젝트를 하나로 묶는 7가지 프로세스

PMBOK 6판은 통합관리를 7개 프로세스로 구성한다. 실전에서 빈번히 마주치는 것들 위주로 압축하면 다음과 같다.

프로젝트 헌장 개발(Develop Project Charter): 프로젝트를 공식 출범시키는 문서를 만드는 프로세스. 스폰서(발주자)가 서명한 헌장이 있어야 PM은 조직 자원을 합법적으로 동원할 수 있다. 권한 부여 문서이자 계약서다.
프로젝트관리계획서 개발(Develop Project Management Plan): 범위·일정·원가·리스크 등 각 지식영역 계획서를 통합하는 마스터 플랜. “모든 계획서의 계획서”다.
프로젝트 작업 지시 및 관리(Direct and Manage Project Work): 계획을 실제 실행으로 전환하는 프로세스. 일상적인 PM 업무 대부분이 여기에 해당한다.
프로젝트 지식 관리(Manage Project Knowledge): 7판에서 비중이 커진 개념. 프로젝트에서 창출·활용된 지식을 조직 자산으로 보존한다.
프로젝트 작업 감시 및 통제(Monitor and Control Project Work): 계획 대비 실적을 추적하고 편차를 탐지한다.
통합 변경통제 수행(Perform Integrated Change Control): 모든 변경 요청을 검토·승인·기각하는 프로세스. CCB(Change Control Board, 변경통제위원회)가 운영 주체다.
프로젝트 또는 단계 종료(Close Project or Phase): 인수·완료·교훈(Lessons Learned) 문서화를 통해 프로젝트를 마무리한다.

이 중 프로젝트 헌장과 통합 변경통제(CCB)는 통합관리의 양쪽 기둥이다. 시작을 공식화하고, 중간의 변경을 통합적으로 통제하는 것이 이 장의 핵심이다.

✅ 읽으며 좋았던 점: 변경을 ‘통합적으로’ 본다는 시각

PMBOK 4장에서 가장 가치 있는 통찰은 “변경은 연쇄 효과를 가진다”는 명시적 선언이다. 많은 팀이 변경을 요청받은 영역만의 문제로 처리한다. 기능 하나가 추가되면 개발팀은 개발 공수만 본다. 하지만 범위가 늘면 테스트 공수가 늘고, 테스트가 늘면 일정이 밀리고, 일정이 밀리면 인건비(원가)가 오른다. 통합관리는 이 연쇄를 명시적으로 보자고 요구한다.

프로젝트 헌장의 가치도 재확인했다. 헌장이 없는 프로젝트는 PM이 “부탁하는 사람”이 된다. 헌장이 있으면 PM은 “권한 위임받은 사람”이 된다. 조직에서 PM의 권한은 직위가 아니라 문서에서 나온다는 사실을 4장은 명확히 가르쳐 준다.

⚠️ 현장과의 괴리: CCB가 개발 속도를 멈춘다

실전에서 통합 변경통제의 가장 큰 장벽은 속도다. 정식 CCB 프로세스는 변경 요청서 작성 → 영향 분석 → 위원회 소집 → 승인 → 기준선 수정 → 공지의 절차를 거친다. 2주 단위 스프린트를 돌리는 팀이 이 절차를 거치면 변경 하나를 처리하는 데 스프린트 한 사이클이 소요된다. 결과적으로 CCB는 “우리 팀은 정식으로 안 한다”는 암묵적 합의 아래 유명무실해지는 경우가 많다.

헌장도 마찬가지다. 스타트업이나 내부 프로젝트에서는 “그냥 해봐”로 시작하는 경우가 태반이다. 헌장을 작성하는 것 자체가 일이 되고, 이해관계자를 모아 서명을 받는 것도 현실적으로 쉽지 않다. 그래서 프로젝트가 공식 출범하지 않은 채로 이미 3개월째 개발 중인 상황이 생긴다. PM은 권한 없이 요청과 통보로만 일하는 구조가 반복된다.

방대한 프로젝트관리계획서도 현장과 괴리를 만든다. PMBOK 정석대로 모든 하위 계획서를 갖추면 문서량이 상당하다. 실제로 “이 문서 마지막으로 업데이트한 게 언제야?”라는 질문에 답을 못하는 팀이 대부분이다. 계획서가 현실을 반영하지 못하면 계획서는 신뢰를 잃고, 아무도 보지 않는 파일이 된다.

🔧 실전 번역: 경량 헌장과 선별적 변경통제

통합관리의 핵심 원리는 유지하되, 현장 속도에 맞게 경량화하는 것이 실전 번역의 요점이다.

1페이지 경량 헌장 (Lean Charter)

정식 헌장을 A4 10장으로 쓸 필요는 없다. 다음 5가지 항목을 1페이지에 담으면 헌장으로서의 기능을 충분히 한다.

목적: 이 프로젝트는 왜 하는가 (비즈니스 목표 1~2줄)
스코프(범위) 경계: 무엇을 하고, 무엇은 하지 않는가 (In-scope / Out-of-scope)
성공 기준: 어떤 상태가 되면 완료인가 (DoD, 완료 정의와 연결)
핵심 이해관계자: 스폰서·PM·주요 의사결정권자 (RACI 축약본)
예산 상한과 일정 제약: 고정값이면 명시, 아니면 범위로 표기

이 1페이지를 킥오프 미팅 전에 이해관계자와 공유하고, 이견을 정리한 뒤 서명(또는 메일 승인)을 받아두면 충분하다. 프로젝트가 흔들릴 때마다 꺼내 볼 수 있는 “공동의 근거”가 생긴다.

선별적 변경통제: 기준선 영향 여부가 기준

모든 변경을 CCB에 올리는 것은 비현실적이다. 그렇다고 모든 변경을 백로그에서 조용히 흡수하면 범위·일정·원가 기준선이 알게 모르게 이동한다. 실전에서 쓸 수 있는 판단 기준은 하나다.

기준선(Baseline)에 영향을 주는가? → 영향 있으면 명시적 합의(이해관계자 확인·문서화)
기준선 안에서 처리되는가? → 팀 자체 판단으로 백로그 우선순위 재조정

예를 들어 “버튼 색상 변경”은 기준선에 영향 없다. 반면 “결제 모듈을 이번 릴리즈에 포함”은 범위 기준선을 건드린다 — 이 경우는 이해관계자와 공식 합의가 필요하다. 기준선이란 범위·일정·원가를 아우르며, 셋 중 하나라도 계획 수치가 바뀌면 기준선 변경으로 본다. 이 판단 기준 하나만 팀 안에서 공유해도 “몰래 변경”이 줄어든다.

🟥 PSTA로 보면 / 🟨 PSTA도 아쉬운 점

PSTA로 보면

PSTA의 P-S-A(Project → Service → Action) 3계층 트리는 통합관리가 요구하는 “하나의 통합 골격”을 구조적으로 구현한다. 프로젝트 하위에 기능 단위(Service)와 실행 단위(Action)를 트리로 연결하면, 어떤 Action이 어떤 Service에, 어떤 Service가 어떤 Project에 속하는지 한눈에 보인다. 또한 산출물과 보고서를 스냅샷으로 “박제”하는 기능은 PMBOK의 지식 관리 프로세스 — 교훈 문서화와 산출물 보존 — 와 맥이 닿는다. 변경이 발생했을 때 이전 상태의 스냅샷이 남아 있으면 “언제, 무엇이, 어떻게 바뀌었는지”에 대한 근거가 생긴다.

다만 PSTA도 아쉬운 점이 있다. 정식 변경통제(변경 요청 접수 → 영향 분석 → 승인 워크플로 → 기준선 갱신)를 위한 전용 기능은 없다. 변경 이력을 공식적으로 추적하는 승인 플로우, CCB 회의록 같은 기능은 현재 PSTA의 의도적 빈칸이다. 변경 관리가 중요한 대형 프로젝트라면 별도 승인 도구를 병행하거나, 변경 내용을 Action 설명과 스냅샷으로 수동 기록하는 방식으로 보완해야 한다.

🎓 이 장을 떼면 당신은 이것을 할 수 있다

프로젝트 시작 전 1페이지 경량 헌장을 작성해 이해관계자와 합의하고, PM으로서의 역할과 권한을 명문화할 수 있다.
“기준선에 영향을 주는 변경인가?”를 기준으로 변경의 공식 합의 여부를 판단할 수 있다.
범위·일정·원가·품질을 하나의 연결된 시스템으로 보고, 변경의 연쇄 효과를 이해관계자에게 설명할 수 있다.
프로젝트 종료 시 교훈과 산출물을 정리해 조직 자산으로 남길 수 있다.
무거운 CCB 없이도 변경을 투명하게 관리하는 경량 프로세스를 설계할 수 있다.

❓ FAQ

프로젝트 헌장이 꼭 필요한가?

법적 의무는 아니지만, 헌장이 없으면 PM의 권한이 암묵적 관계에만 의존하게 된다. 프로젝트가 규모가 작더라도 “목적·스코프·성공 기준·예산 상한”을 한 페이지로 정리해 이해관계자 서명을 받아두면, 나중에 “그게 범위에 있었어?”류의 분쟁을 사전에 차단할 수 있다. 1페이지 경량 헌장이라면 작성 부담도 크지 않다.

애자일 팀도 변경통제가 필요한가?

필요하다. 다만 방식이 다르다. 애자일은 변경을 백로그에서 우선순위 재조정으로 흡수하는데, 이것 자체가 변경통제의 경량화 버전이다. 핵심은 모든 변경이 백로그를 통해 가시화되고, 팀이 우선순위 결정을 투명하게 한다는 점이다. “기준선(릴리즈 스코프·예산)에 영향을 주는 큰 변경”만큼은 스폰서와 명시적 합의를 거치는 것이 애자일 팀에서도 권장된다.

소규모 프로젝트의 최소 헌장은 어떻게 구성하나?

5개 항목으로 충분하다. ① 프로젝트 목적(비즈니스 이유 1~2줄) ② 스코프 경계(In/Out-of-scope) ③ 성공 기준(완료 조건) ④ 핵심 이해관계자(스폰서·PM) ⑤ 예산 상한·일정 제약. 이 5가지를 이메일이나 협업 도구 문서 하나에 정리하고 스폰서 확인을 받으면 간이 헌장으로 기능한다. 형식보다 “합의”가 핵심이다.

변경 요청을 어떻게 관리하면 좋은가?

변경 요청이 들어왔을 때 판단할 것은 두 가지다. 첫째, 이 변경이 범위·일정·원가 기준선 중 하나라도 바꾸는가? 그렇다면 이해관계자와 공식 합의 후 기준선을 갱신한다. 둘째, 기준선 안에서 처리 가능한가? 그렇다면 백로그 우선순위 재조정으로 흡수한다. 어떤 경우든 변경 내용을 기록으로 남기는 것이 핵심이다. “말로 했으니까”로 처리된 변경은 나중에 반드시 분쟁의 씨앗이 된다.

프로젝트 통합관리는 화려한 기법보다 “연결”에 대한 감각을 요구한다. 한 곳을 바꾸면 어디가 흔들리는지를 미리 보는 능력, 그리고 그 흔들림을 이해관계자와 투명하게 공유하는 습관이 이 장의 본질이다. PSTA 도입이나 프로젝트 관리 체계 정비가 필요하다면 주니크에 문의하거나 PSTA를 직접 살펴보기를 권한다.

『PMBOK 완독기』 시리즈
← 이전: 01. PM은 실제 뭘 하는 사람인가 (1~3장)
→ 다음: 03. 범위관리: WBS와 스코프 크립 (5장)

다른 글 보기