에이전트 스킬(Skills) 완전정리
— AI에게 '능력'을 붙이는 법

요즘 AI 업계에서 조용히, 그러나 크게 번지는 개념이 '에이전트 스킬(Agent Skills)'입니다. Anthropic이 이를 공개 표준으로 내놓으면서 Notion·Figma·Atlassian 같은 회사들도 자기 스킬을 내놓기 시작했어요. 이름은 낯설지만 개념은 아주 직관적입니다. 이 글에서 스킬이 무엇인지, 어떻게 생겼는지, 왜 똑똑한 설계인지, 도구·MCP와 뭐가 다른지, 그리고 직접 어떻게 만드는지까지 비개발자 눈높이로 제대로 파고들어 볼게요.

미리 결론부터 말씀드리면 이렇습니다. 스킬은 코드가 아니라 '잘 정리한 글'이고, 그래서 코딩을 모르는 분도 만들 수 있습니다. 저는 이 점이 정말 반가웠어요. 지난 몇 년간 "AI를 잘 쓰려면 결국 개발을 배워야 하나" 하고 주눅 들었던 분이 많았거든요. 스킬은 그 반대 방향으로 갑니다. 일을 조리 있게 설명할 줄 아는 사람이 강해지는 판을 깔아줘요. 자, 하나씩 풀어보겠습니다.

한 줄 요약: 스킬은 AI에게 붙이는 '전문 매뉴얼'입니다. 코드가 아니라 글로 만들고, 필요할 때만 펼쳐 쓰기 때문에 아무리 많이 붙여도 AI가 느려지지 않습니다.

1. 스킬 = AI에게 붙이는 '전문 매뉴얼'

스킬은 "이런 일은 이렇게 처리해"라고 적어둔 업무 설명서를 AI에게 붙여주는 것입니다. 사람으로 치면, 신입에게 "우리 회사 보고서는 이 양식으로, 이 순서로 쓴다"는 매뉴얼을 쥐여주는 것과 같아요. 그걸 가진 AI는 매번 처음부터 설명하지 않아도 그 일을 일관되게, 전문가처럼 해냅니다.

예를 들어 'PDF 스킬'이 있으면 AI는 PDF를 다루는 표준 절차를, '엑셀 스킬'이 있으면 스프레드시트를 만드는 요령을 이미 아는 상태로 시작합니다. 능력을 플러그인처럼 꽂았다 뺐다 하는 셈이죠.

비유 하나: 신입에게 건네는 '업무 매뉴얼'

제가 부장 시절에 신입이 들어오면 늘 이런 일이 반복됐어요. 똑똑한 친구인데도 첫 보고서를 받아보면 우리 회사 양식이 아니고, 인사말도 제각각이고, 숫자 표기도 들쭉날쭉했죠. 그 친구가 부족해서가 아니라 '우리 식(式)'을 모르기 때문입니다. 그래서 저는 A4 몇 장짜리 매뉴얼을 만들어 줬어요. "표지는 이렇게, 목차는 이 순서로, 금액은 천 단위 콤마, 마지막에 요약 3줄." 그 매뉴얼을 읽은 뒤부터는 누가 써도 비슷한 품질이 나왔습니다.

AI에게 스킬을 붙이는 게 딱 이겁니다. AI는 원래 똑똑하지만 '우리 식'은 모릅니다. 스킬은 그 '우리 식'을 적어 건네는 매뉴얼이에요. 그래서 스킬을 붙인 뒤에는 매번 길게 설명하지 않아도 원하는 결과가 안정적으로 나옵니다.

비유 둘: 요리 '레시피 카드'

또 하나 좋은 비유는 레시피 카드입니다. 냉장고에 좋은 재료가 있고 손 빠른 요리사가 있어도, 레시피가 없으면 매번 맛이 달라집니다. 오늘은 짜고 내일은 싱겁죠. 레시피 카드에 "소금 한 스푼, 5분 볶기, 마지막에 참기름"이라고 적어두면 누가 해도 같은 맛이 납니다. 스킬은 AI를 위한 이 레시피 카드예요. "무엇을, 어떤 순서로, 어떤 주의사항과 함께"를 담습니다.

2. 어떻게 생겼나 — SKILL.md 한 장이 뼈대

