개발팀과 소통이 어려웠던 PM이 '엘리펀트 인 더 룸'에서 찾은 답 3가지

소프트웨어 엔지니어링 리더십 서적 '엘리펀트 인 더 룸'을 PM/기획자 관점에서 분석했습니다. 개발팀과의 효과적인 소통과 의사결정을 위한 핵심 질문과 답변을 FAQ 형식으로 정리합니다.

개발팀과의 소통, 때로는 거대한 코끼리처럼 눈앞에 있지만 말하기 어려운 주제를 마주할 때가 있습니다. 기획자나 PM이라면 개발팀의 언어를 완벽히 이해하기 어렵고, 기술적인 문제 뒤에 숨겨진 진짜 어려움을 파악하기란 더욱 쉽지 않습니다. 요구사항을 전달했는데 예상치 못한 난관에 부딪히거나, 개발 기간이 자꾸 늘어져 답답했던 경험이 있으신가요? 이 모든 상황 속에서 우리는 무엇을 놓치고 있었던 걸까요?

이런 고민을 가진 분들을 위해 <엘리펀트 인 더 룸: 소프트웨어 엔지니어링 리더십의 복잡성을 해결하는 핵심 질문과 답변>은 단순한 개발 서적을 넘어, 개발팀의 내부 세계를 이해하고 효과적으로 협력하기 위한 통찰을 제공합니다. 이 책은 복잡한 소프트웨어 엔지니어링 리더십의 핵심을 '자주 묻는 질문(FAQ)' 형식으로 풀어내, 개발 지식이 필요한 PM이나 기획자가 개발팀의 관점에서 문제를 바라보고 의사결정을 내리는 데 큰 도움을 줍니다. 오늘은 이 책이 제시하는 주요 질문과 답변을 PM/기획자 관점에서 3가지 핵심 인사이트로 정리해봅니다.

📑 목차

• 1. 개발팀의 '숨겨진 문제'를 파악하는 핵심 질문 3가지
• PM/기획자를 위한 문제 파악 질문
• 2. 기술 부채와 의사결정, PM은 무엇을 알아야 할까?
• 기술 부채에 대한 PM/기획자의 관점
• 3. 성공적인 개발팀 협업을 위한 PM의 소통 전략
• PM/기획자를 위한 소통 강화 팁
• 결론: PM/기획자를 위한 '엘리펀트 인 더 룸'의 가치

Image by PIRO4D on Pixabay

1. 개발팀의 '숨겨진 문제'를 파악하는 핵심 질문 3가지

PM이나 기획자가 개발팀과 협업할 때 가장 어려운 점 중 하나는 개발팀이 겪는 진정한 어려움을 파악하는 것입니다. 단순히 '어렵다', '오래 걸린다'는 답변 너머에 숨겨진 기술적, 인적, 프로세스적 문제들을 이해해야 비로소 효과적인 의사결정이 가능합니다. <엘리펀트 인 더 룸>은 이러한 '숨겨진 코끼리'를 발견하기 위한 질문의 중요성을 강조합니다.

PM/기획자를 위한 문제 파악 질문

• "이 작업이 왜 예상보다 오래 걸릴까요? 구체적인 장애물은 무엇인가요?"
  단순히 '시간이 오래 걸린다'는 답변 대신, 개발팀이 현재 어떤 기술적 제약, 레거시 코드, 혹은 외부 의존성 때문에 어려움을 겪는지 구체적으로 질문해야 합니다. 예를 들어, 특정 기능 구현에 2주가 걸린다고 할 때, "새로운 프레임워크 학습 시간 때문인가요, 아니면 기존 시스템과의 통합 문제 때문인가요?"와 같이 질문하여 실제 병목 지점을 파악할 수 있습니다.
• "이 작업을 진행했을 때 발생할 수 있는 잠재적 위험은 무엇인가요?"
  개발팀은 단순히 기능을 구현하는 것을 넘어, 장기적인 유지보수성, 확장성, 안정성 등 다양한 측면을 고려합니다. PM은 단기적 목표 달성만큼이나 장기적 리스크 관리에 관심을 가져야 합니다. "이 기능 추가가 향후 시스템 안정성에 어떤 영향을 미칠까요? 특정 서비스에 과부하를 줄 가능성은 없나요?"와 같은 질문은 개발팀이 미처 말하지 못했던 잠재적 위험을 표면 위로 끌어올립니다.
