피그마에 Skill을 모으기 전에, 그 기준은 누구의 것인가

피그마에 Skill을 올리는 방법은 세 가지입니다. 에이전트에게 만들어달라고 하거나, 직접 쓰거나, 기존 .md 파일을 업로드하거나. 그런데 업로드는 마크다운 파일 하나만 받고, scripts/, references/, assets/ 같은 폴더는 지원하지 않습니다. 메이커스노트 34호에서 몽글c가 피그마를 Skill의 새 저장소로 제안하며 지나가듯 적은 제한인데, 저는 이 한 줄이 제안의 범위를 정확히 그어준다고 봐요. 피그마는 모든 Skill을 담는 저장소라기보다, 체크리스트형 Skill을 디자이너 손 닿는 곳에 꽂아두는 배포 창구에 가깝습니다.

왜 하필 피그마인가

제안의 출발점은 공감이 갑니다. 문제 정의를 돕는 질문, 디자인 리뷰 체크리스트, UX 문구를 다듬는 기준 같은 노하우가 개인 메모장과 채팅 기록에 흩어져 있으면 다른 사람이 쓰기 어렵고, 무엇이 최신인지도 모르죠. 컴포넌트가 반복해서 쓰는 디자인 요소라면 Skill은 반복해서 적용할 업무 절차와 판단 기준이니, 컴포넌트처럼 모아 공유하자는 겁니다.

피그마의 Custom Skills는 반복 업무를 마크다운 지침으로 정리해 Figma agent와 Figma Make에서 쓰는 기능이고, 등록한 Skill은 /skill-name 같은 슬래시 명령어로 부릅니다. 가장 큰 장점은 디자이너가 화면을 만지는 바로 그 공간 안에서 검수 기준을 불러올 수 있다는 점이에요. GitHub를 쓸 수 있는 조직은 원본 관리를 거기서 계속하면 되고, 피그마는 발견하고 실행하는 접점으로 쓰자는 게 몽글c의 구도입니다. 저는 이 역할 분담에 동의합니다. 다만 그렇게 되면 원본과 피그마 사본, Skill이 두 벌이 된다는 점을 짚어둬야 해요. 피그마는 만든 Skill에서 md 파일을 내보낼 수 있으니, 진실의 원천을 어느 쪽에 둘지 먼저 정하지 않으면 두 벌은 금방 서로 다른 버전이 됩니다. 저라면 원본은 한곳에서만 고치고 피그마 쪽은 배포본으로만 다루는 규칙부터 정하겠어요.

금융권 독자를 위한 경고도 실무적입니다. 피그마 사용이 승인돼 있어도 AI 기능과 데이터 처리 범위까지 같은 조건으로 승인된 건 아닐 수 있으니, 조직이 허용한 범위 안에서 시작하라는 것. 도입 전에 보안 검토 문서부터 확인해야 하는 팀이라면 이 문단이 가장 먼저 읽혀야 합니다. 화면 속 고객 정보나 미공개 기획이 Skill 실행과 함께 어디로 넘어가는지까지 확인해야 실제 운영을 시작할 수 있어요.

세 가지 예시, 가치는 같지 않다

몽글c는 Skill을 쓸 때 최소한 사용 시점, 입력, 절차와 기준, 결과 형식, 예외 처리 다섯 가지를 담으라고 권하고, 바로 써볼 예시 셋을 생성 요청 프롬프트와 함께 내놓았습니다. 화면을 검토하는 /design-critic, 오타와 표기를 잡는 /typo-correction, 조직의 UX 라이팅 기준으로 문구를 검수하는 /ux-writing-check.

세 예시에 공통으로 들어간 좋은 습관이 있습니다. 결과를 '원문 / 수정 제안 / 수정 이유' 같은 표로 받게 하고, 화면만으로 알 수 없는 내용은 '확인 필요'로 표시하게 하고, 원본은 수정하지 말라고 못 박은 것. '시니어 디자이너처럼 평가해줘'보다 무엇을 근거로 평가할지 구체적으로 적어야 한다는 지적도 맞습니다. 이건 피그마가 아니어도 어떤 Skill에든 그대로 쓸 수 있는 작성 원칙이에요.

/design-critic의 생성 요청을 보면 의견을 '관찰한 내용 → 판단 근거 → 개선 제안' 순서로 정리하고 잘된 점도 함께 설명하라고 돼 있습니다. 저는 이 순서가 AI보다 사람의 리뷰 문화에 더 큰 선물이라고 봐요. 근거 없이 "이건 별로예요"로 끝나는 리뷰를 구조적으로 막아주니까요. 다만 몽글c도 적었듯 문서에 적힌 기준만으로 숙련자의 판단을 모두 재현할 수는 없습니다. 이 Skill의 자리는 시니어 리뷰를 대체하는 게 아니라, 동료에게 보여주기 전에 스스로 한 번 걸러보는 자기 점검 쪽이에요.

