MCP란? API와의 차이와 연결 전에 확인할 세 가지

연결 규격과 사용 권한이 별도라는 점을 표현한 AI 생성 이미지입니다.

MCP를 붙이면 AI가 파일을 읽고, 이슈를 찾고, 외부 서비스의 기능을 부를 수 있습니다. 그래서 MCP를 “AI용 API”라고 부르기도 하지만, 이 표현만으로는 중요한 차이가 빠집니다. API는 특정 서비스의 기능을 호출하는 계약이고, MCP는 AI 애플리케이션이 여러 기능과 자료를 발견하고 주고받는 연결 규약에 가깝습니다.

결론부터 말하면 MCP는 API를 없애지 않습니다. MCP 서버가 내부에서 기존 API를 호출하고, AI 앱에는 도구와 자료의 형태로 보여주는 구성이 흔히 가능합니다. 연결 전에 봐야 할 것은 “MCP인가 아닌가”보다 무슨 기능이 노출되는지, 어디서 실행되는지, 어떤 권한으로 실행되는지입니다.

1. API와 MCP는 경쟁 제품이 아니라 층이 다릅니다

API는 프로그램이 다른 프로그램의 기능을 요청하는 접점입니다. 호출하는 쪽이 주소, 메서드, 인자, 인증 방식과 응답 형식을 알고 있으면 됩니다. 예를 들어 이슈 검색을 직접 호출하는 애플리케이션은 다음과 같은 흐름을 코드에 넣을 수 있습니다.

GET /repos/example/app/issues?q=login&state=open HTTP/1.1
Authorization: Bearer <application-token>
Accept: application/json

위 요청은 설명을 읽고 스스로 도구를 고르는 AI가 없어도 실행됩니다. 호출하는 프로그램이 “로그인 관련 열린 이슈를 찾는다”는 기능과 필요한 인자를 미리 알고 있기 때문입니다. 이 예시는 특정 서비스의 실제 엔드포인트를 재현한 것이 아니라 API 호출의 구조를 보여주는 축약 예시입니다.

MCP를 이용하면 호출하는 애플리케이션이 서버별 기능을 처음부터 모두 하드코딩하지 않아도 됩니다. MCP 호스트가 MCP 클라이언트를 만들고 서버와 연결한 뒤, 서버가 제공하는 기능과 자료를 확인합니다. 모델이 사용자의 요청에 맞는 도구를 고르면 클라이언트가 서버에 호출을 전달하고, 서버가 실제 파일·데이터베이스·기존 API를 처리한 뒤 결과를 돌려줍니다.

MCP 공식 아키텍처 문서는 MCP가 AI 애플리케이션의 모델 사용법을 정하는 것이 아니라 context exchange, 즉 문맥 교환을 위한 프로토콜에 집중한다고 설명합니다. MCP를 지원한다고 해서 모델이 새로 생기거나, 서버가 자동으로 높은 권한을 얻는다는 뜻은 아닙니다.

두 방식을 같은 기능으로 나란히 놓으면 차이가 더 분명합니다.

구분	직접 API 호출	MCP를 사이에 둔 호출
호출자	애플리케이션 코드	AI 호스트의 MCP 클라이언트
기능 발견	개발자가 주소와 인자를 알고 구현	서버가 제공 기능을 알리고 클라이언트가 조회
입력 결정	코드가 결정	모델이 대화 맥락을 보고 고를 수 있음
실제 처리	API 서버가 처리	MCP 서버가 직접 처리하거나 기존 API를 호출
권한 통제	API 인증·인가와 애플리케이션 정책	MCP 클라이언트·서버·하위 API의 정책을 모두 확인
잘 맞는 경우	정해진 화면·배치·백엔드 작업	여러 AI 호스트가 같은 도구와 자료를 재사용하는 경우

이 표에서 “모델이 고를 수 있음”은 편리함이면서 새로운 검토 지점입니다. 코드가 항상 같은 엔드포인트를 부르는 구조와, 모델이 여러 도구 설명을 보고 하나를 선택하는 구조는 실패 방식이 다릅니다. 후자에서는 도구 설명이 부정확하거나 입력 범위가 넓을 때 잘못된 호출이 생길 수 있습니다.

2. 실제로 어떤 부품이 오가는가

MCP 공식 문서의 기본 참여자는 호스트, 클라이언트, 서버입니다.

• MCP 호스트: 사용자가 대화하는 AI 애플리케이션입니다.
• MCP 클라이언트: 호스트 안에서 특정 MCP 서버와 연결을 유지하는 구성 요소입니다. 서버가 세 개면 클라이언트도 서버별로 따로 만들어질 수 있습니다.
• MCP 서버: AI 앱에 도구, 자료, 프롬프트를 제공하는 프로그램입니다. 내 컴퓨터에서 실행될 수도 있고 원격 서비스에서 실행될 수도 있습니다.

