[22호] AI 시대, 기획과 디자인을 위한 새로운 문법 ‘Skill’

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

오늘은 프로덕트 디자이너, 프로덕트 매니저, 프로덕트 오너, 프로덕트 전략과 기획 등 제품을 만드는 모든 메이커분에게 도움이 될 만한 이야기를 가져왔습니다.

바로 AI 시대의 새로운 업무 방식으로 주목받고 있는 ‘Skill’에 대한 이야기를 해보려고요.

업무에서 AI를 활용하고 있다면 Skill이라는 용어를 한 번쯤 들어보셨을 겁니다. 이미 직접 만들어 사용하고 있는 분도 있겠지만, 아직은 “Skill이 프롬프트와 무엇이 다른가?”, “굳이 Skill까지 만들어야 하나?”라고 생각하는 분도 있을 것 같습니다.

그래서 구체적인 활용 방법을 살펴보기에 앞서, 이 글에서 말하는 Skill이 '무엇'인지부터 시작해보겠습니다.

Skill은 프롬프트와 무엇이 다를까요?

Skill은 AI에게 특정 업무를 맡길 때 필요한 절차와 판단 기준, 질문, 결과물의 형식, 참고 자료와 예시 등을 하나의 재사용 가능한 형태로 만들어둔 것입니다.

쉽게 말하면 AI가 특정한 일을 더 안정적으로 수행할 수 있도록 설계한 작은 업무 시스템에 가깝습니다.

예를 들어 AI에게 “신규 서비스 기획안을 만들어줘”라고 요청하는 것은 하나의 프롬프트입니다. AI는 이 요청에 따라 그럴듯한 문서를 빠르게 만들어줄 수 있습니다.

하지만 그 결과물이 우리 조직에서 생각하는 좋은 기획안인지, 실제 의사결정에 도움이 되는지, 개발자와 디자이너가 바로 이해할 수 있는지는 보장하기 어렵습니다.

반면 Skill은 문제 정의, 사용자 분석, 핵심 가설, 기능 우선순위, 화면 구조를 어떤 순서로 검토할지 미리 설계합니다. 각 단계에서 어떤 질문을 던져야 하는지, 정보가 부족할 때 무엇을 추가로 확인해야 하는지, 최종 결과물을 어떤 형식으로 정리해야 하는지도 함께 정의합니다.

프롬프트가 그때그때 AI에게 전달하는 업무 요청이라면, Skill은 반복해서 사용할 수 있도록 정리된 업무 수행 방식입니다.

매번 긴 설명을 새로 입력하지 않아도 되고, 사용하는 사람이 달라져도 일정한 기준과 절차를 적용할 수 있습니다.

결국 Skill은 좋은 프롬프트를 하나 저장해두는 것을 넘어, 좋은 결과가 반복적으로 나올 수 있는 조건을 설계하는 일이라고 할 수 있습니다.

그렇다면 AI 시대의 기획자와 디자이너에게 Skill은 왜 중요할까요?
그 이유를 세 가지 관점에서 먼저 정리해보도록 하겠습니다.

1. Skill은 개인의 감각과 노하우를 반복 가능한 업무 방식으로 바꿔줍니다

기획과 디자인에는 여전히 경험과 감각이 중요합니다.

하지만 감각만으로 일하면 결과물의 품질이 개인의 역량에 크게 의존하게 됩니다. 경험이 많은 사람이 맡으면 좋은 결과가 나오지만, 담당자가 바뀌면 품질이 쉽게 흔들리는 방식이 되기 쉽습니다.

일을 잘하는 사람은 결과물을 만들기 전에 자신도 모르게 많은 질문을 던집니다.

하지만 이런 판단 기준은 대부분 숙련자의 머릿속에만 존재합니다.

문서로 남아 있더라도 “사용자 관점에서 검토한다”, “직관적으로 구성한다”, “핵심 정보를 명확하게 전달한다”와 같은 원론적인 표현에 머무는 경우가 많습니다.

