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

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

디자이너의 고민이 성장이 되는 시간!

안녕하세요, 구독자님!

이지은입니다.

지난 14호에서는 AI가 읽을 수 있는 UI 가이드,

즉 DESIGN.md에 대해 이야기했어요.

핵심은 이거였죠

그럼 이제 다음 질문으로 넘어갈게요.

정리된 Figma 파일과 DESIGN.md가 있다면,

이걸 개발자에게는 어떻게 넘겨야 할까요?

오늘은 협업 문서 3종 세트의 마지막,

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

다만 오늘은 "Figma MCP 연결 버튼 어디 있어요?" 같은 설치 매뉴얼보다

더 중요한 이야기를 먼저 하려고 합니다.

바로 화면별 구현 맥락입니다.

왜냐하면 도구를 연결하기 전에,

먼저 정리되어야 하거든요.

1. AI 시대의 핸드오프

AI 시대의 핸드오프에는 독자가 세 명(?) 있어요.

첫 번째는 개발자입니다.

실제로 구현하는 사람이죠.

두 번째는 AI 에이전트입니다.

Cursor, Claude Code, Codex, Gemini CLI 같은 도구들이 Figma 컨텍스트를 읽고 코드를 생성하거나 수정하는 흐름이 점점 늘어나고 있어요.

세 번째는 미래의 나입니다.

한 달 뒤, 세 달 뒤, 반년 뒤에 다시 이 화면을 열어볼 나 자신이요.

이들은(?) 공통적으로 같은 걸 필요로 합니다.

"이 화면이 왜 이렇게 만들어졌는지"

"어떤 상태를 고려해야 하는지"

"무엇이 확정됐고, 무엇은 아직 확인 필요한지"

그래서...

오늘의 핵심 문장이 이겁니다.

핸드오픈는 더 이상 '전달'이 아닙니다.

AI와 개발자가 함께 읽을 수 있는 구조를 만드는 일입니다.

2. DESIGN.md와 개발 핸드오프 노트는 다릅니다

지난 14호에서 다룬 DESIGN.md는 AI에게 주는 디자인 시스템 컨텍스트였어요.

컬러

타이포그래피

간격

컴포넌트 규칙

상태

패턴

카피 톤

이런 것들을 정리해서 AI가 우리 제품의 UI 기준을 이해하도록 돕는 문서인거죠.

하지만 DESIGN.md만으로는 부족합니다.

DESIGN.md는 제품 전체의 규칙이고,

개발 핸드오프 노트는 특정 화면의 구현 맥락입니다.

예를 들어볼게요.

DESIGN.md에는 이렇게 적혀 있을 수 있어요.

Primary Button은 화면의 핵심 CTA에 사용합니다.

Error 메시지는 해당 인풋 하단에 표시합니다.

Empty State는 다음 행동을 안내하는 CTA를 포함합니다.

좋습니다.

그런데 실제 회원가입 화면을 구현하려면 더 구체적인 정보가 필요해요.

이 화면은 어디서 진입하는가?

회원가입 완료 후 어디로 이동하는가?

이메일 중복 검사는 언제 하는가?

비밀번호 조건은 입력 중에 보여주는가, 제출 후 보여주는가?

소셜 로그인 실패 시 어떤 메시지를 보여주는가?

약관 동의는 필수와 선택을 어떻게 구분하는가?

이건 디자인 시스템 규칙만으로는 알 수 없습니다.

그래서 개발 핸드오프 노트가 필요해요.

한 줄로 정리하면 이렇습니다.

DESIGN.md는 AI에게 주는 디자인 기준이고,

개발 핸드오프 노트는 개발자와 AI에게 함께 주는 화면별 구현 기준입니다.

3. 개발 핸드오프 노트에는 무엇이 들어가야 할까?

예전(이라니...😭) 핸드오프 문서에는 보통 이런 것들이 들어갔습니다.

화면 링크

컴포넌트 스펙

에셋 export 경로

간단한 인터렉션 설명

이것도 여전히 필요해요.

하지만 AI 시대에는 여기에 몇 가지가 더 들어가야 합니다.

1) 화면의 역할과 진입 경로

