
한 학원 원장님이 학부모용 앱을 준비하고 있었습니다. 기능 목록을 받아 보니 마흔 줄이 넘었습니다. 출결 알림, 숙제 확인, 상담 예약, 수납, 성적표, 커뮤니티, 포인트, 쿠폰까지 들어 있었습니다.
원장님은 어느 것도 빼기 싫다고 하셨습니다. 전부 학부모가 원하던 기능이었기 때문입니다. 그런데 그대로 만들면 오픈은 한참 뒤로 밀리고, 정작 학부모가 가장 자주 쓸 기능이 무엇인지 확인할 기회도 늦어집니다.
핵심은 1차 오픈 범위를 「사용자가 처음 와서 목적을 한 번 이루는 흐름」으로 정하는 것입니다. 그 흐름에 꼭 필요한 화면과 기능만 남기고, 나머지는 좋아도 다음 차례로 미룹니다. 기준이 기능의 가치가 아니라 흐름이기 때문에 덜 아프게 뺄 수 있습니다.
먼저 흐름 하나를 문장으로 적습니다
앞의 학원 앱이라면 이렇게 적을 수 있습니다. 「학부모가 앱을 받고, 아이와 연결하고, 오늘 출결 알림을 받는다.」 이 문장이 1차 오픈의 뼈대입니다.
이제 기능 목록을 한 줄씩 보면서 이 문장에 필요한지 묻습니다. 가입과 아이 연결은 필요합니다. 출결 알림은 필요합니다. 커뮤니티와 포인트는 이 문장에 없습니다. 그렇게 걸러내면 마흔 줄이 열 줄 안팎으로 줄어듭니다.
흐름 문장을 두 개 이상 쓰고 싶어질 때가 있습니다. 그럴 때는 서비스를 처음 써 보는 사람이 가장 먼저 겪을 흐름 하나만 고릅니다.
기능을 세 칸으로 나눕니다
뺀 기능을 버리는 것이 아닙니다. 칸을 옮길 뿐입니다. 기획 문서에는 아래처럼 나눠 적습니다.
| 칸 | 기준 | 예시 |
|---|---|---|
| 1차 오픈 | 흐름 문장에 없으면 서비스가 성립하지 않음 | 가입, 아이 연결, 출결 알림 |
| 오픈 직후 | 쓰는 사람이 생기면 바로 필요해짐 | 알림 설정 바꾸기, 공지 보기 |
| 다음 차례 | 있으면 좋지만 반응을 보고 정해도 됨 | 커뮤니티, 포인트, 쿠폰 |
이렇게 적어 두면 회의에서 「그럼 그건 언제 하나요」라는 질문에 바로 답할 수 있습니다. 미룬 기능에도 자리가 있다는 것이 보이면 빼는 결정이 쉬워집니다.
줄이면 안 되는 것도 있습니다
범위를 줄일 때 자주 잘못 빠지는 것들이 있습니다. 화면에 잘 보이지 않아서 덜 중요해 보이는 것들입니다.
- 관리자 기능. 회원을 찾고, 잘못된 정보를 고치고, 공지를 올리는 화면이 없으면 오픈 다음 날부터 운영이 막힙니다.
- 빈 화면과 오류 안내. 처음 가입한 사람은 데이터가 없는 화면부터 봅니다.
- 탈퇴와 비밀번호 찾기. 적게 쓰이지만 없으면 문의가 쌓입니다.
- 약관과 개인정보 동의. 가입 흐름 안에 반드시 들어가야 합니다.
기획자가 범위를 줄일 때 가장 신경 쓰는 부분이 이것입니다. 사용자 화면은 줄여도 운영과 기본 안내는 남겨 둡니다.
줄인 범위는 화면 목록으로 확인합니다
기능 목록만으로는 범위가 실제로 줄었는지 알기 어렵습니다. 기능 하나가 화면 여러 장으로 번지기도 하기 때문입니다. 1차 오픈 칸에 남은 기능을 화면 목록으로 옮겨 보면 실제 크기가 보입니다.
그 목록에서 흐름 문장을 처음부터 끝까지 따라가 봅니다. 중간에 끊기는 곳이 있으면 화면이 빠진 것이고, 한 번도 지나가지 않는 화면이 있으면 더 줄일 수 있는 것입니다.
1차 범위는 개발이 시작된 뒤에 줄이기 어렵습니다. 메뉴 구조와 화면설계를 정하는 단계에서 칸을 나눠 두면, 개발은 어디에 맡기든 직접 하든 같은 범위로 출발할 수 있습니다.
자주 묻는 질문
MVP에는 기능을 몇 개까지 넣는 게 적당한가요?
정해진 개수는 없습니다. 개수보다 사용자가 처음 와서 목적을 한 번 이루는 흐름이 끊기지 않는지를 기준으로 봅니다. 그 흐름에 필요 없는 기능은 개수와 상관없이 미루는 것이 좋습니다.
경쟁 앱에 있는 기능을 빼도 괜찮을까요?
경쟁 앱은 오랜 기간 운영하면서 기능을 쌓아 온 경우가 많습니다. 처음부터 같은 크기로 시작할 필요는 없습니다. 우리 서비스가 다르게 잘하는 흐름 하나를 먼저 열고 반응을 보는 편이 낫습니다.
1차 오픈 뒤에 기능을 추가하면 비용이 더 들지 않나요?
처음부터 다음 차례 기능을 문서에 적어 두면 추가 작업이 덜 흔들립니다. 메뉴 구조에 자리를 미리 잡아 두면 나중에 붙이기도 수월합니다. 오히려 쓰이지 않을 기능을 먼저 만드는 쪽이 더 큰 낭비가 되기 쉽습니다.