'하루 만에 앱을 만들었다.' 2026년 지금, 이 문장은 더 이상 놀랍지 않다. 더존비즈온과 Replit이 협력해 개최한 메이커톤에서 영업직·기획직 참가자들이 바이브 코딩으로 4시간 만에 작동하는 프로토타입을 완성했다. AI 도구가 '구현의 장벽'을 이 정도로 낮춘 건 사실이다. 그런데 만들었다는 것과 쓰인다는 것은 전혀 다른 이야기다.
Dev.to에 올라온 한 인디 개발자의 회고록은 그 간극을 날것으로 보여준다. 그는 Gemini API와 Cloudflare Worker를 붙여 37일 만에 AI 리딩 어시스턴트 크롬 익스텐션을 완성했다. 스택은 군더더기 없이 깔끔했고, 제품은 실제로 작동했다. 결과는 11번의 설치, 활성 사용자 0명, 매출 0원. 지금은 오픈소스로 전환됐다. 실패담이라기보다 '빠른 빌드'가 왜 충분하지 않은지를 보여주는 정직한 해부서다.
그가 맞닥뜨린 첫 번째 벽은 배포가 아니라 유통이었다. 크롬 스토어 심사에 5일, 이후 노출까지 또 일주일. 런칭 당일 다운로드 수는 0이었다. Reddit과 X에서 새 계정은 봇으로 간주돼 차단됐다. '마켓플레이스는 진열대이지 영업사원이 아니다'라는 그의 표현은 정확하다. 진열대는 이미 거기 있던 트래픽에게만 효과가 있다. 신뢰 자본—계정 히스토리, 커뮤니티 관계, 선출시 청중—이 없으면 아무리 잘 만들어도 보이지 않는다.
두 번째 벽은 결제 인프라였다. Lemon Squeezy도, Stripe도 우크라이나에서는 사용 불가. 이 사실을 그는 코드를 다 짜고 나서야 확인했다. 기술적으로 완벽한 제품이 수익화 경로 없이 표류하는 상황이다. 그의 교훈은 명확하다. "첫 줄의 코드를 쓰기 전에 결제 스택을 검증하라." 빌드 속도가 빨라질수록, 검증하지 않은 가정이 더 빠르게 쌓인다는 역설이 여기서 드러난다.
세 번째 벽은 역설적이게도 기술적 결정에서 왔다. 비용 통제를 위해 사용자가 직접 Cloudflare Worker를 배포하는 셀프호스팅 구조로 전환한 것은 경제적으로 옳았다. 하지만 'Worker를 먼저 배포하세요'라는 온보딩 단계가 전환율을 죽였다. 사용자는 '설치하면 바로 된다'를 원한다. 개발자가 우아하다고 느끼는 아키텍처 결정이 사용자에게는 이탈 지점이 된다. 기술의 논리와 경험의 논리는 같은 방향을 가리키지 않는다.
이 간극은 개발자 개인의 실수가 아니라 구조적 문제다. 크롬의 Gemini Nano 사례가 그것을 기업 규모에서 보여준다. 더 버지가 보도하고 국내에서도 확인된 이 사건을 요약하면 이렇다. 크롬에서 AI 기능을 켜면 weights.bin이라는 4GB 파일이 사용자 PC에 자동 저장된다. 사기 탐지·글쓰기 지원·자동완성 등에 쓰이는 Gemini Nano 온디바이스 모델의 파라미터 파일이다. 문제는 이 사실이 기능 활성화 시점에 명확히 고지되지 않는다는 것이다. 저장공간이 갑자기 줄어든 뒤 데이터 폴더를 뒤지다 발견하는 사용자가 속출했고, 파일을 지워도 AI 기능이 켜져 있으면 다시 다운로드된다. 해결하려면 크롬 설정 깊숙이 있는 '온디바이스 AI' 옵션을 직접 꺼야 한다.
구글이 기술적으로 틀린 게 아니다. 온디바이스 AI는 프라이버시와 응답 속도 면에서 명확한 이점이 있고, 모델 크기 관련 안내도 문서에는 존재한다. 문제는 그 안내가 '기능 활성화 화면'이 아니라 '상세 문서' 안에 묻혀 있다는 것이다. 사용자의 인지 흐름 위에 정보를 얹지 않으면, 아무리 좋은 기술도 불신을 만든다. 동의 없이 4GB가 사라지는 경험은 AI 기능에 대한 신뢰를 기술의 완성도와 무관하게 무너뜨린다.
두 사례를 겹쳐 보면 같은 구조가 보인다. 기술은 완성됐고, 사용자 여정은 설계되지 않았다. 인디 개발자는 온보딩 마찰을 과소평가했고, 구글은 동의 흐름을 과소평가했다. AI 도구가 빌드 속도를 10배 높여줬지만, 그 속도가 '사용자가 실제로 받아들이는가'라는 질문을 건너뛰게 만들었다.
그렇다면 바이브 코딩과 Replit 같은 저코드 AI 플랫폼의 확산은 무엇을 의미하는가. 구현 비용이 0에 가까워질수록, 경쟁 우위는 더 이상 '만들 수 있느냐'가 아니라 '사용자 여정을 얼마나 촘촘하게 설계했느냐'로 이동한다. 메이커톤에서 4시간 만에 완성된 프로토타입들이 실제 제품으로 이어지려면, 다음 단계—유통 채널, 온보딩 마찰, 결제 흐름, 투명한 기능 고지—를 누군가 설계해야 한다. 그 설계는 AI가 아직 대신해 주지 않는다.
'AI로 빠르게 만들었는데 왜 아무도 안 쓸까'라는 질문의 답은 결국 하나로 수렴한다. 만드는 것과 경험을 설계하는 것은 다른 행위다. 전자는 AI가 점점 더 잘하고, 후자는 그래서 오히려 더 희소해진다. 빌드 속도가 빨라진 만큼, 사용자 여정을 먼저 그리는 데 쓸 시간이 생겼다. 그 시간을 다시 빌드에 쏟는 팀과, 검증에 쓰는 팀 사이의 격차가 2026년 프로덕트의 실질적인 경쟁 구도가 될 것이다.