AI에 외부 도구 붙이기, MCP 연동 사용법

클로드나 챗GPT에 사내 데이터베이스나 깃허브 저장소를 매번 복사·붙여넣기로 전달하는 게 번거롭다면, MCP 연동으로 이 과정을 자동화할 수 있습니다. MCP(Model Context Protocol)는 AI 모델이 외부 도구·데이터에 표준화된 방식으로 접근하게 해주는 프로토콜입니다. 이 글에서는 MCP가 무엇인지부터 실제 설정 파일이 어떻게 생겼는지, 그리고 써 보면 걸리는 지점까지 정리했습니다.

2026년 8월 2일 실사용 확인: 이 글의 설정 예시와 실패 사례는 MCP 서버 7개(로컬 4 + 원격 3)를 붙여 쓰고 있는 환경에서 확인한 것입니다. 클라이언트마다 설정 파일 위치와 문법이 다르므로 실제 적용 전에는 쓰는 도구의 공식 문서를 함께 보시기 바랍니다.

이 글은 이런 분께 추천합니다: AI 코딩 도구를 업무에 연결하려는 개발자, 사내 시스템에 AI 에이전트를 붙이는 걸 검토 중인 파워유저.

MCP(Model Context Protocol)가 정확히 무엇인가

MCP는 Anthropic이 처음 공개한 오픈 프로토콜로, AI 모델이 파일시스템·데이터베이스·API 같은 외부 시스템에 접근할 때 쓰는 방식을 표준화한 것입니다. 공식 문서는 이를 “AI 애플리케이션을 외부 시스템에 연결하는 오픈소스 표준”으로 정의합니다. 비유로는 USB-C 포트를 씁니다. 이전에는 AI를 특정 도구와 연결하려면 그 조합에 맞춘 연동 코드를 매번 새로 짜야 했지만, MCP 연동을 쓰면 도구 쪽에서 표준 규격에 맞춰 “MCP 서버”를 하나 만들어두는 것만으로 여러 AI 클라이언트가 동일한 방식으로 접근할 수 있습니다.

공개 이후 클로드뿐 아니라 Cursor 같은 AI 코딩 에디터, 그 외 여러 AI 도구들이 잇따라 MCP 지원을 발표하면서 사실상 업계 표준에 가까운 위치로 확산되는 흐름입니다. USB 같은 물리적 표준 규격이 각기 다른 기기와 컴퓨터를 하나의 포트로 연결해주는 것처럼, MCP는 각기 다른 AI 모델과 도구를 하나의 통신 규격으로 연결해준다고 이해하면 됩니다.

MCP 서버가 필요한 이유: 연동을 매번 새로 만들지 않아도 된다

MCP 구조는 크게 두 축으로 나뉩니다. MCP 클라이언트는 클로드 데스크톱, Cursor처럼 AI 모델을 실제로 실행하는 애플리케이션입니다. MCP 서버는 특정 도구나 데이터 소스에 대한 접근을 표준 방식으로 노출해주는 프로그램입니다. AI 개발사나 오픈소스 커뮤니티가 파일시스템용, 데이터베이스용, Slack용처럼 도구별로 MCP 서버를 미리 만들어 공개해두면, 사용자는 이걸 자신의 MCP 클라이언트에 등록하기만 하면 됩니다.

이 구조가 없던 시절에는 “AI를 슬랙과 연결”하고 싶으면 슬랙 API 문서를 직접 읽고, 인증 처리를 짜고, AI 모델이 그 결과를 이해하도록 프롬프트를 다듬는 작업을 각 프로젝트마다 반복해야 했습니다. MCP 연동 방식에서는 이 작업을 서버 개발자가 한 번만 표준에 맞춰 해두면, 이후 어떤 MCP 클라이언트에서도 같은 서버를 그대로 재사용할 수 있어 중복 개발이 크게 줄어듭니다.

실전 활용 시나리오: 파일시스템·데이터베이스·협업 도구

로컬 파일시스템 연결: 파일시스템용 MCP 서버를 등록하면 AI가 지정된 폴더 안의 파일을 직접 읽고 수정 초안을 제안할 수 있습니다. 코드 리팩터링이나 문서 정리처럼 여러 파일을 오가며 맥락을 파악해야 하는 작업에서, 매번 파일 내용을 손으로 복사해 붙여넣지 않아도 되는 게 가장 큰 차이입니다.

