Figma의 source of truth가 코드로 이동할까 2026 – Claude Design·Figma Make·Stitch 비교표

Posted on by

2026년 4월 20일 기준 Claude Design, Figma Make, Google Stitch는 같은 질문을 서로 다르게 푼다.

디자인의 source of truth를 어디에 둘 것인가.

전에는 답이 비교적 단순했다.

제품 화면의 원본은 Figma 파일이고, 개발자는 그 파일을 보고 코드로 옮긴다.

물론 현실은 조금 더 복잡했다.

Figma에는 최신 디자인이 있는데, 프로덕션 코드는 그보다 두 스프린트 앞서 있거나, 반대로 코드에는 이미 바뀐 UI가 있는데, Figma 파일은 아직 회의실에 두고 온 어제의 마음처럼 남아 있는 경우가 많았다.

이 문제는 원래도 있었다.

다만 2026년 들어 AI 디자인 도구와 AI 코딩 에이전트가 같이 커지면서 질문이 더 날카로워졌다.

Claude Design은 코드베이스와 디자인 파일을 읽어 팀 디자인 시스템을 만들고, Claude Code로 넘길 수 있는 handoff bundle을 말한다.

Figma Make는 Figma 파일, 디자인 시스템, Make kits, Code Connect, MCP를 붙여서 Figma 안에서 디자인과 코드 맥락을 같이 다루려 한다.

Google Stitch는 AI-native canvas, MCP server, SDK, skills, 그리고 디자인 규칙 문서화 흐름으로 에이전트가 읽기 좋은 디자인 맥락을 만들려 한다.

그래서 이번 글은 “Figma 끝났나” 같은 단순한 싸움으로 가지 않는다.

그건 클릭은 만들지만, 실무 판단에는 별 도움이 안 된다.

이번 글의 질문은 이거다.

요약: 디자인 source of truth는 당장 Figma에서 코드로 완전히 이동한다기보다, 작업 단계별로 쪼개질 가능성이 크다. Figma는 협업 캔버스, 코드는 실제 제품 원본, DESIGN.md나 Code Connect 같은 문서는 AI가 읽는 디자인 계약서 역할을 맡게 된다.

이 글은 기존 TECHTAEK의 Claude Design 글 두 개와 Google Stitch의 DESIGN.md 글을 보강하는 하위 글이다.

기능 소개는 이미 했다.

이번에는 원본이 어디에 살아야 하는지 본다.

작업자가 실제로 헷갈리는 지점은 기능 목록이 아니다.

이걸 Figma에 고쳐야 하나, 코드에 고쳐야 하나, 문서에 고쳐야 하나다.

그 질문을 닫아보자.

지금 결론

내 판단은 이렇다.

Figma는 사라지지 않는다.

하지만 Figma만 source of truth인 시대는 약해질 수 있다.

특히 AI 에이전트가 화면을 만들고, 코드를 고치고, 디자인 시스템 문서를 읽는 워크플로에서는 원본이 한 군데에만 있으면 오히려 느려진다.

실무적으로는 네 겹으로 나눠 보는 편이 안전하다.

층 source of truth 후보 맡겨도 되는 것 맡기면 위험한 것
제품 동작 프로덕션 코드 실제 상태, 라우팅, API, 접근성, 에러 처리 브랜드 톤과 탐색 아이디어
디자인 협업 Figma 파일 시각 탐색, 리뷰, 컴포넌트 토론, 화면 비교 배포된 동작의 최종 판정
AI 작업 지시 DESIGN.md, PRD, design rules 에이전트가 반복 적용할 규칙 최종 UI 품질 보증
연결 계층 Code Connect, MCP, handoff bundle 디자인-코드 번역 비용 줄이기 자동 동기화가 늘 맞는다는 착각

이 표에서 핵심은 하나다.

원본을 하나로 고집하지 말고, 각 원본이 책임지는 범위를 정해야 한다.

Figma가 강한 곳은 여전히 있다.

여러 방향을 펼쳐놓고 보고, 디자이너와 PM이 화면을 같이 만지고, 컴포넌트 단위로 토론하는 일이다.

코드가 강한 곳도 분명하다.

실제 사용자에게 나가는 상태, 접근성, 반응형, 성능, 비즈니스 로직, 에러 처리다.

DESIGN.md나 Code Connect 같은 문서/연결 계층이 강한 곳은 또 다르다.

사람이 보는 캔버스와 에이전트가 읽는 규칙 사이를 이어주는 일이다.

이 구분을 해두면 도구 논쟁이 조금 차분해진다.

Claude Design이 나왔다고 Figma를 지울 필요도 없고, Figma Make가 있다고 코드 원본을 무시할 필요도 없다.

도구보다 먼저 정해야 할 것은 책임 범위다.

왜 갑자기 source of truth 논쟁이 커졌나

source of truth 논쟁은 새롭지 않다.

디자인 시스템을 운영해본 팀이면 이미 겪은 문제다.

