AI 도구로 뭔가를 만들어본 사람이라면 한 번쯤 이 감각을 알 것이다. 프롬프트 몇 줄로 그럴듯한 화면이 뚝딱 등장하고, 버튼도 눌리고, 데이터도 흐른다. '이거 실제로 쓸 수 있겠는데?'라는 생각이 드는 순간—그런데 막상 실제 사용자 앞에 내놓으려는 순간 뭔가 무너지기 시작한다. AI가 만든 프로토타입이 데모에서 멈추는 이유, 그리고 그것을 넘어서기 위한 설계 원칙을 최근 세 가지 사례가 선명하게 보여주고 있다.
프로토타입이 '도구'가 되는 순간의 가치
Anthropic의 Claude Artifacts는 채팅 응답이 곧바로 실행 가능한 도구가 되는 경험을 제공한다. HTML, CSS, JavaScript 혹은 React 컴포넌트를 대화 패널 옆에 즉시 렌더링하는 방식으로, 사용자는 코드를 복사해서 붙여넣고 환경을 구성할 필요 없이 바로 클릭하고 검증할 수 있다. 모기지 계산기, 멀티스텝 폼, CSV 기반 데이터 뷰—이런 작고 자기완결적인 것들을 만드는 데 Artifacts는 탁월하다. 한 메시지로 CodePen 수준의 결과물이 나온다.
그런데 dev.to에 소개된 Artifacts 분석이 가장 정직하게 짚는 부분은 바로 한계다. Artifacts는 샌드박스 iframe 안에서 돌아간다. 외부 API 호출 불가, 진짜 백엔드 없음, 상태는 리로드하면 사라진다. 이 격리가 '즉시 실행 가능'을 가능하게 하는 동시에, 프로토타입과 제품 사이의 선을 그어버린다. "Artifacts는 아이디어에서 클릭 가능한 것으로 가는 가장 빠른 경로이고, 배포된 제품으로 가는 느리고 잘못된 경로다"—이 한 문장이 핵심이다. 빠른 검증 도구로 쓰고, 검증이 끝나면 실제 코드베이스로 포팅해야 한다.
'바이브'에서 '스펙'으로: 프로토타이핑 워크플로우의 진화
같은 맥락에서, Vibe Coding의 흐름을 정면으로 다룬 글이 흥미로운 진단을 내린다. 초기 바이브 코딩의 매력은 분명하다. 몇 주 걸리던 프로토타입이 하룻밤에 나온다. 하지만 프로젝트가 커지면 AI는 버튼 하나를 바꾸다 네비게이션을 부수고, 인증을 고치다 스타일이 날아간다. 그 원인을 오랫동안 AI 탓으로 돌렸는데, 진짜 문제는 프롬프트였다. "Build me a project management app"—요구사항도, 아키텍처도, 제약도 없이 그냥 바이브만 있었던 것이다.
이 글이 제안하는 해법은 'Spec-Driven Development'다. 코드를 생성하기 전에 질문에 먼저 답한다. 이 포트폴리오는 누구를 위한 건가? 어떤 페이지가 필요한가? 재사용 가능한 컴포넌트는 무엇인가? 성공의 기준은 무엇인가? spec.md, requirements.md, tasks.md 같은 문서가 AI에게 빈 땅이 아니라 설계도를 건네는 방식이다. 놀랍게도 코딩 전에 더 많은 시간을 쓸수록 프로젝트를 더 빨리 끝냈다. 재생성이 줄었고, 토큰 낭비도 줄었다. AI는 내가 더 나은 기획자가 될수록 더 나은 개발자가 됐다.
이 전환이 시사하는 것은 단순히 '프롬프트를 잘 써라'가 아니다. 프롬프트가 점점 길어지다가 어느 순간 스펙이 된다는 것, 즉 AI 코딩 워크플로우의 성숙도는 결국 소프트웨어 엔지니어링의 본질—먼저 생각하고, 그 다음 만들기—로 수렴한다는 것이다.
프로덕션에 닿는 순간, 비용 구조가 설계가 된다
프로토타입이 실제 사용자를 만나는 순간, 또 다른 차원의 문제가 등장한다. 인도 신용카드 비교 서비스 CardCheck의 Next.js App Router 최적화 사례는 이를 구체적으로 보여준다. Vercel에서 예상치 못한 경고가 울렸다—Fluid Active CPU가 허용치의 230%를 초과했고, Edge 요청이 월 98만 건에 육박했다. 트래픽이 늘었는데 서버리스 사용량은 그보다 훨씬 빠르게 폭증했다.
원인은 세 가지였다. 첫째, 미들웨어가 비로그인 방문자(95% 이상)에게도 매 요청마다 외부 인증 체크를 실행하고 있었다. 둘째, 공개 비교 페이지에 force-dynamic을 남용해 CDN 캐시를 완전히 우회했다. 셋째, 미들웨어 매처가 robots.txt, sitemap.xml 같은 정적 메타데이터 파일도 서버리스 함수를 트리거하도록 방치했다. 해법은 놀랍도록 간결했다. 인증 쿠키가 없으면 세션 검증을 건너뛰는 가드 로직, 정적 애셋을 매처에서 명시적으로 제외, force-dynamic 대신 revalidate = 60의 ISR 전환—이 세 가지만으로 24시간 안에 Edge 요청을 80% 줄이고 TTFB도 150~400ms 개선했다.
이 사례가 중요한 이유는 단순한 비용 절감 팁이 아니기 때문이다. AI 도구로 빠르게 만든 Next.js 앱이 프로덕션에 진입하는 순간, '돌아가는 것'에서 '효율적으로 돌아가는 것'으로의 전환이 필요하다는 것을 보여준다. 프로토타입 단계에서 묵인했던 force-dynamic의 남용, 미들웨어의 과도한 범위—이런 것들은 트래픽이 작을 때는 보이지 않지만, 성장하는 순간 비용과 성능으로 돌아온다.
세 사례가 함께 그리는 설계 원칙
세 이야기를 이어붙이면 AI 프로토타이핑의 여정 전체가 드러난다. Claude Artifacts는 '아이디어 → 클릭 가능한 검증'의 구간을 극단적으로 단축한다. Spec-Driven Development는 '검증된 아이디어 → 안정적인 코드베이스'로 넘어가는 다리를 놓는다. Next.js 비용 최적화는 '코드베이스 → 프로덕션 품질'의 마지막 구간을 책임진다. 이 세 구간이 연결되어야 비로소 데모가 제품이 된다.
핵심 시사점은 이렇다. AI가 만든 것을 빠르게 검증하는 능력과, 그것을 제품 수준으로 끌어올리는 설계 능력은 별개다. 전자만 있으면 데모의 무덤이 쌓이고, 후자만 있으면 검증되지 않은 것에 과잉 투자하게 된다. 프로토타입 단계에서는 Artifacts처럼 격리된 환경의 한계를 의도적으로 활용해 빠르게 가설을 소진하고, 그 다음에는 스펙 문서로 AI와의 대화를 구조화하며, 프로덕션에 진입하는 순간에는 캐싱 전략과 미들웨어 설계를 처음부터 의식해야 한다.
다음 국면: 설계 지능의 시대
AI 코딩 도구는 점점 더 강력해지고 있지만, 그 힘을 제대로 쓰는 조건은 오히려 더 인간적인 역량으로 수렴한다. 더 나은 프롬프트 엔지니어가 아니라, 더 나은 소프트웨어 엔지니어—먼저 생각하고, 명확하게 정의하고, 성장을 예측하며 설계하는 사람. Vibe Coding의 엔드게임이 '생각하는 능력'이었다는 통찰처럼, AI 프로토타이핑의 엔드게임은 결국 설계 지능이다. 도구는 이미 충분히 빠르다. 이제 질문은 '어떻게 빠르게 만드나'가 아니라 '무엇을 어떤 수준으로 만들어야 하는가'다.