Agent Skills 재단 편입, 업무 규칙은 언제 옮길까

10월 22일에 바뀐 것은 표준의 운영 주체

Anthropic은 2026년 10월 22일 Agent Skills를 Linux Foundation 산하 Agentic AI Foundation, 줄여서 AAIF에 기증한다고 발표했습니다. 이름과 로고, GitHub 조직, agentskills.io 도메인이 기증 대상입니다. Linux Foundation의 같은 날 발표도 이를 재단의 새 프로젝트로 명시했습니다.

이용자가 알아둘 변화는 특정 회사가 만든 형식이 공개적이고 벤더 중립적인 운영 아래 놓인다는 점입니다. 표준을 이용하거나 기여하려고 AAIF 회원이 될 필요는 없습니다. 다만 이것을 개별 AI 서비스의 무료화나 회사의 AI 사용 허가로 읽으면 범위가 달라집니다. 요금과 사내 정책은 이용할 서비스에서 따로 살펴야 합니다.

버전별 릴리스, 공식 제안 절차, 스킬 작성·설치 보안 안내를 담은 로드맵은 이번 발표에서 제안된 상태입니다. 재단으로 옮겼으니 이런 작업이 이미 모두 끝났다고 받아들일 단계는 아닙니다.

Agent Skills로 묶을 것은 문의가 아니라 분류 규칙

스킬은 최소한 SKILL.md 파일을 포함하는 폴더입니다. 그 안에 업무 지침을 쓰고, 필요하면 참고 문서·양식·스크립트를 함께 둘 수 있습니다. 폴더에 코드를 반드시 넣어야 하는 구조는 아닙니다. 문의 분류처럼 글로 설명할 수 있는 절차라면 우선 분류 기준과 결과 양식부터 정리할 수 있습니다.

문의 내용은 매번 바뀌어도 유형별 담당부서와 애매한 문의의 처리 기준은 반복될 수 있습니다. 이 고정 부분이 스킬 후보입니다. 반대로 이번 문의의 증상, 발생 시점, 사용자가 남긴 설명까지 고정 지침에 섞으면 다음 문의를 처리할 때 이전 상황이 끼어들기 쉽습니다.

Agent Skills 도입 여부를 요청문의 글자 수로 정할 수는 없습니다. 길이를 늘리는 부분이 문의의 배경인지, 빠뜨리면 안 되는 공통 규칙인지 먼저 구별해야 합니다. 예를 들어 담당부서 이름 하나만 바뀌어도 여러 대화의 결과를 함께 고쳐야 한다면, 문장의 길이보다 기준을 한곳에서 관리할 필요가 생깁니다.

설치 없이 먼저 만드는 문의 분류 요청문

아래는 실제 회사의 조직도나 처리 기록이 아닌 가상 예시입니다. 회사에서 허용한 AI 도구에 넣을 수 있도록 개인 이름·계정·내부 주소 없이 만들었습니다. 담당부서는 연습용으로 지정했으므로 실제 업무에서는 회사가 승인한 분류 기준으로 바꿔야 합니다.

처음부터 Agent Skills 파일을 만들 필요는 없습니다. 아래 내용을 일반 요청문으로 전달해 어떤 기준이 빠졌는지 살피면, 재사용할 지침의 범위도 드러납니다.

다음 사내 IT 문의를 분류해 주세요. 실제 전달은 하지 않고 분류안만 만듭니다.
유형·담당부서: VPN 연결→네트워크팀, 프린터 출력→총무팀, 업무 앱 접근 권한→앱운영팀.
기준: 증상만으로 유형을 고를 수 없거나 두 유형에 걸치면 유형은 '사람 확인', 담당부서는 '미정'으로 둡니다.
결과 열: 문의 번호 / 유형 / 담당부서 / 판단 근거 / 추가로 물을 질문.
문의 1: VPN 연결 버튼을 누르면 연결 실패 메시지가 나옵니다.
문의 2: 프린터는 보이지만 출력물이 나오지 않습니다.
문의 3: 업무 앱이 열리지 않습니다. 권한 문제인지 연결 문제인지는 모르겠습니다.

파일 형식이 같아도 환경과 공유 범위는 따로

Agent Skills는 이름과 설명으로 필요한 스킬을 찾고, 업무와 맞으면 SKILL.md의 전체 지침을 읽으며, 필요한 참고 자료를 추가로 사용하는 구조입니다. 그래서 설명에는 무엇을 하는지뿐 아니라 언제 쓸지도 드러나야 합니다. 이름만 ‘IT 도우미’로 붙이기보다 ‘문의 유형과 담당부서를 분류하되 실제 배정은 하지 않는 업무’처럼 범위를 좁혀 두면 적용할 일을 구별하기 쉽습니다.