Figma에 있는 버튼 컴포넌트가 최신인지, React 코드의 Button이 최신인지, Storybook에 있는 예제가 최신인지, 문서 사이트에 적힌 사용법이 최신인지 헷갈린다.

처음에는 작은 불일치다.

버튼 padding이 12px인지 14px인지 정도다.

그런데 제품이 커지면 이 작은 차이가 쌓인다.

토큰 이름이 바뀌고, 컴포넌트 variant가 늘고, 다크모드가 들어오고, 모바일 breakpoint가 추가된다.

디자인 파일에서는 깔끔해 보이던 구조가 실제 코드에서는 예외 처리로 부풀기도 한다.

반대로 코드에서는 간단한 조건문인데, Figma에서는 상태별 화면을 따로 만들어야 해서 파일이 무거워지기도 한다.

AI가 들어오면서 이 문제가 더 크게 보인다.

AI 코딩 에이전트는 Figma 레이어보다 코드와 문서를 훨씬 잘 읽는다.

LLM은 HTML, CSS, React, TypeScript, README, PRD, markdown 규칙에 익숙하다.

반면 Figma 내부의 모든 디자인 primitives를 모델이 온전히 이해한다고 보긴 어렵다.

Sam Henri Gold의 2026년 4월 글이 커뮤니티에서 퍼진 이유도 여기에 있다.

그 글의 주장은 거칠지만 질문은 유효하다.

AI가 코드를 더 잘 읽는다면, 디자인의 최종 원본도 코드 쪽으로 돌아가는 것 아니냐는 질문이다.

이 주장을 그대로 믿을 필요는 없다.

커뮤니티 글은 커뮤니티 글이다.

다만 Anthropic, Figma, Google이 최근 내놓은 방향을 같이 보면, 세 회사 모두 같은 문제를 보고 있다는 건 분명하다.

디자인과 코드 사이의 번역 비용을 줄여야 한다.

다만 각자 답이 다르다.

Claude Design의 답: 코드와 대화에 가까운 디자인

Anthropic은 2026년 4월 17일 Claude Design을 Anthropic Labs 연구 프리뷰로 발표했다.

공식 발표 기준 Claude Design은 Claude Opus 4.7 기반이고, Claude Pro, Max, Team, Enterprise 구독자에게 제공된다.

핵심은 단순 이미지 생성이 아니다.

디자인, 프로토타입, 슬라이드, 원페이저 같은 시각 작업물을 Claude와 함께 만들고 다듬는 작업 공간이다.

Anthropic이 강조한 부분 중 source of truth 논쟁과 직접 연결되는 것은 세 가지다.

첫째, Claude Design은 온보딩 과정에서 코드베이스와 디자인 파일을 읽어 팀 디자인 시스템을 만든다고 설명한다.

둘째, 사용자는 텍스트 프롬프트, 이미지, 문서, 코드베이스, 웹 캡처에서 시작할 수 있다.

셋째, 결과물을 Canva, PDF, PPTX, standalone HTML, 그리고 Claude Code handoff bundle로 내보낼 수 있다.

이 방향은 꽤 선명하다.

Claude Design은 “Figma 파일을 더 잘 읽는 도구”라기보다, 코드와 문서 맥락을 디자인 작업으로 끌고 오는 도구에 가깝다.

이게 강점이 될 수 있는 상황은 이런 경우다.

상황 Claude Design이 유리한 이유
PM이 PRD를 화면으로 바꾸고 싶다 문서에서 시작해 시각 초안을 만들 수 있다
개발자가 내부 도구 UI를 빨리 잡고 싶다 코드베이스와 handoff가 같은 Claude 계열로 이어진다
마케터가 랜딩페이지 초안을 만들고 싶다 Canva, PPTX, HTML 출력이 붙어 있다
팀 디자인 시스템을 AI에게 먹이고 싶다 코드베이스와 디자인 파일을 같이 읽는 흐름을 제공한다

하지만 위험도 있다.

Claude Design이 만든 화면이 실제 제품 원본이 되는 순간, 팀은 검증 책임을 다시 정해야 한다.

AI가 만든 HTML이 예쁘다고 해서, 기존 컴포넌트 규칙을 지켰다는 뜻은 아니다.

브랜드 컬러를 비슷하게 썼다고 해서, 토큰 체계를 이해했다는 뜻도 아니다.

그래서 Claude Design을 쓸 때 내가 잡는 안전한 위치는 이렇다.

디자인 대화를 시작하는 빠른 초안 + Claude Code로 넘기는 작업 정의 보조

여기까지는 강하다.

프로덕션 디자인 시스템의 단일 원본

여기까지 가려면 아직 검증이 필요하다.

Figma Make의 답: Figma 안에 코드 맥락을 끌어오기

Figma는 정반대 방향만 가는 게 아니다.

오히려 최근 Figma의 메시지를 보면 “코드냐 캔버스냐”를 둘 중 하나로 자르지 않으려 한다.

