에이전트 표준은 모델 이름이 아니라 Skill·MCP·런타임으로 갈린다

AI 에이전트를 새로 붙일 때 지금 가장 실용적인 질문은 “어느 모델이 제일 똑똑한가”가 아니다. 반복 가능한 작업 절차는 Skill로, 외부 시스템 연결은 Model Context Protocol(MCP) 같은 도구 경계로, 오래 도는 실행과 상태는 별도 런타임으로 분리할 수 있는가가 더 중요하다. 기준 시점은 2026년 10월 4일이며, 이 글은 Anthropic Claude Platform release notes, Google Gemini Managed Agents, GitHub Copilot Agent Skills, Cloudflare Agents와 Kitesurf 문서를 대조해 작은 팀이 바로 쓸 도입 기준으로 정리한다.

오늘의 독자 질문: 우리 팀은 무엇을 표준화해야 하나

코드 리뷰를 자동화한다고 가정해보자. 검토 순서와 통과 조건을 정하는 일, 저장소와 이슈에 접근할 권한을 정하는 일, 중간에 끊긴 작업을 재개하는 일은 서로 다른 결정이다. 제품을 먼저 고르기보다 이 세 책임을 나눠보면 팀 내부에 남겨야 할 기준이 선명해진다.

Anthropic release notes는 2026년 8월 Agent Skills와 Skills API가 베타를 벗어났고, Skills를 container parameter로 로드하는 요청이 별도 beta header 없이 동작한다고 밝힌다. Anthropic · Release notes GitHub도 Copilot의 agent skills를 “instructions, scripts, resources를 담은 폴더”로 설명하고, .github/skills, .claude/skills, .agents/skills, 사용자 홈의 skill 경로를 지원한다고 문서화했다. GitHub Docs · Agent skills

이 흐름을 한 문장으로 줄이면 이렇다. 벤더별 제품명은 바뀌어도, 반복 작업을 파일·폴더 단위로 패키징하는 방향은 강해지고 있다. 그래서 작은 팀이 먼저 표준화할 것은 “우리의 반복 업무를 어떤 모델에게 물을까”가 아니라 “그 업무를 어떤 Skill 폴더와 검증 자료로 재사용할까”다.

책임을 나누면 도입 질문이 달라진다

아래 표는 제품 기능을 보증하는 비교표가 아니라, 팀이 설계할 책임을 나누는 점검표다. 하나의 제품이 여러 역할을 맡더라도 각 항목의 통과 조건은 따로 적어두는 편이 좋다.

책임	먼저 물을 질문	팀이 남길 자료
작업 절차	어떤 입력으로 무엇을 확인해야 끝나는가?	절차 파일, 예시 입력, 통과·실패 조건
외부 연결과 권한	어떤 도구를 읽기만 하고, 어떤 변경은 승인받는가?	도구 목록, 권한 범위, 승인 규칙
실행 상태와 회복	어디까지 실행했고, 실패한 뒤 어디서 다시 시작하는가?	실행 기록, 결과 파일, 재시도 한도

예를 들어 리뷰 결과가 틀렸다면 절차와 근거를 먼저 살피고, 원치 않는 변경이 일어났다면 도구 권한을 살피며, 같은 작업이 반복됐다면 실행 상태와 재개 지점을 살피는 식이다. 어느 한 층을 추가했다고 다른 층의 검증이 없어지는 것은 아니다.

1. Skill은 프롬프트가 아니라 재사용 가능한 절차다

Skill을 긴 프롬프트 파일로만 보면 금방 실패한다. 좋은 Skill은 “이 일을 할 때 어떤 자료를 읽고, 어떤 스크립트를 돌리고, 어떤 결과를 통과로 볼지”를 묶는다. GitHub 문서는 Copilot agent skills가 specialized tasks를 수행하게 하는 instructions, scripts, resources 폴더라고 설명한다. GitHub Docs · Skills folder

여기서 실무 기준은 세 가지다.

기준	나쁜 형태	좋은 형태
입력	“잘 검토해줘”	PR 번호, changed files, 위험 영역
절차	긴 성격 지시	읽을 문서, 실행할 명령, 실패 처리
산출	감상문	verdict, evidence, 재현 명령, 다음 조치

Anthropic의 Skills API GA는 이 흐름이 특정 IDE 팁이 아니라 플랫폼 기능으로 올라왔다는 신호다. Anthropic · Skills API GA 다만 한계도 있다. Skill이 표준화된다고 해서 결과가 자동으로 맞아지는 것은 아니다. 낡은 Skill은 낡은 절차를 더 빠르게 반복한다. 그래서 Skill에는 “언제 쓰는가”뿐 아니라 “무엇을 확인해야 통과인가”가 같이 들어가야 한다.

