MCP 서버 연동은 대화형 AI가 로컬 파일과 업무 앱, 원격 API를 같은 규약으로 다루게 합니다. 공식 명세는 MCP를 LLM 애플리케이션과 외부 데이터·도구를 JSON-RPC 2.0으로 연결하는 공개 프로토콜로 정의합니다. 작업 자동화와 생산성을 높이려면 연결 규약이 먼저 안정되어야 합니다.
연결을 시작하는 쪽은 Host이고, 호스트 안의 커넥터는 Client이며, 컨텍스트와 기능을 제공하는 쪽은 Server입니다. 연동을 마치면 모델이 도구 목록을 받아 실제 업무 흐름에 붙일 수 있습니다. 아래 내용은 연동 준비부터 권한과 장애 대응까지 실무 순서로 정리합니다.
MCP 서버란 무엇이고 왜 연동하는가
MCP는 상태 유지 연결과 능력 협상을 기본으로 둡니다. 서버는 Resources, Prompts, Tools를 제공할 수 있어 모델이 읽기 전용 자료와 재사용 프롬프트, 실행 가능한 도구를 한 세션에서 함께 씁니다. 채팅만으로 끝내지 않고 실제 데이터와 기능을 붙이려는 팀이 이 규약을 고릅니다.
표준 전송은 로컬 stdio와 원격 Streamable HTTP입니다. Streamable HTTP는 단일 MCP 엔드포인트에서 POST와 GET을 사용합니다. 로컬은 클라이언트가 서버 프로세스를 띄워 표준 입출력으로 JSON-RPC를 주고받고, 원격은 그 HTTP 엔드포인트에 연결합니다.
| 구분 | 로컬 stdio | 원격 Streamable HTTP |
|---|---|---|
| 연결 방식 | 서버 프로세스를 띄워 stdin과 stdout으로 JSON-RPC를 주고받습니다. | 단일 MCP 엔드포인트에 POST와 GET으로 붙습니다. |
| 인가 | 프로세스 권한과 OS 사용자 경계에 의존합니다. | OAuth 2.1 인가 코드와 PKCE로 토큰을 검증합니다. |
| 폴백 | 해당이 없습니다. | 실패 시 구 SSE 전송을 시도할 수 있습니다. |
같은 호스트에 여러 서버를 붙여도 프로토콜 단위는 서버마다 따로 협상합니다. 도구가 없어도 리소스만 제공하는 서버는 검색·인용 용도로 쓰입니다.
MCP 서버 연동 준비와 설정 절차
(출처: 개발동생)
연동 전에 Host 앱이 MCP 클라이언트를 지원하는지부터 확인합니다. 로컬이면 실행 파일 경로와 인자, 작업 디렉터리를 준비하고, 원격이면 Streamable HTTP URL과 인가 방식을 적어둡니다. 레거시 원격 서버는 Streamable HTTP가 실패하면 구 SSE 전송으로 폴백할 수 있습니다. 초기화 타임아웃은 서버 기동 시간보다 길게 잡고, 실패 시 재시도 횟수를 제한합니다.
설정 값은 팀 저장소에 올리기 전에 시크릿이 섞였는지 한 번 더 검토합니다. 전송이 정해지면 방화벽과 프록시가 MCP 엔드포인트와 stdio 자식 프로세스를 막지 않는지 확인합니다. 문서에 서버별 담당자와 재시작 방법을 적어 두면 장애 때 헤매지 않습니다. 개발용과 운영용 설정을 파일로 나눠 실수 호출을 줄입니다.
클라이언트 설정과 서버 등록
클라이언트 설정에는 서버 이름, 전송 종류, 명령 또는 URL을 넣습니다. stdio라면 커맨드와 인자를 등록하고, HTTP라면 엔드포인트만 지정합니다. 시크릿은 설정 파일에 평문으로 남기지 말고 환경 변수나 OS 키체인으로 넘깁니다.
등록 직후 능력 협상 결과를 로그에서 확인하십시오. 여러 서버를 한 Host에 붙일 때는 도구 이름이 겹치지 않게 접두어를 둡니다. 불필요한 서버는 꺼 두어 모델이 엉뚱한 도구를 고르지 않게 합니다. 도구 목록이 과하면 호출 실수가 늘므로 업무에 필요한 서버만 활성화합니다.
명령 인자에 사용자 홈 전체를 넘기지 말고 프로젝트 경로만 허용합니다. 원격 URL은 https만 쓰고, 자체 서명이면 인증서 지문을 별도로 고정합니다. Windows에서는 실행 파일 확장자와 작업 디렉터리 구분자도 함께 검증합니다.
연결 확인과 도구 호출 테스트
연결이 열리면 initialize 응답과 서버 능력 목록이 와야 합니다. Resources와 Prompts, Tools가 비어 있지 않은지 클라이언트 화면에서 확인합니다. 이어서 읽기 전용 도구부터 호출하고, 쓰기 도구는 테스트 계정에서만 실행합니다.
호출이 실패하면 전송 계층과 JSON-RPC 오류 코드를 구분해 봅니다. 타임아웃과 프로세스 종료, HTTP 401은 원인이 다르므로 로그를 구간별로 남기십시오. 같은 도구를 두 번 연속 호출해 상태 유지 세션이 끊기지 않았는지도 점검합니다.
테스트 입출력은 개인정보가 없는 샘플만 사용합니다. 대용량 리소스 읽기는 제한 시간을 두고, 실패 시 부분 결과와 전체 실패를 구분합니다. 도구 스키마의 필수 항목이 비면 클라이언트가 호출을 막을 수 있게 합니다. 샘플 데이터가 준비되지 않으면 호출 테스트를 미루십시오.
연동 후 권한·보안·장애 대응 포인트
원격 HTTP MCP의 인가는 OAuth 2.1 관례를 따르며 인가 코드와 PKCE로 액세스 토큰을 받습니다. 서버는 리소스 서버로서 토큰을 검증합니다. 미인증 연결에는 401과 WWW-Authenticate의 resource_metadata로 Protected Resource Metadata 위치를 알려 클라이언트가 인가 서버를 찾게 합니다.
토큰이 만료되면 재인가 전까지 도구 호출이 거절되므로 만료 시각을 클라이언트에 표시합니다. 로컬 stdio 서버라도 자식 프로세스가 사용자 파일에 접근할 수 있어 Host 앱의 권한 프롬프트를 끄지 마십시오.
인가 서버와 리소스 서버의 식별자가 어긋나면 토큰이 거부되므로 발급 audience를 서버 문서와 맞춥니다. 리다이렉트 URI는 등록된 값만 허용합니다.
접근 권한과 시크릿 관리
도구 권한은 최소 범위로 둡니다. 파일 서버라면 작업 폴더만 열고, 메일·캘린더 도구는 읽기만 허용한 뒤 필요할 때 쓰기를 켭니다. 토큰과 API 키는 만료 시간을 짧게 하고, 유출 시 즉시 폐기할 수 있게 발급처를 기록합니다.
장애 때는 서버 프로세스 생존, 엔드포인트 응답, 토큰 만료를 순서대로 봅니다. 능력 협상이 바뀌면 클라이언트를 재시작해 도구 목록을 다시 받으십시오. 감사 로그에 도구 이름과 시각, 성공 여부를 남기면 사고 범위를 빨리 좁힐 수 있습니다. 권한 변경 뒤에는 반드시 한 번 더 도구 호출로 허용 범위를 확인합니다.
읽기 도구와 쓰기 도구를 다른 서버로 나누면 실수 범위를 줄일 수 있습니다. 만료된 토큰은 디스크 캐시에 남기지 말고 메모리에서만 잠시 보관합니다. 공유 PC에서는 로컬 서버 등록을 사용자 프로필 단위로 분리합니다.
MCP 서버 연동 핵심 정리
MCP 서버 연동은 Host·Client·Server 역할과 JSON-RPC 2.0, stdio 또는 Streamable HTTP 전송을 맞추는 일입니다. 설정 후 능력 협상과 도구 호출을 확인하고, 원격이면 OAuth 2.1과 PKCE, 401 메타데이터 흐름까지 점검합니다. 권한은 최소로 두고 시크릿은 설정 파일 밖으로 분리해 보관하십시오.
운영 단계에서는 레거시 SSE 폴백 여부와 로그 구간을 내부 문서에 남깁니다. 새 서버를 추가할 때도 같은 점검 순서를 반복하면 연결 사고가 줄어듭니다. 전송 방식과 인가 절차가 바뀌면 클라이언트 버전과 서버 능력을 다시 대조하십시오.
점검 순서는 전송 확인, 인가 확인, 최소 권한 확인, 도구 호출 확인입니다. 이 순서를 체크리스트로 고정하면 담당자가 바뀌어도 같은 품질을 유지할 수 있습니다. 서버 목록 문서도 함께 갱신합니다.
