MCP란 무엇인가? Model Context Protocol은 AI Agent, Tools, API와 JSON Schema를 어떻게 연결하는가?

MCP Server를 연결했지만 도구가 보이지 않거나, Agent가 잘못된 인자를 보내고, API 권한을 어디에 둘지 막막한 상태인가요?
가장 빠른 해결법은 MCP를 모델이나 Function Calling이 아니라 AI 애플리케이션과 도구를 연결하는 프로토콜로 분리해 설계하는 것입니다.

이 글을 읽어야 하는 사람

MCP Server 개발자는 도구와 JSON Schema를 정확히 노출하는 방법을 확인할 수 있습니다.
Agent 플랫폼 엔지니어는 여러 Client와 모델을 연결하는 흐름을 정리할 수 있습니다.
운영 및 보안 팀은 인증, 감사 로그, 실행 승인, 원격 배포 범위를 결정할 수 있습니다.

MCP를 처음 붙일 때 역할을 먼저 나눠야 하는 이유

MCP Model Context Protocol은 외부 시스템과 AI 애플리케이션을 연결하는 개방형 프로토콜입니다. 모델 자체가 아니며, Function Calling을 없애거나 대체하지도 않습니다. 일반적인 실행 흐름은 다음과 같습니다.

1. AI 애플리케이션인 Host가 MCP Client를 생성합니다.
2. Client가 MCP Server에 연결하고 지원 기능을 확인합니다.
3. Server가 도구 이름, 설명, 입력 구조를 제공합니다.
4. 모델이 대화 맥락을 보고 사용할 도구를 선택합니다.
5. Client 또는 Host가 실제 MCP 호출을 실행합니다.
6. MCP Server가 내부 API나 데이터베이스를 호출합니다.
7. 결과가 Client를 거쳐 모델과 사용자에게 돌아갑니다.

공식 구조에서 Host는 연결 수명과 사용자 승인, 보안 정책을 관리합니다. Client는 특정 Server와 연결되는 프로토콜 커넥터입니다. Server는 리소스, 도구, 프롬프트를 노출합니다. 하나의 Host가 여러 Client를 만들 수 있지만, 각 Client는 보통 특정 Server 연결을 격리해 관리합니다. 공식 아키텍처 문서는 이 역할 분리를 명시합니다.

이 구분이 중요한 이유는 모델이 보통 네트워크 소켓이나 내부 API에 직접 접근하지 않기 때문입니다. 모델은 사용 가능한 도구 정보를 보고 호출 의도를 생성하지만, 실제 연결과 권한 검사는 Host 또는 Client 계층에서 처리해야 합니다.

예를 들어 사내 배포 시스템을 연결한다고 가정해 보겠습니다.

• 모델은 배포 상태 확인이라는 도구를 선택합니다.
• Client는 도구 이름과 인자를 MCP 메시지로 전달합니다.
• MCP Server는 사내 배포 API에 인증된 요청을 보냅니다.
• Server는 상태 코드와 결과를 정리해 반환합니다.
• Host는 결과를 모델의 다음 입력으로 전달합니다.

따라서 MCP와 대형 언어 모델의 관계는 “모델이 MCP를 직접 실행한다”가 아닙니다. MCP는 모델이 사용할 수 있는 외부 기능을 표준 방식으로 설명하고 연결하며, Host는 모델과 실행 환경 사이의 통제 지점이 됩니다.

연결이 시작되면 어떤 순서로 협상하는가?

MCP의 연결 생명주기는 전송 준비, 초기화, 기능 협상, 도구 발견, 호출 순서로 이해하면 됩니다. 세부 메시지 이름을 모두 외우기보다 각 단계에서 누가 무엇을 결정하는지 확인하는 편이 구현 오류를 줄입니다.

1단계: 전송 방식을 고릅니다

로컬 환경에서는 STDIO가 단순합니다. Client가 MCP Server를 하위 프로세스로 실행하고, Server는 표준 입력과 표준 출력으로 JSON-RPC 메시지를 주고받습니다. 이 방식은 같은 컴퓨터에서 파일, 개발 도구, 로컬 스크립트를 연결할 때 적합합니다.

