MCP(Model Context Protocol)란? 개발자 관점 정리와 커넥터 한 줄 연결 실습

AI에게 바깥 세상을 만지게 해본 적이 있다면, 그 작업의 8할이 배관 공사였다는 걸 아실 겁니다. 함수 스키마를 JSON으로 손으로 적고, 인자 파싱하고, 에러를 어떻게 되돌려줄지 정하고, 인증 토큰을 어디에 둘지 고민하고. 그렇게 겨우 붙여 놓으면 다른 클라이언트로 옮길 때 그 배관을 처음부터 다시 깝니다. 사내 챗봇에 붙인 사내 위키 조회 기능을, 이번엔 IDE 에이전트에서도 쓰고 싶다면 사실상 재작성입니다.

문제의 모양이 익숙합니다. 붙일 도구가 M개, 그 도구를 쓸 AI 클라이언트가 N개일 때 우리는 M×N개의 어댑터를 관리하고 있었습니다. 데이터베이스 드라이버, 에디터 플러그인, 결제 게이트웨이가 다 지나온 길이죠. 이런 문제는 늘 같은 방식으로 풀립니다. 가운데에 규격 하나를 세워 M+N으로 만드는 것.

MCP(Model Context Protocol)가 그 규격입니다. Anthropic이 공개했고, 지금은 여러 AI 클라이언트와 도구 제공자가 함께 구현하는 오픈 스펙입니다. 아래 내용은 공식 문서와 각 서비스의 발표 자료를 정리한 것이고, 연결 명령과 엔드포인트는 확인된 값만 적었습니다. 저희가 이 구성을 실서비스에 장기간 물려 운영해본 것은 아니라는 점을 먼저 밝혀 둡니다.

MCP가 실제로 정하는 것

MCP를 “AI용 USB-C”라고 비유하곤 하는데, 개발자에게는 그 비유보다 규격서가 뭘 고정했는지가 중요합니다. 큰 틀은 이렇습니다.

구분	내용
구조	클라이언트(AI 앱) ↔ 서버(도구 제공자)의 1:1 연결. 클라이언트 하나가 서버 여러 개를 동시에 물 수 있음
메시지	JSON-RPC 방식의 요청/응답 + 알림
전송	로컬 프로세스는 stdio, 원격은 HTTP 계열
서버가 제공하는 것	Tools(모델이 호출하는 동작), Resources(읽을 수 있는 데이터), Prompts(정해진 작업 템플릿)
인증	원격 서버는 OAuth 기반 인가를 쓸 수 있음 → 사용자가 로그인하면 끝, 코드에 API 키를 심지 않아도 됨

핵심은 디스커버리입니다. 클라이언트가 서버에 접속하면 서버가 “내가 가진 도구는 이런 것들이고, 인자는 이렇게 생겼다”를 스스로 알려줍니다. 그래서 도구가 늘어나도 클라이언트 코드를 고칠 일이 없습니다. 우리가 예전에 프롬프트에 하드코딩하던 함수 목록이 런타임 협상으로 옮겨간 셈입니다.

반대로 MCP가 정하지 않는 것도 분명히 해두는 게 좋습니다. 모델이 그 도구를 언제 부를지, 결과를 어떻게 해석할지는 규격 밖입니다. 권한을 어느 수준에서 물어볼지도 클라이언트 구현에 달려 있습니다. 즉 MCP는 배선 규격이지 안전장치가 아닙니다. 뒤에서 다시 이야기하겠습니다.

붙이는 데 걸리는 시간: 명령 한 줄

추상적인 설명보다 실제로 붙는 서버 하나를 보는 편이 빠릅니다. AI 영상·이미지 생성 허브인 Higgsfield가 2026년 4월 말 공식 MCP 서버를 냈는데, 구성이 단순해서 예시로 적당합니다. 엔드포인트는 https://mcp.higgsfield.ai이고 API 키가 필요 없습니다. 계정 OAuth로 인증합니다.

Claude Code라면 한 줄입니다.

claude mcp add higgsfield https://mcp.higgsfield.ai/mcp

붙었는지, 인증이 살아 있는지는 목록으로 확인합니다.

claude mcp list
claude mcp remove higgsfield   # 정리할 때