2025년 5월 Figma Make 발표에서 Figma는 prompt-to-app 도구를 소개했다.

사용자는 기존 Figma Design 프레임을 복사해 구조와 메타데이터를 유지한 채, 자연어로 인터랙티브한 경험으로 바꿀 수 있다.

Figma는 이 흐름을 Figma 플랫폼 안의 single source of truth로 설명했다.

2026년 4월 2일에는 Make kits와 Make attachments가 추가됐다.

이 업데이트는 source of truth 논쟁에 더 직접적이다.

Figma는 AI가 만든 첫 draft가 그럴듯해도, 팀의 디자인 시스템, 실제 컴포넌트, 프로덕션 제약, 엣지 케이스가 빠지면 리뷰 비용이 커진다고 지적한다.

그래서 Make kits는 코드의 디자인 시스템 맥락을 가져온다.

npm packages, 컴포넌트, 스타일, 토큰, 사용 기준을 Make가 참고하도록 하는 방향이다.

이건 “Figma가 코드에게 밀린다”가 아니라, Figma가 코드 맥락을 Figma 안으로 끌어들이는 전략에 가깝다.

Figma Code Connect도 같은 맥락이다.

공식 개발자 문서는 Code Connect를 코드베이스와 Figma Dev Mode 사이의 bridge로 설명한다.

컴포넌트를 Figma 디자인 파일과 코드 저장소의 실제 구현에 연결하고, Figma MCP server가 AI agents에게 더 정확한 구현 정보를 제공하도록 돕는다는 설명도 있다.

즉 Figma의 답은 이렇다.

디자인 파일을 버리지 말고, 코드와 더 강하게 연결하자.

이 방향이 잘 맞는 팀은 꽤 분명하다.

팀 상황 Figma Make/Code Connect가 맞는 이유
이미 Figma 중심 디자인 시스템이 있다 기존 파일과 컴포넌트 자산을 버릴 필요가 없다
디자이너가 여러 명이고 리뷰 흐름이 있다 캔버스에서 비교, 코멘트, 반복이 쉽다
코드 컴포넌트와 디자인 컴포넌트를 연결하고 싶다 Code Connect와 MCP가 연결 계층이 된다
조직/엔터프라이즈 거버넌스가 중요하다 Figma의 권한, 파일, 협업 구조를 유지할 수 있다

물론 약점도 있다.

Figma 안에서 모든 것을 해결하려 하면, AI 에이전트가 읽기 좋은 규칙이 다시 Figma 내부에 갇힐 수 있다.

에이전트는 캔버스보다 문서와 코드를 좋아한다.

사람은 캔버스에서 잘 본다.

AI는 구조화된 텍스트와 코드에서 잘 움직인다.

이 간극을 줄이는 게 Figma의 과제다.

Google Stitch의 답: 에이전트가 읽는 디자인 규칙

Google은 2026년 3월 18일 Stitch를 AI-native software design canvas로 확장한다고 발표했다.

공식 글에서 Stitch는 자연어에서 고충실도 UI를 만들고, AI-native infinite canvas에서 아이디어를 키우며, 이미지, 텍스트, 코드까지 context로 가져올 수 있다고 설명된다.

Stitch는 static design을 interactive prototype으로 바꾸고, Play로 앱 흐름을 미리 볼 수 있다.

또 voice command와 design agent를 통해 실시간 비평과 수정도 이야기한다.

여기까지는 다른 AI 디자인 도구와 비슷하게 들릴 수 있다.

하지만 TECHTAEK 관점에서 더 흥미로운 건 마지막 연결부다.

Google은 Stitch MCP server, SDK, skills, AI Studio, Antigravity export 같은 에이전트 친화 흐름을 같이 언급한다.

이미 TECHTAEK에서 다룬 DESIGN.md 흐름도 여기와 연결된다.

DESIGN.md는 디자인 시스템을 사람이 볼 수 있는 캔버스에만 두지 않고, 에이전트가 읽을 수 있는 markdown 규칙으로 바꾸는 쪽이다.

이 접근의 장점은 명확하다.

AI 코딩 에이전트에게 “우리 제품 느낌으로 만들어줘”라고 말하는 대신, 색상, 간격, 컴포넌트 사용 규칙, 금지 패턴, 상태 처리, 브랜드 톤을 문서로 건넬 수 있다.

즉 Stitch 쪽의 답은 이렇게 볼 수 있다.

디자인 의도를 캔버스에만 두지 말고, 에이전트가 읽는 계약서로 만들자.

이건 작은 차이가 아니다.

AI 작업에서는 재현성이 중요하다.

한 번 예쁜 결과물이 나온 것보다, 다음 화면에서도 같은 규칙이 반복되는지가 더 중요하다.

DESIGN.md나 design rules가 제대로 작동하면, 에이전트는 매번 감으로 UI를 만들지 않고, 정해진 디자인 규칙을 따라 작업할 수 있다.

