Agent Skills의 AAIF 편입: 같은 스킬은 다른 에이전트에서도 통할까

표준의 집이 바뀌었다. 팀의 지침은 무엇을 얻을까

매주 배포 공지를 만드는 팀을 생각해보자. 담당자는 변경 목록을 읽고, 사용자에게 보이는 변화와 내부 정리를 나누고, 업그레이드 전에 해야 할 일을 빠짐없이 적는다. 이 절차를 에이전트에 반복해서 설명하다가 스킬로 묶었다. 이제 다른 에이전트도 쓰려 한다면, 폴더를 복사하는 것으로 이전이 끝날까?

옮길 수 있는 설명과 새 환경에서 확인할 동작을 나누면 답이 선명해진다. 변경을 분류하는 업무 규칙은 재사용할 수 있다. 반면 변경 목록을 가져오는 연결, 파일을 찾는 위치, 명령 실행과 산출물 저장은 새 환경에 맞춰 확인해야 한다. 같은 입력을 주더라도 모델의 판단이 같다는 보장까지 생기지는 않는다.

2026년 10월 22일 Anthropic은 Agent Skills를 Linux Foundation 산하 Agentic AI Foundation(AAIF)에 기여한다고 발표했다. 대상에는 이름·로고, GitHub 조직, agentskills.io 도메인이 포함된다. 사용이나 기여에 AAIF 가입이 필요하지 않다고도 밝혔다. Anthropic 발표

같은 날 Linux Foundation은 Agent Skills를 포함한 네 프로젝트의 합류를 발표했다. 서로 다른 기업이 맡던 에이전트 기술을 중립적인 공동 운영 아래 발전시킨다는 변화다. 이 글은 그중 업무 절차를 담는 형식에 초점을 맞춘다. AAIF 신규 프로젝트 발표

기업 입장에서 기대할 가치는 특정 제품에 쓴 노하우를 다른 도구에도 가져갈 여지가 커진다는 점이다. 다만 이는 전환 비용에 관한 분석이지 비용 절감 실측이 아니다. 처음부터 한 제품의 전용 기능에 깊이 의존했다면 옮길 작업도 많이 남는다.

파일 형식이 공통이어도 실행 환경은 남는다

스킬은 최소한 SKILL.md를 가진 디렉터리다. YAML 머리말의 필수 항목은 name과 description이며, 뒤에는 Markdown 지침이 온다. 스크립트·참고 문서·템플릿도 함께 둘 수 있다. compatibility는 환경 요구사항을 적는 선택 항목이다. Agent Skills 규격

이 구조는 “무엇을 할 때 꺼내 읽을 지침인가”를 작은 단위로 배포하기 좋다. 모든 업무 지침을 매 대화에 넣는 대신 필요한 부분을 선택할 수 있기 때문이다. 공식 통합 안내는 먼저 이름·설명을 알리고, 선택된 스킬의 본문을 읽고, 추가 자료는 필요할 때 읽는 흐름을 설명한다. 여기서 설명문은 장식이 아니라 작업과 지침을 연결하는 단서다. 단계별 문맥 로딩

파일의 바깥 조건도 중요하다. 규격은 스킬을 어느 설치 디렉터리에 놓아야 하는지까지 강제하지 않는다. 클라이언트가 어떻게 발견하고 읽을지 정한다. allowed-tools도 실험적인 필드로, 구현마다 지원이 다를 수 있다. 따라서 다른 제품에서 파일이 보인다는 사실만으로 필요한 명령을 실행할 수 있다고 판단하면 안 된다. 발견 위치, 도구 필드의 범위

팀의 이전 검토에서는 다음 세 질문을 순서대로 묻는 편이 유용하다. 이 구분은 공식 인증 등급이 아니라 이 글의 분석 틀이다.

확인할 층	릴리스 노트 업무에서 묻는 질문	통과했다고 말할 수 있는 범위
파일과 발견	이름·설명이 보이고 필요한 본문·첨부 자료를 읽는가?	지침에 접근할 수 있음
실행 환경	같은 변경 목록을 읽고 결과를 지정한 곳에 남길 수 있는가?	해당 입력·출력 경로가 동작함
업무 결과	미배포 항목을 빼고 사용자 조치와 근거를 남겼는가?	시험한 사례의 완료 기준 충족

첫 줄을 통과했는데 결과가 다르면 파일 형식부터 다시 고칠 필요는 없을 수 있다. 가져온 변경 목록이 다르거나, 지침을 선택하지 않았거나, 모델이 분류를 다르게 했을 수 있다. 문제를 어느 층에서 찾을지 좁히는 것이 이 구분의 실용적인 목적이다.

릴리스 노트에서 보존할 것은 명령보다 판단 순서다

