비교 분석

Microsoft가 Skill을 MCP에 올린 뒤 발견이 여전히 JSON인 이유: SEP-2640, skill://index.json과 skills/list

2026년 9월 22일 기준: Microsoft의 9월 16일 데모는 전문가 루프를 부모가 MCP로 로드하는 Skill로 옮긴다. 절차는 Markdown이어도 된다. 발견면은 JSON. SEP-2640은 Accepted이지 Final이 아니다. skill://index.json과 skills/list가 공존한다.

결론부터: Skill이 MCP 위에 올라간 뒤에도, 설명서는 Markdown일 수 있다. 발견 계약은 여전히 JSON이다.2026년 9월 16일, Microsoft Agent Framework의 Tommaso Stocchi가 대조를 올렸다: 스키장 상담이 「전문가마다 모델을 하나씩 돌린다」에서 「부모 Agent가 Skill을 필요할 때 로드하고, MCP 도구를 직접 친다」로 바뀌었다. 서비스는 여전히 분산이다. 추론은 부모 컨텍스트로 거둬들인다. 본 사이트 9월 11일 《MCP / Skills / Tools / Subagents》는 네 계층 분담을 다뤘다. 이 글은 11일 이후만 보탠다: 발견 문서가 어떤 모양인지, SEP-2640이 어디에 걸려 있는지, 그리고 왜 여전히 JSON을 먼저 검증해야 하는지.

이 글은 2026년 9월 22일 기준. SEP-2640(Skills Extension)은 9월 3일에 Accepted로 적혔다. Final이 아니다. Microsoft 데모가 박은 것은 역사 Draft의 skill://index.json이다. 새 초안은 skills/list / skills/get으로 바꿨다. 두 발견 모양이 동시에 돈다. 「Skill이 Agent를 대체했다」보다 호환성이 먼저다.

9월 16일에 실제로 나온 것

Stocchi의 원문 제목은 From Specialist Agents to Distributed Skills over MCP. 스키장 상담은 원래 A2A로 전문가 넷을 불렀다: 날씨, 안전, 스키 코치, 리프트 대기. 전문가마다 지시, 도구, 모델 루프를 가졌다. 둘째 경로는 같은 도메인 서비스를 MCP Provider로 바꾼다: 각각 설명, SKILL.md, 타입이 있는 MCP 도구를 낸다. 상담은 MAF의 SkillsProvider와 MCPSkillsSource로 발견과 로드를 한다. SkillToolsMiddleware는 load_skill이 성공한 뒤, 그 Provider의 도구를 다음 모델 턴에 건다.

웹 리서치는 평범한 Agent 도구로 남는다. 이건 의도된 혼합이다: 자율이 필요한 곳은 자율로 두고, 능력이 되면 Skill로 바꾼다. MCP 엔드포인트 넷은 /skillsmcp에 있다. 리소스 면은 보통 이것뿐이다:

skill://index.json
skill://<skill-name>/SKILL.md

skill://가 가리키는 것은이미 연결된 MCP 연결 안의 리소스다. 호스트명이 아니고, Skill 본문이 새 네트워크를 열 수도 없다. 인증, 전송, 권한은 인프라와 코드에 남는다. Markdown에 있지 않다.

MCP가 A2A를 대체하는 것이 아니다

원문은 경계를 깨끗이 썼다. A2A는 작업을 다른 추론 루프에 넘긴다. Distributed Skill은 능력과 조작을 현재 추론 루프에 넘긴다. 표 한 장이면 된다:

관심사Agent를 도구로 (A2A)Distributed Skill
부모가 발견하는 것호출할 수 있는 전문가 Agent로드할 수 있는 능력
전문가 지시가 도는 곳전문가 자신의 모델 컨텍스트부모 Agent의 모델 컨텍스트
누가 도메인 조작을 고르나전문가 모델부모 모델
원격에서 실행되는 것전문가 루프 + 그 도구MCP 도구 + 뒤의 서비스
여전히 분산인 것Agent, 서비스, 데이터Skill Provider, 서비스, 데이터

Agent Card의 이름과 설명은 발견 항목이 된다. 시스템 프롬프트는 SKILL.md가 된다. 도구 파라미터는 MCP의 input / output Schema가 된다. 비즈니스 서비스는 도구 핸들러 뒤에 남는다. Card의 엔드포인트, 인증, 전송 능력은 Skill 설명에 쓰지 마라. 이건 본 사이트 11일 글과 같다: Skills는 설명서, MCP는 소켓, Tools는 계약. 바뀐 것은 설명서가 어떻게 발견되느냐이지, 세 계층이 하나로 뭉개진 것이 아니다.

발견 계약: skill://index.json

오케스트레이터는 매 요청마다 설명서 전부를 먹을 필요가 없다. 라우팅에 쓸 만큼의 목록이 필요하다. 데모의 날씨 Provider 인덱스는:

{
  "$schema": "https://schemas.agentskills.io/discovery/0.2.0/schema.json",
  "skills": [
    {
      "name": "weather",
      "type": "skill-md",
      "description": "Weather intelligence agent providing real-time conditions, forecasts, and storm alerts for the ski resort",
      "url": "skill://weather/SKILL.md"
    }
  ]
}

