MCP 처음 연결하기: AI 코딩 도구에 도구를 붙이는 법

AI 코딩 도구를 쓰다 보면 한 가지 한계를 만납니다. 코드는 잘 만들어 주는데, 정작 내 데이터베이스나 사내 문서, 외부 서비스의 정보에는 닿지 못한다는 점입니다. 그때마다 내용을 복사해 붙여 넣는 것도 한두 번이지, 반복되면 번거롭습니다. MCP(Model Context Protocol)는 바로 이 “AI 도구를 외부 세계에 연결하는 방식”을 표준화하기 위한 규약입니다. 이 글은 특정 도구의 설정 화면을 따라가는 안내가 아니라, 처음 연결할 때 알아 두면 좋은 개념과 흐름을 정리한 것입니다.

MCP가 무엇인가

MCP는 Model Context Protocol의 약자로, AI 모델(정확히는 AI 도구)이 외부 도구·데이터 소스와 통신하는 방법을 정해 둔 공통 규약입니다. 핵심 아이디어는 단순합니다. 도구마다 제각각인 연결 방식을 매번 새로 만들지 말고, 하나의 표준 인터페이스로 주고받자는 것입니다.

비유하자면 USB 같은 표준 단자에 가깝습니다. 예전에는 기기마다 전용 케이블이 필요했지만, 표준 단자가 생기면서 어떤 기기든 같은 방식으로 연결됩니다. MCP도 마찬가지로, AI 도구(클라이언트)와 외부 기능을 제공하는 쪽(MCP 서버) 사이를 표준화된 약속으로 잇습니다.

클라이언트와 서버

• 클라이언트: Claude Code 같은 AI 코딩 도구. 사용자가 직접 다루는 쪽입니다.
• MCP 서버: 특정 기능이나 데이터를 표준 방식으로 노출하는 작은 프로그램. 파일 검색, 데이터베이스 조회, 외부 API 호출 등을 담당합니다.

클라이언트가 서버에게 “어떤 도구를 제공하니?”라고 묻고, 서버가 목록을 내려 주면, AI가 필요할 때 그 도구를 골라 쓰는 구조입니다.

왜 쓰는가

MCP를 쓰는 이유는 결국 연결의 재사용입니다. 한번 표준에 맞춰 만들어 두면, 그 서버를 지원하는 여러 AI 도구에서 같은 방식으로 붙여 쓸 수 있습니다. 도구를 바꿔도 연결 자산이 통째로 사라지지 않습니다.

또 하나는 맥락의 확장입니다. AI가 내 작업 환경의 실제 데이터를 참조할 수 있으면, 막연한 일반론 대신 내 상황에 맞는 답을 내놓기 쉬워집니다. 다만 이 장점은 곧 권한 문제와 직결되므로, 뒤에서 다시 짚겠습니다.

일반적인 연결 흐름

도구마다 화면과 명령은 다르지만, 큰 흐름은 비슷합니다.

1. 연결할 MCP 서버를 고른다. 공식·공개된 서버인지, 무엇을 할 수 있는지 먼저 확인합니다.
2. 설정 파일에 서버를 등록한다. 보통 AI 도구의 설정 파일에 서버 이름과 실행 방식을 적어 두는 형태입니다.
3. AI 도구를 재시작하거나 다시 불러온다. 등록한 내용을 도구가 읽어 들이게 합니다.
4. 연결을 확인한다. 도구가 그 서버와 제공 도구 목록을 정상 인식하는지 봅니다.

# 개념 예시일 뿐 — 실제 키 이름·플래그는 도구/버전마다 다릅니다.
# 반드시 사용 중인 AI 도구의 공식 문서를 기준으로 하세요.
your-ai-tool mcp list      # 등록된 MCP 서버 목록 확인(개념)
your-ai-tool mcp status    # 연결 상태 확인(개념)

위 명령은 형식을 단정하는 것이 아니라 “이런 단계가 있다”는 개념 예시입니다. your-ai-tool 자리에 실제 도구 이름이 들어가며, 하위 명령과 설정 파일의 구조는 도구마다 다릅니다.

연결이 됐는지 확인하기