물론 이것도 만능은 아니다.

문서화된 디자인 규칙은 시각적 판단을 완전히 대체하지 못한다.

색상 대비, 공간감, 정보 위계, 감정적인 브랜드 톤은 여전히 사람이 봐야 한다.

하지만 AI에게 반복 작업을 맡기려면, 문서화된 규칙은 꽤 강한 무기가 된다.

세 도구를 같은 표에 놓으면

이제 Claude Design, Figma Make, Stitch를 같은 표에 놓아보자.

기능 목록이 아니라 source of truth 관점으로 보는 표다.

기준 Claude Design Figma Make/Code Connect Google Stitch/DESIGN.md
기본 출발점 대화, 문서, 이미지, 코드베이스 Figma 프레임, 디자인 시스템, 파일 맥락 자연어, 이미지, 텍스트, 코드, 캔버스
원본 철학 Claude와 코드 handoff 중심 Figma 캔버스와 코드 연결 AI-native canvas + 에이전트 규칙
강한 사용자 PM, 개발자, 마케터, 창업자 디자이너, 디자인 시스템 팀, 제품 조직 1인 개발자, 에이전트 운영자, 빠른 UI 탐색팀
코드 연결 Claude Code handoff bundle Code Connect, MCP, npm package kits MCP server, SDK, skills, export
디자인 시스템 접근 코드베이스와 디자인 파일을 읽어 구성 Figma library, Make kits, code components DESIGN.md와 context rules로 문서화
좋은 쓰임 PRD를 화면과 구현 지시로 바꾸기 기존 Figma 중심 조직의 AI 확장 에이전트에게 반복 디자인 규칙 주기
위험 생성물이 팀 컴포넌트를 무시할 수 있음 Figma 내부 복잡성이 계속 커질 수 있음 문서 규칙만으로 시각 품질을 보장하기 어려움

이 표만 보면 셋이 완전히 경쟁하는 것처럼 보인다.

실제로는 겹치기도 하고, 각자 다른 단계에 들어갈 수도 있다.

예를 들어 작은 팀은 이렇게 쓸 수 있다.

  1. Stitch나 Claude Design으로 빠르게 방향을 만든다.
  2. 괜찮은 방향을 Figma로 가져가서 디자이너가 정리한다.
  3. Code Connect나 DESIGN.md로 컴포넌트 규칙을 문서화한다.
  4. Claude Code나 Codex 같은 에이전트가 실제 코드 작업을 한다.
  5. 최종 동작은 프로덕션 코드와 Storybook에서 검증한다.

이 루트에서는 어느 도구도 단독 왕이 아니다.

각자 지나가는 관문이다.

문제는 왕좌가 아니라 책임 분리다.

그러면 Figma 파일은 원본이 아니게 되나

바로 그렇게 말하면 과하다.

Figma 파일은 여전히 강한 원본이다.

특히 사람이 보는 시각적 판단에서는 그렇다.

화면 A와 B를 나란히 비교하고, 디자이너가 spacing을 조정하고, PM이 정보 우선순위를 확인하고, 개발자가 컴포넌트 의도를 확인하는 과정은 캔버스가 잘한다.

코드는 실제 제품의 원본이다.

그러나 코드는 시각적 탐색에는 답답할 수 있다.

브라우저를 띄워야 하고, 상태를 만들어야 하고, 작은 디자인 방향을 비교하려면 변경과 실행을 반복해야 한다.

그때 Figma는 여전히 빠르다.

다만 Figma가 모든 원본이어야 한다는 생각은 흔들린다.

특히 이미 프로덕션 코드가 빠르게 바뀌는 팀에서는, Figma가 실제 화면을 따라가지 못할 수 있다.

AI 코딩 에이전트가 하루에도 여러 화면을 만들고 고치면, 디자인 파일을 매번 손으로 역동기화하는 일은 금방 피곤해진다.

그래서 앞으로는 이렇게 나눠 보는 게 현실적이다.

질문 원본으로 봐야 할 곳
실제 배포된 UI는 무엇인가 프로덕션 코드
다음 방향을 비교하는 곳은 어디인가 Figma 또는 AI design canvas
에이전트가 따라야 할 디자인 규칙은 무엇인가 DESIGN.md, design rules, Code Connect
컴포넌트의 실제 prop과 동작은 어디에 있는가 코드, Storybook, 테스트
조직이 합의한 시각 언어는 어디에 남기는가 Figma library + 문서화된 규칙

여기서 중요한 건 “하나만 고르기”가 아니다.

각 질문마다 원본이 다를 수 있음을 인정하는 것이다.

이걸 인정하지 않으면 회의가 길어진다.

디자이너는 Figma가 맞다고 하고, 개발자는 코드가 맞다고 하고, PM은 마지막으로 본 데모가 맞다고 하고, AI는 오래된 문서를 보고 또 다른 화면을 만든다.

