Figma Make 사용법: 디자인 시스템을 지키는 커스텀 스킬 3종

브랜드 기준을 벗어난 채 출시된 빌드

검토용 빌드는 거의 맞아 보였습니다. 바로 그래서 더 위험했습니다. 리브랜딩 이후 줄곧 8px로 고정된 시스템인데 버튼 모서리 반경은 12px였습니다. 기본 강조색도 #18C5DA에 가까웠습니다. 클라이언트의 #06B6D4와 눈으로 보기에는 비슷했지만, Figma 색상 선택기에 붙여 넣자 차이가 즉시 드러났습니다. 세 번째 프레임에 이르자 본문 글자 크기는 시스템 규격인 16px가 아니라 18px로 바뀌어 있었습니다.

그날 아침에 작성한 프롬프트가 잘못된 것은 아니었습니다. 문제는 여섯 번 전에 작성한 프롬프트였습니다. Figma Make는 세션 안에서 맥락을 유지하지만, 디자인 시스템 규칙은 처음 입력한 지점에서 멀어질수록 흐려집니다. 세 번째 히어로 변형을 다듬을 즈음이면 모델은 그럴듯해 보이는 토큰 값을 임의로 만들어 냅니다. 2026년 5월 릴리스 노트는 커스텀 스킬이 바로 이 간극을 메우기 위한 기능이라고 설명합니다. 다시 붙여 넣을 필요 없이 모든 프롬프트에 불러올 수 있도록 지침을 하나의 패키지로 묶는 방식입니다. (Figma 2026년 5월 릴리스 노트 모음)

아래 스킬 팩을 만든 뒤 같은 브리프를 Make에서 다시 실행했습니다. 버튼 모서리 반경은 8px, 강조색은 #06B6D4, 본문은 16px로 나왔습니다. 스킬이 Make를 더 똑똑하게 만든 것은 아닙니다. 규칙을 잊지 못하게 만들었을 뿐입니다.

Figma 디자인 시스템이 실제로 요구하는 기준

이 글에서 다루는 시스템은 실제 클라이언트의 디자인 시스템입니다. 민감한 부분을 정리한 토큰은 다음과 같습니다.

• 색상: 배경 #0A0E14, 전경 #E6EDF3, 단일 강조색 #06B6D4. 보조 강조색과 그라데이션은 사용하지 않습니다.
• 간격: 기준은 8px입니다. 허용 스케일은 8 / 16 / 24 / 40이며, 그 사이 값이나 범위를 벗어난 값은 쓰지 않습니다.
• 타입 스케일: 14 / 16 / 20 / 32 / 48. 본문은 16이며 18은 사용하지 않습니다.
• 모서리 반경: 모든 인터랙티브 표면은 8px, 카드는 0입니다. 예외는 없습니다.
• 버튼: 하나의 컴포넌트에 기본, 호버, 비활성화의 세 가지 상태가 있습니다. 기본 상태는 강조색으로 채우고, 비활성화 상태는 전경색을 30% 불투명도로 적용합니다.

이 항목들은 "브랜드 가이드를 따라 주세요" 같은 일반적인 프롬프트로는 지켜지지 않습니다. 형용사는 해석의 여지를 남기기 때문입니다. "차갑고 미니멀하며 강조색은 하나"라는 설명에 들어맞는 시스템은 수천 개입니다. 모델에 필요한 것은 무드보드가 아니라 표입니다. 목표는 매 세션마다 이 표를 다시 입력하지 않아도, 이 클라이언트를 위한 모든 Make 빌드가 표의 기준을 통과하게 만드는 것입니다.

Figma Make 사용법의 핵심: 실제 .md 파일로 만든 3종 스킬 팩

Figma Make의 커스텀 스킬은 Agent Skills 사양을 따르는 단일 Markdown 파일입니다. 프런트매터의 name이 슬래시 명령이 됩니다. 스킬은 계정별로 설치되며, 본인이 소유한 모든 Make 파일에서 계속 사용할 수 있습니다. 중요한 제약도 있습니다. 반드시 자체 완결형이어야 하므로 scripts/, references/, assets/ 디렉터리를 둘 수 없습니다. 모델이 사용할 내용은 모두 지침 안에 직접 넣어야 합니다. (Figma Make 커스텀 스킬 도움말)

제가 반복해서 입력하던 내용의 90%는 스킬 세 개로 해결됐습니다.

/follow-ds-guidelines

토큰 표를 지침에 그대로 넣은 스킬입니다. 해석도, 형용사도 개입하지 않습니다.

---
name: follow-ds-guidelines
description: Enforce the client design system on every generated frame.
---

You are building inside a locked design system. Use these exact values.
Do not improvise alternates, do not interpolate, do not soften.

