회의실의 공기가 얼음장처럼 차가워지던 순간을 기억하시나요? 핵심 기능 구현 방식을 두고 언성을 높이던 개발자 A와 기획자 B. 그 사이에서 누구 편도 들지 못한 채 의미 없는 미소만 짓고 있던 나. 차라리 키보드 소리만 들리는 정적이 그리워졌던 그 경험, N년차 직장인이라면 아마 한 번쯤은 겪어보셨을 겁니다.
'사람' 문제가 세상에서 제일 어렵다는 말, 프로젝트 현장에서는 그야말로 진리입니다. 기술적인 문제나 일정 지연은 어떻게든 해결의 실마리가 보이지만, 사람의 감정과 관계가 얽힌 문제는 어디서부터 풀어야 할지 막막하기만 하죠.
PMP 시험에서도 이 '사람 문제(People Domain)'는 수험생들의 발목을 잡는 가장 큰 복병입니다. 보기를 읽다 보면 나도 모르게 감정이입해서 '나라면 이렇게 하겠다' 싶은 답을 고르기 쉽거든요. 하지만 오늘은 그 감정의 덫을 피하고, 가장 PMI스러운, 가장 정답에 가까운 선택을 하는 냉철한 전략에 대해 이야기해보려 합니다. 😊
PMI가 파놓은 3가지 '감정의 덫' ⚠️
PMP 사람 관련 문제의 보기들은 우리의 감정을 교묘하게 자극하도록 설계되어 있습니다. "가장 먼저" 해야 할 일을 묻는 질문에 그럴듯한 공감의 제스처나 빠른 해결책처럼 보이는 것들을 배치해두죠. 하지만 명심하세요. 프로젝트 관리자는 심리 상담사나 독재자가 아닙니다. 다음 세 가지 유형의 보기는 99% 오답 함정입니다.
- 감정적 대응: "갈등을 겪는 팀원 A를 따로 불러 위로하고 그의 입장을 지지한다." "불만을 제기한 이해관계자에게 사과부터 한다." 와 같은 보기는 인간적으로는 끌릴 수 있지만, PM의 객관성과 공정성을 해치는 최악의 선택입니다.
- 문제 회피: "팀원들이 스스로 해결하도록 지켜본다." "일단 급한 개발 업무부터 처리하고 나중에 논의한다." 와 같은 보기는 PM의 책임을 방기하는 것입니다. 프로젝트에 영향을 미치는 갈등과 불만은 반드시 관리되어야 할 '이슈'입니다.
- 권위적 해결: "PM의 권한으로 더 효율적인 B안을 채택하라고 지시한다." 와 같은 보기는 팀의 자율성과 전문성을 무시하는 행동입니다. 이는 단기적으로는 빨라 보일지 몰라도, 장기적으로는 팀의 사기와 주인의식을 떨어뜨립니다.
그렇다면 감정을 배제하고, 회피하지도 않고, 권위를 내세우지도 않으려면 대체 어떻게 해야 할까요?
감정 대신 '문서'와 '프로세스'를 꺼내 드세요 ⚙️
정답은 바로 '사전에 합의된 약속'을 기반으로 행동하는 것입니다. 유능한 PM은 문제가 터졌을 때 즉흥적으로 판단하지 않습니다. 대신, 프로젝트 초기에 팀원, 이해관계자들과 함께 만들어 둔 '우리들의 헌법'을 조용히 펼쳐 보입니다. PMP 시험에서 사람 문제를 만났을 때, 당신의 머릿속에는 다음 3가지 핵심 문서가 떠올라야 합니다.
1. 팀원 간의 갈등 발생 시 → 📜 팀 헌장 (Team Charter)
"그건 그런 식으로 말하면 안 되죠!" 와 같은 감정적 싸움이 시작될 때, PM이 할 일은 "두 분, 잠시만요. 우리 프로젝트 시작할 때 만들었던 팀 헌장 기억나시나요? 거기 명시된 갈등 해결 절차에 따라 공식적으로 논의해 보시죠." 라고 말하는 것입니다. 팀 헌장에는 팀의 가치, 의사소통 방식, 의사결정 방법, 그리고 바로 이 '갈등 해결 프로세스'가 명시되어 있습니다. 이는 PM의 주관적인 개입이 아닌, 팀 스스로 만든 규칙에 따라 문제를 해결하도록 이끄는 가장 객관적인 접근법입니다.
2. 역할과 책임(R&R) 문제 발생 시 → 📑 자원 관리 계획 / RACI 차트
"이 업무는 제 담당이 아닌 것 같은데요?" 라는 말이 나왔을 때, PM은 "아닌데요, 김대리님 일 맞는데요?" 라고 맞서는 대신, 자원 관리 계획서나 RACI 차트를 화면에 띄워야 합니다. 이 문서들에는 각 팀원이 어떤 역할(Role)과 책임(Responsibility)을 갖는지 명확하게 정의되어 있습니다. "여기 RACI 차트를 함께 보실까요? 이 업무의 Accountable 담당자는 김대리님으로 합의되어 있네요." 이처럼 문서에 기반한 대화는 불필요한 논쟁을 줄이고 사실에 집중하게 만듭니다.
3. 이해관계자 불만 제기 시 → 📢 의사소통 관리 계획
"왜 이 중요한 변경사항을 저한테는 보고하지 않은 거죠?" 라며 핵심 이해관계자가 불만을 표출할 때, PM은 당황해서 사과하기보다 의사소통 관리 계획서를 확인해야 합니다. 이 계획서에는 '누구에게, 무엇을, 언제, 어떤 방식'으로 소통할 것인지 상세히 정의되어 있습니다. 계획을 확인한 뒤, "계획에 따르면 해당 내용은 주간 보고서 이메일로 공유 드리기로 되어 있었는데, 혹시 전달 방식에 개선이 필요할까요?" 와 같이 프로세스를 점검하고 개선하는 방향으로 대화를 이끌어가는 것이 PMI가 원하는 PM의 모습입니다.
결국 PMI가 '사람' 문제를 통해 테스트하고 싶은 것은 당신의 공감 능력이 아니라, 감정에 휘둘리지 않고 공정하고 예측 가능한 시스템을 구축하고 운영할 수 있는 능력입니다. 차가워 보일 수 있지만, 사실 이것이야말로 팀원과 이해관계자 모두를 보호하는 가장 따뜻한 방법입니다. 명확한 규칙이 있을 때, 사람들은 비로소 불필요한 오해와 감정 소모 없이 자신의 역할에 집중하며 심리적 안정감을 느낄 수 있으니까요.
여러분은 팀의 암묵적인 룰이 없어서 힘들었던 경험, 혹은 우리 팀만의 공식적인 약속(Team Charter)이 있어서 위기를 넘겼던 경험이 있으신가요? 여러분의 회사는 어떻게 사람 문제를 다루고 있는지 궁금합니다.
자주 묻는 질문 (FAQ) ❓
Q1. 팀 헌장은 프로젝트 시작 시점에 무조건 만들어야 하나요?
PMI 관점에서는 '반드시' 그렇습니다. 프로젝트 초기에 규칙을 정하는 데 드는 시간과 노력은, 나중에 발생할 갈등을 해결하는 데 드는 비용과 감정 소모에 비하면 훨씬 저렴하기 때문입니다. 팀의 '헌법'을 만드는 과정이라고 생각하시면 됩니다.
Q2. 저희 회사는 그런 공식적인 문서를 잘 만들지 않는데, 어떻게 적용하죠?
PMP는 이상적인 글로벌 표준을 제시합니다. 현실에서는 작게 시작하는 것이 중요합니다. 거창한 문서가 아니더라도, 프로젝트 킥오프 때 팀원들과 함께 '우리 팀이 일하는 방식(Ground Rule)'에 대해 3~5가지 핵심 원칙을 정하고 이메일이나 위키에 공유하는 것만으로도 큰 효과를 볼 수 있습니다.
Q3. PM이 모든 갈등을 직접 해결해야 하나요?
아닙니다. PM의 역할은 해결사가 아니라 '해결 프로세스를 촉진하는 조력자(Facilitator)'입니다. 팀 헌장에 명시된 절차에 따라 팀이 스스로 문제를 해결하도록 돕고, 필요한 경우 객관적인 데이터를 제공하는 것이 더 중요합니다. 이는 팀의 문제 해결 능력을 키워주는 서번트 리더십의 핵심입니다.
Q4. 애자일(Agile) 환경에서도 이런 공식적인 문서가 유효한가요?
물론입니다. 명칭이나 형식이 다를 뿐 본질은 같습니다. 애자일에서는 보통 '팀 합의(Team Agreement)' 또는 '워킹 애그리먼트(Working Agreement)'라는 이름으로 더 가볍고 지속적으로 개선 가능한 형태로 존재합니다. 스프린트 회고 등을 통해 이 약속을 계속해서 현실에 맞게 업데이트하는 것이 중요합니다.
Q5. 이해관계자가 문서를 무시하고 계속 감정적으로 불만을 제기하면 어떻게 하죠?
이때는 '감정적 공감'과 '문제 해결'을 분리하는 지혜가 필요합니다. 먼저 1:1 면담을 통해 "많이 답답하셨겠네요."라며 상대방의 감정을 인정하고 경청해주는 것이 중요합니다. 하지만 해결책을 논의할 때는 "그렇다면 이 문제를 해결하기 위해, 우리가 합의했던 의사소통 계획을 어떻게 개선하면 좋을까요?"라며 다시 객관적인 프로세스 기반의 대화로 돌아와야 합니다.