AI는 화면의 맥락을 모릅니다.

프레임 이름이 signup_01이라고 되어 있어도,

이게 최초 회원가입인지, 초대받은 사용자의 가입인지, 소셜 로그인 후 추가 정보 입력 화면인지 알 수 없어요.

그래서 화면마다 이런 설명이 필요합니다.

이 화면은 신규 사용자가 이메일로 회원가입을 시작할 때 진입하는 화면입니다.

진입 경로는 온보딩 첫 화면의 "이메일로 시작하기" 버튼입니다.

회원가입 완료 후에는 관심사 선택 화면으로 이동합니다. [확인 필요: 가입 후 진입 정책]

여기서 중요한 건 마지막 문장입니다.

정책이 확정되지 않았다면 확정하지 마세요.

AI도, 디자이너도, 개발자도 마음대로 정하면 안 됩니다.

그럴 때는 이렇게 표시하면 됩니다.

[확인 필요]

2) 각 컴포넌트의 사용 의도

디자인은 모양만으로 전달되지 않습니다.

버튼 하나에도 의도가 있어요.

이 버튼은 저장인가요?

다음 단계 이동인가요?

임시 저장인가요?

취소인가요?

AI는 버튼의 텍스트와 위치를 보고 추측할 수는 있지만, 추측은 어디까지나 추측입니다.

예를 들어 이렇게 적어두면 좋아요.

Primary Button / "다음으로"

사용자가 필수 정보를 모두 입력한 뒤 다음 단계로 이동하는 핵심 CTA입니다.

필수 입력값이 모두 유효할 때만 활성화됩니다.

클릭 시 입력값을 검증한 후 다음 화면으로 이동합니다.

API 저장 여부는 [확인 필요]입니다.

이렇게 쓰면 개발자도 이해하고, AI 에이전트도 이상한 코드를 만들 확률이 줄어듭니다.

3) State별 동작 정의

실무에서 가장 자주 빠지는 것이 State입니다.

Default

Loading

Error

Empty

Disabled

Success

Permission denied(권한 없음)

정적인 화면 한 장만 넘기면 개발자는 결국 질문할 수밖에 없어요.

"로딩 중에는 뭐가 보이나요?"

"데이터가 없으면요?"

"네트워크 에러면요?"

"권한 없으면 어디로 보내요?"

그래서 개발 핸드오프 노트에는 최소한 이 네가지는 들어가야 합니다.

Default

Loading

Empty

Error

예를 들어 리스트 화면이라면 이렇게요.

Default : 사용자의 프로젝트 리스트를 카드 형태로 표시합니다.

Loading : 첫 진입 시 스켈레톤 UI를 표시합니다.

Empty : 생성된 프로젝트가 없을 경우 "아직 만든 프로젝트가 없어요" 문구와 "첫 프로젝트 만들기" CTA를 표시합니다.

Error : 프로젝트 목록을 불러오지 못한 경우 에러 메시지와 "다시 시도" 버튼을 표시합니다. 에러 코드 노출 여부는 [확인 필요]입니다.

여기서 포인트는 단순히 "에러 화면 있음"이라고 쓰는 게 아니에요.

사용자가 다음에 무엇을 할 수 있는지까지 적어야 합니다.

좋은 Empty State와 Error State는 막다른 길이 아니라 우회로를 제공합니다.

4) [확인 필요] 항목

AI 시대 문서에서 가장 중요한 태그 중 하나가 바로 이것입니다.

[확인 필요]

이건 사람이 결정해야 하는 영역이에요.

예를 들면 이런 것들입니다.

가입 완료 후 이동 화면

결제 실패 시 재시도 가능 횟수

비밀번호 오류 제한 정책

탈퇴 후 재가입 가능 여부

무료 플랜과 유료 플랜의 기능 제한

관리자 권한 범위

알림 발송 조건

데이터 보관 기간

이런 건 디자이너가 혼자 정하면 안 됩니다.

물론 화면에서는 표현해야 해요.

하지만 정책 자체는 PM, 기획자, 개발자, 운영팀, 때로는 법무 담당자와 확인해야 합니다.

