[34호] 피그마가 스킬의 새로운 저장소가 될 수 있을까

안녕하세요, 구독자님. 여의도에 서식 중인 몽글c입니다.

이전 발행한 메이커스 노트 22호에서 AI 시대의 새로운 업무 문법으로 'Skill'을 소개한 적이 있습니다. 좋은 프롬프트를 넘어, 반복 가능한 업무 방식을 설계하는 법에 대한 이야기였죠.

그런데 Skill을 만들고 나면 다음 질문이 남습니다. 이 Skill을 어디에 두어야 동료들도 찾아 쓰고, 함께 개선할 수 있을까요? 

문제 정의를 돕는 질문, 디자인 리뷰의 체크리스트, UX 문구를 다듬는 기준. 이런 노하우가 개인 메모장과 채팅 기록에 흩어져 있다면 다른 사람이 활용하기 어렵습니다. 만든 사람에게 매번 물어봐야 하고, 무엇이 최신인지도 알기 어렵죠. 

오늘은 디자이너에게 익숙한 피그마를 중심으로, Skill을 개인의 도구에서 팀의 자산으로 옮기는 방법을 이야기해보려 합니다.

1. 디자인 결과물 옆, 일하는 방식도 모아둘 수 있을까

디자인 조직은 이미 디자인된 결과물을 공유하는 데 익숙합니다. 컴포넌트를 라이브러리로 만들고, 디자인 시스템에 사용 기준을 정리하고, 좋은 사례를 함께 리뷰합니다. Skill에도 비슷한 접근을 해볼 수 있다고 생각해요.

예를 들어 디자이너가 화면을 디자인할 때는 나름의 순서가 있습니다. 사용자의 니즈(Needs)를 확인하고, 정보의 우선순위(Priority)를 살피고, 사용자의 니즈와 우선순위에 따른 화면들을 설계하게 됩니다. 이 일련의 과정안에서 나오는 결과물들을 만들 때, 그리고 그 결과물들에 대한 기준에 따라 평가 등을 진행할 때 디자이너 각자의 기준들이 있습니다. 이 기준을 Skill로 만들어둔다면 다른 동료들이 만든 해당 skill을 통해 그들의 노하우들을 자신의 화면에 적용해볼 수 있는 것이죠. :)

컴포넌트가 반복해서 쓰는 디자인 요소라면, Skill은 반복해서 적용할 업무 절차와 판단 기준을 담는 방식이라고 할 수 있어요. 다만 문서에 적힌 기준만으로 숙련자의 판단을 모두 재현할 수는 없을거예요. 실행 결과를 사람이 검토하며 기준을 보완해야 한다고 생각해요.

2. 피그마를 저장소의 시작점으로 보는 이유

피그마의 Custom Skills는 반복 업무를 마크다운 지침으로 정리해 Figma agent와 Figma Make에서 활용하는 기능입니다. 등록한 Skill은 /skill-name 같은 슬래시 명령어로 호출할 수 있습니다. (Figma 공식 가이드)

이 기능을 저장소 관점에서 보면, 매력적인 부분은 디자이너의 작업 공간 안이라는 것입니다. (정말 큰 장점이라 생각해요) 화면을 작업하는 흐름 안에서 검수 기준을 불러올 수 있으니까요. 피그마를 매일 사용하는 팀이라면 Skill을 찾아 쓰는 습관도 연결하기 쉬울 것입니다. 

물론 GitHub를 활용할 수 있는 조직은 그 환경을 계속 활용하면 됩니다. 이번 글에서 제안하는 것은 피그마를 디자이너가 Skill을 발견하고 실행하는 접점으로 활용하자는 것입니다. 원본을 보관하고 변경을 관리하는 공간은 조직의 환경에 맞게 함께 정할 수 있습니다. 

이 글을 읽고 계신 독자분이 금융권에 계시다면, 한 가지 살펴볼 내용도 있습니다. 피그마 사용이 승인되어 있더라도 AI 기능과 데이터 처리 범위까지 같은 조건으로 승인된 것은 아닐 수 있습니다. 실제 운영은 조직에서 허용한 기능과 자료 범위 안에서 시작해야 하니, 확인은 필수입니다. :)

3. 첫 Skill은 작고 구체적인 업무로 시작하기