형식 명세에서 name과 description은 필수 항목이고, 환경 조건을 적는 compatibility는 선택 항목입니다. 스킬을 받았다면 대상 제품, 필요한 프로그램, 네트워크 접근 조건을 먼저 읽을 수 있습니다. 환경 설명이 비어 있을 때도 내 회사의 도구에서 실행 가능한지는 별도로 살펴야 합니다.

텍스트만 읽고 분류하는 지침과 사내 문의 시스템을 조회하는 스킬은 준비가 다릅니다. 후자는 시스템 접근과 도구 연결이 필요할 수 있습니다. Agent Skills 형식을 썼다는 이유만으로 이런 연결이나 권한까지 따라오는 것은 아닙니다. 도구 목록을 적는 allowed-tools 역시 실험적 항목이고 구현별 지원이 다를 수 있습니다.

재사용과 배포도 구별해야 합니다. Claude의 문서상 사용자 정의 스킬은 API에서는 워크스페이스 구성원이 접근할 수 있지만, claude.ai에서는 개인 단위이며 조직 전체 공유·관리자 중앙 관리 방식과 구별됩니다. 같은 제품군 안에서도 이 차이가 있으므로, 파일 하나를 고쳤을 때 동료 계정에도 자동으로 반영된다고 기대하면 곤란합니다.

여러 사람이 쓸 계획이라면 지침의 관리 담당자와 최신본 위치, 바뀐 기준을 전달할 경로를 정해 두는 편이 낫습니다. 혼자 쓰는 요청문을 폴더로 옮기는 일과 팀의 공통 업무 규칙을 배포하는 일은 필요한 관리가 다릅니다. Agent Skills를 검토할 때도 이 둘을 나누면 불필요한 설치부터 시작하는 일을 줄일 수 있습니다.

외부에서 받은 스킬은 출처와 내용을 읽은 뒤 사용해야 합니다. 코드 실행, 외부 연결, 파일 접근이 들어 있다면 회사의 허용 범위를 먼저 확인합니다. 재단 편입 소식이 개별 스킬의 안전 심사를 대신하지는 않습니다. 분류만 하려는데 파일 업로드나 추가 권한부터 요구한다면, 텍스트 지침만으로 업무를 진행할 수 있는지부터 검토할 이유가 있습니다.

첫 비교는 세 문의의 정답 기준부터

앞의 예시를 시험한다면 문의 1은 VPN 연결·네트워크팀, 문의 2는 프린터 출력·총무팀이 예상 분류입니다. 문의 3은 ‘사람 확인·미정’으로 남아야 합니다. 앱이 안 열린다는 사실만으로 접근 권한 문제를 확정할 수 없기 때문입니다. 추가 질문에는 오류 메시지처럼 원인을 좁힐 정보가 들어가면 됩니다.

이렇게 사람이 기대하는 분류를 먼저 적고 일반 요청문의 결과와 비교합니다. 세 건 모두 부서를 채웠다는 이유로 잘됐다고 판단하면 예외 처리가 빠진 결과를 놓칩니다. 사람에게 넘길 항목을 제대로 남겼는지도 업무 결과의 일부입니다.

틀린 결과가 나오면 원인을 나눠 봅니다. 기준에 없는 담당부서를 만들어 냈는지, 한 문의에 증상이 둘인데 하나로 밀어 넣었는지, 분류안과 실제 전달을 혼동했는지가 수정할 지점입니다. 사람 사이에서도 담당부서 의견이 갈리는 문의라면 파일 형식을 바꾸기 전에 업무 기준을 합의해야 합니다.

스킬로 옮길 때는 회사에서 사용을 허용한 Agent Skills 지원 도구에 고정 규칙과 결과 열을 넣습니다. 매번 달라지는 문의는 작업 입력으로 따로 전달합니다.

스킬로 바꾼 뒤에는 같은 시험 문의로 다시 비교해야 합니다. 파일 형식이 바뀌었다는 사실과 분류가 나아졌다는 결과는 별개입니다. 대표 문의와 애매한 문의를 나눠 기록하면, 지침에서 고칠 부분과 사람이 계속 맡을 예외를 구별할 수 있습니다.

이 글은 2026년 10월 24일 열람한 공개 문서를 바탕으로 썼으며, 실제 설치나 제품 간 이식·분류 성능 시험은 수행하지 않았습니다. 계정별 이용 조건과 회사 자료의 입력 허용 범위는 사용할 서비스와 사내 정책에서 확인해야 합니다.

지금 할 일은 설치보다 간단합니다. 반복되는 문의 한 종류를 골라 ‘항상 적용할 기준’과 ‘이번 문의에서만 달라질 내용’을 나눠 적어 보세요.