• "이 문제를 해결하기 위해 가장 효과적인 방법은 무엇이라고 생각하시나요? 대안은 없나요?"
  개발팀은 주어진 요구사항을 구현하는 것을 넘어, 문제 해결의 전문가입니다. 때로는 PM이 제시한 방식보다 더 효율적이거나 견고한 기술적 대안을 가지고 있을 수 있습니다. 개발팀의 의견을 존중하고 대안을 물어보는 것은 단순히 기능 구현을 넘어, 최적의 솔루션을 함께 찾아가는 과정이 됩니다. 예를 들어, "클라우드 서비스 A를 사용하려는데, 혹시 내부적으로 더 효율적인 방식으로 처리할 수 있는 아이디어가 있을까요?"와 같이 질문하여 개발팀의 창의적인 해결책을 이끌어낼 수 있습니다.

이러한 질문들을 통해 PM/기획자는 개발팀의 기술적 관점과 제약을 더 깊이 이해하고, 불확실성을 줄여 보다 현실적인 기획과 의사결정을 내릴 수 있습니다. 이는 단순히 질문을 던지는 것을 넘어, 개발팀과의 신뢰 기반 소통을 구축하는 첫걸음이 됩니다.

2. 기술 부채와 의사결정, PM은 무엇을 알아야 할까?

기술 부채(Technical Debt)는 소프트웨어 개발 과정에서 피할 수 없는 현실입니다. 빠른 시장 출시를 위해 당장의 최적화를 미루거나, 급하게 코드를 작성하는 등의 선택으로 인해 미래에 추가적인 비용이나 노력이 발생하는 것을 의미합니다. PM/기획자는 기술 부채를 단순히 '개발팀의 문제'로 치부하기보다, 비즈니스적 관점에서 이해하고 관리해야 할 중요한 요소로 인식해야 합니다.

기술 부채에 대한 PM/기획자의 관점

이 책은 기술 부채가 비즈니스에 미치는 영향을 명확히 설명하며, PM이 개발팀과 함께 기술 부채를 어떻게 다룰지 의사결정하는 방법을 제시합니다. 다음 표는 기술 부채에 대한 전통적인 PM의 시각과, <엘리펀트 인 더 룸>이 제시하는 PM의 시각을 비교합니다.

구분	전통적인 PM의 기술 부채 인식	‘엘리펀트 인 더 룸’이 제시하는 PM의 인식
기술 부채의 본질	단순히 '개발팀이 코드를 잘 못 짠 것' 또는 '나중에 고치면 되는 것'으로 인식.	비즈니스 가치 창출에 지장을 주는 요소이자, 미래 기능 개발 비용을 증가시키는 투자 리스크로 인식.
의사결정 관점	새로운 기능 개발에만 집중하고, 기술 부채 해결은 후순위로 미룸.	기술 부채 해결을 제품 로드맵의 일부로 간주하고, 비즈니스 임팩트를 기준으로 우선순위를 결정.
소통 방식	개발팀의 기술 부채 언급에 대해 '왜 지금 해야 하는가?'라고 반문.	기술 부채 해결의 비용-편익 분석을 요구하고, 비즈니스적 관점에서 함께 논의.

예를 들어, 개발팀이 "이 레거시 모듈 때문에 신규 기능 개발에 2배의 시간이 소요됩니다"라고 보고했을 때, PM은 단순히 '새 기능이 늦어진다'고 생각하는 것이 아니라, "이 레거시 모듈을 개선하는 데 드는 비용(예: 1인월)과, 이로 인해 얻을 수 있는 장기적인 이점(예: 향후 1년간 기능 개발 속도 50% 향상, 버그 발생률 20% 감소)을 비교했을 때 어떤 선택이 비즈니스에 더 유리할까요?"와 같이 질문하며 전략적인 관점에서 접근해야 합니다.

기술 부채는 단순히 기술적인 문제가 아니라, 비즈니스적 의사결정의 한 축입니다. 이 책은 PM이 기술 부채를 단순히 회피하는 것이 아니라, 정보에 기반한 의사결정을 통해 효과적으로 관리할 수 있도록 돕습니다.

Image by Tumisu on Pixabay

3. 성공적인 개발팀 협업을 위한 PM의 소통 전략

개발팀과의 원활한 소통은 프로젝트 성공의 핵심입니다. 하지만 서로 다른 배경과 목표를 가진 PM과 개발팀 사이에는 종종 오해와 갈등이 발생합니다. <엘리펀트 인 더 룸>은 엔지니어링 리더십의 관점에서 효과적인 소통의 중요성을 강조하며, 특히 PM/기획자에게 실질적인 조언을 제공합니다.