스킬의 핵심은 SKILL.md라는 파일 하나입니다. 위쪽엔 간단한 정보(YAML이라 부르는, 이름표 같은 부분)가, 아래쪽엔 사람이 읽는 글(마크다운)로 지침이 적혀 있어요. 확장자 .md는 '마크다운'이라는, 워드보다 훨씬 단순한 글쓰기 형식일 뿐이니 겁먹지 않으셔도 됩니다. 메모장으로도 열 수 있는 그냥 텍스트예요. 대략 이런 구조입니다.

이제 네 가지 구성 요소를 하나씩 더 깊게 뜯어보겠습니다. 특히 두 번째 description이 왜 그렇게 중요한지는 꼭 짚고 넘어가야 해요. 많은 초보가 여기서 첫 단추를 잘못 끼웁니다.

① 이름(name) — 짧고 명확한 간판

이름은 스킬의 간판입니다. pdf-편집, 회사-보고서-양식처럼 무엇에 관한 스킬인지 한눈에 보이게 짓는 게 좋아요. 여기서 멋을 부릴 필요는 없습니다. '초강력만능문서도우미' 같은 이름보다 송장-엑셀-정리처럼 담백한 이름이 훨씬 낫습니다. 나중에 스킬이 수십 개로 늘어나면, 간판이 명확해야 사람도 AI도 헷갈리지 않아요.

② 설명(description) — 스킬의 '심장'

제가 이 글에서 가장 강조하고 싶은 부분입니다. description은 단순한 소개 문구가 아니라, AI가 "지금 이 스킬을 꺼내 쓸까 말까"를 판단하는 유일한 기준이에요. 조금 뒤에 설명할 '점진적 공개' 원리 때문에, 평소 AI는 스킬의 본문을 읽지 않습니다. 오직 이 짧은 description만 훑어보고 지금 상황에 맞는지 아닌지를 결정하죠.

그래서 description은 '무엇을 하는 스킬인가'뿐 아니라 '어떤 상황·어떤 요청일 때 쓰는가'를 담아야 합니다. 예를 들어보죠.

왼쪽처럼 쓰면 AI는 "이게 지금 필요한 건가?"를 판단하지 못하고 스킬을 그냥 지나쳐 버립니다. 애써 만든 스킬이 있어도 안 불리는 슬픈 일이 벌어지죠. 오른쪽처럼 '언제(트리거)'를 구체적으로 적어야 AI가 딱 맞는 순간에 알아서 꺼내 씁니다.

스킬을 처음 만들 때 시간의 절반은 description에 쓰세요. 본문이 아무리 훌륭해도, description이 흐릿하면 그 스킬은 영영 불려 나오지 않습니다.

③ 본문(지침) — 실제 '일하는 방법'

본문은 매뉴얼의 몸통입니다. 단계별 방법, 주의사항, 예시가 들어가요. "먼저 이걸 확인하고, 다음엔 이 순서로, 이럴 땐 이렇게 예외 처리하라"는 식으로, 신입에게 설명하듯 적으면 됩니다. 특별한 문법이 필요 없어요. 조리 있게 순서대로 쓴 한국어(또는 영어) 문장이면 충분합니다.

팁을 드리면, 본문은 '구체적인 예시 한두 개'가 열 줄의 추상적 설명보다 강합니다. "보고서는 정중하게 작성"보다 "제목 다음 줄에 '요약(3줄)'을 넣고, 금액은 1,000 단위 콤마, 마지막에 '다음 액션' 항목"이 훨씬 잘 먹힙니다.

④ 참고 파일 — 딸린 재료들

필요하면 스킬에 템플릿, 예시 문서, 간단한 스크립트 같은 파일을 함께 넣을 수 있습니다. 예컨대 '회사 보고서 스킬'이라면 실제 보고서 빈 양식(.docx)을 함께 붙여두는 거죠. 그러면 AI가 그 양식을 그대로 채워 결과를 냅니다. 이 참고 파일들도 필요할 때만 불려 옵니다. 평소엔 존재만 알고 있다가, 진짜 그 작업을 할 때 열어 봐요. 이게 다음 장에서 설명할 '점진적 공개'의 확장판입니다.

3. 왜 똑똑한 설계인가 — '필요할 때만 펼치기'