사내 데이터베이스 연결: 데이터베이스용 MCP 서버를 붙이면 SQL을 직접 몰라도 자연어로 질의하고 AI가 그 결과를 요약해주는 흐름을 만들 수 있습니다. 다만 이 경우는 실수로 데이터를 바꾸거나 지우는 사고를 막기 위해 읽기 전용 계정으로 연결하는 것이 안전합니다.

Slack·GitHub 같은 협업 도구 연결: Slack MCP 서버를 등록하면 AI가 특정 채널의 최근 논의를 요약하거나 메시지 초안을 대신 작성해줄 수 있고, GitHub MCP 서버를 연결하면 이슈를 조회하거나 PR 상태를 확인하는 작업을 대화형으로 처리할 수 있습니다. 여러 개발자가 반복하던 상태 확인 루틴을 AI에게 위임하는 식입니다.

MCP 서버를 연결하는 기본 흐름

이미 만들어진 MCP 서버를 쓰는 게 일반적인 시작 방식입니다. 오픈소스로 공개된 MCP 서버들을 검색해 필요한 도구(파일시스템, 데이터베이스, Slack, GitHub 등)에 해당하는 서버를 찾고, 사용 중인 MCP 클라이언트(클로드 데스크톱, Cursor 등)의 설정 파일에 그 서버의 실행 정보를 등록하는 방식으로 연결합니다.

전체 흐름은 대략 이렇게 정리됩니다.

1. 연결하고 싶은 도구(예: 파일시스템, Slack)에 맞는 MCP 서버를 찾습니다.
2. 그 서버가 필요로 하는 인증 정보(API 키, 접근 토큰 등)를 준비합니다.
3. MCP 클라이언트의 설정 파일에 서버 이름, 실행 방법, 인증 정보, 접근을 허용할 범위(예: 특정 폴더 경로)를 등록합니다.
4. 클라이언트를 재시작하면 AI가 등록된 MCP 서버의 기능을 대화 중에 도구로 인식하고 호출할 수 있게 됩니다.

세부 설정 항목이나 문법은 클라이언트와 서버마다 조금씩 다르므로, 실제로 설정할 때는 사용 중인 도구와 서버 각각의 공식 문서를 그 시점 기준으로 확인하는 것이 정확합니다.

설정 파일은 실제로 이렇게 생겼습니다

서버 등록 방식은 크게 두 가지입니다. 로컬에서 프로세스로 띄우는 방식(stdio)과 원격 주소에 붙는 방식(http)입니다. 실제로 쓰고 있는 설정을 형태만 남기고 옮기면 이렇습니다.

{
  "mcpServers": {
    "filesystem": {
      "command": "/opt/homebrew/bin/npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/<사용자>/프로젝트/blogs",
        "/Users/<사용자>/Documents/Obsidian"
      ]
    },
    "firecrawl": {
      "command": "/opt/homebrew/bin/npx",
      "args": ["-y", "firecrawl-mcp"],
      "env": { "FIRECRAWL_API_KEY": "..." }
    },
    "notion": {
      "type": "http",
      "url": "https://mcp.notion.com/mcp"
    }
  }
}

여기서 세 가지가 눈에 띕니다.

첫째, command에 npx가 아니라 /opt/homebrew/bin/npx 전체 경로가 들어갑니다. 서브프로세스가 셸의 PATH를 그대로 물려받지 못합니다. npx만 적으면 서버가 뜨지 않는 경우가 있습니다. macOS에서 Homebrew로 node를 설치했다면 이 경로를 확인해 두는 편이 낫습니다.

둘째, API 키는 args가 아니라 env에 들어갑니다. 인자로 넘기면 프로세스 목록에 그대로 노출됩니다.

셋째, filesystem 서버의 마지막 두 인자가 폴더 경로입니다. 이게 다음 절에서 말할 권한 범위의 실제 구현입니다.

권한 범위를 신중하게 설정해야 하는 이유

MCP 연동에서 가장 조심해야 할 부분은 AI에게 넘겨주는 권한 범위입니다. 파일시스템 서버에서 이건 추상적인 원칙이 아니라 인자로 넘긴 경로 목록 그 자체입니다. 위 설정에서 server-filesystem 뒤에 붙은 두 경로가 허용 범위 전부고, 그 밖은 접근이 거부됩니다.

