PMI PMP: 팀 리더십 및 리소스 관리 — 학습 가이드

By Laurynas Brazys · 22 July 2026 · #pmi #pmp #certification #exam-prep #study-guide

다음의 일부입니다: PMP — 학습 가이드. 검증된 답안으로 연습하기: PMI 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

팀 구성, 헌장 및 역할 명확성

모든 고성과 팀은 첫 번째 상태 보고 회의가 아니라, 의도적인 구성 의식(formation ritual)으로 시작합니다. **팀 헌장(team charter)**은 팀의 창립 산출물입니다. 이는 팀의 공유 가치, 의사 결정 규칙, 시간대별 근무 시간, 소통 주기, 에스컬레이션 경로 등을 담은 공동 작성 문서입니다. 프로젝트를 승인하고 스폰서를 지정하는 프로젝트 헌장과 달리, 팀 헌장은 팀을 위해 팀 자신이 작성합니다. 그 힘은 공동 작성에 있습니다. 나중에 개발자가 동료를 방해하거나 스탠드업에 불참했을 때, 프로젝트 관리자는 개인적인 권위를 내세우는 것이 아니라 팀 스스로 정한 규범을 지적합니다.

헌장과 더불어 **기본 규칙(ground rules)**은 일상적인 규율을 운영 가능하게 합니다. 예를 들어, 설계 검토 시 카메라 켜기, 회고 중 멀티태스킹 금지, 구두 업데이트 시 2분 규칙, 24시간 내 결정 사항 문서화 등이 있습니다. 기본 규칙은 팀 회의실에 게시하거나 협업 채널에 고정하여 눈에 잘 띄게 해야 하며, 각 이터레이션이나 단계 게이트 시작 시점에 재검토해야 합니다. 아무도 열어보지 않는 SharePoint 폴더에 있는 헌장은 장식에 불과하지만, 매주 참조되는 헌장은 규제 역할을 합니다.

역할 명확성은 팀 구성의 세 번째 축을 완성합니다. RACI (또는 그 변형인 RASCI) 매트릭스는 책임자(Responsible), 담당자(Accountable), 협의 대상(Consulted), 통보 대상(Informed)에 따라 결과물을 매핑하여 “당신이 맡은 줄 알았어요"와 같은 실패 상황을 방지합니다. 리더십 없이 몇 주간 표류해 온 그룹을 프로젝트 관리자가 인계받은 신규 팀에서, 가장 먼저 해야 할 일은 공격적인 계획 재수립이나 스폰서와의 즉각적인 일정 재협상이 아닙니다. 팀을 소집하여 그들이 무엇에 막혀 있다고 느끼는지 경청하고, 헌장과 역할 맵을 재구축하는 것입니다. 팀이 길을 잃었다고 느끼는 것은 바로 이러한 기준점들이 없기 때문입니다.

성숙도에 따른 리더십 스타일 조정

상황적 리더십은 리더십 스타일을 성격이 아닌 변수로 취급합니다. 고전적인 허시-블랜차드(Hersey-Blanchard) 진행 모델은 리더십 스타일을 팔로워의 준비도에 따라 매핑합니다.

• 낮은 역량, 높은 헌신 (신규)
  • 권장 스타일: 지시형(Directing)
  • 행동: 무엇을, 언제, 어떻게 할지 지시
• 어느 정도의 역량, 가변적인 헌신
  • 권장 스타일: 코칭형(Coaching)
  • 행동: 설명하고, 결정을 설득하며, 대화를 유도
• 높은 역량, 가변적인 헌신
  • 권장 스타일: 지원형(Supporting)
  • 행동: 촉진하고, 의사 결정을 공유
• 높은 역량, 높은 헌신
  • 권장 스타일: 위임형(Delegating)
  • 행동: 책임을 위임

