에이전트 AI - MCP, 도구 연결에서 에이전트 조합 시대로

https://oreillyradar.substack.com/p/mcp-is-not-just-another-api-standard

2026.9.24
[MCP Is Not Just Another API Standard]

이 글은 단순한 API 규격을 넘어 모델 컨텍스트 프로토콜(MCP)이 인공지능 에이전트 시스템에 가져온 패러다임의 전환을 심도 있게 분석합니다. 저자는 MCP가 도구, 리소스, 프롬프트라는 표준화된 프리미티브를 통해 파편화된 통합 방식을 혁신했지만, 동시에 실행 시점에 에이전트가 도구를 자율적으로 조합하는 동적 구성의 불확실성이라는 새로운 과제를 던졌다고 설명합니다. 특히 모델이 코드를 올바르게 선택하도록 만드는 자연어 설명의 중요성과 보안 취약점에 대응하는 거버넌스의 필요성을 강조하며, 이 기술이 실질적인 운영 경험을 통해 성숙해가는 과정을 다룹니다. 결국 MCP는 인간이 사전에 설계한 정적 연결에서 벗어나 인공지능이 런타임에 통합 업무를 수행하도록 만드는 에이전틱 시스템의 핵심 기반임을 천명하고 있습니다.

 

 

이 글의 주장은 MCP의 변화가 API 호출 형식을 통일하는 데 그치지 않고, 어떤 도구를 어떤 순서로 조합할지 결정하는 주체를 사전 작성된 통합 코드에서 실행 중인 에이전트로 옮긴다는 것입니다. 기업 시스템 관점에서 유용한 설명입니다. 다만 이는 MCP만의 고유 기능이라기보다, 표준화된 도구 인터페이스와 에이전트의 동적 계획이 결합될 때 나타나는 변화로 읽는 편이 정확합니다.[1][4]

 

글에서 실무적으로 중요한 세 가지

1. 도구 설명이 사실상 선택 인터페이스가 된다. JSON Schema는 입력 형식을 알려주지만, 비슷한 도구 중 무엇을 언제 써야 하는지는 이름과 설명이 좌우합니다. 따라서 설명에는 업무 대상, 식별자 형식, 결과의 의미, 혼동하기 쉬운 도구와의 차이를 명시해야 한다는 지적이 설득력 있습니다.[1]

1. 도구별 정상 동작만으로 전체 업무의 안전성을 보장할 수 없다. 에이전트는 서로 독립적으로 만든 도구를 예상 밖의 순서와 데이터로 연결할 수 있습니다. 검증 단위도 개별 API에서 도구 간 호출 경로와 최종 업무 결과로 넓어져야 합니다.[1]

1. 통제는 서버 등록 이후가 아니라 권한 부여 이전에 필요하다. 글이 권하는 도구 허용목록, 인증, 호출 감사, 비밀정보 관리는 타당합니다. 여기에 업무별 권한 범위, 쓰기 작업 승인, 호출 한도, 실패 시 중단 조건을 함께 설계하는 것이 좋습니다.[1][4]

 

공식 규격과 대조하면 보완할 점

• 글은 Tools·Resources·Prompts에 Sampling·Elicitation·Roots를 더해 공통 원시 기능처럼 소개하지만, 2026-07-28 규격에서는 Roots와 Sampling이 폐기 예정(deprecated)입니다. 새 구현의 설계 기준을 이 다섯 가지로 고정해서는 안 됩니다.[1][2]
• Tasks는 코어 기능이 아닌 공식 확장으로 이동했습니다. MCP Apps 역시 확장입니다. 장기 작업이나 UI가 필요한 시스템이라면 ‘MCP 지원’ 여부만이 아니라 해당 확장의 클라이언트·서버 지원 여부를 확인해야 합니다.[2][3]
• “에이전트의 결정을 단위 테스트할 수 없다”는 표현은 지나치게 단정적입니다. 미래의 모든 조합을 사전에 열거할 수 없다는 뜻으로는 맞지만, 대표 업무 시나리오 평가, 위험한 도구 연쇄에 대한 적대적 테스트, 실행 정책 검증은 가능합니다. 이는 글의 문제 제기를 실무 검증 체계로 옮긴 해석입니다.[1]
• 글에 나온 취약 서버의 비율·규모 주장은 원문에 개별 조사 출처가 제시되지 않아 이 분석에서 수치로 재인용하지 않았습니다. 반면 stateless 코어, 세션 헤더 제거, 인증 강화, 구형 HTTP+SSE 폐기 예정, SDK 다운로드 규모는 공식 변경 이력과 발표에서 확인됩니다.[1][2][3]

공공·기업 AI 플랫폼에 적용한다면, MCP 서버의 개수보다 도구 설명 품질 → 에이전트별 허용 권한 → 호출 연쇄 평가 → 승인·감사 증적을 하나의 관리 대상으로 묶는 것이 핵심입니다. 특히 조회 도구의 결과가 수정·전송 도구의 입력으로 이어지는 경로를 별도 위험 시나리오로 관리해야 합니다. MCP는 연결 계약을 제공하지만, 그 경로의 업무 적정성까지 보증하지는 않습니다.[1][4]

 

Sources

[1] https://oreillyradar.substack.com/p/mcp-is-not-just-another-api-standard — 원문

[2] https://modelcontextprotocol.io/specification/2026-07-28/changelog — 공식 변경 이력

[3] https://blog.modelcontextprotocol.io/posts/2026-07-28 — 공식 발표

[4] https://modelcontextprotocol.io/specification/2026-07-28 — 공식 규격