Figma·코드·AI Studio로 내보내기

Stitch에서 화면이 잘 나왔다고 해서 일이 끝난 것은 아닙니다. 오히려 그때부터 진짜 일이 시작됩니다. 팀원에게 보여 줘야 하고, 디자이너는 다듬어야 하고, 개발자는 실제 동작으로 바꿔야 하니까요. 그래서 좋은 프로토타입은 완성품이라기보다, 협업이 출발하는 첫 번째 합의안에 가깝습니다.

이 챕터에서는 Stitch 결과물을 세 갈래로 나눠 보겠습니다. 첫째는 Figma로 보내서 디자인 작업을 이어 가는 길, 둘째는 코드로 내보내 구현을 시작하는 길, 셋째는 AI Studio 같은 개발 도구로 넘겨 동작하는 앱 초안으로 발전시키는 길입니다. 중요한 것은 어느 쪽이 더 멋지냐가 아니라, 지금 팀에 무엇이 더 필요한가를 아는 것입니다.

내보내기는 저장이 아니라 전달이다

Stitch에서 만든 화면은 혼자 보기엔 충분히 그럴듯할 수 있습니다. 하지만 실무에서는 그다음 질문이 더 중요합니다. 이 화면을 누가 이어받을 것인가, 어디에서 수정할 것인가, 무엇을 기준으로 구현할 것인가 하는 질문입니다.

디자이너와 함께 디테일을 다듬어야 한다면 Figma가 자연스럽습니다. 빠르게 브라우저에서 동작을 보여 주고 싶다면 AI Studio 같은 개발 도구가 편합니다. 프런트엔드 개발자가 바로 손을 대야 한다면 코드 내보내기가 가장 빠릅니다. 결국 Stitch의 산출물은 끝맺음이 아니라 바통입니다. 어느 손으로 넘길지만 정하면 됩니다.

Figma로 복사할 때 가장 먼저 알아둘 것

Stitch의 Figma 내보내기는 아주 편리하지만, 조건이 있습니다. Google AI Developers Forum의 공식 답변에 따르면 Figma 직접 내보내기는 Standard 모드에서 지원되고, Experimental 모드에서 만든 결과물은 Stitch 안에서 바로 Figma로 내보낼 수 없습니다.¹ 이 차이를 모르고 작업하면, 한참 잘 만들고 나서 "왜 Figma 옵션이 없지?" 하는 순간을 맞기 쉽습니다.

또 하나 실무적으로 자주 헷갈리는 점이 있습니다. Figma 복사 기능은 코드 내보내기와는 다른 흐름입니다. 보통은 디자인 결과를 선택한 뒤, 더보기 메뉴 쪽에서 Copy to Figma 같은 옵션을 확인하게 됩니다.²

정리하면, Stitch에서 Figma로 보낼 때는 먼저 지금 작업한 파일이 어떤 모드에서 만들어졌는지 확인하는 습관이 필요합니다. 이 한 번의 확인이 나중에 꽤 많은 한숨을 줄여 줍니다.

Figma로 보낸 뒤 바로 해야 하는 일

Figma로 붙여넣는 순간 모든 것이 끝날 것 같지만, 사실 그때부터는 "정리 작업"이 시작됩니다. Stitch가 구조를 꽤 잘 가져와도, 그대로 팀 작업 파일에 넣으면 곧장 실무 파일이 되지는 않습니다.

가장 먼저 할 일은 레이어 구조를 보는 것입니다. 이름이 모호하거나 그룹이 지나치게 잘게 쪼개져 있으면, 다음 사람은 금방 길을 잃습니다. 두 번째는 Auto Layout과 간격을 점검하는 일입니다. 화면이 보기엔 맞아 보여도, 콘텐츠 길이가 바뀌거나 버튼 문구가 길어지면 금세 틀어질 수 있기 때문입니다. 세 번째는 반복 요소를 컴포넌트로 승격시키는 일입니다. 버튼, 카드, 입력창, 탭, 배지 같은 요소를 바로 컴포넌트화해 두면 이후 수정 비용이 눈에 띄게 줄어듭니다.

여기서 중요한 태도는 하나입니다. Stitch에서 넘어온 결과물을 "완성된 디자인 파일"로 보지 말고, "좋은 초안이 담긴 편집 가능한 재료"로 보는 것입니다. 이 관점이 있어야 Figma에서 괜히 실망하지 않고, 반대로 너무 믿지도 않게 됩니다.

Figma 내보내기가 안 될 때의 우회 경로

실무에서는 언제나 예외가 생깁니다. 모드 제약 때문에 직접 Copy to Figma가 안 될 수도 있고, 가져온 결과의 충실도가 기대보다 떨어질 수도 있습니다. 이런 경우 일부 팀은 Stitch에서 코드를 ZIP으로 내려받은 뒤, 이를 서드파티 Figma 플러그인으로 다시 가져오는 우회 경로를 쓰기도 합니다.³

