PMBOK 완독기 – 01. PM은 실제 뭘 하는 사람인가 (서론·환경·역할, 1~3장)

“그래서 PM이 정확히 무슨 일을 하는 사람인가요?” — 팀에 처음 합류한 개발자가 나에게 물었을 때, 나는 잠시 말을 잃었다. 일정 짜는 사람? 회의 진행자? 아니면 모든 일에 책임지는 사람? PMBOK 1~3장은 바로 이 질문에 답하는 장이다. 프로젝트 관리자(PM)란 무엇을 하는 사람인지, 어떤 환경에서 어떤 권한으로 일하는지를 정의한다.

프로젝트 관리자(PM)란 무엇을 하는 사람인가? PMBOK은 PM을 “프로젝트 목표를 달성하기 위해 팀을 이끄는 통합자이자 리더”로 정의한다. 핵심은 ‘통합자’라는 단어다. 범위·일정·원가·품질·자원·리스크 등 여러 제약 사이에서 균형을 잡으며 결과물을 만들어 내는 것이 PM의 본질이다. 그리고 그 권한과 영향력은 PM 개인의 역량 못지않게 조직 구조에 의해 결정된다.

📖 정석이 말하는 것: 프로젝트·환경·PM 역할의 정의

1장 — 프로젝트란 무엇인가

PMBOK은 프로젝트를 “한시적(temporary)으로 고유한 제품·서비스·결과물을 만들어내는 노력”으로 정의한다. 핵심은 두 가지다. 첫째, 한시적이다. 시작과 끝이 있다. 둘째, 고유하다. 반복 업무(운영, operations)와 다르다. 서비스를 유지보수하는 일은 운영이고, 그 서비스의 새 기능을 기획·개발·출시하는 일은 프로젝트다.

프로젝트는 독립적으로 존재하지 않는다. PMBOK은 프로젝트·프로그램·포트폴리오의 관계를 다음과 같이 정리한다.

• 프로젝트(Project): 단일 결과물을 목표로 하는 한시적 노력.
• 프로그램(Program): 관련 프로젝트들을 묶어 시너지를 내는 관리 단위. 개별 프로젝트 관리로는 얻지 못하는 편익을 추구한다.
• 포트폴리오(Portfolio): 전략 목표를 달성하기 위해 프로그램과 프로젝트, 운영 업무를 선택·우선순위화·관리하는 최상위 단위.

그리고 모든 프로젝트에는 6개의 제약(constraints)이 따라온다: 범위(scope)·일정(schedule)·원가(cost)·품질(quality)·자원(resources)·리스크(risk). 하나를 건드리면 다른 것이 영향을 받는다. 이 6각형을 PM이 항상 들여다봐야 하는 이유다.

2장 — 프로젝트가 놓인 환경

프로젝트는 진공 속에서 진행되지 않는다. 외부와 내부 환경이 프로젝트에 영향을 준다. PMBOK은 이를 두 가지로 나눈다.

• 기업환경요인(EEF, Enterprise Environmental Factors): 조직이 통제하기 어려운 외부·내부 조건. 법규·시장 상황·조직 문화·팀원 역량·인프라 등. PM은 EEF를 인식하되, 직접 바꾸기 어렵다는 것을 알아야 한다.
• 조직프로세스자산(OPA, Organizational Process Assets): 조직이 축적해 온 프로세스·정책·절차·과거 프로젝트 데이터·교훈(lessons learned). 잘 정리된 OPA는 PM의 공수 산정과 리스크 예측에 실질적인 도움이 된다.

그리고 2장에서 가장 실전적인 내용이 나온다: 조직 구조. PMBOK은 세 가지 대표 구조를 제시한다.

• 기능형 조직(Functional): 개발팀·마케팅팀·디자인팀처럼 기능 단위로 묶인 구조. PM의 공식 권한이 매우 약하다. 팀원은 자기 상위 기능 관리자(팀장)에게 우선 보고한다.
• 프로젝트형 조직(Projectized): 프로젝트 중심으로 팀이 구성된다. PM의 권한이 가장 강하다. 건설·방산·컨설팅에 흔하다.
• 매트릭스 조직(Matrix): 기능형과 프로젝트형의 혼합. 약한 매트릭스(기능 관리자 우세)·균형 매트릭스·강한 매트릭스(PM 우세)로 세분된다. IT 기업의 상당수가 이 구조다.

PMO(프로젝트 관리 오피스, Project Management Office)란 조직 내 PM 방법론·표준·거버넌스를 관리하는 기능 단위다. PMBOK은 세 유형을 제시한다: 지원형(Supportive)(템플릿·교육 제공, 낮은 통제), 통제형(Controlling)(공통 프레임워크·프로세스 준수 요구, 중간 통제), 지시형(Directive)(PM을 직접 배치·통제, 높은 통제). 어떤 PMO가 있느냐에 따라 PM의 자율성과 지원 수준이 달라진다.

