Claude Code MCP 추천: 4개를 42번 돌려 보니 남길 건 Playwright

MCP 추천 글을 보면 대부분 “이걸 붙이면 좋다”에서 끝납니다. 정말 그런지 궁금해서 많이 추천되는 서버 네 개를 Claude Code에 붙이고, 웹 도구만 쓸 때와 같은 질문으로 비교했어요. 모두 42번입니다.

저라면 항상 붙여 둘 서버로 Playwright 하나만 고르겠습니다. 자바스크립트로 그리는 페이지를 읽는 일은 웹 도구로 안 됐거든요. 반대로 문서를 찾는 Context7, DeepWiki, Microsoft Learn은 이번 질문에서 답도 비용도 웹 도구와 거의 같았습니다.

그러니 MCP를 고를 때는 “기본 도구로 못 하는 일이 있나”부터 물어보세요. 없으면 아직 붙이지 않아도 됩니다.

2026년 11월 2일 Windows 11 테스트 환경에서 Claude Code 2.1.310과 Sonnet 5.5로 직접 실행한 결과입니다.

한눈에 보면: 브라우저만 달랐다

아래 그래프는 도구로 찾아보고 답하게 한 조건입니다. 질문마다 MCP 쪽과 웹 도구 쪽을 세 번씩 돌린 평균이에요.

Playwright 줄의 시간이 눈에 띕니다. 웹 도구 쪽은 페이지를 읽으려다 실패하고 다른 방법을 찾느라 21.7초가 걸렸어요. 비용도 17% 더 나왔습니다.

나머지 세 줄은 비용 차이가 3%, 9%, 1%뿐입니다. 이 정도면 고르는 기준이 되지 않아요. 그래서 문서 검색 MCP를 붙일지는 비용보다 평소 어떤 문서를 찾는지로 정하는 게 맞습니다.

JS 페이지를 읽게 시켰더니

차이가 가장 분명했던 건 quotes.toscrape.com/js/였습니다. 명언을 자바스크립트로 그리는 연습용 페이지인데, 첫 명언의 저자를 물었어요.

조건	평균 시간	턴	무엇을 읽었나
Playwright MCP	8.7초	4	요청한 페이지
웹 도구만	21.7초	5~7	다른 주소의 정적 페이지

웹 도구 쪽은 세 번 다 “Albert Einstein”이라고 답했습니다. 답은 맞았지만 요청한 페이지를 읽은 건 아니에요. 가져온 내용에 명언이 없자 같은 사이트의 정적 페이지를 대신 읽은 겁니다.

연습용 사이트는 두 페이지의 첫 명언이 같아서 맞았을 뿐입니다. 실제 서비스 화면이었다면 이렇게 대신 읽을 페이지가 없거나 내용이 달랐겠죠.

세 번 모두 답에 그 사실을 밝혔다는 점은 다행이었어요. 다만 답이 맞았다고 끝내지 말고, 어느 주소를 읽었는지까지 보세요.

문서 검색 세 개는 호출조차 안 됐다

처음에는 그냥 질문만 던졌는데, 아홉 번 모두 MCP 도구를 한 번도 부르지 않았습니다. 기억으로 답한 거예요. 물어본 건 이 세 가지입니다.

• Next.js 15의 cookies()는 동기인가 비동기인가 (Context7)
• astral-sh/uv 저장소에서 리졸버가 있는 크레이트는 어디인가 (DeepWiki)
• PowerShell 5.1 Set-Content의 기본 인코딩은 무엇인가 (Microsoft Learn)

답은 모두 맞았어요. 잘 알려진 내용은 서버를 붙여 둬도 그냥 답한다는 뜻입니다. 이때 비용은 웹 도구 쪽보다 Context7이 6%, DeepWiki가 26%, Microsoft Learn이 11% 높았습니다. 쓰지도 않은 서버 몫을 낸 셈이죠.

그래서 “기억으로 답하지 말고 도구로 찾아보라”고 덧붙여 다시 돌렸더니 그제야 호출하더라고요. 앞의 그래프가 이 결과입니다.

찾아보게 하면 답은 조금 더 구체적이 됐습니다. DeepWiki는 crates/uv-resolver/src/resolver/mod.rs의 Resolver 구조체까지 짚었고, 웹 도구는 GitHub 목록과 README를 읽고 crates/uv-resolver로 답했어요. 질문에 대한 답은 같습니다.

Microsoft Learn 쪽은 대상 파일이 비어 있거나 없을 때 Default를 쓴다고 조건을 붙였습니다. 궁금해서 PowerShell 5.1에서 직접 해 봤어요.

새 파일:            B0 A1 0D 0A
기존 UTF-16 파일:   B0 A1 0D 0A
기존 UTF-8 BOM 파일: B0 A1 0D 0A