## Color
- background: #0A0E14
- foreground: #E6EDF3
- accent: #06B6D4 (single accent, no secondary)

## Spacing (8px base)
- allowed: 8, 16, 24, 40
- forbidden: any value not in the allowed list

## Type ramp
- 14 / 16 / 20 / 32 / 48
- body is 16. never 18.

## Radius
- interactive surfaces: 8
- cards: 0

## Button (one component, three states)
- default: fill #06B6D4, foreground #0A0E14
- hover: fill #06B6D4 at 90% opacity
- disabled: foreground #E6EDF3 at 30% opacity

If a request would produce a value outside this table, return the closest
allowed value and flag the substitution in a comment.

/design-crit

현재 프레임을 토큰 표와 대조해 검사하는 리뷰 스킬입니다. 각 항목의 통과 여부를 표시하고, 문제가 있는 값은 HEX 색상 코드와 픽셀 값으로 정확히 짚어 줍니다.

---
name: design-crit
description: Audit the current frame against the client design system.
---

Walk the current frame top to bottom. For every visual element, check:
- color hex against the allowed palette
- spacing values against the 8 / 16 / 24 / 40 scale
- type size against the 14 / 16 / 20 / 32 / 48 ramp
- radius against 8 (interactive) or 0 (cards)

Return a table:
| Element | Property | Found | Expected | Pass/Fail |

End with a one-line verdict: PASS if all rows pass, FAIL otherwise.
Do not auto-fix. The human decides which deviations are intentional.

/insert-sample-data

샘플 데이터 스킬은 클라이언트가 승인한 플레이스홀더 문구를 넣습니다. 덕분에 검토용 빌드에 lorem ipsum이 남거나, 모델이 만든 회사 이름 때문에 나중에 법무 검토에서 문제가 생기는 일을 막을 수 있습니다. (2026년 5월 릴리스 노트 모음)

---
name: insert-sample-data
description: Replace placeholder text with approved sample data.
---

When asked for sample content, use only this set:

## Names
Sarah Chen, Marcus Okafor, Priya Raman, Diego Alvarez

## Company names (fictional, cleared)
Northwind Labs, Apex & Vine, Halcyon Group, Stratus Co

## Numbers
Use round numbers in product UI: 1,240 / 3,500 / 12,800.
Avoid revenue-shaped numbers unless asked.

Never use lorem ipsum. Never invent a real-sounding brand name not on this list.

파일은 세 개뿐입니다. 각각 제가 예전에는 매번 다시 붙여 넣던 내용을 대신합니다.

Notion 커넥터로 최신 디자인 시스템을 읽게 하는 방법

/follow-ds-guidelines처럼 토큰을 고정해 넣는 방식은 변하지 않는 시스템에서 잘 작동합니다. 하지만 클라이언트가 토큰을 수정하는 순간, 그리고 수정은 반드시 일어납니다, 인라인 표는 낡은 정보가 됩니다. 해결책은 스킬을 커넥터와 함께 사용해 Make가 최신 원본을 가져오게 하는 것입니다. (Figma Make 커넥터 도움말)

이 클라이언트의 파일에서는 디자인 시스템을 하나의 Notion 페이지에 관리합니다. 페이지 제목 구성도 스킬과 동일하게 Color, Spacing, Type ramp, Radius, Button으로 맞췄습니다. 하나의 프롬프트에서 스킬과 커넥터를 함께 호출합니다.

Use the /follow-ds-guidelines skill, but pull the current token values
from @Notion "Halcyon – Design System v3" and override the inline table
where they differ. Then build the pricing section per the attached spec.

같은 방식으로 하나의 프롬프트에서 Drive의 PRD도 가져올 수 있습니다. @Drive "Halcyon pricing PRD"를 지정하면 Make가 디자인 시스템과 사양의 맥락을 한 번에 조합합니다. (2026년 5월 릴리스 노트 모음)

클라이언트별로 판단 기준은 간단합니다. 한 분기 동안 바뀌지 않은 시스템은 토큰을 인라인으로 두고, 아직 계속 변하는 시스템은 커넥터에서 가져옵니다. 두 경우 모두 스킬의 .md는 그대로이고 프롬프트만 달라집니다. 일부러 이렇게 설계했습니다. 클라이언트마다 스킬이 늘어나는 상황 대신, 외부 값으로 덮어쓸 수 있는 스킬 하나를 원했기 때문입니다.

참고로 Figma MCP 서버의 /prototype-to-figma 스킬은 전혀 다른 영역의 기능입니다. 코드와 캔버스를 오가는 작업을 위해 미리 설치되어 있으며 사용자가 직접 작성하지 않습니다. 커스텀 Make 스킬은 그 반대입니다. 사용자가 직접 작성하고 Make 안에 존재하며 MCP 계층에는 관여하지 않습니다.

