AI 시대 디자이너의 새 워크플로우 (2편)

AI 시대 디자이너의 새 워크플로우

구독자님, 반가워요. 지은이에요. ☕

지난 호에서는 "협업 문서 3종 세트" 중 첫 번째, UX 화면 설계서를 다뤘어요.

13호에서 제가 제일 강조하고 싶은 문장은 이거예요.

AI를 잘 쓰는 디자이너는

AI에게 모든 걸 맡기는 사람이 아니라,

AI가 어디서 멈춰야 하는지 아는 사람이거든요.

오늘은 그 다음 이야기예요.

이번 호에서는 협업 문서 3종 세트 중 두 번째, UI 가이드를 다뤄보려고 해요.

예전에는 UI 가이드가 주로 사람을 위한 기준이었어요.

형태는 팀마다 달랐습니다.

어떤 팀은 노션이나 컨플루언스에 따로 정리했고,

어떤 팀은 Figma 파일 안에 가이드 페이지를 만들어서 그걸 UI 가이드처럼 사용했어요.

사실 작은 팀이나 1인 디자이너에게는 후자의 방식이 훨씬 현실적입니다.

원본 컴포넌트와 가이드가 같은 파일 안에 있으니까 업데이트도 빠르고, 관리할 문서도 줄어들거든요.

중요한 건 "노션에 있느냐, Figma에 있느냐"가 아니에요.

팀이 같은 기준을 보고 있는가.

그리고 그 기준을 사람뿐 아니라 AI도 이해할 수 있는 구조로 정리해두었는가.

AI 시대의 UI 가이드는 바로 여기서 달라집니다.

오늘은 이걸 중심으로 이야기해볼게요.

1. AI 시대의 UI 가이드, 뭐가 달라졌을까?

예전에는 UI 가이드가 주로 사람을 위한 문서였어요.

디자이너가 보고,

개발자가 보고,

가끔 PM이 보고,

가끔은 아무도 안 보고...🫠

보통 이런 내용이 들어가죠.

그런데 요즘은 여기에 독자가 하나 더 생겼어요.

바로 AI예요.

Claude, ChatGPT, Cursor, V0, Figma MCP 같은 도구들은 모두 "맥락"을 필요로 해요.

같은 프롬프트를 넣어도

우리 제품의 컬러, 컴포넌트 구조, 버튼 규칙, 카피 톤을 알고 있느냐에 따라 결과물이 완전히 달라지거든요.

예를 들어볼게요.

그냥 이렇게 말하면

AI는 아주 평범한 회원가입 화면을 만들어줄 거예요.

어디선가 본 듯한, 무난한, 평균적인 화면이요.

그런데 이렇게 말하면 달라져요.

이제 AI는 단순히 "회원가입 화면"을 만드는 게 아니라,

우리 제품의 규칙 안에서 화면을 만들기 시작합니다.

여기서 중요한 개념이 바로 DESIGN.md예요.

2. DESIGN.md, 그게 뭔가요?

쉽게 말하면 DESIGN.md는

디자인 시스템의 핵심 규칙을 Markdown으로 정리한 문서예요.

컬러, 타이포, 컴포넌트, 패턴, 카피 톤처럼

제품 UI를 만들 때 반복해서 참고해야 하는 기준을 텍스트로 정리한 파일이죠.

"그거 그냥 노션 가이드랑 같은 거 아닌가요?"

맞아요. 겉으로 보면 비슷해요.

하지만 쓰임이 달라요.

여기서 조심해야 할 점도 있어요.

DESIGN.md가 갑자기 모든 디자인 시스템의 "진짜 원본"이 되는 건 아니에요.

실제 원본은 여전히 Figma Variables, 컴포넌트, 코드 토큰, Storybook, 운영 문서에 있을 수 있어요.

그래서 DESIGN.md는 이렇게 이해하는 게 가장 정확합니다.

조금 쉽게 말하면

AI에게 "우리 집 규칙은 이거야" 하고 건네주는 안내문이에요.

AI도 정리된 집에서는 길을 덜 잃어요.

어질러진 방에서는 사람도 양말 못 찾잖아요. 🫠

DESIGN.md 자체가 핸드오프 문서는 아닙니다.

다만 DESIGN.md가 잘 정리되어 있으면,

AI가 화면을 만들거나 코드를 생성하거나 핸드오프 노트를 초안으로 정리할 때

더 정확한 기준을 참고할 수 있습니다.

즉, DESIGN.md는 결과물이 아니라 입력값입니다.

