Google Stitch 2.0 써봤더니 — 빠른데 Figma는 막혔습니다

프롬프트 한 줄로 UI가 완성된다는 말은 절반만 맞습니다. 2026년 3월 19일 대규모 업데이트 이후, 무한 캔버스·음성 입력·MCP 서버 연동까지 붙었는데 막상 써보면 Figma 내보내기에서 처음 막힙니다. 어떤 조합에서 막히고, 어떻게 돌아가는지 공식 자료와 실사용 데이터로 정리했습니다.

2026년 3월 업데이트에서 뭐가 달라졌나요

Google Stitch는 원래 2025년 Google I/O에서 공개된 Labs 실험 프로젝트였습니다. 당시엔 Gemini 2.5 Pro 기반으로 텍스트 프롬프트를 단일 UI 화면으로 바꿔주는 수준이었습니다. 2025년 12월 업데이트에서 Gemini 3과 화면 간 연결 프로토타입 기능이 붙었고, 2026년 3월 19일 업데이트에서 성격이 완전히 바뀌었습니다. (출처: Medium, tenten.co, 2026.03.21)

3월 업데이트에서 한 번에 다섯 가지가 달라졌습니다. 무한 캔버스, 음성 입력(Voice Canvas), 디자인 에이전트, MCP 서버 연동, 그리고 Gemini 3.1 Pro 사고 모드가 추가됐습니다. Google이 직접 “AI 네이티브 소프트웨어 디자인 캔버스”라고 부르기 시작한 것도 이 시점입니다. (출처: Google Developers Blog, 2025.05.20 / 업데이트 반영)

바뀐 모델 구조도 짚어둘 필요가 있습니다. 현재 Stitch는 Gemini 3 Flash(표준 모드, 속도 최적화)와 Gemini 3.1 Pro 사고 모드(실험 모드, 품질 최적화)로 나뉩니다. 어떤 모드를 쓰냐에 따라 Figma 내보내기 가능 여부가 달라지는데, 이 부분이 가장 많이 혼란을 일으키는 지점입니다.

▲ 목차로 돌아가기

무료인데 350회면 실제로 얼마나 쓸 수 있을까요

처음 접할 때 가장 먼저 눈에 들어오는 게 “무료, 카드 없음, 월 350회”라는 숫자입니다. 실제로 체감되는 양과 비교해봤습니다. (출처: nxcode.io, 2026.03.22)

표준 350회가 생각보다 빨리 소진되는 구조

Stitch의 생성 1회는 화면 1개를 새로 만들거나 기존 화면을 프롬프트로 수정하는 행동 하나입니다. 한 페이지를 잡는 데 보통 3~5회의 반복이 필요하고, 랜딩 페이지 5개 화면짜리 프로토타입을 만들면 15~30회가 소모됩니다. 단순 계산으로 350회 ÷ 25회 = 14세트, 한 달에 프로젝트 14개 정도를 첫 초안 수준에서 다룰 수 있는 양입니다.

문제는 실험 모드 50회입니다. Gemini 3.1 Pro 사고 모드는 이미지 참조나 복잡한 레이아웃 처리에서 품질이 눈에 띄게 다릅니다. 그런데 월 50회는 하루 이틀이면 다 씁니다. 실험 모드를 메인으로 쓰는 구조는 현실적으로 불가능합니다. 표준 모드로 80%를 처리하고, 최종 화면 완성 단계에서만 실험 모드를 아껴 쓰는 습관이 필요합니다.

솔직히 말하면, 사이드 프로젝트나 개인 포트폴리오 작업에는 350회면 충분합니다. 반면 협업 팀이 하나의 계정을 돌려 쓰거나, 클라이언트 프로젝트를 여러 개 동시에 진행하는 상황이라면 한 달 안에 한도를 채울 가능성이 큽니다.

▲ 목차로 돌아가기

Gemini 3 Pro를 선택하면 Figma로 못 넘깁니다

Stitch가 “Figma로 내보내기를 지원합니다”라고 공식 소개하지만, 조건이 있습니다. Gemini 3 Pro 에이전트로 생성한 디자인은 “Copy to Figma” 옵션이 뜨지 않습니다. 이건 버그가 아닌 의도된 제한이고, html.to.design 공식 문서에 명확히 나옵니다. (출처: html.to.design blog, 2026.03 기준)