한글 “가”를 Set-Content로 덮어쓴 뒤 바이트를 읽은 결과입니다. 기존 파일의 인코딩과 상관없이 모두 시스템 코드 페이지(CP949)로 저장됐어요. 덮어쓸 때는 어느 쪽 답을 믿어도 결과가 같았습니다.

이 비교는 질문 세 개로 한 것이고, 셋 다 공개 문서에 답이 잘 나와 있습니다. 검색에 잘 안 잡히는 라이브러리나 최근에 바뀐 API라면 결과가 다를 수 있어요. 저라면 그런 문서를 자주 찾게 될 때 Context7이나 DeepWiki를 붙이겠습니다.

붙여 두는 값은 얼마인가

서버를 붙이기만 해도 드는 토큰은 생각보다 적었습니다. 도구 정의가 처음부터 다 올라가지 않고, Claude가 필요할 때 도구 검색으로 불러오기 때문이에요.

서버	도구 수	필요할 때 불러올 정의	새 세션 시작 토큰
없음	0	0	30.5k
Playwright	25	6.7k	30.5k
Context7	2	1.5k	30.7k
Microsoft Learn	3	1.1k	31k
DeepWiki	3	264	31.8k

도구가 25개나 되는 Playwright도 시작 토큰은 그대로였습니다. 시작할 때 가장 많이 늘어난 건 도구 정의가 가장 작은 DeepWiki였고요. 그러니 도구 개수만 보고 무겁다고 판단하면 안 됩니다.

직접 재 보려면 세션에서 /context를 실행하세요. 다만 도구 검색을 끈 설정이거나 도구 검색을 쓰지 못하는 모델이라면 이 표와 달라집니다.

앞에서 본 것처럼 안 쓰는 서버도 요청 비용을 조금씩 올립니다. 이번 값은 요청당 0.002~0.006달러였어요. 한 번은 작아도 세션이 길면 쌓이니, 몇 달째 호출되지 않은 서버는 빼는 게 낫습니다. 어느 서버가 실제로 쓰였는지는 /usage의 사용 내역에서 볼 수 있습니다.

저라면 이렇게 고릅니다

하는 일	고른 것	이유
화면 확인, JS 페이지 읽기	Playwright	웹 도구로 못 함
공개 문서 찾기	먼저 웹 도구	답과 비용이 같았음
검색에 안 잡히는 라이브러리 문서	Context7	이번 비교 밖이라 써 보고 판단
처음 보는 GitHub 저장소 구조 파악	DeepWiki	파일 위치까지 답함
Azure·PowerShell 문서를 자주 찾음	Microsoft Learn	쓰는 사람에게만 값이 있음

Playwright는 프로젝트에 이렇게 붙였습니다. 버전을 고정해 두면 어느 날 갑자기 서버 코드가 바뀌는 일을 막을 수 있어요.

claude mcp add --scope project playwright '--' cmd /c npx -y '@playwright/mcp@0.0.84' --headless

'--'를 따옴표로 감싼 건 PowerShell 5.1 때문이고, Git Bash에서는 따옴표 없이 --로 씁니다. Node.js 18 이상이 필요해요. 이 명령과 도구 호출까지 확인하는 순서는 Claude Code에 MCP 서버를 연결하는 글에 정리했습니다.

원격 서버는 설치할 것이 없어 더 간단합니다.

claude mcp add --scope project --transport http context7 https://mcp.context7.com/mcp

Added HTTP MCP server context7 with URL: https://mcp.context7.com/mcp to project config

Playwright에는 browser_run_code_unsafe 같은 도구도 들어 있으니 서버 전체를 항상 허용하지 마세요.

브라우저는 Claude가 보는 페이지의 글을 그대로 읽어 들입니다. 신뢰하지 않는 사이트를 열게 한다면 프롬프트 인젝션을 막는 방법도 같이 봐 두세요. 문서 검색 서버도 질문이 외부 서비스로 나가니, 회사 코드나 내부 이름을 질문에 넣지 않는 게 좋습니다.

돌려 보고 남은 생각

돌려 보니 잘 알려진 내용에서는 문서 검색 MCP를 부르지도 않더라고요. MCP는 많이 붙일수록 똑똑해지는 게 아니라, 못 하던 일을 하게 해 줄 때 값을 합니다.

지금 붙여 둔 서버가 있다면 /usage의 사용 내역에서 실제로 쓰였는지부터 보세요. 안 쓰인 서버를 빼고, 기본 도구로 막힌 일이 생겼을 때 그 일에 맞는 서버를 하나 더하는 순서를 권합니다. 서버가 붙지 않으면 연결 실패를 점검하는 순서부터 따라가 보세요.