아름다운 혼돈이다.

물론 아름답다고 했지 좋다고는 안 했다.

실무 체크리스트: 우리 팀은 어디에 원본을 둬야 하나

도구 이름보다 먼저 팀 상태를 봐야 한다.

아래 질문에 답하면 방향이 빨리 잡힌다.

1. 프로덕션 코드와 Figma가 자주 어긋나는가

자주 어긋난다면 코드 쪽 원본성을 높여야 한다.

Figma를 버리라는 뜻은 아니다.

Figma에 있는 컴포넌트와 실제 코드 컴포넌트를 연결하거나, Storybook, Code Connect, design token 문서를 강화해야 한다.

이 상태에서 AI 디자인 도구만 추가하면 어긋남이 더 빨라질 수 있다.

빠른 생성은 빠른 불일치도 만든다.

2. 디자이너가 없는 팀인가

디자이너가 없다면 Claude Design이나 Stitch의 가치가 커진다.

첫 화면을 만들고, 정보 구조를 잡고, PM이나 개발자가 대화 가능한 시각 물체를 만드는 데 도움이 된다.

하지만 이 경우에는 DESIGN.md나 간단한 디자인 규칙 문서가 더 중요해진다.

사람 디자이너가 없을수록 AI에게 줄 규칙은 더 명확해야 한다.

규칙 없이 “예쁘게”라고 하면 보통 평균적인 SaaS 회색 화면이 온다.

세상에 회색 SaaS가 하나 더 태어나는 순간이다.

3. 이미 Figma 디자인 시스템이 크고 복잡한가

이미 Figma library와 디자인 시스템이 크다면 Figma Make, Make kits, Code Connect 쪽을 먼저 봐야 한다.

기존 자산을 버리고 새 도구로 갈 이유가 없다.

오히려 해야 할 일은 연결이다.

Figma 컴포넌트가 실제 코드 컴포넌트와 어떻게 연결되는지, AI가 어떤 컴포넌트를 써야 하는지, 어떤 variant는 쓰면 안 되는지 정리해야 한다.

이 팀에서 Claude Design은 초기 탐색이나 외부 산출물 생성에는 좋을 수 있다.

하지만 핵심 source of truth를 바로 넘기기는 부담스럽다.

4. AI 코딩 에이전트가 이미 코드를 자주 고치는가

이 경우에는 디자인 규칙을 markdown이나 코드 근처에 두는 편이 유리하다.

Codex, Claude Code, Cursor, Gemini CLI 같은 도구가 실제 레포에서 움직인다면, 에이전트가 읽을 수 있는 문서가 필요하다.

DESIGN.md, AGENTS.md, README.md, Storybook docs, component usage examples가 여기에 해당한다.

Figma 파일만 원본으로 두면 에이전트가 계속 추측한다.

추측은 빠르다.

그리고 가끔 아주 자신 있게 틀린다.

5. 최종 리뷰는 누가 하는가

이 질문이 제일 중요하다.

AI design workflow에서 source of truth는 파일이 아니라 책임 구조이기도 하다.

누가 최종 UI 품질을 본다.

누가 접근성을 본다.

누가 컴포넌트 사용을 승인한다.

누가 코드와 디자인 불일치를 정리한다.

이 네 가지가 없으면 어떤 도구를 써도 흔들린다.

Claude Design이든 Figma Make든 Stitch든 결국 리뷰 책임은 사람에게 남는다.

내가 추천하는 3단 운영 모델

현재 시점에서 가장 현실적인 모델은 3단 운영이다.

1단: 캔버스는 탐색 원본

Figma, Claude Design, Stitch 같은 캔버스는 탐색 원본으로 둔다.

새 기능 방향, 여러 레이아웃, 마케팅 페이지 초안, 회의용 프로토타입을 여기서 빠르게 만든다.

이 단계에서는 속도가 중요하다.

정확도보다 비교 가능성이 더 중요하다.

한 가지 안을 끝까지 다듬기보다, 세 가지 방향을 빨리 놓고 팀이 판단하는 편이 낫다.

2단: 문서는 에이전트 원본

DESIGN.md, PRD, component rules, Code Connect mapping, Storybook examples는 에이전트 원본으로 둔다.

AI가 반복 적용해야 할 규칙은 캔버스보다 문서에 더 잘 맞는다.

예를 들어 이런 식이다.

## Buttons

- Primary action은 화면당 1개만 사용한다.
- destructive action은 빨간색 토큰만 쓰고 confirm dialog를 붙인다.
- loading 상태에서는 label을 유지하고 spinner를 오른쪽에 둔다.
- mobile에서는 full-width button을 우선한다.

이 규칙은 사람에게도 좋고 AI에게도 좋다.

Figma에서 눈으로 봐야 할 것은 시각적 균형이다.

AI가 반복해야 할 것은 규칙이다.

둘을 같은 곳에 억지로 넣으면 둘 다 애매해진다.

