목표
✅ 아티클카타
2 순위
✅ 대면 피드백1 순위🌟 목표 달성률 : 100%
아티클카타
⚠️ 모든 아티클은 주관적, 그대로 받아들이기 보단 비판적으로 읽어야 함.
1. 아티클 정보
제목 : 앱 기획서 작성법, PM이 실제로 쓰는 5개 문서로 정리합니다
작성자(저자) : MobilePartners
❓아티클 선정 이유 : 기획서 쓰는 게 아직 부족한 거 같아서 선정
2. 핵심 내용 요약
와이어프레임만 그리는 건 기획의 일부일 뿐. 기획서는 5개 문서를 순서대로 작성해야 한다.
| # | 문서 | 역할 |
|---|---|---|
| 1 | 프로젝트 개요서 | 왜 만드는지, 누구를 위한지 — 팀 정렬의 기준 |
| 2 | 정보구조도 (IA) | 화면 계층을 트리로 정리 — 누락 기능 조기 발견 |
| 3 | 기능정의서 | 기능을 세부 동작 단위로 분해 — 견적·일정의 근거 |
| 4 | 와이어프레임 | 레이아웃 스케치 — "어디에 무엇이 있는가"만 표현 |
| 5 | 화면설계서 (스토리보드) | 와이어프레임에 디스크립션 추가 — 개발자 실행 기준 |
⚠️ 순서가 중요한 이유: 위에서 아래로 갈수록 디테일이 쌓이는 구조. 거꾸로 가면 나중에 처음부터 다시 해야 함.
✅ 각 문서 핵심 포인트
1. 프로젝트 개요서
A4 한 장으로 충분. 필수 4항목: 기획 배경 / 타겟 페르소나 / 핵심 가치 제안 / KPI
2. IA (정보구조도)
메뉴 트리를 그리다 보면 "주문 취소는 어디서?" 같은 빈틈이 보임. 툴보다 팀이 한눈에 파악하는 게 핵심.
3. 기능정의서
"회원가입"이 아니라 이메일 가입 / 휴대폰 인증 / 소셜 로그인 / 탈퇴 정책으로 쪼개야 함. 이 문서가 견적 산정의 유일한 근거.
4-5. 와이어프레임 + 화면설계서
화면설계서에서 예외 처리 필수 — 비로그인 상태, 네트워크 오류, Empty State 등을 빠뜨리면 개발 후반에 터짐.
기획자가 자주 빠뜨리는 5가지
- 회원 탈퇴 후 데이터 처리 정책 (유예 기간, 재가입 제한)
- 푸시 알림 거부 시 동작
- 결제 실패 / 환불 시나리오
- 비로그인 상태에서의 화면 동작 범위
- 데이터 없음 / 네트워크 오류 화면 (Empty/Error State)
개발 방법론 요약
- 워터폴 — 요구사항 고정된 B2B·공공 프로젝트
- 애자일 (스크럼) — 피드백 반영이 중요한 B2C 서비스
- 린 (MVP) — 검증 안 된 아이디어, 초기 스타트업
👉 처음 앱 만든다면 린으로 MVP 검증 → 애자일로 확장 추천
3. 인사이트
"기획 1~2주를 아끼면 개발에서 4주 까먹는다"
기획서는 화려함보다 팀이 같은 그림을 보게 만드는 도구. 일단 개요서 한 장부터 써보고 피드백 받는 게 가장 빠른 시작.
4. 튜터님 피드백 : 윤정 튜터님
"정해진 포맷은 없다"
-
정보 구조도, 기능 정의서, 와이어 프레임 등 5개 문서를 반드시 순서대로 모두 써야 한다는 건 잘못된 생각
-
중요한 건 누가 읽는지(목적) 에 따라 문서 구성이 달라져야 함
-
아티클은 "이렇게 쓰는 사람도 있구나" 참고 정도로만 활용, 정답으로 받아들이지 말 것
-
아티클을 볼 때 비판적 시각으로 "이게 정말 법칙인가?" 라고 질문하는 습관 필요
-
1~2주 이렇게 표현하는 것도 사실 맞지 않음. 상황마다 팀원들의 역량마다 다르기 때문
대면 피드백
숙련 과제에 대한 Q&A는 Q&A(with. 지선 튜터님) 참고
Q1. 팀원들과 싱크를 맞추는 법에 대한 조언이 있을까요?
A1.
1. 현업 PM이 마주하는 현실 — 팀원들의 관점이 다 다르다
부트캠프에서는 기획자들끼리만 팀 프로젝트를 진행하지만, 실제 현업에서는 PM 혼자서 디자이너, 개발자, 데이터 분석가, 마케터 등 완전히 다른 포지션의 사람들과 함께 일하게 된다. 그리고 각 직군마다 같은 기획을 바라보는 관점이 완전히 다르다.
개발자는 기획을 직접 구현해야 하고 기한 안에 끝내야 하다 보니, 조금이라도 복잡하거나 까다로운 요건이 들어오면 "안 됩니다, 불가능합니다"라는 답변이 먼저 나온다. 디자이너는 UX 관점에서 판단하기 때문에, PM이 비즈니스 전략까지 고민해서 기획한 내용도 "사용자가 너무 불편할 것 같다", "사용성이 너무 떨어진다"는 이유로 반대 의견을 내기도 한다.
이런 상황이 현업에서는 비일비재하다. 그래서 PM에게 가장 중요한 것은 "이 기획을 왜 구현해야 하는지"를 설득하는 능력이다.
2. 싱크를 맞추는 법 — PRD가 핵심이다
그 설득의 도구가 바로 PRD 문서다. PRD는 킥오프 미팅을 위한 문서로, 내가 주장하고자 하는 핵심 메시지만 담아야 한다. 부가적이고 부차적인 내용이 너무 많으면 협업하는 팀원들이 오히려 혼란스러워진다. "여기에 집중해야 하는 건지, 저기에 집중해야 하는 건지, 이 기획이 왜 필요하다는 건지" 스스로 판단하게 만들면 안 된다. 상위 목표를 달성하기 위해 이 솔루션이 필요하다는 논리를 명료하게 전달하는 것이 PM의 몫이다.
단, 현실적으로 PRD를 Confluence, Notion 등에 아무리 잘 정리해 올려놔도 읽지 않고 PM에게 직접 찾아와서 질문하는 경우가 많다. "문서 올려놨으니 보세요"라고 하면 일이 안 된다. 반복적으로 설명하고, 일일이 커뮤니케이션해야 하는 상황도 감수해야 한다. 이런 경험들을 부트캠프에서부터 쌓아두면 실무에서의 커뮤니케이션 스킬로 이어진다.
Q2. 집중도가 떨어지거나 의지가 없는 팀원에 관한 동기 부여도 PM의 일인지?
A2.
동기부여 방법 — 팀원 성향 파악이 먼저다
동기부여도 PM의 역할 중 하나다. PM은 근본적으로 "일이 되게끔 만드는 사람"이기 때문에, 팀원들이 잘 움직일 수 있게 독려하는 것도 업무의 일부다.
이를 위해 가장 먼저 해야 할 것은 팀원 개개인의 성향 파악이다. 처음 만나는 팀원이라면 아이스브레이킹 시간을 따로 가지면서, 이 사람이 어떤 백그라운드를 가지고 있는지, 일할 때 어떤 스타일인지, 인간적으로는 어떤 성격인지를 먼저 파악해야 한다.
동기부여가 되는 포인트는 사람마다 다르다. 어떤 사람은 전적으로 믿고 맡겼을 때 오히려 더 잘하고, 어떤 사람은 매일 데일리로 체크해줘야 동기가 생겨서 움직인다. PM은 팀원별로 이 성향에 맞게 개별적으로 케어하고, 커뮤니케이션 방식도 다르게 가져가야 한다.
물론 이건 현업 PM도 늘 고민하는 어려운 영역이다. 정답이 있다기보다는, 실제로 다양한 사람들과 부딪혀보면서 여러 인간 군상을 경험하는 것 자체가 이 스킬을 키우는 가장 좋은 방법이다.
오늘의 회고
- 잘한 점: 저번 과제에서 궁금했던 점을 잘 정리해두어서 좋은 튜터님의 답변으로 좋은 인사이트를 얻을 수 있었다.
- 아쉬운 점: 강의를 많이 듣지 못했다.
- 원인: 토요일 반납할 생각이었어서 조금 여유 있게 진행을 함
- 개선 액션 아이템: 다음 주 부터는 주말에 안한다는 생각으로 학습 시간을 알차게 보내기
💭 오늘의 한 줄 평 : 이것.. 또한.. PM의 일...