처음부터 ‘좋은 디자인을 만드는 Skill’!!! 을 만들고자 하신다면 하면 범위가 너무 넓습니다. 대신 반복해서 확인하는 업무 하나를 골라보는 것은 좋은 꿀팁입니다.

피그마에서는 에이전트에게 생성을 요청하거나, 직접 작성하거나, 기존 .md 파일을 업로드할 수 있습니다. 업로드는 단일 마크다운 파일 방식이며, 별도 scripts/, references/, assets/ 폴더는 지원하지 않습니다. 다른 환경의 Skill을 옮길 때는 이 차이를 확인해야 합니다. (Figma 공식 가이드)

Skill을 작성할 때는 최소한 아래 다섯 가지를 담아보세요. 🖐 

아래에 실무에서 시작해볼 수 있는 (제 생각에 유용해보이는) 예시를 생성요청 prompt와 함께 정리해보았습니다. 각 사례의 ‘생성 요청 예시’ prompt를 피그마 에이전트에게 전달하고, 조직의 기준에 맞게 다듬어보세요. 제시한 이름은 '완전!' 예시이며, 실제 호출하려면 해당 이름으로 Skill을 등록하시면 됩니다.

① /design-critic — 디자인 크리틱

화면을 만들고 나면 ‘핵심 정보가 잘 보이는지’, ‘사용자가 다음 행동을 알 수 있는지’를 다시 살펴보게 됩니다. 이때 자주 쓰는 검토 기준을 Skill로 정리해두면, 동료 리뷰 전에 스스로 점검하는 데 활용할 수 있습니다. 

생성 요청 예시 

결과는 ‘검토 항목 / 관찰 내용 / 판단 근거 / 개선 제안’ 표로 받도록 정할 수 있습니다. ‘시니어 디자이너처럼 평가해줘’보다 무엇을 근거로 평가할지 구체적으로 적는 것이 중요합니다. 

② /typo-correction — 오타·표기 검수

화면이 많아지면 오타나 띄어쓰기, 금액과 단위의 표기 차이를 놓치기 쉽습니다. 반복해서 확인하는 항목을 Skill로 묶어두면, 디자인 전달 전 검수를 보조하는 데 활용할 수 있습니다. 

생성 요청 예시 

수정안을 먼저 확인한 뒤 반영하는 방식으로 시작하면 좋습니다. AI가 놓치는 오류도 있으므로, 실행을 마쳤다는 이유만으로 모든 문구의 검수가 끝났다고 판단하지는 않아야 합니다. 

③ /ux-writing-check — 조직의 UX 라이팅 기준 검수

오타 검수가 문장의 정확성을 확인한다면, UX 라이팅 검수는 조직이 정한 표현 기준을 확인합니다. 종결어미, 버튼 문구, 오류 안내 방식처럼 매번 가이드를 찾아보는 항목을 Skill에 담아볼 수 있습니다. 

생성 요청 예시 

여기서는 우리 조직의 UX 라이팅 가이드가 핵심입니다. (아직 존재하지 않는다면 메이커스 노트 11호를 참고해주세요) ‘버튼은 항상 ~하기로 쓴다’ 같은 일반적인 예시를 그대로 적용하기보다, 실제 조직에서 서비스를 위해 합의된 기준과 예외 사항을 넣었을 때 우리 조직 만의 skill로서 의미가 있을 것 입니다.

4. 직접 테스트하고, 동료의 피드백으로 다듬기

Skill을 만들었다면 먼저 실제 업무에서 직접 실행해보세요 . 요청한 항목을 빠뜨리지 않는지, 결과가 원하는 형식으로 나오는지, 근거 없이 내용을 덧붙이지 않는지 확인합니다. 문제가 보이면 지침을 수정하고 다시 실행해보면 됩니다. 

배포하기 전에는 동료의 피드백도 꼭 한 번 받아보세요. Skill의 설명과 실행 결과를 함께 보여주고, 가능하면 직접 사용해보도록 부탁하는 것입니다. (서비스 오픈 전에 Usability Test하는 맘..)

피드백은 세 가지 정도로 시작하면 충분합니다. 1) 언제 쓰는 Skill인지 이해되는지, 2) 결과가 실제 업무에 도움이 되는지, 3) 빠지거나 불필요한 내용은 없는지. 만든 사람에게는 당연한 설명이나 절차가 다른 사람에게는 모호할 수도 있으니까요.

