개발자와 갈등 없이 협업하는 PM의 7가지 원칙: 스타트업 생존 필수템

개발팀과 PM의 관계, 마치 톰과 제리 같다고 느껴본 적 없나요? 서로 쫓고 쫓기는 관계, 때로는 앙숙처럼 느껴지는 이 관계를 어떻게 하면 건설적으로 바꿀 수 있을까요? 제가 겪었던 수많은 삽질과 깨달음을 바탕으로, 개발팀과의 협업을 극대화하고, 불필요한 갈등을 최소화하는 7가지 실전 원칙을 공유합니다.

1. 전쟁의 서막: 왜 PM과 개발자는 싸우는가?

PM과 개발자의 갈등은 마치 숙명 같습니다. 서로의 역할과 책임이 다르기 때문에 발생하는 필연적인 현상일까요? 아니면 소통 부족, 오해에서 비롯된 문제일까요? 저는 둘 다 맞다고 생각합니다. PM은 '무엇'을 만들어야 하는지, '언제'까지 만들어야 하는지에 집중합니다. 반면, 개발자는 '어떻게' 만들 것인지, '기술적인 제약'은 무엇인지 고민합니다. 이처럼 초점이 다르기 때문에, 서로의 입장을 이해하지 못하면 갈등이 발생할 수밖에 없습니다.

실패담 #1: 과거 스타트업에서 PM으로 일할 때, 저는 MVP 출시를 위해 기능 목록을 쉴 새 없이 추가했습니다. 개발팀은 마감 기한을 맞추기 위해 야근을 밥 먹듯이 했죠. 결국, 론칭은 했지만, 코드 퀄리티는 엉망이었고, 기술 부채는 눈덩이처럼 불어났습니다. 그때 저는 PM으로서 '무엇'을 만드는 것만큼이나 '어떻게' 만드는지, 개발팀의 입장을 이해하는 것이 중요하다는 것을 깨달았습니다.

• PM의 목표: 빠른 출시, 사용자 만족, 비즈니스 목표 달성
• 개발자의 목표: 안정적인 코드, 기술적 완성도, 지속 가능한 시스템 구축

이처럼 서로 다른 목표를 이해하고 존중하는 것이 협업의 첫걸음입니다.

2. 기술 부채, PM도 책임감을 가져야 하는 이유

기술 부채는 마치 시한폭탄과 같습니다. 당장은 문제가 없어 보이지만, 시간이 지날수록 개발 속도를 늦추고, 시스템을 불안정하게 만들죠. 많은 PM들이 기술 부채를 개발팀의 문제로 치부하지만, 저는 PM도 기술 부채에 대한 책임감을 가져야 한다고 생각합니다. 왜냐하면, PM의 무리한 요구, 잦은 스펙 변경이 기술 부채를 키우는 주범이기 때문입니다.

사례 연구: 한 커머스 스타트업에서 A/B 테스트를 통해 전환율을 3배 증가시킨 기능이 있었습니다. 하지만, 이 기능은 급하게 개발된 탓에 코드 퀄리티가 매우 낮았고, 다른 기능에 영향을 미치는 잠재적인 버그를 안고 있었습니다. PM은 전환율 증가에만 집중한 나머지, 기술 부채의 위험성을 간과했고, 결국 몇 달 후 시스템 전체가 마비되는 사태가 발생했습니다.

기술 부채를 줄이기 위한 PM의 역할은 다음과 같습니다.

• 기술 부채 인지: 개발팀과 함께 기술 부채를 파악하고, 우선순위를 정합니다.
• 리스크 관리: 기술 부채가 비즈니스에 미치는 영향을 분석하고, 리스크를 관리합니다.
• 장기적인 관점: 단기적인 성과에 매몰되지 않고, 장기적인 관점에서 기술 부채를 해결합니다.

3. 우선순위, 투명하게 공개하고 함께 결정하라

개발팀은 제한된 자원을 가지고 있습니다. 모든 기능을 동시에 개발할 수 없죠. 따라서, PM은 기능의 우선순위를 명확하게 정의하고, 개발팀과 공유해야 합니다. 이때, 단순히 비즈니스 가치만을 기준으로 우선순위를 결정하는 것은 위험합니다. 개발 난이도, 기술적인 제약, 기술 부채 등 다양한 요소를 고려해야 합니다.

데이터 분석: 한 설문 조사에 따르면, 개발자의 70%가 PM이 우선순위를 결정하는 과정에 참여하지 못한다고 응답했습니다. 이는 개발팀의 불만을 야기하고, 협업 효율성을 저하시키는 주요 원인으로 작용합니다.

우선순위 결정 과정에 개발팀을 참여시키는 방법은 다음과 같습니다.

• 정기적인 회의: 개발팀과 함께 스프린트 계획 회의를 진행하고, 기능의 우선순위를 논의합니다.
• 데이터 공유: 사용자 데이터, A/B 테스트 결과 등 의사 결정에 필요한 데이터를 공유합니다.
• 피드백 수렴: 개발팀의 의견을 경청하고, 현실적인 제약 사항을 반영합니다.

4. 스펙 변경, 신중하게 접근해야 하는 이유

PM의 잦은 스펙 변경은 개발팀에게 악몽과 같습니다. 이미 개발이 완료된 기능을 수정해야 하고, 테스트를 다시 진행해야 하며, 마감 기한을 맞추기 위해 야근을 해야 합니다. 스펙 변경은 개발팀의 사기를 저하시키고, 코드 퀄리티를 떨어뜨리는 주범입니다.