핸드오프 문서가 아니라, AI에게 주는 디자인 컨텍스트입니다.

3. AI 시대의 디자인 프로세스는 이렇게 달라집니다

지난 호에서 이런 이야기를 했었죠.

이 프레임을 UI 가이드에 적용하면 이렇게 볼 수 있어요.

우리가 집중할 부분은 세 번째와 네 번째예요.

예전에는 이런 순서가 많았어요.

너무 현실적이라 마음이 아프네요. 🥲

AI 시대에는 순서를 조금 바꿔야 해요.

이 말이 "문서를 먼저 쓰고 화면을 나중에 그리자"는 뜻은 아니에요.

핵심은 이거예요.

컴포넌트 이름이 일관되고,

Variables가 역할 기반으로 연결되어 있고,

State가 빠짐없이 정의되어 있고,

Description에 사용 맥락이 적혀 있다면,

그 Figma는 사람이 보기에도 좋고 AI가 읽기에도 좋은 파일이 됩니다.

4. AI가 읽기 좋은 Figma를 만드는 5가지 원칙

그럼 실제로 Figma에서 무엇을 정리해야 할까요?

오늘은 딱 5가지만 가져가 보세요.

1) 네이밍을 일관되게 정리하기

AI는 패턴을 읽어요.

그런데 이름이 제각각이면 패턴을 못 잡습니다.

예를 들어 버튼 이름이 이렇게 되어 있다고 해볼게요.

디자이너는 대충 알아볼 수 있어요.

"아, 다 버튼이구나."

그런데 AI나 개발자 입장에서는 이게 같은 시스템 안의 컴포넌트인지,

각각 다른 용도인지 헷갈릴 수 있어요.

그래서 이름은 한 가지 규칙으로 맞추는 게 좋아요.

또는 조금 더 구조화한다면 이렇게요.

중요한 건 멋진 이름이 아니에요.

계속 같은 규칙으로 이름 짓는 것입니다.

AI는 천재처럼 보이지만, 사실 이런 반복 규칙에 꽤 의존합니다.

규칙이 없으면 AI도 "음... 감으로 가볼게요?" 모드가 됩니다.

그건 무섭죠. 디자이너도 감으로 가면 야근인데,

AI까지 감으로 가면 지옥문이 열립니다.

2) Primitive → Semantic Variables 2단 구조로 만들기

이건 조금 어려워 보일 수 있지만, 한 번만 이해하면 정말 편해져요.

디자인 토큰은 크게 두 단계로 나눠볼 수 있어요.

Primitive Variables

실제 색상값이에요.

Semantic Variables

왜 이렇게 나눌까요?

예를 들어 브랜드 컬러가 파란색에서 보라색으로 바뀌었다고 해볼게요.

만약 화면 곳곳에 blue/500을 직접 써두었다면, 나중에 이런 이상한 일이 생겨요.

이름과 실제 의미가 어긋납니다.

보기만 해도 찝찝하죠.

반대로 color/action/primary 처럼 의미 기반으로 연결해두면, 브랜드 컬러가 바뀌어도 이름은 그대로 유지할 수 있어요.

사용 목적은 그대로고, 연결된 색만 바뀌는 거예요.

AI 입장에서도 이 구조가 훨씬 좋아요.

blue/500만 보면 어디에 쓰는 색인지 모르잖아요.

하지만 color/action/primary를 보면 이렇게 이해할 수 있죠.

이름에 의미가 담기는 순간,

토큰은 단순한 값이 아니라 문서가 됩니다.

3) Component Properties로 조합 가능한 구조 만들기

버튼 컴포넌트를 만들 때 이런 식으로 Variant를 잔뜩 늘어놓은 경험 있으시죠?

처음에는 괜찮아요.

그런데 조금만 커지면 컴포넌트가 괴물이 됩니다.

버튼 하나 찾으려다 정글 탐험하게 되는 거죠.

AI가 읽기에도 좋지 않습니다.

그래서 컴포넌트는 가능한 한 속성을 분리해서 조합 가능하게 만드는 게 좋아요.

예를 들어 버튼이라면 이렇게요.

여기서 중요한 건 "Variant를 쓰지 말자"가 아니에요.

정확히는 이거예요.

이렇게 나눠두면 좋은 점이 있어요.

사람도 이해하기 쉽고,

개발자도 구현 구조를 예측하기 쉽고,

AI도 "이 컴포넌트는 어떤 조합이 가능한지" 더 잘 읽습니다.

디자인 시스템은 결국 선택지를 늘리는 작업이 아니라,

선택지를 통제하는 작업이에요.