이 경계는 실제로 작동합니다. 이 블로그를 운영하는 환경에서 워드프레스 접속 정보가 담긴 .env 파일이 스코프 밖 폴더에 있습니다. MCP 파일시스템 도구로는 그 파일을 읽을 수 없습니다. 처음엔 설정 실수인 줄 알았지만 의도한 대로 동작한 것이었습니다. 자격증명 파일을 AI에게 열어준 폴더 밖에 두는 것만으로 실수로 읽히는 경로가 하나 줄어듭니다.

반대로 홈 디렉터리 전체를 인자로 넘기면 그 안의 모든 것이 범위 안에 들어옵니다. 편하지만, 실수했을 때 되돌릴 수 없는 쪽도 같이 열립니다.

데이터베이스나 협업 도구도 마찬가지입니다. 쓰기 권한까지 전부 열어둔 상태에서 AI가 프롬프트 상의 애매한 지시를 잘못 해석하면, 되돌리기 어려운 삭제나 수정 명령이 그대로 실행될 수 있습니다. 검증되지 않은 출처의 MCP 서버를 설치하는 것도 위험 요소입니다 — 서버 코드 자체가 악의적으로 만들어졌거나 취약점이 있다면, AI가 그 서버를 통해 권한 범위 안의 데이터를 외부로 유출하는 통로가 될 수 있습니다. 신뢰할 수 있는 출처의 서버만 쓰고, 꼭 필요한 최소 권한만 부여합니다. 되돌리기 어려운 작업일수록 읽기 전용으로 시작해 점진적으로 권한을 넓히는 접근이 안전합니다.

써 보면 걸리는 두 가지

설명서에는 잘 안 나오는데 실제로 붙여 쓰면 바로 만나는 상황이 있습니다.

연결이 세션 도중에 끊깁니다. 로컬 프로세스로 뜨는 서버는 프로세스가 죽으면 그 서버의 도구가 통째로 사라집니다. 2026년 8월 2일 작업 중에도 서버 여러 개가 중간에 끊겼다가 잠시 뒤 다시 붙었습니다. 도구를 부르던 중이었다면 그 호출은 실패합니다. 한 번 연결되면 계속 붙어 있다고 가정하고 자동화를 짜면 안 됩니다.

원격 서버는 인증이 따로입니다. http 방식으로 등록한 서버는 설정에 주소만 적혀 있습니다. 그래서 처음 쓸 때 브라우저에서 로그인·권한 승인을 따로 해야 도구가 열립니다. 승인 전에는 서버가 목록에는 보이는데 도구는 하나도 안 뜨는 상태가 됩니다. 설정이 틀린 것처럼 보이지만 인증만 남은 경우가 많습니다.

여기에 하나 더, 서버를 여러 개 붙이면 도구 개수가 빠르게 늘어납니다. 서버 7개에 도구가 수백 개까지 늘어납니다. 클라이언트에 따라 전부를 한꺼번에 물고 있지 않고 필요할 때 불러오는 방식으로 처리합니다. 붙이는 서버가 늘수록 이 부분이 체감됩니다.

마무리

MCP는 AI 모델과 외부 도구를 표준 방식으로 연결해, 도구마다 따로 만들던 연동 코드를 줄여주는 프로토콜입니다. 이미 공개된 MCP 서버를 설정 파일에 등록하는 것만으로 파일시스템·데이터베이스·Slack·GitHub 같은 도구에 AI가 직접 접근하게 만들 수 있지만, 그만큼 권한 범위를 신중히 설정하는 습관이 함께 필요합니다.

콘텐츠 제작·자동화와 관련된 글도 함께 보면 흐름이 잘 잡힙니다.

• AI 맞춤법, 60문항 돌려본 결과
• 한글 파일명 깨짐, 진짜 원인 네 가지
• 한국어 토큰, 아직도 영어의 2배일까

이 글은 업무 자동화 묶음에 속합니다. 같은 주제의 글을 배우는 순서대로 묶어 두었으니 묶음 페이지에서 이어 보세요.

---

글쓴이 · K.Lee — 파티시에로 일하며 AI·자동화 도구를 실무에 매일 씁니다. 확인한 범위와 확인하지 못한 범위를 글 안에 밝힙니다. 운영자 소개 · 편집 원칙 · 수정 정책

---