PM/기획자를 위한 소통 강화 팁

• "WHY"를 명확히 설명하세요:
  개발팀에게 단순히 '무엇을(What)' 만들지 전달하는 것을 넘어, '왜(Why)' 이 기능이 필요한지, 어떤 사용자 문제를 해결하는지, 어떤 비즈니스 가치를 창출하는지 명확하게 설명해야 합니다. 예를 들어, "간편 로그인 기능을 추가해주세요"라고 말하기보다, "사용자들이 회원가입 과정에서 이탈하는 비율이 30%에 달합니다. 간편 로그인 기능으로 이탈률을 줄여 사용자 유입을 늘리고자 합니다"와 같이 맥락과 목적을 공유하면 개발팀은 단순한 구현자가 아닌, 문제 해결의 주체로서 더 깊이 공감하고 참여할 수 있습니다.
• 기술적 제약을 이해하고 존중하세요:
  개발팀이 '안 된다'거나 '어렵다'고 말할 때, 그것은 단순히 거절이 아닐 수 있습니다. 기존 시스템의 한계, 예상치 못한 복잡성, 보안 문제 등 다양한 기술적 제약 때문일 수 있습니다. 이럴 때는 "어떤 기술적 제약 때문에 어려운가요? 대안은 없을까요?"와 같이 질문하며 기술적 관점을 이해하려는 노력을 보여야 합니다. 개발팀의 제안을 경청하고 함께 해결책을 모색하는 태도는 상호 존중과 신뢰를 구축하는 데 필수적입니다.
• 정기적인 피드백과 인정:
  개발 과정에서 정기적인 피드백을 제공하고, 개발팀의 노력과 성과를 인정하는 것은 동기 부여에 매우 중요합니다. 단순히 버그를 지적하거나 지연을 질책하는 것이 아니라, "어려운 상황에서도 이 기능을 잘 구현해주셔서 감사합니다. 덕분에 사용자 만족도가 높아질 것 같습니다"와 같이 긍정적인 피드백과 함께 기여를 인정하는 메시지를 전달해야 합니다. 이는 개발팀이 자신의 업무에 대한 보람을 느끼고, 다음 프로젝트에서도 적극적으로 임하게 하는 원동력이 됩니다.

이러한 소통 전략들은 PM이 개발팀과 단순히 업무 관계를 넘어 파트너십을 구축하는 데 기여합니다. 명확한 목표 공유, 기술적 배경 이해, 그리고 상호 존중은 개발팀의 생산성을 높이고, 궁극적으로는 더 나은 제품을 만드는 기반이 됩니다.

결론: PM/기획자를 위한 '엘리펀트 인 더 룸'의 가치

<엘리펀트 인 더 룸>은 소프트웨어 엔지니어링 리더십에 대한 책이지만, 개발 지식이 필요한 PM이나 기획자에게도 개발팀의 세계를 이해하는 강력한 도구가 될 수 있습니다. 이 책은 개발팀이 마주하는 복잡한 문제들을 명확히 파악하고, 기술 부채를 포함한 다양한 의사결정 포인트를 비즈니스 관점에서 재해석하며, 궁극적으로 개발팀과의 효과적인 소통 전략을 제시합니다.

이 책을 통해 PM/기획자는 개발팀의 '숨겨진 코끼리'를 발견하고, 기술적 제약을 비즈니스 기회로 전환하며, 더 나아가 개발팀과 진정한 파트너십을 구축할 수 있을 것입니다. 개발팀과의 소통이 막막하게 느껴졌다면, 이 책이 제시하는 질문과 답변을 통해 새로운 시야를 얻어보시길 강력히 추천합니다.

여러분은 개발팀과 소통하며 어떤 '코끼리'를 마주한 경험이 있으신가요? 이 책에서 어떤 질문과 답변이 가장 인상 깊으셨는지 댓글로 공유해주세요!

📌 함께 읽으면 좋은 글

• [개발 도구] Go 모듈은 왜 항상 최신 버전만 가져오지 않을까? MVS와 불변성 파헤치기
• [임베디드 IoT] 느려터진 IoT 대시보드, 엣지에서 데이터 전처리로 다시 숨통 튼 이야기
• [클라우드 인프라] 클라우드 DNS 기반 글로벌 트래픽 관리(GTM) 장애 조치, 실전 체크리스트와 검증 가이드

이 글이 도움이 되셨다면 공감(♥)과 댓글로 응원해 주세요!
궁금한 점이나 다루었으면 하는 주제가 있다면 댓글로 남겨주세요.