문제는 이런 표현만으로는 실제 업무에서 무엇을 확인하고, 어떤 기준으로 판단해야 하는지 알기 어렵다는 것입니다.

Skill은 이러한 감각을 구체적인 절차와 질문, 판단 기준으로 바꿔줍니다.

“사용자 관점에서 보세요”라고 말하는 대신, “이 화면에서 사용자가 가장 먼저 판단해야 하는 정보는 무엇인가?”라고 묻게 만드는 것입니다.

즉 Skill은 일을 잘하는 사람의 머릿속에 있던 (보이지 않는) 판단 기준을 꺼내어, 다른 사람과 AI가 함께 사용하고 계속 개선할 수 있는 형태로 만드는 장치입니다.

보통 이런 업무 방식은 문서보다 구두로, 그리고 사수로부터 전수되는 경우가 많습니다. 누군가는 자연스럽게 배우지만, 누군가는 같은 시행착오를 처음부터 다시 겪습니다.

Skill은 개개인에게 의존하던 노하우를 팀이 함께 사용할 수 있는 자산으로 바꿔줄 수 있습니다.

2. Skill은 디자이너와 기획자가 함께 판단하는 공통 기준이 됩니다

프로덕트 디자이너, PM, PO는 같은 제품을 만들지만 자주 다른 언어를 사용합니다.

디자이너는 사용자 경험과 흐름을 보고, 기획자는 요구사항과 정책을 보고, PO는 목표와 우선순위를 봅니다.

관점이 다른 것은 자연스러운 일입니다. 하지만 판단의 기준까지 다르면 회의는 쉽게 각자의 주장과 취향을 설명하는 자리로 바뀝니다.

“이 기능이 필요한 것 같다”, “이 화면이 더 직관적인 것 같다”, “이 방식이 개발하기 쉬울 것 같다”는 의견만 오가다 보면 무엇을 기준으로 결정해야 하는지가 흐려집니다.

이때 Skill은 각자의 관점을 연결하는 공통 기준이 될 수 있습니다.

“이 기능이 필요한가?”를 논쟁하는 대신 다음과 같은 질문을 함께 검토하도록 만드는 것입니다.

팀이 동일한 질문과 기준을 사용하면 역할이 달라도 같은 문제를 같은 구조로 바라볼 수 있습니다.

그래서 Skill은 개인의 생산성을 높이는 도구에 그치지 않습니다. 팀이 더 빠르고 정확하게 합의하고, 결정의 근거를 함께 축적하기 위한 협업의 기준이 될 수 있습니다.

3. Skill은 AI에게 일을 맡기고 결과물을 검증하는 새로운 작업 단위가 됩니다

AI를 잘 쓰는 사람과 그렇지 않은 사람의 차이는 프롬프트를 멋지게 작성하는 능력보다, 문제를 어떤 순서로 나누고 어떤 기준으로 결과물을 판단하는가에서 갈립니다.

AI는 초안을 빠르게 만들 수 있습니다. 하지만 좋은 문제 정의와 충분한 맥락, 구체적인 판단 기준이 없으면 결과물은 쉽게 평범해집니다.

문장은 그럴듯하지만 실제 업무에서는 사용할 수 없는 결과물이 만들어지기도 합니다.

결국 AI 시대에 더 중요해지는 것은 내가 직접 모든 결과물을 만드는 능력만이 아닙니다.

AI가 좋은 결과물을 만들 수 있도록 작업의 구조를 설계하고, 결과를 평가하고, 필요한 부분을 다시 수정하도록 만드는 능력이 중요해집니다.

이 관점에서 Skill은 AI에게 일을 맡기는 단위인 동시에 결과물을 평가하는 기준이 됩니다.