3단: 코드는 제품 원본

마지막 원본은 코드다.

사용자가 실제로 만지는 것은 Figma 파일이 아니라 배포된 제품이다.

그래서 최종 동작, 접근성, 반응형, 성능, 상태 처리, 데이터 바인딩은 코드에서 검증해야 한다.

AI가 만든 디자인이 아무리 좋아 보여도, 실제 코드에서 깨지면 그건 아직 원본이 아니다.

이때 필요한 검증은 이런 것들이다.

검증 항목 확인 방법
컴포넌트 재사용 새로 만든 div 덩어리인지 기존 컴포넌트인지 diff 확인
접근성 label, focus, keyboard navigation, contrast 확인
반응형 mobile, tablet, desktop viewport 확인
상태 처리 loading, empty, error, permission 상태 확인
디자인 토큰 hardcoded color/spacing이 많은지 확인
리뷰 비용 사람이 고친 줄 수와 되돌린 변경 수 기록

이 표를 통과해야 “AI 디자인이 실무에 들어왔다”고 말할 수 있다.

그 전까지는 멋진 초안이다.

멋진 초안은 좋다.

다만 초안은 초안이다.

실수 TOP

실수 1. Claude Design 결과물을 바로 최종 디자인으로 보는 것

Claude Design은 빠른 초안에 강할 수 있다.

하지만 빠르다는 말은 검증을 생략해도 된다는 뜻이 아니다.

특히 팀 컴포넌트, 접근성, 반응형, empty/error state는 따로 봐야 한다.

이 검증이 없으면 “화면은 예쁜데 제품에 못 넣는” 결과가 나온다.

AI 디자인 도구의 첫 번째 함정은 감탄이다.

첫 화면이 그럴듯하면 사람은 검증을 늦춘다.

그때부터 빚이 쌓인다.

실수 2. Figma를 낡은 도구로만 보는 것

Figma는 여전히 강하다.

특히 여러 사람이 동시에 보고, 코멘트를 달고, 디자인 시스템을 운영하고, 시각적 방향을 비교하는 작업에서는 캔버스가 필요하다.

AI 에이전트가 코드를 잘 읽는다고 해서, 사람이 시각적으로 탐색하는 공간이 사라지는 건 아니다.

코드가 source of truth가 되는 영역과, Figma가 협업 원본이 되는 영역을 나눠야 한다.

둘을 싸움 붙이면 팀만 피곤해진다.

실수 3. DESIGN.md를 색상표로만 만드는 것

DESIGN.md를 만든다면 색상, 폰트, spacing만 넣으면 부족하다.

AI가 진짜로 필요한 건 사용 규칙이다.

언제 primary button을 쓰는지, 언제 card layout을 피해야 하는지, 모바일에서는 어떤 순서로 정보를 접는지, empty state 문구는 어떤 톤인지, 금지해야 할 UI 패턴은 무엇인지가 필요하다.

토큰은 재료다.

규칙은 요리법이다.

토큰만 주고 좋은 화면을 기대하면, AI는 재료를 다 꺼내놓고 이상한 비빔밥을 만들 수 있다.

실수 4. Code Connect나 MCP를 자동 동기화 마법으로 보는 것

Code Connect, MCP, handoff bundle은 연결 계층이다.

연결은 강력하지만 마법은 아니다.

컴포넌트 매핑이 틀리면 AI도 틀린 맥락을 받는다.

문서가 오래됐으면 에이전트도 오래된 규칙을 따른다.

실제 코드가 레거시 예외로 가득하면, AI는 그 예외까지 “팀 스타일”이라고 배울 수 있다.

그래서 연결 계층을 도입할 때는 정리 작업이 먼저다.

쓰지 않는 컴포넌트, deprecated variant, 중복 토큰, 옛날 layout pattern을 표시해야 한다.

AI는 정리된 조직에서는 빠르다.

정리 안 된 조직에서는 빠르게 헷갈린다.

언제 무엇을 선택할까

간단히 고르면 이렇게 볼 수 있다.

지금 하고 싶은 일 먼저 볼 도구
PRD를 화면 초안으로 바꾸고 Claude Code로 넘기고 싶다 Claude Design
기존 Figma 디자인 시스템을 유지하면서 AI 생성을 붙이고 싶다 Figma Make + Make kits
코드 컴포넌트와 Figma 컴포넌트를 연결하고 싶다 Figma Code Connect
에이전트가 읽을 디자인 규칙을 만들고 싶다 DESIGN.md
텍스트/이미지/코드 맥락으로 빠르게 UI 방향을 보고 싶다 Google Stitch
최종 제품 동작과 상태를 검증하고 싶다 코드 + Storybook + 테스트

