클로드 코드 MCP 사용법: 외부 도구 연결을 안전하게 시작하는 팁

TL;DR

클로드 코드 MCP 사용법의 핵심은 "도구를 많이 붙이는 것"이 아니라, 신뢰할 수 있는 서버 하나를 좁은 범위로 연결하고 권한 요청을 확인하면서 넓혀 가는 것입니다.

Anthropic의 Claude Code 문서에 따르면 MCP는 클로드 코드가 이슈 트래커, 모니터링 도구, 데이터베이스, 브라우저 같은 외부 도구와 데이터를 사용할 수 있게 해 주는 표준 연결 방식입니다. 서버는 claude mcp add로 추가하고, claude mcp list와 /mcp에서 연결 상태와 인증 상태를 확인합니다.

처음에는 local scope로 시작하고, 읽기 전용 질문부터 테스트하세요. project scope의 .mcp.json은 팀과 공유할 수 있지만, 팀원이 첫 사용 때 승인해야 하며 민감한 토큰을 저장소에 넣지 않도록 특히 조심해야 합니다.

핵심 3줄 요약

• 핵심 1
  MCP는 클로드 코드가 외부 도구와 데이터를 다루게 해 주는 연결 표준입니다. 반복해서 복사해 붙여 넣던 이슈, 로그, 문서, 브라우저 확인 작업을 줄일 수 있습니다.
• 핵심 2
  실전 순서는 사용 목적 정하기, 서버 신뢰도 확인, local scope로 추가, claude mcp list 확인, /mcp 인증, 첫 도구 호출 권한 검토입니다.
• 핵심 3
  MCP 서버는 실제 계정과 데이터에 접근할 수 있으므로 project scope 공유, OAuth 인증, 토큰 관리, MCP tool 권한 규칙을 발행 전보다 더 엄격하게 봐야 합니다.

이 글에서 다룰 내용

클로드 코드 MCP란 무엇인가요?

MCP는 Model Context Protocol의 줄임말입니다. 쉽게 말해 AI 앱과 외부 도구를 연결하는 공통 규격입니다. 클로드 코드에서는 이 규격을 통해 이슈 트래커, 모니터링 대시보드, 데이터베이스, 브라우저, 문서 저장소 같은 도구를 작업 흐름 안으로 가져올 수 있습니다.

클로드 코드가 기본으로 파일 읽기, 편집, 명령 실행을 할 수 있다면, MCP는 그 바깥의 업무 시스템까지 연결하는 통로에 가깝습니다. 예를 들어 "이 에러와 관련된 최근 이슈를 찾아줘", "Sentry의 최근 오류를 보고 원인을 좁혀줘", "브라우저로 화면을 확인하고 접근성 문제를 찾아줘" 같은 요청을 더 자연스럽게 처리할 수 있습니다.

다만 MCP는 편의 기능만은 아닙니다. 연결한 서버가 실제 계정, 내부 문서, 로그, 데이터베이스, 외부 API에 접근할 수 있습니다. 그래서 처음부터 여러 서버를 한꺼번에 붙이기보다, 필요한 작업 하나를 정하고 신뢰할 수 있는 서버부터 좁게 열어야 합니다.

한 문장 정리: 클로드 코드 MCP는 클로드 코드가 외부 업무 도구를 사용할 수 있게 하는 연결 방식이며, 연결 범위와 권한 검토가 사용성만큼 중요합니다.

누가 쓰면 좋은가요?

클로드 코드 MCP는 개발자만을 위한 기능처럼 보이지만, 실제로는 반복적인 확인 작업이 많은 팀에 유용합니다. 코드 작업 중 이슈 트래커, 로그, 문서, 브라우저 화면을 계속 오가는 사람이라면 먼저 검토할 만합니다.

첫째, 제품 개발자와 엔지니어에게 잘 맞습니다. GitHub 이슈, 오류 추적 도구, 문서, 테스트 브라우저를 오가며 원인을 찾는 시간이 많다면 MCP 서버 하나만 연결해도 맥락 전환이 줄어듭니다.

둘째, 테크니컬 PM이나 운영 담당자도 쓸 수 있습니다. 버그 리포트, 릴리즈 노트, 고객 문의, 모니터링 알림을 연결해 "무엇이 바뀌었는지"와 "어디를 먼저 봐야 하는지"를 정리하는 데 도움이 됩니다.

