당신의 AI 에이전트는 멍청하지 않습니다. 에이전트가 호출하는 SaaS가 적대적일 뿐입니다.

우리는 11,000개 이상의 MCP 서버와 SaaS API를 카탈로그화한 데이터베이스를 운영하며, 실제 JSON-RPC 핸드셰이크(handshake), 실제 활성 상태 확인(liveness checks), 실제 robots.txt 읽기 등을 통해 이들을 조사합니다. 카탈로그화된 엔드포인트(endpoint) 10개 중 1개는 단순히 작동하지 않았습니다. 활성화된 MCP 엔드포인트 5개 중 1개는 기본적인 핸드셰이크에 실패했습니다. 이는 에이전트가 문서를 읽기도 전의 상황입니다.

데이터가 말해주는 에이전트가 실패하는 이유는 다음과 같습니다. 그리고 이는 대부분 에이전트의 잘못이 아닙니다.

요약 (TL;DR)

• 카탈로그화된 11,151개의 MCP/API 엔드포인트 중 1,154개가 작동하지 않음 (활성 상태 조사 후 제거됨)
• 4,367개의 활성 JSON-RPC initialize 조사 중 892개가 핸드셰이크 실패 (20.4%)
• 31개의 주요 일본 SaaS 제품을 심층 조사한 결과: 단 10개만이 공식 MCP 서버를 제공하며, 5개는 공개적으로 접근 가능한 개발자 문서가 전혀 없음 — 사람은 영업팀에 이메일을 보내 PDF를 받을 수 있지만, 에이전트는 불가능함
• 한 벤더는 API 문서 사이트가 robots.txt를 통해 모든 봇을 차단하고 있음에도 불구하고 공식 MCP 서버를 제공함. 정문은 열려 있지만, 안내 데스크는 잠겨 있는 격임
• 인증(Auth)은 방언 동물원과 같음: 커스텀 토큰 헤더, 비표준 Authorization: Token 스킴, 클라이언트 ID-to-Bearer 교환 등 — 각각의 방식은 시행착오를 거치며 토큰을 소모함

1. 엔드포인트 10개 중 1개는 그냥... 죽어 있습니다

레지스트리(Registries)와 어썸 리스트(awesome-lists)는 계속 늘어나지만, 아무도 이를 정리하지 않습니다. 우리가 11,151개의 MCP/API 엔드포인트 전체 카탈로그를 활성 상태 확인으로 조사했을 때, 1,154개(10.4%)는 작동하지 않았습니다 — 서버가 사라졌거나, 저장소(repos)가 방치되었거나, URL이 404 오류를 반환했습니다.

인간 개발자에게 이것은 약간의 짜증스러운 일입니다. 에이전트에게는 더 심각한 문제입니다. 에이전트는 레지스트리에서 도구를 확신을 가지고 선택하고, 연결을 시도하고, 실패하고, 재시도하며, 그 과정에서 당신의 토큰을 낭비합니다. 죽은 엔드포인트는 카탈로그상에서는 죽은 것처럼 보이지 않습니다.

2. 활성 MCP 엔드포인트 5개 중 1개가 핸드셰이크에 실패합니다

우리는 호스팅된 MCP 엔드포인트에 실제 JSON-RPC initialize 요청을 보냅니다. 이는 가장 기본적인 "안녕, 너 MCP 서버니?"라고 묻는 확인 절차입니다.

4,367건의 조사 시도 중: 3,475건 성공, 892건 실패 (20.4%). 이 서버들은 작동하지 않는 서버가 아닙니다 — HTTP를 통해 응답합니다. 다만 프로토콜 핸드셰이크 (protocol handshake)를 완료하지 못할 뿐입니다: 잘못된 컨텐츠 타입 (content types), 탐색 가능한 흐름이 없는 인증 장벽 (auth walls), 혹은 절반만 구현된 스펙 버전 (spec versions) 때문입니다.

"살아있는" 에이전트 진입로의 5분의 1이 제대로 인사조차 할 수 없다면, 당신의 에이전트 재시도 루프 (retry loop)는 버그가 아닙니다. 그것은 환경의 문제입니다.

3. 문서가 인간 전용으로 잠겨 있음

이 부분은 우리를 가장 놀라게 했습니다. 우리는 31개의 주요 일본 SaaS 제품(회계, HR, 전자 서명, 결제, CRM — 실제 비즈니스를 운영하는 소프트웨어)을 조사했으며, 모든 사실을 벤더의 1차 자료와 대조하여 검증했습니다.

31개 중 5개는 공개적으로 접근 가능한 개발자 레퍼런스 (developer reference)가 전혀 없었습니다. API는 존재하지만, 스펙 (spec)은 영업 담당자 문의, 파트너 프로그램, 또는 유료 계약 뒤에 숨겨져 있습니다. 인간 개발자는 영업팀에 이메일을 보내 PDF를 받습니다. 에이전트는 마케팅 페이지에 접속했다가 포기합니다.