이건 Agent Skills 발견 인덱스에 MCP 의미를 더한 것이다: url은 리소스 URI이지, https 호스트가 아니다. $schema는 schemas.agentskills.io의 discovery 0.2.0을 가리킨다. 설명은 「이 능력을 언제 쓰나」에 답한다. SKILL.md는 「어떻게」에 답한다 — weather_forecast 같은 조작을 집고, 구간, 단위, 관측을 지어내지 말 것. 조작 자체의 타입과 범위는 여전히 MCP tools/list가 주는 JSON Schema가 정한다.

부모 Agent는 시작 때 MCP로 목록과 tools/list를 당긴다. 모델이 처음 보는 것은 Skill 요약과 로드 헬퍼뿐, 조작 Schema 전부가 아니다. load_skill("weather") 뒤에야 미들웨어가 그 그룹 도구를 건다. 도구가 컨텍스트에 나타났다고 실행된 것은 아니다.

SEP-2640: Accepted, Final이 아니다

SEP-2640은 Extensions Track의 Skills 바인딩이다: MCP Resources로 Agent Skills를 제공한다. 확장 식별은 io.modelcontextprotocol/skills. 디렉터리 구조, YAML frontmatter, 점진적 공개는 여전히 Agent Skills 규격의 몫이다. SEP는 전송만 정한다.

Stocchi 글의 9월 10일 확인 기준: 9월 3일 개정이 상태를 Accepted로 적고, 발견 면을 skills/list와 skills/get으로 바꿨다(페이지 가능, 항목에 uri, 파싱된 frontmatter, sha256: digest가 붙은 리소스 목록). 대응 PR은 그때 아직 머지되지 않았다. 데모가 박은 것은 더 이른 Draft다: skill://index.json을 읽고, 새 메서드 둘은 구현하지 않는다. 인큐베이션 저장소는 여전히 Experimental이다.

그러니 이차 보도의 「9월 13일 Final」을 생산 체크리스트에 쓰지 마라. 2026년 9월 22일에 확정할 수 있는 것은: Accepted, Final 아님, 두 발견 모양이 공존. Draft 인덱스를 「핵심 MCP 필수」로 보는 것은, 원문 자신의 각주와 반대다.

도구 계약은 여전히 JSON Schema

날씨 예측은 데모에서 Range(1, 24)가 붙은 hours이고, UseStructuredContent를 켰다. SDK가 도구 정의를 내고, 핸들러가 먼저 범위를 검증한 뒤 도메인 서비스에 넘긴다. SKILL.md는 어떤 도구를 고를지 안내한다. 파라미터 Schema를 대체하지 않고, 서버 측 검증도 대체하지 않는다.

권위 있는 조작 정의는 tools/list에서 온다. 실행은 tools/call. 설명서는 resources/read. 세 홉 모두 JSON-RPC다. Skill은 「페이지네이션하라」고 말할 수 있다. cursor를 대신 유지해 주지는 않는다. 「승인이 필요하다」고 말할 수 있다. 권한을 대신 강제하지는 않는다. 이건 《Tool Calling은 왜 JSON Schema에 의존하는가》와 같은 층이다: 산문이 길을 고르고, 계약이 불법 파라미터를 막는다.

세 쌍의 측정: 더 빠르다, token이 더 싼 것은 아니다

같은 프롬프트(날씨와 대기 시간을 보고, 어디서 시작할까?), 같은 Aspire 앱, gpt41, 신선한 대화 세 쌍. A2A 경로는 6 / 6 / 7회 모델 호출(전문가는 병렬 가능). Skills 경로는 매번 3회: 먼저 load_skill, 그다음 MCP 조작을 직접 치고, 그다음 최종 답. 클라이언트 경과 시간 평균은 대략 6.35초 대 15.48초.

token은 줄지 않았다. 세 라운드 합계, Skills 쪽에서 관찰한 값은 약 13,533, A2A는 약 11,134, 대략 22% 더 많다. 모델 홉이 적다고 누적 컨텍스트가 작아지는 것은 아니다 — 설명서, 그룹 Schema, 결과가 세 호출에 쌓인다. A2A의 캐시 카운트는 불완전하다. 이건 청구서 비교가 아니고, 대조 실험도 아니다. 원문 스스로 썼다: 세 쌍의 예시일 뿐, 같은 정확성이나 완전성을 증명하지 않는다.

가져갈 구조 관찰은 한 문장이다: 빠진 것은 중첩 전문가 루프이지, JSON 왕복이 아니다. 발견 인덱스, 도구 Schema, 구조화 결과는 홉이 남는다. 「전문가마다 한 번씩 말한다」에서 「부모 컨텍스트 안의 계약 몇 장」으로 거둬들였을 뿐이다.

두 발견 모양, Host가 서로 놓친다

2026년 8–9월에 이미 균열이 보였다. Microsoft.Agents.AI.Mcp의 UseMcpSkills는 여전히 skill://index.json을 읽는다. skills/list만 구현한 Server에는 「index 리소스 없음」을 적는다. 새 초안대로 인덱스만 내고, 확장을 선언하지 않고 digest도 안 하는 Server는, 새 Host에게 다시 안 보인다. 어떤 Host는 이미 인덱스 기반 Server를 legacy로 표시한다.