따라서 “MCP 서버”라는 이름만 보고 원격 서버라고 판단하면 안 됩니다. 공식 아키텍처 문서는 로컬 서버가 표준 입출력으로 같은 기기에서 실행될 수 있고, 원격 서버는 Streamable HTTP 같은 전송을 사용할 수 있다고 구분합니다. 실행 위치는 이름이 아니라 전송 방식과 실제 프로세스를 확인해야 합니다.

서버가 제공할 수 있는 세 가지 기본 기능도 나눠 읽어야 합니다.

기능	의미	예시	먼저 물을 질문
Tools	AI 앱이 호출할 수 있는 실행 기능	이슈 검색, 파일 수정, SQL 실행	읽기인가 쓰기인가? 되돌릴 수 있는가?
Resources	AI 앱에 제공하는 참고 자료	파일 내용, DB 스키마, API 응답	어느 범위의 자료가 노출되는가?
Prompts	재사용 가능한 상호작용 템플릿	코드 리뷰 형식, 서평 작성 틀	어떤 지시와 입력을 함께 넣는가?

예를 들어 데이터베이스 MCP 서버 하나가 query_database 도구, 스키마를 설명하는 resource, SQL 질문용 prompt를 모두 제공할 수 있습니다. 그렇다고 모든 MCP 서버가 세 기능을 전부 제공하거나, 연결한 호스트가 같은 방식으로 모두 지원한다는 뜻은 아닙니다. 목록과 실제 지원 범위를 각각 확인해야 합니다.

MCP 아키텍처 문서는 데이터 계층의 메시지 구조에 JSON-RPC 2.0을 사용하고, 전송 계층에서 표준 입출력이나 HTTP 같은 통신 방식을 다룬다고 설명합니다. 기능의 의미와 실제 통신 채널을 나눠 보는 이유가 여기에 있습니다.

기능 발견과 호출은 대략 다음처럼 이해할 수 있습니다. 아래 JSON은 특정 SDK에 그대로 복사하는 코드가 아니라, 메시지의 역할을 보여주는 축약 예시입니다.

{
  "method": "tools/list"
}

서버는 이름, 설명, 입력 스키마를 포함한 도구 목록을 돌려줄 수 있습니다. 자료와 프롬프트를 조회하는 경우에도 같은 발견 흐름을 사용해 resources/list, resources/read, prompts/list 같은 메서드를 확인합니다. 위 JSON은 역할만 보여주는 축약 예시입니다. 실제 전송 메시지에는 보통 JSON-RPC의 jsonrpc, id, params 같은 envelope가 함께 들어가며, 특정 SDK에 그대로 복사할 수 있는 완성 요청은 아닙니다.

모델이 사용자의 “로그인 관련 열린 이슈를 찾아줘”라는 요청에 search_issues가 맞다고 판단하면 클라이언트는 다음과 같은 의미의 호출을 전달합니다.

{
  "method": "tools/call",
  "params": {
    "name": "search_issues",
    "arguments": {
      "repository": "example/app",
      "query": "login",
      "state": "open"
    }
  }
}

실제 서버가 할 일은 여기서 끝나지 않습니다. repository가 허용된 대상인지, 사용자가 읽기 권한을 가지고 있는지, query가 너무 큰 검색이나 내부 데이터 접근으로 이어지지 않는지 서버가 검사해야 합니다. 서버가 내부에서 GitHub API를 호출한다면 하위 API의 인증과 rate limit, 감사 로그도 별도로 남습니다. MCP 메시지가 있다고 해서 이 검사가 자동으로 생기는 것은 아닙니다.

3. 연결 전에 확인할 세 가지

첫째, 기능: 도구 이름이 아니라 실제 행동을 적습니다

search, manage, assistant처럼 이름이 부드럽다고 읽기 전용인 것은 아닙니다. 도구 설명과 입력 스키마를 보고 다음 표를 직접 채워보는 편이 낫습니다.

확인 항목	예시 답변
읽는 대상	/Users/me/project 아래의 파일만
바꾸는 대상	없음 또는 특정 저장소의 이슈 본문
삭제 기능	없음
외부 네트워크	GitHub API로 검색 요청
실행 명령	없음 또는 서버 시작 시 실행되는 고정 명령
사람 확인	수정·삭제 전에 대상과 변경 내용을 표시

특히 write_file, delete_record, run_command, send_message처럼 상태를 바꾸거나 외부로 전송하는 도구는 읽기 도구와 같은 묶음으로 승인하지 않는 편이 안전합니다. 처음에는 검색과 읽기만 열고, 실제 쓰기 기능은 별도 확인을 거쳐 추가하는 것이 이 글의 운영 제안입니다. 이는 MCP가 요구하는 필수 설정이 아니라 권한을 줄이는 시작 방법입니다.

