기획서 완성도가 아니라 ‘협업 언어’를 맞추는 것이 핵심
기능 설명보다 '왜 이걸 해야 하는가'
개발자와 디자이너와의 갈등은 대부분 기능 설명이 부족해서 생기지 않습니다.
오히려 왜 이 기능이 필요한지, 즉 기획의 목적과 맥락이 명확하게 공유되지 않을 때 갈등이 반복됩니다.
개발자는 기술적 리스크를 우선 고려하고, 디자이너는 사용자 경험의 일관성과 완성도를 우선 고려합니다.
반면 PM은 비즈니스 목표·사용자 행동·제품 전략을 동시에 봐야 합니다.
관점 자체가 다르다 보니, 같은 문장도 서로 다르게 읽게 됩니다.
예를 들어 PM이 “A 기능이 꼭 필요합니다”라고 말할 때
- 개발자는 “이걸 지금 스프린트 내에 만들 수 있을까?”를 고민하고
- 디자이너는 “이 기능이 UX 흐름을 망가뜨리지 않을까?”를 생각하고
- PM은 “전환율이 떨어지는 핵심 문제를 해결해야 한다”라고 생각하죠.
즉, 모두가 다른 문제를 보고 있는 겁니다.
그래서 협업의 첫 단계는 기능 설명이 아니라 “이 기능이 해결하려는 비즈니스 문제”를 분명히 말하는 것입니다.
예를 들면 이렇게 설명하면 좋겠죠.
- “이 기능은 단순 부가 기능이 아니라 첫 방문자의 이탈을 줄이기 위한 핵심 요소입니다.”
- “이번 분기 KPI 중 가장 비중이 큰 부분을 해결하기 위해 필요한 기능입니다.”
- “기능보다 중요한 건 이 문제를 풀었을 때 고객 행동이 어떻게 바뀌는가입니다.”
이렇게 목적이 선명하면, 개발자는 기술적 제약 안에서 가능한 대안을 찾고 디자이너는 UX 기준을 보존하면서 타협점을 고민하게 됩니다.
기획이 흔들리는 이유는 PM이 기능을 그대로 전달하기 때문이 아니라,
기능이 해결하려는 문제를 먼저 설명하지 않기 때문입니다.
협업의 첫 번째 언어는 기능이 아니라 목적입니다.
개발자 · 디자이너 간 협업이 잘 되는 팀은 뭐가 다른가
문제가 아니라 “조건”을 먼저 맞춘다
협업이 어려운 팀은 대부분 같은 특징이 있습니다.
회의는 길고, 논의는 반복되고, 결론은 매번 뒤집히며, 마지막에 가서 “안 된다”는 말이 나옵니다.
반대로 협업이 잘되는 팀은 기획서가 특별히 화려하지 않아도
갈등 없이 빠르게 방향을 맞추고 일을 진행합니다.
이 차이를 만드는 건 조건 정리의 힘입니다.
협업이 무너지는 팀은 대체로 이렇게 말합니다.
- “이 기능은 이렇게 만들겠어요.”
- “이렇게 하면 되잖아요?”
- “이 디자인이 더 나아 보이는데요?”
반면 협업이 잘되는 팀은 항상 조건부터 선명하게 공유합니다.
- “이 기능은 전환율 5% 개선이 목표입니다.”
- “이번 스프린트는 7일이라 구현 범위가 제한됩니다.”
- “전체 UX 흐름은 지난 기획과 일관성이 필요합니다.”
PM의 역할은 해결책을 강요하는 사람이 아니라
조건을 정리해 논의를 효율적으로 만드는 사람입니다.
조건이 정리되면 협업 과정이 이렇게 달라집니다.
- 개발자
“기술적으로 어려운 이유”를 추상적으로 말하지 않고
“그 조건 안에서는 이 방식이 구현 범위에 맞습니다”라고 말함. - 디자이너
PM의 취향이나 개인적 선호를 맞추는 게 아니라
“이 조건에서 사용자 경험을 살리려면 이런 방향이 적절합니다”라고 말함. - PM
이제 더 이상 요청을 조율하는 사람이 아니라
비즈니스·UX·기술의 균형을 맞추는 ‘판단자’가 됨.
조건을 먼저 맞추지 않은 상태에서 기능 논의를 시작하면
대화는 끝없이 흩어지고, 결정은 계속 밀리며, 협업 관계는 금방 소모됩니다.
결국 협업의 핵심은
“무엇을 만들까”가 아니라
“어떤 조건에서 만들까”를 먼저 맞추는 것입니다.
PRD(요구사항 문서)는 문서가 아니라 “관점 통일 도구”
완벽한 문서를 쓰려하지 말고 ‘같은 그림’을 보게 하세요
PRD는 많은 PM들이 부담스러워하는 문서입니다.
하지만 PRD의 목적은 상세한 기획을 쓰는 것이 아니라, 개발자·디자이너·기획자 모두가 같은 그림을 보도록 만드는 것입니다.
좋은 PRD는 다음 세 가지가 명확합니다.
① 무엇을 해결하려는가
기능 요청이 아니라 해결해야 하는 문제를 써야 합니다.
“장바구니 UX 개선”이 아니라 “재방문 고객의 구매 전환율이 낮은 문제 해결”처럼
문제를 먼저 규정해야 합니다.
문제가 선명하면 기능의 범위도 불필요하게 커지지 않습니다.
② 누구를 위한 기능인가
페르소나·사용자 시나리오를 적는 이유는 팀 전체가 “같은 사람”을 떠올리게 하기 위한 것입니다.
사용자가 처한 상황이 공유돼야 디자인도 기술도 동일한 방향으로 기울어집니다.
③ 흐름이 보이는가
텍스트로 기능을 가득 적는 PRD는 실제로 협업하는 순간 효력이 약합니다.
팀이 가장 빠르게 이해하는 것은 흐름입니다.
그래서
- 유저 플로우
- 화면 이동 구조
- 분기 조건
이 세 가지를 시각적으로 표현하는 게 훨씬 효과적입니다.
특히 분기 조건(로그인 실패, 재고 없음, 결제 오류 등)은 협업 오류를 줄이는 데 매우 큰 역할을 합니다.
분기가 명확해야 개발자는 로직을, 디자이너는 화면을 누락 없이 설계할 수 있습니다.
PRD는 화려한 문서가 아니라 협업 혼란을 줄이는 설계 과정입니다.
문서가 아니라 “관점 통일 도구”라고 생각해야 합니다.
정리
- 기능보다 먼저 설명해야 하는 건 “왜 지금 이 문제를 해결해야 하는가”입니다.
- 협업이 흔들리는 팀은 문제를 논의하고, 협업이 잘되는 팀은 조건을 먼저 맞춥니다.
- 개발자와 디자이너는 의견을 거절하는 게 아니라 제약과 기준을 말하고 있는 것입니다.
- PRD는 문서가 아니라 팀을 한 방향으로 정렬시키는 도구입니다.
- PM의 핵심 역할은 기능을 지시하는 것이 아니라 혼란 속에서 논리적 기준을 만드는 것입니다.