그리고 가장 극단적인 사례: 한 주요 벤더는 공식 MCP 서버를 배포하면서도, 정작 API 문서 사이트는 모든 봇에 대해 403 에러를 반환하고 robots.txt에서 모든 크롤러를 차단하고 있습니다. 에이전트는 초대받았지만, 매뉴얼에서는 차단당한 셈입니다. (상세 분석은 다음 보고서에서 이어집니다.)

만약 당신의 문서에 에이전트가 접근할 수 없다면, 에이전트 입장에서 당신의 제품은 존재하지 않는 것과 같습니다.

4. 공식적인 에이전트 진입로는 여전히 드묾

이 31개의 주요 SaaS 제품 중:

• 10개는 공식 MCP 서버를 배포함 (회계 분야 선두주자인 freee와 Money Forward는 모두 우리 인덱스에서 AAA 등급을 받았습니다)
• 10개는 제품 또는 개발자 도메인에서 llms.txt를 제공함
• 나머지는 단순히 "API를 제공함" — 이는 에이전트 관점에서 다음과 같은 의미입니다: 인증 (auth), 페이지네이션 (pagination), 그리고 에러 시맨틱 (error semantics)을 실패한 호출을 거듭하며 스스로 알아내야 한다는 뜻입니다.

우리는 평가 가능한 26개 제품 모두에 대해 AAA–D 등급을 매겼으며, 전체 표와 점수 산정 공식, 그리고 각 등급 뒤에 숨겨진 사실들을 공개했습니다. 여기서 확인하세요: Agent Readiness Index 2026 Summer.

5. 인증 (Auth)은 방언의 동물원과 같음

이 31개의 제품만 조사했을 때 발견한 결과는 다음과 같습니다:

• OAuth 2.0 (좋음!)
• 커스텀 헤더(custom headers) 내의 API 키
• 클라이언트 자격 증명 교환(client-credentials exchange)을 통해 얻는 독자적인 Kaonavi-Token 헤더
• Basic-auth 토큰 발급 후 Bearer가 아닌 Authorization: Token {token} 형식을 사용
• 1시간 만료 시간이 있는 client-ID→access-token 교환 방식
• 서로 다른 헤더에 API 키와 API 토큰이 동시에 요구됨

이 중 어느 것도 개별적으로 틀린 것은 아닙니다. 하지만 표준이 아닌 모든 방언(dialect)은 에이전트가 조용히 실패하고, 재시도하며, 토큰을 낭비하게 만드는 또 다른 방식이 됩니다. 표준화는 하나의 기능(feature)이며, 모든 편차는 연결되는 모든 에이전트에게 부과되는 세금입니다.

측정 방법 (및 공개하지 않는 사항)

• 라이브니스(Liveness) + 핸드셰이크(handshake) 데이터: 2026년부터 지속적으로 수행한 자체 자동화 프로브(호스팅된 MCP 엔드포인트에 대한 JSON-RPC initialize) 결과입니다. 위 수치는 2026-07 기준입니다.
• 31개 제품 심층 조사: 모든 사실(공식 MCP, 공개 문서, 인증 방식)은 2026-07-13에 벤더의 1차 자료(개발자 문서, 보도 자료, 공식 도움말)를 통해 검증되었습니다. 수정 사항은 언제든 환영하며, 저희는 수정 로그를 공개합니다.
• 공개하지 않는 사항: 벤더별 성공률 수치는 공개하지 않습니다. 저희의 제3자 텔레메트리(telemetry)는 해당 수치를 공정하게 나타낼 만큼의 규모에 아직 도달하지 않았으므로, 규모가 확보될 때까지는 비공개로 유지합니다. 방법론 및 독립성 정책은 공개되어 있습니다: kansei-link.com/independence.

이 데이터셋은 저희의 MCP 서버가 에이전트에게 제공하는 내용(11,000개 이상의 서비스에 대한 연결 가이드, 인증 함정, 실패 해결 방법)입니다: npx @kansei-link/mcp-server — 무료이며, 모든 실패 보고는 데이터를 더 개선하게 만듭니다.

여러분의 차례

여러분의 에이전트가 상대해 본 최악의 API는 무엇인가요? 응답 없는 엔드포인트, 문서화되지 않은 인증 방언, 영업 상담 후에야 볼 수 있는 문서 등 — 여러분의 전쟁 이야기를 들려주세요. 다음 보고서를 위해 실패 패턴을 수집하고 있습니다.

AI의 도움을 받아 작성되었습니다; 모든 측정, 검증 및 분석은 저희의 자체 수행 결과입니다. 데이터: KanseiLink, 2026-07 측정.