예를 들어 막연한 아이디어를 문제 정의, 요구사항, 화면 구조의 순서로 발전시키는 Skill을 만들 수 있습니다. 이때 Skill은 단순히 문서를 대신 작성하는 데 그치지 않고, 사용자가 제품을 사고하는 순서 자체를 안내합니다.

앞으로 기획자와 디자이너에게 Skill은 생산성을 조금 높여주는 옵션이 아니라, AI와 협업하기 위한 기본적인 '업무 문법'에 가까워질 수 있습니다.

다시 정리하면 Skill은 개인의 감각에 기대던 기획과 디자인의 품질을 재현 가능한 방식으로 바꾸고, 디자이너와 PM, PO가 같은 문제를 같은 기준으로 바라보게 합니다.

동시에 AI에게 업무를 맡기고 결과물을 검증하기 위한 새로운 작업 단위가 됩니다.

그럼 Skill은 어떻게 구성될까요?

앞서 Skill을 기획과 디자인의 새로운 문법이라고 이야기했지만, 이것을 단순히 “프롬프트를 잘 정리해둔 것” 정도로 이해하면 안됩니다.

Anthropic의 Agent Skills에서 Skill은 AI가 특정 작업을 어떻게 수행해야 하는지 이해할 수 있도록 만든 패키징된 지시사항과 참고 자료의 집합으로 설명됩니다.

하나의 Skill은 SKILL.md, scripts, reference, assets 같은 요소로 구성될 수 있습니다.

skill의 트리구조

모든 내용을 하나의 거대한 프롬프트에 넣는 것이 아니라, AI가 필요한 순간에 필요한 자료를 찾아 활용하도록 만드는 것이 핵심입니다.

회사에서 업무를 할 때도 모든 규정과 참고 문서를 처음부터 끝까지 읽고 일을 시작하지는 않습니다. 우선 해야 할 일을 확인하고, 필요한 순간에 관련 정책과 사례를 찾아봅니다.

Skill 역시 이와 비슷한 방식으로 작동합니다.

좋은 Skill을 만들기 위한 원칙

Anthropic의 Skill 가이드에서는 좋은 Skill의 원칙으로 점진적 공개, 조합성, 이식성을 이야기합니다. 모든 정보를 한꺼번에 넣기보다 필요한 순간에 필요한 자료를 불러오고, 하나의 거대한 Skill보다 역할이 명확한 여러 Skill을 조합하며, 특정한 대화나 환경을 넘어 다른 사람과 프로젝트에서도 활용할 수 있도록 만드는 것입니다.(참고: https://brunch.co.kr/@monglec/178) 

이를 PM과 디자이너의 언어로 바꿔보면, 좋은 Skill은 AI에게 많은 정보를 밀어 넣는 것이 아니라 좋은 결과를 만들기 위해 필요한 기준과 절차를 적절한 순간에 꺼내 쓰게 하는 설계입니다. 결국 Skill을 만든다는 것은 AI에게 명령어를 하나 더 추가하는 일이 아니라, 우리가 일하는 방식을 재사용하고 확장할 수 있는 구조로 만드는 일에 가깝습니다.

Skill을 만드는 일은 개발자만의 영역이 아닙니다

Skill이라는 표현과 파일 구조를 보면 개발자를 위한 기술처럼 느껴질 수 있습니다. 하지만 Skill의 핵심은 코드를 작성하는 것이 아닙니다.

어떤 상황에서 업무를 시작해야 하는지, 어떤 순서로 질문해야 하는지, 어떤 정보가 부족한지, 무엇을 좋은 결과라고 판단할지를 정의하는 것이 Skill의 핵심입니다.

사용자가 어떤 상태에서 시작하는지, 어떤 질문과 판단을 거쳐야 하는지, 최종적으로 어떤 산출물에 도착해야 하는지를 설계하는 일은 기획자와 디자이너가 오랫동안 해온 업무에 가깝습니다.

기획자는 모호한 요구를 구체적인 문제와 요구사항으로 바꾸고, 디자이너는 사용자의 흐름과 판단 과정을 구조화합니다.

Skill을 설계하는 과정도 이와 크게 다르지 않습니다.

그래서 Skill은 개발자만 만들 수 있는 기술적인 도구라기보다, 기획자와 디자이너가 자신의 업무 경험과 판단 기준을 AI가 활용할 수 있는 형태로 바꾸는 방법이라고 보는 편이 적절합니다.

오히려 좋은 업무 흐름과 결과물의 품질 기준을 많이 고민해온 기획자와 디자이너가 Skill을 더 잘 만들 수 있는 영역도 많다고 생각합니다.

Skill을 만드는 것은 어렵지 않을까요?

Skill을 만드는 과정은 생각보다 어렵지 않아요. 처음부터 완벽한 구조를 직접 설계할 필요도 없습니다.

Skill 제작을 도와주는 도구와 방법론을 활용할 수 있기 때문입니다.

대표적으로 Anthropic의 skill-creator 와 Superpowers의 writing-skills 를 활용할 수 있습니다. 두 도구 모두 Skill 제작을 돕지만 접근 방식에는 조금 차이가 있습니다.

Anthropic의 skill-creator 는 테스트 케이스를 만들고, Skill 적용 전후의 결과를 비교하고, 평가와 개선을 반복하도록 돕는 Skill 제작·평가 도구에 가깝습니다.

Superpowers의 writing-skills 는 Skill이 없을 때 AI가 어떤 실수를 하는지 먼저 확인한 뒤, 해당 실패를 막는 Skill을 작성하고 다시 테스트하는 TDD 방식에 가깝습니다.

* TDD = Test Driven Development  
(RED: 실패하는 테스트 먼저, GREEN: 최소한의 스킬 작성),REFACTOR: 허점 막기)

