선배 기획서를 보고 배운 것들 (공식으로는 배우지 못했던)
- 25 Dec, 2025
온보딩 자료는 2페이지
입사했다. 온보딩 자료를 받았다. 2페이지다.
“우리 회사 서비스 소개” “기획자 업무 프로세스”
끝.
사수가 말했다. “일단 이것저것 보면서 익혀봐.”
뭘 봐야 하는데?
첫 주는 그냥 선배들 회의 듣고, 노션 페이지 구경하고, 슬랙 채널 둘러보는 게 다였다. 월급은 나가는데 뭘 하는 건지 모르겠다.
노션 폴더를 뒤진다
할 게 없어서 노션을 뒤졌다.
“기획서 아카이브” 폴더를 찾았다. 들어가 봤다.
와.
2년치 기획서가 있다. 50개는 넘는다.
선배가 쓴 기획서. 대표님이 쓴 초기 기획서. 심지어 안 된 프로젝트 기획서도 있다.
이게 교과서구나.
첫 번째 파일을 열었다. “회원가입 개편 기획서 v3.final.최종.진짜최종”
웃겼다. 근데 내용은 진지했다.
목차부터 달랐다
학교 과제 목차:
- 서론
- 본론
- 결론
선배 기획서 목차:
- 배경 및 목적
- 현황 분석
- 개선 방향
- 상세 기획
- 예상 이슈
- 일정 및 리소스
아. 이렇게 쓰는 거구나.
특히 “예상 이슈” 파트가 신기했다. 아직 안 만들었는데 이슈를 미리 쓴다고?
예상 이슈
- 개발: 기존 DB 마이그레이션 2주 소요
- 디자인: 3단계 인증 화면이 복잡해 보일 수 있음
- CS: 기존 회원 재가입 문의 예상미래를 예측하는 거였다. 문제를 먼저 말해두는 거.
회의에서 개발자가 “이거 안 돼요” 할 때, “네, 그래서 대안으로 B안을 준비했습니다” 하는 거.
나는 그냥 얼어붙는데.
문장이 짧다
선배 기획서를 읽는다. 문장이 짧다.
내가 쓴 기획서: “본 기능은 사용자가 더욱 편리하게 상품을 검색할 수 있도록 필터 기능을 개선하여 사용자 경험을 향상시키고자 하는 목적으로 기획되었습니다.”
선배 기획서: “검색 필터를 개선한다. 사용자가 원하는 상품을 빠르게 찾게 한다.”
끝.
한 문장에 한 가지만 말한다. 주어, 동사, 목적어.
“~하고자 하는 목적으로” 같은 말은 없다. “~함으로써” 같은 것도 없다.
그냥 한다. 개선한다. 추가한다. 삭제한다.
명확하다.
개발자가 읽었을 때, “이거 뭔 소리야?” 할 일이 없는 거다.
나는 그동안 뭘 쓴 거지.
스크린샷이 많다
선배 기획서는 스크린샷이 많다. 거의 모든 페이지에 있다.
“현황” 파트: 경쟁사 앱 스크린샷 6개. 우리 앱 현재 화면 4개. 문제점에 빨간 박스 표시.
“개선안” 파트: 와이어프레임. 실제 구현된 다른 서비스 예시. “이런 느낌으로” 레퍼런스.
말보다 이미지.
처음에는 귀찮아서 안 넣었다. “말로 설명하면 되지” 했다.
틀렸다.
사수가 피드백했다. “이거 화면 어떻게 되는 건지 보여줘.”
말로 10분 설명할 거, 이미지 하나면 10초다.
지금은 스크린샷부터 찍는다.
숫자가 구체적이다
내 기획서: “많은 사용자가 이탈합니다.”
선배 기획서: “회원가입 1단계에서 42%가 이탈합니다. (지난 달 기준 1,247명)”
구체적이다.
“빠르게”가 아니라 “3초 이내”. “자주”가 아니라 “주 2회 이상”. “많은”이 아니라 “전체의 23%”.
숫자를 찾아야 한다. GA를 열어본다. 데이터팀에게 물어본다. 없으면 “추정”이라고 쓴다.
“추정 20% (경쟁사 A 사례 기준)”
이렇게라도 쓴다.
숫자가 있으면 회의가 달라진다. “이게 문제인가요?”가 아니라, “42%를 30%로 줄이려면?”으로 시작한다.
목표가 생긴다.
대안이 있다
선배 기획서에는 항상 대안이 있다.
A안, B안, C안.
A안: 이상적. 개발 4주. 리소스 많이 듦. B안: 현실적. 개발 2주. 핵심 기능만. C안: 최소. 개발 3일. 임시방편.
회의 때 본다. 대표님이 묻는다. “이거 다음 주까지 되나요?”
선배가 답한다. “A안은 어렵고, C안으로 먼저 하고 A안은 다음 분기에 하죠.”
대안이 있으니까 협상이 된다.
나는 대안이 없었다. “안 되면 어떡하죠?” 만 했다.
지금은 A, B, C를 먼저 쓴다. 회의 전에.
왜 하는지를 쓴다
초반에 내 기획서: “푸시 알림 기능을 추가합니다.”
사수 피드백: “왜?”
”…사용자가 편하게?”
“그게 왜 지금 필요한데?”
대답 못 했다.
선배 기획서를 본다.
배경 및 목적
배경:
- 재방문율이 18%로 경쟁사 대비 낮음 (경쟁사 평균 32%)
- 이벤트 공지를 놓치는 사용자 클레임 주 5건 이상
- 앱 푸시 허용률은 67%로 양호함
목적:
- 재방문율 18% → 25% 달성
- 이벤트 참여율 12% → 20% 증가Why가 먼저다. What은 그다음이다.
“이게 필요해서”가 아니라, “이 문제를 해결하려고”다.
지금은 “배경 및 목적”부터 쓴다. 이게 명확하지 않으면 아래를 안 쓴다.
리스크를 먼저 말한다
예전엔 장밋빛만 썼다. “이렇게 하면 좋아질 겁니다!”
선배 기획서는 다르다.
리스크
- 개인정보 수집 동의 추가 필요 → 법무 검토 1주
- iOS 심사 시 리젝 가능성 30% (유사 사례 확인됨)
- 푸시 차단 사용자는 혜택 없음 → 형평성 이슈미리 말한다. 문제를 숨기지 않는다.
회의 때 누가 “이거 법적으로 괜찮아요?” 물으면, “네, 법무팀 검토 요청했습니다. 다음 주 결과 나옵니다.”
준비된 사람.
나는 “아 그건… 확인해보겠습니다” 했다. 준비 안 된 사람.
리스크 파트를 쓰면서 배운다. 기획은 좋은 것만 말하는 게 아니다. 나쁜 것까지 준비하는 거다.
일정을 역산한다
내 초기 기획서: “개발: 4주”
사수: “왜 4주야?”
”…그냥요?”
틀렸다.
선배 기획서:
개발 일정 (총 4주)
1주차: 기획 확정 및 디자인 (5일)
2주차: API 개발 (5일)
3주차: 화면 개발 및 연동 (5일)
4주차: QA 및 수정 (3일), 배포 (2일)
여유 기간: 없음
리스크: QA에서 이슈 발생 시 일정 지연 가능쪼갠다. 역산한다. 배포일부터 거꾸로 센다.
그리고 개발자한테 물어본다. “이거 2주 안에 되나요?”
혼자 쓰는 게 아니다.
실패한 기획서도 본다
아카이브에 “보류” 폴더가 있다. 안 된 프로젝트들.
궁금해서 열어봤다.
“커뮤니티 기능 기획서” 상태: 보류 사유: 리소스 부족, 우선순위 밀림
내용은 좋았다. 기획도 탄탄했다.
근데 안 됐다.
댓글이 있었다. “좋은 기획인데, 지금은 아니다. 내년에 다시 검토.”
아. 좋은 기획도 안 될 수 있구나.
타이밍이 중요하구나.
실패 사례를 보면서 배운다. “이러면 안 되는구나.”
성공 사례만 보면 착각한다. “이렇게 하면 되는구나.”
둘 다 봐야 한다.
그래서 나는
선배 기획서를 출력했다. 5개 골랐다. 잘 쓴 것들.
형광펜 들고 분석한다.
- 목차 구조: 노란색
- 좋은 문장: 파란색
- 데이터 쓰는 법: 초록색
- 리스크 쓰는 법: 빨간색
내 양식을 만든다. 선배 걸 베끼는 게 아니라, 구조를 배끼는 거다.
이제 기획서 쓸 때, 백지에서 시작 안 한다.
템플릿을 연다. 선배한테 배운 구조.
채운다.
여전히 부족하다. 사수한테 혼난다. “이거 왜 이렇게 했어?”
근데 예전보단 낫다.
3개월 전에는 “기획서를 어떻게 쓰는지” 몰랐다. 지금은 “뭘 더 써야 하는지” 안다.
다르다.
회사는 학교가 아니다. 누가 앉혀서 안 가르쳐 준다.
온보딩 자료는 2페이지다.
나머지는 내가 찾는 거다.
선배 기획서가 제일 솔직한 교과서다. 실전이 여기 다 있다.