다만 STDIO Server의 표준 출력에는 유효한 MCP 메시지만 기록해야 합니다. 디버그 문장을 표준 출력에 섞으면 Client가 프로토콜 메시지로 오인할 수 있습니다. 로그는 표준 오류나 별도 로깅 경로로 분리해야 합니다. 공식 전송 방식 문서에서 STDIO의 입출력 규칙을 확인할 수 있습니다.

원격 환경에서는 Streamable HTTP를 사용합니다. Server가 독립 프로세스로 실행되며 여러 Client 연결을 받을 수 있으므로 팀 공유, 게이트웨이, 인증 서버, 관찰 도구를 붙이기 쉽습니다. 대신 TLS, 인증, 요청 제한, 원본 검증, 재시도 정책이 필요합니다.

2단계: 초기화와 기능 협상을 진행합니다

기존 세대의 MCP 연결에서는 Client와 Server가 초기화 메시지를 주고받고, 지원하는 프로토콜 버전과 기능을 교환했습니다. 도구 호출을 지원한다고 선언하지 않은 Server에 Client가 임의로 도구 호출을 보내면 안 됩니다.

2026년 7월 28일 규격에서는 HTTP 요청 구조와 연결 방식에 큰 변경이 포함됐습니다. 초기화 교환과 세션 식별자 사용 방식이 바뀌었고, 요청마다 프로토콜 버전과 Client 정보를 전달하는 구조가 도입됐습니다. 따라서 MCP Server를 운영 환경에 배포할 때는 “MCP를 지원한다”는 문장만 보지 말고, 실제 Client가 어떤 규격 버전을 사용하는지 확인해야 합니다. 2026년 7월 28일 공식 규격 변경 안내를 기준으로 호환성을 점검해야 합니다.

3단계: 기능 목록을 확인합니다

Server는 도구만 제공하는 것이 아닙니다.

• 도구는 모델이 작업을 수행하거나 외부 정보를 조회하는 기능입니다.
• 리소스는 파일, 문서, 데이터처럼 문맥으로 읽을 수 있는 정보입니다.
• 프롬프트는 사용자가 선택할 수 있는 재사용 지침이나 작업 흐름입니다.

이 세 가지는 통제 주체도 다릅니다. 도구는 모델 주도, 리소스는 애플리케이션 주도, 프롬프트는 사용자 주도로 설명됩니다. Server 기능 공식 문서는 이 차이를 구분합니다.

AI Agent는 왜 JSON Schema를 읽고 누가 도구를 실행하는가?

MCP Server가 도구를 노출할 때 Client가 받아야 하는 핵심 정보는 도구 이름, 사람이 읽을 수 있는 설명, inputSchema입니다. 필요하다면 outputSchema와 도구의 읽기 전용, 파괴적 동작, 멱등성 관련 주석도 제공할 수 있습니다.

JSON Schema는 연결 규칙이지 모델의 판단을 대신하지 않습니다

JSON Schema는 입력값의 형태를 설명합니다. 예를 들어 배포 도구라면 환경 이름은 문자열이고, 버전은 문자열이며, 승인 여부는 불리언이라는 식으로 제한할 수 있습니다.

하지만 Schema만으로 좋은 도구 선택이 보장되지는 않습니다. 다음 두 요소도 중요합니다.

• 도구 설명이 실제 동작과 일치해야 합니다.
• 필드 이름과 예시가 모호하지 않아야 합니다.

run_task처럼 의미가 넓은 이름보다 staging_deploy_preview처럼 대상과 동작이 드러나는 이름이 모델 선택에 유리합니다. “파일을 삭제할 수 있음”, “외부 결제가 발생함”, “읽기 전용임” 같은 경계도 설명에 포함해야 합니다.