2. MCP는 “다 붙이는 표준”이 아니라 권한 경계다

GitHub Changelog는 Copilot code review에서 Agent skills와 MCP servers가 GA가 됐고, MCP tool calls는 read-only로 제한된다고 설명한다. GitHub Changelog · Skills/MCP GA 이 문장에서 중요한 부분은 “MCP를 붙인다”보다 “code review에서는 read-only로 제한한다”다.

MCP는 AI 앱과 도구를 연결하는 유용한 경계지만, 모든 도구를 같은 위험도로 열어도 된다는 뜻은 아니다. 이슈 트래커 읽기, 문서 검색, 서비스 카탈로그 조회는 리뷰 품질을 올린다. 반면 토큰 발급, 웹훅 수정, 결제, 배포는 별도 승인 없이 리뷰 에이전트에게 열면 안 된다.

작은 팀은 MCP 서버를 붙이기 전에 아래 네 칸으로 나누면 된다.

1. 읽기 전용: 문서, 이슈, 로그 조회. 기본 허용 후보.
2. 제한적 쓰기: 코멘트 작성, 임시 파일 생성. 작업별 승인 필요.
3. 고위험 쓰기: 배포, 권한 변경, 토큰 생성, 결제. 사람 확인 없이는 차단.
4. 불가: 원본 삭제, 고객 데이터 대량 추출, 외부 공개 공유. 별도 제품 설계 필요.

이 구분은 이전 zero-trust 글의 tool governance와 이어진다. 차이는 오늘의 초점이 보안 제품명이 아니라 연결 표준을 도입할 때 권한 표준도 같이 만들어야 한다는 점이다.

3. 런타임은 오래 도는 작업의 기억과 회복을 맡는다

Google Managed Agents는 Gemini API에서 Antigravity agent를 secure cloud sandbox로 띄우고, isolated Linux environment에서 reason, plan, tools, code execution, web browsing을 수행한다고 설명한다. 이어 AGENTS.md와 SKILL.md 같은 파일로 custom agent를 정의할 수 있다고 소개한다. Google · Managed Agents

Cloudflare Agents 문서는 각 agent session이 durable identity, local SQL storage, real-time connections, scheduled work, recoverable execution을 가진다고 설명한다. Cloudflare Docs · Agents

여기서 런타임의 역할이 보인다. Skill은 “어떻게 할지”를 담고, MCP는 “무엇을 읽거나 실행할지”를 연결한다. 런타임은 “작업이 길어지고 끊기고 재시도될 때 상태를 어디에 남길지”를 담당한다.

예를 들어 블로그 자동화라면 주제 후보 수집은 짧은 작업이다. 그러나 원고 작성, 이미지 생성, 역할 검토, 빌드, 배포, live read-back까지 이어지면 중간 실패가 당연히 생긴다. 이때 상태가 프롬프트 안에만 있으면 재개가 어렵다. 런타임이나 외부 상태 저장소가 “현재 라운드, 원고 해시, 이미지 해시, 검토 receipt, 배포 결과”를 보관해야 한다.

4. 브라우저 자동화는 사람 브라우저와 agent 브라우저를 나눈다

Cloudflare Kitesurf 문서는 이 차이를 노골적으로 말한다. Kitesurf는 Workers 위에서 도는 stateless browser이며, AI agent에 필요한 token count, context windows, scalability, performance, cost에 초점을 맞추고 탭·테마·확장·pixel-perfect rendering 같은 사람용 기능을 포기한다고 설명한다. Cloudflare Docs · Kitesurf

숫자도 함께 제시한다. 문서 기준 Kitesurf는 14개 URL corpus의 median quick action에서 Chromium보다 screenshot CPU는 3.1배, HTML extraction CPU는 3.8배 적게 쓰고, 메모리도 screenshot 4.7배, HTML extraction 7.0배 적게 쓴다고 한다. 대신 wall time은 Chromium보다 1.7~1.8배 느리다. Cloudflare Docs · Kitesurf 비교

이 숫자는 “Kitesurf가 항상 더 좋다”가 아니다. 문서도 WebGL, 비디오, bot-challenge TLS handshake, long-running authenticated session에는 아직 맞지 않고 Chromium을 쓰라고 적는다. 따라서 기준은 명확하다. HTML 추출, 스크린샷, 일회성 렌더처럼 agent가 많이 반복하는 작업은 agent browser 후보가 되고, 로그인 세션·정밀 시각 검수·복잡한 인터랙션은 실제 Chromium/브라우저가 필요하다.

적용 예시: 작은 팀의 에이전트 표준 7개

