이 글에서 예로 든 스킬은 naver/design-to-ui라는 이름의 오픈 소스로 공개되어 있습니다.
들어가며: 같은 모델, 다른 결과
AI 코딩 도구를 쓰다 보면 프롬프트에서 같은 설명을 매번 반복하게 됩니다. "이건 아이콘이니까 에셋으로 받아", "이건 그래프니까 Canvas로 그려", "색상은 하드코딩하지 말고 디자인 토큰을 써" 같은 설명이 그렇습니다. Figma 디자인을 Android 코드로 옮길 때도 마찬가지였습니다.
그래서 Claude의 스킬(Agent Skills) 기능이 공개되자마자 Figma 디자인을 Android UI로 변환하는 스킬을 만들기 시작했습니다. 목표는 프롬프트 한 번으로 완성도 높은 UI를 얻는 것이었습니다.
스킬의 효과는 생각보다 컸습니다. 2026년 3월, 같은 모델(Claude Opus 4.6)과 같은 프롬프트에 Figma Desktop MCP 서버까지 똑같이 쓰고 스킬만 바꿔 화면 하나를 조건마다 한 번씩 변환해 보았습니다. 그 결과는 다음과 같습니다.
조건디자인 토큰(colorScheme) 참조생성된 drawable스킬 없음8회0개범용 공식 스킬(Figma implement-design)20회0개프로젝트 맞춤 스킬(figma-to-android)39회1개
colorScheme 참조가 많을수록 색상을 하드코딩하지 않고 디자인 토큰을 썼다는 뜻이고, drawable은 Figma의 아이콘을 실제 에셋 파일로 받아 왔는지를 보여 줍니다. 이 숫자를 어떻게 얻었는지는 계명 10에서 다룹니다.
Figma 공식 스킬이 부족해서 생긴 차이는 아닙니다. 범용 스킬은 프로젝트의 디자인 토큰과 에셋 규칙을 알 수 없고, 맞춤 스킬은 바로 그 공식 스킬 위에 프로젝트 규칙을 얹은 것입니다. 이 방식은 계명 2에서 자세히 다룹니다.
Figma 원본과 세 조건으로 변환한 날씨 화면(오토앱)을 나란히 놓으면 다음과 같습니다. 지역과 날씨 데이터는 Figma 시안의 예시 값이거나 캡처 시점의 실제 값이라 서로 다릅니다.
Figma 원본
① 스킬 없음
② 범용 공식 스킬
③ 프로젝트 맞춤 스킬
그림 1 Figma 원본(위)과 세 조건으로 변환한 날씨 화면(아래)
모델은 같았는데 결과물의 디테일은 확연히 달랐습니다. 예를 들어 '서울시 명동' 옆 위치 아이콘은 맞춤 스킬에서만 제대로 나왔고, 시간별 기온 그래프도 맞춤 스킬에서만 그려졌습니다.
다만 이 스킬을 틈틈이 만드는 데 3개월쯤 걸렸습니다. 이 글에서는 3개월 동안 알게 된 원칙 10가지를 정리했습니다. 처음부터 알았다면 그 시간을 크게 줄일 수 있었을 것입니다. 사내 Engineering Day에서 발표한 내용을 글로 옮기면서 발표에서 다 하지 못한 사례를 더했습니다.
스킬은 무엇이고 프롬프트와 무엇이 다른가
스킬은 특정 작업을 어떻게 해야 하는지 적어 둔 폴더입니다. 폴더에는 SKILL.md 파일이 하나 있고, 필요하면 참고 문서(references/)와 스크립트(scripts/)를 함께 넣습니다. Claude는 평소에는 스킬의 이름과 설명만 알고 있다가, 요청이 그 설명과 맞으면 SKILL.md 본문을 읽어 들여 그 지침에 따라 작업합니다.
프롬프트와의 차이는 세 가지입니다.
반복 설명이 사라집니다. 매번 프롬프트에 붙여 넣던 에셋 규칙과 변환 절차를 스킬에 한 번만 적어 두면 됩니다.
스크립트를 함께 넣을 수 있습니다. 말로 설명하기 어렵고 결과가 늘 같아야 하는 작업(예: SVG를 VectorDrawable로 변환)은 스크립트로 만들어 두고 Claude가 실행하게 합니다.
팀이 같이 키울 수 있습니다. 파일이라 버전 관리가 되고, 플러그인으로 묶어 배포할 수 있습니다.
이 글의 예시는 Claude Code 기준이지만, 같은 스킬 형식(Agent Skills)을 지원