08. Figma 공식스킬

id: 4094
slug: figma-official-skills
title: "Figma 공식스킬"
status: publish
date: "2026-07-28 22:15:23"
categories: creative-figma
tags: %ed%94%bc%ea%b7%b8%eb%a7%88

1. 이 문서를 읽는 법

Figma가 AI 에이전트용으로 배포하는 스킬(Skill) 이 무엇인지, 어떤 것들이 있는지, 어떻게 설치하고 무엇을 조심해야 하는지를 정리한 문서다. Figma를 쓰는 디자이너·기획자·개발자 중 Claude Code·Cursor 같은 에이전트 도구를 처음 붙여 보는 사람을 기준으로 썼다.

1.1. 사실 표기 규칙

이 문서의 각 항목에는 근거를 함께 적었다.

확인 기준일은 2026-07-30, 확인 대상은 플러그인 버전 2.2.81이다. 스킬 파일은 플러그인 버전이 오르면 내용이 바뀐다. 실제 도입 전에는 자기 환경에 설치된 파일을 직접 열어 보는 것이 가장 정확하다.

설치본 경로 예시(Claude Code, Windows):

~/.claude/plugins/cache/claude-plugins-official/figma/<버전>/skills/
~/.claude/plugins/cache/claude-plugins-official/figma/<버전>/workflow-skills/

2. 먼저 알아 둘 것 — "스킬"이 무엇인가

스킬은 AI에게 미리 넣어 두는 작업 설명서다. 마크다운 파일 한 장이며, "이 상황에서는 이런 순서로, 이런 규칙을 지키며 일해라"를 적어 둔 것이다.

여기서 반드시 구분해야 하는 개념이 둘 있다.

스킬은 새로운 기능을 만들어 주지 않는다. 이미 있는 MCP 도구를 덜 헤매고 쓰게 해 줄 뿐이다. 따라서 아래 어느 스킬을 켠다고 해서 없던 능력이 생기지는 않는다. Figma MCP 서버 연결이 전제다.

3. 전체 지도

3.1. Figma 공식 스킬 14종 (원문 확인)

플러그인 v2.2.81에 실제로 들어 있는 스킬은 skills/ 12개 + workflow-skills/ 2개 = 14개다.

workflow-skills/에 있는 둘은 도구 하나를 감싼 스킬이 아니라 여러 스킬을 순서대로 엮어 쓰는 상위 작업 절차다. 그래서 폴더가 분리돼 있다.

3.2. 커뮤니티 스킬 10종 (미검증)

아래는 Figma 커뮤니티에 공개된 외부 기여 스킬이다. 각각 별도 GitHub 저장소에서 배포되며 Figma가 동작을 보증하지 않는다. 이 문서는 이들의 원문을 직접 확인하지 못했다.

3.3. 방향으로 보는 분류

작업 방향을 먼저 잡으면 어떤 스킬을 쓸지가 거의 정해진다.

코드 → Figma (쓰기)      generate-design / generate-library / use-figjam
                          use-slides / generate-diagram / use-motion
                          create-new-file / generate-project-plan
                          video-interaction-mapper

Figma → 코드 (읽기)      design-to-code / implement-motion

양쪽 연결                 code-connect / swiftui

4. 설치

4.1. 가장 쉬운 방법 — 플러그인 하나로 끝낸다

스킬을 하나씩 받는 것이 아니라, Figma 플러그인을 설치하면 MCP 서버 설정과 공식 스킬이 한꺼번에 딸려 온다. 공식 문서가 권장하는 방식이 이것이다. (공식 문서)

Cursor와 Claude Code에서 Figma MCP 서버를 설정하는 권장 방법은 Figma 플러그인을 설치하는 것이다. 플러그인에는 MCP 서버 설정과 함께, 자주 쓰는 작업용 Agent Skills가 포함돼 있다.
— 플러그인 동봉 README.md

4.2. 1단계 — MCP 서버 연결

스킬은 설명서일 뿐이므로(→ 2장), MCP 서버 연결이 먼저다. 원격 서버 주소는 하나다.

https://mcp.figma.com/mcp

Claude Code — 플러그인으로 설치하면 MCP 연결과 스킬이 함께 들어온다(권장). (공식 문서)

claude plugin install figma@claude-plugins-official

MCP 서버만 따로 연결하려면:

claude mcp add --transport http figma https://mcp.figma.com/mcp

연결 상태 확인·해제는 이렇게 한다.

claude mcp list          # 연결된 서버 목록
claude mcp get figma     # 상세 정보
claude mcp remove figma  # 해제

Cursor — 에이전트 채팅에 아래를 입력한다. (공식 문서)

/add-plugin figma

수동으로 넣으려면 MCP 설정에 아래를 추가한다.

{
  "mcpServers": {
    "figma": {
      "url": "https://mcp.figma.com/mcp"
    }
  }
}

VS Code — ⌘ Shift P → MCP: Add Server → HTTP 선택 → 위 주소 입력 → 서버 ID를 figma로 → 전역/작업공간 범위 선택. GitHub Copilot이 계정에 활성화돼 있어야 한다. 채팅에서 #get_design_context를 입력해 도구가 보이는지 확인하고, 안 보이면 VS Code를 재시작한다. (공식 문서)

Gemini CLI — 플러그인 저장소에 gemini-extension.json이 동봉돼 있고, 그 안에 같은 서버 주소와 OAuth 설정이 들어 있다. (원문 확인)

그 밖의 편집기 — Streamable HTTP를 지원하면 위 JSON 설정을 그대로 쓰면 된다.

4.3. 2단계 — 스킬 파일 직접 넣기 (플러그인을 못 쓸 때)

