개발자, 웬수 아냐! PM이 겪어보니 알겠더라: 협업 스킬 풀장착 가이드
개발자, 웬수 아냐! PM이 겪어보니 알겠더라: 협업 스킬 풀장착 가이드
솔직히 말해서, PM하면서 개발자랑 안 싸워본 사람 손?… 없겠지. 나는 디자이너에서 PM으로 전향한 6년차인데, 아직도 가끔 '아, 내가 왜 이걸 시작했을까' 싶을 때가 있어. 특히 스프린트 막바지에 버그 때문에 밤샘 각 뜰 때. 하지만 결국 깨달았지. 개발자는 웬수가 아니라, 함께 목표를 향해 달려가는 '동료'라는 걸. 문제는 그 '달려가는' 방식이 너무나 다르다는 거다. 마치 페라리와 경운기처럼.
자, 그럼 어떻게 해야 이 페라리 같은 개발자님들과 경운기 같은… 아니, 섬세한 감성의 PM이 아름다운 협업을 이뤄낼 수 있을까? 내 6년간의 뼈와 살을 깎는 경험과, ADHD 덕분에 얻은 (억지로) 뛰어난 분석력으로 깐깐하게 분석해봤다. (아, 목도 뻐근하네. 역시 거북목 방지템 하나 사야 하나… 쿠팡 파트너스 링크: 거북목 방지 목베개) 일단 시작해보자.
1. 데이터로 말해, 감정은 쓰레기통에 (일단) 넣어둬.
PM이라면 누구나 '데이터 기반 의사결정'의 중요성을 귀에 딱지가 앉도록 들었을 거다. 근데 이걸 실제로 얼마나 실천하고 있을까? 감정에 휘둘려 '느낌적인 느낌'으로 개발자를 설득하려 들진 않았는지 냉정하게 돌아보자. 특히, “이번 디자인이 너무 예뻐서 유저들이 엄청 좋아할 거예요!” 같은 말은… 제발… (물론 예쁜 건 중요하지만, 그 '예쁨'을 뒷받침할 데이터가 없다면 그냥 망상일 뿐이다.)
사례: 한 번은 새로운 로그인 플로우를 도입하려고 했다. 디자인팀은 기존 방식보다 훨씬 직관적이고 아름답다고 주장했지만, 나는 망설였다. 그래서 A/B 테스트를 진행했고, 결과는 충격적이었다. 새로운 플로우의 전환율이 기존 방식보다 15%나 낮았던 것이다. (출처: 자체 A/B 테스트 결과 보고서, 2023.10.26.)
이 데이터 덕분에 디자인팀은 아쉬움을 뒤로하고 기존 방식을 유지하기로 결정했다. 물론 처음에는 불만이 있었지만, 객관적인 데이터를 보여주니 결국 수긍하더라. 감정적인 설득보다 데이터 한 방이 훨씬 효과적이라는 걸 뼈저리게 느꼈다.
핵심:
- 정량적 데이터: 사용자 행동 데이터, A/B 테스트 결과, 성능 지표 등 객관적인 데이터를 수집하고 분석하라.
- 정성적 데이터: 사용자 인터뷰, 설문 조사 등을 통해 사용자 니즈를 파악하고, 이를 데이터로 정량화하라.
- 시각화: 데이터를 시각적으로 표현하여 이해도를 높여라. (구글 데이터 스튜디오, 엑셀, 태블로 등 활용)
2. 개발자의 언어로 소통하라: 최소한의 '개발 용어' 습득 필수
개발자와 효과적으로 소통하려면 그들의 '언어'를 이해해야 한다. 마치 외국어를 배우는 것처럼 말이다. 물론 개발자가 될 필요는 없다. 하지만 최소한의 개발 용어와 개념은 숙지해야 한다. 예를 들어, API, 프레임워크, 데이터베이스, 알고리즘 같은 용어들을 모른다면, 개발자와의 대화는 엉뚱한 방향으로 흘러갈 가능성이 높다. (마치 내가 다이어트 한다고 탄수화물 '로딩'하는 것만큼이나.)
경험담: 초기 PM 시절, 나는 'API'가 뭔지도 모르고 개발자에게 API 연동을 요청했다가 엄청난 비웃음을 샀다. (지금 생각해도 이불킥 감이다.) 그 후로 나는 개발 관련 책을 읽고, 온라인 강의를 들으며 개발 용어들을 공부했다. 덕분에 지금은 개발자와 어느 정도 수준의 대화는 나눌 수 있게 되었다. (물론 아직도 어려운 부분은 많지만…)
꿀팁:
- 개발 관련 서적/강의: 생활코딩 같은 무료 강의부터 유료 강의까지, 다양한 학습 자료를 활용하라.
- 개발자에게 질문: 모르는 용어가 있다면 주저하지 말고 개발자에게 질문하라. 단, 질문하기 전에 스스로 검색해보고, 최대한 구체적인 질문을 준비하는 것이 좋다.
- 개발 블로그 구독: 기술 블로그를 구독하고 최신 트렌드를 파악하라. (Medium, Velog, 개발자 개인 블로그 등)
3. '왜'를 설명해라. '어떻게'는 개발자 몫이다.
PM의 역할은 '무엇'을 만들 것인지 정의하고, 그 '이유'를 명확하게 설명하는 것이다. '어떻게' 만들 것인지는 개발자의 전문 영역이다. PM이 개발 방식에 대해 지나치게 간섭하면, 개발자는 자신의 능력을 무시당한다고 느낄 수 있다. (마치 내가 'AI는 다 알아서 해줄 거야' 라고 말하는 것과 같다. 물론 AI는 훌륭하지만, 모든 것을 해결해 주진 않는다.)
실패 사례: 과거에 나는 개발팀에 특정 라이브러리를 사용하도록 강요한 적이 있었다. 그 이유는 단순히 내가 그 라이브러리에 익숙했기 때문이다. 하지만 개발팀은 그 라이브러리가 프로젝트에 적합하지 않다고 판단했고, 결국 프로젝트는 예상보다 훨씬 오래 걸리고, 퀄리티도 좋지 않게 마무리되었다. (결국 나는 엄청나게 깨지고, 깨달음을 얻었다.)
교훈:
- 목표 명확화: 개발자에게 프로젝트의 목표와 비전을 명확하게 설명하고, 그들이 왜 이 프로젝트에 참여해야 하는지 동기부여하라.
- 요구사항 정의: 기능 요구사항을 명확하고 구체적으로 정의하되, 개발 방식에 대한 간섭은 최소화하라.
- 신뢰 구축: 개발자의 전문성을 존중하고, 그들에게 충분한 자율성을 부여하라.
4. 감정 쓰레기통이 되어주되, 적당히 하자. (번아웃 방지!)
PM은 종종 팀원들의 감정 쓰레기통 역할을 해야 할 때가 있다. 특히 개발팀은 마감 압박, 버그 수정, 기술적인 문제 등으로 스트레스를 많이 받는다. 그들의 고충을 들어주고 공감해주는 것은 중요하지만, 모든 감정을 받아주는 것은 PM 본인의 번아웃으로 이어질 수 있다. (나는 ADHD 약 먹는 것도 잊을 정도로 정신이 나가버리더라.)
나만의 멘탈 관리법:
- 경청: 팀원들의 이야기를 주의 깊게 들어주고, 그들의 감정을 이해하려고 노력하라.
- 공감: 팀원들의 고충에 공감하고, 그들이 혼자가 아니라는 것을 느끼게 해주라.
- 객관적인 조언: 감정적인 공감 외에도, 문제 해결을 위한 객관적인 조언을 제공하라.
- 개인 시간 확보: 업무 외 시간을 통해 스트레스를 해소하고, 재충전하는 시간을 가져라. (나는 명상 앱을 사용하거나, 맛있는 걸 먹으면서 넷플릭스를 본다. 쿠팡 파트너스 링크: 넷플릭스 기프트카드)
- 전문가 도움: 필요하다면 정신과 상담이나 코칭을 받는 것도 좋은 방법이다. (나는 ADHD 치료 받으면서 많이 좋아졌다.)
실전 팁: 지금 바로 적용 가능한 5가지 액션 아이템
- 오늘 당장 스프린트 회고에 참여해서, 개발팀의 솔직한 피드백을 경청하라. (그리고 꼭 반영해라.)
- 개발 관련 책 한 권을 빌려, 1주일 안에 10페이지 이상 읽어라. (너무 어렵다면, 개발 관련 유튜브 영상이라도 봐라.)
- 다음 회의에서 개발 용어를 3개 이상 사용해라. (물론 정확한 의미를 알고 사용해야 한다.)
- 개발팀원에게 커피 한 잔을 사주고, 고충을 들어줘라. (진심으로 공감하는 모습을 보여줘야 한다.)
- 오늘 퇴근 후, 30분 동안 명상 앱을 사용하거나, 좋아하는 음악을 들으며 휴식을 취해라. (번아웃은 만병의 근원이다.)
마무리: 함께 성장하는 PM이 되자! (그리고 좋아요, 댓글, 공유 부탁해요!)
개발자와의 협업은 결코 쉬운 일이 아니다. 하지만 서로의 차이를 이해하고 존중하며, 끊임없이 소통하고 노력한다면, 최고의 팀워크를 만들어낼 수 있다. 나 역시 아직도 부족한 점이 많지만, 꾸준히 배우고 성장하는 PM이 되기 위해 노력할 것이다. 여러분도 함께 성장하는 PM이 되기를 응원한다!
마지막으로, 이 글이 도움이 되었다면 좋아요, 댓글, 공유 부탁드립니다! 그리고 제 뉴스레터를 구독하시면 더 많은 PM 꿀팁을 받아보실 수 있습니다! (링크 삽입 예정)