이 방법은 분명 실용적일 수 있습니다. 다만 공식 기본 흐름이라기보다 대체 경로에 가깝습니다. 따라서 회사나 팀 차원에서는 보안과 업로드 정책을 먼저 확인하는 편이 안전합니다. 특히 실제 고객 데이터나 비공개 화면이 들어간 경우라면 더더욱 그렇습니다.

즉, 우회 경로는 분명 유용하지만, 편리함만 보고 바로 쓰기보다 "이 파일을 외부 도구에 올려도 되는가"를 먼저 판단해야 합니다.

코드 내보내기는 개발 시작선으로 쓰는 것이 맞다

Stitch의 큰 장점 중 하나는 결과물을 프런트엔드 코드로 이어 줄 수 있다는 점입니다. 첫 공개 당시 공식 소개에서도 Stitch는 디자인을 바탕으로 프런트엔드 코드를 생성해 개발 워크플로와 연결하는 도구로 설명됐습니다.⁴

여기서 꼭 기억할 점은, 내보낸 코드가 곧바로 배포용 최종 코드라는 뜻은 아니라는 것입니다. 더 정확히 말하면, 이 코드는 아주 빠르게 출발할 수 있는 초반 구조물입니다. 손으로 처음부터 레이아웃과 스타일을 짜는 시간을 크게 아껴 주지만, 실제 제품 코드베이스에 넣으려면 여전히 정리와 분해가 필요합니다.

쉽게 말해 Stitch의 코드 내보내기는 "빈 땅"을 "골조가 올라간 현장"으로 바꿔 줍니다. 그런데 골조가 올라갔다고 바로 입주할 수는 없죠. 전기, 배관, 문 손잡이, 주소 체계까지 다 잡아야 합니다. 프런트엔드도 비슷합니다.

내보낸 코드를 그대로 배포하면 아쉬운 이유

처음 받은 HTML/CSS 코드는 보기에는 그럴듯해도, 실제 서비스에서는 곧 부족한 부분이 드러납니다. 정적인 더미 데이터가 들어 있을 수 있고, 버튼은 예뻐도 실제 이벤트가 안 붙어 있을 수 있으며, 접근성이나 반응형 처리도 팀 기준에는 못 미칠 수 있습니다.

그래서 개발자가 Stitch 산출물을 받았다면, 최소한 다음 네 가지는 점검하는 편이 좋습니다.

• 반복 UI를 컴포넌트로 분리했는가

• 색상, 간격, 글꼴을 팀의 토큰이나 스타일 시스템에 매핑했는가

• 빈 상태, 로딩 상태, 오류 상태 같은 현실적인 화면이 있는가

• 키보드 포커스, 라벨, 시맨틱 태그 같은 접근성 요소가 살아 있는가

이 네 가지를 빼고 나면 남는 것은 예쁜 목업에 가깝습니다. 반대로 이 네 가지를 채우기 시작하면, 비로소 구현 자산이 됩니다.

AI Studio로 넘길 때 생기는 변화

2026년 공식 업데이트에서 Google은 Stitch가 AI Studio 같은 개발 도구로 디자인을 내보내는 흐름을 지원한다고 설명했습니다.⁵ 이 말의 핵심은 간단합니다. Stitch가 화면의 생김새를 빠르게 잡아 준다면, 그다음 단계에서는 그 결과를 다른 개발 도구로 옮겨 더 실제에 가까운 앱이나 프로토타입으로 발전시킬 수 있다는 뜻입니다.

이 흐름의 좋은 점은, 같은 화면 설명을 다시 처음부터 말로 풀어쓰지 않아도 된다는 것입니다. 디자인이 이미 참조 자료로 전달되기 때문입니다. 그래서 제품팀 입장에서는 "디자인 초안"과 "개발용 초안" 사이의 거리가 조금 줄어듭니다.

다만 여기서도 기대치는 현실적으로 잡는 편이 좋습니다. Stitch에서 AI Studio로 넘어간다고 해서 곧바로 완성형 서비스가 되는 것은 아닙니다. 더 살아 있는 시연본, 더 빠른 검증용 앱 초안에 가까워진다고 보는 편이 맞습니다.

Stitch에서 AI Studio로 갈 때 특히 좋은 상황

모든 프로젝트가 AI Studio를 반드시 거쳐야 하는 것은 아닙니다. 하지만 아래 상황에서는 꽤 강력합니다.

• 사용 흐름을 빠르게 시연해야 하는 MVP일 때

• 개발자 없이도 작동하는 데모를 먼저 보여 줘야 할 때

• 디자인과 기능 요구를 한 자리에서 짧은 사이클로 반복해야 할 때

• HTML/CSS 초안보다 한 단계 더 살아 있는 프로토타입이 필요할 때

특히 PM, 창업자, 디자이너가 함께 보는 자리에서는 정적인 화면보다 "클릭했을 때 이렇게 열리고, 여기서 이렇게 넘어간다"가 훨씬 설득력이 큽니다. 말보다 동작이 빠르기 때문입니다.

