Published on

Google Stitch Skills: 디자인 작업도 이제 에이전트 워크플로가 된다

Authors

Google Stitch · Agent Skills · MCP · Design-to-Code

Google의 google-labs-code/stitch-skills가 흥미로운 이유는 "AI로 예쁜 화면을 만든다"는 익숙한 이야기 때문이 아니다. 핵심은 더 운영적이다. 이 저장소는 디자인 생성, 프론트엔드 코드 업로드, 디자인 시스템 추출, React 컴포넌트 변환, Remotion 기반 워크스루 영상 생성 같은 작업을 에이전트가 설치해서 실행할 수 있는 스킬·플러그인 단위로 패키징한다.

Google Stitch Skills cover

이 글의 관점은 단순하다. 디자인 AI의 다음 경쟁은 프롬프트 품질이 아니라, 디자인 작업을 얼마나 반복 가능하고 검증 가능한 에이전트 워크플로로 만들 수 있느냐다. Stitch Skills는 그 방향을 꽤 노골적으로 보여준다.

기준 시점: 2026-07-12에 확인한 google-labs-code/stitch-skills README, 플러그인 매니페스트, 개별 skill 문서, Stitch MCP setup 문서, Agent Skills 문서를 바탕으로 정리했다. 저장소와 제품 문서는 빠르게 바뀔 수 있다.

왜 지금 볼 만한가: 디자인 AI가 "도구"에서 "작업 절차"로 내려온다

최근 AI 디자인 도구 대부분은 사용자가 프롬프트를 넣으면 화면을 만들어주는 식으로 설명된다. 이 프레이밍은 데모에는 좋지만, 실제 팀 운영에는 부족하다. 제품 팀이 반복해서 마주치는 문제는 "첫 화면을 그럴듯하게 만드는가"보다 다음에 가깝다.

  • 기존 React/Vue 코드를 디자인 도구로 어떻게 가져올 것인가
  • 디자인 시스템 토큰과 생성 프롬프트가 충돌하지 않게 어떻게 관리할 것인가
  • 생성된 화면을 다시 코드 컴포넌트로 어떻게 되돌릴 것인가
  • 여러 에이전트 환경(Codex, Claude Code, Cursor 등)에서 같은 절차를 어떻게 재사용할 것인가

stitch-skills README는 이 문제를 플러그인 세트로 나눈다. stitch-design은 디자인 생성·편집·업로드·디자인 시스템 관리를 담당하고, stitch-build는 Stitch 디자인을 React 컴포넌트나 워크스루 산출물로 바꾸는 쪽에 가깝고, stitch-utilities는 DESIGN.md 생성, 프롬프트 개선, 멀티페이지 사이트 구성 같은 보조 절차를 맡는다.

이 구성이 중요한 이유는, 디자인 AI를 "한 번 생성하고 끝"이 아니라 반복 가능한 운영 루프로 다루기 때문이다.

Stitch Skills workflow

README가 말하는 핵심: Stitch MCP가 전제다

이 저장소는 그냥 프롬프트 라이브러리가 아니다. README의 Prerequisites 섹션은 분명하게 말한다. 이 스킬들은 에이전트 환경에 Stitch MCP server가 설정되어 실행 중이어야 한다. 즉 에이전트가 단순히 텍스트를 생성하는 게 아니라, Stitch 프로젝트·디자인 시스템·스크린 생성 도구를 실제 툴 호출로 다루는 구조다.

이 차이는 크다. 프롬프트 모음은 모델이 잘 따라주길 기대한다. 반면 MCP 기반 스킬은 다음을 명시한다.

  1. 어떤 프로젝트를 찾아야 하는가
  2. 디자인 시스템이 이미 있는지 확인해야 하는가
  3. 어떤 도구를 어떤 입력 스키마로 호출해야 하는가
  4. 생성 후 어떤 산출물을 다운로드하고 어디에 보관해야 하는가
  5. 사용자가 봐야 할 AI 피드백을 어떻게 노출해야 하는가