스킬의 진짜 영리한 부분은 '프로그레시브 디스클로저(progressive disclosure)', 우리말로 '점진적 공개'입니다. 말은 어렵지만 원리는 아주 단순해요. "한 번에 다 보여주지 않고, 필요한 만큼만 단계적으로 펼친다"는 뜻입니다.

이 방식 덕분에 스킬을 아무리 많이 만들어 둬도 AI가 느려지거나 혼란스러워지지 않습니다. 만약 점진적 공개가 없다면, 스킬 50개의 본문을 통째로 머리에 이고 다녀야 해서 정작 지금 할 일에 집중하지 못하겠죠. "필요할 때만 펼친다"는 이 원리가 스킬 설계의 핵심이에요.

비유: '메뉴판 → 주문하면 그때 조리'

식당을 떠올려 보세요. 메뉴판에는 요리 이름과 한 줄 설명만 있습니다. "매콤 제육볶음 — 고추장 양념에 볶은 돼지고기." 손님(사용자)이 그걸 주문하면, 그제야 주방에서 전체 레시피를 펴고 조리를 시작하죠. 손님이 시키지도 않은 100가지 요리의 레시피를 미리 다 외우고 있는 요리사는 없습니다. 그건 비효율이니까요.

스킬도 똑같습니다. description은 메뉴판의 한 줄 설명이고, 본문은 주방의 레시피입니다. AI는 메뉴판(description)만 보고 있다가, 주문(사용자 요청)이 들어오면 그 요리의 레시피(본문)만 펼칩니다. 그래서 메뉴가 100개든 500개든 부담이 없어요.

4. 도구(Tools)·MCP와는 뭐가 다를까

가장 헷갈리는 부분입니다. '도구', 'MCP', '스킬' 이 셋이 자꾸 뒤섞여서 어렵게 느껴져요. 하지만 '요리사'에 비유하면 깔끔하게 정리됩니다.

즉 도구가 '무엇을 할 수 있나'라면, 스킬은 '어떤 상황에서 어떤 순서로 하나'를 담습니다. 좋은 도구가 있어도 레시피(스킬)가 없으면 결과가 들쭉날쭉하죠. 스킬이 붙으면 AI의 결과물이 훨씬 일관되고 전문적으로 바뀌는 이유입니다.

조금 더 깊이 — 셋의 관계

세 개념은 경쟁 관계가 아니라 층층이 쌓이는 관계입니다. 아래에서 위로 올라간다고 생각하면 편해요.

언제 무엇을 쓰나 — 실전 판단표

"그래서 나는 뭘 만들어야 하죠?"라는 질문에 답하는 표입니다.

대부분의 비개발자에게 필요한 건 십중팔구 스킬입니다. 도구나 MCP는 보통 개발자가 세팅해 두고, 우리는 그 위에서 "어떻게 일할지"를 글로 적어주면 되니까요.

5. 왜 '표준'이 중요한가

Anthropic이 스킬을 공개 표준(agentskills.io)으로 푼 이유는, 예전에 MCP가 'AI가 외부 도구 쓰는 표준'으로 자리 잡은 것과 같은 그림을 노려서예요. 표준이 되면 —

• 한 번 만든 스킬을 여러 AI·여러 사람이 공유할 수 있습니다.
• 회사라면 "우리 팀 표준 스킬"을 중앙에서 관리할 수 있어요.
• Notion·Figma·Atlassian처럼 서비스 회사들이 자기 스킬을 내놓으며 생태계가 커집니다.

'표준'이 왜 이렇게 힘이 셀까

표준의 힘을 실감하려면 콘센트를 떠올려 보세요. 나라마다 플러그 모양이 다르면 여행 갈 때마다 어댑터를 챙겨야 하죠. 반대로 USB처럼 전 세계가 같은 규격을 쓰면, 어느 기기든 그냥 꽂으면 됩니다. 스킬이 표준이라는 건, 한 번 만든 매뉴얼을 이 AI, 저 AI, 우리 회사, 협력사 어디든 '그냥 꽂으면' 돌아간다는 뜻이에요.

