AI 코딩 도구 덕분에 프로토타입을 만드는 속도는 드라마틱하게 빨라졌다. OpenCraft처럼 스케치 한 장을 Next.js 앱으로 바꿔주는 디자인-투-코드 플랫폼이 등장하고, Claude Code 같은 도구로 비개발자도 며칠 안에 맞춤형 대시보드를 뚝딱 만들어낸다. 소규모 팀이 "개발자가 없어서"라는 말을 더 이상 핑계로 쓸 수 없는 시대가 됐다.
그런데 여기서 불편한 질문 하나가 남는다. 데모는 인상적인데, 왜 6개월 뒤엔 아무도 안 쓰는가? dev.to에 올라온 「Why Most AI Features Fail After the Demo」는 이 패턴을 정확하게 짚는다. 대부분의 AI 기능은 '첫인상'을 위해 설계된다. 질문 하나에 깔끔한 답변, 소셜 미디어에 공유하기 좋은 장면. 하지만 실제 사용자는 데모 영상처럼 행동하지 않는다. 정보는 불완전하고, 질문은 모호하고, 신기함이 사라진 자리엔 신뢰성에 대한 요구가 남는다.
핵심 이슈는 'AI 기능'과 'AI 프로덕트'의 혼동이다. 모델 자체를 제품으로 착각하는 순간, 팀은 잘못된 방향으로 최적화를 시작한다. 사용자는 Gemini를 쓰는지 Claude를 쓰는지 관심 없다. 자신의 문제가 해결됐는지만 본다. 인텔리전스는 인프라고, 제품은 그 위에 설계된 경험이다. 이 구분을 못 하면 아무리 좋은 모델을 붙여도 프로덕트는 데모 단계에서 멈춘다.
그렇다면 프로토타입이 프로덕트로 살아남으려면 무엇이 필요한가. 세 가지 조건이 반복적으로 등장한다.
첫째, 컨텍스트 설계. 범용 모델이 아니라 '이 제품의 사용자가 실제로 겪는 문제'에 집중된 컨텍스트가 있어야 한다. 모든 질문에 답할 수 있는 어시스턴트보다, 우리 제품과 문서와 워크플로우에 대해서만 정확하게 답하는 어시스턴트가 더 높은 신뢰를 얻는다. OpenCraft가 모델에 무관하게 일관된 디자인 품질을 내기 위해 멀티패스 프롬프팅과 시스템 레벨 디자인 제약을 적용한 것도 같은 맥락이다. 좋은 출력은 좋은 모델이 아니라 좋은 컨텍스트 설계에서 나온다.
둘째, 관찰 가능성(Observability). 전통적인 소프트웨어는 예측 가능한 출력을 낸다. AI는 그렇지 않다. 사용자가 무엇을 묻는지, 어디서 응답이 실패하는지, 어떤 워크플로우가 중단되는지—이 피드백 루프 없이는 개선이 감으로만 이뤄진다. 특히 빠른 프로토타이핑으로 런칭한 팀일수록 이 레이어를 나중으로 미루는 경향이 있는데, 그게 데모 이후 침묵의 진짜 원인이 되기도 한다.
셋째, 가드레일은 제약이 아니라 기능이다. 모든 것에 답하려는 AI는 오히려 사용자 신뢰를 깎는다. "그건 제가 도울 수 없어요"라고 명확하게 말하는 시스템이 더 예측 가능하고, 예측 가능한 시스템이 더 오래 쓰인다. 범위를 명확히 하는 것, 잘 모르는 영역에서 응답을 제한하는 것—이런 설계 결정이 UX의 일부다.
소규모 팀의 관점에서 보면 이 흐름은 더 흥미롭게 읽힌다. 「The End of 'We Don't Have a Developer'」에서 체인지 매니지먼트 컨설턴트가 Claude Code로 맞춤형 대시보드를 만든 경험을 공유하며 강조하는 것은 속도가 아니다. 번역 손실이 없어졌다는 것이다. 문제를 가장 잘 아는 사람이 직접 구현 대화에 참여하니, "내가 상상한 것"과 "실제로 만들어진 것" 사이의 간극이 줄었다. 이건 기술의 민주화이기도 하지만, 동시에 문제 정의 능력이 새로운 병목이 됐다는 신호다. 프롬프트가 흐릿하면 도구도 흐릿하다.
결국 AI 프로토타이핑 워크플로우가 성숙해질수록, 차별화 지점은 모델 성능이나 생성 속도가 아니라 프로덕트 사고의 밀도로 이동한다. 누가 쓰는지, 어떤 맥락에서 쓰는지, 실패했을 때 사용자가 어떻게 느끼는지—이 질문들은 AI가 대신 해줄 수 없다. OpenCraft가 "AI 슬롭(AI slop)"이라는 단어를 직접 꺼내며 싸우는 것도 이 지점이다. 빠르게 생성된 UI가 다 똑같아 보이는 문제, 그건 모델의 한계가 아니라 의도 설계의 부재다.
앞으로의 경쟁은 더 빠른 프로토타입을 만드는 팀이 아니라, 프로토타입 이후를 설계한 팀이 가져갈 가능성이 높다. AI 기능이 데모 이후에도 살아남는 조건—컨텍스트, 관찰 가능성, 가드레일—은 결국 프론트엔드 개발자가 코드 바깥에서 설계해야 할 영역이다. 도구가 빨라질수록, 판단의 무게는 오히려 사람 쪽으로 더 쏠린다.