AI에게 디자인시키지 마세요 — Figma Skills가 보여준 ‘AI Critic’의 시작

AI에게 “랜딩페이지 하나 만들어줘”라고 요청하는 건 이제 별로 놀랍지 않습니다.

그런데 Figma가 최근 공개한 Skills를 보면 AI를 디자인에 쓰는 방향이 조금 다르게 흘러가고 있다는 것을 알 수 있습니다.

화면을 대신 만드는 것보다, “이 디자인에 문제가 없는지 봐줘.”, “빠진 상태를 찾아줘.”, “디자인 시스템 규칙에서 벗어난 부분을 검사해줘.” 같은 일을 AI에게 맡기는 사례가 많아지고 있습니다.

2026년 8월 13일 Figma는 Figma Agent에서 직접 Skill을 만들고, Community의 Skill을 가져와 사용하고, 자신이 만든 Skill을 공유할 수 있는 기능을 공개했습니다. 현재 Community에는 디자인 리서치부터 디자인 시스템, Handoff까지 다양한 작업을 위한 50개 이상의 Skill이 제공되고 있습니다.

처음 보면 단순히 “프롬프트를 저장하는 기능 아닌가?” 싶습니다. 하지만 조금 더 자세히 보면 꽤 중요한 변화가 보입니다.

디자이너가 오랫동안 쌓아온 판단 기준을 AI가 반복해서 사용할 수 있는 형태로 바꾸기 시작했기 때문입니다.

Figma Skill이란 무엇일까?

Figma에서 말하는 Skill은 복잡한 플러그인이나 프로그램이 아닙니다.

기본적으로는 Markdown으로 작성된 지침과 작업 순서입니다. Agent가 어떤 순서로 일을 해야 하는지, 무엇을 확인해야 하는지, 어떤 기준을 따라야 하는지를 적어두는 파일이라고 생각하면 쉽습니다. Figma 역시 Skills를 디자이너가 가진 의견과 판단 기준을 담아 Agent가 활용하게 만드는 방법으로 설명합니다.

예를 들어 한 시니어 디자이너가 UI를 리뷰할 때 항상 이런 기준을 본다고 해봅시다.

“Spacing이 8pt Grid에서 벗어나지 않았는지 확인한다.”

“Primary CTA가 한 화면에 너무 많지 않은지 확인한다.”

“에러 상태와 로딩 상태가 빠지지 않았는지 확인한다.”

“불필요한 Motion은 넣지 않는다.”

지금까지 이런 기준은 디자이너의 머릿속에 있거나, Notion이나 디자인 시스템 문서 어딘가에 적혀 있었습니다.

Skill에서는 이런 내용을 하나의 규칙으로 만들 수 있습니다.

예를 들어 /designbase-ui-review라는 Skill에 Typography, Spacing, Component, Accessibility, State, Responsive 기준을 넣어두면, Agent에게 매번 같은 내용을 처음부터 설명할 필요가 없습니다.

Skill을 만드는 과정도 Agent가 도와준다

더 흥미로운 점은 Skill 파일을 직접 처음부터 작성하지 않아도 된다는 것입니다.

Figma에서는 Frame을 선택한 뒤 해당 디자인을 참고해 Skill을 만들어달라고 요청할 수 있고, 특정 작업 절차나 Guideline을 알려준 뒤 이를 Skill로 정리해달라고 할 수도 있습니다.

Agent가 초안을 만들면 Preview에서 실행해보고, 결과가 마음에 들지 않으면 다시 수정합니다. 필요하면 Markdown Editor를 열어 직접 내용을 고칠 수도 있습니다.

즉 흐름은 꽤 단순합니다.

디자인 선택 → Skill 생성 요청 → Preview → 테스트 → 수정 → 반복 사용

일부 Skill은 Figma MCP Server를 통해 Figma 밖의 Agent에서도 활용할 수 있습니다.

이 변화의 핵심은 AI 사용 방식이 Prompt에서 Reusable Skill로 이동하고 있다는 것입니다.

매번 같은 설명을 입력하는 것이 아니라, 한 번 정리한 판단 기준을 계속 재사용하는 것입니다.

실제 Skill들을 보면 ‘생성’보다 ‘검수’가 더 흥미롭다

Figma는 이번 업데이트와 함께 Community에서 주목할 만한 Skill 10개를 소개했습니다.

그런데 목록을 살펴보면 재미있는 특징이 하나 있습니다.

물론 이미지를 만들거나 Motion을 추가하는 생성형 Skill도 있지만, 디자인을 검사하고 정리하고 보완하는 Skill이 상당히 많습니다.

Motion도 무조건 추가하는 것이 아니라 ‘빼야 할 곳’을 찾는다

Linear의 Emil Kowalski가 만든 /find-animation-opportunities는 화면을 분석해 Motion이 있으면 좋은 부분을 찾습니다.