플러그인 방식이 안 되는 도구라면 저장소를 통째로 받아 스킬 폴더에 넣는다.

1. https://github.com/figma/mcp-server-guide/archive/refs/heads/main.zip 을 내려받는다
2. 압축을 푼다
3. skills/ 안의 폴더들을 쓰는 도구의 스킬 디렉터리로 옮긴다

Claude Code라면 개인 스킬 디렉터리는 다음 위치다.

~/.claude/skills/figma-use/SKILL.md
~/.claude/skills/figma-generate-design/SKILL.md
...

주의할 점 두 가지.

• figma-use는 사실상 항상 같이 넣어야 한다. generate-design·generate-library·use-figjam·use-slides·use-motion·swiftui(코드→디자인 방향)가 전부 이것을 전제로 한다(→ 5.3).
• generate-project-plan과 video-interaction-mapper는 skills/가 아니라 workflow-skills/에 있다. 이 둘이 필요하면 그쪽 폴더도 함께 복사한다.

각 스킬 폴더 안에는 SKILL.md 외에 references/ 하위 문서가 여러 장 들어 있다. 폴더째 복사해야 한다. SKILL.md 한 장만 옮기면 본문이 참조하는 세부 문서가 전부 끊긴다.

4.4. 3단계 — 설치 확인

whoami는 create_new_file이 요구하는 planKey를 얻는 경로이기도 하다. 소속 플랜이 여러 개면 어느 팀에 파일을 만들지 사용자에게 물어야 한다. (원문 확인)

4.5. 설치해도 안 되는 경우

설치 자체는 됐는데 쓰기가 실패한다면 계정 조건 문제일 수 있다. 요금제·좌석·호출 한도는 8장에 정리했다.

5. 모든 것의 기반 — /figma-use

5.1. 한 줄 정의

Figma 파일 안에서 자바스크립트를 실행해 무언가를 만들거나 고칠 때, 지켜야 할 규칙을 모아 놓은 스킬이다.

이름이 비슷한 것이 셋 있어 헷갈리기 쉽다. 먼저 구분하고 시작한다.

즉 figma-use는 기능이 아니라 주의사항 모음이다. 없어도 도구는 호출되지만, 거의 확실히 실패한다.

5.2. 왜 "필수"인가

figma-use의 스킬 설명문 첫 줄은 이렇게 되어 있다. (원문 확인)

MANDATORY prerequisite — 모든 use_figma 도구 호출 전에 반드시 이 스킬을 불러와야 한다. 절대 이 스킬 없이 use_figma를 직접 호출하지 마라. 건너뛰면 흔하지만 원인 찾기 어려운 실패가 발생한다.

비유하자면 Figma Plugin API는 공작 기계다. 성능은 좋지만 안전 규칙이 여럿 있다. figma-use는 그중 실제로 자주 사고가 나는 항목만 골라 앞에 모아 놓은 안전 수칙표다.

원문의 "Critical Rules" 중 초보자가 특히 자주 밟는 것들이다. (원문 확인)

에러 메시지가 원인을 짐작하기 어렵다는 것이 핵심이다. 색이 0~1이라는 것을 모르면 "빨강을 넣었는데 흰색이 나온다"는 증상만 남는다.

5.3. 다른 스킬과의 관계

                    figma-use  (안전 수칙 — 기반)
                         │
   ┌──────────┬──────────┼──────────┬──────────┬─────────────┐
   │          │          │          │          │             │
generate-  generate-  use-figjam  use-slides  use-motion  swiftui
 design     library                                      (코드→디자인 방향만)
(화면 조립) (부품 창고)  (FigJam)   (Slides)   (애니메이션)

• figma-use = 어떻게 쓰는가 (문법과 안전 규칙)
• 나머지 스킬 = 무엇을 어떤 순서로 만드는가 (작업 절차)

generate-project-plan은 여기에 더해 figma-use는 세션당 한 번, figma-use-figjam은 매 use_figma 호출 직전마다 다시 로드하라고 명시한다. (원문 확인) 스킬마다 재로드 요구가 다르므로 각 원문을 따르는 편이 안전하다.

한편 generate_diagram·create_new_file·get_design_context는 use_figma를 쓰지 않으므로 figma-use가 필요 없다. 대신 각각 figma-generate-diagram·figma-create-new-file·figma-design-to-code가 자기 자신을 필수 선행 스킬로 요구한다. (원문 확인)

6. 공식 스킬 낱개 보기

6.1. /figma-generate-design — 코드를 보고 Figma에 화면을 조립한다

무엇을 하나