AI Studio에서도 결국 사람이 마무리해야 하는 부분

여기서도 기대치를 너무 높게 잡지는 않는 편이 좋습니다. AI Studio 같은 도구는 프런트엔드 시연과 코드 초안을 상당히 빨리 만들어 줄 수 있지만, 실제 서비스에 필요한 모든 것을 자동으로 해결해 주지는 않습니다. 백엔드 연동, 인증, 실제 API 연결, 권한 처리, 데이터 검증, 예외 상황 처리는 여전히 엔지니어링의 몫입니다.

이 말은 곧, 그 결과물도 "최종 납품본"보다는 "검증 가능한 앱 초안"으로 보는 편이 맞다는 뜻입니다. 다만 이 초안은 꽤 강력합니다. 단순한 그림보다 훨씬 많은 것을 검증하게 해 주기 때문입니다. 사용 흐름, 화면 전환, 정보 밀도, 버튼 위치, 폼 구성, 모바일 대응까지 한 번에 볼 수 있으니까요.

실무에서 가장 많이 쓰는 후속 수정 포인트

내보내기 이후에 팀이 가장 자주 손보는 곳은 의외로 거창한 부분이 아닙니다. 아주 현실적인 부분입니다.

첫째는 텍스트입니다. AI가 넣은 문구는 대체로 자연스럽지만, 제품의 말투와 완전히 같지는 않은 경우가 많습니다. 버튼 문구, 빈 상태 메시지, 오류 안내, 도우미 문장은 거의 항상 사람이 마지막 손질을 하게 됩니다.

둘째는 데이터와 상태입니다. 예쁜 카드가 있어도 실제 데이터 길이가 달라지면 줄바꿈이 어색해지고, 표는 항목이 없을 때 금방 허전해집니다. 그래서 실무에서는 더미 데이터가 아니라 진짜 데이터 형태로 한 번 흔들어 보는 과정이 꼭 필요합니다.

셋째는 반응형과 접근성입니다. 데스크톱에서 멀쩡한 화면이 모바일에서 갑자기 꽉 막힌 복도처럼 보이는 일은 흔합니다. 버튼 터치 영역, 폼 입력 포커스, 대비, 헤딩 구조도 이 단계에서 함께 확인해야 합니다.

넷째는 팀 규칙에 맞추는 일입니다. 클래스 네이밍, 폴더 구조, 컴포넌트 분리 기준, 상태 관리 방식, 테스트 방식은 각 팀마다 다릅니다. Stitch가 여기까지 미리 다 알 수는 없습니다. 결국 프로젝트 문법으로 다시 번역하는 작업이 필요합니다.

추천 핸드오프 순서: 가장 덜 헤매는 흐름

현실적으로는 아래 순서가 가장 덜 헷갈립니다.

• Stitch에서 화면 방향을 확정한다

• 디자이너 협업이 필요하면 Figma로 먼저 보낸다

• 더 살아 있는 동작 검증이 필요하면 AI Studio 같은 개발 도구로 넘긴다

• 실제 구현이 시작되면 코드 내보내기 결과를 기준으로 컴포넌트화한다

• 마지막으로 실제 데이터, 상태, 접근성, 반응형을 붙인다

이 순서가 좋은 이유는 역할이 겹치지 않기 때문입니다. Figma는 다듬기, 개발 도구 연계는 동작 검증, 코드 내보내기는 구현 시작에 초점을 둡니다. 셋을 한 도구처럼 보지 않고, 각각 다른 단계의 도구로 보면 훨씬 매끄럽습니다.

결국 중요한 것은 "잘 넘기는 능력"이다

Stitch를 잘 쓴다는 말은 예쁜 화면을 잘 뽑는다는 뜻만은 아닙니다. 그 화면을 Figma에서 수정 가능하게 만들고, 코드로 이어 붙일 수 있게 정리하고, 개발 도구로 자연스럽게 넘길 수 있어야 비로소 실무 도구가 됩니다.

좋은 프로토타입은 박수 받고 끝나는 결과물이 아닙니다. 다음 사람의 일을 쉽게 만드는 문서이자, 다음 단계의 속도를 올리는 발판입니다. 디자이너에게는 정리된 재료가 되고, 개발자에게는 구현의 골조가 되고, 제품팀에게는 검증 가능한 가설이 됩니다.

그러니 Stitch에서 마음에 드는 화면이 나왔을 때, 이렇게 생각하면 됩니다. "완성됐다"가 아니라, "이제 제대로 넘길 차례다." 바로 그 순간부터 프로토타입은 그림이 아니라 제품이 되기 시작합니다.

참고

¹Exporting Stitch to Figma

²Unable to Export as Figma in Google Stitch

³From Google Stitch to Figma

⁴From idea to app: Introducing Stitch, a new way to design UIs

⁵Introducing "vibe design" with Stitch