셋째, 감자나라ai님처럼 AI 도구 활용법을 정리하거나 자동화 흐름을 운영하는 사람에게도 좋습니다. 공식 문서 확인, 브라우저 검증, 이슈 정리, 작업 로그 확인을 클로드 코드 안에서 묶으면 원고 작성이나 QA 전에 확인해야 할 항목이 덜 흩어집니다.

핵심 인사이트: MCP는 "AI가 더 똑똑해지는 기능"이라기보다, AI가 확인할 수 있는 업무 창구를 늘리는 기능입니다.

언제 쓰면 효과적인가요?

MCP는 매번 같은 도구를 열어 같은 정보를 확인할 때 효과가 큽니다. 한 번만 볼 자료라면 브라우저나 앱을 직접 여는 편이 더 빠를 수 있습니다. 반대로 매일 같은 이슈, 로그, 문서, 테스트 화면을 확인한다면 MCP 연결이 시간을 줄여 줍니다.

예를 들어 이런 상황에 잘 맞습니다.

1. 버그 수정 전에 관련 이슈와 최근 로그를 함께 확인해야 할 때
2. PR을 보기 전에 제품 문서나 릴리즈 노트를 같이 참고해야 할 때
3. 브라우저 화면을 열어 실제 UI 동작을 확인해야 할 때
4. 반복되는 운영 알림을 보고 원인 후보를 정리해야 할 때
5. 팀원이 같은 MCP 서버 설정을 프로젝트 단위로 공유해야 할 때

반대로 민감한 고객 데이터, 결제 정보, 개인정보가 섞인 도구는 처음부터 연결하지 않는 편이 안전합니다. 꼭 필요하다면 읽기 전용 범위, 테스트 계정, 최소 권한을 먼저 준비해야 합니다.

주의: MCP 연결이 가능하다는 사실과 업무에 바로 연결해도 된다는 판단은 다릅니다. 계정 권한, 데이터 범위, 팀 승인 절차를 먼저 정하세요.

처음 연결할 때의 안전한 순서

처음에는 "편한 서버"보다 "검증하기 쉬운 서버"를 고르세요. 공식 문서나 신뢰할 수 있는 배포 경로가 있고, 어떤 도구를 제공하는지 설명이 명확한 서버가 좋습니다.

1. 먼저 사용 목적을 한 문장으로 적습니다. 예를 들어 "클로드 코드에서 공식 문서를 찾아 명령어 사용법을 확인한다"처럼 범위를 좁힙니다.
2. 서버 출처를 확인합니다. 공식 문서, 공식 GitHub, 제품 문서, 배포자 정보를 봅니다. 출처가 불분명한 서버는 업무 계정에 붙이지 않습니다.
3. local scope로 추가합니다. Claude Code quickstart의 예시는 claude mcp add –transport http claude-code-docs https://code.claude.com/docs/mcp 입니다.
4. claude mcp list를 실행해 상태를 확인합니다. connected, needs auth, failed, pending approval 같은 상태를 보고 다음 행동을 정합니다.
5. 클로드 코드 세션 안에서 /mcp를 열어 인증과 연결 상태를 확인합니다. OAuth가 필요한 서버는 여기서 브라우저 인증을 진행할 수 있습니다.
6. 첫 질문은 읽기 전용으로 시작합니다. "최근 항목을 요약해줘"처럼 안전한 확인 요청을 먼저 보내고, 어떤 MCP tool을 호출하려는지 권한 창을 살핍니다.
7. 필요 없어진 서버는 claude mcp remove로 제거합니다. 연결한 뒤 쓰지 않는 서버가 남아 있으면 권한 관리가 어려워집니다.

이 순서를 지키면 MCP가 실패했을 때도 원인을 좁히기 쉽습니다. 인증 문제인지, 서버 연결 문제인지, 도구 호출 권한 문제인지 구분할 수 있기 때문입니다.

실전 팁: MCP 첫 연결은 "읽기 가능한 공식 문서 서버"처럼 위험이 낮은 대상으로 연습하세요. 외부 계정 쓰기 권한이 있는 서버는 마지막에 붙이는 편이 안전합니다.

local, project, user scope는 어떻게 고르나요?