이미 만들어진 웹/앱 화면의 소스코드를 읽고, 그 화면을 Figma 안에 다시 그린다. 핵심은 "새로 그리지 않는다" 는 점이다. 팀이 이미 배포해 둔 디자인 시스템에서 버튼·카드·입력창 인스턴스를 꺼내 쓰고, 색과 여백도 하드코딩된 값(#3B82F6 같은 것) 대신 등록된 변수를 연결한다.

작업 순서 (원문 확인)

1. 소스코드를 읽어 화면을 큰 덩어리(헤더·본문·푸터 등)로 나눈다
2. 각 덩어리에 어떤 컴포넌트가 쓰이는지 목록을 만든다
3. Code Connect 파일에서 그 컴포넌트의 Figma 키를 찾는다
4. 없으면 파일 안 기존 화면을 뒤져 찾고, 그래도 없으면 라이브러리를 검색한다
5. 한 번에 한 덩어리씩만 만들고, 만들 때마다 검증한다

초보자가 놓치기 쉬운 함정 3가지 (원문 확인)

• 글꼴을 Inter로 기본 처리하면 안 된다. 원문 4번 준비 단계가 "제품이 실제로 쓰는 글꼴을 소스에서 찾아라. Inter를 기본값으로 쓰지 마라"라고 못 박는다. 코드가 SF Pro를 쓰는데 Inter로 그리면 오류 없이 성공한 것처럼 보이지만 결과물은 틀린 것이다. 그래서 만든 뒤 글꼴을 다시 읽어 검사(assert)하라고 별도로 요구한다.
• 이미지가 있으면 generate_figma_design 병행 캡처가 의무다. Plugin API는 외부 이미지 주소를 가져오지 못하고, 파일 안에 이미 있는 노드의 imageHash를 복사하는 방식으로만 이미지 채우기를 설정할 수 있다. 그래서 같은 fileKey에 캡처를 떠서 해시를 확보한 뒤 옮겨 붙이고, 다 옮기면 캡처 결과물은 삭제한다. 건너뛰면 이미지 자리가 빈칸으로 남는다.
• 한 번의 호출로 전체 화면을 만들려 하면 깨진다. 원문 표현은 "한 번의 use_figma 호출에 주요 섹션 하나를 넘겨 만들지 말 것"이다.

필요 조건: Figma MCP 연결, 대상 파일 키(fileKey), 대상 파일에 게시된 디자인 시스템. 파일이 없으면 /figma-create-new-file을 먼저 부른다.

6.2. /figma-generate-library — 코드베이스로 디자인 시스템을 만든다

무엇을 하나

6.1이 "화면 한 장"을 만든다면, 이것은 "부품 창고 전체" 를 만든다. 개발이 앞서 나가서 코드에는 컴포넌트가 있는데 Figma에는 없는 상태를 되돌리는 용도다. 컴포넌트 하나만 만들 때도 이 스킬을 써야 한다. 컴포넌트는 변수 기반·변형(variant) 세트·토큰 연결이 갖춰져야 제대로 된 물건이기 때문이다. (원문 확인)

작업 방식 (원문 확인)

• use_figma 호출을 20~100회 이상 나눠서 진행하는 다단계 작업이다
• 단계마다 Phase N Checklist(할 일 목록)를 먼저 사용자에게 보여 주고, 그것을 올린 뒤에야 쓰기 작업을 시작한다
• 단계가 끝나면 Phase N Summary(요약)를 보고한다
• 작업 ID는 P{단계}.{스텝} 고정 형식을 쓴다 (P0.a, P1.b …)

5단계 구성 (원문 확인)

반드시 알아야 할 경고

원문이 강조한다 — "이것은 절대 한 번에 끝나는 작업이 아니다(This is NEVER a one-shot task)."

한 번에 다 만들려 하면 깨지거나, 불완전하거나, 되돌릴 수 없는 결과가 나온다. 파일 생성·라이브러리 가져오기·페이지 만들기·변수 만들기 전부 "생성 작업"으로 센다. "이건 그냥 준비 단계니까"라고 넘기면 안 된다.

6.3. /figma-use-figjam — FigJam(화이트보드) 전용

무엇을 하나

FigJam 보드에 스티키 메모, 섹션, 연결선, 도형, 표, 코드 블록, 라벨을 만든다.

FigJam만의 규칙 (Design 파일과 다른 점) (원문 확인)

초보자 주의 (원문 확인)

글자를 바꾸려면 반드시 "폰트 불러오기 → await → 수정하기" 순서를 지켜야 한다. 건너뛰면 Cannot write to node with unloaded font 오류가 난다. 또 노드 종류마다 기본 글꼴이 다르다. 스티키와 도형은 Inter Medium, 연결선은 지정 전까지 유효하지 않다. 그러니 {family:'Inter', style:'Regular'} 같은 값을 직접 박지 말고 그 노드의 현재 글꼴(node.text.fontName)을 읽어서 불러와야 한다.

get_screenshot은 유효한 nodeId가 있어야 한다. 빈 값을 넘기면 "invalid nodeId" 오류가 나므로, ID는 get_figjam으로 먼저 확보한다.

6.4. /figma-use-slides — Figma Slides(발표자료) 전용

무엇을 하나

슬라이드 덱을 새로 만들거나, 기존 덱을 고친다. 섹션(슬라이드 행) 정리와 발표자 노트도 다룬다.

generate_deck과 둘 중 하나만 고른다 (원문 확인)

환경에 generate_deck 도구가 함께 있다면, 한 덱 요청에 둘 중 하나만 쓴다. 둘 다 부르면 중복되고 충돌하는 결과물이 남는다.

가장 중요한 함정 — 좌표가 240px씩 밀린다 (원문 확인)

새로 만든 노드는 눈에 보이지 않는 슬라이드 격자 기준점 (240, 240)(GRID_PADDING)에 자동으로 붙는다. 그래서 appendChild(부모에 붙이기)보다 x/y(위치 지정)를 먼저 하면 결과가 의도한 자리에서 정확히 240씩 어긋난다.

문제는 이 버그가 간헐적이라는 점이다. 같은 스크립트 안에서도 어떤 프레임은 멀쩡하고 어떤 것만 틀어진다. 한 번 잘 됐다고 안전하다는 뜻이 아니다.

증상 판별법: 무언가가 지정한 위치에서 (−240, −240)만큼 밀려 있다면 순서가 틀린 것이다. 해결법은 240을 더해서 보정하는 게 아니라, 순서를 고치는 것이다. 보정하면 다시 실행할 때 더 나빠진다.

그 밖의 규칙 (원문 확인)

• Slides에서도 figma.createPage()는 오류 (Design 전용 기능). 구조는 SLIDE_GRID/SLIDE_ROW/SLIDE로 잡는다
• get_metadata 작동 안 함. 검사는 use_figma 읽기 전용 스크립트 + get_screenshot으로 한다
• SLIDE_GRID·SLIDE_ROW는 불투명 노드다. .fills·.effects 등에 손대면 안 된다. 예외는 SLIDE_ROW.name — 섹션 이름 변경이 이 경로다
• "고쳐 달라"는 요청에 기존 슬라이드를 지우고 새로 만들면 안 된다. 있는 것을 그 자리에서 수정한다. "처음부터 다시"라고 명시할 때만 삭제한다
• 새로 만든 Slides 파일은 슬라이드가 0장이다. figma.getSlideGrid()가 빈 배열을 돌려주므로, 첫 슬라이드가 있다고 가정한 스크립트는 깨진다

5장 이상 덱을 만들 때의 2단계 절차 (원문 확인)

1. Phase 1 — 계획: 코드를 쓰기 전에 전체 슬라이드 계획을 먼저 세운다. 슬라이드별 목적·레이아웃(픽셀이 아니라 "제목은 좌상단, 스펙 카드는 우측 1/3" 식의 공간 서술)·배경, 색 팔레트와 폰트 상수, 레이아웃 반복 점검
2. Phase 2 — 제작: use_figma 한 번에 3~5장씩 묶어 만든다. 배치 사이에 계획을 다시 세우지 않는다. 배치마다 겹침·텍스트 잘림·영역 이탈을 검사하고, 스크린샷은 첫 배치와 마지막 배치에만 찍는다

6.5. /figma-generate-diagram — 다이어그램 생성

무엇을 하나

Mermaid.js 문법(글로 쓰는 다이어그램 문법)을 받아, FigJam에 편집 가능한 다이어그램으로 그려 준다.

지원되는 것 / 안 되는 것 (원문 확인)

미지원 종류를 요청받으면 도구를 부르지 말고 지원하지 않는다고 바로 알려 주는 것이 원문의 지시다.

꼭 지켜야 할 문법 제약 9가지 (원문 확인)

1. 이모지 금지 — 도구가 거부한다
2. 라벨 안에 \n 금지
3. HTML 태그 금지
4. end, subgraph, graph를 노드 ID로 쓰지 말 것
5. 노드 ID는 userService 같은 camelCase, 띄어쓰기 금지 (밑줄도 연결선 배치를 망가뜨릴 수 있음)
6. 괄호 등 특수문자가 든 라벨은 따옴표로 감쌀 것 — A["처리 (본체)"]
7. 시퀀스 다이어그램의 Note over/Note left of/Note right of는 조용히 삭제된다. 주석이 필요하면 기본 다이어그램을 먼저 만들고 스티키·텍스트를 따로 붙인다
8. 간트 차트의 classDef·class 등 스타일 지정은 전처리에서 제거된다. 색 구분이 필요하면 생성 후 별도로 칠하거나, 아예 use_figma로 직접 만든다
9. 생성 결과가 FigJam 파일이므로, 후속 use_figma 확장도 FigJam 지원 API만 써야 한다 (figma.createPage() 금지)

한계와 운영 요령 (원문 확인)

• 만들어진 다이어그램의 글꼴 변경·도형 개별 이동·노드 단위 수정은 불가능하다. 그런 요청이 오면 Figma에서 직접 열어 고치라고 안내하는 편이 맞다. 내용을 바꾸는 것이라면 다시 생성하는 게 빠르다
• fileKey 없이 호출할 때마다 드래프트에 새 FigJam 파일이 생긴다. 4번 다시 만들면 정리할 파일이 4개다. 같은 다이어그램을 고쳐 나가는 중이라면 fileKey를 넘겨 기존 파일을 재사용한다
• generate_diagram은 자기 파일을 스스로 만들므로, 앞에 create_new_file을 부르면 안 된다
• 같은 다이어그램을 두 번 고쳐도 불만이면 계속 재생성하지 말고, 무엇이 문제인지 묻거나 Figma에서 직접 편집하도록 권한다

6.6. /figma-create-new-file — 빈 파일 만들기

무엇을 하나

사용자의 드래프트 폴더에 빈 Figma 파일을 만든다. use_figma로 뭔가 만들기 전에 대상 파일이 없을 때 쓴다. 이 스킬 역시 create_new_file 호출 전에 반드시 로드해야 하는 필수 선행 스킬이다. (원문 확인)

쓰는 법 (원문 확인)

/figma-create-new-file [editorType] [fileName]

• editorType: design(기본값) / figjam / slides
• fileName: 기본값 Untitled

예: /figma-create-new-file figjam My Whiteboard

핵심 절차 — planKey 해결

create_new_file은 planKey를 요구한다. 없으면 whoami를 호출해 plans 배열을 받고, 플랜이 하나면 그것을 쓰고 여러 개면 사용자에게 어느 팀·조직에 만들지 물어야 한다. 반환값은 file_key와 file_url이며, 이후 use_figma 호출에 file_key를 넘긴다.

Slides 주의: 이 도구로 만든 Slides 파일은 행 0개, 슬라이드 0개로 시작한다. figma.getSlideGrid()가 빈 배열을 돌려주므로, 첫 슬라이드가 존재한다고 가정한 후속 스크립트는 실패한다.

6.7. /figma-design-to-code — Figma를 읽어 코드로 옮긴다

무엇을 하나

지금까지의 스킬이 "Figma에 쓰는" 방향이라면, 이것은 반대 방향이다. get_design_context로 디자인 정보를 꺼내 실제 프로젝트의 스택으로 구현한다. get_design_context 호출 전 필수 선행 스킬이다. (원문 확인)

핵심 규칙 (원문 확인)

• get_design_context를 먼저 부른다. 한 번 호출로 참조 코드·스크린샷·힌트가 함께 온다. get_metadata나 get_screenshot으로 대체하지 않는다
• 돌아오는 React + Tailwind 코드는 참고자료이지 최종 코드가 아니다. 프로젝트의 언어·프레임워크·컴포넌트 라이브러리·스타일 체계에 맞춰 다시 쓴다
• 새로 만들기 전에 프로젝트에 이미 있는 컴포넌트와 토큰을 먼저 찾아 재사용한다
• 힌트는 우선순위대로 적용한다: ① Code Connect 스니펫 → ② 컴포넌트 문서 링크 → ③ 디자인 주석 → ④ 디자인 토큰(CSS 변수) → ⑤ 원시 hex·절대 좌표
• 아이콘·이미지는 내보낸 에셋 그대로 렌더한다. <svg>/<path>를 손으로 쓰지 않는다(진짜 벡터 데이터가 없으므로 무엇을 그리든 틀린다). 에셋 URL은 약 7일 뒤 만료되므로, 커밋할 코드라면 바이트를 내려받아 넣거나 프로젝트의 데이터 소스에 연결한다
• URL에 node-id가 없으면 추측하지 말고 노드 단위 주소를 요청한다

6.8. /figma-code-connect — 컴포넌트-코드 연결표

무엇을 하나

Figma 컴포넌트와 코드 컴포넌트를 짝지어 주는 .figma.ts 템플릿 파일을 만들고 관리한다. 이 표가 있어야 generate-design·design-to-code가 "이 버튼은 우리 코드의 어느 컴포넌트인가"를 1순위로 참조할 수 있다.

선행 조건 4가지 (원문 확인)

• Figma MCP 서버 연결
• 컴포넌트가 팀 라이브러리에 게시(publish) 돼 있을 것 — 아니면 중단
• Organization 또는 Enterprise 요금제. Free·Professional에서는 쓸 수 없다
• URL에 node-id가 포함돼 있을 것

nodeId의 하이픈은 콜론으로 바꿔야 한다(1234-5678 → 1234:5678). 이 스킬은 MCP 도구로 컨텍스트를 받아 오는 .figma.ts 템플릿 방식만 다룬다. CLI로 게시하는 파서 기반 .figma.tsx(figma.connect())는 범위 밖이다.

6.9. /figma-implement-motion과 /figma-use-motion — 모션 두 방향

이름이 비슷하지만 방향이 정반대다.

/figma-implement-motion (원문 확인)

get_motion_context가 애니메이션의 값(키프레임·이징·타이밍·사전 생성 스니펫)을, get_design_context가 구조(레이아웃·에셋·스타일)를 준다. 둘을 노드 ID로 이어 붙이는 것이 작업 전부다. 주의할 점:

• 스니펫이 있으면 그대로 쓴다. 다시 만들지 않는다 — 커스텀 베지어, 스프링 근사, 오버슛 값의 정확도가 떨어진다
• 사용자의 기존 모션 스택(Framer Motion·GSAP 등)이 있으면 거기에 맞춘다. motion.dev를 강요하지 않는다
• prefers-reduced-motion을 반드시 존중한다. 옵션이 아니라 접근성 기본값이다
• 모션 데이터가 없는 노드는 정적으로 둔다. 다른 곳의 이징·지속시간을 빌려와 "알아서" 움직이게 만들지 않는다
• 같은 애니메이션이 반복되면 스니펫을 15번 붙여 넣지 말고 재사용 컴포넌트나 variants로 한 번만 구현한다

/figma-use-motion (원문 확인)

Figma 파일 안에서 키프레임(manualKeyframeTracks)·애니메이션 스타일·타임라인 길이·이징을 다룬다. 정적인 작업(도형·컴포넌트·변수·레이아웃)은 figma-use 단독으로 가고, 이 스킬은 시간 축이 있을 때만 쓴다.

중요: 모션 API는 metronome이라는 사용자 기능 플래그로 잠겨 있다. 플래그가 없는 계정에서는 이 스킬이 참조하는 모든 속성이 "<name>" is not a supported API 오류를 낸다. 이 오류가 나면 재시도하지 말고 즉시 중단하는 것이 원문의 지시다.

검증도 까다롭다. get_screenshot은 정지 상태만 보여 준다. 실제 움직임을 확인하려면 export_video로 렌더해야 하는데, 서버 렌더라 10초에서 수 분까지 걸리고 비용도 든다. 그래서 원문은 "확인할 순간을 4~6개만 정하고, 작게(WIDTH: 320, quality: low) 낮은 fps(5)로 렌더한 뒤 ffmpeg로 프레임을 뽑아 쓰라"고 안내한다.

6.10. /figma-swiftui — SwiftUI ↔ Figma

무엇을 하나

Swift·SwiftUI·iOS·iPhone·iPad가 언급되면 켜지는 방향 라우터다. 본문 자체는 짧고, 방향을 정한 뒤 references/design-to-code.md 또는 references/code-to-design.md를 읽는 구조다. 방향이 애매하면(Figma URL과 .swift 파일이 같이 있는데 동사가 불분명한 경우) 먼저 물어본다. (원문 확인)

양방향 공통 규칙 (원문 확인)

• get_design_context 호출 시 clientLanguages: "swift", clientFrameworks: "swiftui"를 넘겨 Swift 관점으로 응답받는다
• 돌아오는 React+Tailwind는 구조 참고용이다. position: absolute나 픽셀 프레임을 SwiftUI로 그대로 옮기지 않는다. 스크린샷이 진실의 기준이다
• iOS HIG 시맨틱 색은 hex가 아니라 토큰이다. var(--labels/secondary, …) → Color.secondary 식으로 매핑을 유지하고 리터럴 RGBA는 버린다
• SF Symbols는 코드포인트가 아니라 이름으로 왕복한다. 코드→디자인 방향에서는 figma.util.getSfSymbolCharacter(name)을 쓴다
• 노드 이름이 아니라 iOS 패턴을 알아본다. 큰 제목 + 뒤로 가기 셰브론 = NavigationStack, 하단 아이콘+라벨 줄 = TabView, 같은 높이 반복 행 = List
• 코드 → 디자인 방향은 figma-use를 반드시 함께 로드한다

6.11. /generate-project-plan — 프로젝트 계획판 생성 (workflow-skills)

무엇을 하나

PRD(제품 요구사항 문서)를 입력받아 FigJam에 2단 구성의 프로젝트 계획판을 만든다. 코드베이스 경로를 함께 주면 그 내용까지 반영한다.

필요한 선행 스킬 3개 (원문 확인)

• figma-use — 세션당 한 번 로드하면 계속 유효
• figma-use-figjam — 매 use_figma 호출 직전마다 다시 로드
• figma-generate-diagram — 오른쪽 열 다이어그램 생성용

작업 순서 (9단계) (원문 확인)

핵심은 바로 그리지 않고 두 번 확인받는다는 점이다.

20개 캡에 걸리면 중단하고 expansion_truncated: true를 기록해, 사용자가 조사가 불완전했음을 알 수 있게 한다.

초보자가 알아 둘 규칙 3가지 (원문 확인)

• 섹션 이름을 빈 문자열("")로 둔다 — STRICT. FigJam이 섹션 위에 자동으로 붙이는 제목 띠를 없애기 위해서다. 실제 제목은 섹션 안쪽의 H2 텍스트가 담당한다. 이름을 넣으면 라벨이 두 개가 되어 지저분해진다
• FigJam 기본 섹션 색을 쓰지 않는다 — STRICT. 기본 팔레트(#CDF4D3, #C2E5FF 등)는 채도가 높아 다이어그램과 부딪힌다. ARCH_PALE 팔레트(#EBFFEE, #F8F5FF, #F5FBFF, #FFF7F0)를 쓴다
• 아키텍처 다이어그램은 노드 하나가 아니다. useArchitectureLayoutCode: "FIGMA_DIAGRAM_2026"으로 만든 결과는 서브그래프 섹션 1~2개 + 낱개 도형들 + 연결선이 페이지에 흩어진 형태다. 섹션으로 감싸려면 이 점을 감안해야 한다

한 번의 use_figma 호출에 논리 작업 10개까지가 상한이다.

6.12. /video-interaction-mapper — 화면 녹화를 스토리보드로 (workflow-skills)

무엇을 하나

UI 화면 녹화 영상(.mp4/.mov/.webm/.avi)에서 중요한 전후 상태를 뽑고, 무엇이 그 변화를 일으켰는지 추론해, 주석이 달린 Figma Design 스토리보드로 만든다. (원문 확인)

필요한 것 (원문 확인)

• 로컬 영상 파일 경로
• 머신에 ffmpeg와 ffprobe 설치
• Pillow가 설치된 Python
• Figma MCP 도구: create_new_file, use_figma, upload_assets, 그리고 get_screenshot 또는 get_design_context

대상은 Design 파일(figma.com/design/...)이어야 한다. 생성되는 코드가 페이지와 이미지 채우기 프레임을 만드는 Design 전용 동작이기 때문이다. FigJam이나 Slides 주소를 받으면 Design 파일을 요청하거나 새로 만든다.

이 스킬은 scripts/ 폴더의 실행 스크립트를 작업 도구로 직접 실행한다. 참고 자료가 아니라 구현체이므로, 디버깅이나 환경 적응 목적이 아니면 열어 고칠 필요가 없다.

7. 커뮤니티 스킬 10종

이 장 전체는 (미검증)이다. 아래 항목들은 Figma 커뮤니티에 공개된 외부 기여 스킬이며, 각각 별도 GitHub 저장소에서 배포된다. Figma가 동작을 보증하지 않는다. 이 문서는 이들의 SKILL.md 원문을 직접 열어 확인하지 못했고, 소개 글·목록 등 2차 출처에 근거해 정리했다. 도입 전에 저장소를 직접 열어 최신 내용을 확인할 것.

7.1. /prototype-to-figma — 시제품을 정지 화면으로

만든 곳: Amy Lima / github.com/alima-max/prototype-to-figma-skill

동작하는 코드 시제품을 여러 장의 정지된 Figma 프레임으로 변환하고, 상호작용(클릭하면 무엇이 일어나는지)을 주석으로 달아 준다.

핵심 방식 — 소스코드를 읽어 손으로 재현하지 않고, Playwright로 로컬 개발 서버를 실제로 띄워 화면을 캡처한 뒤 Figma로 옮긴다. 화면에 브라우저 창이 뜨지 않는 헤드리스(headless) 방식만 쓴다.

알려진 규칙

1. 헤드리스 캡처만 — 눈에 보이는 브라우저 창을 쓰지 않는다
2. Figma 컴포넌트를 새로 만들지 않는다 — 맞는 것이 없으면 기본 도형으로 조립하고 "시스템 이탈"로 표시한다
3. 기존 디자인 시스템의 컴포넌트·변수·텍스트 스타일을 쓴다 — 색을 hex로 박지 말고 변수를 연결한다
4. 시제품에 보이는 요소를 하나도 빠뜨리지 않는다
5. 주석은 노드에 직접 붙이고(node.annotations), 프레임당 2~4개로 제한한다

제약: 개발 서버가 실제로 돌아가고 있어야 하고, 헤드리스 브라우저도 필요하다. 쓰기 도구를 못 쓰는 환경이면 Figma 파일 대신 마크다운 명세서를 만들어 준다.

쓰는 상황: 코드로 먼저 만들어 본 결과물을 디자인 팀·기획자가 검토해야 할 때. 코드를 실행하지 않고도 Figma에서 댓글로 피드백할 수 있게 된다.

7.2. /create-voice — 접근성 명세서 생성

만든 곳: Ian Guisard (Uber) / github.com/redongreen/uSpec

Figma 컴포넌트를 읽어 VoiceOver(iOS)·TalkBack(안드로이드)·ARIA(웹) 스크린리더 명세를 만든다. "시각장애 사용자가 이 버튼에 도달했을 때 무엇이라고 읽혀야 하는가"를 개발자에게 넘길 문서로 뽑는다.

접근성 문서는 일정이 빡빡해지면 가장 먼저 잘려 나가는 작업이다. 이 스킬은 그것을 별도 문서화 단계 없이 인수인계 과정 안에 넣는다.

교육 관점: 웹 접근성(KWCAG·WCAG)을 가르칠 때 이론과 실제 산출물을 잇는 예시로 쓸 만하다.

7.3. /rad-spacing — 여백 통일

만든 곳: Nolan Perkins (Rad Collab) / github.com/nolanperk/rad-spacing

파일에 이미 등록된 여백(spacing) 변수를 읽고, 디자인 전체에 그 값들을 체계적으로 적용한다. 맞는 토큰이 없으면 대체 규칙(fallback)으로 처리한다.

여백이 어긋난 것은 컴포넌트 하나만 보면 눈에 띄지 않는다. 제품 전체를 늘어놓고 봐야 보이고, 그때는 이미 출시된 뒤인 경우가 많다.

대상: 디자인 시스템 전담 인력이 없는 1인 디자이너나 소규모 팀.

7.4. /apply-design-system — 시스템에 다시 연결

만든 곳: Chris Goebel (Edenspiekermann) / github.com/edenspiekermann/Skills

Figma 화면을 검사해서, 시스템과 연결이 끊긴 일회성 요소(one-off) 를 찾아내 올바른 컴포넌트와 토큰에 다시 이어 붙인다.

쓰는 상황

• 남이 만들다 만 파일을 넘겨받았을 때
• 디자인 시스템이 생기기 전에 만들어진 화면을 정리할 때
• 팀마다 서로 다른 라이브러리를 쓰고 있을 때

7.5. /audit-design-system — 시스템 이탈 점검

만든 곳: Chris Goebel (Edenspiekermann) — 7.4와 같은 제작자

디자인 파일을 훑어서, 게시된 디자인 시스템에서 얼마나 벗어났는지를 찾아 보고한다. 고치지는 않는다.

7.4와의 관계 — 짝으로 쓴다

audit-design-system  →  무엇이 어긋났는지 파악 (진단)
        ↓
apply-design-system  →  어긋난 것을 다시 연결 (치료)

먼저 진단하고, 그다음 고치는 순서다. 어디부터 손대야 할지 모를 만큼 파일이 많을 때 audit부터 돌린다.

7.6. /cc-figma-component + 7.7. /cc-figma-tokens — JSON 명세로 만들기

만든 곳: Nick Villapiano (One North) / github.com/nvillapiano/component-contracts-figma

구조화된 JSON 계약서(contract) 파일을 입력으로 받아, 그에 해당하는 Figma 컴포넌트(cc-figma-component) 또는 토큰 변수(cc-figma-tokens)를 만든다.

핵심 개념 — "계약서 우선" 방식

        component.json  (단 하나의 진실)
              ↓                ↓
       코드베이스          Figma 라이브러리

버튼의 크기·색·상태를 JSON에 한 번 정의하면, 코드와 Figma 양쪽이 같은 문서를 근거로 만들어진다. 사람이 손으로 옮겨 적는 단계가 사라진다.

대상: JSON 명세를 인수인계 문서로 이미 쓰고 있는 코드 우선(code-first) 팀. 그런 관행이 없는 팀에는 오히려 부담만 된다.

7.8. /edit-figma-design — Warp 터미널 연동

만든 곳: Warp(터미널 앱 제작사) / github.com/warpdotdev/figma-skills

글로 쓴 설명만 가지고 Figma 디자인을 새로 만들거나 고친다. "결제 화면 만들어 줘" 같은 문장을 받아, 디자인 시스템에서 쓸 부품을 검색한 다음 파일에 직접 그린다.

세 가지와 헷갈리지 말 것 — 스킬의 1단계가 이 구분부터 시킨다.

알려진 작업 순서

1. 무엇을 할 일인지 확정한다(위 표의 구분)
2. 대상 파일부터 정한다 — 기존 파일의 fileKey를 찾거나 새 파일을 만든다. 이걸 먼저 하지 않으면 진행하지 않는다
3. 필요한 경우에만 코드베이스·제품 맥락을 끌어온다
4. 그리기 전에 디자인 시스템을 먼저 검색해 재사용할 컴포넌트·변수·스타일을 찾는다
5. Plugin API 제약에 맞게 작업을 잘게 나눈다
6. 한 번에 다 하는 큰 스크립트 대신, use_figma를 여러 번 나눠 호출한다
7. 파일 주소와 변경 요약을 전달하고 수정 의사를 묻는다

필요 조건: Figma MCP 연결, 그리고 search_design_system·create_new_file·use_figma 세 도구. 최소한 "무엇을 그릴지 / 어느 파일에 / 기존 디자인 시스템을 따를지"는 알려 줘야 시작한다.

Warp 전용인가: 3단계의 맥락 수집이 Warp 에이전트 기능을 쓰지만, 나머지는 Figma MCP 표준 도구다. 설치는 npx skills add warpdotdev/figma-skills --skill edit-figma-design으로 하며, Claude Code·Cursor 등 다른 클라이언트도 설치된 스킬을 인식한다.

7.9. /multi-agent — 병렬 작업

만든 곳: Augment Code / github.com/AugmentedAJ/skills → augment-multi-agent-figma
(저장소 안의 실제 스킬 이름은 figma-augment-parallel)

Figma를 "살아 있는 사양서" 로 놓고, 화면 구현 작업을 여러 에이전트에 나눠 동시에 진행한 뒤, 완성된 결과를 다시 Figma로 되돌려 보낸다. 앞의 스킬들이 "Figma에 그리기"라면 이것은 Figma → 코드 → 다시 Figma의 왕복 흐름이다.

어떻게 나누나 — 프레임 하나에 에이전트 하나

frame A ─→ 에이전트 1 ─┐
frame B ─→ 에이전트 2 ─┼→ 각자 독립 구현
frame C ─→ 에이전트 3 ─┘

각 에이전트가 자기 프레임에 대해 get_design_context(구조 가져오기) → get_variable_defs(토큰 가져오기)를 돌린다. 프레임 주소는 agents.md 파일에 적어 두고 공유한다.

알려진 작업 순서

1. get_design_context — 프레임 구조를 React + Tailwind 형태로 받아온다
2. get_variable_defs — 색·여백·글꼴 토큰을 받아온다
3. get_code_connect_map — Figma 노드와 코드 컴포넌트를 짝지운다
4. 여러 에이전트가 나눠서 구현한다
5. generate_figma_design — 구현 결과를 Figma에 다시 반영해 디자이너가 검토하게 한다

반드시 지킬 제약 4가지

• 주소는 프레임 단위여야 한다. 파일 전체 주소를 주면 안 된다
• use_figma 쓰기 작업은 절대 병렬로 돌리지 않는다. 읽기는 나눠도 되지만, 쓰기는 순서대로 하나씩이다
• 작업이 실패하면 그냥 재시도하지 말고, 남아 있는 잘못된 노드를 먼저 정리한다
• Dev Mode에서 Code Connect를 미리 연결해 둬야 한다. 안 하면 디자인 시스템과 무관한 밋밋한 HTML이 나온다

호출 한도 주의 — 출처가 엇갈린다. 이 스킬의 소개는 "Pro 하루 200회, Enterprise 하루 600회"로 알려져 있으나, 플러그인 동봉 README.md가 밝히는 공식 한도는 이와 형태가 다르다(→ 8.2). 8.2의 공식 수치를 기준으로 삼고, 이 항목의 숫자는 신뢰하지 말 것.

7.10. /sync-figma-token — 토큰 불일치 탐지

만든 곳: Anish Karthik (Firebender) / github.com/firebenders/sync-figma-token-skill

Figma 변수의 값과 코드베이스의 토큰 값을 비교해서, 둘이 어긋난 지점을 찾아낸다(drift detection).

토큰 어긋남은 조용히, 천천히 벌어진다. 실제 서비스에서 색이 뭔가 이상해서 원인을 추적해 보면 몇 주 전부터 어긋나 있던 경우가 많다. 이 스킬은 그것이 출시되기 전에 드러나게 한다.

대상: Dev Mode로 인수인계하는 팀. 디자인만 정확하고 그 뒤의 토큰이 틀리면 소용없기 때문이다.

8. 조건과 제약 — 시작 전에 확인할 것

8.1. 기능·계정 조건

8.2. 호출 한도(rate limit) — 공식 기준

플러그인 동봉 README.md가 밝히는 내용이다. (공식 문서)

Figma는 이 한도를 변경할 권리를 유보한다고 명시한다.

주의: 좌석·요금제·베타 여부·과금 정책은 바뀌는 정보다. 이 장은 플러그인 v2.2.81 동봉 문서 기준, 2026-07-30 확인이며, 실제 도입 전에 Figma 공식 문서에서 다시 확인할 것.

9. 정오표 — 흔히 도는 "16종 목록"과의 차이

인터넷에 도는 "Figma 스킬 16종" 목록(공식 6 + 커뮤니티 10)을 그대로 믿으면 실제 설치본과 어긋난다. 확인된 차이는 다음과 같다.

9.1. 공식 스킬은 6개가 아니라 14개다

그 목록에서 8개가 빠져 있다. (원문 확인)

9.2. 왜 figma-use 누락이 특히 치명적인가

figma-use는 자동차 운전면허에 해당하고, figma-generate-design은 "서울에서 부산 가는 길 안내서" 에 해당한다. 길 안내서만 들고 있으면 어디로 가야 할지는 알아도, 기어를 어떻게 넣는지 모른다.

실제로 figma-generate-design 원문에는 이렇게 적혀 있다. (원문 확인)

MANDATORY: use_figma를 호출하기 전에 반드시 figma-use를 함께 불러와야 한다. 그 스킬에는 색 범위, 폰트 로딩 등 모든 코드에 적용되는 핵심 규칙이 들어 있다.

이걸 빼먹으면 나는 오류가 이런 식이다.

• 빨강을 {r:255, g:0, b:0}으로 넣음 → Figma는 0~1 범위를 쓰므로 값이 튄다
• 폰트를 불러오지 않고 글자를 씀 → Cannot write to node with unloaded font 오류
• figma.currentPage = page로 페이지 전환 시도 → Setting figma.currentPage is not supported 오류 (setCurrentPageAsync를 써야 함)

전부 원인을 짐작하기 어려운 오류다. 그래서 원문이 "이걸 건너뛰면 디버깅하기 힘든 실패가 생긴다"고 못 박았다.

9.3. 그 밖의 사실 정정