둘째, 실행 위치: 내 컴퓨터에서 무엇이 실행되는지 봅니다

로컬 MCP 서버라면 호스트가 설정에 적힌 프로그램을 실행하고 표준 입출력으로 통신할 수 있습니다. 이 경우 서버 프로그램은 사용자가 설치한 일반 프로그램처럼 파일, 네트워크, 환경 변수에 접근할 가능성이 있습니다. MCP 보안 지침은 원클릭으로 새 로컬 서버를 등록하는 클라이언트라면 실행할 정확한 명령을 잘리지 않게 보여주고, 코드 실행이 일어날 수 있음을 알린 뒤, 명시적인 사용자 승인을 받도록 요구합니다. 샌드박싱과 최소 권한은 추가 방어선으로 제시됩니다.

원격 MCP 서버라면 URL, 인증 흐름, 서버가 다시 호출하는 하위 서비스와 데이터의 이동 경로를 봐야 합니다. HTTPS를 쓰는지만으로 충분하지 않습니다. 실제로 어느 계정의 토큰을 어느 대상 API에 보내는지, 응답에 비공개 정보가 섞이는지, 요청과 결과가 감사 로그에 남는지를 확인해야 합니다.

셋째, 권한: 연결 성공과 사용 허가는 다릅니다

도구 목록이 보이고 연결 표시가 초록색이어도 다음 질문에는 답이 남아 있습니다.

1. 이 서버가 접근하는 계정은 개인 계정인가, 별도 제한 계정인가?
2. 토큰의 대상과 범위는 이 MCP 서버에 맞게 제한되어 있는가?
3. 읽기와 쓰기 권한이 같은 승인으로 묶여 있지 않은가?
4. 수정·삭제·전송 직전에 대상과 내용이 사용자에게 보이는가?
5. 실패한 호출과 권한 상승이 나중에 추적 가능한가?

보안 지침이 지적하는 대표적인 문제는 token passthrough입니다. MCP 서버가 클라이언트에서 받은 토큰을 검증하지 않고 하위 API에 그대로 넘기면, 토큰의 대상과 권한을 확인하는 경계가 무너질 수 있습니다. 공식 지침은 MCP 서버가 자신을 대상으로 발급되지 않은 토큰을 받아서는 안 된다고 명시합니다. 따라서 “OAuth로 로그인했다”는 사실만 적지 말고, 토큰이 어느 서비스와 어떤 범위를 대상으로 발급됐는지 확인해야 합니다.

연결이 실패했을 때 먼저 볼 지점

MCP 연결 실패를 곧바로 “서버가 고장 났다”로 해석하면 안 됩니다. 발견·인증·권한·도구 실행은 서로 다른 단계이므로, 마지막으로 성공한 단계를 기록해야 원인을 좁힐 수 있습니다.

증상	먼저 확인할 것	아직 결론 내리면 안 되는 것
로컬 서버 프로세스가 바로 종료됨	실행 명령·인자, 경로, 패키지 설치, 표준오류 로그	API 권한이나 모델 선택 문제라고 단정하지 않기
초기 연결은 되지만 기능 목록이 비어 있음	서버의 capability와 tools/list·resources/list 응답, 호스트의 지원 범위	서버에 기능이 전혀 없다고 단정하지 않기
원격 서버가 401·403을 반환함	토큰의 대상(audience), scope, 만료, 서버가 요구하는 인증 방식	네트워크 장애나 도구 구현 오류라고 단정하지 않기
도구 목록은 보이지만 호출이 거부됨	입력 스키마, 대상 리소스 권한, 읽기·쓰기 정책, 사용자 승인 단계	도구 설명만 보고 호출이 허용된다고 가정하지 않기
호출은 성공하지만 결과가 비어 있음	검색 조건, 리소스 범위, 하위 API 응답, 감사 로그	MCP가 데이터를 임의로 생성했다고 추정하지 않기

이 표는 공식 문서의 구성 요소와 보안 경계를 바탕으로 한 진단 순서입니다. 특정 호스트가 어떤 오류 문구나 승인 UI를 제공하는지는 제품별로 다르므로, 실제 장애 기록에는 호스트·클라이언트·서버 버전과 전송 방식도 함께 남겨야 합니다.

직접 API를 쓸지 MCP를 쓸지 고르는 기준

MCP가 더 최신이거나 더 좋은 API라는 식으로 고르면 안 됩니다. 한 애플리케이션이 정해진 백엔드 기능 하나를 호출하고 결과를 화면에 표시하는 일이라면 직접 API가 단순하고 통제하기 쉽습니다. 호출 순서와 인자를 코드가 정하고, 테스트도 같은 요청을 반복하면 되기 때문입니다.