Stitch 에이전트가 4가지라는 사실을 모르는 경우가 많습니다

현재 Stitch에서 선택할 수 있는 에이전트는 Fast, Gemini 2.5 Pro, Gemini 3 Pro, Nano Banana Pro입니다. 이 중 Fast와 Gemini 2.5 Pro에서는 “Copy to Figma”가 정상 동작합니다. Gemini 3 Pro를 선택하는 순간 이 경로가 막히고, Nano Banana Pro의 경우 공식적으로 이유를 밝히지 않았습니다.

막혔을 때 쓸 수 있는 대안이 있습니다

html.to.design을 활용하면 Gemini 3 Pro 결과물도 Figma로 가져올 수 있습니다. Stitch에서 .zip으로 코드를 다운로드한 후 Figma 플러그인(html.to.design)에 올리면 됩니다. Stitch 자체 내보내기보다 레이어 구조가 더 깔끔하고 색상·폰트 충실도도 높다는 게 이 플러그인 측 실측 결과입니다. (출처: html.to.design 공식 블로그, 2026.03 기준)

이 우회 경로를 미리 알아두면 에이전트 선택에서 Gemini 3 Pro를 자유롭게 쓸 수 있습니다. 모르고 시작하면 디자인 완성 후 막혀서 처음부터 다시 하거나 에이전트를 바꾸는 상황이 생깁니다.

▲ 목차로 돌아가기

DESIGN.md가 Claude Code를 만나면 달라지는 것

Stitch가 생성한 결과물 중 가장 낮게 평가받는 요소가 DESIGN.md 파일입니다. 색상, 폰트, 간격 정보를 자동으로 문서화한 파일인데, 대부분의 포스팅에서 “그냥 참고용 마크다운”으로 다룹니다. 실제로는 다릅니다. 이 파일을 Claude Code의 CLAUDE.md에 등록해두면 뒤에서 만드는 모든 컴포넌트가 처음 Stitch에서 잡은 디자인 기준을 자동으로 따릅니다.

실제 워크플로는 이렇게 연결됩니다

구체적인 흐름은 세 단계입니다. 먼저 Stitch에서 UI를 생성하고 DESIGN.md를 포함한 코드 전체를 다운로드합니다. 다음으로 Claude Code 세션을 열고 CLAUDE.md 파일에 DESIGN.md를 import합니다. 마지막으로 “이 디자인 기준으로 로그인 화면 만들어줘”라는 자연어 한 줄만 입력하면 됩니다.

이전에는 디자이너가 Figma에서 색상 코드와 폰트 이름을 일일이 개발자에게 전달하던 작업이었습니다. 그 소통 비용이 Stitch + DESIGN.md 조합에서는 자동화됩니다. MCP 서버 연동을 사용하면 AI Studio, Antigravity, Cursor로도 같은 파이프라인을 연결할 수 있습니다.

단, 이 워크플로가 빛나는 건 혼자 개발하거나 소규모 팀이 빠르게 프로토타입을 만드는 상황입니다. 이미 Figma 기반 디자인 시스템이 정착된 팀에서는 DESIGN.md를 굳이 쓸 이유가 없습니다.

▲ 목차로 돌아가기

20년 경력 디자이너가 “still mid”라고 한 이유

Stitch가 화제를 모으면서 “Figma 주가 12% 하락”이라는 뉴스가 함께 퍼졌습니다. 막상 현장 반응은 다릅니다. DesignCourse를 운영하는 Gary Simon은 UI/UX 및 프론트엔드 개발 20년 경력자로, 출시 다음 날 Stitch를 테스트했습니다. 결론은 “still mid”였습니다. (출처: Medium, tenten.co, 2026.03.21)

구체적으로 어디서 막혔는지가 중요합니다

Simon이 짚은 문제는 크게 세 가지입니다. 첫 번째는 색상 채도입니다. 생성된 화면이 전반적으로 탁하고 대비가 낮습니다. “atmospheric depth”를 요청했지만 실제 변형 결과물 3개 중 1개만 소폭 개선됐고, 1개는 오히려 텍스트 가독성이 나빠졌습니다. 두 번째는 편집 범위입니다. 요소 단위로만 수정이 가능해서, 섹션 전체 배경색을 바꾸거나 레이아웃을 재구성하려면 프롬프트를 새로 넣어야 합니다. Figma처럼 레이어를 잡아서 직접 수정하는 방식이 아닙니다. 세 번째는 비주얼 위계 판단입니다. 어떤 정보를 크게 강조하고 어디에 여백을 둬야 하는지, 즉 “왜 이렇게 배치했는가”의 근거가 없는 레이아웃이 나옵니다.

