[3] 초보 개발 PM의 위기 | 팀워크가 무너진다는 말이 들려왔다

1. 위기의 징후

프로젝트가 한창이던 어느 날, 뜻밖의 말이 전해졌다.

“팀워크가 깨지고 있는 것 같대요. A님이 지치신 것 같은데, 위로가 필요할 것 같아요.”

 

그 말을 전해준 사람에게 먼저 고마움이 스쳤다.
누군가의 마음 상태를 이렇게 세심하게 살펴서 알려주는 건, 아무나 할 수 있는 일이 아니니까.
하지만 동시에, 그 말은 내 마음 한가운데로 ‘쿵’ 하고 내려앉았다.

A님은 프로젝트 곳곳에서 묵묵히 버티며 여러 역할을 감당해온 팀원이었다.
그 생각이 미안함과 책임감을 한꺼번에 몰고 왔다. 복잡한 생각들이 밤새 나를 붙잡아, 좀처럼 잠들 수 없었다.

나는 바쁘게 프로젝트를 진행하며, 우리의 팀워크가 점점 더 견고해지고 있다고 믿고 있었다.
하지만 그것은 착각이었다.
특정 사람들에게 업무가 과도하게 몰리고 있다는 사실을 미처 보지 못했던 것이다.

그 말을 들은 뒤에야 비로소 깨달았다. 평소 활발하던 팀 Slack 수다방이 최근 들어 유난히 조용해졌다는 것을...

초기에 업무 분배를 UI 단위로 나누다 보니 복잡한 스펙을 고려하지 못했다.
UI 뒤에 숨겨진 수많은 연동 작업과 부수적인 작업들을 고려하지 못한 것이였다.
그래서 특정 부분을 맡은 팀원에게 너무 많은 업무가 몰릴 수 있다는 사실을 간과했다.
(1편에서의 나의 단순한 선택이 불러온 파장이었다.)

또한, 개발자로서의 작업과 처음 맡은 PM 역할을 동시에 하다 보니, 어느 순간 ‘다른 사람들의 상황’을 살피는 일이 뒷전으로 밀려나 있었다.
그 사이 팀원들은 일에 파묻혀 점점 더 바빠지고, 스트레스는 커지고, 악순환의 고리가 조용히 조여왔다.

그때 머릿속을 스친 생각.

“이대로 가면… 정말 팀이 무너질 수도 있겠다.”

---

2. 숨 고르기, 그리고 중간 점검

나는 ‘중간 점검 회의’를 제안했다.
모두의 시간을 1~2시간 붙잡아 두는 게 부담이 될 수 있겠지만, 이대로 가는 것은 훨씬 더 위험했다.

회의 자리에서 우리는 프로젝트 보드를 펼쳤다.

• 업무 집중도 파악: 일이 어디에 몰려 있는지 시각적으로 확인
• 우선순위 조정: 지금 진행 중인 업무를 제외한 나머지는 과감히 할당 해제
• 새 원칙 공유: “지금 일만 끝내면, 다음 건 보드에서 직접 가져갑시다.”

이어서 막힌 부분과 해야 할 일을 전부 리스트업했다.

• 아직 정리되지 않은 스펙들 확인
• 팀 전체가 합의해야 하는 개발 방식 점검
• 공통으로 개발해 사용할 수 있는 부분들 취합
• 남은 배포 일정 논의

그 자리에서 나는 쌓인 일보다도 “각자 맡은 일에만 집중하자”는 원칙을 다시 한번 강조했다.
회의가 끝날 무렵, 업무가 과중했던 팀원들의 마음이 조금은 가벼워진 것을 느꼈다.

그리고 나 역시 이 시간을 통해, 우리의 프로젝트가 지금 어디쯤 와 있는지, 앞으로 무엇을 해야 하는지를 또렷하게 파악할 수 있었다.
그것만으로도 충분히 귀중한 시간이었다.

---

3. 데일리 스크럼이 도움되는 상황

중간 점검 회의가 끝날 무렵, 리더님이 한 가지 제안을 했다.

“긴장감을 유지하려면, 당분간 데일리 스크럼을 해보는 게 좋겠습니다.”

사실 나는 처음에 망설였다.
과거의 경험상, 데일리 스크럼은 매일 의무적으로 하는 지루한 형식에 그치는 경우가 많았기 때문이다.
하지만 이번 프로젝트처럼 짧은 기간 안에 모두가 힘을 합쳐 결과를 내야 하는 상황에서는, 그 효과가 전혀 달랐다.

데일리 스크럼은 “진행 중입니다”로 끝나는 형식적인 보고가 아니었다.
우리는 프로젝트 보드를 함께 보며 진행 상황을 한눈에 파악했고, 막힌 부분을 바로 논의했다.

• 어제는 이만큼 진행했고
• 오늘은 이걸 마무리할 예정이며
• 여기는 아직 막혔다는 점

모두가 같은 그림을 보니 대화가 다시 살아났다.
무엇보다, 거대한 업무 덩어리가 ‘작게 쪼개진 조각’으로 보이기 시작하자 부담이 눈에 띄게 줄었다.

“이거 끝내면, 다음 걸 하면 되지.”
그 마음가짐이 팀 전체에 조금씩 번져갔다.

---

4. 깨달음 — ‘보인다’는 건 큰 힘이다

이번 경험에서 나는 하나를 확실히 배웠다.

압박감은 ‘양’ 때문만이 아니라 ‘보이지 않음’에서 온다.

보이지 않으면 상상력이 불안을 키운다.
반대로, 상황이 한 눈에 보이면 ‘할 수 있다’는 확신이 조금씩 자란다.
중간 점검과 데일리 스크럼은 단순한 회의가 아니라, 서로를 다시 연결해 주는 장치였다.

PM의 역할은 단순히 일정을 맞추는 게 아니라, 팀이 “우린 같이 하고 있다”는 감각을 잃지 않게 하는 거라는 걸, 이번에 뼈저리게 느꼈다.

---

다음 편에서는, 위기를 넘기고 나서 우리가 어떻게 배포까지 갈 수 있었는지, 그리고 그 과정에서 부딪힌 또 다른 현실 이야기를 해보려고 한다.

 

앞으로의 이야기

0️⃣ 개발 5년 차, PM을 맡다 | 초보 개발 PM의 고민과 성장
1️⃣ 초보 개발 PM의 파악기 | 개발 PM이 하는 일
2️⃣ 초보 개발 PM의 적응기 | 결국은 커뮤니케이션
📌 초보 개발 PM의 위기 | 팀워크가 무너진다는 말이 들려왔다
4️⃣ 초보 개발 PM의 끈기 | 반드시 배포는 해야 합니다
5️⃣ 초보 개발 PM의 성장기 | 더욱 강해졌다, 그리고 커리어의 다음 단계