** Sub Agent로 진행하는 이유는 Agent기반인 경우 맥락을 참고해 공정하지 않기 때문

여기서 중요한 것은 처음부터 완벽한 Skill을 만드는 것이 아닙니다.

실제로 사용해보고, 기대한 결과와 다른 부분을 찾고, 그 차이를 새로운 규칙과 예시로 보완하는 과정이 중요합니다. Skill도 일반적인 제품과 비슷합니다. 먼저 작은 버전을 만들고, 테스트하고, 실패 사례를 수집하고, 반복해서 개선해야 합니다.

테스트는 가능하면 새로운 세션이나 독립된 Sub Agent에서 진행하는 것이 좋다고 합니다. Skill을 작성했던 대화의 맥락이 남아 있으면 AI가 부족한 지침을 이전 맥락으로 보완해버릴 수 있기 때문입니다.

즉 좋은 Skill은 한 번에 완성되는 문서가 아니라, 실제 실패와 평가를 통해 조금씩 단단해지는 업무 시스템입니다.

Superpowers에 대해서는 이전 뉴스레터에서도 한 차례 소개한 적이 있습니다. 해당 Skill을 어떻게 활용할 수 있는지, 혹은 어떻게 만들어 나가는지 궁금하신 분들은 아래 글을 먼저 살펴보셔도 좋겠습니다.

https://maily.so/makersnote/posts/1do1dwqlox6 

https://brunch.co.kr/@monglec/177 

꼭 직접 만들어야 할까요?

당연히 모든 Skill을 직접 만들 필요는 없습니다.

이미 공개된 Skill이나 AI 업무 프레임워크 중 자신의 업무에 맞는 것을 먼저 사용해보는 것도 좋은 출발점입니다. 다만 현재 공개된 프로젝트들은 성격이 서로 조금씩 다릅니다. 모두 하나의 Skill이라고 보기보다는 Skill 모음, AI 업무 프레임워크, 디자인 포맷 등으로 구분해서 살펴보는 것이 좋습니다.

바로 설치해 활용할 수 있는 Skill 모음

Anthropic Skills

https://github.com/anthropics/skills