2026년 7월 28일 규격에서는 도구 입력과 출력 Schema의 표현 범위가 확장됐습니다. 기존 구현이 객체 중심 구조를 전제로 작성됐다면, 배열이나 다른 JSON 값이 포함된 결과를 처리할 수 있는지 확인해야 합니다. 규격 버전과 Client 지원 범위가 다르면 outputSchema를 제공해도 Client가 이를 완전히 활용하지 못할 수 있습니다. 공식 도구 규격과 Schema 참고 문서를 함께 검토하는 편이 안전합니다.

실제 호출자는 모델이 아니라 실행 계층입니다

도구 호출은 다음 세 층으로 나눠야 합니다.

• 모델 계층: 어떤 도구를 어떤 인자로 사용할지 결정합니다.
• MCP 계층: 도구 이름과 인자를 JSON-RPC 메시지로 전달합니다.
• 업무 API 계층: 실제 데이터 조회, 파일 수정, 배포, 결제 같은 동작을 수행합니다.

이 구분을 코드에 반영하지 않으면 모델 출력과 실제 실행을 한 함수에 섞게 됩니다. 그러면 승인 화면을 넣기 어렵고, 재시도 때 같은 작업이 두 번 실행될 수 있습니다.

권장 호출 흐름은 다음과 같습니다.

1. Client가 tools/list 결과를 저장합니다.
2. Host가 현재 사용자에게 허용된 도구만 모델에 전달합니다.
3. 모델이 도구 이름과 인자를 제안합니다.
4. Client가 JSON Schema로 인자를 검증합니다.
5. 위험도가 높은 도구라면 사용자 확인을 받습니다.
6. MCP Server가 내부 API를 호출합니다.
7. Server가 성공, 업무 오류, 인증 오류를 구분해 반환합니다.
8. Host가 결과를 모델과 감사 로그에 각각 전달합니다.

오류 처리는 성공 응답과 별개로 설계해야 합니다. 네트워크 시간 초과, 잘못된 인자, 인증 만료, 외부 API의 제한 초과를 같은 문자열로 반환하면 Agent가 잘못된 재시도를 할 수 있습니다. 쓰기 작업에는 멱등 키를 사용하고, 취소 신호를 받으면 하위 API 요청도 중단할 수 있어야 합니다. 장시간 작업은 즉시 완료된 것처럼 응답하지 말고 상태 조회나 작업 핸들을 별도 흐름으로 분리하는 편이 좋습니다.

권한과 자격 증명은 실행 환경에서 통제합니다

MCP Server에 API를 연결할 때 가장 흔한 실수는 자격 증명을 Schema나 프롬프트에 넣는 것입니다. Schema는 Client와 모델에 전달될 수 있으므로 비밀값을 넣어서는 안 됩니다. 토큰과 비밀번호는 Host의 비밀 저장소, 환경 변수, 주입된 실행 환경 또는 별도 인증 계층에서 관리해야 합니다.

도구는 최소한 다음 세 그룹으로 나누어 운영하십시오.

• 읽기 도구: 조회, 검색, 상태 확인
• 쓰기 도구: 생성, 수정, 배포 요청
• 파괴적 도구: 삭제, 권한 변경, 결제, 운영 환경 중단

배포 방식을 결정하는 조건 목록

아래 항목을 순서대로 확인하면 로컬, 원격, 혼합 배포 중 어디서 시작할지 결정할 수 있습니다.

