개발자에게 코딩 대신 'Why'를 팔자
PM의 핵심 업무는 '소통'입니다. 하지만 종종 "기획 의도와 다르게 개발됐어요" 또는 "이건 기술적으로 불가능합니다"라는 답변을 듣고 당황할 때가 있습니다. 개발자와 디자이너는 우리의 가장 가까운 동료이지만, 사용하는 언어와 집중하는 영역이 다르기 때문에 발생하는 당연한 일입니다. 오늘은 제가 일하면서 느낀 기능 개발 착수 전 팀원들을 설득시키는 명세서 작성 및 소통의 3가지를 이야기해 보겠습니다.
1. '왜'와 '무엇'을 먼저 팔아라: 목적 중심의 문서 설계
가장 흔한 실수는 PRD(제품 요구사항 정의서)나 기획서의 첫 페이지부터 '버튼 위치'나 'API 스펙'을 나열하는 것입니다. 개발자와 디자이너는 단순히 시키는 일을 하는 사람이 아니라, 문제를 함께 해결하는 전문가입니다. 따라서 문서의 초반에는 'Why(왜 이 기능을 만드는가?)'와 'What(이 기능으로 달성할 핵심 목표는 무엇인가?)'을 명확히 제시해야 합니다.
예를 들어, "이 버튼을 주황색으로 만들어주세요" 대신, "사용자들의 결제 이탈률 15% 감소를 위해, 시인성을 높이는 것이 목표입니다"라고 설명해야 합니다. 이처럼 명확한 목표를 공유할 때, 개발자는 "주황색 외에 더 좋은 코딩 기법이 없을까?"를 고민하게 되고, 디자이너는 "주황색 외에 더 좋은 심리적 유도 장치가 없을까?"를 고민하게 되면서 능동적인 파트너로 참여하게 됩니다.
2. '추상적인 언어'를 '객관적인 언어'로 번역하라
PM의 언어는 종종 '사용자 경험'이나 '감성'에 치우쳐 있어 기술팀에게는 모호하게 들립니다. 개발팀이 기능을 구현할 수 있도록, 추상적인 요구사항을 '코드 레벨에서 작동 가능한 구체적인 기준'으로 번역해야 합니다. 디자이너와의 소통에서는 "예쁘게 해주세요" 대신 '이 버튼을 클릭했을 때 로딩 속도는 2초 이내여야 하고, 애니메이션은 0.3초의 딜레이를 가져야 합니다.'와 같이 구체적인 수치를 제시해야 합니다.
개발자와의 소통에서는 '사용자에게 알림을 보내주세요' 대신, '사용자가 로그인 후 24시간 동안 특정 기능을 사용하지 않았을 경우, 백엔드에서 푸시 알림 API [Notification_API_V2]를 호출하여 알림을 발송해야 합니다.'와 같이 데이터 흐름과 호출 시점을 명확히 정의해야 합니다. 특히 예외 상황(Error Case)을 꼼꼼하게 정리하는 것이 중요합니다. 네트워크 연결이 끊기거나, 서버 응답이 느릴 때 사용자에게 어떤 에러 메시지를 보여주고 앱이 어떻게 동작을 멈춰야 하는지 등 모든 시나리오를 빠짐없이 명시해야 개발 후반부에 발생하는 '숨겨진 버그'를 미리 방지할 수 있습니다.
3. '문서'가 아닌 '툴'로 소통하는 워크플로우를 구축하라
문서 전달을 완료했다고 PM의 역할이 끝나는 것이 아닙니다. 개발자와 디자이너는 그들의 주력 툴에서 가장 효율적으로 작업합니다. 따라서 PM은 이들의 워크플로우에 맞춰 문서를 유기적으로 연결해야 합니다. 디자이너와의 연결은 디자이너가 Figma에서 화면을 만들면, PM은 PRD의 기능 ID(예: F03)를 해당 디자인 화면에 주석으로 남기는 방식입니다. 이렇게 하면 디자이너는 자신이 만든 화면이 전체 프로젝트에서 어떤 목적을 가지고 있는지 즉시 확인할 수 있습니다.
개발자와의 연결은 개발팀이 JIRA나 GitHub에서 작업을 시작할 때, PM은 PRD의 사용자 스토리를 JIRA의 티켓으로 변환하여 등록하는 것입니다. 개발자는 작업 중 궁금한 점이 생겼을 때 별도의 메신저 문의 없이 티켓에 링크된 PRD 원본을 통해 답을 얻을 수 있습니다. 이처럼 PM이 '문서' 자체보다 '문서가 팀원들의 작업 툴에서 어떻게 활용될지'를 설계한다면, 불필요한 소통을 줄이고 프로젝트의 속도를 극대화할 수 있습니다.
PM은 단순한 기획자가 아니라, 복잡한 팀을 효율적으로 이끄는 '소통 아키텍트'입니다. 이 세 가지 원칙을 통해 팀원들의 신뢰를 얻고, 성공적인 제품 출시를 이끌어보시길 바랍니다.