4) State를 빠뜨리지 않기

주니어 때 가장 많이 놓치는 게 State예요.

화면을 예쁘게 만들었는데, 개발자가 꼭 이런 질문을 합니다.

그때 마음속으로 생각하죠.

하지만 미래의 나는 보통 바쁩니다.

그리고 지금의 개발자는 기다리고 있죠. 🥲

최소한 인터랙티브 요소에는 이 State를 챙겨주세요.

특히 Focus는 접근성과 연결돼요.

마우스를 쓰지 않고 Tab 키로 이동하는 사용자에게

지금 어디에 포커스가 있는지 보여줘야 하거든요.

버튼, 인풋, 링크, 체크박스, 드롭다운처럼 사용자가 조작하는 요소라면

"기본 상태"만으로는 부족합니다.

State가 빠진 디자인 시스템은

비 오는 날 우산 없이 나간 것과 비슷해요.

처음엔 괜찮은데,

나중에 반드시 젖습니다. ☔️

5) Description 필드에 사용 맥락 적기

Figma에는 컴포넌트, 스타일, 변수에 설명을 적을 수 있는 Description 필드가 있어요

많은 파일에서 이 칸이 비어 있죠.

그런데 AI 시대에는 이 빈칸이 생각보다 유용해요.

예를 들어 Primary Button 설명을 이렇게 적어둘 수 있죠.

이 설명이 중요한 이유는,

컴포넌트의 "모양"이 아니라 "의도"를 알려주기 때문이에요.

물론 이 한 줄이 자동으로 DESIGN.md에 들어간다고 단정하면 안 돼요.

도구와 워크플로우에 따라 다르거든요.

하지만 AI에게 컴포넌트 설명을 함께 넘기면,

AI가 컴포넌트의 역할을 추측하지 않아도 됩니다.

AI의 추측을 줄이는 것.

이게 AI 활용의 핵심이에요.

AI는 그럴듯하게 틀리는 데 재능이 있거든요.

그 재능을 굳이 깨워주지 않아도 됩니다. 😇

5. 그래서 DESIGN.md에는 무엇이 들어가야 할까?

이제 정리된 Figma 파일이 있다고 가정해볼게요.

그럼 AI와 사람이 함께 참고할 수 있는 DESIGN.md에는 무엇이 들어가면 좋을까요?

크게 여섯 가지로 잡으면 됩니다.

하나씩 보면 어렵지 않아요.

1) Overview

이 디자인 시스템이 어떤 제품을 위한 것인지 한 줄로 정리합니다.

AI에게도 제품 맥락을 먼저 알려줘야 해요.

"누구를 위한 제품인지"가 없으면

AI는 또 평균의 바다로 떠내려갑니다. ⛵️

2) Foundation

기본 시각 규칙입니다.

여기서는 값만 적는 게 아니라, "어디에 쓰는지"까지 적어야 해요.

숫자만 있으면 표고,

맥락이 있으면 가이드가 됩니다.

3) Tokens

Primitive와 Semantic을 구분해서 적습니다.

여기서 중요한 건 Semantic 기준으로 설명하는 거예요.

AI에게도, 개발자에게도

"이 색이 어디에 쓰이는지"가 더 중요합니다.

4) Components

컴포넌트별로 이런 내용을 정리합니다.

예를 들어 버튼이라면 이렇게요.

여기서 [확인 필요]가 나왔죠.

이건 뒤에서 다시 자세히 볼게요.

5) Patterns

컴포넌트 하나가 아니라 여러 요소가 함께 쓰이는 반복 패턴입니다.

예를 들어 이런 것들이 있어요.

실무에서 컴포넌트보다 패턴이 더 중요할 때가 많아요.

버튼 하나는 잘 만들어도,

폼 에러가 어디에 뜨는지 정하지 않으면 핸드오프에서 질문이 들어옵니다.

여기서는 [확인 필요]와 [검증 필요]가 같이 나와요.

둘의 차이가 중요합니다.

6) Voice & Microcopy

디자인 시스템은 화면 규칙만 담는 게 아니에요.

제품이 사용자에게 어떤 말투로 말할지도 담아야 합니다.

예를 들면 이런 식이에요.

작은 문구 하나가 제품의 인상을 만듭니다.

AI에게 마이크로카피를 요청할 때도 

이 기준이 있으면 결과물이 훨씬 좋아요.

6. [확인 필요]와 [검증 필요]를 구분하세요

지난 호에서는 [확인 필요]를 강조했어요.

정책을 AI가 마음대로 확정하지 않게 하는 장치였죠.