등록만 하고 끝내면 안 됩니다. 도구가 그 서버를 실제로 인식하는지, 서버가 제공한다고 한 기능 목록이 보이는지 확인해야 합니다. 대개 AI 도구에는 연결된 MCP 서버와 사용 가능한 도구를 보여 주는 화면이나 명령이 있습니다. 여기서 서버가 보이지 않거나 오류로 표시된다면, 설정 파일의 경로·이름·실행 방식 중 하나가 어긋난 경우가 많습니다.

권한과 범위를 의식해야 하는 이유

MCP 서버는 종종 내 파일, 데이터베이스, 외부 서비스에 접근할 수 있는 권한을 갖습니다. 이는 편리함의 원천이자 동시에 위험의 원천입니다.

• 최소 권한 원칙: 서버에 꼭 필요한 만큼만 접근 범위를 주세요. 모든 디렉터리, 모든 데이터에 닿게 할 이유는 없습니다.
• 출처 확인: 신뢰할 수 없는 곳에서 받은 서버는 신중히 다루세요. 외부 코드를 내 환경 권한으로 실행하는 셈입니다.
• AI의 행동 검토: AI가 MCP 도구를 통해 파일을 바꾸거나 외부에 요청을 보낼 수 있습니다. 자동 실행 범위를 어디까지 허용할지 스스로 정해 두세요.

인증과 포트포워딩에서 자주 막힌다

원격 환경(예: WSL이나 서버)에서 MCP 서버를 붙일 때 가장 흔한 막힘 지점이 인증입니다.

• OAuth 흐름: 외부 서비스에 OAuth로 로그인하는 서버라면, 브라우저로 인증 페이지가 열리는 단계가 있습니다. 그런데 원격·헤드리스 환경에서는 그 브라우저 창이 자동으로 열리지 않아 멈춘 것처럼 보일 수 있습니다. 안내에 나온 URL을 직접 열어 인증을 마쳐야 할 때가 많습니다.
• 포트포워딩: 인증 과정이 특정 로컬 포트로 콜백을 받는 경우, 원격 환경의 그 포트가 내 PC로 전달되지 않으면 마지막 단계에서 실패합니다. SSH 포트포워딩 등으로 해당 포트를 연결해 주어야 합니다.
• 토큰·자격증명 보관: 인증 후 발급된 토큰이 어디에 저장되는지, 어떻게 만료·갱신되는지 알아 두면 “어제는 됐는데 오늘은 안 되는” 상황을 덜 겪습니다.

이 부분은 서비스와 도구마다 절차가 크게 다르므로, 막혔다면 추측으로 설정을 바꾸기보다 해당 도구·서버의 공식 문서에서 인증 절차를 다시 확인하는 편이 빠릅니다.

초보자가 자주 막히는 부분

• 설정 파일 형식을 다른 도구 기준으로 베낌 — 도구·버전마다 키 이름이 달라 그대로 쓰면 인식되지 않습니다.
• 재시작을 빼먹음 — 등록 후 도구를 다시 불러오지 않으면 새 서버가 반영되지 않습니다.
• 연결 확인을 건너뜀 — 등록만 하고 실제 인식 여부를 안 봐서, 안 되는 줄도 모른 채 시간을 씁니다.
• 인증 단계에서 멈춘 걸 오류로 오해 — 원격 환경에서 브라우저 인증이 안 열린 것을 설정 오류로 착각합니다.
• 권한 범위를 과하게 줌 — 편하다는 이유로 모든 접근을 허용해 두는 것은 위험합니다.

정리

MCP는 AI 코딩 도구를 외부 도구·데이터에 표준 방식으로 잇는 규약입니다. 연결의 흐름은 서버를 고르고, 설정 파일에 등록하고, 재시작한 뒤, 인식 여부를 확인하는 것으로 요약됩니다. 여기에 더해 권한 범위를 좁게 잡고, 원격 환경에서는 인증과 포트포워딩을 미리 챙기면 대부분의 초기 문제를 피할 수 있습니다. 다만 구체적인 설정 형식과 명령은 도구·버전마다 다르므로, 이 글의 개념을 바탕으로 반드시 사용 중인 도구의 공식 문서를 기준으로 실제 연결을 진행하세요.