주관적으로 보면, 현재 Stitch의 가치는 빠른 초안 생성에서 시작해 개발 파이프라인으로 넘기는 속도에 있습니다. “클라이언트에게 보여줄 수 있는 수준”이 되려면 Figma에서 손을 더 봐야 합니다. 이 부분을 알고 들어가면 기대 이하의 실망은 피할 수 있습니다.

▲ 목차로 돌아가기

지금 Stitch가 가장 쓸모 있는 사람과 아닌 사람

결론부터 말씀드리면, Stitch는 디자인을 새로 시작해야 하는 사람에게 유리하고, 이미 디자인 시스템이 있는 곳에는 굳이 필요하지 않습니다.

이런 상황이라면 지금 당장 써볼 가치 있습니다

비개발자·PM·스타트업 창업자가 “돌아가는 화면”을 빠르게 만들어야 할 때, 그리고 사이드 프로젝트나 해커톤에서 Figma를 배울 시간이 없을 때입니다. 기존에 Lovable이나 v0로 작업하던 분들에게는 Stitch가 “프론트 초안 단계”를 더 정교하게 잡아주는 도구로 앞에 붙일 수 있습니다. 프롬프트만으로 초안 잡고 → v0나 Claude Code로 코드 완성 → Lovable로 백엔드 붙이는 파이프라인이 2026년 현재 가장 현실적인 조합입니다.

이런 상황이라면 굳이 안 바꿔도 됩니다

Figma를 이미 잘 쓰고 있는 디자이너, 팀 단위 협업이 Figma를 중심으로 돌아가는 경우, 디자인 시스템을 운영 중인 프로덕트 팀입니다. Stitch는 팀 협업 기능이 Figma에 비해 얕고, 레이어 단위 편집 깊이가 부족합니다. 기존 워크플로를 바꿀 만큼의 이득이 아직 없습니다.

Google의 장기 전략도 봐둘 필요는 있습니다. Stitch는 현재 Google Labs 실험 프로젝트이고, Google은 과거 수많은 Labs 제품을 조용히 종료한 전적이 있습니다. 다만 MCP 서버 통합과 AI Studio, Antigravity, Gemini CLI와의 연동 구조를 보면 인프라 레벨에서 묶여 있어 단순 실험 종료보다는 Google I/O 2026(예정: 5월 19~20일)에서 방향이 더 구체화될 가능성이 높습니다.

▲ 목차로 돌아가기

자주 묻는 것들

▲ 목차로 돌아가기

마치며

Google Stitch 2.0은 생성 속도와 무료라는 진입 장벽 낮음에서는 실제로 강점이 있습니다. 다만 기대하고 들어가야 할 것과 기대하지 말아야 할 것이 있습니다.

기대해도 되는 것: 프롬프트 한 줄로 10~15초 만에 나오는 초안, DESIGN.md를 통한 Claude Code 연결, Voice Canvas로 빠른 탐색. 기대하지 말아야 할 것: 클라이언트에게 바로 보여줄 수준의 완성도, Gemini 3 Pro에서 Figma로 끊김 없는 내보내기, React 직접 출력.

이 도구가 진짜 빛나는 경우는 “아이디어가 있는데 Figma는 모르고, 코드도 못 짜는 상황”입니다. 그 공백을 채워주는 도구로는 지금 시점에 무료 선택지 중 가장 잘 만들어진 편입니다.

▲ 목차로 돌아가기

본 포스팅 참고 자료

1. Google Developers Blog — Stitch 공식 소개 (developers.googleblog.com)
2. Google AI Developers Forum — Figma 내보내기 오류 스레드 (discuss.ai.google.dev)
3. html.to.design 공식 블로그 — Gemini 3 Pro Figma 내보내기 제한 (html.to.design)
4. Medium (tenten.co) — Google Stitch 2026.03.19 업데이트 실사용 분석 (medium.com)
5. NxCode — Google Stitch 5분 튜토리얼 2026 (nxcode.io)