이번 UI 가이드에서는 한 가지를 더 추가하면 좋아요.

바로 [검증 필요]예요.

둘은 이렇게 다릅니다.

예를 들어볼게요.

이건 사람이 결정해야 해요.

우리 제품에서 정말 Primary Button을 한 화면에 하나만 쓸지,

예외를 허용할지 정해야 하거든요.

반면 이건 다릅니다.

이건 누군가의 취향으로 정하는 게 아니에요.

실제 색상값을 넣고 계산해야 합니다.

또 이런 것도 [검증 필요]예요.

이 구분이 왜 중요할까요?

AI가 만든 문서를 검토할 때

우리가 해야 할 일이 둘로 나뉘기 때문이에요.

이렇게 나누면 AI 문서가 그냥 "그럴듯한 정리"에서 끝나지 않고,

실제 협업에 쓸 수 있는 체크리스트가 됩니다.

AI가 초안을 만들고,

사람이 기준을 세우고,

검증으로 신뢰를 채우는 구조예요.

7. AI로 DESIGN.md 초안 만들기

그럼 실제로 어떻게 만들 수 있을까요?

이번 호에서는 가장 가벼운 방법만 다룰게요.

Figma MCP 직접 연결은 다음 호에서 더 깊게 다루고,

오늘은 Figma Variables JSON + 컴포넌트 설명을 AI에게 넘기는 방식으로 보겠습니다.

Step 1. Figma Variables를 JSON으로 추출하기

Figma의 Variables modal에서 컬렉션이나 모드를 선택한 뒤,

JSON 형식으로 내보낼 수 있어요.

또는 Variables Import/Export 계열 플러그인을 사용할 수도 있습니다.

여기서 중요한 건

컬러만 뽑는 게 아니라, 가능하면 이런 값들을 함께 정리하는 거예요.

재료가 좋아야 결과도 좋아요.

양파 하나만 넣고 "근사한 코스 요리 해줘" 하면

AI도 난감합니다. 🧑‍🍳

Step 2. AI에게 DESIGN.md 초안 요청하기

아래 프롬프트를 그대로 써보세요.

이 프롬프트에서 핵심은 두 줄이에요.

AI에게 "잘 써줘"라고만 하면

AI는 너무 자신 있게 씁니다.

문제는 그 자신감이 항상 사실에서 나오는 게 아니라는 거예요.

그래서 우리는 AI에게 이렇게 말해야 합니다.

이 한 줄이 AI 문서를 실무 문서로 바꿉니다.

Step 3. 디자이너가 검수하기

AI가 DESIGN.md 초안을 만들어줬다고 끝이 아니에요.

이제 디자이너가 해야 할 일이 있습니다.

크게 네 가지예요.

1) 제품 맥락과 맞는지 보기

AI는 일반론을 잘 말해요.

하지만 우리 제품의 사용자는 누구인지,

우리 브랜드가 어떤 말투를 써야 하는지,

우리 팀의 개발 리소스가 어느 정도인지는 모릅니다.

그래서 이런 문장을 보면 확인해야 해요.

좋은 말이긴 한데,

우리 제품에 정말 필요한가요?

개발 리소스는 되나요?

접근성 문제는 없나요?

좋은 말과 맞는 말은 다릅니다.

디자이너는 그 차이를 잡아야 해요

2) [확인 필요] 항목을 담당자에게 보내기

예를 들어 이런 항목이 나왔다고 해볼게요.

이건 디자이너가 혼자 확정하면 안 돼요.

PM이나 기획자에게 물어봐야 합니다.

AI는 결정을 대신하는 도구가 아니라,

결정해야 할 빈칸을 찾아주는 도구로 쓰는 게 안전합니다.

3) [검증 필요] 항목을 실제로 테스트하기

예를 들어 이런 항목이 있다면요.

이건 실제 대비 계산을 해야 해요.

또 이런 항목도요.

이건 Figma에서 실제 버튼 높이, 아이콘 터치 영역을 봐야 합니다.

말로만 "접근성 고려"는 안 됩니다.

접근성은 수치와 상태로 확인해야 해요.

4) 우리만의 규칙을 추가하기

AI가 만든 문서는 보통 "무난한 좋은 사례"에  가까워요.

하지만 디자인 시스템은 우리 제품의 선택이 담겨야 해요.

예를 들면 이런 규칙이죠.

이런 규칙은 AI가 알아서 만들어줄 수는 있지만,

최종 확정은 사람이 해야 해요.

8. Figma MCP와 양방향 워크플로우는 어디까지 왔을까?