조직 내에서 활용할 준비가 되면 피그마의 Manage skills → Publish → Private에서 팀 또는 조직에 배포할 수 있습니다. 팀 배포는 해당 파일이 속한 팀을 대상으로 하며, 수정한 지침은 Publish changes로 배포합니다. (Figma 공식 가이드)

권장하는 운영 흐름은 단순합니다. 만든다 → 직접 테스트한다 → 동료의 피드백을 받는다(나름의 UT) → 보완해 배포한다. 배포한 뒤에도 실제 사용에서 나온 의견을 반영해 조금씩 개선해가면 됩니다. 

5. 저장소가 계속 쓰이려면 필요한 것들

Skill이 많아지면 비슷한 이름이 늘고, 어떤 것이 최신인지 알기 어려워집니다. 처음부터 거창한 관리 시스템을 만들 필요는 없지만, 최소한의 운영 정보는 함께 정해두는 편이 좋습니다. 

이 정보는 별도의 목록에 나누어 기록할 수 있습니다. 예를 들어 피그마에 Skill 안내 페이지를 만들고, 업무별 사용법과 담당자, 피드백 위치를 정리해두는 방식입니다. 중요한 것은 동료가 만든 사람에게 묻지 않고도 사용 할 수 있게 하는 것입니다. 

원본 지침도 보관해두세요. 피그마는 md 파일을 불러와 skill을 만들 수도 있지만, 만들어진 skill에서 부터 md파일 내보내기도 지원합니다. 변경 전후 원본과 기록을 별도로 남겨두면 좋습니다.

Skill이 공유되었다고 '판단'까지 자동으로 완성되는 것은 아닙니다. 어떤 기준을 적용할지, 무엇을 고칠지 결정하는 책임은 여전히 사람에게 있습니다. 저장소는 그 판단에 필요한 절차와 근거를 팀이 함께 활용하도록 돕는 공간입니다. 

여러분의 조직은 어떤 Skill을 함께 쓰고 싶나요?

피그마를 디자인 결과물뿐 아니라 일하는 방법을 공유하는 공간으로 활용해볼 수 있습니다. 처음에는 자주 쓰는 검수 기준 하나를 Skill로 정리하고, 동료 두세 명과 써보는 것으로 시작해도 좋겠습니다. 

그리고 위에서 이야기한 것과 같이 조직 내에서 직접 skill을 만들어 사용하는 것도 방법이지만, 아래와 같이 이미 누군가 잘 만들어둔 skill을 가져와 사용하는 것도 고민해보세요.

Figma에서는  AI Skills Library를 운영하고 있어, 필요한 스킬들은 복사해서 직접 적용하고 사용하면 됩니다. (여기도 검증된 유용한 스킬들이 꽤 존재합니다)

Figma AI Skills Library

Figma를 Skill의 저장소로 활용하면서, 업무의 기준은 더 명확해지고 동료들의 경험도 더해질 것입니다. 이렇게 다듬은 Skill이 다음 사람도 활용할 수 있는 형태로 남는다면, 개인의 노하우는 팀의 자산으로 쌓이게 될 것입니다.

함께 쓰는 Skill이 늘어나면, 무엇을 유지하고 누가 개선하며 어떻게 최신 상태로 관리할지도 고민하게 되겠죠. 메이커스 노트 32호에서 다뤘던 Agent 관리의 문제가 우리 팀의 과제가 되는 것입니다. ㅎ_ㅎ;

그 출발점은 동료와 함께 써보는 Skill 하나입니다. 여러분의 팀에서 가장 먼저 함께 쓰고 싶은 Skill은 무엇인가요? 

Reference

📮 다음 호 예고

[35호] 빨라진 구현, 느려진 실행

AI 덕분에 만드는 속도는 빨라졌습니다. 하지만 화면의 문구 하나를 바꾸는 일도 다른 시스템이 그 값을 판단 기준으로 쓰고 있다면 단순한 수정이 아니라 약속을 바꾸는 일이 됩니다. 문제는 되돌릴 수 있느냐보다, 잘못됐다는 사실을 알아챌 수 있느냐에 있었습니다. 다음 호에서는 AI가 먼저 만들어도 되는 일과 제안까지만 맡겨야 하는 일을 어떻게 구분할지 이야기해볼게요.

✉️ 다음 호가 궁금하신 분들은 아래 [구독하기] 버튼을 눌러주세요.