반대로 여러 AI 호스트에서 같은 파일 검색, 이슈 조회, 데이터베이스 자료를 쓰고 싶고, 기능 목록과 입력 스키마를 공통 방식으로 제공해야 한다면 MCP 어댑터가 유용할 수 있습니다. 다만 이 선택은 기존 API를 버리는 선택이 아닙니다. 보통은 다음처럼 층을 나눕니다.

AI 호스트
  └─ MCP 클라이언트
      └─ MCP 서버
          ├─ 기존 REST/GraphQL API
          ├─ 데이터베이스
          └─ 로컬 파일 또는 사내 시스템

이 구조의 이점은 AI 호스트마다 별도 커넥터를 만들지 않고 도구 설명과 호출 경계를 공유할 수 있다는 점입니다. 대신 MCP 서버라는 어댑터와 권한 경계가 하나 더 생깁니다. 서버가 어떤 하위 API를 대신 호출하는지, 모델에게 보여주는 도구 설명과 실제 권한이 일치하는지, 장애와 감사 로그를 어디서 확인하는지까지 운영해야 합니다.

다음과 같이 판단하면 시작점이 흔들리지 않습니다.

상황	우선 검토할 방식
정해진 백엔드가 정해진 인자로 호출됨	직접 API
여러 AI 호스트가 같은 기능 목록을 사용함	MCP 서버와 기존 API의 조합
읽기 자료를 여러 도구가 같은 문맥으로 사용함	MCP Resources 검토
삭제·결제·메시지 발송처럼 영향이 큼	방식보다 서버 권한, 승인, 감사, 복구 설계를 먼저 검토
단순한 정기 배치와 재현 가능한 파이프라인	직접 API 또는 전용 작업 코드

마지막 행이 중요합니다. MCP를 도입한다고 해서 정기 작업이 더 재현 가능해지는 것은 아닙니다. 모델이 도구를 고르는 단계가 필요 없는 작업이라면 오히려 고정된 API 호출과 명시적인 검증 코드가 더 읽기 쉬울 수 있습니다.

제가 처음 연결한다면 이렇게 줄입니다

처음부터 파일 전체와 계정 전체를 열지 않습니다.

• 읽기 전용 도구 한두 개만 켭니다.
• 허용 디렉터리나 저장소를 하나로 제한합니다.
• 원격 서버의 계정과 scope를 업무용 제한 계정으로 분리합니다.
• 쓰기 도구는 기본 거부하고, 필요할 때만 별도 승인합니다.
• 수정·삭제·전송에는 대상, 변경 내용, 외부 수신자를 표시합니다.
• 호출 이름, 인자, 결과, 실패와 권한 변경을 로그에 남깁니다.
• 로컬 서버의 시작 명령과 패키지 출처를 확인하고 샌드박스나 OS 권한 제한을 검토합니다.

이렇게 시작하면 MCP가 “AI에게 컴퓨터를 맡기는 버튼”인지, 단순히 자료를 읽는 연결 계층인지 구분할 수 있습니다. 기능 목록에서 쓰기 도구를 발견했다고 바로 활성화하지 말고, 한 번의 호출이 어떤 시스템 상태를 바꾸는지부터 추적해 보세요.

정리

API는 특정 서비스의 기능을 호출하는 계약이고, MCP는 AI 호스트와 기능·자료 제공 프로그램 사이에서 발견과 문맥 교환을 표준화하는 규약입니다. MCP 서버는 기존 API를 없애는 대신 그 API를 감싸는 어댑터일 수 있으며, 로컬 또는 원격으로 실행될 수 있습니다.

연결 전에 확인할 세 가지는 기능, 실행 위치, 권한입니다. 이 세 가지를 분리하지 않으면 읽기 도구를 연결했다고 생각하면서 실제로는 파일 수정이나 외부 API 호출 권한까지 함께 열 수 있습니다.

자료 확인일과 범위

자료 확인일은 2026년 9월 7일입니다. 구조와 기본 기능은 MCP 아키텍처 문서의 2026-07-28 버전, 연결 보안의 예시는 MCP 보안 지침의 2025-11-25 버전을 기준으로 정리했습니다.

본문의 HTTP 요청, JSON-RPC 메시지, search_issues 도구와 권한 표는 이해를 위한 축약·가상 예시입니다. 특정 MCP 서버의 코드, 호스트의 실제 권한 UI, 성능, 보안성을 직접 감사하거나 측정한 글은 아닙니다. 프로토콜 지원 표시만으로 서버 운영자나 배포 패키지의 신뢰성을 보증할 수 없다는 점도 함께 남깁니다.

이어서 읽기

권한 범위를 정하는 기준은 AI에게 어디까지 맡길까: 가역성으로 보는 위임에서 이어집니다.