MCP는 API를 대체할까? AI 도구 연결의 표준과 남는 책임

연결이 쉬워졌다는 말에서 빠진 것

회사에 주문 조회 API가 있다고 하자. AI 앱 하나가 이 API를 부르는 데는 주소와 인증정보, 요청 형식을 정한 연동 코드가 필요하다. AI 앱이 세 개로 늘면 같은 기능을 각 앱의 도구 형식에 맞춰 다시 설명하고 구현할 수 있다. MCP가 주목받는 이유 중 하나는 이 반복을 줄일 수 있다는 데 있다.

그런데 주문 조회 옆에 주문 취소를 붙이면 문제가 달라진다. 조회 결과를 읽는 일과 돈·재고·배송 상태를 바꾸는 일은 같은 위험을 갖지 않는다. 프로토콜이 같아도 취소 가능한 주문인지, 이 사용자가 취소할 수 있는지, 이미 처리된 요청인지 확인해야 한다.

따라서 MCP를 평가할 때는 “몇 개 서비스와 연결되는가”와 “연결된 기능을 어느 조건에서 실행할 수 있는가”를 나눠야 한다. 전자는 상호운용의 범위이고 후자는 제품의 업무 계약이다. 이 글은 MCP 2025-11-25 규격을 기준으로 그 경계를 설명한다. 모든 제품이 해당 규격의 모든 기능을 지원한다는 뜻은 아니다.

API·함수 호출·MCP는 같은 층의 대안이 아니다

REST API는 외부 시스템이 제공하는 기능을 HTTP 요청으로 표현하는 흔한 방식이다. 모델 API의 함수 호출 기능은 모델이 실행할 도구 이름과 인자를 구조화해 제안하도록 만드는 접점이다. MCP는 AI 애플리케이션과 도구·자료 제공 서버가 공통으로 이해할 연결 규약이다.

이를 다음처럼 함께 쓸 수 있다. 순서는 설명용 예시이며 모든 구현이 이 형태인 것은 아니다.

사용자 요청
  → AI 호스트가 사용 가능한 도구를 모델에 제시
  → 모델이 도구와 인자를 선택
  → 호스트의 정책·사용자 확인
  → MCP 클라이언트가 MCP 서버에 호출
  → MCP 서버가 기존 업무 API 호출
  → 결과 반환·업무 상태 확인

비교 대상	주로 정하는 것	자동으로 해결하지 않는 것
업무 API	주문 조회·변경 등 서비스 기능과 데이터 계약	AI가 언제 어떤 기능을 고를지
모델의 도구 호출 접점	도구 이름·인자 제안의 표현	실제 실행 권한, 외부 시스템의 성공
MCP	도구 발견·호출·자료 교환의 공통 메시지와 기능 협상	업무 의미, 모든 호스트의 동일한 UI·정책
제품의 실행 정책	승인, 제한, 감사, 중단·복구 기준	모델 능력이나 외부 서비스 가용성 자체

MCP 서버가 기존 API를 감싸는 구조라면 API의 오류와 변경도 여전히 관리해야 한다. MCP를 붙였다는 이유로 기존 서비스의 권한 검사를 지워서는 안 된다. 표준화는 책임을 없애는 것이 아니라, 어디에 책임을 둘지 더 분명하게 만들 기회다.

호스트가 중요한 이유: 모델과 서버 사이의 조정자

MCP 아키텍처 문서는 호스트, 클라이언트, 서버를 구분한다. 호스트는 사용자와 모델을 연결하는 애플리케이션이며 서버별 클라이언트 연결을 관리한다. 클라이언트는 서버와 규격·기능을 협상하고 메시지를 주고받는다. 서버는 도구, 자료, 프롬프트 등의 기능을 제공한다.

여기서 서버는 대화 전체를 자동으로 알고 있는 존재가 아니다. 어떤 문맥을 전달하고 여러 서버의 결과를 어떻게 합칠지 호스트가 결정한다. 같은 MCP 서버라도 호스트가 지원하는 기능과 정책에 따라 경험이 달라질 수 있다. 기능 협상은 서로 할 수 있는 일을 확인하는 절차이지, 모든 조합의 업무 품질을 보증하는 인증서는 아니다.

예를 들어 두 AI 앱이 같은 주문 서버를 사용해도 한 앱은 조회만 노출하고 다른 앱은 취소 도구까지 노출할 수 있다. 후자는 별도의 사용자 확인을 요구할 수도 있다. 이 차이는 프로토콜 호환성 실패가 아니라 호스트가 선택한 제품 정책일 수 있다.

이 구조를 이해하면 “MCP 호환”이라는 표기에서 더 물어볼 것이 보인다. 어떤 규격 버전과 기능을 구현했는지, 도구 목록 변경을 어떻게 반영하는지, 연결이 끊기면 상태를 어디서 확인하는지까지 살펴야 한다.

도구 목록을 읽었다고 업무 의미까지 이해한 것은 아니다

도구 규격에는 도구 목록을 얻는 tools/list, 실행을 요청하는 tools/call, 입력·출력 스키마 등의 요소가 있다. 이는 통합을 위한 유용한 공통 형식이다. 하지만 스키마는 주로 값의 형식과 구조를 설명한다.

가상의 cancel_order 도구가 문자열 order_id를 받는다고 하자. A-1042가 문자열이라는 검사는 쉽다. 그 주문이 현재 사용자의 것인지, 이미 발송됐는지, 취소하면 어떤 비용이 발생하는지는 다른 검사다. 도구 설명에 취소 조건을 적더라도 실제 서버가 그 조건을 다시 집행해야 한다.