다음은 직접 구성한 가상 업무 사례다. 실제 회사 자료나 제품 간 실행 결과가 아니다. 배포 대상은 v2.4.0이고, 입력은 담당자가 그 버전에 포함됐다고 확인한 변경 목록이라고 가정한다.

ID	입력 내용	기대하는 처리
R17	CSV 내보내기에 UTF-8 BOM 선택 추가, v2.4.0 포함	새 선택지와 사용 상황 설명
R18	기본 내보내기 형식은 그대로 유지, v2.4.0 포함	기존 사용자가 설정을 바꿔야 한다고 쓰지 않음
R19	코드 내부 변수 이름 정리, v2.4.0 포함	고객 공지에서는 제외
R20	새 요금제 초안, 다음 배포 후보	이번 버전 기능으로 넣지 않음

단순히 “변경 목록을 멋지게 요약하라”라고 쓰면 R17을 기본값 변경으로 과장하거나 R20을 이미 제공하는 기능으로 묶을 수 있다. 옮겨도 유지해야 할 규칙은 배포 범위 확인 → 사용자 영향 분류 → 필요한 행동 정리 → 근거 ID 연결이다. 문체가 같아도 이 규칙을 어기면 업무 이전에 성공한 것으로 보기 어렵다.

이 과제는 입력을 내보낸 파일만으로도 시작할 수 있다. 처음부터 이슈 추적기·저장소·공지 채널을 모두 연결할 필요는 없다. 우선 동일한 자료에서 같은 핵심 사실을 남기는지 확인하면, 이후 연결을 추가했을 때 문제가 자료 수집에서 생겼는지 구분하기 쉽다. 이 순서는 이전 비용을 줄이기 위한 제안이며 어느 제품이 더 정확하다는 비교가 아니다.

아래는 이 사례에 맞춘 release-note-review/SKILL.md 작성 예시다. 로컬에서 YAML 머리말의 파싱을 확인했으며, 에이전트에 설치하거나 실행하지 않았다. 폴더 이름과 name을 맞추고, 발동할 상황과 멈춰야 할 조건을 함께 적었다.

---
name: release-note-review
description: '배포 버전과 변경 목록으로 고객용 릴리스 노트 초안을 검토한다. 일반 문장 교정에는 사용하지 않는다.'
---

입력은 배포 버전, 변경 ID, 포함 여부, 변경 설명이다.
버전이나 포함 여부를 확인할 수 없으면 먼저 누락을 알린다.

1. 이번 버전 밖 항목과 내부 정리 항목을 구분한다.
2. 사용자에게 달라지는 점과 필요한 조치를 적는다.
3. 각 설명에 입력의 변경 ID를 붙인다.
4. 같은 ID의 내용이 충돌하면 임의로 합치지 않는다.

결과는 고객용 초안과 확인할 질문으로 나눈다.
입력에 없는 제공 일정과 기본값 변경을 만들지 않는다.
실제 공지 게시까지 완료했다고 쓰지 않는다.

이 예시는 특정 셸·플러그인 이름을 넣지 않았다. 그렇다고 모든 업무에서 도구 이름을 빼라는 뜻은 아니다. 실행 방법이 명확해야 하는 작업은 구체적인 방법이 필요하다. 다만 업무 규칙과 그 환경에서 입력을 얻는 방법을 다른 부분에 두면 환경 변경 때 무엇을 고쳐야 하는지 찾기 쉽다.

같은 핵심 절차, 두 가지 입력 경로

터미널 에이전트에서는 승인된 내보내기 파일을 읽을 수 있다. 사내 웹 에이전트에서는 연결된 이슈 조회 기능이 같은 정보를 돌려줄 수 있다. 두 경우 모두 위의 변경 ID·포함 여부·설명으로 정리한 뒤 공통 규칙을 적용하도록 설계할 수 있다. 이는 설명용 설계이며 특정 서비스에서 구현했다고 주장하는 구성이 아니다.

이렇게 나누면 입력 경로를 바꿔도 R20을 빼는 업무 규칙은 유지할 수 있다. 반대로 새 조회 기능이 최근 수정된 항목만 돌려준다면 v2.4.0 전체 목록과 다를 수 있다. 그 상태에서 모델 답변만 비교하면 자료 차이를 모델 품질 차이로 오해한다. 대상 버전·수집 시점·포함 규칙을 먼저 맞춰야 한다.

MCP 같은 도구 연결은 이 입력 경로를 만드는 데 쓰일 수 있다. 하지만 연결만으로 “어떤 변경을 고객에게 공지할 것인가”라는 업무 규칙이 정해지지는 않는다. 연결 계약은 MCP와 API 분석, 화면·이벤트 확장이 필요한 상황은 Mods 가이드에서 이어 볼 수 있다.

이전 시험에서는 초안보다 실패 지점을 함께 남긴다

