이 글의 순서
핵심 내용
앱 아이디어가 떠오르면 로그인, 결제, 알림 같은 기능부터 적기 쉽습니다. 하지만 개발 전에 먼저 확인해야 할 것은 기능 수가 아니라 `누구의 어떤 문제가 지금도 반복되고 있는가`입니다. 문제가 분명하지 않은 상태에서 화면과 기능을 늘리면 개발은 진행돼도 사용자가 다시 찾을 이유를 만들기 어렵습니다.
아래 일곱 질문에 한두 문장으로 답할 수 있으면 첫 버전의 검증 범위를 정할 수 있습니다. 답이 모호한 항목은 실패가 아니라, 개발 전에 작은 실험으로 확인해야 할 가정입니다.
1. 누구의 문제인지 한 사람처럼 좁힐 수 있나요?
`운동하는 사람`, `소상공인`, `학생`처럼 넓은 표현만으로는 같은 화면을 설계하기 어렵습니다. 같은 학생이라도 시험을 준비하는 사람과 실습 일정을 관리하는 사람의 행동은 다릅니다.
처음에는 모든 사용자를 만족시키려 하기보다 대표 사용자 한 유형과 그 사람이 문제를 겪는 순간을 정하세요. 다른 역할은 첫 흐름이 성립한 뒤 추가해도 됩니다.
확인해보세요
- 이 문제를 가장 자주 겪는 사람은 누구인가?
- 언제, 어디에서 문제가 발생하는가?
- 본인 외에 관리자·파트너·보호자처럼 함께 움직이는 역할이 있는가?
- 결제하거나 도입을 결정하는 사람과 실제 사용자가 같은가?
2. 사용자는 지금 어떤 방법으로 해결하고 있나요?
경쟁 앱이 없다고 수요가 없는 것도, 좋은 기회라는 뜻도 아닙니다. 사용자는 엑셀, 단체 채팅, 전화, 종이, 여러 앱의 조합처럼 이미 다른 방식으로 문제를 해결하고 있을 수 있습니다.
현재 방법을 관찰하면 새 앱이 반드시 개선해야 할 기준이 보입니다.
새 앱의 경쟁 상대는 비슷한 앱만이 아니라 사용자가 익숙하게 쓰는 현재 방식입니다.
확인해보세요
- 같은 내용을 여러 곳에 반복 입력하는가?
- 담당자에게 진행 상태를 계속 물어봐야 하는가?
- 누락·중복·잘못된 권한 때문에 다시 처리하는 일이 있는가?
- 결제·승인·정산처럼 기록이 필요한 업무가 대화에만 남는가?
- 기존 도구를 바꾸기 싫어하는 이유는 무엇인가?
3. 문제가 얼마나 자주, 얼마나 크게 발생하나요?
불편하다는 말만으로 개발 우선순위를 정하기 어렵습니다. 문제의 빈도와 손실을 함께 기록하세요.
정확한 숫자가 없다면 일주일 동안 대표 상황을 기록하는 것부터 시작하면 됩니다. 드물지만 큰 손실을 만드는 문제와 자주 생기지만 작은 불편인 문제는 검증 방법이 달라집니다.
확인해보세요
- 하루·주·월에 몇 번 발생하는가?
- 한 번 생길 때 몇 명이 영향을 받는가?
- 처리 시간, 취소, 환불, 문의, 누락 중 어떤 비용이 생기는가?
- 해결하지 않으면 사용자가 떠나거나 운영이 멈추는가?
4. 사용자가 앱에서 반드시 끝내야 할 행동은 하나인가요?
첫 버전은 기능 목록이 아니라 시작부터 결과까지 이어지는 한 가지 행동으로 설명하는 편이 좋습니다.
`정보를 제공한다`, `편리하게 관리한다`보다 누가 무엇을 시작해 어떤 결과를 확인하는지 적으세요. 이 문장이 정해지면 필요한 화면·관리자·알림과 나중에 미룰 기능을 나누기 쉬워집니다.
확인해보세요
- 고객이 전문가를 찾고 상담을 신청한다.
- 보호자가 수업을 선택하고 출석 결과를 확인한다.
- 매장 직원이 주문을 접수하고 완료 상태를 변경한다.
- 사용자가 활동을 인증하고 적립 결과를 확인한다.
5. 앱을 만들지 않고도 먼저 확인할 수 있나요?
개발은 가정을 확인하는 가장 비싼 첫 수단일 수 있습니다. 핵심 위험을 더 작은 방법으로 시험해보세요.
수작업 실험의 목적은 완성된 서비스를 흉내 내는 것이 아니라 사용자가 실제 행동을 시작하는지, 운영자가 약속한 결과를 제공할 수 있는지 확인하는 것입니다.
확인해보세요
- 대표 고객에게 현재 처리 과정을 보여달라고 요청하기
- 신청을 폼으로 받고 사람이 직접 결과를 전달하기
- 클릭 가능한 화면 시안으로 사용 순서를 확인하기
- 예약·문의·결제 의향을 랜딩 페이지에서 확인하기
- 운영자가 실제로 처리할 수 있는 양과 예외 상황 기록하기
6. 어떤 결과가 나오면 다음 단계로 갈 건가요?
검증을 시작하기 전에 판단 기준을 정하지 않으면 긍정적인 반응만 기억하기 쉽습니다. 서비스 특성과 사용 주기에 맞는 신호를 정하세요.
인터뷰 수나 전환율 하나를 모든 서비스의 합격선으로 쓰지는 마세요. 대신 `어떤 가정`, `무엇을 관찰`, `어떤 결과면 유지·수정·중단`을 실험 전에 기록합니다.
확인해보세요
- 인터뷰에서 같은 문제가 반복해서 확인됨
- 설명을 들은 사람이 테스트 사용이나 도입 검토를 요청함
- 시안에서 도움 없이 핵심 행동을 끝냄
- 수작업 운영에서도 취소·누락 없이 결과를 제공함
- 다시 사용하거나 다른 사람에게 공유할 이유가 확인됨
7. 웹이 아니라 앱이어야 하는 이유가 있나요?
앱 설치는 사용자에게 추가 행동을 요구합니다. 다음처럼 앱의 특성이 핵심 문제 해결에 직접 필요할 때 우선순위가 높아집니다.
초기 검증이 정보 제공이나 한 번의 신청에 가깝다면 모바일 웹이나 수작업으로 먼저 확인할 수도 있습니다. 앱이 목표가 아니라 문제를 가장 적은 비용과 시간으로 검증하는 것이 목표입니다.
확인해보세요
- 자주 반복해 사용하고 로그인 상태를 유지해야 함
- 카메라, 위치, 생체 인증, 푸시 알림 같은 기기 기능이 핵심임
- 이동 중 빠르게 입력하거나 현장에서 즉시 확인해야 함
- 네트워크가 불안한 환경에서도 일부 기능이 필요함
- 홈 화면 접근성과 알림이 재사용에 중요한 역할을 함
답을 모으면 첫 버전의 검증 범위를 정하세요
일곱 질문의 답을 한 장에 모아 다음처럼 결정합니다.
기능을 정할 준비가 됐다면 MVP 기능 우선순위 진단으로 지금 만들 기능과 나중에 만들 기능을 나눠보세요. 사용 흐름과 운영 범위를 더 구체화하려면 앱 아이디어를 실제 범위로 정리하는 방법을 이어서 확인할 수 있습니다.
아이디어 검증 결과와 첫 버전 범위를 함께 정리하고 싶다면 30분 무료 상담을 신청해 주세요. 확인된 가정과 아직 검증하지 못한 위험을 나누고, 바로 개발할지 작은 실험을 먼저 할지 함께 정리하겠습니다.
확인해보세요
- 진행: 고객·문제·핵심 행동이 분명하고 작은 실험에서 실제 행동이 확인됨
- 추가 검증: 문제는 있지만 대상 사용자나 사용 빈도, 지불·도입 결정이 아직 모호함
- 방식 변경: 문제는 분명하지만 앱 설치보다 웹·기존 도구 개선이 더 적합함
- 보류: 인터뷰 반응은 좋지만 실제 사용·신청·운영 행동이 확인되지 않음