GUI 클라이언트(웹·데스크탑·모바일)에서는 설정의 커넥터 항목에 같은 주소를 커스텀 커넥터로 넣습니다. 어느 쪽이든 처음 한 번은 브라우저가 열려 로그인·동의 화면을 거치고, 그 뒤로는 토큰이 클라이언트에 저장됩니다.

팀 저장소에 공유하려면 프로젝트 루트의 설정 파일로 관리하는 편이 낫습니다. 형식은 대략 이렇습니다.

{
  "mcpServers": {
    "higgsfield": {
      "type": "http",
      "url": "https://mcp.higgsfield.ai/mcp"
    }
  }
}

이 파일을 커밋해두면 팀원은 클론 후 승인만 하면 됩니다. 다만 전송 방식 플래그나 스코프 옵션(--transport, --scope 등)은 클라이언트 버전에 따라 이름이 바뀌는 영역이라, 실행 전에 claude mcp add --help로 한 번 확인하시길 권합니다. 저희도 문서 기준으로 적은 것이라 최신 버전과 다를 수 있습니다.

연결이 끝나면 대화 안에서 도구가 호출됩니다. Higgsfield 쪽은 Veo 3.1, Sora 2, Kling 3.0, Seedance 2.0 같은 영상 모델과 Nano Banana Pro, Flux 2.0 등 이미지 모델을 한 계정으로 묶어두었기 때문에, 웹 프로젝트 작업 중에 히어로 배경 영상 소스를 그 자리에서 뽑는 식의 사용이 가능합니다. 별도 플러그인을 설치하면 After Effects 프로젝트 안에서 컴포지션·키프레임·익스프레션까지 만들게 할 수 있고, 결과가 렌더된 파일이 아니라 편집 가능한 씬으로 남습니다. 이 부분은 Higgsfield MCP 리뷰에서 더 자세히 다뤘습니다.

로컬 서버와 원격 서버, 어느 쪽을 만들 것인가

직접 MCP 서버를 만들 계획이라면 초반에 갈리는 결정이 전송 방식입니다.

stdio(로컬 프로세스) — 클라이언트가 서버를 자식 프로세스로 띄우고 표준 입출력으로 대화합니다. 로컬 파일 시스템, 사내망 DB, 로컬 CLI 래핑에 적합합니다. 배포는 각자 설치이고, 인증은 대개 로컬 환경변수로 해결합니다.
HTTP(원격) — 서버를 우리가 호스팅하고 사용자는 URL만 넣습니다. Higgsfield처럼 계정이 있는 SaaS라면 이쪽입니다. 대신 인가·레이트리밋·멀티테넌시를 직접 책임져야 합니다.

사내 도구를 붙이는 목적이라면 stdio로 시작해 필요할 때 HTTP로 옮기는 순서가 편합니다. 반대로 외부 고객에게 배포할 제품이라면 처음부터 원격 + OAuth가 맞습니다. 사용자에게 API 키 발급·보관을 시키지 않는 것만으로 도입 마찰이 눈에 띄게 줄어듭니다. Higgsfield가 “API 키 불필요”를 앞세우는 이유도 같은 맥락으로 보입니다.

도구를 설계할 때의 실무 팁도 하나 적어둡니다. 도구 이름과 설명(description)은 사람이 읽는 주석이 아니라 모델이 읽는 유일한 사양서입니다. getData 같은 이름과 한 줄짜리 설명을 주면 모델은 엉뚱한 타이밍에 그 도구를 부릅니다. 인자 제약과 실패 조건까지 설명에 적어두면 호출 정확도가 달라집니다.

커넥터 권한: 사고는 대부분 여기서 납니다

MCP를 붙이는 건 쉽고, 위험한 것도 쉽다는 점이 이 규격의 양면입니다. 붙이기 전에 확인할 항목들입니다.

1. 서버 출처를 확인하세요. MCP 서버는 결국 우리 컴퓨터나 우리 계정에서 뭔가를 실행하는 코드입니다. 공식 도메인인지, 커뮤니티가 올린 래퍼인지 구분해야 합니다. 로컬 서버는 임의의 프로세스를 띄우는 것과 같으니 더 그렇습니다.