Before/After 비교: 한 프로젝트에서 PM은 개발 진행 중 3번의 스펙 변경을 요청했습니다. 그 결과, 개발 기간은 2배로 늘어났고, 코드 퀄리티는 30% 감소했으며, 팀원들의 만족도는 50% 하락했습니다.

스펙 변경을 최소화하기 위한 PM의 노력은 다음과 같습니다.

• 사전 검토 강화: 개발 시작 전에 스펙을 꼼꼼하게 검토하고, 불확실성을 제거합니다.
• 사용자 검증: 사용자 인터뷰, 프로토타입 테스트 등을 통해 스펙의 타당성을 검증합니다.
• 변경 관리 프로세스: 스펙 변경 요청에 대한 명확한 프로세스를 정의하고, 변경의 필요성을 신중하게 평가합니다.

5. 소통, 명확하고 솔직하게 해야 오해가 없다

소통은 협업의 핵심입니다. PM은 개발팀에게 명확하고 솔직하게 정보를 전달해야 합니다. 모호한 표현, 숨겨진 의도, 감정적인 언어는 오해를 불러일으키고, 갈등을 심화시킬 수 있습니다.

논란 요소: 일부 PM들은 개발팀에게 압박감을 주기 위해 일부러 어려운 용어를 사용하거나, 비판적인 어조로 말하는 경향이 있습니다. 이는 단기적으로는 효과가 있을지 모르지만, 장기적으로는 신뢰를 잃고, 협업 관계를 악화시키는 결과를 초래합니다.

효과적인 소통을 위한 PM의 자세는 다음과 같습니다.

• 경청: 개발팀의 의견을 주의 깊게 듣고, 공감하는 자세를 보여줍니다.
• 간결함: 복잡한 내용을 쉽게 이해할 수 있도록 간결하게 설명합니다.
• 피드백: 개발팀의 성과를 인정하고, 건설적인 피드백을 제공합니다.

6. 개발 문화 존중, 함께 성장하는 팀 만들기

개발팀은 고유한 문화를 가지고 있습니다. 코드 리뷰, 페어 프로그래밍, 스크럼 등 다양한 방법론을 통해 코드 퀄리티를 높이고, 지식을 공유합니다. PM은 이러한 개발 문화를 존중하고, 함께 성장하는 팀을 만들어야 합니다.

실전 사례: 한 스타트업에서 PM은 개발팀의 코드 리뷰 문화를 적극적으로 지원했습니다. 코드 리뷰 시간을 확보해주고, 리뷰에 필요한 도구를 제공하고, 리뷰 결과를 공유하는 자리를 마련했습니다. 그 결과, 코드 퀄리티는 20% 향상되었고, 버그 발생률은 15% 감소했습니다.

개발 문화 존중을 위한 PM의 행동은 다음과 같습니다.

• 학습 지원: 개발팀의 학습을 지원하고, 새로운 기술을 도입하는 데 적극적으로 참여합니다.
• 지식 공유: 개발팀의 지식을 공유하고, 함께 성장하는 문화를 조성합니다.
• 자율성 보장: 개발팀에게 업무 방식에 대한 자율성을 보장하고, 창의적인 아이디어를 장려합니다.

7. 도구 활용, 협업 효율성을 극대화하라

다양한 협업 도구를 활용하면 개발팀과의 커뮤니케이션을 원활하게 하고, 업무 효율성을 높일 수 있습니다. 슬랙, 지라, 컨플루언스 등 협업 도구를 활용하여 정보를 공유하고, 진행 상황을 추적하고, 피드백을 주고받을 수 있습니다.

추천 도서:

• 린 스타트업 - (쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.)
• 프로덕트 매니저 - (쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.)

협업 도구 활용 팁:

• 슬랙 (Slack): 실시간 커뮤니케이션, 파일 공유, 알림 기능 등을 제공합니다.
• 지라 (Jira): 이슈 관리, 프로젝트 추적, 스프린트 계획 기능 등을 제공합니다.
• 컨플루언스 (Confluence): 문서 협업, 지식 공유, 회의록 작성 기능 등을 제공합니다.

8. 함정: PM이 절대 하지 말아야 할 행동들

PM은 다음과 같은 행동을 절대 해서는 안 됩니다.

• 개발팀에게 일방적으로 지시한다.
• 기술적인 내용을 잘 모르는 척한다.
• 스펙 변경을 밥 먹듯이 한다.
• 개발팀의 노력을 폄하한다.
• 개인적인 감정을 드러낸다.

이러한 행동들은 개발팀의 사기를 저하시키고, 협업 관계를 악화시키는 결과를 초래합니다.

9. 결론: 함께 성장하는 PM이 되자

개발자와의 협업은 마치 춤과 같습니다. 서로의 움직임을 이해하고, 호흡을 맞춰야 아름다운 무대를 만들 수 있습니다. PM은 개발팀을 존중하고, 함께 성장하는 파트너가 되어야 합니다. 이 글에서 제시된 7가지 원칙을 실천하여 개발팀과 윈-윈하는 관계를 구축하고, 성공적인 프로덕트를 만들어나가시길 바랍니다. 혹시 더 궁금한 점이나 공유하고 싶은 경험이 있다면 댓글로 남겨주세요!

• 스타트업 첫 PM으로 입사하기 전

이 글이 도움 됐다면 SNS 공유 부탁드립니다!