예를 들어 stitch::generate-design skill 문서는 새 화면 생성 전에 사용자의 모호한 요구를 UI/UX 용어로 개선하고, 프로젝트의 design system 존재 여부를 확인하라고 지시한다. 디자인 시스템이 이미 있으면 색상·폰트·테마 지시를 생성 프롬프트에 다시 넣지 말라고 경고한다. 이건 사소한 프롬프트 팁이 아니라, 실무에서 자주 터지는 디자인 토큰 충돌을 줄이는 운영 규칙이다.

설치 방식도 메시지다: Codex, Claude Code, Cursor를 한 번에 겨냥한다

README는 Codex 기준으로 codex plugin marketplace add google-labs-code/stitch-skills --ref main 흐름을 제시하고, Claude Code와 Cursor에는 npx plugins add ... --target claude-code, --target cursor 형태를 안내한다. 또 선택적으로 npx skills add google-labs-code/stitch-skills로 필요한 스킬만 설치할 수 있다고 설명한다.

여기서 읽어야 할 신호는 "지원 도구가 많다"가 아니다. 더 중요한 건 디자인 워크플로가 특정 채팅 제품 안에 갇히지 않고, 에이전트 런타임이 설치할 수 있는 패키지 형태로 움직이기 시작했다는 점이다.

Agent Skills 표준이 말하는 방향도 비슷하다. 스킬은 에이전트에게 새로운 역량과 전문성을 주는 표준화된 방식이다. 즉 stitch-skills는 Google Stitch라는 디자인 제품을, 코딩 에이전트 생태계가 설치 가능한 작업 능력으로 배포하려는 사례로 볼 수 있다.

가장 실무적인 부분: code-to-design와 design-to-code 루프

stitch::code-to-design 문서는 기존 프론트엔드 코드를 Stitch Design으로 옮기는 절차를 꽤 구체적으로 쪼갠다. 흐름은 대략 이렇다.

  1. 빌드 결과에서 self-contained HTML을 추출한다.
  2. 소스 코드에서 .stitch/DESIGN.md 형태의 디자인 시스템을 만든다.
  3. 이 DESIGN.md를 Stitch에 업로드해 design system을 생성한다.
  4. 추출한 HTML을 Stitch 프로젝트에 업로드한다.

반대로 stitch-build 플러그인 매니페스트는 Stitch 디자인을 React components, Remotion walkthrough video, shadcn/ui 통합으로 이어주는 빌드 도구라고 설명한다. 즉 방향이 한쪽만이 아니다.

Code to design loop

이 루프가 잘 작동하면 제품 팀의 디자인-개발 경계가 조금 달라진다.

  • 개발자는 이미 있는 화면을 디자인 도구로 가져와 변형 실험을 할 수 있다.
  • 디자이너는 생성된 화면을 정적 이미지가 아니라 컴포넌트 변환 가능한 산출물로 다룰 수 있다.
  • 에이전트는 "대충 화면 만들어줘"가 아니라 "프로젝트 확인 → 디자인 시스템 확인 → 화면 생성 → 자산 다운로드 → 코드 변환" 같은 절차를 실행한다.

물론 이것이 곧바로 완전 자동 제품 개발을 뜻하지는 않는다. 오히려 반대다. 자동화가 의미 있으려면 중간 산출물, 토큰, 프로젝트 ID, 파일 경로, 검증 단계가 명확해야 한다. stitch-skills의 가치는 여기서 나온다.

실무 해석: 디자인 시스템을 먼저 다루는 에이전트가 더 안전하다

생성형 UI 도구의 흔한 실패는 매번 다른 느낌의 화면을 만든다는 점이다. 데모에서는 다양성이 장점처럼 보이지만, 실제 제품에서는 브랜드·접근성·컴포넌트 일관성을 깨뜨리는 비용이 된다.

stitch::generate-design 문서가 design system 존재 여부를 먼저 확인하고, 기존 design system이 있으면 생성 프롬프트에 색상·폰트·테마를 중복 지시하지 말라고 하는 대목은 그래서 중요하다. 좋은 에이전트 워크플로는 더 많은 프롬프트를 넣는 쪽이 아니라, 프롬프트에 넣지 말아야 할 것을 아는 쪽에 가깝다.