여기서 자연스럽게 다음 질문이 생깁니다.

"그럼 앞으로는 AI가 Figma 파일을 직접 읽고, UI 가이드도 자동으로 만들고, 코드까지 다 해주는 건가요?"

방향은 맞아요.

하지만 아직은 너무 마법처럼 이해하면 안 됩니다.

Figma MCP는 AI 에이전트가 Figma 파일의 구조화된 디자인 컨텍스트를 읽을 수 있게 도와주는 연결 방식이에요.

예를 들면,

이걸 Cursor나 Codex 같은 개발 도구와 연결하면

AI가 Figma 컨텍스트를 참고해서 더 디자인에 가까운 코드를 만들 수 있어요.

또 최근에는 코드에서 만든 UI를 다시 Figma의 편집 가능한 레이어로 가져오고,

Figma에서 수정한 내용을 다시 코드 쪽으로 반영하는 흐름도 확장되고 있어요.

이걸 흔히 rounud-trip workflow, 즉 양방향 워크플로우라고 부릅니다.

흐름만 보면 정말 멋있어요.

그런데 여기서 오해하면 안 되는 게 있어요.

Figma MCP는 "원클릭으로 완벽한 코드를 뽑아주는 마법 버튼"이 아닙니다.

AI가 읽는 건 결국 우리가 정리해둔 파일이에요.

컴포넌트 이름이 엉망이면,

AI도 엉망인 이름을 읽습니다.

토큰이 연결되어 있지 않으면,

AI도 토큰 맥락을 알 수 없습니다.

State가 빠져 있으면,

AI도 빠진 상태로 코드를 만들 가능성이 높습니다.

즉, AI 시대의 핸드오프는 이렇게 바뀌고 있어요.

그래서 오늘 이야기한 5가지 원칙이 중요해집니다.

이건 단순히 예쁜 Figma 파일을 만드는 습관이 아니에요.

AI가 우리 디자인을 제대로 읽게 만드는 기본기입니다.

9. 바로 해보는 10분 미션

오늘은 거창하게 DESIGN.md 전체를 만들 필요 없어요.

딱 하나만 해봅시다.

지금 작업 중인 Figma 파일에서 가장 자주 쓰는 컴포넌트 하나를 골라보세요.

추천은 버튼이에요.

그리고 아래 체크리스트를 봅니다.

여기서 ❌가 하나라도 있다면,

그게 바로 여러분의 DESIGN.md 첫 빈칸입니다.

완벽하게 시작하려고 하지 마세요.

컬러 토큰 하나 정리하고,

버튼 State 하나 추가하고,

Description 한 줄 쓰는 것.

그게 AI 시대 디자인 시스템의 첫걸음입니다.

10. 오늘의 한 줄 요약

지난 호가 "UX 화면 설계서를 AI와 함께 쓰는 법"이었다면,

오늘은 "UI 가이드를 AI가 읽을 수 있는 구조로 만드는 법"이었습니다.

AI가 대신 해주는 일은 점점 늘어날 거예요.

문서 초안도 만들고,

컴포넌트 설명도 정리하고,

코드도 생성하고,

어쩌면 Figma 파일까지 다시 만들어줄지도 몰라요.

하지만 그 모든 작업의 기준은 여전히 사람이 세워야 합니다.

AI가 읽을 수 있는 규칙을 만들고,

AI가 확정하면 안 되는 영역을 표시하고,

AI가 검증해야 할 항목을 놓치지 않게 하는 것.

앞으로 디자이너의 역할은

픽셀을 하나한 잡는 사람에서

시스템의 기준을 설계하는 사람으로 더 이동할 거예요.

멋있게 들리지만, 시작은 소박합니다.

버튼 이름 하나 제대로 짓기.

토큰 하나 의미 있게 연결하기.

State 하나 빠뜨리지 않기.

늘 그렇듯, 좋은 시스템은 작은 약속에서 시작됩니다.

다음 호 예고

다음 15호에서는 협업 문서 3종 세트의 마지막,

개발 핸드오프 노트 + Figma MCP 워크플로우를 다뤄볼게요.

그 전에

Figma 파일이 정리되어 있어야

AI도 제대로 읽고,

개발자도 덜 묻고,

미래의 나도 덜 웁니다. 😇

오늘 너무 열심히 떠들다보니 뉴스레터가 길어져버렸네요.

긴 글 읽어주셔서 감사합니다.

다음 호는 길지 않게 잘 요약해 볼게요. 🥲

그럼, 2주 뒤에 또 만나요.

지은 드림