From REST to MCP: An Empirical Study of API Wrapping and Automated Server Generation for LLM Agents
이 논문은 LLM 에이전트의 외부 도구 호출 표준인 MCP 서버가 REST API 에 어떻게 의존하고 있는지 대규모로 분석하고, OpenAPI 명세 기반의 자동 생성 및 수정 기법을 통해 MCP 서버 구축의 정확성과 효율성을 획기적으로 개선하는 'AutoMCP' 파이프라인을 제안합니다.
상상해 보세요. **LLM(예: 챗봇)**은 아주 똑똑하지만, 직접 요리를 할 수 없는 초고급 요리사입니다. 이 요리사는 외부의 재료를 사오거나, 식당을 예약하거나, 날씨를 확인하려면 메뉴판이 필요합니다.
이 메뉴판이 바로 MCP 서버입니다. 이 서버는 요리사가 사용할 수 있는 '도구 (Tools)' 목록을 제공합니다.
이 논문은 이 메뉴판이 어떻게 만들어지는지를 조사하고, 자동으로 메뉴판을 만들 수 있는지 연구했습니다.
🔍 연구의 핵심 내용 (4 가지 질문)
연구진은 116 개의 실제 MCP 서버를 분석하며 다음과 같은 4 가지 의문을 해결했습니다.
1. 이 메뉴판은 누구의 레시피를 그대로 가져왔나요? (REST API 의존성)
현실: 대부분의 MCP 서버는 이미 존재하는 **웹 서비스의 API(REST API)**를 그대로 가져다 썼습니다. 마치 유명 식당의 레시피를 그대로 복사해서 메뉴판에 올린 것과 같습니다.
통계: 조사된 서버의 **88.6%**가 외부 API 를 그대로 연결해서 썼습니다.
특징: 대부분의 서버는 복잡한 변형을 가하지 않고, "요청을 보내고 답을 받아온다"는 단순한 역할만 합니다. (약 92% 가 단순한 '통과' 역할만 함)
2. 메뉴판에는 모든 메뉴가 다 있나요? (노출과 생략)
현실: 외부 식당 (API) 에는 수백 가지 메뉴가 있지만, MCP 서버가 제공하는 메뉴판에는 약 19% 정도만 나옵니다.
왜 그럴까요?
필요한 것만 골라냅니다: "검색", "조회" 같은 안전한 메뉴는 많이 노출하지만, "삭제", "설정 변경" 같은 위험한 메뉴는 아예 숨깁니다.
비유: 식당 전체 메뉴가 1,000 개라도, 요리사가 쓸 수 있는 메뉴판에는 '오늘 추천 메뉴 20 개'만 올려놓는 것과 같습니다. 너무 많으면 요리사가 혼란을 겪기 때문입니다.
3. 이 메뉴판을 컴퓨터가 자동으로 만들 수 있나요? (자동 생성)
시도: 연구진은 "API 문서 (OpenAPI) 만 있으면 컴퓨터가 자동으로 메뉴판을 만들 수 있지 않을까?"라고 생각했습니다.
결과: **76%**는 성공했습니다! 하지만 **24%**는 실패했습니다.
실패 이유: 문서에 적힌 내용과 실제 식당의 운영 방식이 달랐기 때문입니다.
예: "이 메뉴는 무료야"라고 적혀있는데, 실제로는 "비밀번호 (인증) 가 필요해"라고 하는 경우.
예: "주소는 여기야"라고 적혀있는데, 실제로는 "주소가 바뀌었어"라고 하는 경우.
4. 실패를 고치고 메뉴판을 더 깔끔하게 만들 수 있나요? (수리 및 정리)
해결책: 연구진은 AutoMCP라는 도구를 만들었습니다.
수리 (SpecFix): 문서의 오류를 찾아서 자동으로 고쳐줍니다. (예: "비밀번호 필요"라고 다시 적어줌)
정리 (Filtering & Grouping): 메뉴가 너무 많으면 요리사가 골라내기 힘듭니다. 그래서 비슷한 메뉴를 묶거나, 필요 없는 메뉴를 지웁니다.
성과:
성공률: 자동 생성 성공률이 **76% → 94%**로 크게 올랐습니다.
간소화: 메뉴 (도구) 의 개수가 평균 3 분의 1로 줄어들어, 요리사가 훨씬 더 쉽게 선택할 수 있게 되었습니다.
💡 이 연구가 우리에게 주는 교훈
대부분의 MCP 서버는 단순합니다: 복잡한 마법 같은 기술보다는, 기존 API 를 잘 포장해서 전달하는 역할이 대부분입니다.
적게 보여주는 것이 중요합니다: 모든 기능을 다 보여주는 것보다, 필요한 기능만 추려서 보여주는 것이 AI 가 더 잘 작동하게 합니다.
문서 (API 명세) 가 중요합니다: 자동화의 핵심은 '문서'입니다. 문서에 오류가 있으면 자동화가 실패합니다. 하지만 이 연구처럼 오류를 자동으로 찾아 고치는 기술이 있다면, AI 가 외부 서비스를 훨씬 더 잘 다룰 수 있게 됩니다.
🚀 결론: AutoMCP 의 등장
이 논문은 **"AutoMCP"**라는 도구를 공개했습니다. 이 도구는:
API 문서를 읽어서 오류를 고치고,
요리사 (AI) 가 골라먹기 좋게 메뉴를 정리하고,
바로 쓸 수 있는 MCP 서버를 만들어줍니다.
이제 개발자들은 수백 개의 메뉴를 일일이 일일이 만들지 않아도, 문서만 있으면 AI 가 쓸 수 있는 메뉴판을 자동으로 만들어낼 수 있게 된 것입니다. 이는 AI 에이전트가 더 많은 일을 할 수 있게 되는 중요한 디딤돌이 될 것입니다.
1. 연구 배경 및 문제 정의 (Problem)
배경: 대형 언어 모델 (LLM) 에이전트가 외부 도구를 호출하기 위해 MCP가 표준 인터페이스로 부상하고 있습니다. 많은 MCP 서버는 기존 벤더의 REST API 를 기반으로 구축되어 있습니다.
문제점:
관계의 불명확성: MCP 서버가 어떻게 REST API 를 래핑 (wrapping) 하는지, 어떤 연산이 노출되거나 생략되는지에 대한 실증적 연구가 부족합니다.
도구 선택의 어려움: REST API 는 수백 개의 엔드포인트를 가지는 경우가 많지만, LLM 에이전트는 너무 많은 도구가 주어지면 성능이 급격히 저하됩니다 (도구 선택 정확도 하락).
자동화의 한계: OpenAPI 명세에서 MCP 서버를 자동 생성하려는 시도가 있지만, 명세의 결함 (authentication 오류, URL 문제 등) 과 과도한 도구 수 (tool-set explosion) 로 인해 실패하거나 실용성이 떨어집니다.
2. 연구 방법론 (Methodology)
저자들은 4 가지 연구 질문 (RQ) 을 중심으로 4 단계에 걸친 실증 연구를 수행했습니다.
데이터셋:
RQ1: Anthropic 공식 카탈로그의 116 개 MCP 서버 (GitHub stars ≥ 10, REST API 보유).
RQ2: 위 서버 중 OpenAPI 명세가 공개된 42 개 서버 (6,966 개 REST 연산).
RQ3/RQ4: 77 개의 실제 REST API 명세 (RQ2 데이터 + APIs.guru/Konfig 데이터셋 샘플).
연구 질문 및 접근법:
**RQ1 **(REST 의존성 및 통합 전략) 116 개 서버의 소스 코드를 분석하여 REST API 의존도, 인증 방식, 전송 프로토콜, 그리고 API 호출 로직이 '단순 래퍼 (Bare API)'인지 '사용자 정의 로직 (Custom Logic)'인지 분류했습니다.
**RQ2 **(연산 노출 및 매핑 패턴) OpenAPI 명세와 MCP 도구를 매핑하여 노출 비율, 생략된 연산 카테고리, 그리고 도구 간 그룹화 패턴 (1:1, 다대 1 등) 을 분석했습니다.
**RQ3 **(자동 생성 가능성) AutoMCP-Baseline이라는 기본 생성기를 개발하여 77 개 API 명세에서 MCP 서버를 자동 생성하고, 실행 성공률과 실패 원인 (Defect Taxonomy) 을 분석했습니다.
**RQ4 **(수정 및 변환 효과)
SpecFix: 명세 결함을 자동으로 감지하고 수정하는 모듈.
Tool-Set Transformations: RQ2 에서 발견된 패턴을 기반으로 불필요한 도구를 필터링하고 (Filtering), 유사한 엔드포인트를 병합 (Grouping) 하는 기법.
이들을 결합한 AutoMCP 파이프라인의 효과를 평가했습니다.
3. 주요 기여 및 발견 (Key Contributions & Results)
RQ1: MCP 서버의 구조적 특성
REST 의존성: 116 개 서버 중 **88.6%**가 완전히 또는 부분적으로 REST API 에 의존합니다.
구현 패턴: REST 기반 서버의 **92%**는 복잡한 로직 없이 API 를 그대로 호출하는 'Bare API Consumption(단순 래퍼) 방식입니다.
설정: 인증은 토큰 기반 (API Key, Bearer) 이 주류이며, 전송 방식은 STDIO 가 가장 흔합니다.
RQ2: 연산 노출 및 매핑 패턴
낮은 노출률: MCP 서버는 벤더 API 의 전체 연산 중 **중앙값 19%**만 노출합니다. API 가 클수록 노출 비율은 낮아집니다 (대규모 API 는 6% 만 노출).
선별적 노출:
노출 선호: 읽기 전용 (Read-only), 목록 조회 (Listing), 분석 (Analytics), 워크플로우 관리.
생략 선호: 인증/권한 관리 (Auth/Authorization), 설정 (Settings), 파괴적 연산 (Destructive), 비하인드 (Deprecated).
매핑 패턴: 도구와 연산은 주로 1:1로 매핑됩니다. 다대 1 (Many-to-One) 그룹화는 주로 '컬렉션/아이템 병합' (예: 목록 조회와 상세 조회를 하나의 도구로 통합) 패턴으로 나타납니다.
RQ3: 자동 생성의 한계와 원인
성공률: 기본 생성기 (AutoMCP-Baseline) 로 76% 의 도구 실행에 성공했습니다.
실패 원인: 실패는 개별 엔드포인트 문제가 아니라 API 전체의 명세 결함에서 비롯됩니다. 주요 5 가지 결함:
잘못된/누락된 인증 스키마 (가장 흔함).
malformed 또는 상대 경로 Base URL.
문서화되지 않은 런타임 헤더/토큰 접두사.
파라미터 타입 불일치.
엔드포인트별 인증 누락.
RQ4: 자동 수정 및 도구 집합 변환의 효과
**SpecFix **(명세 수정) 결함을 자동으로 감지하고 수정하여 실행 성공률을 **76% → 94.2%**로 크게 향상시켰습니다.
**도구 집합 축소 **(Filtering & Grouping)
RQ2 에서 발견된 '생략 패턴' (인증, 설정 등) 을 기반으로 불필요한 도구를 제거했습니다.
'Collection/Item Merge' 패턴을 적용하여 도구 수를 줄였습니다.
결과: 총 도구 수 23.9% 감소, API 당 도구 중앙값이 73 개에서 49 개로 32.9% 감소했습니다. 이는 LLM 의 컨텍스트 윈도우 제한과 도구 선택 능력을 고려할 때 매우 실용적인 수준입니다.
4. 제안된 프레임워크: AutoMCP
논문은 AutoMCP라는 엔드투엔드 파이프라인을 제안합니다.
입력: OpenAPI 명세 (및 선택적 문서 URL).
SpecFix: 명세 결함 감지 및 자동 수정.
변환: 카테고리 기반 필터링 (불필요한 도구 제거) 및 그룹화 (병합).
생성: 수정된 명세와 변환 규칙을 기반으로 실행 가능한 MCP 서버 스텁 (Stub) 생성.
출력: 인증 설정 (.env) 과 서버 스텁을 포함한 실행 가능한 프로젝트.
5. 의의 및 결론 (Significance)
실증적 통찰: MCP 서버 개발자가 실제로 어떤 연산을 선택하고 생략하는지에 대한 데이터 기반 가이드라인을 최초로 제시했습니다. 이는 향후 MCP 서버 설계 시 '무엇을 포함할지/제외할지'에 대한 경험적 휴리스틱을 제공합니다.
자동화 가능성 입증: OpenAPI 명세만으로도 MCP 서버를 자동 생성할 수 있음을 증명했으며, 명세 품질 개선 (SpecFix) 과 도구 집합 최적화 (Filtering/Grouping) 를 통해 실용적인 수준의 자동화 파이프라인을 구축했습니다.
실무적 기여:
API 제공자: 자동화를 방해하는 명세 결함 (인증, URL 등) 에 대한 체크리스트 제공.
개발자: AutoMCP 를 통해 수동 코딩 없이도 신뢰할 수 있는 MCP 서버를 빠르게 구축할 수 있는 도구 제공.
LLM 에이전트: 도구 수가 과도하게 늘어나는 문제를 해결하여 에이전트의 도구 선택 정확도와 안정성을 높임.
이 연구는 MCP 생태계의 성숙도를 높이고, LLM 에이전트가 외부 REST API 를 효과적으로 활용할 수 있는 기반을 마련했다는 점에서 중요한 의의를 가집니다.