내 기획서가 개발자에게 '암호문'인 이유
PM이 반드시 경계해야 할 '지식의 저주'
기획자라면 누구나 한 번쯤 이런 경험이 있을 겁니다. 밤을 새워 꼼꼼하게 기획서(PRD)를 작성해서 넘겼는데, 며칠 뒤 개발자가 가져온 결과물은 내 생각과 딴판입니다. "아니, 여기 기획서 5페이지 셋째 줄에 '자연스럽게 전환된다'고 썼잖아요!" "PM님, '자연스럽게'가 0.3초 페이드 아웃인가요? 아니면 슬라이드 인터랙션인가요? 그리고 데이터 로딩 중에는 뭘 보여주죠?"
나는 분명히 한글로 썼는데, 상대방은 암호문을 받은 표정입니다. 왜 이런 일이 반복될까요? 개발자의 이해력이 부족해서일까요? 아닙니다. 범인은 바로 '지식의 저주' 때문입니다. 오늘은 기획서의 빈틈을 메우고, 개발자와의 소통 비용을 획기적으로 줄이는 '친절한 기획의 기술'에 대해 이야기해 보겠습니다.
1. 지식의 저주: "내가 알면 남도 알겠지"라는 착각
스탠퍼드 대학의 한 심리학 실험에서 참가자들에게 '학교 종이 땡땡땡' 같은 유명한 노래의 박자를 손가락으로 두드리게 했습니다. 두드리는 사람은 상대방이 50% 정도는 맞힐 거라고 예상했지만, 실제 정답률은 2.5%에 불과했습니다.
두드리는 사람(PM)의 머릿속에는 멜로디가 생생하게 들리지만, 듣는 사람(개발자)에게는 그저 의미 없는 '탁, 탁, 탁' 소리로만 들리기 때문입니다. PM은 기획 단계에서 수주 간 고민하며 맥락을 완벽히 파악하고 있습니다. 하지만 개발자는 오늘 처음 그 문서를 봅니다. '내 머릿속에 있는 배경지식'을 기획서에 생략하는 순간, 그 문서는 암호문이 됩니다.
2. 기획서에서 흔히 저지르는 '지식의 저주' 유형 3가지
몇 가지 예시를 통해 PM들이 기획서에 저지르는 '지식의 저주' 유형 3가지를 한번 보려고 합니다.
① "그냥 아시죠?" (맥락의 생략)
Bad: "회원가입 완료 후 홈으로 이동."
Dev의 의문: "비회원이 가입했을 때랑, 탈퇴한 회원이 재가입했을 때랑 똑같이 홈으로 가나요? 토큰 처리는요?"
Good: "신규 회원가입 완료 시, 서버에서 발급받은 액세스 토큰을 저장 후 메인 홈 화면으로 이동한다."
② "적당히 예쁘게" (형용사의 남발)
Bad: "사용자가 놀라지 않게 부드러운 경고창을 띄운다."
Dev의 의문: "'부드러운'이 뭐지? 핑크색인가? 모서리가 둥근 건가?"
Good: "시스템 기본 Alert 창 대신, Custom Modal(디자인 가이드 #3-2 참조)을 사용하며 딤(Dim) 처리는 40% 불투명도로 적용한다."
③ "당연히 되어야죠" (투명 인간 취급)
Bad: (아무런 언급 없음)
Dev의 의문: "데이터 불러오는데 3초 걸리면 흰 화면만 보여주나요? 에러 나면 앱 꺼지나요?"
Good: (기획서 하단에) Exception Case: 네트워크 지연 시 스켈레톤 UI 노출, 로딩 실패 시 '재시도 버튼' 노출.
3. 지식의 저주를 깨부수는 PM의 습관: '초등학생에게 설명하듯(ELI5)'
이 저주를 풀기 위한 유일한 방법은 "상대방은 아무것도 모른다"고 가정하는 것입니다. 먼저 'Why'를 적으세요. 기능 명세(Spec)로 바로 들어가지 말고, "사용자가 왜 이 기능을 써야 하는지(User Story)"를 기획서 최상단에 적으세요. 맥락을 알면 개발자가 스스로 빈틈을 채울 수 있습니다.
그리고 글보다는 그림(Wireframe)이 좋습니다. "버튼이 우측 하단에 위치한다"라는 글보다, 발로 그린 그림 한 장이 훨씬 강력합니다. 텍스트는 오해를 낳지만, 시각 자료는 오해를 차단합니다. 마지막으로, 동료 PM에게 리뷰를 받아보세요. 도메인 지식이 없는 옆 팀 동료에게 기획서를 보여주세요. 그들이 "이게 무슨 말이야?"라고 묻는다면, 개발자도 똑같이 물어볼 것입니다.