Anthropic에서 공개한 샘플 및 참고용 Skill 모음입니다.

프론트엔드 디자인, 문서 작성, PPTX·Excel·PDF 편집과 검토 등 다양한 사례를 통해 Skill이 어떤 구조로 만들어지는지 살펴볼 수 있습니다.

직접 Skill을 만들기 전에 전체적인 형태를 이해하기 위한 참고 자료로 활용하기 좋습니다.

PM Skills Marketplace

https://github.com/phuryn/pm-skills

제품 발견, 전략 수립, 사용자와 시장 조사, 데이터 분석, 실행, 출시, 성장 등 PM 업무 전반을 지원하는 Skill과 워크플로우를 제공합니다.

특정 산출물 하나를 만드는 것보다 제품 업무의 여러 단계를 연결해서 활용하고 싶은 PM에게 유용합니다.

UI UX Pro Max

https://github.com/nextlevelbuilder/ui-ux-pro-max-skill

다양한 UI 스타일, 색상 팔레트, 폰트 조합, 제품 유형별 디자인 시스템과 UX 가이드라인을 바탕으로 적합한 UI·UX 디자인 방향을 제안하는 Skill입니다.

AI 코딩 도구로 화면을 만들 때 결과물이 지나치게 획일적으로 나오는 문제를 보완하는 데 활용할 수 있습니다.

AI 코딩의 전체 업무 방식을 제공하는 프레임워크

Superpowers

https://github.com/obra/superpowers

코딩을 시작하기 전에 사용자의 의도와 요구사항을 구체화하고, 설계 검토, 구현 계획, TDD, Sub Agent 기반 개발, 코드 리뷰까지 이어주는 AI 소프트웨어 개발 방법론입니다.

코드를 빠르게 생성하는 것보다 코딩 전에 충분히 생각하고 검증하는 과정을 중요하게 다룹니다.

gstack

https://github.com/garrytan/gstack

제품을 재구상하는 CEO, 아키텍처를 검토하는 엔지니어링 매니저, UI와 UX의 오류를 찾아내는 디자이너, 프로덕션 버그를 확인하는 리뷰어, 실제 브라우저에서 테스트하는 QA 리더 등 다양한 전문가 역할을 제공합니다.

하나의 AI에게 모든 일을 요청하는 대신, 업무 단계마다 적절한 전문가의 관점으로 결과물을 검토하도록 만드는 방식입니다.

Ouroboros

https://github.com/Q00/ouroboros

AI 코딩을 위한 명세 중심의 Agent OS에 가깝습니다.

바로 코딩을 시작하기보다 인터뷰, 구체화, 실행, 평가, 진화와 같은 구조화된 워크플로우를 거쳐 결과물을 만들어갑니다.

하나의 Skill이라기보다 여러 Skill과 Agent가 함께 작동하는 전체 업무 체계로 이해하는 편이 적절합니다.

AI가 디자인 기준을 이해하도록 만드는 포맷과 도구

Google DESIGN.md

https://github.com/google-labs-code/design.md

디자인 토큰과 디자인 의도를 AI 코딩 에이전트가 이해할 수 있는 형태로 정의하는 포맷입니다.

DESIGN.md를 사양에 맞춰 검증하고, 잘못된 토큰 참조와 WCAG 대비, 구조적인 문제를 확인해 AI가 활용할 수 있는 데이터 형태로 제공합니다.

디자인 시스템이 사람만 읽는 문서에 머무르지 않고, AI가 실제 구현 과정에서 참고할 수 있는 구조로 변화하고 있다는 점에서 흥미로운 사례입니다.

Skill은 AI가 아니라 우리의 일하는 방식을 설계하는 도구입니다

AI가 결과물을 빠르게 만들어주는 시대가 오고 있습니다.

문서와 화면, 코드의 초안을 만드는 속도는 앞으로도 계속 빨라질 것입니다.