그래서 핸드오프 노트에는 이렇게 적는 게 안전합니다.

비밀번호 5회 오류 시 계정 잠금 여부는 [확인 필요]입니다.

무료 사용자의 프로젝트 생성 개수 제한은 [확인 필요]입니다.

탈퇴 계정의 데이터 보관 기간은 [확인 필요]입니다.

이 태그 하나가 협업 리스크를 크게 줄여줍니다.

5) [검증 필요] 항목

지난 14호에서도 이야기했지만, [확인 필요]와 [검증 필요]는 다릅니다.

[확인 필요]는 사람이 결정해야 하는 것.

[검증 필요]는 기준으로 테스트해야 하는 것.

예를 들어 이런 항목은 [검증 필요]입니다.

Primary Button의 배경색과 흰색 텍스트 대비가 WCAG AA 기준을 충족하는지 확인 필요

모바일 터치 타겟이 최소 44px 이상인지 확인 필요

키보드 Tab 이동 시 Focus 상태가 시각적으로 구분되는지 확인 필요

긴 닉네임 입력 시 카드 레이아웃이 깨지지 않는지 확인 필요

스테이징 환경에서 Loading / Empty / Error 상태가 실제로 구현되었는지 확인 필요.

이건 회의에서 취향으로 결정할 수 있는 문제가 아니에요.

직접 확인해야 합니다.

그래서 핸드오프 노트에는 이렇게 쓰면 좋아요.

접근성 : 버튼 대비는 WCAG AA 기준 충족 여부를 확인해야 합니다. [검증 필요]

터치 영역 : 아이콘 버튼의 사각 크기는 24px이지만, 실제 터치 영역은 44px 이상이어야 합니다 [검증 필요]

반응형 : 320px 화면에서 CTA 버튼 문구가 줄바꿈되지 않는지 확인해야 합니다. [검증 필요]

좋은 핸드오프 노트는 개발자에게 "이렇게 만들어 주세요"만 말하지 않습니다.

"이건 나중에 이렇게 확인해야 합니다"까지 알려줍니다.

4. Figma MCP는 무엇을 해주고, 무엇을 못 할까?

이제 Figma MCP 이야기를 해볼게요.

Figma MCP는 쉽게 말하면,

AI 에이전트가 Figma 파일의 구조화된 디자인 컨텍스트를 읽을 수 있게 해주는 연결 통로입니다.

이전에는 AI가 화면 이미지를 보고 대충 추측했다면,

이제는 Figma 안의 레이어 구조, 컴포넌트, 변수, 레이아웃 정보, 선택한 프레임 정보 등을 더 직접적으로 참고할 수 있게 되는 흐름이에요.

최근에는 Figma MCP가 더 확장되면서 이런 일들이 가능해지고 있습니다.

선택한 프레임의 디자인 컨텍스트 가져오기

컴포넌트 구조와 Properties 읽기

Variables와 토큰 정보 참고하기

Code Connect로 연결된 실제 코드 컴포넌트 정보 활용하기

Figma Make 리소스를 참고해 코드 작업에 활용하기

Figma 캔버스에 프레임, 컴포넌트, 변수, Auto Layout을 생성하거나 수정하기

듣기만 하면 정말 멋있죠.

그런데 여기서 오해하면 안 됩니다.

Figma MCP는 디자이너의 의도를 자동으로 완벽하게 이해하는 도구가 아닙니다.

Figma MCP가 읽을 수 있는 건 주로 구조입니다.

컴포넌트 이름

레이어 이름

변수 이름

레이아웃 정보

Code Connect 연결 정보

Annotation

선택한 프레임의 디자인 컨텍스트

하지만 이런 건 여전히 사람이 정리해야 합니다.

이 화면이 왜 필요한가

어떤 정책이 적용되는가

어떤 예외 상황을 고려해야 하는가

이 버튼의 비즈니스 의미는 무엇인가

어떤 상태 전환이 일어나는가

무엇이 아직 미정인가

그래서 핵심 메시는 이거예요.

Figma MCP는 구조를 읽지만, 의도는 자동으로 읽지 못합니다.

의도를 적는 것이 개발 핸드오프 노트입니다.