그런데 단순히 “애니메이션을 많이 넣어주는 Skill”은 아닙니다.

오히려 움직이면 안 되는 부분까지 함께 판단합니다. 필요한 Motion을 찾으면 어디에 어떤 움직임을 넣을지 구체적인 값까지 제안하고, Figma Motion으로 직접 적용하도록 Agent에게 요청할 수도 있습니다.

이 접근은 꽤 중요합니다.

AI에게 “더 화려하게 만들어줘”라고 시키는 것이 아니라,

“여기에서 Motion이 정말 필요한가?”

를 먼저 묻기 때문입니다.

AI가 UI를 ‘Critique’한다

/better-interface는 Typography, Layout, Accessibility, Motion, Product Writing 같은 기준을 Agent에게 제공해 UI의 세부적인 완성도를 검토합니다.

/superfuture-design-review는 더 직접적입니다.

UX Heuristics, Accessibility, Visual Hierarchy, Interaction Design, Product Thinking을 기준으로 디자인을 검토한 뒤 문제의 우선순위를 Red, Yellow, Green으로 나눕니다. Red는 반드시 해결해야 할 문제, Yellow는 개선이 필요한 부분, Green은 이미 잘된 부분입니다.

여기에서 새로운 AI 디자인 Workflow가 하나 보입니다.

기존에는 Designer → AI → Design이라는 그림을 많이 떠올렸습니다.

AI에게 Prompt를 입력하면 AI가 화면을 만들어주는 구조입니다.

하지만 Skill 사례에서는 오히려 이런 방식이 더 흥미롭습니다.

Designer → Design → AI Critic → Designer Judgment

디자이너가 먼저 문제를 풀고, AI가 정해진 기준으로 검수한 뒤, 마지막 판단은 다시 사람이 하는 방식입니다.

AI가 디자이너를 대신하는 것이 아니라 두 번째 눈을 제공하는 것에 가깝습니다.

디자인 시스템 운영에서는 Skill이 더 현실적이다

AI가 버튼 하나를 예쁘게 만들어주는 기능은 처음에는 재미있지만, 실제 팀 업무에서는 반복적으로 발생하는 다른 일이 훨씬 많습니다.

컴포넌트를 정리하고, Design Token이 제대로 사용됐는지 검사하고, 문서를 작성하고, 누락된 상태를 찾는 일입니다.

Figma가 소개한 Skill들을 보면 이 영역에서 특히 현실적인 사례들이 등장합니다.

Design Token과 Hard-coded Color를 검사한다

Uber의 Ian Guisard가 만든 /create-color는 선택한 Component의 Fill, Stroke, Shadow를 분석합니다.

사용된 색상을 Design Token이나 Style과 연결하고, 직접 입력된 Hard-coded Color도 찾아냅니다. Variant와 State까지 분석해 결과를 문서화할 수 있습니다.

디자인 시스템을 운영해본 사람이라면 이 작업이 왜 유용한지 바로 알 수 있습니다.

디자인 시스템을 만들어놓아도 실제 파일에서는 특정 색상이 직접 입력되거나, 오래된 스타일이 남거나, Variant마다 규칙이 조금씩 달라지는 일이 생깁니다.

AI가 새로운 디자인을 만드는 것보다 기존 디자인이 규칙을 잘 지키고 있는지 검사하는 것이 실제 팀에서는 더 많은 시간을 줄여줄 수 있습니다.

컴포넌트 파일도 한 번에 감사한다

Walmart의 Amy Ha가 만든 /analyze-components는 Page를 훑어 컴포넌트를 검사합니다.

Orphan Component, Duplicate Component, Naming Error를 찾아내고, 문제가 있는 컴포넌트를 수정한 뒤 기존 Instance까지 교체할 수 있습니다. 마지막에는 결과를 정리한 Audit Document도 Canvas에 생성합니다.

/component-handoff는 컴포넌트 문서화에 집중합니다.

하나의 Component나 Component Set을 선택하면 이름, 버전, Owner, 설명, Live Preview, Variant Grid, Do/Don’t, Interaction과 State, Component Anatomy가 들어간 Handoff 문서를 만들어줍니다.

이런 작업은 화려하지 않습니다.

하지만 실제 실무에서 정말 귀찮고 반복적으로 발생합니다.

그래서 오히려 AI가 생성보다 운영과 유지보수에 들어올 때 훨씬 현실적인 가치가 생길 수 있습니다.

Happy Path만 만든 뒤, 빠진 상태는 AI에게 찾게 한다

UX 디자인에서 자주 발생하는 문제가 있습니다.

디자이너가 가장 이상적인 상황만 디자인하는 것입니다.