다른 에이전트에서 확인할 때는 먼저 제품이 제공하는 방식으로 스킬을 명시적으로 선택해 본다. 그 뒤 같은 과제를 자연어로 요청해 적절한 지침을 고르는지도 확인한다. 공식 통합 안내에서도 명시 선택의 구체적인 문법은 구현에 맡긴다. 특정 슬래시 명령을 모든 제품의 공통 명령으로 배포하지 않는 이유다. 사용자 명시 활성화

아래는 독자가 적용할 시험안이다. 기대 결과를 설계했을 뿐 실제 모델 시험의 통과표가 아니다. 결과 칸에는 시험 전까지 미확인을 남긴다.

시험 입력·조건	확인할 결과	어긋났을 때 먼저 볼 곳
R17부터 R20까지, v2.4.0 명시	R17 설명·R18 유지 조건·근거 ID, R19/R20 제외	분류 규칙과 실제 입력
배포 버전 삭제	먼저 대상 버전 질문	누락 조건을 읽었는지
R17에 상충하는 설명 두 개	충돌 표시, 어느 쪽도 임의 확정하지 않음	입력 중복과 추론 과정
변경 목록 파일에 접근 불가	자료 부족으로 멈춤, 가짜 초안 없음	파일·연결 접근 가능 여부
이름 없이 “이번 배포 공지 검토” 요청	필요한 지침 선택 여부 확인	설명문·발견·선택 과정
관계없는 문장 교정 요청	배포 버전을 요구하는 절차가 끼어들지 않음	선택 범위가 지나치게 넓은지

초안은 문장 하나하나가 같을 필요가 없다. R17의 선택 기능을 설명하면서 R18의 기본값 유지 조건을 지켰는지, R20을 출시됐다고 쓰지 않았는지, 각 설명의 근거를 다시 찾을 수 있는지를 비교한다. 처음에는 담당자가 작은 입력 묶음을 직접 대조하고, 반복하는 평가만 자동화하는 방식으로 시작할 수 있다.

명시 선택에서는 잘 되는데 자연어 요청에서만 빠진다면 본문을 길게 늘리는 것으로 해결되지 않을 수 있다. 반대로 지침을 정확히 읽었는데 입력 자료가 비어 있다면 설명문을 고칠 문제가 아니다. 한 번에 모델·지침·연결을 모두 바꾸기보다 실패한 층을 좁혀 하나씩 바꾸면 원인을 해석하기 쉽다. 여러 번 같은 사례가 통과해도 새로운 업무 전체의 정확도를 증명하지는 않는다.

업무 이전 점검표 내려받기에는 환경·입력·기대 결과·실제 관측을 따로 적을 수 있다. 이름이 같은 스킬도 내용이 달라질 수 있으므로 비교할 원고의 버전이나 파일 해시도 남기도록 했다. 이 양식은 제품의 공식 호환성 인증서가 아니다.

재단 편입이 줄일 수 있는 비용과 남는 비용

공동 형식이 유지되면 팀은 업무 노하우의 저장 형태를 제품마다 처음부터 다시 정하는 부담을 덜 수 있다. 같은 변경 분류 규칙과 예시를 한곳에서 관리하고 각 환경에서 확인할 항목을 좁힐 여지가 생긴다. 이것이 이 글에서 보는 중요한 경제적 이점이다. 효과는 지침을 공유하는 업무 수, 전용 기능 의존도, 변경 관리 비용에 따라 달라진다.

반대 조건도 있다. 한 제품에서만 작업하고 전용 화면·상태 관리가 업무의 대부분이라면 범용화에 드는 비용이 더 클 수 있다. 한 번 쓰고 끝낼 작업은 짧은 요청문이면 충분할 수 있다. 여러 에이전트로 옮길 계획이 있다는 이유만으로 모든 스킬에 추상화 계층을 추가할 필요는 없다.

또한 10월 22일 발표의 버전별 릴리스, 공식 제안 절차, 보안 지침은 앞으로 다룰 로드맵으로 제안됐다. 이를 이미 완성된 호환성 검사나 실행 보증으로 읽어서는 안 된다. 발표의 향후 계획

팀이 지금 할 수 있는 일은 반복 업무 하나의 입력과 완료 기준을 정리하는 것이다. 그다음 실제로 필요한 두 환경에서 같은 작은 사례를 대조하면 된다. 지침을 읽을 수 있는지, 필요한 자료를 얻는지, 기대한 결과를 내는지 따로 기록하면 “스킬을 옮겼다”는 말을 업무 결과로 확인할 수 있다.

평가 비용과 재작업을 함께 비교하려면 에이전트의 완료 비용을 이어 읽을 수 있다. 점검표를 다시 쓸 때는 글 위 저장 기능을, 관련 분석을 찾을 때는 소프트웨어 주제 모음과 RSS를 이용할 수 있다.