3줄 요약
- PMBOK 9장은 팀과 물적 자원을 체계적으로 확보·배분·개발하는 방법을 다루며, 그 핵심은 RACI 차트(책임배정매트릭스)로 역할과 책임을 구조화하는 것이다.
- Accountable(최종책임자)은 반드시 1명이어야 한다는 원칙이 현장 역할 혼선을 방지하는 가장 강력한 규칙이다.
- 소규모 IT 팀에서는 경량 RACI로 핵심 의사결정 항목만 명시하고, 워크로드를 가시화해 특정인 과부하를 구조적으로 예방하는 것이 실전 자원관리다.
“그 일 제 담당 아닌데요.” — 프로젝트 킥오프 이후 첫 번째 위기 회의에서 가장 많이 나오는 말.
자원 관리(Resource Management)는 이름만 들으면 HR이나 총무팀 얘기 같다. 그런데 PMBOK 9장을 읽어보면 다르다. 프로젝트에 필요한 사람과 물건을 언제, 얼마나, 누구에게 배정할 것인가를 PM이 직접 설계해야 한다는 내용이다. 특히 RACI 차트(Responsibility Assignment Matrix, 책임배정매트릭스)는 단순한 표 하나가 아니라, “역할 혼선”이라는 프로젝트 최대 적 중 하나를 구조로 막는 도구다. RACI 차트란 프로젝트의 각 작업·산출물에 대해 실무 담당자(Responsible)·최종책임자(Accountable)·자문자(Consulted)·통보 대상(Informed)을 명시적으로 정의한 매트릭스를 말한다.
📖 PMBOK 9장이 말하는 자원 관리란?
PMBOK 6판 기준으로 9장은 6개 프로세스로 구성된다. 자원 관리 계획 수립, 활동 자원 산정, 자원 확보, 팀 개발, 팀 관리, 자원 통제가 그것이다. 흐름은 단순하다. 먼저 어떤 자원이 필요한지 계획하고(계획), 실제로 확보한 뒤(실행), 팀을 키우고 문제를 조율하면서(실행·감시), 마지막에 자원 소비가 계획 범위를 벗어나지 않도록 통제한다(감시통제).
이 중 자원 관리에서 가장 실전적 도구가 RACI 차트다. RACI는 네 역할의 머릿글자를 딴 약어다.
- R — Responsible(실무 담당): 실제로 그 일을 실행하는 사람. 한 작업에 여러 명이 될 수 있다.
- A — Accountable(최종 책임): 그 작업의 결과에 최종 책임을 지는 사람. 반드시 1명이어야 한다.
- C — Consulted(자문): 의견이나 검토를 제공하는 사람. 양방향 소통.
- I — Informed(통보): 결과를 공유받는 사람. 일방향 통보로 충분하다.
팀 개발 측면에서는 터크만(Tuckman) 모델이 등장한다. 팀은 형성(Forming) → 격동(Storming) → 규범(Norming) → 수행(Performing)의 단계를 거쳐 성숙한다는 이론으로, PM은 각 단계에 맞는 리더십 방식을 달리 적용해야 한다. 형성기에는 방향 제시, 격동기에는 갈등 조율, 규범기에는 프로세스 정착, 수행기에는 위임이 핵심이다.
물적 자원 관리도 9장의 범주에 들어간다. 장비·소프트웨어·인프라 등을 언제 조달하고, 어떻게 사용하며, 낭비 없이 반납하는가를 계획한다. IT 프로젝트에서는 클라우드 리소스 비용이 이 범주에 해당한다.
✅ 읽으며 좋았던 점: “공동 책임은 무책임이다”
RACI 차트에서 가장 강력한 원칙은 하나다. Accountable은 단 1명이어야 한다는 것. “공동 책임”이 실제로는 아무도 책임지지 않는 무책임으로 귀결된다는 현실을 구조로 강제하는 규칙이다.
현장에서 “팀 전체가 책임진다”는 말은 위기가 오면 누구도 앞에 나서지 않는다는 뜻이 된다. PMBOK이 이 원칙을 명문화한 것은 실용적 지혜다. PM으로서 처음 이 문장을 읽었을 때 “당연한 것 같은데 왜 지금껏 안 지켰지?”라는 자성이 들었다.
또 하나 인상적인 부분은 9장이 팀을 단순 ‘인적 자원’이 아니라 개발 대상으로 바라본다는 점이다. 터크만 모델은 팀이 시간이 지나면 저절로 잘 맞는 게 아니라, PM이 의도적으로 각 단계를 이끌어야 한다는 메시지를 담고 있다. 이 시각은 단기 프로젝트에서도 유효하다. 처음 만나는 팀이 격동기를 건너뛰고 수행기에 바로 진입하는 경우는 드물기 때문이다.
⚠️ 현장과의 괴리: RACI를 만들어도 “제 일 아닌데요”가 나오는 이유
PMBOK 9장의 가장 큰 전제는 자원이 풀타임으로 배정 가능하다는 것이다. 전담 팀원, 명확한 조달 예산, 계획대로 움직이는 인력 풀. 하지만 대부분의 IT 현장은 다르다.
- 겸직 다발: 개발자 한 명이 세 프로젝트에 동시 할당되어 있다. 이 경우 RACI에서 Responsible을 지정해도 실질 가용 시간이 없다.
- 리소스 레벨링의 현실: PMBOK은 자원 과부하를 고르게 분산(레벨링)하라고 하지만, 스킬셋이 다른 팀원 사이에서 작업을 물처럼 나누는 건 불가능하다. 백엔드 작업을 디자이너에게 분산할 수 없다.
- 문서와 실제의 괴리: RACI를 정성껏 만들어도, 조직 문화에서 “그 일이 내 담당이라고 지정됐지만 우리 팀장은 다르게 생각한다”는 상황이 발생한다. 매트릭스는 종이 위에만 존재하고, 실제 의사결정은 비공식 라인에서 이뤄진다.
- 터크만 모델의 한계: 실제 팀은 단선적으로 성숙하지 않는다. 새 팀원이 합류하거나, 조직 개편이 생기면 수행기에서 다시 격동기로 후퇴한다. 단계별 처방이 항상 맞아 떨어지진 않는다.
결국 RACI는 “만든다”가 목적이 아니라, 모두가 같은 이해를 가지고 동의하는 과정이 핵심이다. 그 과정 없이 PM이 혼자 만들어 공유한 RACI는 인쇄된 종이에 불과하다.
🔧 실전 번역: 소규모 IT 팀을 위한 경량 RACI
완벽한 RACI 대신 작동하는 경량 RACI를 만드는 법을 정리한다.
- 핵심 항목만 정의한다: 전체 WBS 작업이 아니라, 역할 혼선이 예상되는 의사결정 포인트와 주요 산출물(기획서 최종 승인, 개발 완료 판정, 클라이언트 보고 등)에만 RACI를 적용한다. 항목이 많을수록 아무도 안 읽는다.
- Accountable 1명 원칙을 협의로 확정한다: 킥오프 미팅에서 각 항목의 A를 소리 내어 정한다. 침묵이 동의가 아니라는 점을 명시한다. “누가 이 결정의 최종 책임자입니까?”라는 질문에 이름이 나와야 완성이다.
- 각 작업에 담당자(R) 1명을 먼저 지정한다: 여러 명이 Responsible이면 실제 실행이 분산된다. 대표 담당자 1명을 먼저 지정하고, 나머지를 지원 인력으로 구분한다.
- 워크로드를 가시화한다: 담당자 배정 직후, 각 팀원이 맡은 작업 수와 예상 공수를 한눈에 볼 수 있게 정리한다. 특정인에게 작업이 몰리면 구조적으로 재배분한다. 이를 하지 않으면 성실한 사람이 항상 과부하 상태가 된다.
- C와 I는 간소화한다: Consulted와 Informed를 과도하게 나열하면 회의가 늘고 커뮤니케이션 비용이 증가한다. C는 “없으면 결과가 달라지는 사람”만, I는 “알아야 할 이해관계자”로 압축한다.
R&R 정의(역할 분담)는 한 번 만들고 끝이 아니다. 팀 구성이 바뀌거나 스코프가 달라지면 RACI도 갱신된다. 문서가 현실을 따라가지 못하면 혼선은 다시 시작된다.
🟥 PSTA로 보면
PSTA는 Action 단위로 담당자를 1명 지정하는 구조를 기본으로 한다. “이 Action의 담당자는 누구인가”가 시스템 레벨에서 강제되므로, RACI의 Responsible 1인 원칙이 자연스럽게 구현된다. RBAC 권한 체계(ADMIN / PO / PM / MEMBER)는 Accountable·Consulted 역할을 조직 권한으로 매핑하고, LDAP 연동으로 실제 조직도의 사람과 역할이 연결된다. 역할 혼선이 “문서로 막는 것”이 아니라 시스템 구조로 예방되는 셈이다.
🟨 다만 아쉬운 점: PSTA는 워크로드(가용량·용량 계획)와 리소스 레벨링을 직접 지원하지 않는다. “이 팀원이 현재 몇 개의 Action을 맡고 있고, 가용 시간은 얼마인가”를 자동으로 계산해주는 스킬 매트릭스나 용량 계획 기능은 없다. “누가 지금 얼마나 바쁜지”를 구조적으로 가시화하는 것은 사용자가 직접 관리해야 한다.
🎓 이 장을 떼면 당신은 무엇을 할 수 있나
- 프로젝트 킥오프 전에 핵심 의사결정 항목과 주요 산출물에 대한 경량 RACI를 작성하고, 팀원 합의를 통해 확정할 수 있다.
- 모든 Accountable 항목에 이름 1명만 들어가는지 검수하고, “공동 책임” 표현을 구조적으로 제거할 수 있다.
- 담당자 배정 직후 워크로드를 가시화해 특정인 과부하를 초기에 발견하고 재배분할 수 있다.
- 팀이 격동기(Storming)에 있을 때 이를 자연스러운 성장 과정으로 인식하고, 갈등 조율자로서 PM의 역할을 수행할 수 있다.
- RACI를 살아있는 문서로 유지 관리하며, 팀 구성이나 스코프 변경 시 즉시 갱신하는 습관을 정착시킬 수 있다.
❓ FAQ
RACI 차트란 무엇인가?
RACI 차트(책임배정매트릭스)는 프로젝트의 각 작업·산출물·의사결정에 대해 실무 담당자(Responsible), 최종책임자(Accountable), 자문자(Consulted), 통보 대상(Informed)을 명시적으로 표로 정리한 도구다. 역할 분담(R&R 정의)을 구조화해 “그 일 제 담당 아닌데요”가 나오지 않도록 사전에 경계를 그어두는 것이 핵심 목적이다.
RACI를 만들었는데 왜 여전히 역할 혼선이 생기나?
RACI가 혼선을 막지 못하는 가장 흔한 이유는 두 가지다. 첫째, PM이 혼자 만들어 공유만 했을 경우다. RACI는 팀원 모두가 소리 내어 동의하는 과정이 있어야 실제로 작동한다. 둘째, Accountable이 여러 명이거나 비워져 있는 경우다. 최종책임자가 불분명하면 결국 아무도 결정하지 않는 상태로 가게 된다. 문서의 형식보다 합의 과정이 더 중요하다.
Accountable과 Responsible의 차이는?
Responsible은 그 일을 직접 실행하는 사람이고, Accountable은 그 일의 결과에 최종 책임을 지는 사람이다. 예를 들어 기획서를 작성하는 기획자는 Responsible이고, 기획서 내용과 일정에 책임지는 PM이 Accountable이다. 둘이 같은 사람일 수도 있지만, Accountable은 항상 단 1명이어야 한다는 원칙이 핵심이다.
소규모 팀에도 RACI가 필요한가?
팀이 작을수록 한 사람이 여러 역할을 겸직하기 때문에 오히려 RACI가 더 필요하다. 3~5인 팀에서 “우리 다 같이 하면 되지”라는 문화가 결국 역할 혼선과 과부하를 만든다. 다만 소규모 팀의 RACI는 전체 작업 목록이 아니라, 의사결정 포인트와 핵심 산출물만 다루는 경량화 버전이 현실적이다. 분량보다 각 항목에 이름이 명확히 들어있는지가 더 중요하다.
자원관리와 역할 분담 구조를 팀에 도입하고 싶다면 PSTA(psta.app)에서 Action 단위 담당자 배정과 RBAC 권한 체계를 직접 확인해보거나, 주니크에 문의해주세요.
『PMBOK 완독기』 시리즈
← 이전: 06. 품질관리: DoD와 검수 기준 (8장)
→ 다음: 08. 의사소통관리: 보고 오버헤드 줄이기 (10장)