3장 — PM의 역할

PMBOK은 PM을 단순 일정 관리자가 아니라 통합자(integrator)이자 리더로 규정한다. PM의 영향력은 프로젝트 팀 안에만 머물지 않는다. 스폰서·이해관계자·공급업체·PMO·타 부서에까지 뻗어 있다. PMBOK은 이를 “영향력의 범위(sphere of influence)”라고 부른다.

PM이 갖춰야 할 역량을 PMBOK은 PMI 인재삼각형(Talent Triangle)으로 정리한다.

• 기술적 프로젝트 관리(Technical PM Skills): WBS(작업분류체계)·공수 산정·EVM(획득가치관리)·리스크 관리 대장 운영 등 PM 고유의 도구와 기법.
• 리더십(Leadership): 동기 부여·갈등 해결·협상·의사소통·팀 빌딩.
• 전략 및 경영 관리(Strategic & Business Management): 프로젝트가 조직 전략에 어떻게 기여하는지 이해하고, 비즈니스 언어로 이해관계자와 대화하는 능력.

✅ 읽으며 좋았던 점: PM의 정의를 명확히 잡아준다

PMBOK 1~3장에서 가장 가치 있는 부분은 “PM이 무엇을 하는 사람인가”를 논쟁의 여지 없이 정의한다는 점이다. 현장에서 PM의 역할 범위를 두고 팀원·경영진·스폰서 사이에서 이견이 생길 때, 이 정의는 공통 언어 역할을 한다.

두 번째로 좋았던 것은 조직 구조가 PM의 권한을 결정한다는 통찰이다. PM이 “왜 팀원을 움직이기 힘들까”라고 좌절할 때, 그것이 PM 개인의 능력 문제가 아니라 구조적 문제일 수 있다는 것을 PMBOK이 명시적으로 알려준다. 기능형 조직의 PM은 구조적으로 권한이 약하다. 이것을 인정하고 협상·설득·공식 채널을 활용하는 전략을 세우는 것과, 자신을 탓하며 소진하는 것은 전혀 다른 결과를 낳는다.

PMI 인재삼각형도 유효하다. 많은 PM이 기술적 스킬(일정·WBS·EVM)만 집중하다 리더십과 전략 역량을 놓친다. 삼각형은 “PM은 세 축을 균형 있게 개발해야 한다”는 경고다.

⚠️ 현장과의 괴리: PMO·거버넌스는 중소 IT엔 과할 수 있다

PMBOK이 묘사하는 세계는 PMO가 있고, 거버넌스 체계가 작동하고, PM의 역할이 명확히 분리된 중대형 조직이다. 하지만 국내 IT 스타트업과 소규모 에이전시에서는 이런 그림이 잘 맞지 않는 경우가 많다.

• PMO 부재: 10명 미만 팀에 PMO는 과다한 오버헤드다. 표준·프로세스를 관리할 전담 조직이 없고, PM이 방법론 정의까지 혼자 해내야 한다.
• 겸직 문제: PM이 개발팀장·PO(제품 책임자)를 동시에 맡는 경우가 흔하다. PMBOK의 역할 분류는 이 상황을 상정하지 않는다. 어느 역할 모자를 쓰고 있는지 스스로 혼란스러울 때가 많다.
• 기능형 조직의 PM 무력감: 기능형 조직에서 PM으로 임명되면, 공식 권한 없이 프로젝트를 이끌어야 한다. 팀원은 자기 팀장의 지시를 우선한다. PMBOK은 이 사실을 인정하지만, 해법을 충분히 주지는 않는다.
• 거버넌스의 무게: 거버넌스 문서·보고 체계는 프로젝트 규모에 비례해서 필요하다. 소규모 프로젝트에 대형 거버넌스를 얹으면 문서만 늘고 실제 일은 늦어진다.

🔧 실전 번역: 내 조직에서 PM 역할을 제대로 세팅하는 법

PMBOK의 정석을 현장에 그대로 이식하면 안 된다. 조직 규모와 구조에 맞게 경량화해야 한다. 아래는 내가 실전에서 써먹을 수 있는 번역들이다.