5. AI가 잘 읽는 Figma 파일의 조건

Figma MCP를 제대로 쓰려면 Figma 파일 자체가 정리되어 있어야 합니다.

이건 지난 14호와도 연결되는 이야기예요.

AI가 읽기 좋은 Figma 파일에는 몇 가지 특징이 있습니다.

1) 컴포넌트를 사용한다.

버튼, 카드, 인풋, 네비게이션처럼 반복되는 요소는 컴포넌트로 만들어야 합니다.

매번 Frame으로 복사해서 만들면 AI와 개발자는 구조를 파악하기 어려워요.

2) Code Connect로 실제 코드와 연결한다.

팀에 디자인 시스템 코드가 있다면 Code Connect가 큰 도움이 됩니다.

Figma 컴포넌트와 실제 코드 컴포넌트를 연결하면, AI 에이전트가 더 정확한 구현 맥락을 참고할 수 있어요.

다만 이건 디자이너 혼자 끝내기보다는 개발자와 함께 잡아야 하는 영역입니다.

3) Variables를 사용한다.

컬러, 간격, radius, 타이포그래피 같은 값은 가능하면 Variables로 관리하세요.

특히 의미 기반 토큰이 중요합니다.

blue/500보다

color/action/primary가 더 좋습니다.

왜냐하면 AI도 "이 색이 어디에 쓰는지" 이름을 통해 이해할 수 있기 때문이에요.

4) 의미 있는 네이밍을 사용한다.

Frame 123

Group 45

Rectangle 88

이런 이름은 AI에게도 개발자에게도 도움이 되지 않습니다.

CardContainer

ProdctImage

CTA_Button

SignupForm

ErrorMessage

이런 식으로 역할이 보이게 이름을 붙여주세요.

이름은 장식이 아닙니다.

AI 시대에는 이름도 스펙입니다.

5) Auto Layout을 사용한다.

Auto Layout은 단순히 정렬을 편하게 해주는 기능이 아니에요.

레이아웃의 의도를 전달하는 방식입니다.

어떤 요소가 세로로 쌓이는지

간격은 얼마인지

패딩은 얼마인지

콘텐츠가 늘어날 때 어떻게 반응하는지

이 정보를 AI와 개발자가 더 잘 이해할 수 있게 해줍니다.

6) Annotation을 남긴다

시각적으로 보이지 않는 의도는 메모로 남겨야 합니다.

예를 들면 이런 것들이요.

"이 버튼은 필수 입력값이 모두 유효할 때 활성화됩니다"

"이 영역은 데이터가 없을 때 Empty State로 대체됩니다."

"모달 바깥 영역을 클릭하면 닫히지 않습니다. 닫기 버튼으로만 닫습니다."

"정렬 기본값은 최신순입니다. [확인 필요]"

"이미지 로딩 실패 시 기본 썸네일을 표시합니다."

완벽한 문서를 따로 만들 시간이 없다면, Annotation 하나라도 남겨보세요.

AI도, 개발자도, 미래의 나도 그 메모 하나에 구원받을 때가 있습니다. 😇

6. 실전 워크플로우 : AI로 핸드오프 노트 초안 만들기

이제 실제로 어떻게 써먹을 수 있는지 볼게요.

워크플로우는 3단계입니다.

Step 1. Figma에서 준비하기

Figma에서 최소한 이것만 확인하세요.

섹션 이름이 일관적인가?

최종 화면과 작업 중 화면이 구분되어 있는가?

핵심 컴포넌트가 컴포넌트로 연결되어 있는가?

컬러와 간격이 Variables에 연결되어 있는가?

버튼, 인풋, Empty, Error 같은 주요 상태가 정의되어 있는가?

Annotation에 화면 역할, 예외 케이스, 미정 정책이 적혀 있는가?

Ready for Dev 상태로 넘겨도 되는 화면인가?

여기서 ❌가 많아도 괜찮아요.

완벽하게 정리하고 시작하라는 뜻이 아닙니다.

다만 AI에게 넘기기 전에 내가 무엇을 알고 있고, 무엇을 모르는지 구분해야 한다는 뜻이에요.