장애물을 제거하고, 외부의 불필요한 방해로부터 팀을 보호하며, 팀원의 성장을 우선시하는 서번트 리더십(servant leadership) 자세는 이 모델에 겹쳐 적용될 수 있지만, 상황적 판단을 대체하지는 않습니다. 서번트 리더십이 허용적인 리더십을 의미하는 것은 아닙니다. 팀이 표류할 때 서번트 리더는 여전히 지시를 내립니다. 다만 자신의 가시성이 아닌 팀의 성공을 위해 그렇게 할 뿐입니다.

방향성 없는 팀에 대한 자유방임형 리더십(laissez-faire leadership)의 함정은 흔한 실패 유형입니다. 팀이 작업에 대한 공유된 모델이 없을 때 ‘팀이 스스로 조직화하도록’ 뒤로 물러서는 것은 혼란, 의존성 누락, 사기 저하를 초래합니다. 자기 조직화는 성숙의 결과이지, 시작 조건이 아닙니다. 반대로, 비슷한 작업을 다섯 번이나 수행한 시니어 엔지니어를 마이크로매니징하는 것은 불신을 나타내고, 주도성을 억누르며, 이직률을 높입니다. 프로젝트 관리자가 포트폴리오 수준의 리스크 논의는 무시하면서 도메인 전문가의 작업에 대해 커밋 수준의 세부 사항을 검토할 때 이런 징후가 나타납니다.

다양한 경력의 팀원이 섞인 팀에 합류할 때, 첫 번째 조치는 일대일 미팅과 업무 협약 워크숍을 함께 진행하는 것입니다. 이를 통해 각 개인이 준비도 스펙트럼의 어디에 위치하는지 파악하여, 리더십 스타일을 일괄적으로 적용하는 대신 개인별로 조정할 수 있습니다.

코칭, 일대일 미팅 및 성과 관리

주기적인 일대일 미팅(일반적으로 2주에 30분)은 코칭, 문제 조기 발견, 경력 개발을 위한 주요 채널입니다. 이는 상태 보고 회의가 아닙니다. 안건은 팀원이 주도해야 하며, 프로젝트 관리자는 시간의 70%를 경청하는 데 사용해야 합니다. 주제는 현재의 장애물, 기술 성장, 양방향 피드백, 사기 등 다양하게 다룹니다.

성과 문제는 공식적인 검토 주기를 위해 쌓아두지 말고 처음 관찰되었을 때 즉시 제기해야 합니다. 어려운 대화를 미루는 것은 프로젝트 리더십에서 가장 해로운 패턴 중 하나입니다. 성과가 저조한 사람은 너무 늦기 전까지 아무것도 배우지 못하고, 고성과자들은 이를 지켜보며 참여를 중단하고, 사기는 조용히 무너집니다. 피드백은 “의욕이 없어 보여요"와 같은 주관적인 인상이 아니라, 결함 탈출률, 스토리 사이클 타임, 코드 리뷰 처리 시간, 회의 참석률, 약속 이행 신뢰도 등 측정 가능한 지표를 참조해야 합니다. 측정 가능한 지표는 대화를 관찰 가능한 행동에 기반하게 하고, 팀원에게 구체적인 목표를 제공합니다.

기능 관리자에게 에스컬레이션하거나 궁극적으로 인력 교체를 요청하는 것은 코칭, 명확한 기대치 설정, 문서화된 성과 개선 논의가 실패한 후에만 정당화됩니다. 이러한 단계를 건너뛰는 것은 신뢰를 손상시키고 종종 HR 정책을 위반합니다.

갈등 해결 및 팀 빌딩

대인 관계 갈등은 해결하지 않으면 악화됩니다. 단기 프로젝트에서 팀원이 동료들에게 고립될 때, 프로젝트 관리자는 상황이 해결되기 전에 프로젝트가 끝나므로 그냥 기다려서도 안 되고, 공개적으로 그룹과 대립해서도 안 됩니다(이는 굴욕감을 주고 입장을 더 완고하게 만듭니다). 올바른 대응 방식은 세 가지 조치를 결합하는 것입니다. 먼저 해당 개인과 비공개 대화를 통해 그들의 경험을 이해하고, 배제적인 행동을 보이는 동료들과 개별적으로 이야기하여 관찰된 패턴과 그 영향을 지적하며, 팀 헌장과 잘 짜인 팀 빌딩 활동을 통해 포용 규범을 강화하는 것입니다. HR에 문제를 보고해야 할 경우를 대비하여 개입 과정을 문서화하는 것이 필수적입니다.