• 내 조직 구조부터 파악하라. 지금 내가 속한 조직이 기능형인지, 매트릭스인지, 프로젝트형에 가까운지 진단하면 내 실제 권한 수준이 보인다. 권한이 약한 구조라면, 공식 지시 대신 협력·설득·이해관계자 관리에 에너지를 써야 한다.
• 겸직 시 역할 전환을 명시적으로 하라. “지금 나는 PM으로서 일정을 이야기하는 것”과 “지금은 PO로서 백로그 우선순위를 결정하는 것”을 팀에게 명확히 선언하면, 혼선이 줄어든다. 슬랙 채널이나 회의 도입 시 “오늘 이 회의는 PM 모드”라고 한 줄 쓰는 것만으로도 다르다.
• 경량 거버넌스로 시작하라. 전면적인 PMO 대신, 주 1회 정기 리뷰 미팅 하나로 시작한다. 거기서 일정·리스크·이슈 세 가지만 점검해도 거버넌스의 70%는 작동한다.
• 인재삼각형으로 내 약점을 점검하라. 기술적 PM 스킬은 충분한데 리더십이 약한가? 리더십은 강한데 전략 이해가 부족한가? 삼각형의 어느 꼭짓점이 처지는지 아는 것이 성장의 출발이다.
• OPA를 직접 만들어라. 조직에 OPA(교훈·템플릿·과거 데이터)가 없다면, 지금 프로젝트 종료 시 회고를 문서화해 다음 PM이 쓸 수 있게 남겨라. 이것이 OPA의 씨앗이다.

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

• 프로젝트·프로그램·포트폴리오의 차이를 명확히 설명하고, 내가 담당하는 일이 어느 단위인지 분류할 수 있다.
• 내 조직이 기능형·매트릭스·프로젝트형 중 어디에 해당하는지 진단하고, 그에 따른 내 실제 권한 수준을 이해한다.
• PMO의 세 유형(지원형·통제형·지시형)을 구분하고, 우리 조직에 필요한 PMO 수준을 제안할 수 있다.
• PMI 인재삼각형으로 자신의 PM 역량을 자가 점검하고, 성장해야 할 축을 식별한다.
• 6개 프로젝트 제약(범위·일정·원가·품질·자원·리스크)을 머릿속에 상시 켜놓고, 하나가 흔들릴 때 다른 것들에 미치는 영향을 팀과 대화할 수 있다.

❓ 자주 묻는 질문 (FAQ)

PM과 PO(제품 책임자)의 차이는 무엇인가?

PM(프로젝트 관리자)은 프로젝트의 범위·일정·원가·리스크를 통합 관리하며 결과물 납기를 책임진다. PO(Product Owner)는 제품 백로그의 우선순위를 정하고 사용자 가치 중심으로 제품 방향을 결정하는 역할이다. 이 둘은 원래 별개 역할이지만, 스타트업과 소규모 팀에서는 한 사람이 겸직하는 경우가 많다. 겸직 시에는 지금 어느 역할로 의사결정하는지를 명확히 하는 것이 중요하다.

소규모 팀에도 PMO가 필요한가?

10명 미만의 팀에 정식 PMO 조직은 과하다. 다만 PMO의 기능 — 공통 템플릿, 교훈 기록, 프로젝트 현황 가시화 — 은 어떤 규모에서도 가치가 있다. 소규모 팀이라면 전담 조직 대신 PM이 직접 간단한 템플릿과 주간 리뷰 루틴을 운영하는 것으로 PMO의 핵심 기능을 경량화해 구현할 수 있다.

기능형 조직에서 PM 권한이 약할 때 어떻게 해야 하나?

기능형 조직에서 PM은 공식 지시 권한이 약하다. 이 경우 효과적인 전략은 세 가지다. 첫째, 스폰서(경영진)의 공식 지원을 확보해 킥오프 시 역할과 책임을 공표한다. 둘째, 팀원의 기능 관리자(팀장)와 정기적으로 소통하며 협력 관계를 유지한다. 셋째, RACI(역할·책임·협의·정보) 매트릭스를 문서화해 역할 혼선을 줄인다. 결국 기능형 조직의 PM은 권위보다 신뢰와 협상으로 움직인다.

PM은 개발도 직접 해야 하나?

PMBOK은 PM에게 직접 개발을 요구하지 않는다. PM의 본질은 팀이 일을 잘 할 수 있도록 환경·방향·장애물 제거에 집중하는 것이다. 다만 현실에서 개발 배경이 있는 PM은 팀원과의 소통·공수 산정·기술 리스크 식별에서 유리하다. “개발도 한다”가 아니라 “개발을 이해한다”가 더 정확한 표현이다. 개발 겸직이 필요한 상황이라면, 그것은 조직 규모의 문제이지 PM의 본질이 아님을 명심해야 한다.

PMBOK 완독기는 계속 이어진다. 다음 편은 4~6장 — 통합·범위·일정 관리, 즉 PM 업무의 핵심 엔진을 다룬다. 프로젝트 관리 도구 도입이나 팀 내 PM 프로세스 구축을 검토 중이라면, PSTA를 살펴보거나 주니크에 문의해도 좋다.

『PMBOK 완독기』 시리즈
← 이전: 00. 오리엔테이션: 왜 정석을 완독하나 + 6판·7판 지도
→ 다음: 02. 통합관리: 헌장과 변경통제 (4장)