2. ‘항상 허용’을 기본값으로 만들지 마세요. 매번 승인 창이 뜨면 귀찮아서 전체 허용으로 열게 되는데, 이 순간 파일을 수정하거나 과금을 발생시키는 도구까지 무승인 상태가 됩니다. 읽기 전용 도구만 허용하고 쓰기·결제·삭제는 매번 확인하는 편이 낫습니다.

3. 과금형 서버는 잔량부터 확인하세요. Higgsfield는 크레딧제입니다. 신규 가입 시 무료 크레딧을 주지만 모델마다 소모량이 다르고, 긴 작업 도중 크레딧이 떨어져 멈추는 사례가 보고돼 있습니다. AI가 도구를 자동으로 반복 호출할 수 있는 구조에서는 이게 곧 비용 사고로 이어집니다. 요금 체계는 변동이 잦으니 시작 전에 공식 페이지에서 확인하세요.

4. 도구 결과는 신뢰할 수 없는 입력으로 취급하세요. 서버가 돌려주는 텍스트는 그대로 모델의 컨텍스트에 들어갑니다. 외부 문서·웹페이지·이슈 트래커를 읽는 서버라면, 그 안에 모델을 향한 지시문이 섞여 있을 수 있습니다. 프롬프트 인젝션의 표면이 도구 개수만큼 늘어난다고 보면 됩니다.

5. 안 쓰는 커넥터는 끊으세요. OAuth로 연결한 서버는 계정 쪽에 인가가 남습니다. 테스트로 붙였다 잊은 커넥터가 제일 위험합니다. 클라이언트에서 제거하는 것과 서비스 계정에서 인가를 회수하는 것은 별개 작업입니다.

6. 중요한 파일은 사본에서 작업시키세요. 로컬 파일이나 디자인 프로젝트를 직접 조작하는 서버라면 특히 그렇습니다. 되돌리기가 되는 환경(git, 사본 폴더)에서만 붙이는 게 안전합니다.

점수: 8.4

이 점수는 공개된 규격 문서와 실제 커넥터 구성 방식을 기준으로 한 평가입니다. 저희가 MCP 서버를 직접 개발해 운영하거나, 유료 크레딧을 태워 장기간 사용해본 결과는 아닙니다. 그 부분이 확인되면 갱신하겠습니다.

좋은 점

도구 하나를 만들어두면 지원하는 클라이언트 어디서나 재사용됩니다. M×N 어댑터 관리에서 벗어나는 효과가 실제로 큽니다.
원격 서버 + OAuth 조합이면 사용자가 API 키를 만들고 보관할 일이 없습니다. 도입 마찰이 줄고, 키 유출 표면도 줄어듭니다.
붙이는 비용이 낮습니다. claude mcp add <이름> <URL> 한 줄이면 끝나는 서버가 늘고 있어서, 시험 삼아 붙였다 빼는 실험이 부담 없습니다.
도구 목록을 런타임에 협상하므로 서버 쪽 기능이 늘어도 클라이언트 코드를 손대지 않습니다.

아쉬운 점

규격이 빠르게 개정되고 있습니다. 전송 방식·인증 관련 세부가 버전에 따라 다르고, CLI 플래그 이름도 바뀝니다. 블로그 글에 적힌 명령이 몇 달 뒤엔 안 먹을 수 있어 공식 문서 확인이 매번 필요합니다.
클라이언트마다 구현 범위가 다릅니다. 규격에 있는 기능이라고 해서 내가 쓰는 앱에서 동작한다는 보장은 없습니다.
보안 책임이 사용자에게 넘어와 있습니다. 규격은 배선만 정할 뿐, 어떤 도구를 어디까지 허용할지 판단하는 건 사람 몫입니다. 승인 피로가 쌓이면 전체 허용으로 흐르기 쉽다는 구조적 약점이 있습니다.
서버 품질 편차가 큽니다. 도구 설명이 부실한 서버를 붙이면 모델이 오작동하는데, 그 원인을 추적하기가 생각보다 까다롭습니다.

이럴 때 쓰세요: 같은 도구를 여러 AI 클라이언트에서 반복해 쓰게 될 때, 또는 SaaS를 만들면서 사용자가 자기 AI 앱에서 우리 기능을 부르게 하고 싶을 때. 반대로 단일 앱 안에서 한 번 쓰고 말 함수라면 기존 함수 호출로 충분합니다. 굳이 서버를 세울 이유가 없습니다.