회사 입장에서 이건 큰 변화입니다. 예전엔 "우리 업무 방식"이 베테랑 직원 머릿속에만 있었어요. 그분이 퇴사하면 노하우도 같이 사라졌죠. 스킬로 정리해 두면 그 노하우가 회사 자산으로 남고, 신입이든 AI든 똑같이 꺼내 씁니다.

6. 실제 스킬은 어떻게 생겼나 — 개념 수준 예시

감을 잡으시라고, 자주 쓰이는 스킬을 개념 수준에서 몇 개 그려볼게요. 아래는 '이런 식으로 생겼다'는 예시일 뿐, 실제 파일 코드는 아닙니다.

예시 ① PDF 스킬

• 이름: pdf-도우미
• 설명: "사용자가 PDF를 합치거나 나누거나, 텍스트·표를 뽑아내거나, 양식을 채워달라고 할 때 사용"
• 본문: 여러 PDF를 하나로 합치는 순서, 특정 페이지만 뽑는 법, 스캔본에서 글자를 인식하는 절차, 주의사항(원본 훼손 금지 등)

예시 ② 엑셀 스킬

• 이름: 엑셀-정리
• 설명: "사용자가 스프레드시트를 만들거나, 수식·차트를 넣거나, 지저분한 표 데이터를 깔끔하게 정리해달라고 할 때 사용"
• 본문: 열 제목 정리 규칙, 합계·평균 수식 넣는 법, 보기 좋은 서식, 자주 쓰는 차트 유형

예시 ③ 회사 문서양식 스킬 (가장 실용적)

• 이름: 회사-보고서-양식
• 설명: "사용자가 회사 표준 양식의 주간보고·품의서·기획안을 요청할 때, 정해진 표지·목차·요약 형식으로 작성하기 위해 사용"
• 본문: 표지 구성, 목차 순서, "요약 3줄 → 배경 → 제안 → 예상 효과 → 다음 액션" 흐름, 금액 표기 규칙
• 참고 파일: 실제 빈 보고서 양식 파일 한 개

세 번째가 특히 중요합니다. PDF·엑셀 같은 범용 스킬은 이미 여기저기 있지만, '우리 회사만의 방식'을 담은 스킬은 세상에 하나뿐이고 오직 여러분만 만들 수 있어요. 이게 조직에서 스킬이 진짜 값어치를 갖는 지점입니다.

회사 표준 스킬을 함께 쓰면 생기는 일

스킬 하나를 잘 만들어 팀에 공유하면, 그날부터 팀원 모두가(그리고 그들의 AI가) 같은 품질로 같은 양식의 결과물을 냅니다. 신입 교육 시간이 확 줄어드는 건 덤이에요.

7. 스킬 만드는 법 — 단계별 실전 가이드

드디어 핵심입니다. "그래서 나도 만들 수 있나요?" 네, 만들 수 있습니다. 다시 강조하지만 스킬은 코드가 아니라 '글'로 만듭니다. 프로그래밍 언어가 아니라, 신입에게 일을 가르치듯 우리말로 순서를 적으면 돼요. 아래 다섯 단계를 그대로 따라 해 보세요.

실전 팁 — '글 잘 쓰는 사람'이 유리하다

스킬 만들기의 승부는 결국 "일을 얼마나 명확하게 설명하느냐"에서 갈립니다. 코딩 실력이 아니라 정리력·설명력이 핵심이에요. 평소 후배에게 일을 잘 가르치던 분, 매뉴얼을 잘 만들던 분이라면 이미 좋은 스킬 제작자입니다.

8. 초보가 흔히 하는 실수 & 해결법

제가 여러 분의 첫 스킬을 봐드리면서 반복해서 보이는 실수들이 있어요. 미리 알아두면 시행착오를 확 줄일 수 있습니다.

9. 자주 묻는 질문 (FAQ)

Q. 정말 코딩을 몰라도 만들 수 있나요?
네. 스킬은 코드가 아니라 '글'입니다. 신입에게 일을 가르치듯 순서를 적으면 되고, 그 초안조차 AI에게 대신 써달라고 부탁할 수 있어요. 여러분이 할 일은 '우리 식'이 맞는지 검토하고 다듬는 것입니다.

