[PM온보딩] 프로젝트 분석 : 기능정의서와 PRD 1
Chapter 5
기능정의서 작성법
마인드맵 기반으로 접근을 해볼까요?
기능정의서는 기획자가 의도한 ‘기능의 목적’을 각 팀원이 이해할 수 있도록 작성하여 디자인 → 개발 → QA → 출시까지의 과정에서 기준이 되는 문서입니다.
한마디로 “이 기능이 왜 필요한지, 어떤 화면에서 어떤 동작을 하며, 어떤 데이터를 주고받는지”를 설명해 주는 설계의 중심이 됩니다.
하지만 모든 프로젝트가 동일하지 않기에 매번 작성할 때마다 어렵게 느껴지기도 하는데요. 어떤 항목부터 어떻게 채워야 할지 막막할 수 있습니다. 그래서 순차적으로 채워나가는 마인드맵 방식으로 접근하여 설명을 해보려고 합니다.
기능정의서 항목은 아래와 같이 구성해 볼 수 있습니다.
1. 기능의 목적
이 기능은 왜 필요한가요?
어떤 문제를 해결하기 위한 것인가요?
예: 사용자가 앱을 처음 실행했을 때, 로딩 중이라는 것을 보여주기 위해 Splash 화면을 띄운다.
2. 사용자 시나리오
사용자는 어떤 흐름으로 이 기능을 경험하나요?
이 기능은 어떤 화면에서, 어떤 액션을 유도하나요?
예: 사용자가 "내 물건 팔기" 버튼을 클릭 → 제목, 가격을 입력 → "등록" 버튼 클릭 → 상품이 등록된다.
3. 수집 정보
사용자로부터 어떤 입력을 받아야 하나요?
개인정보나 기타 데이터가 포함되나요?
예: 카카오 로그인 시 이메일, 닉네임
4. 디자인 요소
디자이너에게 어떤 UI 요소가 필요하다고 전달해야 할까요?
버튼, 인풋 필드, 카드, 아이콘 등
예: "채팅하기" 버튼, 100자 제한 인풋창
5. 유효성 처리
입력값이 유효한지 어떻게 판단하나요?
빈값, 숫자 제한, 문자수 제한 등
예: 제목은 30자 이내 / 가격은 0원 이상 1억 이하
6. 예외 조건
특정 조건에서 이 기능은 어떻게 다르게 작동하나요?
일반적인 플로우를 벗어나는 경우를 정의해 주세요.
예: 본인이 올린 게시글에는 "수정하기" 버튼이, 타인이면 "채팅하기" 버튼이 노출된다.
7. 에러 처리
API 요청 실패, 로딩 실패 등의 경우 어떻게 대응해야 하나요?
사용자에게 어떤 메시지를 보여줘야 하나요?
예: 네트워크 오류 시 “채팅방 연결에 실패했습니다. 다시 시도해 주세요.” 토스트 메시지
8. 백엔드 처리
서버에서 어떤 작업이 필요한가요?
API 호출 방식, DB 저장 방식, 인증/인가 절차 등
예: 사용자 입력 데이터를 DB에 저장
9. 프론트엔드 처리
클라이언트(앱/웹)에서는 어떤 식으로 처리하나요?
API 응답 데이터 처리, 상태 업데이트 등
예: 상품 등록 후, 상품 목록 페이지로 리다이렉트
10. 참고사항
해당 기능에 대해 참고할 수 있는 문서, 유의사항, 향후 고려사항 등을 적습니다.
예: 향후 검색 기능을 고려해 제목/카테고리 저장 방식 결정 필요
처음부터 한 번에 완전하게 채우려고 하기보다는 기능의 목적과 흐름을 생각해 보고 순차적으로 채워나가는 과정이 중요합니다.
기능의 목적을 먼저 정의해 보고, 사용자가 실제로 어떤 경로를 거쳐 해당 기능을 이용하게 될지 시나리오를 말로 풀어보는 것부터 시작해 보세요.
아래는 당근마켓의 실제 앱 화면을 예로 작성해 본 기능정의서 초안입니다.
먼저 채워본 항목은 1. ‘기능의 목적’과 2. ‘사용자 시나리오’입니다.
기능의 목적 → 사용자 시나리오를 통해 기능의 목적과 사용자가 어떤 액션을 하면 어떤 화면으로 이동하는지 작성해 보았습니다.
디자이너는 버튼 노출 조건, 화면 진입 위치 등을 파악할 수 있으며 개발자는 시나리오 순서대로 플로우 구성을 해볼 수 있을 거예요.
여기에
로그인 항목에 로그인 실패 또는 토큰 만료 시 흐름을 부가 설명을 작성해 보거나
썸네일/이미지 항목에 이미지 포맷, 업로드 개수 제한 등을 디자인 요소와 연결하거나
채팅하기 버튼의 시나리오에 ‘본인 게시글일 경우 수정하기 버튼으로 대체됨’을 미리 명시해도 좋아요.
다음으로 채워본 항목은 3. ‘수집 정보', 4. '디자인 요소', 5. '유효성 처리', 6. '예외 조건', 7. '에러 처리'입니다.
잊지 말아야 하는 단계는 팀 리뷰입니다. 내가 작성한 기능정의서 리뷰를 통해 정보가 충분한지, 모호한 표현은 없는지, 빠진 케이스는 없을지 팀원분들과 함께 점진적으로 채워나가는 것이 제일 제일 중요합니다. (여러 번 채우고 메워도 결국 발견되는 이슈는 생길 수 있어요. 유연한 마음가짐을 가져야 해요.)
다음으로 채워본 항목은 8. '백엔드 처리', 9. '프론트엔드 처리', 10. '참고 사항'입니다.
백엔드 처리와 프론트엔드 처리 항목은 저도 작성하면서 참 어려웠습니다. 시트를 따로 구분하여 작성하는 게 좋으려나, 얼마나 더 자세하게 써야 하지 그런 고민들이 들었는데요.
오늘 주제처럼 마인드맵을 통해 순차적으로 채워나가는 것이 목표이니, 위와 같이 생각을 넓혀 나갈 수 있음을 보여드리고 싶어서 간략하게나마 작성을 했습니다.
내 생각으로 먼저 작성해 보고 더 기술자이자 전문가인 개발자분들에게 조언을 구하며 채워나가자는 마인드로, 시도해보고 깨져보기도 하면서 단단해지는 과정을 겪는 것을 추천드려요.
흔한 고민들
“기획자인 내가 어디까지 기술적으로 써야 하지?”
“시트를 구분 짓는 게 나을까? 하나의 표에 다 넣을 수 있을까?”
“API 명세도 아닌데 너무 디테일한가?”
“내가 맞게 쓰고 있는 건지 확신이 없다..”
기획자는 개발자의 언어를 완벽히 알지 못하기에, 가설을 세워보고 검증하는 자세가 중요합니다.
"API가 필요하겠지", "이건 DB에 저장되겠지"라는 식의 예상을 먼저 써보고 팀 리뷰를 통해 피드백을 받고 빌드업하는 것이 중요합니다.
초기 작성은 하나의 표 안에서 흐름을 볼 수 있도록 정리하고, 프로젝트가 커지면 백엔드/프론트 별 시트로 분리해서 상세 내용 및 버전 관리를 해나가는 것을 추천합니다.
오늘은 마인드맵처럼 생각을 확장하며 기능정의서를 써보는 것에 대하여 설명을 해보았습니다.
특히 기획 시간이 짧고 일정이 타이트한 에이전시의 경우, 기능정의서를 촘촘히 고민하고 채워나가기란 란 쉽지 않을 수 있습니다.
하지만 기능정의서가 부재한 상태에서 프로젝트가 진행된다면, 서로 다른 기준, 다른 상상을 기반으로 디자인과 개발이 엇갈릴 수도 있습니다. 그 결과는 대부분 일정 지연, 커뮤니케이션 오류, 품질 저하로 이어지게 됩니다.
기능의 목적은 무엇일까?
사용자는 어떤 흐름으로 이 기능을 경험하지?
필요한 정보는 무엇이고, 어떤 UI가 있어야 할까?
입력값은 어떻게 제한을 두고, 어떤 예외 상황이 발생할 수 있을까?
에러 발생 시 어떻게 안내하는 게 좋을까?
서버는 어떤 데이터를 주고받고 저장해야 할까?
프론트엔드는 어떤 값을 요청하고 화면에 보여줘야 할까?
질문을 이어가다 보면, 자연스럽게 기능정의서의 항목들을 채워나갈 수 있을 거예요.
먼저 초안을 써보고, 팀원들의 피드백을 받아 점점 더 단단한 정의서로 다듬어보세요.
다음 챕터에서는 이어서 PRD (Product Requirement Document) 요구사항 정의서에 대하여 작성해 보겠습니다.
