앱 기획서 작성법, PM이 실제로 쓰는 5개 문서로 정리합니다

기획서를 처음 써보는 분들이 가장 많이 하는 실수가 있습니다. 와이어프레임만 그려놓고 기획이 끝났다고 생각하는 거죠. 하지만 실무에서 와이어프레임은 5개 문서 중 하나일 뿐입니다.

PM으로 일하면서 가장 많이 받는 질문이 "앱 기획서 어떻게 써요?"입니다. 정답은 사실 단순합니다. 5개 문서를 차례대로 만들면 됩니다. 프로젝트 개요서, 정보구조도(IA), 기능정의서, 와이어프레임, 화면설계서. 이 다섯 개가 앱 기획서의 뼈대입니다.

그런데 처음 기획해보는 분들은 보통 와이어프레임부터 그리기 시작합니다. 그러면 반드시 후반부에 큰 비용을 치르게 됩니다. 화면을 다 그리고 나서 "어, 이 기능이 빠졌네?"가 되면 처음부터 다시 그려야 하거든요. 순서가 중요한 이유입니다.

기획서 5개 문서, 작성 순서와 역할

이 순서가 중요한 이유는 위에서 아래로 갈수록 디테일이 늘어나기 때문입니다. 1번 개요서가 흔들리면 2번 IA가 무너지고, IA가 잘못되면 3번 기능정의서가 어그러집니다. 거꾸로 가면 안 됩니다.

제가 처음 기획할 때 했던 실수가 바로 이거였어요. 와이어프레임부터 신나게 그렸는데, 정작 "회원 탈퇴하면 데이터 어떻게 처리할 거예요?" 같은 정책 질문에 답을 못해서 개발팀이 손 놓고 기다리는 사태가 벌어졌습니다.

1번. 프로젝트 개요서, 한 장으로 끝낸다

개요서는 길게 쓰는 문서가 아닙니다. A4 한 장이면 충분해요. 다만 다음 4가지 항목은 반드시 들어가야 합니다.

이 한 장을 못 쓰면 뒤에 무슨 문서를 만들어도 흔들립니다. 진짜로요. 기획자, 디자이너, 개발자가 같은 그림을 보고 일하려면 이 한 장이 정렬 기준이 되어야 합니다.

2번. IA로 빠진 화면을 잡아낸다

IA(Information Architecture)는 정보구조도라고 부릅니다. 앱의 메뉴 트리를 그리는 거예요. 별 거 아닌 것 같지만 이게 빠진 기능을 잡아내는 가장 효율적인 도구입니다.

IA를 그리다 보면 "어, 결제는 됐는데 주문 취소는 어디서 하지?" 같은 빈틈이 보입니다. 화면 단위로 들어가기 전에 이런 누락을 찾아내는 게 IA의 핵심 가치예요.

툴은 그렇게 중요하지 않습니다. 노션의 토글 기능, Figma의 도형, 심지어 PPT로도 됩니다. 중요한 건 팀원들이 한눈에 앱 구조를 파악할 수 있어야 한다는 것입니다.

3번. 기능정의서, 견적의 근거가 된다

기능정의서는 IA에서 도출된 각 기능을 더 잘게 쪼개는 작업입니다. 이게 왜 중요하냐면, 개발 견적과 일정 산출의 근거가 되는 유일한 문서이기 때문입니다.

예를 들어 "회원가입"이라고만 쓰면 안 됩니다. 이렇게 쪼개야 합니다.

이렇게 쪼개놓으면 견적 받을 때도 명확합니다. F-001부터 F-100까지 각 기능별로 공수를 산정하면 정확한 견적이 나오거든요. "회원가입 한 덩어리"로 견적 받으면 나중에 "이건 빠진 거였어요" 같은 분쟁이 생깁니다.

정책 정의도 여기 들어갑니다. 회원, 결제, 환불, 푸시 알림 같은 항목별 정책을 미리 확정해야 개발팀이 DB 스키마를 짜기 시작할 수 있어요.

4-5번. 와이어프레임 + 화면설계서

와이어프레임은 흔히 알려진 그것입니다. Figma, XD, 또는 PPT로 화면 레이아웃을 단순하게 그리는 단계예요. 색상, 이미지는 안 들어갑니다. "어디에 무엇이 들어가는가"만 보여주면 됩니다.

중요한 건 그 다음입니다. 화면설계서, 즉 스토리보드는 와이어프레임의 각 요소에 번호를 붙이고 디스크립션을 추가하는 작업입니다. 개발자는 이걸 보고 코드를 짭니다.

예외 처리를 빼먹지 마세요. 비로그인 상태, 데이터가 없을 때, 네트워크 오류, 입력값이 잘못됐을 때. 이런 케이스를 화면설계서에 안 적어두면 개발자가 알아서 처리하는데, 그게 기획자가 원한 방향과 다르면 다시 짜야 합니다.

예외 처리 시나리오까지 다 적힌 화면설계서가 나왔다면 기획은 끝난 거예요. 이제 개발 프로세스로 넘어갑니다.

앱 개발 프로세스, 5단계 타임라인

기획서가 완성되면 본격적인 개발 사이클이 시작됩니다. 일반적인 중규모 앱(3~6개월 프로젝트) 기준으로 단계별 기간을 정리하면 다음과 같습니다.

전체적으로 보면 최소 6주에서 길게는 3개월 이상이 걸리는 게 일반적입니다. 이 일정에서 가장 많이 깨지는 게 개발 단계인데, 이유는 보통 둘 중 하나입니다. 기획이 미흡해서 도중에 계속 추가 요구가 나오거나, QA에서 발견한 버그를 다 잡지 못하고 무리하게 출시 일정을 잡아서요.

그래서 PM 입장에서 가장 신경 써야 할 게 기획 1~2주를 절대 줄이지 않는 것입니다. 여기서 1주 아끼면 개발 단계에서 4주 까먹습니다. 진짜로요.

개발 방법론, 어떤 걸 선택할까

앱 개발에는 크게 3가지 방법론이 있습니다. 각각 언제 쓰는지 정리하면 이렇습니다.

처음 앱 만든다면 린 방식 + 애자일 운영을 추천합니다. MVP로 핵심 기능만 검증하고, 검증되면 애자일로 확장하는 방식이 시행착오 비용을 가장 줄여줍니다.

기획자가 가장 자주 빼먹는 5가지

실무에서 보면 같은 항목을 반복적으로 빼먹는 경우가 많아요. 체크리스트로 정리해드립니다.

이 다섯 가지는 화면 가짓수로는 적어 보여도, 빠뜨리면 개발 후반부에 큰 폭으로 일정이 밀립니다. 기획서 작성하면서 이 다섯 개는 무조건 체크해보세요.

정리하며

앱 기획서는 결국 팀이 같은 그림을 보게 만드는 도구입니다. 화려할 필요 없어요. 5개 문서를 순서대로 만들고, 각 문서가 다음 단계의 근거가 되도록 연결하면 그게 좋은 기획서입니다.

처음 기획해보신다면 너무 완벽하게 쓰려고 하지 마세요. 일단 1번 개요서부터 한 장 써보고, 팀원에게 보여주고, 피드백 받고 수정하는 게 더 빠릅니다. 머릿속에서만 굴리면 절대 완성 안 됩니다.

이 글을 출력해서 책상에 두고, 본인의 앱 기획서가 5개 문서 다 갖췄는지 한 번씩 확인해보세요. 한 개라도 빠진 게 있다면, 그게 나중에 폭탄이 될 가능성이 높습니다.