Q. 스킬을 많이 만들면 AI가 느려지지 않나요?
아니요. 바로 그 걱정을 없애려고 '점진적 공개'가 있습니다. 평소엔 짧은 description만 보고, 필요한 스킬의 본문만 그때 펼치므로 스킬이 수백 개여도 부담이 적습니다.

Q. 스킬과 그냥 '프롬프트(지시문)'는 뭐가 다른가요?
프롬프트는 그때그때 손으로 입력하는 일회성 지시입니다. 스킬은 그 지시를 파일로 저장해 두고, AI가 상황에 맞게 알아서 꺼내 쓰는 재사용 매뉴얼이에요. 매번 같은 설명을 반복하지 않아도 된다는 게 결정적 차이입니다.

Q. 도구·MCP가 없으면 스킬은 못 쓰나요?
스킬은 대개 AI가 이미 가진 기본 능력 위에서 '어떻게 할지'를 지휘합니다. 외부 앱 연결이 꼭 필요한 스킬이라면 MCP가 필요하지만, 문서 양식·글쓰기 규칙처럼 많은 실용 스킬은 추가 연결 없이도 잘 작동합니다.

Q. 만든 스킬을 팀원과 공유할 수 있나요?
네, 그게 표준으로 만든 핵심 이유입니다. SKILL.md 파일과 참고 파일을 공유하면 팀 전체가 같은 스킬을 씁니다. 회사라면 '표준 스킬 모음'을 중앙에서 관리하기도 해요.

Q. 스킬은 한 번 만들면 끝인가요?
아니요. 업무 방식이 바뀌면 본문을, 잘 안 불려 나오면 description을 고칩니다. 살아있는 매뉴얼처럼 계속 다듬는 게 좋아요. 파일 하나만 고치면 되니 관리도 쉽습니다.

10. 좋은 스킬 체크리스트

스킬을 만든 뒤, 팀에 공유하기 전에 이 목록으로 스스로 점검해 보세요. 하나라도 '아니오'라면 그 부분부터 손보면 됩니다.

• ✅ 이름만 봐도 무엇에 관한 스킬인지 한눈에 보이나요?
• ✅ description에 '언제 쓰는지(어떤 요청·상황)'가 구체적으로 적혀 있나요?
• ✅ description이 1~2문장으로 간결한가요? (본문 내용을 욱여넣지 않았나요?)
• ✅ 이 스킬은 한 가지 일에 집중하나요? (여러 일을 몰아넣지 않았나요?)
• ✅ 본문에 순서(1·2·3)와 예시가 들어 있나요?
• ✅ 필요한 참고 파일(양식·예시)을 빠짐없이 붙였나요?
• ✅ 진짜 요청 몇 개로 테스트해서 잘 불려 나오는 걸 확인했나요?
• ✅ 결과물이 매번 일관되게 나오나요?

11. 비개발자에게 주는 의미

가장 반가운 소식은, 스킬은 코드가 아니라 '글(설명)'로 만든다는 점입니다. 즉 코딩을 몰라도, 일을 잘 정리해서 설명할 줄 아는 사람이면 좋은 스킬을 만들 수 있어요. "우리 일은 이런 순서로 한다"를 명확히 적을 수 있는 사람이 강해지는 시대입니다.

저는 이 변화가 참 반갑습니다. 지난 몇 년간 "AI 잘 쓰려면 개발을 배워야 하나" 하고 위축됐던 분이 많았는데, 스킬은 정반대 방향이에요. 업무를 깊이 아는 사람, 설명을 조리 있게 하는 사람이 유리해집니다. 여러분이 오래 쌓아온 '일머리'가 그대로 AI의 능력이 되는 거죠.

코드를 짜는 능력보다, "일을 잘 정리해 설명하는 능력"이 값어치를 갖는 시대입니다.

오늘 당장 거창한 걸 만들 필요는 없어요. 여러분이 매주 반복하는 업무 하나를 골라, 그 순서를 글로 적어 보세요. 그게 여러분의 첫 스킬이고, 첫 걸음입니다. 한 번 만들어 보면 "아, 이거였구나" 하고 감이 확 옵니다.

※ 에이전트 스킬 생태계는 빠르게 발전 중입니다. 세부 규격은 각 플랫폼의 최신 문서를 확인하세요. (2026년 7월 기준 작성)

← 기술 블로그 목록으로