Thomas-Kilmann의 다섯 가지 갈등 관리 방식(협력, 타협, 순응, 강요, 회피)은 상황에 맞는 해결책을 선택하는 데 지침이 됩니다. 협력(윈윈(win-win) 해결책을 찾기 위한 문제 해결)은 지속적인 팀의 대인 관계 및 기술적 분쟁에서 일반적으로 선호되는 반면, 강요는 안전, 윤리 또는 엄격한 마감일과 관련된 결정에만 정당화될 수 있습니다.

자원 할당, 평준화 및 용량 계획

자원 관리는 산술만큼이나 협상이 중요합니다. **자원 평준화(Resource leveling)**는 일정을 연장하여 과도한 할당을 해소하는 것이고, **자원 평활화(resource smoothing)**는 종료 날짜를 고정한 채 여유 시간(float) 내에서 작업하는 것입니다. 핵심 전문가가 과도하게 투입되어 품질 저하가 우려될 때는 평준화를 선택하고, 종료 날짜가 계약 사항일 때는 평활화를 선택합니다.

기능 관리자가 스프린트 중간에 공유 아키텍트를 재배치할 때, 프로젝트 관리자는 현재 약속된 작업, 핵심 경로(critical path)에 미치는 영향, 지연으로 인한 후속 비용과 같은 데이터를 사용하여 협상합니다. 스폰서나 운영 위원회(steering committee)에 문제를 보고하는 것은 직접적인 협상을 시도하고 문서화한 후에만 적절합니다. 먼저 해결을 시도하지 않고 불만을 그대로 윗선에 보고하는 것은 정치적 자산을 소모하는 행위입니다.

지식 이전 및 교차 교육

단일 지점 의존성(Single-point dependencies)은 가장 예측 가능하면서도 가장 자주 무시되는 프로젝트 리스크 중 하나입니다. 한 사람이 하위 시스템의 유일한 담당자인데 두 달간 입원하게 되었다면, 실패는 그 사고 자체가 아니라 사전 완화 조치가 없었다는 점입니다. 예방 조치에는 페어 프로그래밍 또는 페어 멘토링, 온콜(on-call) 책임 순환, 조직 내부에만 알려진 지식(tribal knowledge)을 런북(runbook)으로 의무적으로 문서화하기, 지식 전달 세션 녹화, 그리고 보조 담당자가 전문가의 작업을 참관한 후 직접 수행하는 교차 교육(cross-training) 순환 등이 포함됩니다. 신규 채용자를 위한 온보딩 계획에는 버디(buddy)를 지정하고 30-60-90일 역량 로드맵을 명시적으로 포함해야 합니다.

팀 수준의 승계 계획은 각 핵심 역할을 누가 맡을 수 있는지, 그리고 그들이 어떤 역량 격차를 해소해야 하는지를 식별합니다. 이는 분기별로 검토되는 기술 매트릭스(skills matrix)에 기록됩니다.

회의 진행 및 인정

회의는 팀의 가용 시간 중 가장 눈에 띄는 부분을 차지합니다. 회의를 효율적으로 운영하려면 명시된 목적, 사전에 배포된 시간 제한이 있는 안건, 적절한(최대가 아닌) 참석자, 담당자와 날짜가 명시된 명확한 결정 및 실행 항목, 그리고 주제에서 벗어난 논의를 위한 파킹랏(parking lot) 운영이 필요합니다. 결정 사항이 없는 정기 회의는 취소해야 합니다.