나처럼 블로그와 자동화 파이프라인을 같이 굴리는 입장에서는, 당장 가장 실용적인 조합은 이쪽이다.

  1. DESIGN.md로 디자인 규칙을 문서화한다.
  2. Claude Design이나 Stitch로 화면 방향을 빠르게 본다.
  3. 괜찮은 방향만 Figma나 코드로 옮긴다.
  4. Claude Code/Codex에는 DESIGN.md와 컴포넌트 규칙을 같이 준다.
  5. 최종 diff에서 기존 컴포넌트 재사용률을 본다.

이 루트가 좋은 이유는 단순하다.

AI가 잘하는 것과 사람이 잘하는 것을 분리한다.

AI는 초안과 반복 규칙 적용에 강하다.

사람은 방향 판단과 품질 리뷰에 강하다.

코드는 최종 동작의 원본이다.

Figma는 시각적 합의의 원본이다.

문서는 AI 협업 규칙의 원본이다.

이 셋을 구분하면 논쟁이 줄어든다.

작은 팀용 source of truth 운영표

작은 팀이라면 아래처럼 시작하면 충분하다.

항목 원본 위치 최소 운영 규칙
브랜드 컬러와 typography DESIGN.md + Figma styles 바뀌면 둘 다 업데이트
컴포넌트 사용법 Storybook 또는 component docs props, 상태, 금지 예시를 남김
화면 탐색안 Figma 또는 Claude Design/Stitch 최종안이 아니라 비교안으로 표시
실제 구현 Git repository 배포된 UI가 최종 동작 원본
AI 지시 규칙 AGENTS.md, DESIGN.md, PRD 에이전트가 반복 적용할 문장으로 작성
리뷰 로그 PR, issue, changelog 왜 바꿨는지 남김

이 표에서 제일 자주 빠지는 것은 리뷰 로그다.

AI가 화면을 빠르게 만들수록, 왜 이 방향을 골랐는지 기록하지 않으면 다음 사람이 다시 같은 결정을 반복한다.

그리고 그 다음 사람이 AI일 수도 있다.

AI에게도 기억은 공짜가 아니다.

기록을 남겨야 다음 작업이 덜 흔들린다.

2026년 4월 21일 색인 리프레시 링크맵

2026년 4월 21일 아침 분석 보드에서 이 글은 1일차 기준 노출 0, PV 0으로 잡혔다.

새 글을 하나 더 쓰기보다 먼저 해야 할 일은 내부 경로를 다시 여는 것이었다.

이 글은 도구 뉴스 하나를 설명하는 글이 아니다.

Claude Design, Figma Make, Google Stitch, DESIGN.md를 한 테이블에 올려놓고 디자인 원본을 어디에 둘 것인가를 묻는 허브 글이다.

그래서 오늘 리프레시는 본문을 늘리는 작업보다 링크 지도를 고치는 작업에 가깝다.

들어오는 글 독자의 직전 질문 이 글로 넘기는 문장
Claude Design이 Figma를 바로 대체하긴 어려운 이유 Claude Design이 정말 Figma를 밀어낼까 대체 여부보다 먼저 source of truth가 어디에 남는지 확인해야 한다
DESIGN.md 2026 디자인 규칙도 문서로 빼야 할까 DESIGN.md가 규칙 문서라면, Figma와 코드는 각각 어떤 책임을 가져야 할까
CLAUDE.md commands skills agents 운영 분리 에이전트가 읽는 문서는 어디까지 나눠야 할까 개발 규칙 문서와 디자인 규칙 문서를 분리하면 source of truth 충돌을 줄일 수 있다

이 구조에서는 Figma가 사라진다는 식의 결론을 내리면 오히려 약해진다.

현실적인 결론은 더 단순하다.

Figma는 시각 합의의 원본으로 남을 수 있다.

코드는 실행 결과의 원본이다.

DESIGN.md나 AGENTS.md 같은 문서는 AI가 반복해서 읽는 의도 원본이 된다.

이 셋을 한 문장으로 뭉개면 팀은 다시 회의로 돌아간다.

반대로 셋의 책임을 분리하면, AI 도구가 바뀌어도 운영 규칙은 덜 흔들린다.

오늘 꽂은 내부 링크의 목적도 여기에 있다.

Claude Design 글에서 들어온 독자는 대체 가능성을 보다가 이 글에서 원본 책임표를 확인한다.

DESIGN.md 글에서 들어온 독자는 문서화 필요성을 보다가 이 글에서 Figma, 코드, 문서의 경계를 확인한다.

도구 뉴스는 빨리 늙는다.

원본 책임표는 오래 간다.

내가 이 글을 새 글로 살린 이유

사실 이 주제는 위험했다.

이미 TECHTAEK에는 Claude Design 글이 있다.

Google Stitch와 DESIGN.md 글도 있다.

그 상태에서 “Claude 사용법” 같은 제목으로 새 글을 쓰면 중복이 된다.

그래서 이번 글감은 한 번 드롭하고 다시 각도를 잡았다.

살린 포인트는 기능 설명이 아니라 source of truth다.

이건 기존 글과 질문이 다르다.

