프로젝트 매니저(PM)를 위한 기술 이해도: 개발자와 원활하게 소통하는 법

"이 기능 추가하는 데 왜 이렇게 오래 걸리나요?" PM과 개발자 사이의 갈등은 대개 '기술적 맥락'의 차이에서 발생합니다. PM이 코딩을 직접 할 필요는 없지만, 소프트웨어가 어떻게 만들어지는지에 대한 최소한의 이해가 있다면 팀의 생산성은 폭발적으로 향상됩니다.

개발자와 신뢰를 쌓고, 불가능한 일정을 가능한 일정으로 바꾸는 전략적인 소통법을 PM의 언어로 정리해 드립니다.

기술 부채와 리팩토링의 필요성 공감하기

눈에 보이는 기능을 만드는 것만이 개발의 전부는 아닙니다. 코드가 엉망인 상태에서 기능만 추가하면 나중에는 사소한 수정조차 불가능한 상태가 되는데, 이를 '기술 부채'라고 합니다. 개발자가 "리팩토링이 필요하다"고 말할 때, 그것을 단순히 '청소 시간'으로 치부하지 마세요.

기술 부채를 방치하면 결국 서비스 전체의 속도가 느려지고 장애 발생 확률이 높아집니다. PM은 비즈니스 우선순위와 기술 부채 해결 사이의 균형을 잡아주는 조정자 역할을 해야 합니다. 개발자가 왜 이 작업이 필요한지 설명할 때, 그로 인해 얻게 될 미래의 생산성 향상을 지표로 대화해 보세요.

개발 프로세스와 API 명세의 이해

프론트엔드와 백엔드가 어떻게 데이터를 주고받는지(API), 그리고 왜 데이터베이스 구조를 한 번 정하면 바꾸기 어려운지 이해하면 요구사항 변경 시 발생하는 리스크를 미리 예측할 수 있습니다. 기획 단계에서부터 개발자와 함께 '데이터의 흐름'을 논의하세요.

기획서에 "이 버튼을 누르면 이 값이 바뀝니다"라고만 적지 말고, "A API를 호출해서 B 데이터를 업데이트한다"는 수준의 논의가 가능해진다면 커뮤니케이션의 오해는 획기적으로 줄어듭니다. 개발자는 자신의 언어를 이해하려 노력하는 PM에게 훨씬 더 협력적으로 변합니다.

예외 상황(Edge Case)을 고려한 기획

개발자가 가장 힘들어하는 기획은 '행복 회로'만 가득한 기획입니다. 네트워크가 끊겼을 때, 사용자가 이상한 값을 입력했을 때, 서버에 과부하가 걸렸을 때 어떻게 작동해야 하는지(Exception Handling)를 기획 단계에서부터 고민해 보세요.

이런 예외 상황을 미리 정의해 주는 PM은 개발자의 업무 범위를 명확히 해주고 삽질을 줄여줍니다. "이런 상황에선 어떻게 동작하는 게 좋을까요?"라고 먼저 질문을 던지는 PM은 개발팀이 가장 사랑하는 파트너가 될 것입니다.