개발자를 일하게 하는 기획서는 무엇이 다를까?
'기능'이 아닌 '이유'를 설계하는 법
압사 후 처음으로 기획서를 작성할 때, 저는 '완벽한 기획서'에 대한 강박이 있었습니다. 개발자가 한 번도 질문하지 않고 코딩만 할 수 있는 문서가 최고의 기획서라고 믿었기 때문입니다. 그래서 버튼의 픽셀 위치, 폰트 크기, 예외 처리 로직 하나하나까지 깨알같이 적어 내려갔습니다. 개발자 동료들은 제가 적어준 대로 기능은 구현해 주었지만, 딱 거기까지였습니다. 예상치 못한 기술적 이슈가 발생하면 그들은 작업을 멈추고 저를 바라보며 물었습니다. "기획서에 이 내용은 없는데요? 어떻게 할까요?"
그때 깨달았습니다. 제가 쓴 상세한 명세(Spec)가 오히려 동료들을 수동적인 '작업자'로 만들고 있었다는 사실을 말입니다. 이 경험은 제 커뮤니케이션 방식을 송두리째 바꾸는 계기가 되었습니다.
PM은 '왜(Why)'를 이야기해야 한다
먼저, 기획서의 화법을 바꿨습니다. "로그인 버튼을 빨간색으로 만들고 상단에 배치해 주세요"라고 해결책(How)을 지시하는 대신, 우리가 겪고 있는 문제와 목표(Why)를 설명하는 데 페이지의 절반을 차지하기 시작했습니다. "현재 로그인 페이지의 전환율이 지난달 대비 10% 떨어졌습니다. 데이터 로그를 보니 유저들이 로그인 버튼을 찾지 못해 헤매는 시간이 평균 3초나 됩니다. 이들의 시선을 바로 사로잡을 방법이 필요합니다."
개발자들은 단순히 버튼 색깔을 바꾸는 것을 넘어 더 근본적인 해결책을 제안해오기 시작했습니다. "단순히 색깔만 바꾼다고 될 게 아니라, 로딩 속도가 느려서 버튼이 늦게 뜨는 게 문제인 것 같아요. 렌더링 방식을 바꿔보는 건 어떨까요?" 혹은 "차라리 생체 인증을 먼저 띄우는 게 낫지 않을까요?"
제가 미처 생각하지 못했던, 개발자의 관점에서 더 효율적이고 창의적인 솔루션들이 쏟아져 나왔습니다. 저는 그제야 제가 해야 할 일은 '기능을 정의하는 것'이 아니라, '문제를 정의하는 것'임을 알게 되었습니다.
빈틈이 있는 기획서가 좋은 기획서다
흔히 꼼꼼함이 PM의 최고 덕목이라고 하지만, 때로는 의도된 '빈틈'이 팀의 역동성을 만들어냅니다. 가상자산 거래소와 같이 트래픽이 몰리고 구조가 복잡한 환경에서 PM 혼자 모든 기술적 변수를 고려하여 완벽한 답을 내리기란 불가능합니다. 오히려 PM이 솔루션을 꽉 닫아두지 않고 열어두었을 때, 메이커(Maker)들은 그 빈 공간을 자신의 전문성으로 채우려는 욕구를 가집니다.
개발자는 단순히 코드를 짜는 기계가 아닙니다. 그들 역시 자신의 코드로 사용자에게 가치를 전달하고 싶어 하는 크리에이터입니다. PM이 그들에게 "이 기능을 만들어"라고 명령하면 그들은 '일'을 하지만, "이 문제를 해결해 줘"라고 부탁하면 그들은 '도전'을 합니다.
정답을 주는 사람이 아니라, 방향을 가리키는 사람
지금도 저는 기획서를 쓸 때 다짐을 합니다. "나는 지금 동료들에게 '할 일'을 주고 있는가, 아니면 '목표'를 주고 있는가?" 최고의 프로덕트는 천재 PM 한 명의 머리에서 나오는 것이 아니라, 문제의 본질을 이해한 팀원들의 집단지성 속에서 탄생한다고 믿습니다.
그래서 저는 오늘도 빽빽한 기능 정의 대신, 우리가 왜 이 험난한 여정을 떠나야 하는지 그 '이유'를 설득하는 데 온 힘을 쏟습니다. 개발자를 춤추게 하는 것은 화려한 기획서가 아니라, 명확한 'Why'이기 때문입니다.