• [ ] 한 명의 개발자만 사용하고 로컬 파일이나 개인용 스크립트가 중심이면 로컬 STDIO를 선택합니다. Server를 다른 사용자와 공유하지 않는 조건에서 가장 단순합니다.
• [ ] 여러 사용자가 같은 도구를 호출하거나 중앙 감사 로그가 필요하면 팀용 원격 HTTP를 선택합니다. TLS, 인증, 요청 제한, 장애 복구를 함께 준비해야 합니다.
• [ ] 민감한 파일과 개발 키는 개인 컴퓨터에 두고 문서 검색이나 공용 API만 공유해야 하면 혼합 방식을 선택합니다. 도구별 연결 위치와 권한을 분리합니다.
• [ ] Xcode, 서명 환경, macOS 전용 자동화가 실제 실행 대상이면 Mac 실행 환경을 추가합니다. MCP Server 자체와 Mac 전용 실행 노드는 분리할 수 있습니다.
• [ ] 일반적인 API, 데이터베이스, 웹훅만 연결하고 macOS 의존성이 없으면 Mac을 기본 배포 위치로 선택하지 않습니다. Linux나 컨테이너 환경으로도 충분히 운영할 수 있습니다.
• [ ] 장기 중량 작업이 안정적으로 계속 실행되고 물리 장치나 로컬 GUI 접근이 필수이면 자체 환경을 우선 검토합니다. 이 조건에서는 원격 임대보다 직접 관리가 적합할 수 있습니다.
• [ ] 임시 테스트, 짧은 검증, 팀 공유용 macOS 실행 노드가 필요하면 원격 Mac을 검토합니다. 장기 운영과 단기 실험을 같은 방식으로 계약하지 않는 편이 좋습니다.

결정 규칙은 간단합니다. 첫 번째나 세 번째 항목만 해당하면 로컬 또는 혼합 방식에서 시작합니다. 두 번째 항목이 포함되면 원격 HTTP를 기본안으로 검토합니다. 네 번째 항목이 포함되면 Mac 실행 환경을 별도 노드로 추가합니다. 여섯 번째 항목이 강하면 자체 환경을 우선하고, 일곱 번째 항목이 강하면 원격 Mac을 테스트 용도로 먼저 사용합니다.

공식 보안 원칙도 사용자 동의, 데이터 접근 통제, 도구 실행 승인, Server 간 격리를 강조합니다. 특히 도구 설명이나 주석을 신뢰할 수 없는 Server에서 가져왔다면 안전한 동작이라고 가정해서는 안 됩니다. 공식 보안 및 신뢰 원칙을 배포 승인 기준에 포함하십시오.

원격 HTTP Server를 운영한다면 인증은 선택 가능한 기능이지만, 인증을 생략할 수 있다는 뜻은 아닙니다. HTTP 기반 배포에서는 인증 체계와 TLS를 적용하고, 로컬에 직접 바인딩하는 경우에는 외부 인터페이스에 노출하지 않는 구성이 우선입니다. 공식 인증 문서는 HTTP 전송과 STDIO 환경의 자격 증명 처리 차이를 설명합니다.

로컬 MCP Server를 원격 서비스로 바꿀 때 무엇을 바꿔야 하는가?

개인 개발용 MCP Server를 팀용 서비스로 전환할 때는 실행 위치만 바꾸면 된다고 생각하기 쉽습니다. 실제로는 다음 다섯 단계를 다시 설계해야 합니다.

1. 로컬 의존성을 목록화합니다

파일 경로, 운영체제 명령, 사용자 홈 디렉터리, 로컬 인증서, USB 장치, 개발 도구 설치 여부를 적습니다. 특정 컴퓨터에서만 존재하는 의존성은 원격 Server로 옮기기 전에 대체 경로를 정해야 합니다.

2. 도구 계약을 고정합니다

도구 이름, 필수 인자, 허용 값, 오류 형태, 출력 구조를 문서화합니다. 변경이 잦은 내부 API를 그대로 노출하지 말고 MCP Server가 안정적인 계약으로 감싸야 합니다.

3. 전송과 인증을 교체합니다

STDIO는 Client가 Server 프로세스를 실행하지만, 원격 HTTP는 별도 서비스와 네트워크 경로가 필요합니다. 인증서 갱신, 토큰 만료, 요청 제한, 접근 IP, 장애 시 재시도 정책을 정합니다.

4. 실행 권한을 줄입니다

Server 프로세스에 운영 데이터베이스 전체 권한이나 서버 관리자 권한을 주지 마십시오. 도구별 서비스 계정과 최소 권한을 사용하고, 읽기와 쓰기 자격 증명을 분리합니다.