한국 개발팀 관점에서는 다음 세 가지 체크가 현실적이다.

1) DESIGN.md를 먼저 제품 자산으로 취급하라

DESIGN.md가 단순 문서라면 아무도 안 본다. 하지만 에이전트가 화면 생성과 코드 변환 전에 읽는 계약이라면 이야기가 다르다. 색상, 타이포그래피, spacing, 컴포넌트 원칙, 금지 패턴을 사람이 읽는 문서이자 에이전트 입력으로 관리해야 한다.

2) 생성 결과보다 변환 경로를 평가하라

첫 화면이 예쁜지보다 중요한 질문은 이것이다. 이 결과를 다시 React 컴포넌트로 바꿀 수 있는가? 기존 디자인 시스템과 충돌하지 않는가? 접근성·반응형·상태 표현을 검증할 수 있는가? stitch-build가 React, Remotion, shadcn/ui 같은 산출 경로를 명시하는 이유도 여기에 있다.

3) 에이전트 권한을 분리하라

MCP 서버와 플러그인 설치는 강력하다. 프로젝트 목록을 보고, 파일을 만들고, 외부 디자인 서비스에 업로드할 수 있다면 권한·비밀키·감사 로그가 필요하다. 디자인 자동화도 운영 시스템이다.

Governance boundary

SEO 관점에서 이 주제가 오래 가는 이유

이 키워드는 당장의 GitHub Trending보다 수명이 길다. "AI design tool"은 이미 넓고 경쟁이 심하지만, "Agent Skills", "MCP", "design system", "code to design", "design to code"가 결합된 영역은 아직 실무 언어가 정리되는 중이다.

앞으로 검색 수요는 다음 방향으로 갈 가능성이 높다.

  • Google Stitch MCP 설정 방법
  • Stitch Skills 설치와 Codex/Claude Code/Cursor 호환성
  • Agent Skills로 디자인 시스템을 관리하는 방법
  • DESIGN.md와 AI UI 생성 워크플로
  • AI 디자인 도구를 React 컴포넌트 파이프라인에 연결하는 방법

단순한 제품 소개보다 이런 운영 키워드가 더 중요하다. 실제 도입자는 "멋진 화면 예시"보다 "내 코드베이스와 디자인 시스템에 어떻게 연결되는가"를 찾기 때문이다.

결론: Stitch Skills는 디자인 AI의 패키징 방식을 보여준다

google-labs-code/stitch-skills를 "Google Stitch용 스킬 모음"으로만 보면 작게 보인다. 더 큰 의미는, 디자인 작업이 점점 에이전트가 설치·실행·검증할 수 있는 작업 패키지로 바뀌고 있다는 점이다.

프롬프트만으로는 팀 운영을 만들기 어렵다. 반면 스킬은 절차, 도구 권한, 파일 산출물, 디자인 시스템, 검증 규칙을 함께 담을 수 있다. 그래서 이 저장소의 핵심은 디자인 생성 성능이 아니라 디자인 워크플로의 배포 형식이다.

한국의 개발자·빌더에게 실용적인 takeaway는 분명하다. AI 디자인 도구를 볼 때 이제 "예쁜 화면을 잘 뽑나"만 묻지 말고, 다음을 확인해야 한다.

  • 우리 디자인 시스템을 계약처럼 읽고 적용할 수 있는가
  • 기존 코드와 생성된 디자인 사이를 왕복할 수 있는가
  • 에이전트별 설치·버전 관리·권한 통제가 가능한가
  • 생성 이후의 검증과 리뷰 지점이 명확한가

이 질문에 답하지 못하는 디자인 AI는 데모로 끝날 가능성이 높다. Stitch Skills가 보여주는 방향은 반대다. 디자인을 생성물이 아니라 운영 가능한 에이전트 워크플로로 다루는 쪽이다.

출처

Discuss on Twitter • View on GitHub