《개발 너머의 일》PM이 된 개발자, 리더의

개발자로서 어느 정도 경력이 쌓인 후, 저는 PM(프로젝트 매니저)이라는 역할을 맡게 되었습니다. 처음에는 단순히 업무의 연장선상으로 생각했지만, 이 역할은 제게 완전히 새로운 도전과 시야를 제공했습니다. 개발자일 때는 코드를 잘 짜는 것이 전부였지만, PM이 되자 코드보다는 사람과 일정, 우선순위를 관리하는 일이 더 중요했습니다.

일정 관리 vs 사람 관리

PM으로 처음 프로젝트를 진행할 때, 저는 일정을 완벽하게 관리하고 싶었습니다. 상세한 일정을 만들고, 모든 것을 계획대로 진행하려 했지만 현실은 달랐습니다. 한 팀원이 개인적인 사정으로 예상보다 작업이 늦어졌고, 또 다른 팀원은 기술적 난관에 부딪혀 작업이 멈춰버리는 일이 발생했습니다.

처음엔 단지 일정의 문제라고 생각하고 압박을 주었지만, 그것은 오히려 역효과였습니다. 어느 날 한 팀원이 저를 따로 찾아와 "일정은 알겠지만, 사람의 사정도 고려해주셨으면 좋겠다"라고 했습니다. 이 말을 듣고 크게 깨달았습니다. 일정표는 숫자에 불과하고, 결국 프로젝트를 완성하는 건 사람이었다는 사실을 말입니다. 이후 저는 일정보다는 사람 관리에 더욱 신경 쓰게 되었습니다.

갈등 조율과 우선순위의 기술

PM의 가장 어려운 역할 중 하나는 다양한 이해관계자들의 요구를 조율하고 우선순위를 정하는 일이었습니다. 고객은 새로운 기능을 추가하길 원했고, 개발팀은 기술적 부담을 호소했습니다. 이 두 사이에서 저는 명확한 우선순위를 정해야 했습니다.

한 예로, 대형 쇼핑몰 앱 프로젝트 중 고객이 갑자기 대규모 기능 추가를 요청한 적이 있었습니다. 개발팀은 일정 내 완료가 불가능하다고 반발했고, 고객은 필수 기능이라며 물러서지 않았습니다. 저는 먼저 개발팀의 부담을 정확히 파악하고, 고객에게 현실적인 대안을 제시했습니다. 결국 단계별 기능 배포라는 절충안을 만들어 양측 모두 만족할 수 있었습니다. 이 경험을 통해 갈등 조율은 단순히 타협이 아니라, 모두가 납득할 수 있는 공통의 이해를 만드는 과정이라는 것을 깨달았습니다.

실력보다 더 중요한 ‘말하는 방식’

리더의 위치에서는 커뮤니케이션이 실력만큼이나 중요하다는 사실을 깨달았습니다. 실력이 뛰어난 개발자도 말하는 방식이 거칠거나 불친절하면 결국 팀의 분위기를 해칠 수 있었습니다.

한 번은 실력이 뛰어나지만 말투가 직설적이었던 개발자가 있었습니다. 그의 의도는 나쁘지 않았지만, 팀원들은 그의 말에 상처를 받곤 했습니다. 결국 제가 나서서 그 개발자와 진지하게 대화를 나눴고, 어떻게 소통을 개선할지 함께 고민했습니다. 그는 이후 자신의 의사소통 방식에 신경 쓰기 시작했고, 팀의 분위기와 협력의 질이 크게 좋아졌습니다.

이러한 경험들을 통해 PM으로서 리더십이 단순히 기술적인 부분을 넘어서 사람을 이해하고, 사람을 통해 목표를 달성하는 과정임을 배웠습니다.

다음 편에서는 운영을 통해 진짜 사용자 경험을 배우게 된 이야기를 전하겠습니다.