도구 연결 — MCP로 AI에 손발 달기

손발이 없으면 에이전트도 말뿐

4장까지 만든 것, 그리고 빠진 것

4장에서 Claude Code로 에이전트를 굴려 봤습니다. 그런데 아무리 똑똑한 에이전트라도, 붙어 있는 도구가 없으면 결국 말만 하는 챗봇으로 돌아갑니다.

에이전트가 실제로 일하려면 손발이 필요합니다. 검색할 손, 파일을 열 손, 메일을 보낼 손.

MCP가 하는 일: 표준 콘센트에 도구 꽂기

MCP는 이 손발을 표준 방식으로 붙여 주는 규격입니다. 2장에서 "AI의 USB-C"라고 했던 그 콘센트에, 이제 실제 도구를 꽂는 단계죠. 어떤 도구를 어디까지 붙이느냐가 그 에이전트가 해내는 일의 범위를 그대로 정합니다. 손이 하나뿐이면 한 가지 일밖에 못 하고, 손이 많으면 그만큼 넓게 움직입니다.

무엇을 붙일 수 있나 — 자주 쓰는 MCP 서버

갈래로 보는 도구 지도

MCP 서버로 붙이는 도구는 크게 몇 갈래입니다. 커뮤니티 디렉터리 기준으로 2026년 5월 5,000개가 넘는 서버가 등록돼 있어(출처: mcpplaygroundonline·Cubitrek), 웬만한 도구는 이미 준비돼 있습니다.

공식 서버와 벤더·커뮤니티 서버

전부 같은 곳에서 관리하는 건 아닙니다. Anthropic이 직접 유지하는 공식 레퍼런스 서버는 일곱 개입니다.

Anthropic 공식 레퍼런스 서버는 Everything·Fetch·Filesystem·Git·Memory·Sequential Thinking·Time 7종입니다. GitHub·Slack·Google Drive·Postgres·Brave Search 등 초창기 13종은 2025년 각 벤더·커뮤니티 관리로 넘어갔습니다. (출처: MCP 공식 저장소·Developers Digest)

즉 "공식이라 더 안전한 소수"와 "벤더·커뮤니티가 만든 다수"가 섞여 있습니다. 무엇을 붙이느냐만큼, 누가 만든 서버인지도 봐야 한다는 뜻입니다.

가장 많이 쓰이는 서버들

수천 개가 있어도 실제로 자주 깔리는 건 몇 개로 좁혀집니다. GitHub, Context7, Playwright, Filesystem, Brave Search가 사실상 어디서나 지원됩니다(출처: TECHSY·SSOJet). 인기의 무게도 확인됩니다. GitHub 공식 MCP 서버는 깃허브 스타 30,800개, 마이크로소프트의 Playwright MCP는 34,100개를 넘겼습니다. 처음이라면 이 검증된 몇 개부터 시작하는 편이 안전합니다.

붙이는 큰 흐름은 똑같다

방법 자체는 도구마다 조금씩 다르지만, MCP 덕분에 "커넥터를 고르고 연결한다"는 큰 흐름은 같습니다. 노코드 도구라면 목록에서 원하는 커넥터를 고르고 로그인 한 번 해 주면 끝입니다. 회의록을 노션에 저장하는 에이전트라면, 노션 커넥터를 고르고 계정을 연결한 뒤 "어느 데이터베이스에 저장할지"만 지정하면 됩니다. 그 순간부터 에이전트는 노션에 글을 쓰는 손 하나를 갖습니다. 코드는 한 줄도 없습니다.

무엇을 붙일지는 목표가 정한다

도구가 아니라 목표부터

여기서 순서가 중요합니다. 도구를 먼저 잔뜩 붙이고 "뭘 시킬까" 고민하면 십중팔구 어수선해집니다. 반대로 가세요. 먼저 이 에이전트의 목표를 적고, 그다음 "그 목표를 이루려면 어떤 손발이 필요한가"만 따져 최소한으로 붙입니다.

예: 리서치 에이전트 vs 문의응대 에이전트

경쟁사 동향을 모으는 리서치 에이전트라면 필요한 건 둘뿐입니다. 정보를 찾을 검색, 결과를 남길 문서 저장. 여기에 메일 발송이나 결제 권한을 붙일 이유가 없죠. 반대로 고객 문의에 답장하는 에이전트라면 메일 읽기·쓰기가 핵심이고, 검색은 없어도 됩니다. 목표가 다르면 붙일 손발도 달라집니다.

많이 붙인다고 좋은 게 아니다

도구가 많을수록 강한 에이전트라고 생각하기 쉽지만, 실제로는 반대인 경우가 많습니다. 선택지가 많을수록 에이전트가 엉뚱한 도구를 골라 헤매고, 붙인 도구 하나하나가 사고가 날 통로가 됩니다.

한 가지를 잘하는 에이전트 여럿

그래서 실전에서는 "이 일에 딱 필요한 것만"이 원칙입니다. 도구를 줄이면 에이전트의 판단이 단순해지고, 관리할 위험도 줄어듭니다. "만능 에이전트" 하나보다 "한 가지 일을 잘하는 에이전트" 여럿이 대개 더 낫다는 이야기는 6장 멀티 에이전트로 이어집니다.

안전하게 연결하기 — 권한과 신뢰

권한은 좁게, 위험한 건 사람 손

도구를 붙일 때는 권한을 함께 봐야 합니다. 같은 메일 도구라도 "읽기만"과 "발송까지"는 전혀 다른 위험입니다. 기준은 단순합니다. 읽기는 넉넉히 열어 줘도 되지만, 되돌리기 어려운 쓰기(실제 발송, 결제, 삭제)는 좁게 잡거나 사람 승인을 한 칸 끼웁니다.

연결 도구는 내 계정 권한을 물려받는다

연결한 도구가 내 계정 권한을 그대로 물려받는다는 점도 기억하세요. 회사 메일을 붙이면 에이전트도 그 메일함 전체에 접근합니다. 가능하면 전용 계정이나 최소 권한 토큰으로 연결하는 게 안전합니다.

신뢰 안 되는 서버의 위험

출처가 불분명한 커뮤니티 서버를 아무거나 붙이는 건 위험합니다. 악의적으로 만든 서버는 도구 설명이나 반환값에 숨긴 지시를 심어 에이전트를 조종할 수 있습니다(프롬프트 인젝션). 앞서 공식·벤더 서버를 구분한 이유가 여기 있습니다. 검증된 서버부터, 그리고 코드나 평판을 확인할 수 있는 것부터 붙이세요.

연결 전 안전 체크리스트

새 도구를 붙이기 전에 이 네 가지만 확인해도 사고 대부분을 막습니다.

• 이 목표에 이 도구가 정말 필요한가 (아니면 붙이지 않기)
• 읽기로 충분한가, 쓰기까지 필요한가
• 되돌리기 어려운 행동에 사람 승인을 끼웠는가
• 서버 출처가 공식·벤더인가, 정체불명 커뮤니티인가

도구 연결의 원칙은 하나로 요약됩니다. 필요한 것만, 최소 권한으로, 신뢰할 수 있는 출처에서. 이 "위험한 행동엔 사람 손, 권한은 최소로"를 7장 에이전트 가드레일에서 제대로 다룹니다.

다음 챕터에서는 하나로 벅찬 일을 여러 에이전트가 역할을 나눠 협업하게 만드는 멀티 에이전트를 다루겠습니다.