앱을 만들기 전, 아이디어를 검증하는 법 (개발이 저렴해진 시대에도)

앱을 만드는 데는 예전엔 몇 달과 수천 달러가 필요했습니다. 그 과정 자체가 나쁜 아이디어를 자연스럽게 걸러냈죠 — 완성할 즈음이면 유료 고객이 생겼거나, 아니면 왜 아무도 원하지 않는지 알게 됐습니다.

지금은 어떨까요? 개발은 저렴해졌습니다. 아이디어를 검증하고, MVP를 만들고, 주말 안에 사용자 앞에 내놓을 수 있습니다. 근사하게 들리지만, 새로운 문제를 깨닫기 전까지만입니다. 어떤 아이디어든 주말 안에 ‘시작’할 수는 있지만, 중요하지 않은 아이디어에도 여전히 몇 달을 쏟아붓게 된다는 것이죠.

가장 희소한 자원은 돈도, 개발에 걸리는 시간도 아닙니다. 바로 당신의 주의력입니다. 앞으로 석 달, 어디에 집중할 건가요?

코드와 사랑에 빠지기 전에 검증하는 방법을 알려드립니다.

앱 아이디어를 만들기 전에 어떻게 검증하나요?

저렴하고 순차적인 세 가지 테스트로 앱 아이디어를 검증하세요. 사람들이 관심을 갖는지 보는 대기자 명단 랜딩 페이지, 돈을 낼 의향이 있는지 보는 소규모 선판매, 문제를 제대로 이해했는지 확인하는 솔직한 대화 한 번입니다. 각 단계는 몇 달이 아니라 몇 시간이면 되고, 각각이 잘못된 것을 만드는 걸 막아줄 수 있습니다.

아이디어를 테스트하려면 대기자 명단 페이지를 만들어야 하나요?

네 — 대기자 명단 페이지는 가장 간단한 검증 단계입니다. 뉴스레터 신청에 “그래”라고 답할 만큼 누군가 관심이 있는지 보는 것이죠.

아이디어를 위한 한 페이지짜리 랜딩 페이지를 만드세요. 아직 가입은 필요 없습니다. 앱이 무엇을 하는지, 누구를 위한 것인지, 왜 중요한지만 설명하세요. 실제 사람이 쓰는 말을 쓰세요. 과대포장하지 마세요. 그다음 버튼을 하나 넣으세요. “얼리 액세스 신청하기 — 준비되면 이메일로 알려드립니다.”

일주일 동안 운영해보세요. 신청이 0건이라면, 그것도 데이터입니다. 5건이라면, 그것도 데이터입니다. 100건이라면, 뭔가 있는 겁니다.

저희가 아는 한 창업자는 반려견 산책 스케줄링 앱을 만들었습니다. 하루는 아이디어를 정리하는 데, 반나절은 간단한 랜딩 페이지를 만드는 데 썼고, 몇몇 커뮤니티 포럼에 올렸습니다. 일주일에 신청 1건. 그녀는 이 앱을 만들지 않았습니다. 대신 2주 만에 400건의 신청을 받은 다른 아이디어에 시간을 썼습니다. 그게 옳은 답입니다.

바이럴 성공을 노리는 게 아닙니다. 문턱 질문에 답하려는 겁니다. “이게 누군가의 문제를 해결하는가?” 답이 ‘아니오’라면, 두 시간과 약간의 민망함이라는 비용으로 그걸 알아낸 것이지, 석 달의 개발 기간을 날린 게 아닙니다.

앱을 만들기 전에 선판매를 해야 하나요?

네, 대기자 명단 페이지가 효과가 있었다면요 — 선판매는 다음 단계이며, 동시에 두 가지를 검증해줍니다. 사람들이 실제로 돈을 낼 것인지, 그리고 당신이 이해한 문제가 현실과 일치하는지 말이죠.

대기자 명단에서 다섯 명에게 이메일을 보내세요. 솔직하게 말하세요. “이걸 만들고 있어요. 아직 준비되지 않았습니다. 제가 정말 필요하신 것을 제대로 만들 수 있도록 선불로 200달러를 내주실 수 있나요?” 사업을 시작하는 게 아닙니다. 당신이 이해한 문제가 현실과 맞는지 검증하는 겁니다.

한 부기 담당자는 소규모 사업체의 지출을 자동으로 분류해주는 앱 아이디어를 가지고 있었습니다. 랜딩 페이지를 만들었고, 30건의 신청을 받았습니다. 그중 다섯 명에게 이메일을 보내 이렇게 말했습니다. “이걸 만들고 있어요. 첫 고객이 되어 제가 제대로 만들 수 있도록 도와주는 대가로 500달러를 내주실 건가요?”