마지막으로, 인정(팀의 성공에 대해서는 시기적절하고 구체적이며 공개적으로, 개인 코칭은 비공개로)은 그저 부수적인 좋은 일이 아닙니다. 헌장의 가치에 부합하는 보상은 그러한 성과를 만들어낸 행동을 강화합니다. 검토 회의에서의 간단한 칭찬, 기능 관리자와 협의한 즉석 보너스, 또는 누군가의 직속 상사에게 보내는 서면 메모는 비용이 거의 들지 않지만 사기와 직원 유지율을 크게 높이는 복리 효과를 가져옵니다.

실전 문제: 유스케이스 시나리오

시나리오: Priya Kapoor는 한 중견 지역 은행의 “Meridian” 결제 현대화 프로젝트 책임자로 막 배정되었습니다. 이 프로젝트의 예산은 420만 달러, 기간은 14개월입니다. 11명으로 구성된 팀은 세 개의 시간대에 걸쳐 있습니다. 방갈로에 개발자 5명, 런던에 비즈니스 분석가(BA) 3명, 그리고 토론토에 QA 책임자, 아키텍트, 그리고 Priya 자신이 있습니다. 프로젝트 시작 2주 후, 방갈로 개발자들이 만든 프로토타입을 런던의 BA들이 “‘모두가 읽었을 것이라고 가정한’ 규정 준수 요구사항과 맞지 않는다"며 거부했고, 토론토의 아키텍트는 기술 스택 결정에 대해 자신은 전혀 자문을 받지 못했다고 주장합니다.

과제: Priya는 프로젝트가 더 지연되기 전에, 어느 한 그룹도 비난하는 것처럼 보이지 않으면서 팀의 운영 규범과 역할 명확성을 재설정해야 합니다.

권장 접근 방식:

1. 11명의 팀원 모두가 실시간으로 결과물을 공동 작성할 수 있도록 겹치는 시간대(토론토 오전 7:00–10:00 / 런던 오후 12:00–3:00 / 방갈로 오후 4:30–7:30)를 정해, 이틀간의 가상 팀 구성 워크숍을 위해 진행 중인 개발을 일시 중단합니다.
2. 공유 근무 시간 중복, 의사결정 권한, ‘consulted(자문)‘와 ‘informed(통보)‘의 정의, 비동기적 의사결정을 위한 24시간 내 처리 규칙, 그리고 스폰서에게까지 이어지는 에스컬레이션 절차를 포함하는 팀 헌장의 공동 작성을 촉진합니다.
3. WBS의 18개 주요 결과물에 대한 RASCI 매트릭스를 구축하고, 팀과 함께 각 행을 검토하여 ‘Accountable(책임자)‘은 항상 한 명의 지정된 사람이어야 하며, 모든 기술 스택 결정에 대해 ‘Consulted(자문 대상)‘로 아키텍트를 명시적으로 지정하도록 합니다.
4. 설계 검토 시 카메라 켜기, 영업일 기준 1일 이내에 Confluence에 의사결정 기록, 겹치는 시간대에 매주 30분간 교차 시간대 동기화 회의 진행과 같은 기본 원칙을 수립하고 팀의 Slack 채널에 고정합니다.
5. BA 및 개발자들과 함께 프로토타입의 범위를 재작업하고, 새롭게 명확해진 RASCI를 사용하여 코드를 작성하기 전에 누가 승인해야 하는지 식별합니다.
6. 팀이 성숙해짐에 따라 규범을 수정할 수 있도록, 각 이터레이션의 첫 회고에 10분짜리 ‘헌장 점검’ 시간을 정기적으로 추가합니다.

이 방법이 효과적인 이유: 공동 작성은 헌장을 지시가 아닌 동료 간의 약속으로 전환시키며, 이는 PM이 직책상의 권한을 사용하지 않고도 규범을 시행할 수 있는 명분을 줍니다. RASCI는 규정 준수 문제를 야기했던 ‘당신이 맡은 줄 알았다’는 식의 책임 공백을 없애주고, 이터레이션마다 규범을 재검토함으로써 헌장이 장식용 문서가 아닌 살아있는 합의로 유지되도록 합니다.

← 이해관계자 참여 및 소통 · 모든 도메인 · Agile →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →