새로운 앱을 떠올리면 기능 목록부터 적기 쉽습니다. 로그인, 프로필, 알림, 통계, 공유, 구독처럼 익숙한 항목이 빠르게 늘어납니다. 목록은 구체적으로 보이지만 아직 제품의 핵심을 말해 주지는 않습니다. 같은 기능도 사용자의 상황과 기대에 따라 가치가 완전히 달라지기 때문입니다.
작은 팀에게 첫 버전의 목적은 완성된 사업을 축소해서 보여주는 것이 아닙니다. 사용자가 가장 중요하게 여길 행동이 실제로 성립하는지 확인하는 것입니다. 이를 위해 Starflow는 문제 문장, 핵심 순환, 출시 경계라는 세 가지 기준을 순서대로 확인합니다.
1. 문제를 기능이 아닌 상황으로 적습니다
“할 일 관리 앱을 만든다”는 제품 분야를 설명하지만 문제는 설명하지 않습니다. “오늘 해야 할 일을 머릿속에만 두고 있어 우선순위를 잊는다”처럼 사용자가 겪는 상황을 적어야 선택 기준이 생깁니다.
좋은 문제 문장에는 사용자, 맥락, 불편, 원하는 변화가 들어갑니다. 처음부터 완벽할 필요는 없지만 기능 이름은 빼는 편이 좋습니다. 해결책을 문장 안에 넣으면 다른 방법을 비교하기 어려워집니다.
Todoly를 예로 들면 목표는 가능한 많은 생산성 기능을 제공하는 것이 아닙니다. 할 일을 빠르게 적고, 무엇을 먼저 할지 바꾸고, 완료 상태를 확인하는 짧은 흐름이 부담 없이 반복되어야 합니다. 이 문제에 직접 기여하지 않는 기능은 첫 버전의 우선순위에서 내려갈 수 있습니다.
문제 문장을 검토하는 질문
- 특정 기능 이름을 빼도 의미가 남는가?
- 언제 이 문제가 발생하는지 장면을 떠올릴 수 있는가?
- 사용자가 현재 사용하는 대안은 무엇인가?
- 문제가 해결되었는지 행동으로 확인할 수 있는가?
2. 사용자가 반복할 핵심 순환을 찾습니다
앱의 가치는 화면 개수가 아니라 행동의 연결에서 나옵니다. 사용자가 앱을 열고, 무엇인가 입력하거나 선택하고, 결과를 확인한 뒤 다시 방문할 이유를 얻는 과정을 핵심 순환이라고 부릅니다.
Numball의 순환은 비교적 분명합니다. 대결에 입장하고, 비밀 숫자를 정하고, 상대의 숫자를 추측하고, 스트라이크와 볼 단서를 확인해 다음 추측을 만듭니다. 이 순환이 끊기지 않으려면 매칭보다 멋진 프로필 화면을 먼저 만드는 것은 적절하지 않습니다.
PetBites에서는 순환이 두 개입니다. 반려동물의 정보를 개인적으로 기록하는 순환과 일상·제품 리뷰를 커뮤니티에 공유하는 순환입니다. 두 행동이 같은 프로필을 사용하더라도 공개 범위는 다르므로 화면에서 경계를 명확히 보여줘야 합니다. 핵심 순환을 그리면 기능뿐 아니라 개인정보 결정도 함께 드러납니다.
핵심 순환을 한 줄로 그리는 법
- 진입: 사용자는 왜 지금 앱을 여는가?
- 행동: 반드시 해야 하는 한 가지 입력 또는 선택은 무엇인가?
- 피드백: 행동이 반영되었음을 어떻게 즉시 알 수 있는가?
- 결과: 앱을 닫기 전에 무엇을 얻는가?
- 재방문: 다음 사용을 만드는 상태나 기대는 무엇인가?
이 다섯 단계 중 설명하기 어려운 부분이 있다면 화면을 추가하기 전에 제품의 약속을 다시 확인합니다. 특히 재방문 이유를 푸시 알림 하나로 대신하면 장기적으로 약해집니다. 알림은 이미 존재하는 가치를 상기시킬 수는 있지만 가치를 만들지는 못합니다.
3. ‘없어도 되는 것’이 아니라 ‘나중에 검증할 것’을 정합니다
첫 버전에서 기능을 줄인다고 해서 중요하지 않다는 뜻은 아닙니다. 지금 검증하려는 가설과 직접 연결되지 않는 기능을 나중으로 보내는 것입니다. 이 구분이 없으면 출시 이후에도 왜 기능을 뺐는지 설명할 수 없습니다.
범위를 정할 때는 세 가지 목록을 만듭니다. 첫째는 핵심 순환이 동작하기 위해 반드시 필요한 항목, 둘째는 운영과 안전을 위해 필요한 항목, 셋째는 사용 패턴을 확인한 뒤 결정할 항목입니다.
- 핵심: 입력, 저장, 결과처럼 제품 약속을 완성하는 기능
- 운영·안전: 오류 처리, 문의, 개인정보 안내, 삭제 경로, 신고 등
- 후속 검증: 소셜 기능, 고급 통계, 테마, 세밀한 개인화처럼 사용 근거가 필요한 기능
운영과 안전 기능을 “나중에”로 미루지 않는 것이 중요합니다. 사용자가 계정을 만들 수 있다면 삭제 방법도 준비해야 하고, 공개 콘텐츠를 올릴 수 있다면 신고와 운영 기준도 함께 생각해야 합니다. 첫 버전이 작다는 이유로 사용자의 권리까지 축소할 수는 없습니다.
출시 전 무엇을 증거로 볼 것인가
다운로드 수만으로 초기 제품의 가치를 판단하기 어렵습니다. 작은 제품에서는 사용자가 핵심 순환을 완료하는지, 어느 단계에서 멈추는지, 문의 내용이 설명 부족인지 실제 오류인지가 더 유용할 수 있습니다.
정량 데이터가 충분하지 않을 때는 직접적인 사용 관찰과 지원 문의도 중요한 증거입니다. 단, 몇 명의 의견을 모든 사용자의 요구처럼 확대해서는 안 됩니다. 의견이 나온 상황과 실제 행동을 함께 기록하고 반복되는 패턴을 찾습니다.
Starflow의 초기 검토 항목
- 첫 실행 후 핵심 행동까지 불필요한 단계가 있는가?
- 빈 화면에서 사용자가 다음 행동을 알 수 있는가?
- 실패 후 다시 시도할 수 있는가?
- 기능 설명과 실제 동작이 일치하는가?
- 수집하는 정보와 보관 이유를 설명할 수 있는가?
- 지원 문의에서 같은 혼동이 반복되는가?
작게 시작한다는 의미
작은 제품은 기능이 적은 제품이 아니라 판단이 선명한 제품입니다. 해결할 상황을 좁히고, 반복할 순환을 확인하고, 출시 경계를 설명할 수 있다면 첫 버전은 작아도 불완전하게 느껴지지 않습니다.
반대로 핵심 순환이 불명확한 상태에서 기능을 늘리면 화면은 풍부해져도 사용 이유는 약해집니다. 다음 아이디어를 시작할 때 기능 목록보다 문제 문장 한 줄과 사용 순환 다섯 칸을 먼저 적어보는 것을 권합니다.