4부 14장. Skills — 반복 산출물 자동화
AI를 오래 써 본 사람일수록 묘하게 같은 문제에 부딪힌다. 처음에는 프롬프트 하나만 잘 써도 감탄이 나온다. 그런데 며칠이 지나면 슬슬 귀찮아진다. 지난주에 잘 먹혔던 지시문을 또 붙여 넣고, 회사 톤을 또 설명하고, 보고서 형식을 또 적고, 숫자 처리 원칙을 또 말한다.
이쯤 되면 생산성이 오른 것 같으면서도 어딘가 이상하다. 분명 AI를 쓰고 있는데, 정작 나는 더 열심히 브리핑 문서를 복붙하는 사람이 되어 있기 때문이다.
바로 여기서 Skills가 등장한다. Skills는 잘 먹히는 지시 몇 줄을 저장해 두는 기능이 아니다. 당신과 팀이 일하는 방식을 하나의 재사용 가능한 작업 방법으로 포장해 두는 기능에 가깝다. 문서 작성 방식, 보고서 구조, 분석 절차, 회사 양식, 예시 파일, 심지어 필요한 스크립트까지 한데 묶어 Claude가 필요할 때 알아서 꺼내 쓰게 만드는 것이다.12
이 장의 핵심은 한 문장으로 요약할 수 있다.
잘 만든 스킬 하나는, 잘 쓴 프롬프트 백 개보다 오래 간다.
Skills는 왜 게임체인저인가
프롬프트는 보통 한 번의 대화를 잘 끝내기 위한 도구다. 반면 Skills는 같은 종류의 일을 다음번에도, 다다음번에도, 다른 팀원도 비슷한 품질로 하게 만드는 장치다.
이 차이는 생각보다 크다. 예를 들어 당신이 매주 임원 보고용 1페이지 요약을 만든다고 해 보자. 프롬프트 방식이라면 매번 이런 내용을 다시 써야 한다. 독자는 임원진이고, 말투는 단정해야 하고, 숫자는 과장하면 안 되고, 리스크는 별도 섹션으로 빼고, 마지막에는 다음 액션을 세 줄로 정리해야 한다고 말이다.
하지만 이 절차를 Skill로 만들어 두면, Claude는 그 일을 할 때마다 같은 운영 원칙을 다시 적용한다. 즉흥적으로 잘 대답하는 AI가 아니라, 익숙한 방식으로 계속 일하는 AI가 된다.1
Anthropic이 Skills를 밀고 있는 이유도 여기에 있다. Skills는 단순 저장 기능이 아니라, 회사의 절차와 베스트 프랙티스를 재사용 가능한 능력으로 바꾸는 방식이다. 한 번 만든 스킬은 Claude.ai, Claude Code, API 같은 여러 환경에서 같은 개념으로 이어서 쓸 수 있다.13
쉽게 말해 보자. 프롬프트가 메모장에 적어 둔 개인 비법이라면, Skill은 팀에서 돌려 쓰는 표준 작업 매뉴얼이다. 메모장은 나만 안다. 매뉴얼은 신입도 쓴다. 바로 그 차이다.
프롬프트, Projects, Connectors와는 무엇이 다른가
앞 장들에서 본 기능과 Skills는 서로 겹쳐 보이기 쉽다. 하지만 역할은 꽤 다르다.
프롬프트는 그때그때 내리는 지시다. Projects는 기준 문서와 대화를 쌓아 두는 작업대다. Connectors는 Gmail, Drive, 캘린더 같은 바깥 도구에서 재료를 가져오는 통로다. Skills는 그 재료를 어떤 순서와 기준으로 가공할지 알려 주는 작업법이다.
한 문장으로 정리하면 이렇다.
프로젝트는 맥락을 보관하고, 커넥터는 데이터를 가져오고, 스킬은 일을 하는 방식을 고정한다.
그래서 셋은 경쟁 관계가 아니라 분업 관계다. 예를 들어 "고객 미팅 후속 제안서" 업무를 생각해 보자. Projects에는 제안서 예시와 회사 톤앤매너를 넣어 둔다. Connectors는 Gmail에서 최근 스레드를 읽고 Drive에서 지난 제안서를 가져온다. Skills는 그 자료를 바탕으로 어떤 순서로 인사이트를 뽑고, 어떤 슬라이드 구조로 정리하고, 어떤 표현은 피해야 하는지 알려 준다. 그리고 마지막에는 문서 생성용 스킬이나 파일 생성 기능으로 실제 결과물을 만든다.12
즉, Projects가 작업대라면 Skills는 손에 익은 공구다. 작업대만 있고 공구가 없으면 일이 느리다. 공구만 있고 작업대가 없으면 맥락이 흔들린다. 둘 다 있어야 속도와 품질이 동시에 올라간다.
어떤 업무를 Skill로 만들어야 하나
모든 일을 스킬로 만들 필요는 없다. 오히려 무조건 스킬화하려 들면 금방 피곤해진다. 좋은 후보는 따로 있다.
같은 요청을 세 번 이상 반복했다.
입력과 출력의 패턴이 비교적 일정하다.
결과물이 좋아졌는지 나빠졌는지 판단 기준이 있다.
예시 파일, 템플릿, 금지 표현, 체크리스트처럼 붙여 줄 재료가 있다.
반대로 스킬화에 잘 안 맞는 일도 있다.
한 번 하고 끝나는 탐색성 대화
문제 정의 자체가 아직 흔들리는 일
매번 접근 방식이 완전히 달라지는 고도의 창의 작업
우선 지식을 찾고 읽는 것이 중요한 Q&A형 작업
여기서 많은 사람이 헷갈린다. "전략"이라는 이름이 붙었다고 다 스킬 후보가 아닌 것은 아니다. 예를 들어 "경쟁사 분석 매트릭스 초안 만들기"는 입력과 출력이 꽤 고정되어 있어 스킬화하기 좋다. 반면 "내년 회사 전체 전략 방향을 제로베이스로 다시 생각하기"는 스킬보다 대화형 탐색이 더 어울린다.
처음 시작할 때는 야심을 줄이는 편이 좋다. "회사 콘텐츠 전체를 다루는 만능 스킬"보다 "주간 뉴스레터 초안 작성 스킬"이 훨씬 성공 확률이 높다. 작은 스킬이 잘 돌아가면, 그다음에 붙이면 된다.
Skill의 기본 구조는 의외로 단순하다
Skills의 매력은 거창한 개발부터 하지 않아도 된다는 점이다. 기본은 놀라울 정도로 소박하다. 폴더 하나와 그 안의 SKILL.md 파일이 출발점이다. 여기에 이름, 설명, 사용 시점, 작업 절차, 예시, 참고 파일 경로를 적는다. 필요하면 템플릿 문서나 스크립트를 함께 넣어 더 강하게 만들 수 있다.12
기본 골격은 대체로 이런 식이다.
---
name: weekly-report
description: 운영팀 주간 보고서 초안을 만들 때 사용하는 스킬. 임원 보고용 톤과 고정 섹션을 따른다.
---
## When to use this skill
주간 보고서, 운영 업데이트, KPI 요약, 리스크 보고를 쓸 때 사용한다.
## Inputs
회의록, KPI 수치, 이슈 메모, 지난주 보고서
## Process
1. 핵심 성과와 수치 변화를 분리한다.
2. 리스크와 확인 필요 항목을 따로 모은다.
3. 정해진 템플릿 순서대로 초안을 작성한다.
4. 숫자가 불명확하면 단정하지 않는다.
## Output rules
문장은 짧게 쓴다.
과장 표현을 쓰지 않는다.
마지막에 다음 주 액션 3개를 넣는다.중요한 것은 형식의 화려함이 아니다. Claude가 "언제 이 스킬을 써야 하는지"와 "써야 한다면 어떤 순서로 일해야 하는지"를 헷갈리지 않게 만드는 것이다.
Anthropic이 공개한 예시들을 보면, 좋은 스킬은 대개 세 층으로 이루어진다. 메인 설명이 있고, 세부 예시 파일이 있고, 필요하다면 문서 생성이나 변환을 돕는 코드와 리소스가 붙는다.12 이 구조가 좋은 이유는 간단하다. 운영 원칙은 SKILL.md에, 구체적 형식은 예시 파일에, 정밀한 반복 처리는 스크립트에 맡길 수 있기 때문이다.
즉, "지침은 말로, 일관성은 파일로, 정밀함은 코드로" 나누는 셈이다.
비개발자도 만드는 Skill 작성법
여기서 겁먹을 필요는 없다. 스킬을 만든다고 해서 갑자기 개발자가 되어야 하는 것은 아니다. 비개발자에게 필요한 것은 프로그래밍 문법보다 업무를 분해하는 습관이다.
첫째, 업무를 한 줄로 줄여 쓴다. "보고서를 잘 써줘"가 아니라 "회의록과 KPI를 받아 임원용 주간 보고서 초안을 만든다"처럼 입력과 결과를 보이게 적는다.
둘째, 좋은 산출물 두세 개를 모은다. 말로 설명한 규칙보다 실제 예시가 훨씬 강하다. 잘 쓴 보고서, 회사에서 통과된 제안서, 말투가 잘 맞는 공지문이 최고의 재료다.
셋째, 규칙을 운영 문장으로 바꾼다. "좋은 느낌으로 써줘"는 규칙이 아니다. "한 문장은 25자 안팎으로 짧게", "숫자 없는 성과 표현 금지", "결론부터 쓰고 배경은 뒤로"처럼 바뀌어야 한다.
넷째, 처음부터 완벽한 스킬을 만들려 하지 않는다. Claude의 예시 스킬이나 스킬 제작 보조 기능을 이용해 초안을 만든 뒤, 실제 업무 데이터로 돌려 보고 고치는 편이 훨씬 빠르다.14
다섯째, 테스트 문서를 따로 저장해 둔다. 같은 입력으로 두세 번 돌려 봤을 때 톤과 구조가 너무 흔들린다면 지침이 모호하다는 뜻이다. 좋은 스킬은 실행보다 검수에서 자란다.4
이 과정을 책 앞부분에서 배운 브리핑 4요소로 다시 보면 더 쉽다. 맥락은 "누구를 위한 일인가", 목표는 "무슨 산출물을 만드는가", 제약은 "무엇을 하면 안 되는가", 형식은 "어떤 구조로 내보내는가"다. 결국 좋은 스킬은 좋은 브리핑을 한 번 쓰고 끝내지 않고, 재사용 가능한 폴더로 승격시킨 결과물이다.
잘 만든 Skill은 스스로 튀지 않는다
스킬은 존재감이 강한 기능처럼 보이지만, 실무에서는 오히려 안 튀는 쪽이 좋다. "와, 이번엔 특별히 잘 됐네"보다 "늘 이 정도는 나오네"가 더 중요하다.
Anthropic과 여러 실전 가이드가 공통으로 강조하는 점도 바로 이것이다. Skills의 강점은 자동 활성화와 조합 가능성에 있다. Claude는 사용자의 요청과 의도를 보고 관련 있는 스킬을 불러오고, 필요하면 여러 스킬을 함께 엮어 쓸 수 있다.14
이 말은 곧 이런 뜻이다. 당신이 고객 인터뷰 녹취를 올리고 "임원 보고용 요약으로 정리해 줘"라고 하면, 인터뷰 분석 스킬과 보고서 형식 스킬이 연달아 작동할 수 있다는 뜻이다. 사용자가 매번 "지금은 A 스킬, 다음은 B 스킬"이라고 오케스트라 지휘하듯 지정하지 않아도 된다.
실무자 입장에서 이건 엄청 편하다. AI를 쓰기 위해 기능 이름을 외우는 대신, 평소처럼 일을 요청하면 되기 때문이다. 좋은 스킬은 존재를 과시하지 않는다. 그저 일의 마찰을 줄인다.
회사 양식에 맞춘 docx·pptx 자동 생성은 왜 Skills와 찰떡인가
많은 사람이 Skills를 "말 잘 쓰게 만드는 기능"으로만 생각한다. 하지만 진짜 재미는 결과물이 파일이 될 때 시작된다.
Anthropic은 공식 예시와 문서에서 문서 생성용 스킬들을 함께 보여 준다. docx, pptx, xlsx, pdf 같은 문서 작업 스킬은 단순 채팅 답변이 아니라 실제 파일 산출물 생성에 맞춰져 있다.23 여기에 회사 전용 커스텀 스킬을 얹으면, 비로소 "우리 양식대로 나오는 문서 자동화"가 가능해진다.
예를 들어 보자. 당신 회사가 늘 같은 슬라이드 구조를 쓰는 영업 제안서를 가지고 있다고 하자. 서론 1장, 고객 과제 2장, 해결 방안 3장, 일정과 견적 1장, 레퍼런스 1장처럼 구성은 늘 비슷하다. 이때 단순 프롬프트만 쓰면 매번 구조와 톤을 다시 설명해야 하고, 결과물도 조금씩 흔들린다.
하지만 "sales-deck-brand" 같은 스킬을 만들면 이야기가 달라진다. 이 스킬 안에는 회사 로고 사용 규칙, 금지 표현, 슬라이드별 목적, 고객 업종별 문장 패턴, 자주 쓰는 사례 구조를 넣어 둘 수 있다. 그리고 실제 파일 생성은 pptx 계열 스킬이 맡는다. 그러면 Claude는 단지 예쁜 문장을 쓰는 데서 멈추지 않고, 브랜드 기준을 반영한 실제 제안서 파일까지 가는 흐름을 만들 수 있다.123
docx도 마찬가지다. "임원 회의 보고서" 스킬을 만들어 두면, 회의록과 수치를 받아 정해진 목차와 문체로 보고서를 구성하고, 공식 문서 형식으로 결과를 내는 패턴을 반복할 수 있다. 잘 설계하면 사람은 내용 검토와 민감도 판단에 집중하고, 형식 정리와 초안 골격은 AI가 맡는다.
이 대목이 중요하다. 많은 업무에서 시간은 내용보다 형식에 더 많이 든다. 무슨 말을 할지는 대충 아는데, 그것을 회사 양식에 맞게 정리하느라 시간이 녹아내린다. Skills는 바로 그 형식 노동을 패키징하는 데 강하다.
실무 예시: "채용공고 패키저" 스킬 만들기
조금 더 현실적인 예로 가 보자. 인사팀에서 채용공고를 자주 쓴다고 해 보자. 겉보기엔 쉬워 보여도, 실제로는 늘 비슷한데 늘 미묘하게 다르다. 직무 요약, 자격 요건, 우대 사항, 회사 소개, 복지 문구, 법적 주의 문구까지 챙겨야 한다.
이 업무를 스킬로 만들면 구조가 선명해진다.
먼저 SKILL.md에는 이렇게 적을 수 있다. 이 스킬은 채용공고 초안 작성, 기존 JD 정제, 공고 플랫폼용 요약본 생성에 사용한다. 입력은 직무명, 소속 팀, 핵심 업무, 필수 역량, 우대 조건, 회사 소개 문안이다. 출력은 "직무 소개 → 주요 업무 → 자격 요건 → 우대 사항 → 합류 후 기대 역할 → 지원 안내" 순서를 따른다. 그리고 차별적 표현, 과장 표현, 모호한 인재상 표현은 피한다.
그다음 예시 폴더에는 실제로 통과된 공고 두세 개를 넣는다. 또 금지 표현 목록도 둔다. 예를 들어 "열정적인", "센스 있는", "가족 같은" 같은 문구를 빼야 한다면 따로 적어 둔다.
이렇게 해 두면 새 채용이 생길 때마다 HR 담당자는 긴 프롬프트를 다시 쓰지 않아도 된다. "백엔드 엔지니어 공고 초안 만들어 줘. 아래 직무 메모 반영해 줘" 정도만 말해도 Claude가 이미 팀의 기준을 불러와 작업한다.
처음엔 한 시간 들여 스킬을 만들 수 있다. 하지만 이후 공고를 열 번 쓴다면, 열 번마다 길게 브리핑하던 시간이 거의 사라진다. 바로 이런 순간에 스킬의 투자 대비 수익이 나온다.
팀 자산으로 만들려면 개인 비법에서 벗어나야 한다
스킬의 진짜 가치는 내가 잘 쓰는 데서 끝나지 않는다. 다른 사람도 같은 결과를 낼 수 있을 때 커진다.
Claude Code 환경에서는 프로젝트별 스킬을 .claude/skills/ 아래에 두고, 개인용 스킬은 ~/.claude/skills/에 둘 수 있다. 프로젝트 스킬은 버전 관리에 포함해 팀과 공유할 수 있다.5 이 구조가 중요한 이유는 아주 단순하다. 회사의 일하는 방식이 개인 채팅 기록이 아니라 저장소 안의 파일로 남기 때문이다.
이렇게 되면 좋은 일이 세 가지 생긴다.
첫째, 팀원이 바뀌어도 작업 방식이 남는다. 둘째, 스킬을 누가 어떻게 바꿨는지 추적할 수 있다. 셋째, 업무 개선이 감에 의존하지 않고 버전 업의 형태로 쌓인다.
그래서 팀에서 스킬을 운영할 때는 몇 가지 원칙이 있으면 좋다.
스킬마다 오너를 정한다.
이름은 업무가 드러나게 짓는다.
예시 파일은 현재 기준만 남긴다.
수정할 때는 테스트 입력으로 다시 검증한다.
"언제 쓰는지"와 "언제 쓰지 않는지"를 설명에 함께 적는다.
이 다섯 가지만 지켜도 스킬 라이브러리가 금세 쓸 만해진다. 반대로 누구나 아무 이름으로, 아무 예시나 넣고, 테스트도 없이 바꾸면 스킬은 곧 "회사 공용 폴더의 정체불명 파일"이 된다. 그 순간부터 아무도 믿고 쓰지 않는다.
좋은 Skill은 넓지 않고, 좁고 날카롭다
초보자가 가장 자주 하는 실수는 만능 스킬을 만들려는 것이다. "우리 회사 마케팅 업무 전반을 도와주는 스킬" 같은 이름이 대표적이다. 멋있어 보이지만 대개 실패한다. 너무 많은 상황을 하나의 규칙으로 묶으려 하기 때문이다.
좋은 스킬은 보통 더 작다. 예를 들면 "블로그 글을 링크드인 पोस्ट로 바꾸는 스킬", "고객 인터뷰 녹취에서 pain point만 뽑는 스킬", "임원 보고용 1페이지 요약 스킬"처럼 범위가 선명하다.
왜냐하면 범위가 좁을수록 입력, 절차, 출력, 금지선이 또렷해지기 때문이다. 그래야 테스트도 쉽고, 실패 원인도 빨리 찾는다. 스킬은 야심으로 이기는 기능이 아니다. 경계 설정으로 이기는 기능이다.
실무에서는 이런 감각이 중요하다. 큰 스킬 하나보다 작은 스킬 셋이 더 강하다. 작은 스킬은 조합할 수 있고, 고치기도 쉽고, 망가져도 피해가 작다. 마치 스패너 하나로 모든 걸 해결하려 하지 않고, 드라이버와 렌치와 육각키를 나눠 쓰는 것과 비슷하다.
Skill이 실패하는 다섯 가지 패턴
스킬을 만들어 놓고도 "별로 달라진 게 없네"라고 느끼는 경우가 있다. 대부분 이유는 비슷하다.
범위가 너무 넓다: 한 스킬이 여러 업무를 동시에 맡으려 한다.
설명만 있고 예시가 없다: 규칙은 있지만 실제 산출물의 감이 없다.
금지선이 없다: 무엇을 하지 말아야 하는지가 빠져 결과가 흔들린다.
테스트가 없다: 처음 한 번 잘 되자마자 실전에 투입한다.
최종 검토를 생략한다: 숫자, 법무, 대외 메시지까지 그대로 내보낸다.
특히 네 번째가 중요하다. 스킬은 저장했다고 끝이 아니다. 한 번 만든 뒤에는 표준 테스트 입력으로 다시 돌려 봐야 한다. 결과의 톤이 같은지, 섹션이 빠지지 않는지, 금지 표현이 새지 않는지 확인해야 한다.4
AI는 늘 조금씩 변한다. 모델도 바뀌고, 업무 환경도 바뀌고, 팀의 기준도 바뀐다. 그래서 스킬은 조각상이 아니라 운영 문서에 가깝다. 만들어 두고 끝내는 것이 아니라, 가끔 먼지를 털고 나사를 조여 줘야 한다.
실전 운영 팁: 스킬은 설명서가 아니라 생산 라인이다
스킬을 잘 운영하는 팀은 스킬을 "똑똑한 지시문"으로 보지 않는다. 아예 작은 생산 라인처럼 다룬다.
예를 들어 콘텐츠팀이라면 이렇게 구성할 수 있다. 원고 분석 스킬이 핵심 메시지를 뽑고, 채널 변환 스킬이 블로그 글을 링크드인과 뉴스레터 버전으로 바꾸고, 브랜드 톤 스킬이 최종 문장을 다듬는다. 마지막에는 필요하면 문서 생성 스킬이 파일 형태로 뽑는다.12
이 구조의 장점은 분명하다. 한 스킬이 모든 걸 다 하려 하지 않는다. 각 스킬이 한 가지 역할만 맡고, 다음 단계에 넘겨 준다. 그러면 문제도 빨리 발견되고, 팀원이 이해하기도 쉽다.
그리고 이때 Projects와 Connectors가 다시 살아난다. Projects는 기준 파일과 작업 맥락을 붙들고, Connectors는 최신 메일과 문서를 끌어오고, Skills는 그 자료를 표준 방식으로 가공한다. 이 셋이 맞물리면 Claude는 단순 채팅 도구가 아니라, 꽤 그럴듯한 실무 생산 시스템이 된다.
결국 Skills는 팀의 노하우를 파일로 남기는 일이다
회사의 진짜 자산은 종종 문서보다 사람 머릿속에 있다. "김 대리가 쓰면 이상하게 보고서가 잘 나온다", "박 팀장이 쓰면 제안서 구조가 늘 깔끔하다" 같은 식이다. 문제는 이런 감각이 퇴사와 함께 사라지기 쉽다는 데 있다.
Skills의 가장 큰 의미는 바로 여기에 있다. 잘하는 사람의 감각을 완전히 복제할 수는 없더라도, 최소한 반복 가능한 절차와 기준을 파일 형태로 남길 수 있다. 그러면 개인의 요령이 팀의 자산이 된다.
이건 단순한 편의 기능이 아니다. 일하는 방식을 제도화하는 일에 가깝다. 누가 하든 비슷한 품질이 나오게 만들고, 신입도 첫날부터 어느 정도 기준에 맞는 결과물을 내게 하고, 회사 양식과 표현을 계속 같은 결로 유지하게 만든다.1
그래서 스킬을 만든다는 것은 단지 Claude를 더 잘 쓰는 일이 아니다. 팀의 업무 방식을 언어화하고, 정리하고, 재사용 가능하게 만드는 일이다.
잘 만든 스킬은 말이 없다. 그저 매번 같은 자리에서, 같은 품질로, 같은 실수를 덜 하게 해 준다.
실무에서 오래 살아남는 시스템은 대개 그런 식으로 생긴다. 화려해서가 아니라, 반복에 강해서.
참고
1Teach Claude your way of working
2GitHub - anthropics/skills: Public repository for Agent Skills
3Get started with Agent Skills in the API - Claude API Docs
4Claude Skills: Build repeatable workflows in Claude
5Claude Code Skills Library — Reusable Workflows & Automations
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.