Step 2. AI에게 핸드오프 노트 초안 요청하기

아래 프롬프트를 그대로 써보셔도 좋아요.

이 프롬프트에서 중요한 건 

모르는 건 [확인 필요]로 표시해.

검증해야 하는 건 [검증 필요]로 표시해

없는 건 있다고 만들지 마.

이렇게 말해야 해요.

AI는 빈칸을 참 싫어합니다.

그래서 가만히 두면 빈칸을 그럴듯한 문장으로 채워요.

하지만 실무에서는 그게 제일 위험합니다.

모르는 건 모른다고 표시하는 문서가

그럴듯하게 다 아는 척하는 문서보다 훨씬 안전합니다.

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

AI가 핸드오프 노트를 만들어줬다고 끝이 아닙니다.

이제 디자이너가 해야 할 일이 있어요.

첫 번째, 화면 의도가 맞는지 봅니다.

AI가 화면의 역할을 잘못 이해했을 수 있어요.

두 번째, [확인 필요] 항목을 담당자에게 보냅니다.

정책은 PM 또는 기획자와 확인해야 합니다.

API나 기술 제약은 개발자와 확인해야 합니다.

세 번째, [검증 필요] 항목을 실제로 테스트합니다.

색상 대비, 터치 타겟, 포커스 상태, 반응형은 말이 아니라 확인입니다.

네 번째, 로직 오류를 직접 수정합니다.

AI는 흐름을 그럴듯하게 정리하지만, 우리 제품의 실제 맥락은 모릅니다.

다섯 번째, 최종 문서를 Figma / Jira / Notion 등 팀이 실제로 보는 곳에 연결합니다.

7. Figma MCP 연결은 어디까지 해보면 좋을까?

여기서 이런 질문이 생길 수 있어요.

"그럼 이제 무조건 Figma MCP를 써야 하나요?"

제 답은 이렇습니다.

팀에 개발자와 AI 코딩 도구를 함께 쓰는 흐름이 있다면 시도해볼 가치가 있습니다.

하지만 1인 디자이너나 작은 팀이라면, 먼저 Figma 파일 정리와 핸드오프 노트 습관부터 잡는 게 우선입니다.

도구 연결보다 중요한 건 기본 구조예요.

그래도 흐름을 아주 가볍게 정리하면 이렇습니다.

여기서 꼭 기억해야 할 점이 있어요.

큰 페이지 전체를 한 번에 던지면 결과가 느리거나 부정확할 수 있습니다.

작은 단위로 나눠서 요청하는 게 훨씬 안정적이에요.

8. 협업 문서 3종 세트가 완성되었습니다

세 문서는 따로 노는 문서가 아닙니다.

UX 화면 설계서가 화면의 목적과 흐름을 잡고,

DESIGN.md가 디자인 시스템의 기준을 잡고,

개발 핸드오프 노트가 실제 구현 맥락을 잡습니다.

이 세 가지가 연결되어 있을 때 AI는 훨씬 잘 작동합니다.

AI는 좋은 맥락을 받았을 때 덜 헤매는 도구이기 때문이에요.

9. 바로 써먹는 개발 핸드오프 노트 템플릿

이 정도만 있어도 개발자와의 대화가 훨씬 편해집니다.

오늘의 한 줄 요약

Figma MCP는 구조를 읽지만, 의도는 사람이 적어야 합니다.

AI 시대의 핸드오프는 화면을 넘기는 일이 아니라, AI와 개발자가 함께 읽을 수 있는 구현 맥락을 만드는 일입니다.

시작은 거창하지 않아도 됩니다.

컴포넌트 이름 하나 제대로 짓기.

State 하나 빠뜨리지 않기.

Annotation 한 줄 남기기

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

늘 그렇듯, 좋은 협업은 작은 메모에서 시작됩니다.

다음 호 예고

다음 호에서 

[AI 시대 UX/UI 디자이너 실무 워크플로우와 포트폴리오 설계를 위한 사전 설문]을

집계한 내용과 인사이트를 이야기 해볼까 합니다.

어떤 결과가 나왔을지 궁금하지 않으신가요? ㅎㅎ

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

지은 드림