예를 들어 회원가입을 완료하고, 데이터를 정상적으로 불러오고, 결제가 성공하는 화면은 잘 만들어져 있습니다.

그런데 개발 단계가 되면 질문이 쏟아집니다.

“데이터가 없으면 어떻게 보이나요?”

“로딩 중에는요?”

“결제가 실패하면요?”

“버튼을 사용할 수 없는 경우는요?”

이른바 Happy Path 또는 Golden Path만 만들어진 상태입니다.

Paystack의 Linda Ojo가 만든 /ui-state-expander는 바로 이 문제를 다룹니다.

화면이나 Component, Flow를 선택하면 Loading, Empty, Error, Disabled, Partial Data, Edge Case와 같은 상태를 확장합니다. 여기에 각 상태가 발생하는 Trigger, 필요한 Copy, Transition, 개발 참고사항까지 함께 제공합니다.

이 Skill이 만들어진 이유도 현실적입니다.

제작자는 디자인 리뷰 때마다 “실패하면 어떻게 되나요?”, “비어 있으면 어떻게 보이나요?”라는 같은 질문이 반복되는 것을 보고, 자신의 머릿속 체크리스트를 누구나 실행할 수 있는 Skill로 바꿨다고 설명합니다.

이것이 AI를 사용하는 꽤 좋은 방법입니다.

AI에게 Happy Path 화면을 10개 더 만들어달라고 하는 것이 아니라,

내가 만든 Happy Path 하나에서 무엇을 놓쳤는지 찾아달라고 하는 것입니다.

결국 생성 능력보다 빠뜨린 것을 발견하는 능력에 AI를 사용하는 셈입니다.

UX Research 준비에도 Context가 들어간다

Skill은 UI 검사에만 사용되는 것이 아닙니다.

Figma Researcher Neha Kodi가 만든 /usability-test-guide는 선택한 User Flow를 분석한 뒤, 각 Frame 옆에 사용성 테스트용 질문을 생성합니다.

이것은 단순히 ChatGPT에게 “사용성 테스트 질문 10개 만들어줘”라고 요청하는 것과 차이가 있습니다.

Agent가 실제 디자인 Flow를 보고 있기 때문입니다.

어떤 화면에서 사용자가 무엇을 해야 하는지, Flow가 얼마나 복잡한지 등을 Context로 갖고 질문을 만들 수 있습니다.

Skill에는 참가자의 실제 Goal을 중심으로 Task를 구성하고, 답을 유도하는 질문을 피하고, Flow의 복잡도에 따라 질문량을 조절하는 Research 원칙도 포함되어 있습니다.

즉 구조는 이렇게 됩니다.

Design Context + Research Rule → Usability Test Guide

Prompt 자체보다 현재 디자인과 전문가의 규칙이 함께 주어지는 것이 중요해지는 것입니다.

결국 디자이너의 ‘노하우’가 파일이 되고 있다

이번 Figma Skills 업데이트에서 가장 주목할 부분은 새로운 메뉴가 하나 생겼다는 사실이 아닙니다.

디자이너가 가지고 있던 암묵적인 판단을 파일로 만들 수 있게 됐다는 것입니다.

시니어 디자이너에게는 경험을 통해 쌓인 수많은 기준이 있습니다.

“이 상황에서는 Modal보다 Inline Feedback이 낫다.”

“이 정도 Interaction에는 Motion을 넣지 않는다.”

“Error Message는 문제만 말하지 말고 다음 행동을 알려줘야 한다.”

“Primary CTA는 한 화면에서 경쟁하면 안 된다.”

이런 지식은 디자인 시스템의 Button Component만 봐서는 알기 어렵습니다.

Design System과 Skill은 무엇이 다를까?

Design System은 주로 무엇을 사용할 것인가를 정의합니다.

어떤 Color Token을 사용할지, Button은 어떻게 생겼는지, 어떤 Typography Style을 사용할지 알려줍니다.

Skill은 조금 다릅니다.

어떻게 판단할 것인가를 정의할 수 있습니다.

예를 들어 Design System에는 Modal Component가 존재할 수 있습니다.

하지만 Skill에는 “사용자가 현재 작업을 중단해야 할 정도로 중요한 상황이 아니면 Modal 사용을 피한다.”

같은 판단 기준을 넣을 수 있습니다.

이 차이는 상당히 큽니다.

Design System = UI의 표준화라면, Design Skill Library = 디자인 판단 방식의 표준화라고 볼 수 있습니다.

앞으로 AI-Ready Design System을 만든다면 Component와 Token만 정리하는 것으로 끝나지 않고, 팀이 어떤 기준으로 디자인을 리뷰하고 결정하는지까지 AI가 읽을 수 있는 형태로 정리하는 일이 중요해질 수 있습니다. 이는 Figma가 Skills를 팀의 의도와 판단을 Agent에 전달하는 방식으로 설명하는 방향과도 맞닿아 있습니다.

