Claude Design이 코드를 뱉을 때, 스택 선택은 누가 하는가

Claude Design이 코드를 뱉을 때, 스택 선택은 누가 하는가

AI가 동작하는 HTML/React를 즉시 만들어주는 시대, 프로토타입을 프로덕션으로 이어붙이는 판단은 여전히 개발자 몫이다.

Claude Design Vite Next.js 스택 선택 AI 프로토타이핑 렌더링 전략 디자인 시스템
광고

Claude Design이 프롬프트 하나로 인터랙티브한 체크아웃 플로우를 뽑아내는 장면을 처음 봤을 때, 솔직히 두 가지 감정이 동시에 들었다. '이제 프로토타이핑 속도는 진짜 문제가 아니구나'라는 해방감, 그리고 '그래서 이 코드, 어디에 붙이지?'라는 현실적인 질문. Anthropic이 2026년 4월 리서치 프리뷰로 공개한 이 도구는 결과물이 이미지가 아니라 실제 동작하는 HTML, React, SVG라는 점에서 기존 AI 디자인 도구와 결이 다르다. 클릭 가능하고 테스트 가능한, '배포 직전'에 가까운 산출물이다.

기술적 기반은 Claude Opus 4.7의 비전 모델이다. 고해상도 이미지 입력을 지원하면서 기존 코드베이스를 읽어 폰트·색상·컴포넌트 같은 디자인 시스템 요소를 자동 추출하고 이후 작업에 일관되게 반영한다. '매번 처음부터 브랜드 가이드를 다시 설명해야 하는' 반복을 제거한다는 점에서, 이건 단순한 코드 생성기가 아니라 컨텍스트를 기억하는 디자인 협업 파트너에 가깝다. 이 차이가 실무에서 왜 중요한지는 뒤에서 다시 이야기하겠다.

그런데 Claude Design이 빠르게 코드를 내어놓는 순간, 워크플로우에는 즉시 다음 질문이 등장한다. 이 코드를 어떤 스택 위에 올릴 것인가. Vite인가, Next.js인가. 이 선택이 왜 갑자기 중요해지냐면, AI 프로토타이핑 도구가 '첫 번째 시안까지의 시간'을 극단적으로 압축해버렸기 때문이다. 예전에는 프로토타입을 만드는 시간이 워낙 길었기 때문에 스택을 먼저 정하고 시작하는 게 자연스러웠다. 지금은 그 순서가 뒤집혔다. 코드가 먼저 나오고, 스택 판단은 그 다음이다.

스택 선택 판단의 기준은 사실 단순하다. 프로젝트의 성격이 렌더링 전략을 결정하고, 렌더링 전략이 프레임워크를 결정한다. Vite와 Next.js를 비교한 실무 사례를 보면 이 원칙이 선명하게 드러난다. TMDB 기반 영화 검색·관리 앱처럼 순수 SPA 구조라면 Vite가 자연스럽다. 빠른 개발 환경, React Router 중심 구조, 서버 렌더링 불필요—이 세 조건이 맞아떨어지면 Next.js의 풀스택 프레임워크 무게는 오히려 오버엔지니어링이 된다. 반대로 SEO가 중요한 마케팅 사이트, 쇼핑몰, 블로그라면 SSR/SSG/ISR을 내장한 Next.js가 압도적으로 유리하다. 이미지 최적화, API Routes, Vercel과의 긴밀한 통합까지 고려하면 선택지는 더 좁혀진다.

여기서 Claude Design과 스택 선택의 교차점이 생긴다. Claude Design이 생성하는 코드는 대부분 독립형 HTML이거나 React 컴포넌트 수준이다. 내보내기 형식으로 zip, 독립형 HTML, Claude Code 핸드오프를 지원하지만, 피그마 직접 내보내기와 Next.js 프로젝트 구조 자체를 내뱉는 기능은 없다. 다시 말해 Claude Design은 '컴포넌트를 빠르게 만드는 도구'이지 '프로젝트 아키텍처를 결정하는 도구'가 아니다. 배포는 여전히 사용자 몫이고, GitHub Pages나 Netlify Drop 같은 별도 도구로 우회해야 한다.

이 구분이 실무에서 가장 자주 흐릿해지는 지점이다. Claude Design이 '배포 직전'에 가까운 결과물을 내어놓으면, 개발자나 기획자는 무의식적으로 '이걸 그냥 올리면 되는 거 아닌가?'라고 생각하게 된다. 하지만 그 코드가 SPA로 동작하기에 충분한지, SSR이 필요한 서비스인지, 디자인 시스템 드리프트가 이미 발생하지 않았는지는 Claude Design이 판단해주지 않는다. 특히 작업이 길어질수록 처음 설정한 디자인 규칙에서 벗어나는 경향—'드리프트'—은 브랜드 아이덴티티가 엄격한 프로젝트에서 반드시 사람이 검증해야 할 지점이다.

그렇다면 실무에서 이 흐름을 어떻게 설계해야 할까. 현재 가장 현실적인 조합은 이렇다. Claude Design으로 방향성을 다섯 개 내외로 빠르게 탐색한다. 그중 하나를 골라 프로젝트 성격을 진단한다—SEO가 필요한가, 서버 렌더링이 필요한가, 순수 인터랙티브 앱인가. 이 진단 결과가 Vite냐 Next.js냐를 결정한다. 그 위에 피그마로 디자인 시스템을 정리하고, 최종적으로 Claude Code나 별도 퍼블리싱 도구로 배포 파이프라인을 연결한다. 핵심은 Claude Design을 '탐색 압축 도구'로 쓰고, 스택 선택과 아키텍처 설계는 그 탐색 결과를 받아든 개발자가 프로젝트 맥락 기반으로 판단한다는 역할 분리다.

AI 프로토타이핑 도구가 성숙할수록 이 역할 분리는 더 중요해진다. Claude Design이 더 정교해지고, 어쩌면 미래에는 Next.js 프로젝트 구조 자체를 내뱉는 날이 올 수도 있다. 하지만 그때도 'SEO가 필요한 서비스인가', '이 컴포넌트는 CSR로 충분한가 아니면 SSR이 필요한가', '디자인 시스템 드리프트가 허용 가능한 수준인가'라는 질문은 사람이 먼저 정의해야 한다. 도구가 빨라질수록 판단의 무게는 도구가 아닌 개발자에게 더 선명하게 남는다. Claude Design이 코드를 뱉는 속도가 빨라진 지금, 스택 선택의 기준을 먼저 세우는 쪽이 더 느린 팀이 결국 더 빠르게 도착한다.

출처

더 많은 AI 트렌드를 Seedora 앱에서 확인하세요