에이전트 스킬(Agent Skills)
(agentskills.io)- 에이전트 스킬은 인공지능 에이전트에 새로운 기능과 전문 지식을 추가하기 위한 개방형 포맷
- Anthropic이 개발한 후 오픈 스탠더드로 공개되어 다양한 에이전트 제품이 채택중
- 스킬은 지침, 스크립트, 리소스로 구성된 폴더 형태로, 에이전트가 이를 탐색해 더 정확하고 효율적으로 작업을 수행함
- 도메인 전문성, 새로운 기능 확장, 반복 가능한 워크플로우, 상호운용성을 지원
- 기업과 개발자는 이를 통해 조직 지식의 재사용과 배포 자동화를 실현할 수 있음
개요
- Agent Skills는 에이전트에게 새로운 능력과 전문성을 부여하기 위한 단순하고 개방된 형식
- 각 스킬은 명령어, 스크립트, 리소스가 포함된 폴더로 구성되어, 에이전트가 이를 불러와 작업 정확도와 효율성을 높임
왜 Agent Skills인가
- 에이전트는 점점 더 강력해지고 있지만, 실제 업무를 안정적으로 수행하기 위한 맥락 정보 부족 문제 존재
- 스킬은 절차적 지식과 조직·팀·사용자별 맥락을 필요할 때 로드할 수 있도록 제공
- 스킬을 보유한 에이전트는 작업에 따라 능력을 확장 가능
- 스킬 작성자는 한 번 구축한 기능을 여러 에이전트 제품에 배포 가능
- 호환 에이전트는 사용자가 즉시 새로운 기능을 추가할 수 있음
- 팀과 기업은 조직의 지식을 버전 관리 가능한 이동식 패키지로 보존 가능
Agent Skills로 가능한 일
- 도메인 전문성: 법률 검토, 데이터 분석 등 특화된 지식을 재사용 가능한 지침으로 패키징
- 새로운 기능: 프레젠테이션 제작, MCP 서버 구축, 데이터셋 분석 등 다양한 기능 추가
- 반복 가능한 워크플로우: 다단계 작업을 일관되고 감사 가능한 프로세스로 전환
- 상호운용성: 동일한 스킬을 여러 호환 에이전트 제품에서 재사용 가능
채택 현황
- Agent Skills는 여러 AI 개발 도구에서 지원됨
- 예시로는 Factory.ai, Gemini CLI, Mux, Ampcode, Letta, Autohand.ai, Spring AI, Goose, Piebald.ai, OpenAI Codex, Cursor, Databricks, Mistral Vibe, Roocode, VS Code, Agentman.ai, Trae.ai, Commandcode.ai, Firebender, Opencode.ai, Claude.ai 등이 포함됨
오픈 개발
- Agent Skills 포맷은 Anthropic이 처음 개발하고 오픈 스탠더드로 공개
- 이후 다양한 에이전트 제품이 이를 채택하고 있으며, 생태계 전반의 기여를 허용
- GitHub 저장소를 통해 포맷과 예시 스킬을 확인 가능
시작하기
- “What are skills?” 페이지에서 스킬의 구조와 작동 방식 학습 가능
- “Specification”에서 SKILL.md 파일의 포맷 명세 확인 가능
- “Integrate skills”를 통해 에이전트나 도구에 스킬 지원 추가 가능
- GitHub에서 예시 스킬 과 레퍼런스 라이브러리 를 탐색 가능
Agent Skills is an open format maintained by Anthropic and open to contributions from the community.
앤트로픽이 표준을 만든거네요
네 보내주신 그거는 구현체
본문에 공유된건 Spec
마치
도커같은 녀석의 표준 = OCI
도커, podman = OCI 를 구현한 컨테이너 런타임
(틀릴 수 있어염)
Hacker News 의견들
-
이 논의는 표준화의 필요성에 대한 의문에서 출발함
나는 좋은 문서의 핵심은 여전히 “사람이 읽기 쉽게 쓰는 것”이라고 생각함. 굳이 새로운 포맷을 강제할 이유가 있을까 싶음. 만약 생산성 향상이 진짜라면 비교 연구로 입증할 수 있을 것임- 다른 사람들이 말한 것 외에도, 표준화는 훈련과 RL에 활용할 수 있는 기회를 열어준다고 봄
- 실제로 비교 실험이 있었음. Hugging Face 직원이 Qwen3-0.6B 모델을 codex + skills로 파인튜닝했더니 humaneval 점수가 +6 향상되었다고 함. 관련 링크는 여기, 그리고 프로젝트는 huggingface/upskill에 있음
- 시스템은 단순한 문서가 아니라, 모든 skills의 인덱스를 만들어 대화마다 LLM에 전달함. 이렇게 하면 LLM이 필요할 때만 skill을 읽음. GUI의 기능 탐색성과 비슷한 개념임. 개인적으로는 README 중심 구조가 더 직관적이라 생각함
- 나는 Claude Code로 업무 자동화를 하며 각 작업을 슬래시 명령으로 연결해둠. 결국 skills도 문서화의 다른 형태일 뿐이라 느낌. 장기적으로는 context window 확장과 모델 지능 향상으로 skills 패러다임이 사라질 것 같음
- 하지만 현재 모델 기준으로 보면, Claude는 skill 설명까지만 읽고 멈추기 때문에 토큰 절약 효과가 큼. 대형 리포지토리에서는 이 차이가 체감될 정도임. 이런 패턴을 널리 알릴 가치가 있음
-
우리 팀은 skills를 재사용 가능한 준결정적 함수처럼 다루며 성공을 거두었음
예를 들어/create-new-endpoint스킬은 OpenAPI 갱신, 통합 테스트 추가 등 모든 보일러플레이트를 포함함. CLI에서 JIRA 티켓 번호를 입력하면 LLM이 일관된 품질로 작업을 완수함- 누군가 “시간이 지나도 일관성을 어떻게 테스트하느냐”고 물었음
-
폴더 구조를 표준화하자는 제안이 있었음
.claude/skills .codex/skills .opencode/skills .github/skills- 표준은 아니지만 대부분의 CLI 도구가
.md파일을 스캔해 실행함. 그래도 플러그인까지 포함한 통합 표준화가 있으면 좋겠음 - 실제로 Codex가 시작했고 OpenCode가 바로 뒤따랐다고 함. 관련 트윗
- 이 논의는 agentskills/agentskills#15에서도 진행 중임
- 어떤 사람은 “아직 너무 초기라 표준화는 창의성을 제한할 수 있다”고 함
- 또 다른 사람은 XDG base spec을 따라
~/.config/claude같은 경로를 쓰는 게 낫다고 주장함. 현재의~/.claude방식은 불편하다고 함
- 표준은 아니지만 대부분의 CLI 도구가
-
하위 폴더마다 README.md를 만들어 관련 skill을 링크하라는 팁이 있었음. 사람에게도 유용함. 관련 글은 Claude Skills Considered Harmful
- “skills는 결국 특정 주제의 README일 뿐”이라는 의견이 나옴. 반복적으로 설명해야 하는 내용을 skill로 정리하면 됨. 표준 폴더를 따를 필요도 없고, 필요할 때 직접 context에 추가하면 됨
- 또 다른 사람은
just같은 명령 실행기를 쓰면 사람과 에이전트 모두에게 도움이 된다고 함
-
나는 skills를 명시적 워크플로우로 다루는 게 효과적이었음
“X를 하고, Y를 하고, Z를 검증한다”처럼 완결된 절차로 정의하면 에이전트가 이를 하나의 모드로 인식함. 반면 모호한 가이드라인 형태는 무시되기 쉬움- 어떤 사람은 특정 상황에서 skill을 자동 활성화하는 hook 시스템을 Claude에 적용했다고 함. Python 파일을 다룰 때 자동으로 관련 skill을 불러오는 식임
- 또 다른 사람은 skill과 command의 차이가 모호하다고 지적함. 결국 둘 다 명령처럼 쓰인다면 구분이 필요한가 하는 의문임
- 누군가는 이 구조가 Obsidian 노트나 CLI 명령 모음과 비슷하다고 함
- 또 다른 사람은 skill의 활성 조건을 매우 명확히 기술해야 한다고 강조함. Claude Code에서는
/foo처럼 명시적 호출이 가능하므로 그 방식을 선호함
-
누군가는 skills를 통해 암묵적 도메인 지식을 문서화할 수 있다고 봄. 개발자 머릿속에 있던 규칙을 기록하고, 이를 LLM 학습에 재활용할 수 있음
-
“에이전트가 요청하지 않으면 skills를 사용하지 않는다”는 질문이 나왔음
- 여러 사람도 같은 문제를 겪고 있음. 현재 모델은 skills 기반으로 RLVR 훈련되지 않아 혼란스러워함. 다음 세대 모델(예: Opus)은 훨씬 안정적으로 skills를 사용할 것으로 기대함
- Vercel의 평가에서도 56%의 경우 skill이 호출되지 않았다고 함. 대신 AGENTS.md 접근법이 더 넓은 범위에서 효과적이었다고 보고함. 관련 블로그
- Codex를 쓰는 사람은 AGENTS.md에서 skill 디렉터리를 명시해두면 꽤 잘 작동한다고 함. 단, skills가 많아질수록 충돌 가능성이 커지므로 단순하게 유지하는 게 좋다고 함
- 또 다른 사람은 skills를 거의 사용하지 못했다고 하며, 차라리 skill 내용을 AGENTS.md에 직접 넣는 게 더 정확했다고 함
-
skills.sh에서 세 번째로 인기 있는 skill은 단순히 명령 다운로드 링크였다고 함. 이런 SKILLS.md/AGENTS.md/COMMANDS.md 파일들은 결국 프롬프트 모음일 뿐이며, 잘못 쓰면 위험할 수 있음
- 하지만 어떤 사람은 “도구는 결국 책임 있는 사용이 중요하다”고 응답함
-
새로운 프로그래밍 언어를 개발 중인 사람은 LLM이 학습하지 않은 언어를 이해하도록 하기 위해 AGENTS.md와 SKILLS를 사용한다고 함. 표준화 덕분에 도구 통합이 쉬워졌다고 함
-
진짜 가치는 포맷이 아니라 점진적 공개(progressive disclosure) 에 있음
모든 지침을 한 문서에 몰아넣으면 불필요한 토큰을 낭비함. skills 패턴은 필요한 순간에만 세부 내용을 불러오게 해줌. 표준화는 주로 배포와 재사용을 위한 것임- 이에 대해 MOOLLM 프로젝트의 개발자가 “Semantic Image Pyramid” 개념으로 확장했다고 설명함.
GLANCE.yml → CARD.yml → SKILL.md → README.md 순으로 점진적 세분화를 적용함.
GLANCE는 5~70줄로 “관련 있는가?”만 판단, CARD는 인터페이스 정의, SKILL은 실제 절차, README는 인간용 설명임.
INDEX.md가 INDEX.yml보다 80% 이상 압축률이 높고 서사적 구조를 제공한다고 함.
관련 링크: INDEX.yml, INDEX.md
또한 sniffable-python 구조를 통해 코드 상단 50줄만 읽어도 API를 파악할 수 있게 함.
관련 자료: Semantic Image Pyramid 설명, sister-script, sniffable-python README, sniffable-python SKILL
- 이에 대해 MOOLLM 프로젝트의 개발자가 “Semantic Image Pyramid” 개념으로 확장했다고 설명함.