도구 설계를 검토할 때 다음 네 층을 구분하면 빠진 부분을 찾기 쉽다.

1. 형식: 필드가 존재하고 자료형이 맞는가.
2. 권한: 이 사용자·앱이 이 대상에 이 동작을 할 수 있는가.
3. 업무 조건: 현재 상태에서 이 변경이 유효한가.
4. 완료: 변경 후 실제 상태가 요청 의도와 일치하는가.

도구가 정상 응답을 반환해도 비동기 작업의 접수만 끝난 경우가 있을 수 있다. 제품이 그 응답을 바로 완료로 세면 상태 확인이 빠진다. 실패 후 다시 호출할 때 중복 취소나 중복 알림이 생기지 않는지도 업무 API와 함께 설계해야 한다. 이는 앞서 다룬 에이전트의 완료 비용과 직접 연결된다.

인증 성공과 업무 권한은 다르다

MCP 인가 문서는 HTTP 기반 전송의 흐름을 다룬다. 로컬 STDIO 전송을 같은 방식으로 설명하지 않는다. 원격 서버 로그인 화면이 있다고 해서 모든 로컬 도구 실행이 같은 보호를 받는다고 추정하면 안 된다.

또한 연결 가능한 사용자라는 사실과 특정 업무 레코드를 변경할 권한이 있다는 사실은 다르다. 어떤 사용자가 CRM 서버에 접속할 수 있어도 타 부서 고객 정보를 모두 읽을 수 있는 것은 아닐 수 있다. 서버는 최종 데이터 접근 지점에서 사용자·조직·대상의 권한을 확인해야 한다.

MCP 보안 지침은 서버가 자신을 대상으로 발급됐는지 확인하지 않은 토큰을 받아 하위 API로 넘기는 token passthrough를 금지한다. 편리하게 연결하는 것과 토큰의 발급 대상·책임 경계를 유지하는 것은 별도의 요구다. 이 글은 그 구조를 설명하며 실제 인증 우회나 공격을 시험하지 않았다.

도구가 “읽기 전용”이라고 표시한 정보도 출처를 봐야 한다. 도구 규격은 신뢰할 수 없는 서버의 annotation을 그대로 믿지 말라고 명시한다. 이름이나 설명만 보고 실행의 영향을 확정할 수 없다는 뜻이다.

비용이 사라지는 대신 이동하는 지점

AI 호스트가 H개, 업무 서비스가 S개인 환경에서 모든 조합을 제각각 연결하면 연결 지점이 H×S에 가까워질 수 있다. 공통 규약을 지원하는 호스트와 서버를 만들면 일부 공통 작업을 H+S 쪽으로 줄일 여지가 있다. 이는 연결 구조를 설명하는 단순 모형이지, 실제 개발시간이 그 비율로 감소한다는 측정 결과가 아니다.

실무에서는 다음 비용이 남거나 새로 생긴다.

비용 항목	표준화로 기대할 수 있는 변화	계속 관리할 내용
도구 설명과 호출 형식	여러 호스트에서 재사용 가능	설명 품질, 기능별 지원 차이
업무 서비스 연동	서버 뒤에 한 번 감쌀 수 있음	원래 API 버전·오류·사용량 제한
인증·연결	공통 흐름과 구현 재사용	조직별 승인·토큰 보관·권한 회수
장애 분석	프로토콜 경계를 따라 로그 구분	모델 판단·MCP 호출·하위 API 결과의 연계
공급망·운영	중앙 관리의 여지	서버 업데이트, 의존성, 배포·복구 책임

하나의 앱에서 고정된 API 하나만 호출한다면 새 서버 계층이 운영 부담을 더할 수 있다. 여러 앱이 같은 업무 기능을 공유하거나 도구 제공자의 교체 가능성이 중요하다면 공통 계층의 이점이 커질 수 있다. 도입 판단은 “표준이므로 좋다”보다 재사용의 규모와 책임의 위치에 달려 있다.

도입 전에는 호환성보다 업무 시나리오를 시험한다

가상의 일정 관리 도구를 평가한다고 하자. 일정 조회가 된다는 시연만으로 변경 기능을 승인하기는 어렵다. 다른 사용자 일정의 거절, 존재하지 않는 일정, 이미 바뀐 일정의 재수정, 중복 요청, 서버 연결 중단을 각각 확인해야 한다. 정상 흐름과 실패 흐름을 같은 수준의 계약으로 다루는 것이다.

기록할 단위도 나눌 수 있다. 호스트가 선택한 도구, 서버에 전달한 인자, 서버가 호출한 업무 API, 최종 확인된 상태를 동일한 작업 식별자로 연결하면 어느 단계에서 의미가 달라졌는지 추적하기 쉽다. 민감한 원문과 인증정보를 로그에 그대로 남기라는 뜻은 아니다.

다음 조건이라면 작은 범위부터 도입을 검토할 만하다. 여러 호스트에서 재사용할 기능이 있고, 그 기능의 입력·출력·권한·실패 조건을 명확하게 정의할 수 있으며, 서버 유지 책임을 맡을 주체가 있는 경우다. 반대로 업무 조건이 아직 정리되지 않았다면 프로토콜 추가보다 API 계약과 권한 모델 정리가 먼저일 수 있다.

MCP의 가치는 도구를 발견하고 호출하는 접점을 공유하는 데 있다. 좋은 업무 도구를 설계하는 일, 잘못된 실행을 막는 일, 결과를 확인하는 일은 그 공통 접점 위에서 계속해야 한다. 표준 도입 후 무엇이 쉬워졌고 무엇이 남았는지 나누어 보는 것이 이 기술을 오래 활용하는 기준이다.