착지할 때 「어느 쪽이 이길지」에 걸지 마라. 목록이 작으면 둘 다 제공하라: Draft 인덱스 한 장은 옛 클라이언트에, skills/list / skills/get은 확장을 선언한 Host에. 인덱스가 없거나 비어 있다고 Host가 「이 Server에 Skill이 없다」로 보면 안 된다 — 초안이 적었다, 큰 목록, 동적 생성 목록은 부분 열거를 허용한다.

로컬에서 여전히 검증할 JSON 세 장

  1. 발견 문서.skill://index.json 또는 skills/list의 항목: name, type, description, url / uri. $schema에 맞춰라. 여분 키, 빈 설명, url에 https 호스트를 넣는 것은 라우팅 오류다. 문구 문제가 아니다.
  2. 도구 Schema.tools/list에서 inputSchema를 꺼내라. required를 채우고, additionalProperties: false, enum과 범위를 조여라. Skill 본문이 집은 도구 이름은 목록의 이름과 같아야 한다.
  3. 구조화 결과.데모는 Structured Content를 켰다. 부모 모델에 되돌리는 output은 여전히 적법한 JSON이어야 하고, Schema로 한 번 더 검증하라. DB 행 전체나 스택을 되돌리지 마라. 《Agents API 이후 왜 JSON이 더 필요한가》를 보라.

로컬 JSON 도구로 발견 문서를 보라

MAF나 어떤 Host에 붙이기 전에, 브라우저에서 텍스트 세 장을 펼쳐라: 발견 인덱스, tools/list의 Schema 한 장, 샘플 tools/call의 arguments.

  • JSON 검증기 — 문법이 적법한가; Schema가 있으면 필드, 필수, 여분 키를 같이 검사하라.
  • JSON 포맷터 — 한 줄로 눌린 index를 펼쳐, url이 진짜 skill://인지 보라.
  • JSON Diff — Draft 인덱스 항목과 skills/list 항목을 비교해, 두 목록이 서로 다른 말을 하지 않게 하라.

데이터는 브라우저를 떠나지 않는다. 발견 계약이 안정되면, 그때 부모 Agent가 SKILL.md를 로드하게 하라. 설명서는 문구를 바꿔도 된다. 필드 이름과 URI는 주마다 따라 움직이면 안 된다.

FAQ

SEP-2640이 이미 Final인가?

아니다. 9월 3일 개정은 Accepted다. Microsoft 9월 10일 확인 때 PR이 아직 열려 있었다. 데모는 역사 Draft의 skill://index.json을 쓴다. 「이미 Final」로 옛 클라이언트를 자르지 마라.

Distributed Skill이 A2A를 대체하나?

한칼에 자르지 않는다. 독립 수명, 비공개 컨텍스트, 전용 모델이 필요하면 여전히 Agent여야 한다. 설명서와 조작만 필요하면 Skill로 옮겨라. 원문이 웹 리서치를 Agent 도구로 남긴 것이 그 뜻이다.

skill://는 해석해야 하는 주소인가?

아니다. 이미 구성된 MCP 연결 위의 리소스를 가리킨다. Skill 본문이 이걸로 다른 호스트에 붙을 수 없다.

SKILL.md가 있으면 JSON Schema는 안 써도 되나?

써야 한다. Markdown은 도구를 고르고 결과를 읽는 안내다. 파라미터 타입, 범위, required는 여전히 tools/list의 Schema와 당신 이차 검증의 몫이다.

skill://index.json만 구현하면 되나?

지금 일부 Microsoft 클라이언트에는 된다. 새 초안 Host에는 안 된다. 목록이 작으면 둘 다 제공하라. 한쪽만 하면 나머지 절반 Host에서 안 보인다.

Skills 경로가 더 싸나?

데모에서 경과 시간은 더 빨랐고, 관찰된 token은 대략 22% 더 많았다. 대조 실험이 아니다. 라우팅과 구조화 결과가 맞는지 먼저 보고, 그다음 청구서를 말해라.

요약

9월 16일 이 데모는 「Agent가 낡았다」고 선언하지 않았다. 선언한 것은: 중첩 추론이 필요 없는 능력은 설명서와 조작만 배포하고, 발견 면은 JSON이면 된다는 것이다.서비스 경계는 그대로다. 빠진 것은 전문가 모델 루프다. 당신이 아직 쥐고 있는 것은 발견 인덱스, 도구 Schema, 구조화 결과다.

SEP-2640은 여전히 Accepted다. Draft 인덱스와 skills/list는 당분간 같이 산다. 먼저 로컬 검증 도구에서 JSON 세 장을 평평하게 보고, 그다음 Host에 붙여라. 11일 그 계층은 폐기되지 않았다. 폐기된 것은 「Skill은 로컬 폴더일 뿐」이라는 기본값이다. 모델과 harness는 버전을 바꾼다. name, url, inputSchema는 같이 느슨해지면 안 된다.