오늘 바로 적용한다면 복잡한 플랫폼부터 사지 말고 아래 7개를 문서화하는 편이 낫다.

1. 반복 업무마다 SKILL.md 또는 동등한 절차 파일을 만든다.
2. Skill에는 목적, 입력, 금지 사항, 실행 명령, 통과 조건을 넣는다.
3. 외부 도구는 MCP든 내부 API든 읽기·쓰기·고위험 쓰기로 분류한다.
4. 고위험 쓰기는 사람 승인과 read-back 없이는 완료로 보지 않는다.
5. 오래 도는 작업은 런타임 상태와 artifact 해시를 남긴다.
6. 브라우저 작업은 agent browser와 사람 검수 브라우저를 나눈다.
7. 벤더 기능을 쓰더라도 내부 표준은 Skill·도구권한·런타임 상태로 남긴다.

이렇게 구분해두면 벤더를 바꿀 때 무엇을 다시 검증할지 정리하기 쉽다. 절차 파일이 있다고 그대로 이식되는 것은 아니므로 실행 명령, 인증 방식, 지원 도구와 상태 저장 방식을 새 환경에서 확인해야 한다. 제품별 연결 부분과 팀의 통과 조건을 분리해두는 것이 목표다.

실패 조건: 언제 이 구조가 과한가

모든 자동화에 Skill·MCP·런타임을 다 붙일 필요는 없다. 하루 한 번 개인 메모를 정리하거나, 실패해도 다시 실행하면 되는 단순 요약이라면 긴 구조가 오히려 비용이다. 이 경우에는 짧은 프롬프트와 로컬 스크립트, 최종 사람이 읽는 검토만으로 충분하다.

반대로 다음 조건 중 둘 이상이면 구조를 나눠야 한다.

• 같은 업무를 매주 반복한다.
• 외부 상태를 바꾸는 도구가 있다.
• 작업이 10분 이상 걸리거나 중간 실패가 흔하다.
• 다른 사람이 결과를 검토해야 한다.
• 비용, 권한, 고객 데이터, 공개 배포가 걸려 있다.

결론: 제품명이 아니라 경계를 남겨라

이 글에서 비교한 Skill 폴더, 도구 연결, 상태를 가진 런타임은 서로 대체하는 한 가지 기능이 아니다. 팀이 반복하는 업무에서 절차·권한·회복 중 무엇이 부족한지 먼저 짚어야 제품 선택도 구체적이 된다.

작은 팀의 실용적 답은 단순하다. 업무 절차는 Skill로 남기고, 외부 연결은 권한 있는 도구 경계로 제한하고, 오래 도는 실행은 상태를 가진 런타임에 맡긴다. 그런 다음 모든 완료 주장은 실제 read-back과 검토 증거로 닫는다. 이 기준이 있으면 다음 벤더 발표가 나와도 “새 장난감”이 아니라 “우리 구조의 어느 층을 바꾸는가”로 판단할 수 있다.

자주 묻는 질문

Agent Skills와 프롬프트 템플릿은 무엇이 다른가?

프롬프트 템플릿은 주로 모델에게 말하는 문장이다. Agent Skills는 보통 instructions, scripts, resources를 함께 담아 반복 작업을 수행하게 하는 폴더형 절차다. 좋은 Skill은 실행 명령과 통과 조건까지 포함한다.

MCP를 붙이면 벤더 종속이 줄어드나?

일부는 줄어든다. 도구 연결을 모델별 플러그인 대신 표준 인터페이스로 둘 수 있기 때문이다. 하지만 권한, 인증, 로그, 쓰기 승인 정책은 여전히 팀이 설계해야 한다. MCP 자체가 안전을 보장하지는 않는다.

작은 팀도 durable agent runtime이 필요한가?

모든 작업에는 필요 없다. 하지만 작업이 오래 걸리고, 중간 실패 후 재개해야 하며, 외부 상태를 바꾸고, 검토 receipt를 남겨야 한다면 런타임 또는 그에 준하는 상태 저장소가 필요하다.

브라우저 자동화는 Kitesurf 같은 agent browser로 충분한가?

HTML 추출, 간단한 스크린샷, 일회성 렌더에는 적합할 수 있다. 하지만 로그인 세션, bot challenge, WebGL, 정밀한 시각 검수, 긴 인증 상태가 필요하면 Chromium 같은 실제 브라우저가 필요하다. 도구 선택은 비용보다 실패 조건으로 정해야 한다.

참고한 1차 자료

• Anthropic · Claude Platform release notes
• Google · Managed Agents in Gemini API
• GitHub · Copilot code review Skills/MCP GA
• GitHub Docs · About agent skills
• Cloudflare Docs · Agents
• Cloudflare Docs · Kitesurf