에이전트에 반복 업무를 맡기다 보면 모델 선택보다 먼저 피곤해지는 지점이 있다. 같은 배포 절차와 도구 연결을 VS Code용, CLI용, 사내용으로 조금씩 다시 적는 일이다. 기능은 비슷한데 디렉터리 구조와 매니페스트가 다르고, 한쪽만 고친 뒤 다른 쪽을 놓치기 쉽다.
GitHub는 8월 12일 Agent Plugins 1.0의 정식 지원을 발표했다. 이 규격은 에이전트 스킬과 MCP 서버 설정을 하나의 설치 가능한 플러그인으로 묶는다. GitHub는 이를 AWS, Anysphere, Microsoft, OpenAI, Vercel과 함께 8월 6일 공개했고, Google도 같은 날 핵심 관리자로 참여했다고 밝혔다. 현재 GitHub Copilot 쪽에서는 VS Code, Copilot CLI, Copilot SDK, Copilot 앱에서 사용할 수 있다.
이번 변화는 새 모델 하나가 추가된 소식과는 결이 다르다. 에이전트가 일을 수행하는 데 필요한 지식과 도구 연결을 어떤 단위로 관리할지에 관한 변화다. 여러 개발 환경을 오가는 팀이라면 작은 자동화 하나도 이식 가능한 패키지로 다루는 출발점이 될 수 있다.
무엇을 한 묶음으로 다루게 되나
Agent Plugins 1.0에서 중심이 되는 것은 스킬과 MCP 서버다. 스킬은 에이전트가 따라야 할 업무 절차와 맥락을 담은 문서형 지식이다. MCP 서버는 에이전트가 외부 시스템이나 로컬 도구를 호출할 수 있게 연결하는 설정이다. 예를 들어 배포 플러그인 하나에 배포 전 점검 순서를 적은 스킬과, 내부 배포 도구에 접속하는 MCP 설정을 함께 넣을 수 있다.
기존에도 각 제품의 플러그인으로 비슷한 일을 할 수 있었다. 문제는 같은 내용이라도 클라이언트마다 별도 매니페스트와 폴더 구조를 유지해야 했다는 점이다. GitHub가 설명한 규격은 공통 부분을 skills/와 mcp.json으로 정리하고, Copilot에만 필요한 에이전트·명령·규칙·훅은 com.github.copilot/ 아래에 둔다. 호환 클라이언트는 공통 부분을 읽고, 모르는 공급자 전용 디렉터리는 무시한다.
여기서 중요한 단어는 호환성이다. 플러그인 파일 하나가 있다고 해서 모든 에이전트 도구에서 같은 동작이 보장되는 것은 아니다. 각 클라이언트가 어떤 스킬 형식과 MCP 설정을 지원하는지 확인해야 한다. 규격은 중복 포장을 줄이는 장치이지, 서로 다른 실행 환경의 차이를 없애는 마법은 아니다.
왜 한국의 작은 팀과 개인 자동화에도 의미가 있을까
사내 개발 플랫폼을 크게 운영하지 않더라도 맥락은 비슷하다. NAS에서 서비스 운영 절차를 자동화하거나, 코드 저장소 점검과 배포 확인을 에이전트에 맡길 때, 도구별 지시문을 복사해 두면 시간이 갈수록 기준이 갈라진다. 한 곳에서는 테스트를 먼저 실행하게 했는데 다른 곳에서는 바로 배포를 제안하는 식이다.
공통 절차를 하나의 플러그인으로 만들면 수정 지점이 줄어든다. 더 현실적인 이점은 검토 범위가 선명해지는 데 있다. 새 도구 연결을 추가할 때 산재한 프롬프트와 설정을 찾는 대신, 플러그인 단위로 어떤 스킬과 MCP 서버가 들어갔는지 읽고 승인할 수 있다.
GitHub의 8월 13일 주간 변경 공지는 플러그인 정식 지원과 함께 Copilot 앱의 플러그인 버전 확인 및 개별·일괄 업데이트 기능을 소개했다. Copilot CLI에는 하위 에이전트와 작업을 보는 /tasks, 실행 중 프롬프트와 명령을 대기열에 넣는 기능, 사용자 편집을 버리지 않고 변경을 되돌리는 /rewind도 추가됐다. 기능을 한꺼번에 도입하기보다, 플러그인과 실행 기록을 함께 관리하라는 신호로 읽는 편이 낫다.
포터블하다고 해서 안전한 것은 아니다
플러그인은 스킬만 담지 않는다. MCP 서버 설정을 함께 담을 수 있다. 즉 설치가 지식 문서 추가에서 끝나지 않고, 외부 URL·명령·서비스 연결을 에이전트에게 소개하는 일이 될 수 있다. 이식성이 좋아질수록 검토하지 않은 설정도 더 쉽게 옮겨질 수 있다.
GitHub는 기업용 관리 설정에서 특정 플러그인을 자동 설치하거나 차단하고, 허용된 마켓플레이스를 추가하거나 제한할 수 있다고 설명한다. MCP 서버도 URL, 명령, 이름 단위의 허용 목록과 함께 쓰라고 권한다. 개인 환경에서도 같은 원칙을 축소해 적용할 수 있다. 출처가 불명확한 플러그인은 설치하지 않고, 서버 설정에 적힌 실행 명령과 네트워크 목적지를 먼저 읽는 편이 안전하다.
또 하나는 업데이트다. 플러그인을 코드처럼 취급해야 한다. 버전이 바뀔 때 스킬의 지시가 달라졌는지, MCP 서버 주소나 실행 인자가 추가됐는지, 기존 권한보다 넓은 파일 경로나 네트워크 접근을 요구하는지 비교해야 한다. 플러그인 설치 후 에이전트가 실제로 호출한 도구와 변경한 파일을 남기는 것도 필요하다.
도입 전에 작게 확인할 세 가지
- 읽기 전용 작업부터 고른다. 처음에는 저장소 구조 요약, 테스트 결과 정리, 배포 체크리스트 생성처럼 외부 상태를 바꾸지 않는 스킬로 시작한다. 자동 배포나 계정 변경은 플러그인 내용과 승인 흐름을 검증한 뒤에 붙인다.
- 공통부와 전용부를 분리한다. 여러 클라이언트에서 똑같이 써야 하는 절차는 스킬과
mcp.json에 둔다. 특정 도구에서만 필요한 명령과 훅은 해당 공급자 디렉터리에 둔다. 이렇게 해 두면 이식성의 범위와 종속성의 범위를 함께 볼 수 있다. - 설치와 갱신을 코드 리뷰처럼 본다. 플러그인 목록, 버전, 출처를 기록한다. MCP 설정의 URL과 명령을 허용 목록에 대조하고, 업데이트 전후 차이를 확인한다. 에이전트가 위험한 호출을 하기 전에는 사람이 멈출 수 있어야 한다.
규격의 가치는 결과가 아니라 관리 경계에 있다
Agent Plugins 1.0이 곧바로 에이전트의 품질을 높여 주는 것은 아니다. 잘못된 절차가 담긴 스킬도 더 편하게 배포될 수 있고, 클라이언트별 지원 범위 차이도 남아 있다. GitHub의 발표 역시 일부 모델은 ‘롤아웃 중’이라고 표현하며, 모든 기능이 같은 시점에 모든 환경에 나타난다고 약속하지 않는다.
다만 스킬과 도구 연결을 흩어진 프롬프트가 아니라 검토 가능한 패키지로 다룰 수 있다는 점은 실무적이다. AI를 팀의 일 흐름에 넣을수록 중요한 것은 에이전트가 무엇을 잘 답하는가만이 아니다. 어떤 절차와 어떤 연결을 가지고, 어느 환경에서, 누가 검토한 상태로 작동하는지를 다시 확인할 수 있어야 한다. 이번 규격은 그 관리 경계를 조금 더 명확하게 만드는 변화로 볼 수 있다.