두 명이 그러겠다고 했습니다. 그녀는 3주간 그들과 함께하며, 진짜 문제는 분류가 아니라 ‘대사(reconciliation)‘라는 걸 알게 됐습니다. 그들이 원한 건 앱이 회계사에게 장부와 은행 내역이 일치한다는 걸 증명하도록 도와주는 것이었습니다. 그녀는 하마터면 엉뚱한 앱을 만들 뻔했습니다.

사람들이 선불을 내지 않겠다면, 괜찮습니다 — 만들기 전에 그걸 알아낸 겁니다. 선불은 내지만 필요로 하는 게 예상과 다르다면, 그건 ‘보물’입니다. 코드를 단 한 줄도 쓰기 전에 나눠야 할 바로 그 대화니까요.

앱을 만들기 전에 잠재 고객에게 무엇을 물어봐야 하나요?

솔직한 대화 한 번에서 다섯 가지 질문을 하세요. 지금은 그 문제를 어떻게 해결하고 있는지, 그중 가장 안 좋은 점은 무엇인지, 좁은 범위의 해결책이라도 당신의 앱을 쓰게 만들 수 있는지, 관련 도구에 현재 얼마를 쓰고 있는지, 그리고 구체적인 가격을 제시했을 때 승낙할지 여부를 물으세요. 당신이 만들 것은 당신의 추측이 아니라 그들의 대답이 결정해야 합니다.

때로는 사람들이 선불을 내지 않으려 할 겁니다. 인색해서가 아니라 신중해서입니다. 먼저 뭔가를 보고 싶은 거죠.

그럴 땐 통화 일정을 잡으세요. “제 앱 아이디어에 대해 이야기해보실래요?” 같은 통화가 아니라, “고객님의 문제를 계속 생각해봤는데, 제가 제대로 이해했는지 확인하고 싶어요”라는 통화여야 합니다.

다섯 가지 질문을 하세요.

1. 지금은 이 문제를 어떻게 해결하고 계신가요?
2. 지금 방식에서 가장 안 좋은 점은 무엇인가요?
3. 제가 그 한 가지를 해결하는 걸 만든다면, 쓰실 건가요?
4. 이 문제를 어느 정도 해결해주는 도구에 얼마를 쓰고 계신가요?
5. 제가 월 X달러를 청구한다면, 승낙하시겠어요, 거절하시겠어요?

대부분의 사람들은 솔직하게 답해줄 겁니다. 어떤 사람들은 대충 넘어가려 하겠죠. 솔직하게 답해주는 사람들 — 특히 자신의 임시방편이나 지금 쓰는 도구에 대해 이야기해주는 사람들 — 그들이 바로 당신이 만들어야 할 대상입니다.

한 창업자는 프로젝트 관리 앱을 만들었습니다. 프리랜서 세 명과 이야기를 나눴고, 이 질문들을 던졌습니다. 세 명 모두 같은 말을 했습니다. “이런 걸 위한 도구는 안 써요. 그냥 머릿속에 담아두는데, 계속 놓쳐요.”

그 대답이 모든 걸 바꿨습니다. 그녀는 프로젝트 관리 도구를 만들지 않았습니다. 대신 알림을 보내주는 것을 만들었습니다. 다른 제품, 더 나은 제품, ‘진짜’ 문제를 이해한 것에 기반한 결과였습니다.

앱 아이디어가 검증을 통과했다는 건 언제 알 수 있나요?

세 가지 테스트 중 적어도 하나가 실제 수요를 확인해줄 때, 앱 아이디어는 검증을 통과한 겁니다. 대기자 명단이 늘어나고 있거나, 사람들이 선불을 낼 의향이 있거나, 대화들이 문제에 대해 일관된 이야기를 들려주고 있을 때 말이죠. 그때가 바로 만들어야 할 때입니다.

그리고 자신 있게 만들 수 있습니다. 추측하는 게 아니니까요. 이미 무엇이 필요한지 말해준 특정한 사람들을 위해 만드는 것이니까요.

여전히 몇 가지는 틀릴 겁니다. 개발은 대화로는 드러나지 않는 구체적인 선택을 강요하니까요. 하지만 틀리는 건 ‘디테일’이지, 이 앱이 중요한지 여부가 아닙니다.

솔직한 한 가지

때로는 검증 결과가 부정적으로 나옵니다. 대기자 명단이 채워지지 않았습니다. 사람들이 선불을 내지 않으려 합니다. 대화는 예의 바르지만 미적지근합니다.

바로 그게 핵심입니다. 그게 승리입니다. 아무도 원하지 않는 것을 만드느라 몇 주를 쓰기 전에 그걸 알아낸 거니까요.

성공하는 앱은 창업자가 검증이 필요 없을 만큼 완벽한 아이디어를 가졌던 경우가 아닙니다. 창업자가 일찍 검증하고, 생각을 두 번 바꾸고, 세 번째에 제대로 된 것을 만든 경우입니다.

일주일은 검증에 쓰세요. 그다음 석 달은 개발에 쓰세요. 그 비율이 당신의 커리어를 바꿀 겁니다.