하지만 어떤 결과물이 좋은지 정의하고, 어떤 순서로 만들어야 하는지 설계하고, 어디까지 AI에게 맡기고 어디에서 사람이 판단해야 하는지를 결정하는 일은 여전히 사람의 몫입니다.

Skill은 바로 '사람의 판단'과 '업무 노하우'를 AI가 함께 사용할 수 있는 형태로 바꾸는 '새로운 문법'입니다.

앞으로의 PM과 프로덕트 디자이너에게 Skill은 단순한 생산성 도구가 아닐 수 있습니다.

좋은 Skill을 만든다는 것은 좋은 프롬프트를 하나 더 저장하는 것이 아니라, 내가 어떻게 일하고 판단하는지를 더 명확하게 이해하는 일입니다.

동시에 좋은 결과를 반복 가능하게 만들고, 팀이 함께 사용할 수 있는 기준을 세우며, 조직의 경험과 노하우를 축적하는 일이기도 합니다.

결국 Skill을 잘 만드는 사람은 단순히 AI를 잘 다루는 사람이 아니라, AI 시대의 '새로운 일하는 방식을 설계하는 사람'이 될 수 있습니다.

🎁 One more thing

글을 마치기 전에, 직접 만들어본 Skill 하나를 가볍게 소개해보겠습니다. 

 skill-idea2planning 이라는 Skill 인데요, 이 Skill은 막연한 제품이나 서비스 아이디어를 1-pager, PRD, ASCII 와이어프레임으로 차근차근 발전시켜주는 Claude Code Skill입니다. 👀

좋은 아이디어가 떠올라도 막상 문서로 옮기려고 하면 “왜 필요한가?”, “누구의 어떤 문제를 해결하는가?”, “무엇을 만들어야 하는가?”, “화면은 어떻게 구성해야 하는가?”에서 자주 막히게 됩니다.

skill-idea2planning 은 이 질문들을 순서대로 검토하면서, 머릿속의 생각을 다른 사람과 논의할 수 있는 결과물로 바꿔줍니다.

특히 refrences 폴더에는 자신만의 1-pager, PRD, 와이어프레임의 템플릿과 예시를 추가할 수 있습니다. 즉, 현재 회사에서 사용하는 문서나 좋은 사례가 있다면 이를 넣어, 자신의 조직에 맞는 결과물을 생성하도록 발전시킬 수도 있습니다. 

궁금하신 분은 아래 GitHub 링크를 통해 직접 설치해 사용해보세요.

https://github.com/pentaxzs/skill-idea2planning 

물론 이 Skill 그대로를 활용하셔도 좋고, 구조를 참고해 자신만의 첫 번째 Skill을 만들어보셔도 좋겠습니다. 🔮 

skill-idea2planning

📮 다음 호 예고

[23호] AI로 다 빨라진다더니, 돈 앞에서는 왜 다시 느려질까

AI 덕분에 기획도, 디자인도, 개발도 유례없이 빨라졌습니다. 며칠 걸리던 일을 몇 시간에 끝내는 게 이제 당연해졌죠. 그런데 최근 자리를 옮겨 다시 핀테크 도메인을 맡으면서, 이상한 경험을 했습니다.

그 빨라진 속도가 여기서는 오히려 불안하게 느껴지더라고요. 정산이 어긋나거나, 규제를 놓치거나, 신뢰가 한 번 깨지면 — 되돌릴 수 없는 영역이 있었습니다.

다음 호에서는 'AI가 끝내 건너오지 못하는 강'에 대해 이야기해보려 합니다. 속도가 미덕인 시대에, 왜 어떤 도메인은 여전히 신중하고 느린지. 그리고 그 '느림'이 사실은 결함이 아니라 방어선일 수 있다는 이야기를요.

빠르게 만드는 능력만큼이나, 언제 멈춰야 하는지 아는 감각이 왜 점점 더 중요해지는지 함께 나눠보겠습니다.

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