Claude Code quickstart는 MCP 서버 scope를 local, project, user로 나누어 설명합니다. 초보자는 이 차이를 먼저 이해해야 합니다. 같은 서버라도 scope 선택에 따라 저장 위치와 공유 범위가 달라집니다.

local scope는 기본값입니다. 현재 프로젝트 안에서만 개인적으로 쓰는 설정입니다. 처음 테스트하거나 혼자 쓰는 서버라면 local scope가 가장 무난합니다.

user scope는 내 계정의 여러 프로젝트에서 개인적으로 쓰는 설정입니다. 여러 저장소에서 같은 도구를 반복해서 쓴다면 편합니다. 다만 모든 프로젝트에서 보이므로, 업무별로 분리해야 하는 계정이나 데이터라면 신중하게 선택해야 합니다.

project scope는 팀과 공유하는 설정입니다. 이 경우 .mcp.json 파일에 서버 설정이 들어가고, 팀원이 처음 사용할 때 승인해야 합니다. 프로젝트 전체에서 같은 서버를 쓰는 장점이 있지만, 민감한 토큰이나 개인 계정 정보가 파일에 들어가면 안 됩니다.

한 줄 정리: 혼자 처음 테스트할 때는 local, 여러 개인 프로젝트에서 반복해서 쓸 때는 user, 팀 표준 설정으로 공유할 때만 project를 고르세요.

권한 승인은 어디를 봐야 하나요?

Anthropic의 보안 문서는 클로드 코드가 기본적으로 읽기 전용이며, 파일 수정, 테스트 실행, 명령 실행처럼 시스템을 바꿀 수 있는 행동은 명시적 권한을 요구한다고 설명합니다. MCP도 마찬가지로 실제 도구 호출 전 권한 요청을 확인해야 합니다.

권한 창에서 봐야 할 것은 세 가지입니다. 어느 서버의 도구인지, 어떤 작업을 하려는지, 읽기인지 쓰기인지입니다. 서버 이름이 낯설거나 작업 설명이 예상보다 넓다면 승인하지 말고 중단하세요.

Claude Code permissions 문서에 따르면 MCP tool은 mcp__서버이름__도구이름 형태의 규칙으로 다룰 수 있습니다. 예를 들어 모든 MCP tool을 막고 싶다면 mcp__*를 deny 규칙으로 둘 수 있고, 특정 서버만 허용하려면 서버 이름을 포함한 규칙을 사용할 수 있습니다. deny 규칙은 allow보다 우선합니다.

초기 운영에서는 "자동 허용"보다 "물어보기" 상태가 낫습니다. 반복 작업이 충분히 검증된 뒤에만 일부 읽기 도구를 허용하고, 쓰기나 외부 변경을 만드는 도구는 계속 승인 방식으로 남겨 두는 편이 안전합니다.

주의: MCP 서버 출력에는 프롬프트 인젝션 위험이 섞일 수 있습니다. 외부 도구에서 가져온 텍스트가 "이전 지시를 무시하라" 같은 문장을 포함할 수 있으므로, 서버 신뢰도와 출력 내용을 함께 봐야 합니다.

실전 설정 팁

첫째, 서버 이름을 업무 목적에 맞게 붙이세요. docs, sentry, playwright처럼 짧고 구분되는 이름이 좋습니다. 나중에 권한 규칙을 만들 때 서버 이름이 기준이 됩니다.

둘째, 연결 상태를 글로 남기세요. 서버를 추가한 날짜, scope, 인증 방식, 쓰는 목적, 제거 기준을 간단히 적어 두면 팀원이 이어받기 쉽습니다.

셋째, OAuth 인증과 토큰 인증을 구분하세요. OAuth가 필요한 서버는 /mcp에서 인증 흐름을 확인하고, 토큰을 직접 넣어야 하는 서버는 저장 위치와 노출 범위를 따로 점검해야 합니다.

넷째, 로컬 stdio 서버는 실행 환경을 확인하세요. Claude Code quickstart는 Playwright MCP 예시처럼 로컬 프로세스를 실행하는 방식도 보여 줍니다. 이런 서버는 Node.js, 패키지 실행, 브라우저 접근 같은 로컬 의존성이 맞아야 정상 동작합니다.