5. 관찰과 복구를 검증합니다

초기화 또는 기능 발견 실패, 도구 인자 오류, API 시간 초과, Server 재시작, Client 재연결을 각각 시험합니다. 성공 사례만 확인하면 실제 장애 때 원인을 찾기 어렵습니다.

개인용 로컬 Server는 빠르고 비용 부담이 작습니다. 반면 팀 공유, 중앙 감사, 여러 Agent 연결, 상시 실행이 필요하면 원격 Server가 관리하기 쉽습니다. 혼합 방식도 가능합니다. 민감한 파일과 개발 키는 로컬에 두고, 공용 검색이나 업무 조회 도구만 원격으로 제공하는 방식입니다.

macOS 자원이나 Xcode, 서명 환경, 애플 자동화가 실제 도구 실행에 필요할 때만 원격 Mac을 검토하십시오. 일반적인 API, 데이터베이스, 웹훅 중심의 MCP Server는 Linux나 컨테이너 환경에서도 충분히 운영할 수 있습니다. 모든 MCP Server를 Mac에 배치하는 것은 비용과 유지 관리 범위를 불필요하게 키울 수 있습니다.

장기 운영 환경의 네트워크 구성과 호스트 자원이 궁금하다면 인프라 운영 환경 안내를 먼저 확인하십시오. 원격 Mac이 필요한 경우에도 MCP Server 자체와 Mac에서 실행되는 자동화 도구를 분리해 판단해야 합니다.

배포 전 연결 수명주기 점검

다음 조건을 모두 통과해야 팀 공유용 MCP Server로 올리는 것이 좋습니다.

• [ ] Client가 Server에 연결한 뒤 지원 기능을 정확히 확인합니다.
• [ ] 도구 목록의 이름과 설명이 실제 동작과 일치합니다.
• [ ] inputSchema 검증 실패가 외부 API 실행 전에 차단됩니다.
• [ ] outputSchema가 제공되는 경우 반환 결과가 해당 구조를 따릅니다.
• [ ] 읽기, 쓰기, 파괴적 도구의 승인 정책이 다릅니다.
• [ ] 자격 증명이 Schema, 프롬프트, 공개 설정 파일에 포함되지 않습니다.
• [ ] 시간 초과와 취소가 하위 API 호출까지 전달됩니다.
• [ ] 중복 실행을 막을 멱등 처리나 작업 상태 조회가 있습니다.
• [ ] 원격 HTTP Server에 TLS와 인증이 적용됩니다.
• [ ] Client 규격 버전과 Server SDK 버전을 함께 기록합니다.
• [ ] 도구 호출 로그에 비밀값과 민감한 원문이 남지 않습니다.
• [ ] 장애 때 재연결, 재시도, 수동 중단 절차가 문서화되어 있습니다.

현재 로컬 PC에서만 MCP를 돌리면 사용자가 자리를 비웠을 때 연결이 끊기고, 팀원이 같은 환경을 재현하기 어렵고, 사내 API 자격 증명과 실행 로그가 여러 개발자 컴퓨터에 흩어질 수 있습니다. 반대로 무조건 클라우드로 옮기면 로컬 파일, Xcode, 서명 키, macOS 자동화처럼 물리 환경에 묶인 작업을 다시 연결해야 합니다.

그래서 API와 문서 조회 중심이면 기존 서버 환경을 유지하고, Xcode 빌드나 서명, 장시간 애플 자동화를 계속 실행해야 한다면 Mac 상시 환경을 별도로 검토하는 편이 합리적입니다. 그런 팀이라면 원격 Mac 상시 운영 상담에서 필요한 macOS 자원, 연결 방식, 인증 경계를 먼저 확인한 뒤 임시 테스트 환경과 장기 운영 환경을 나누어 결정하십시오. Kvmjet의 Mac 환경은 MCP Server 자체를 대신하는 것이 아니라, macOS 전용 도구를 지속적으로 호출해야 할 때 선택할 수 있는 실행 기반입니다.