AI 시대에는 ‘Generator’보다 ‘Critic’이 더 중요해질지도 모른다

AI 디자인 이야기는 오랫동안 생성에 집중돼 있었습니다.

“한 문장으로 앱을 만들어준다.”

“몇 초 만에 랜딩페이지를 만든다.”

“디자인 Variation을 20개 생성한다.”

하지만 생성 비용이 계속 낮아지면 새로운 문제가 생깁니다.

만드는 것은 쉬운데 무엇이 좋은지 판단하는 일이 더 어려워집니다.

최근 Designlab의 UX·Product Designer 조사에서도 비슷한 문제가 나타났습니다. 응답자의 56.8%가 AI 때문에 디자인 품질이 떨어질 가능성을 우려했고, AI가 만든 결과물을 완전히 신뢰한다고 답한 비율은 1.6%에 불과했습니다. 결과가 겉보기에는 그럴듯해도 실제 사용성 문제나 검증되지 않은 판단이 숨어 있을 수 있다는 우려입니다.

이 상황에서 Figma Skills의 실제 사례들은 꽤 흥미로운 방향을 보여줍니다.

AI에게 더 많이 만들라고 하기보다, 검사하게 하고, 비교하게 하고, 누락을 찾게 하고, 규칙을 적용하게 하는 것입니다.

앞으로 AI 디자인 Workflow가 이런 식으로 바뀔 수도 있습니다.

Design → AI Critic → Human Judgment → Improve

AI가 최종 심사위원이 되는 것은 아닙니다.

Skill에 들어 있는 기준 역시 누군가가 만든 기준이기 때문에 틀릴 수도 있고, 프로젝트의 맥락과 맞지 않을 수도 있습니다.

그래서 마지막 판단은 여전히 디자이너에게 남습니다.

하지만 매번 놓치기 쉬운 항목을 반복해서 검사해주는 일관된 Critic이 옆에 하나 생긴다면 이야기는 달라집니다.

디자이너에게 중요한 능력도 조금 달라진다

Figma Skills가 보여주는 변화는 “디자이너가 필요 없어졌다”와는 거리가 멉니다.

오히려 AI가 실행을 더 많이 담당할수록 디자이너의 판단을 얼마나 잘 설명하고 구조화할 수 있는가가 중요해집니다.

좋은 디자이너는 앞으로 화면 하나를 잘 만드는 것뿐 아니라 자신의 판단을 이런 식으로 설명할 수 있어야 할지도 모릅니다.

“왜 이 UI가 문제인가?”

“어떤 기준에서 잘못됐는가?”

“어떤 상황에는 이 규칙을 적용하지 않아야 하는가?”

“사용자에게 미치는 영향의 우선순위는 무엇인가?”

이런 기준을 잘 설명할 수 있다면 그것을 Skill로 만들고, 팀 전체가 재사용하고, Agent가 반복적으로 실행할 수 있습니다.

즉 디자이너의 경쟁력이 단순한 제작 능력에서 판단 기준을 만드는 능력으로 조금씩 이동하는 것입니다.

Figma Skills의 진짜 의미는 ‘프롬프트 저장’보다 크다

Figma Skills를 가장 단순하게 보면 Markdown으로 작성된 재사용 가능한 Prompt입니다.

하지만 실제 Community 사례를 살펴보면 그보다 조금 더 큰 가능성이 보입니다.

Motion을 어디에 넣을지 판단하고, UI를 Critique하고, Token을 검사하고, Component를 Audit하고, 빠진 State를 찾고, Handoff 문서를 만들고, Usability Test를 준비합니다.

이 작업들의 공통점은 하나입니다.

AI가 디자이너 대신 창의적인 결정을 내리는 것이 아니라, 디자이너가 이미 가지고 있던 전문적인 판단을 반복적으로 실행한다는 것입니다.

Design System이 팀의 UI를 표준화했다면, 앞으로 Skill Library는 팀의 디자인 판단 방식을 표준화할 수도 있습니다.

그리고 생성 AI가 누구나 빠르게 결과를 만들 수 있게 하는 시대라면, 오히려 더 중요한 능력은 많이 만드는 것이 아니라 잘 검수하고, 잘 버리고, 잘 판단하는 능력일지도 모릅니다.

Figma Skills는 그 변화를 꽤 구체적인 형태로 보여주기 시작했습니다.

참고 자료

Figma, 「Try these 10 skills—and show off your own」, 2026년 8월 13일. Figma Agent의 Skill 제작 방식과 Community Skill 10개 사례를 소개한 공식 글입니다.

Figma Release Notes, 2026년 8월 13일. Community의 50개 이상 Skills 탐색, Agent를 통한 Skill 생성, Community 게시 기능이 추가됐습니다.