프로토타입과 제품: AI로 만든 앱이 정말 완성됐는지 아는 법
AI로 만든 앱이 작동합니다. 그 일을 해냅니다. 그런데 왜 아직 준비가 안 된 것처럼 느껴질까요? 작동하는 프로토타입과 사람들이 정말로 돈을 낼 무언가 사이의 간극에 대한 비개발자 안내서입니다.
몇 주 전, 제가 아는 한 창업자가 치료사를 위한 예약 앱을 만들었습니다. AI 앱 빌더로 나흘 걸렸죠. 그녀가 필요한 일을 합니다. 치료사는 일정을 보고, 고객은 예약을 잡고, 확인 메일이 이메일로 나갑니다. 작동합니다.
그녀는 2주째 그걸 들여다보면서 출시를 못 하고 있습니다.
왜냐고 물었더니, 이렇게 답했습니다. “작동은 하는데… 다 된 느낌이 안 들어요.”
뭘 바꾸고 싶냐고 물었습니다. “모르겠어요. 그게 문제예요.”
이것이 AI 앱 빌더로 만드는 일에서 가장 힘든 순간입니다. 작동은 하는데, “작동한다”와 “진짜 사람들에게 이걸 써 보라고 편하게 권할 수 있겠다” 사이에 간극이 있습니다. 그 간극을 이해하는 것 — 그리고 자기가 실제로 어느 쪽에 있는지 아는 것 — 이 출시하느냐, 머릿속 목소리 단계에 영원히 갇히느냐의 차이입니다.
”완성”이 실제로 뜻하는 것
중요한 구분이 여기 있습니다. 프로토타입은 아이디어를 시험하려고 쓰는 것입니다. 제품은 문제를 풀려고 쓰는 것입니다.
치료사 예약 앱은 프로토타입입니다. 개념이 통한다는 걸 증명합니다. 치료사가 쓸 수 있긴 합니다. 하지만 투박하게 느껴지게 만드는 사소한 것이 열일곱 가지쯤 있습니다.
- 확인 이메일이 휑합니다. 로고도, 맞춤 브랜딩도, 그냥 일반적인 문구뿐입니다.
- 취소되면 알림이 가지 않습니다. 고객은 그냥 나타나지 않을 뿐이죠.
- 치료사가 예약이 꽉 찼을 때 대기 명단이 없습니다.
- 가입 흐름이 치료사의 전문 분야를 받지 않아서, 진료 유형으로 필터링할 방법이 없습니다.
- 예약 24시간 전에 보내는 리마인더 이메일이 없습니다.
이 중 어느 것도 앱을 망가뜨리지 않습니다. 그러나 모두가 진짜 치료사로 하여금 이렇게 생각하게 만듭니다. “이건 누가 주말에 대충 만든 것 같지, 나한테 돈을 받는 무언가 같진 않은데.”
그 느낌은 진짜이고, 중요합니다. 프로토타입은 이론상 문제를 풉니다. 제품은 실제로, 그걸 쓰는 진짜 사람을 위해 문제를 풉니다.
프로토타입과 제품을 가르는 세 가지 질문
여기가 어려운 부분입니다. 무엇이 빠졌는지 다 알 수는 없습니다. AI 빌더도 알 수 없습니다. 그래서 자기가 선의 어느 쪽에 있는지 알아내는 빠른 질문 세 가지가 필요합니다.
1. 당신 자신의 문제를 풀려고 이걸 쓸 것인가?
이건 정직한 질문입니다. 자기 제품과 실제로 함께 살아야 하니까요.
당신이 그 치료사 예약 앱의 창업자라면, 당신의 치료 예약을 잡는 데 그걸 쓸 건가요? “쓸 수 있나”가 아니라 — 이메일 주고받기나 공유 Google 문서 대신 실제로 그걸 쓸 건가요?
답이 “아니오”라면, 아직 완성이 아닙니다. 무엇이 잘못됐는지 정확히 압니다 — 앱을 열 때마다 느끼니까요. 답이 “예”라면, 더 가까워진 겁니다.
앞서 말한 창업자는 직접 치료사 가입을 해 봤습니다. 양식에서 막혔습니다(예약하게 해 주기도 전에 너무 많은 정보를 물었거든요). 확인 이메일을 보고는 아마추어 같다고 생각했습니다. 자기 치료사가 그 이메일을 어떻게 받을지, 스팸함으로 갈지 생각하기 시작했습니다.
그녀는 돈을 내는 고객이 쓰는 방식으로 자기 제품을 쓰고 있지 않았던 겁니다. 그렇게 써 보니, 고칠 것 열 가지를 찾았습니다.
2. 당신이 아닌 세 사람에게 보여 줬는가?
잠재 사용자와 이야기하는 건 만드는 것보다 어렵고, 대부분의 창업자는 출시 때 사람들을 놀라게 하고 싶어서 이걸 건너뜁니다. 그건 실수입니다.
포커스 그룹은 필요 없습니다. 당신이 생각하는 고객과 비슷한 세 사람이 필요합니다. 치료사 앱이라면, 실제 치료사 세 명이죠.
당신이 찾는 건 이겁니다. 그들이 어디서 헷갈리는가? 어디서 머뭇거리는가? 무엇을 묻는가? “이거 어떻게 생각해요?”가 아니라(사람들은 너무 친절합니다). 실제로 그 일을 해 보라고 하세요 — 예약을 잡고, 확인 메일을 보내고, 무언가를 취소하라고요.
창업자가 치료사 앱을 치료사 셋에게 보여 줬을 때, 둘이 물었습니다. “제가 언제 시간이 되는지 규칙을 정할 수 있나요? 예를 들어, 신규 고객은 목요일에만 받고, 오후 2시 전에는 겹쳐 예약하지 않는 식으로요.” 앱에는 일정은 있었지만 규칙은 없었습니다. 그녀는 자기가 생각한 예약 방식대로 프로토타입을 만든 것이지, 치료사가 실제로 일하는 방식대로 만든 게 아니었습니다.
그건 제품 정보입니다. 명세서로는 짐작할 수 없는 것이죠.
3. 진짜 사용자 열 명에게 주면 무엇이 깨질까?
이건 가장 어려운 질문입니다. 당신의 예외 상황을 정말로 생각해 보길 요구하니까요.
치료사 앱의 경우:
- 고객이 같은 시간에 두 예약을 잡으려 하면 어떻게 되나? (앱은 확인하지 않습니다.)
- 치료사가 예약을 취소하면 어떻게 되나? 고객이 자동으로 알림을 받나? (아니오.)
- 고객의 이메일 주소가 틀렸다면? 처음부터 다시 하지 않고 고칠 방법이 있나? (아니오.)
- 치료사가 아파서 일주일 동안 일정을 닫아야 한다면? (모든 예약을 일일이 삭제해야 합니다.)
이것들은 버그가 아닙니다. 앱이 죽지는 않습니다. 하지만 종이에 베이는 상처들입니다. 진짜 사용자 열 명과 진짜 예외 상황이면, 첫 주에 이 모두에 부딪힙니다.
제품은 예외 상황을 다룹니다. 전부는 아니고 — 어떤 건 기다려도 됩니다. 하지만 진짜 사용자와 함께 첫 2주 안에 일어나는 것들, 그것들은 작동해야 합니다.
결정하는 법: 세 층 테스트
자기가 어디 있는지 알아내는 데 이걸 쓰세요.
1층: 핵심 흐름 — 행복한 경로가 작동하나요? 사용자가 당신 앱이 설계된 그 핵심 일을 할 수 있나요?
치료사 예약기의 경우: 예. 누군가가 가입하고, 예약을 잡고, 확인 메일을 받을 수 있습니다. 작동합니다.
2층: 진짜 사용에서 나오는 예외 상황 — 실제 사용자 셋에게 보여 줬습니다. 당신이 만들지 않은 무언가에 부딪혔나요? 어딘가에서 헷갈렸나요?
치료사 예약기의 경우: 예. 치료사 셋이 규칙 기반 가용성을 원했습니다. 한 명은 확인 이메일이 너무 일반적으로 보여서 헷갈렸습니다. 한 명은 예약을 한꺼번에 삭제하려다 못 했습니다.
3층: 다듬기와 프로페셔널함 — 당신이 신경 쓴다는 느낌이 드나요? 아니면 대충 짜 맞춘 느낌인가요?
치료사 예약기의 경우: 짜 맞춘 느낌입니다. 확인 이메일이 휑합니다. 맞춤 브랜딩이 없습니다. 무언가 잘못됐을 때 오류 메시지가 없어서, 뭔가 깨지면 사용자는 무슨 일이 일어났는지 알 길이 없습니다.
발견적 규칙은 이렇습니다.
- 세 층이 다 작동한다? 당신은 제품입니다. 출시하세요.
- 1층과 2층은 되는데 3층은 아니다? 80% 완성입니다. 다듬기에 하루를 쓰세요.
- 1층은 되는데 2층과 3층은 아니다? 당신은 프로토타입입니다. 아직 출시하지 마세요.
- 1층이 탄탄하지 않다? 완성이 아닙니다. 계속 만드세요.
치료사 앱은 1층과 2층의 경계에 멈춰 있었습니다. 핵심 흐름은 작동했지만, 진짜 치료사들이 빠진 조각들을 찾아냈죠. 그래서 창업자에게는 선택지가 있었습니다. AI 빌더와 일주일을 더 보내 치료사가 실제로 필요로 하는 기능을 추가하거나, 가진 것으로 출시하고 나중에 더하거나.
(그녀는 추가했습니다. 사흘 걸렸습니다. 이제 그건 제품입니다.)
이걸 어렵게 만드는 것
이 지점에서 그토록 많은 창업자가 막히는 이유는, 만드는 건 재미있고 출시하는 건 무섭기 때문입니다.
만드는 건 AI 도구와의 대화입니다. 아이디어가 있고, 설명하면, 도구가 실행합니다. 몇 분이면 도는 피드백 루프죠. 출시는 다릅니다. 게시를 누르면, 무언가 잘못됐을 때 진짜 사람들이 알게 됩니다. 다시 하기는 없습니다.
그래서 우리는 출시하지 않을 이유를 찾습니다. “충분히 안 다듬어졌어.” “기능 하나 더 넣어야겠어.” “폰트가 이상하면 어쩌지?” 그리고 6주 뒤, 작동은 하지만 완성된 느낌은 안 드는 무언가를 여전히 끌어안고 있고, 그게 폰트 때문이라고 스스로를 설득해 둔 상태입니다.
폰트 때문이 아닙니다.
대개는 진짜 사용자와 시간을 보내지 않았거나, 머릿속에서는 말이 됐지만 진짜 사람들이 일하는 방식과는 잘 맞지 않는 무언가를 만든 겁니다. 그건 고칠 수 있습니다. 다만 자기가 모르는 걸 모른다는 사실을 인정하고, 그걸 아는 누군가와 이야기하러 가야 할 뿐이죠.
출시 준비 체크리스트
이걸 쓰세요. 짧고 정직합니다.
- 진짜 작업을 하는 데 직접 써 봤고, 작동했다(데모 모드 식이 아니라 실제로).
- 실제로 쓸 만한 세 사람에게 보여 줬고, 그들이 헷갈려한 것들을 고쳤다.
- 일어날 수 있는 모든 오류에, 사용자에게 어떻게 해야 할지 알려 주는 메시지가 있다(“오류”가 아니라 실제 안내).
- 이게 6개월간 마지막 버전이어도 괜찮다(즉, 다시 손대지 않아도 쓸모 있을 만큼 완성됐다).
- 진공 속에서 기능을 더 추가하는 것보다, 진짜 사용자에게서 배울 것에 더 설렌다.
다섯 칸을 다 체크할 수 있다면, 완성입니다. 출시하세요.
못 한다면, 하지 마세요. 다만 왜인지 구체적으로 말하세요. “다 된 느낌이 안 들어”는 이유가 아닙니다. “진짜 치료사들은 가용성 규칙이 필요한데 아직 안 만들었어”는 이유입니다. 그건 실행 가능합니다. 고칠 수 있습니다. 그게 막혀 있는 것과 길 위에 있는 것의 차이입니다.
치료사 앱의 창업자는 어제 그걸 출시했습니다. 첫 유료 고객이 생겼습니다. 제품이 완벽하진 않지만, 진짜이고, 고객은 벌써 다음에 무엇을 만들지 그녀에게 말해 주고 있습니다. 완성됐다는 걸 아는 건 바로 그때입니다. 앱이 완벽할 때가 아니라, 그걸 쓰는 사람들에게 완벽함이 실제로 무엇을 뜻하는지 배울 준비가 됐을 때 말입니다.