기존 Claude Design 글은 Figma를 대체하나, 워크플로우로 어떻게 검증하나에 가까웠다.

이번 글은 디자인 원본을 어디에 둬야 하나다.

이 차이가 있어야 글을 새로 낼 이유가 생긴다.

TECHTAEK에서는 이런 구분이 중요하다.

AI 도구 뉴스는 매일 나온다.

뉴스마다 새 글을 쓰면 금방 얇아진다.

대신 같은 뉴스에서도 실무자가 실제로 결정해야 하는 질문을 하나만 뽑아야 한다.

이번 질문은 이거다.

우리 팀의 source of truth는 Figma 파일인가, 코드인가, 아니면 에이전트가 읽는 문서인가.

이 질문은 2026년 내내 계속 남을 가능성이 높다.

그래서 글로 살릴 만하다.

FAQ

Claude Design이 나오면 Figma를 안 써도 되나

아직 그렇게 보기 어렵다.

Claude Design은 빠른 초안, 문서에서 화면으로 가는 흐름, Claude Code handoff에 강점이 있다.

반면 Figma는 디자인 리뷰, 컴포넌트 협업, 시각적 비교, 디자인 시스템 운영에서 여전히 강하다.

두 도구는 당장 대체 관계라기보다 단계가 다른 도구로 보는 편이 안전하다.

Figma Make는 코드 source of truth 흐름에 밀리는 건가

꼭 그렇지는 않다.

Figma는 Make kits, Make attachments, Code Connect, MCP를 통해 코드 맥락을 Figma 안으로 가져오려 한다.

즉 Figma의 전략은 “코드를 무시하자”가 아니라 “캔버스와 코드를 연결하자”에 가깝다.

이미 Figma 중심 디자인 시스템이 큰 팀이라면 이 방향이 더 현실적일 수 있다.

DESIGN.md는 Figma를 대체하나

아니다.

DESIGN.md는 시각적 캔버스가 아니라 디자인 규칙 문서에 가깝다.

Figma는 사람이 보고 비교하는 곳이고, DESIGN.md는 AI와 개발자가 반복 적용할 규칙을 읽는 곳이다.

둘은 대체보다 보완 관계다.

코드가 source of truth라면 디자이너 역할은 줄어드나

단순히 줄어든다고 보면 위험하다.

코드가 실제 제품 동작의 원본이 될 수는 있지만, 무엇이 좋은 사용자 경험인지 판단하는 일은 여전히 사람의 몫이다.

오히려 디자이너의 역할은 픽셀 생산에서 시스템 판단, 품질 리뷰, 탐색 방향 설계로 이동할 가능성이 크다.

작은 팀은 뭘 먼저 해야 하나

처음부터 거대한 디자인 시스템을 만들 필요는 없다.

작은 팀은 DESIGN.md나 짧은 design rules 문서부터 만들면 된다.

색상과 폰트보다 더 중요한 것은 사용 규칙이다.

버튼, 카드, 폼, empty state, error state, mobile layout 기준을 짧게 적어두면 AI 코딩 에이전트에게 바로 도움이 된다.

AI가 만든 화면을 바로 코드로 넣어도 되나

프로토타입은 가능하지만 프로덕션은 검증이 필요하다.

기존 컴포넌트 재사용, 접근성, 반응형, 상태 처리, hardcoded style, 테스트 누락을 봐야 한다.

AI 디자인 결과물은 시작점을 빠르게 만들 수 있지만, 최종 품질 책임까지 자동으로 가져가지는 않는다.

source of truth를 하나로 정해야 하나

하나로 정하면 깔끔해 보인다.

하지만 실무에서는 질문별로 원본을 나누는 편이 낫다.

실제 동작은 코드, 시각 협업은 Figma, AI 반복 규칙은 DESIGN.md나 component docs, 연결 정보는 Code Connect나 MCP처럼 구분하는 방식이다.

이렇게 해야 도구가 늘어도 팀이 덜 흔들린다.

공식 출처

관련 글

정리하면 이렇다.

Figma는 끝난 게 아니다.

코드가 모든 것을 삼키는 것도 아니다.

하지만 AI가 디자인과 개발 사이에 들어오면서, source of truth는 더 이상 한 파일 안에 조용히 앉아 있기 어렵다.

사람이 보는 원본, AI가 읽는 원본, 제품이 실행되는 원본을 나눠야 한다.

그 구분을 못 하면 도구가 많아질수록 팀은 더 느려진다.

반대로 이 구분을 해두면, Claude Design, Figma Make, Google Stitch는 서로 싸우는 도구가 아니라 각 단계에서 쓸 수 있는 작업 도구가 된다.

2026년의 디자인 워크플로우는 “어떤 툴이 이기나”보다 “어떤 원본을 어디에 둘 것인가”로 갈 가능성이 크다.

이 질문을 먼저 잡는 팀이 AI 디자인 도구를 덜 흔들리게 쓸 것이다.