실제로 쓰이는 한 페이지 제품 브리프 작성법

FabricLoop 팀  ·  2026년 5월  ·  읽는 시간 4분

대부분의 제품 브리프는 같은 운명을 맞습니다. 프로젝트 시작 전에 공들여 작성되고, 킥오프 회의에서 한 번 검토된 뒤, 다시는 열어 보지 않는 것입니다. 팀이 개발 한창일 때쯤 브리프는 역사적 유물이 됩니다. 범위를 두고 다툴 때 가끔 인용될 뿐, 의사결정을 이끄는 살아 있는 가이드로 쓰이는 일은 드뭅니다.

이것은 형식의 문제가 아니라 프로세스의 문제입니다. 브리프가 쓰이지 않는 이유는 쓰이도록 작성되지 않았기 때문입니다. '요구사항을 정의했다'는 칸에 체크하기 위해, 즉 절차를 충족하기 위해 쓰였을 뿐, 불확실한 상황에서 팀이 더 나은 결정을 내리도록 돕기 위해 쓰인 것이 아닙니다.

실제로 쓰이는 브리프는 짧고, 분명한 관점이 있으며, 개발 중에 팀이 실제로 던질 질문을 중심으로 구성됩니다. 우리는 무엇을 해결하는가, 누구를 위한 것인가, 그리고 성공했는지 어떻게 알 수 있는가입니다.

중요한 다섯 가지 섹션

제품 브리프의 모든 내용은 다섯 가지 질문 중 하나에 답해야 합니다. 어떤 섹션이 이 질문 중 어느 것에도 답하지 못한다면, 한 페이지짜리 브리프에는 어울리지 않을 가능성이 높으며 별도의 더 자세한 명세서에 들어가야 합니다.

'범위 외'가 가장 중요한 섹션인 이유

팀은 무엇을 만들지 쓰는 데는 많은 시간을 쓰지만, 무엇을 만들지 않을지 쓰는 데는 거의 시간을 쓰지 않습니다. 이 불균형이 스코프 크리프의 대부분을 만듭니다. 디자이너가 당연해 보여서 '방해 금지 시간' 토글을 넣거나, 엔지니어가 이미 해당 영역을 작업 중이라 워크스페이스별 설정을 추가한다면, 대개 그것이 범위 외라고 아무도 명시적으로 정하지 않았기 때문입니다.

범위 외 항목을 적으면 개발 중에 터졌을 경계에 관한 논의를 미리 하게 됩니다. 그때는 방향을 바꾸는 비용이 훨씬 큽니다. 또한 PM이 추가 요청을 거절할 때 명확하고 문서화된 근거를 갖게 됩니다. “그건 브리프에서 범위 외로 정했고, 이유는 이렇습니다.”

미해결 질문: 대부분의 브리프가 빠뜨리는 섹션

모든 프로젝트는 해결되지 않은 질문과 함께 시작됩니다. 대부분의 브리프는 마치 모든 결정이 끝난 것처럼 쓰여 있습니다. 작성자는 그렇지 않다는 것을 알면서도 말이죠. 그 결과 팀은 개발 도중, 가장 큰 혼란을 일으키는 시점에 미해결 질문을 발견합니다.

미해결 질문을 명시적으로 적으면 두 가지 효과가 있습니다. 첫째, 작업 시작 전에 해결해야 하는 질문(진행 차단)과 개발 중에 결정해도 되는 질문(진행 가능)이 구분되어 드러납니다. 둘째, 이 브리프가 완성된 명세서가 아니라 작업 중인 문서라는 신호를 팀에 줍니다. 그래서 팀이 결정이 내려질 때마다 브리프로 돌아와 업데이트할 가능성이 높아집니다.