'AI를 쓰면 혼자서도 제품을 만들 수 있다'는 말은 이제 선언이 아니라 증명된 사실에 가깝다. 하지만 진짜 질문은 그 다음이다. 만들고 난 뒤, 사용자가 왜 돌아오는가. 최근 두 가지 사례가 이 질문에 대한 서로 다른 각도의 답을 내놓았다.
데이터가 제품을 설계한다: Wishyze의 Phase Model
dev.to에 공개된 Wishyze 개발기는 단순한 성공 회고가 아니다. 개발자 funnywish는 AI 기반 아침 루틴 앱을 혼자 만들어 28,547명의 가입자를 모았고, 그 과정에서 발견한 사용자 이탈 패턴을 제품 설계의 핵심 원리로 전환했다. 스택 자체는 낯설지 않다. Next.js 14, TypeScript, Tailwind, Supabase—익숙한 조합이다. DeepSeek V4 Pro를 붙여 사용자별로 진화하는 루틴을 생성했고, 기술적 구현은 빠르게 끝났다.
흥미로운 건 그가 데이터에서 발견한 Phase Model이다. 가입 직후 1~7일은 기대감으로 가득한 'Spark' 단계다. 그런데 2~6주 사이, 사용자의 73%가 조용히 사라진다. 그는 이 구간을 'Void'라고 이름 붙였다. 루틴이 습관이 되기 전, 새로움이 사라지고 의지만 남는 바로 그 시간. 반대로 이 구간을 버텨낸 사용자들은 6~12주 차에 실제 행동 변화를 경험하기 시작한다. 이 구조를 발견하자마자 그는 제품 전체를 재설계했다. Day 3의 프롬프트와 Day 21의 프롬프트가 의도적으로 다르게 설계된 것도, 93일 연속 스트릭이 탄생한 것도 이 인사이트에서 출발한다.
코드를 몰라도 시스템을 설계할 수 있다: TransferIQ의 빠른 검증
velog에 공개된 TransferIQ 개발기는 또 다른 맥락에서 같은 교훈을 전한다. 200번의 취업 실패 끝에 "내가 나를 고용하자"는 결심으로 시작한 이 프로젝트는, 코딩 비전공자가 AI를 '주니어 개발자'처럼 다루며 핀테크 앱을 런칭한 기록이다. 총 예산 20만 원, 낡은 노트북 한 대. 그가 세운 원칙은 단순했다. '비파괴적 개발'—현재 작동하는 구조를 건드리지 않고 새로운 레이어를 추가하는 방식. 이 원칙 하나가 AI의 무분별한 리팩토링을 막고 앱을 안정화시켰다.
기술보다 주목할 부분은 그의 검증 루프다. GA4와 구글 서치 콘솔을 매일 들여다보며 어떤 채널이 실제 가입으로 이어지는지 추적했고, 반응 없는 채널은 빠르게 포기했다. 그 결과 런칭 5일 만에 활성 유저 100명, 전주 대비 400% 이상의 성장세. 코드를 짤 줄 몰라도, 데이터를 읽고 집중할 곳을 결정하는 프로덕트 감각이 속도를 만들어냈다.
두 사례가 가리키는 공통 지점
기술 스택도, 도메인도, 배경도 다른 두 사람이 공통으로 도달한 결론이 있다. AI는 구현을 빠르게 해주지만, 사용자가 돌아오는 이유는 AI가 설계해주지 않는다. Wishyze의 개발자는 "리텐션이 초기에 유일하게 중요한 지표"라고 단언했다. TransferIQ 빌더는 트래픽이 아닌 '실제 가입'으로 이어지는 채널만 남겼다. 두 사람 모두 허수를 보지 않았다.
솔로 빌더에게 AI 도구는 팀원을 대체하는 것처럼 느껴지지만, 실제로는 결정의 고독을 없애주지 않는다. Wishyze 개발자는 페이먼트 게이트웨이 하나를 고르는 데 3주를 썼다고 고백한다. 검증해줄 팀원이 없기 때문이다. 그 고독을 버티게 한 건 "매일 작은 것을 배포하라"는 원칙과 사용자로부터 직접 오는 피드백이었다.
솔로 빌더를 위한 실전 시사점
두 사례를 프론트엔드 개발자의 시각으로 재해석하면 몇 가지 설계 원칙이 도출된다.
첫째, 이탈 구간을 제품에 내장하라. Wishyze의 Phase Model처럼, 사용자가 가장 많이 떠나는 시점을 미리 알고 그 구간에 다른 경험을 배치하는 것은 UX 설계의 문제다. 온보딩이 끝난 뒤의 경험을 누가 설계하고 있는가.
둘째, AI에게 가이드라인을 줘라. TransferIQ의 '비파괴적 개발' 원칙처럼, AI 코딩 도구는 제약 없이 쓰면 코드베이스를 빠르게 망가뜨린다. 어떤 파일을 건드리지 말아야 하는지, 어떤 패턴을 유지해야 하는지 명시적으로 설계하는 것이 안정성의 출발점이다.
셋째, 측정 가능한 지표를 먼저 고르라. Wishyze 개발자가 MRR 대신 '오늘 완료된 루틴 수'를 봤듯, 제품 건강을 드러내는 지표는 매출이 아닐 수 있다. 지금 당신의 제품에서 사용자의 실제 참여를 가장 잘 보여주는 숫자는 무엇인가.
전망: 빠른 출시 이후의 설계가 더 중요해진다
AI 도구 덕분에 '만드는 것'의 장벽은 사실상 무너졌다. 비전공자도, 혼자인 개발자도 몇 주 안에 작동하는 제품을 세상에 내놓을 수 있다. 그러나 바로 그렇기 때문에, 경쟁의 축이 '얼마나 빨리 만드는가'에서 '사용자가 왜 계속 쓰는가'로 빠르게 이동하고 있다. 솔로 빌더에게 다음 진짜 질문은 여기서 시작된다. AI가 코드를 뽑아주는 속도만큼, 사용자 행동 데이터를 읽고 제품 경험을 재설계하는 속도를 함께 높일 수 있는가. 두 사례는 그 답이 도구가 아니라 사용자를 향한 집요한 관찰에 있음을 다시 한번 확인시켜준다.