/typo-correction에는 제가 가장 높이 치는 한 줄이 들어 있습니다. 검수하지 못한 텍스트가 있으면 알려달라는 요구예요. AI가 놓치는 오류도 있으니 실행을 마쳤다는 이유만으로 모든 문구 검수가 끝났다고 판단하지 말라는 경고와 짝을 이룹니다. 검수 Skill의 진짜 위험은 틀린 지적보다 '다 봤다'는 착각이고, 무엇을 못 봤는지 스스로 보고하게 만드는 건 그 착각을 막는 가장 싼 장치입니다.

그런데 세 예시의 가치는 같지 않다고 봅니다. /design-critic과 /typo-correction은 어느 조직에서나 비슷하게 쓸 수 있는 범용 Skill이에요. 그런 건 피그마가 운영하는 AI Skills Library에도 이미 검증된 것들이 꽤 있다고 몽글c도 적었습니다.

/ux-writing-check는 다릅니다. 이 Skill은 사용자가 실행할 때 제공하는 조직의 UX 라이팅 가이드를 기준으로만 검수하고, 가이드가 없으면 달라고 요청하고, 가이드에 없는 규칙은 만들지 말고, 약관과 필수 고지는 '담당자 확인 필요'로 넘기게 돼 있어요. 핵심이 Skill 안이 아니라 조직의 합의된 기준 쪽에 있습니다. 저는 팀이 공유할 첫 Skill로 이런 걸 고르라고 권하고 싶어요. 범용 비평 Skill은 라이브러리에서 가져오면 되고, 팀이 직접 만들어 관리할 가치가 있는 건 그 조직에만 있는 기준을 담은 Skill입니다.

공유 Skill은 공유 문서처럼 낡는다

배포 과정에 대한 조언도 단단합니다. 먼저 실제 업무에 직접 돌려보고, 요청한 항목을 빠뜨리지 않는지, 원하는 형식으로 나오는지, 근거 없이 내용을 덧붙이지 않는지 확인한 뒤, 동료에게 언제 쓰는 Skill인지 이해되는지, 업무에 도움이 되는지, 빠지거나 불필요한 내용은 없는지 세 가지를 물으라는 겁니다. 준비가 되면 Manage skills에서 Publish를 거쳐 Private으로 팀이나 조직에 배포하고, 수정은 Publish changes로 내보내고요.

배포한 뒤가 더 중요합니다. Skill이 늘면 비슷한 이름이 생기고 무엇이 최신인지 헷갈리기 시작하니, 몽글c는 최소한의 운영 정보를 함께 기록하라고 권합니다.

이름과 설명, 담당자, 상태(실험 중 / 팀 권장 / 사용 종료), 버전과 변경 내용, 사용 예시, 기준 자료. 저는 이 표가 글 전체에서 가장 실무적인 결과물이라고 봐요. 디자인 시스템을 운영해본 팀이라면 컴포넌트 문서에 똑같은 칸이 있다는 걸 알아볼 겁니다. 공유 Skill은 공유 문서와 같은 방식으로 낡거든요. 담당자가 없는 Skill은 가이드가 바뀌어도 그대로 남아 틀린 기준을 계속 적용하고, 상태가 없는 Skill은 실험용과 권장용이 섞입니다.

여기에 하나만 더하겠습니다. 같은 화면에 같은 Skill을 돌렸을 때 결과가 예전과 비슷하게 나오는지 확인하는 작은 예시 세트예요. 모델이나 지침이 바뀌면 Skill의 판단도 소리 없이 바뀌는데, 표의 '사용 예시' 칸에 입력과 기대 결과를 남겨두면 그게 곧 회귀 테스트가 됩니다.

처음에 짚은 단일 마크다운 제한도 이 지점에서 다시 의미를 가집니다. 다른 환경에서 쓰던 Skill 중 보조 스크립트나 참조 자료 폴더에 기대는 것은 피그마로 그대로 옮겨지지 않아요. 지침만으로 완결되는 검수형 Skill은 잘 옮겨지고, 여러 파일을 엮어 돌아가는 작업형 Skill은 원래 환경에 두는 편이 낫습니다. 어떤 Skill을 피그마에 올릴지 고르는 기준이 하나 더 생기는 셈이죠.

몽글c는 함께 쓰는 Skill이 늘어나면 무엇을 유지하고 누가 개선하며 어떻게 최신 상태로 관리할지가 결국 팀의 과제가 된다고 글을 맺었습니다. 저는 그 과제가 Skill이 늘어난 다음이 아니라 첫 번째 Skill을 배포하는 날 시작된다고 봐요.

정리하면 이 제안이 잘 맞는 팀의 조건은 이렇습니다. 피그마에서 매일 일하는 디자인 조직이고, 공유할 만한 조직 고유의 기준(라이팅 가이드, 디자인 시스템 규칙)이 이미 문서로 있고, 그 기준의 담당자를 정할 수 있을 것. 이 조건이 갖춰졌다면 피그마는 Skill을 디자이너 곁에 두는 훌륭한 창구입니다. 기준 문서도 담당자도 없는 상태라면, Skill을 모으기 전에 그 기준부터 합의하는 게 순서예요. Skill은 기준을 실행해줄 뿐, 기준을 대신 만들어주진 않으니까요.