실제로 부딪힌 한계: 비결정성과 공유 비용

발표 내용만으로는 알기 어려웠던 문제가 세 가지 있었습니다.

지원 모델은 문서에서 느껴지는 것보다 제한적입니다. 현재 커스텀 스킬은 Figma Make 기본 모델과 Claude Opus 4.7에서만 작동합니다. 팀이 Make에서 다른 모델을 표준으로 쓰고 있다면 스킬이 적용되지 않습니다. 눈에 띄는 오류도 없이 그저 조용히 규칙 적용을 멈춥니다. (Figma Make 커스텀 스킬 도움말) 팀 빌드에서 "모서리 반경이 또 왜 틀렸지?"를 디버깅하기 전에 가장 먼저 확인하는 항목입니다.

결과는 동일한 것이 아니라 "매우 자주" 일관됩니다. Figma 공식 문서도 그렇게 설명합니다. 모델은 비결정적이므로 /design-crit이 복잡한 프레임에서 이탈 항목을 간혹 놓치거나, 의도된 값을 문제로 표시할 수 있습니다. (Figma Make 커스텀 스킬 도움말) 따라서 이 리뷰 스킬은 빠른 첫 검사로 활용할 뿐, 최종 승인으로 간주하지 않습니다.

운영 관점에서 가장 큰 문제는 공유 비용입니다. 현재 커스텀 스킬은 계정별로 관리됩니다. 팀원에게 스킬 팩을 전달하려면 .md 파일을 내보낸 뒤 각자가 자기 계정에 업로드해야 합니다. 조직 전체에 배포하는 기능은 없습니다. (Figma Make 커스텀 스킬 도움말) 여러 클라이언트 시스템을 운영하는 스튜디오에는 분명한 마찰입니다. 새 팀원이 들어올 때마다 활성 스킬을 일일이 설치해야 하고, 스킬이 업데이트될 때마다 다시 내보내야 합니다. 해결책은 평범하지만 효과적입니다. .md 파일을 클라이언트 저장소에서 버전 관리하고, 저희처럼 같은 모노레포의 디자인 토큰 옆에 둔 다음 릴리스 태그를 붙입니다. 그러면 업로드할 파일의 기준이 Slack 메시지가 아니라 하나의 원본으로 정리됩니다.

이처럼 좌석별 부담이 있는 플랫폼에서 작업하는 디자이너라면 스튜디오 운영 관점도 함께 봐야 합니다. 제가 Webflow 프리미엄 플랜의 비용 구조를 따로 다룬 이유도 같습니다. 툴은 표면에 드러난 기능에 가격을 매기지만, 실제 사용자는 그 아래의 통합 마찰까지 비용으로 치릅니다.

스킬에 맡길 일과 사람이 판단할 일

DVNC.studio에서 몇 주간 사용한 뒤 세운 원칙은 간단합니다. 두 번 넘게 다시 입력한 내용은 스킬로 옮깁니다. 토큰 표, 리뷰 체크리스트, 샘플 데이터 규칙, 접근성 주석용 상용구가 여기에 해당합니다. 어느 것도 창의적인 작업은 아니지만, 모두 반복 비용을 만듭니다.

사람에게 남겨야 할 것은 판단입니다. /design-crit은 시스템을 벗어난 값을 찾아내지만, 그것이 실수인지 일회성 마케팅 화면을 위한 의도적 예외인지는 결정하지 못합니다. 스킬은 "이 모서리 반경은 12인데 기준은 8입니다"라는 판단에는 능합니다. 그러나 "캠페인 콘셉트에 더 부드러운 카드가 필요해 화요일에 합의했기 때문에 반경이 12입니다"라는 맥락까지는 판단하지 못합니다. 그 결정이 바로 사람이 해야 할 일입니다.

다음 주 화요일에는 가장 자주 사용하는 클라이언트 시스템 하나를 고릅니다. .md 파일을 열고, 위에서 Halcyon 토큰을 넣은 방식대로 토큰 표를 붙여 넣습니다. 파일 이름은 follow-ds-guidelines.md로 저장하고 커스텀 스킬로 업로드합니다. 실제 빌드 하나에 적용한 다음 결과물에 /design-crit을 실행하고, 토큰 표와 직접 비교합니다. 스킬이 사람이 잡아낼 문제를 제대로 찾아낸다면 클라이언트당 매주 한 시간씩 들던 반복 프롬프팅을 없앤 셈입니다. 명백한 문제를 놓친다면 고쳐야 할 곳은 프롬프트 기록이 아니라 .md입니다.