다섯째, 연결 후 바로 자동화하지 마세요. 처음 며칠은 읽기 요청과 수동 승인으로 돌려 보고, 어떤 도구가 자주 호출되는지 확인한 뒤 권한을 좁게 조정하는 편이 좋습니다.

실전 팁: MCP 서버 하나를 붙일 때마다 "이 서버가 읽을 수 있는 것", "바꿀 수 있는 것", "팀과 공유되는 것"을 세 줄로 적어 두세요.

주의할 점

가장 큰 실수는 project scope를 빨리 쓰는 것입니다. 팀 공유가 편해 보여도 .mcp.json은 저장소에 남을 수 있습니다. 서버 주소는 괜찮아도 개인 토큰, 내부 엔드포인트, 테스트 계정 정보가 섞이면 문제가 됩니다.

두 번째 실수는 "공식 MCP"라는 표현만 보고 신뢰하는 것입니다. MCP는 표준 이름이고, 서버의 품질과 권한 범위는 배포자마다 다릅니다. 공식 문서, 설치 방법, 권한 설명, 업데이트 이력을 확인해야 합니다.

세 번째 실수는 쓰기 권한을 너무 빨리 여는 것입니다. 이슈 생성, 티켓 수정, 데이터베이스 변경, 브라우저 조작처럼 외부 상태를 바꾸는 도구는 실수 비용이 큽니다. 처음에는 읽기, 검색, 요약 같은 작업부터 시작하세요.

네 번째 실수는 실패 상태를 그냥 넘기는 것입니다. claude mcp list에서 failed, needs auth, pending approval이 보이면 이유를 해결한 뒤 사용해야 합니다. 연결이 불안정한 서버를 기준으로 자동화하면 결과 검증이 어려워집니다.

한 줄 주의: MCP는 연결보다 회수가 더 중요합니다. 쓰지 않는 서버는 제거하고, 프로젝트가 끝나면 권한도 함께 정리하세요.

자주 묻는 질문

MCP를 쓰면 클로드 코드가 모든 외부 서비스를 자동으로 쓸 수 있나요?

아닙니다. MCP 서버가 준비되어 있고, 해당 서버가 필요한 도구를 제공하며, 인증과 권한 승인이 끝나야 합니다. 서비스마다 지원 범위가 다르므로 공식 문서와 서버 설명을 먼저 확인해야 합니다.

local scope로 추가하면 팀원에게 보이나요?

보이지 않습니다. local scope는 현재 프로젝트에서 개인적으로 쓰는 설정입니다. 팀과 공유하려면 project scope를 써야 하지만, 이때는 .mcp.json에 무엇이 들어가는지 반드시 확인해야 합니다.

project scope는 언제 쓰는 게 좋나요?

팀이 같은 서버를 반복해서 쓰고, 서버 주소와 설정을 공유해도 안전하며, 각 팀원이 첫 사용 승인 절차를 이해하고 있을 때 적합합니다. 개인 토큰이나 개인 계정 전용 설정은 project scope에 넣지 않는 편이 좋습니다.

권한 요청이 뜨면 무엇을 봐야 하나요?

서버 이름, 도구 이름, 작업 설명, 읽기와 쓰기 여부를 봐야 합니다. 예상하지 못한 서버나 쓰기 작업이 보이면 승인하지 말고 중단하세요.

MCP 서버가 실패하면 무엇부터 확인하나요?

claude mcp list로 상태를 확인하세요. 인증이 필요한지, 연결이 실패했는지, 승인 대기인지 먼저 나눕니다. OAuth 서버라면 /mcp에서 인증 상태를 확인하고, 로컬 stdio 서버라면 실행 환경과 패키지 설치 상태를 봅니다.

출처

마무리

클로드 코드 MCP는 제대로 쓰면 작업 흐름을 크게 줄여 줍니다. 이슈, 로그, 문서, 브라우저를 오가던 시간을 줄이고, 클로드 코드가 필요한 정보를 직접 확인하게 만들 수 있습니다.

다만 시작점은 작아야 합니다. 서버 하나, local scope, 읽기 전용 질문, 수동 권한 승인부터 시작하세요. 그다음 실제로 반복 가치가 확인된 서버만 project scope나 user scope로 넓히면 됩니다. MCP는 연결 기능이지만, 운영에서는 권한 관리 기능으로 봐야 오래 안전하게 쓸 수 있습니다.