좋은 프로젝트 브리프에는 누가 도움이 필요한지, 그 사람들이 무엇을 해야 하는지, 그리고 성공한 결과가 어떤 모습인지가 담겨 있습니다. 명확한 문단 몇 개와 대략적인 스케치, 구체적인 예시 하나면 시작하기에 충분합니다.
저는 이 내용을 바탕으로 질문을 드리고, 범위와 일정을 제안하기 전에 작업을 함께 정리합니다. 이 가이드에서는 가상의 예약 서비스를 예로 들어 무엇을 적으면 되는지 설명합니다. 새 앱이든, 봇이든, 기존 제품의 기능이든 같은 질문이 적용됩니다.
문제와 사용자부터 적기
누가 제품을 사용할지, 그 사람이 무엇을 하려는지, 지금은 어떻게 하고 있는지 알려 주세요. 예약 예시라면 이렇습니다. “고객이 메시지로 원하는 시간을 문의합니다. 직원이 공유 캘린더를 확인하고 결제 링크를 보낸 뒤, 예약을 하나하나 직접 확정합니다.” 이것만으로 소프트웨어가 어떤 업무를 도와야 하는지 알 수 있습니다.
원하는 결과도 적어 주세요. 수작업 단계를 줄이는 것일 수도 있고, 제대로 작동하는 예약 흐름이나 고객이 주문 상태를 확인할 방법일 수도 있습니다. 지금 측정하고 있는 수치가 있다면 공유해 주세요. 없다면 성공한 모습을 말로 설명해 주시면 됩니다.
중요한 작업 하나를 처음부터 끝까지 따라가기
중요한 작업 하나를 골라 처음부터 끝까지 적어 주세요. 예를 들어 고객이 서비스를 고르고, 비어 있는 시간을 선택하고, 결제한 뒤 확인 안내를 받습니다. 그다음 관리자가 예약을 확인하거나 취소할 수 있습니다.
예외 상황도 함께 적어 주세요. 결제가 실패하거나, 고객이 마음을 바꾸거나, 두 사람이 같은 시간을 고르면 어떻게 될까요? 모든 경우를 직접 해결해 두실 필요는 없습니다. 질문으로 남겨 두기만 해도 일정을 확정하기 전에 필요한 작업을 찾아낼 수 있습니다.
첫 번째 릴리스에 필요한 것 정하기
쓸모 있는 첫 릴리스에 꼭 필요한 것과 나중에 해도 되는 것을 나눠 주세요. 예약 서비스라면 출시 때는 결제 수단 하나로 충분하고, 구독이나 추천 보상은 나중으로 미룰 수 있습니다. 우선순위를 알면 그 자체로 쓸모 있는 릴리스를 제안할 수 있습니다.
기능 이름 하나에 여러 결정이 숨어 있을 수 있습니다. 예를 들어 “고객 계정”이라면 누가 가입할 수 있는지, 무엇을 볼 수 있는지, 직원 권한은 다른지, 접근 권한을 잃으면 어떻게 되는지 알려 주세요. 정해지지 않았다면 함께 정할 질문으로 남겨 두셔도 됩니다.
기능이 완성됐는지 어떻게 확인할지도 적어 두세요. “예약 이메일 발송”만으로는 사람마다 기대하는 바가 다를 수 있습니다. “결제가 완료되면 고객에게 예약 번호, 날짜, 취소 방법이 담긴 이메일이 발송된다”처럼 적으면 확인 기준이 분명해집니다.
이런 확인 기준을 흔히 인수 조건이라고 부릅니다.GOV.UK의 사용자 스토리 가이드도 같은 방식을 설명합니다. 먼저 사용자의 필요를 적고, 그 필요가 충족됐음을 확인할 수 있는 결과를 나열하는 것입니다.
이미 있는 것 공유하기
현재 운영 중인 웹사이트나 앱, 그리고 이미 사용하는 사람이 있는지 여부.
디자인, 브랜드 자료, 콘텐츠, 마음에 드는 화면의 예시. 각 예시에서 어떤 점이 마음에 드는지도 함께 적어 주세요.
결제, 이메일, CRM, Telegram 봇처럼 제품과 연결해야 하는 서비스.
옮겨야 하는 기존 데이터와 관련 계정의 소유자.
지원해야 할 언어, 기기, 접근성 요구 사항, 이미 정해진 기술 등 전제 조건.
기존 제품을 개선하려는 경우라면 처음부터 알려 주세요. 기능 하나가 현재의 데이터, 권한, 업무 흐름의 변경으로 이어질 수 있습니다. 기존 시스템을 살펴보는 일도 범위를 파악하는 과정의 일부입니다.
마감일과 결정권자 알려 주기
출시일이 있다면 그 날짜가 왜 중요한지, 그때까지 무엇이 준비돼야 하는지 알려 주세요. 행사에 맞춘 날짜와 희망하는 목표일은 필요한 판단이 다릅니다. 예산 범위가 있다면 제안서를 만들기 전에 우선순위를 논의하는 데도 도움이 됩니다.
우선순위를 확정하고 작업을 승인할 수 있는 분을 정해 주세요. 아직 준비되지 않은 콘텐츠, 이전 개발자에게서 넘겨받아야 할 접근 권한, 연동을 맡은 다른 팀처럼 의존하는 사항도 알려 주세요. 이런 요소는 코드만큼이나 진행 계획에 영향을 줍니다.
좋은 첫 브리프의 예
저희는 예약제로 서비스를 운영합니다. 지금은 고객이 메시지로 예약하고, 직원이 직접 일정을 확인합니다.
첫 릴리스에서는 고객이 서비스와 비어 있는 시간을 고르고, 지금 쓰는 결제 서비스로 결제한 뒤 예약 확인을 받을 수 있어야 합니다. 직원은 예약을 확인하고 취소를 처리할 수 있어야 합니다.
웹사이트, 브랜드 자료, 결제 계정은 이미 있습니다. 구독 상품과 추천 보상은 나중에 추가해도 됩니다.
취소와 결제 실패를 어떻게 처리할지 결정하는 데 도움이 필요합니다. 희망하는 출시일은 있지만, 이런 질문이 정리된 뒤에 현실적인 일정을 함께 정하고 싶습니다.
이 예시에도 아직 정할 것이 남아 있습니다. 예약 가능 규칙, 환불, 직원 권한, 확인 안내에 들어갈 정보 등입니다. 그래도 괜찮습니다. 첫 브리프는 이런 결정이 필요한 지점을 찾아낼 만큼의 맥락을 주면 됩니다.
그대로 쓸 수 있는 브리프
만들거나 개선하고 싶은 것: …
사용하는 사람: …
지금 방식의 문제점: …
사용자가 완료해야 할 가장 중요한 작업: …
첫 릴리스에 필요한 것: …
나중으로 미룰 수 있는 기능: …
이미 있는 것(디자인과 연동 서비스 포함): …
마감일, 제약 조건, 예산 범위(알고 있다면): …
성공했다고 볼 기준: …
결정을 내리는 사람: …
아직 답을 모르는 항목은 비워 두셔도 됩니다. 정해지지 않은 질문이 눈에 보이게 해 두세요. 범위를 합의한 뒤 새로운 요청이 생기면, 추가하기 전에 작업과 일정에 미치는 영향을 먼저 논의합니다.
브리프는 여기에서 보내 주세요. 저는 글로 소통하기 때문에 발표 자료나 통화를 준비하실 필요가 없습니다. 작업을 합의하기 전에 질문과 다음 단계를 담아 답장드리겠습니다.