Claude Code 창시자가 가장 중요하게 여기는 것이 무엇인지 아시나요?
프롬프트 작성 방법이 아닙니다. 모델 선택도 아닙니다.
"Claude 에게 자신의 결과물을 검증할 수단을 제공하라."
이것이 가장 중요합니다. 그가 Claude Code 사용법 중 가장 중요한 팁이라고 말하는 것입니다.
이 글은 그 논의의 연장선에 있습니다. 원칙은 이해했습니다. 그렇다면 구체적으로 어떻게 그 수단을 제공할까요? 정답은 MCP 서버입니다.
솔직히, 이것을 아느냐 모르느냐에 따라 Claude Code 사용 경험이 완전히 달라집니다. 문서를 붙여넣고, 이슈를 복사하고, 화면을 직접 열어 확인하느라 시간을 허비하는 모든 일이 사라집니다.
Claude Code 사용하면서 이런 경험 해보셨나요?
- 생성된 코드가 오래된 문법을 사용해서 매번 직접 수정합니다.
- 만든 화면이 실제로 작동하는지 직접 브라우저를 열어 확인합니다.
- 이슈 내용을 복사해서 Claude 에 붙여넣고 구현하게 한 후, 다시 진행 상황을 작성합니다.
- 프로덕션 에러가 발생할 때마다 Sentry 에서 스택 트레이스를 복사합니다.
- MCP 라는 단어는 알지만 무엇을 추가해야 할지 몰라서 아무것도 설정하지 않았습니다.
네. 저도 그렇게 하고 있었습니다.
미리 말씀드리자면, 코딩을 못하는 분들도 이 글을 읽을 수 있습니다. 기술 용어는 나올 때마다 풀어서 설명하겠습니다. 사실 MCP 는 비개발자에게 더 큰 혜택이 있을 수 있는 시스템입니다.
이 글을 다 읽고 나면, 업무 중에서 "매번 복사-붙여넣기" 하는 부분을 하나 찾아보고 싶어질 것입니다.
꼭 저장해두세요.
"Boris"는 정확히 누구인가요?
보리스 처니(Boris Cherny). 바로 Claude Code 를 만든 사람입니다.
그는 스스로 "내가 Claude Code 를 만들었다"고 명확히 밝히고 있으므로 의심의 여지가 없습니다. 그는 Claude Code 의 설계 철학을 가장 깊이 이해하고 있는 사람입니다.
그의 사용 방식은 매우 특별합니다.
먼저, 그는 오랫동안 직접 코드를 작성하지 않았습니다. 대신 터미널에서 약 5개의 Claude 세션을 실행하고, 웹에서 또 5~10개를 동시에 실행하며, 탭에 번호를 매기고 어떤 Claude 가 사람의 입력을 기다리고 있는지 알림으로 관리합니다.
(15명의 부하 직원이 모두 다른 작업을 하고 있고, 막힌 사람만 와서 보고하는 모습을 상상해보세요.)
게다가 그의 CLAUDE.md — 프로젝트 규칙 파일 — 는 약 100줄밖에 되지 않습니다. 그는 방대한 양의 규칙을 작성하는 스타일이 아닙니다.
그가 가장 자주 인용하는 말은 이것입니다:
"프롬프트를 작성하지 마세요. 루프를 작성하세요."
잘 부탁하는 방법을 찾는 대신, Claude 가 스스로 작업을 순환할 수 있는 환경을 만드세요. 이것이 그의 철학의 핵심입니다.
Boris 가 반복하는 3가지 원칙
그의 게시물을 보면, 그는 일관되게 같은 이야기를 합니다.
원칙 1: Claude 에게 자신의 결과물을 검증할 수단을 제공하라.
그는 이것을 "가장 중요한 팁"이라고 부릅니다. 그의 설명은 매우 이해하기 쉽습니다.
누군가에게 웹사이트를 만들라고 하면서 브라우저 사용을 금지하면 어떻게 될까요? 제대로 된 것은 나오지 않습니다.
하지만 브라우저를 주면, 만들고, 보고, 고치고, 다시 보고, 만족할 때까지 반복할 것입니다.
Claude 도 마찬가지입니다. 검증할 수단을 주면 만족할 때까지 스스로 반복합니다.
원칙 2: 하루에 한 번 이상 하는 작업은 시스템으로 만들어라.
매번 채팅에서 같은 절차를 설명하는 것은 시간 낭비이므로, Skill 이나 명령어로 만들어 두세요. 호출될 때까지 준비되어 있는 비용이 거의 없으므로 만들어두어도 나쁠 것이 없습니다.
원칙 3: 외부 도구를 Claude Code 작업 공간으로 가져와라.
Slack, 이슈 트래커, 데이터베이스, 내부 API. 이것들을 Claude Code 에서 직접 접근할 수 있게 만들면 도구 간 이동이 사라집니다.
이것이 바로 MCP 가 필요한 이유입니다.
마지막으로
MCP 에 대해 이야기할 때면 항상 이 벽에 부딪힙니다.
MCP 를 연결하는 순간, Claude Code 의 손이 프로덕션 환경에 닿게 됩니다. 배포, DNS, 결제, 고객 데이터. 읽는 것은 괜찮지만, 갑자기 쓰기나 삭제를 허용하면 사고가 발생할 수 있습니다.
그렇다면, 어디까지 위임하고, 어디에서 사람이 확인해야 할까요?
경계 차트를 무료로 공개합니다. MCP 를 설치하기 전에 꼭 한 번 보시기 바랍니다.
👇
MCP 를 한 문장으로 설명하면?
먼저 이것부터 확실히 합시다.
MCP 는 "AI 도구와 외부 서비스를 연결하는 공통 인터페이스"입니다. USB 표준과 비슷하다고 생각하면 됩니다.
이것이 없는 세상에서는 Claude, ChatGPT, 다른 AI 마다 각각 별도의 통합을 구축해야 합니다. MCP 표준이 있으면 서비스 제공자가 한 번만 구축하면 모든 호환 AI 도구에서 사용할 수 있습니다.
그리고 분명히 말씀드리자면, MCP 는 단순히 Claude Code 에 기능을 추가하는 것만이 아닙니다.
작업 대상 자체를 Claude Code 내부로 가져옵니다.
Figma 디자인, Sentry 오류, Linear 티켓, Cloudflare 프로덕션 로그 — Claude 가 직접 보고 직접 조작합니다. 그래서 복사-붙여넣기가 사라지는 것입니다.
그리고 이제 이 표준이 크게 변화했습니다.
MCP 전제 조건의 변화
이 내용은 일본어권에서 아직 잘 정리되지 않았으니 주목해주세요.
최신 사양 업데이트에서 MCP 는 출시 이후 가장 큰 개편을 겪었습니다. 주요 변경 사항 4가지는 다음과 같습니다:
상태 비저장(Statelessness). 이전의 원격 MCP 는 서버가 연결 상태를 유지하도록 설계되었습니다. 그것이 사라지고, 이제는 표준 HTTP 와 같은 요청-응답 유형이 되었습니다. 장점은 서버리스나 엣지 환경에서 직접 실행할 수 있다는 것입니다. MCP 는 이제 단일 상주 서버가 아니라 액세스에 따라 확장되는 시스템으로 구축할 수 있습니다.
장기 실행 프로세스 지원. 도구가 즉시 결과를 반환한다는 가정이 사라졌습니다. 먼저 추적 번호를 반환하고, 나중에 진행 상황 확인, 업데이트, 취소가 가능합니다. 대규모 코드 마이그레이션, 비디오 생성, 장기 데이터 분석, 전체 환경 배포 — 이러한 "몇 시간 걸리는 작업"이 이제 MCP 를 통해 공식적으로 지원됩니다.
대화 내 UI 반환 가능. 이전에는 MCP 가 텍스트와 JSON 에 중점을 두었지만, 이제 서버가 조작 화면을 반환할 수 있습니다. 배포 대상 선택 화면, 그래프, 승인/거부 버튼, 양식. 즉, MCP 는 AI 가 백그라운드에서 API 를 호출하는 시스템에서 AI 위에서 실행되는 미니 앱 표준으로 진화하고 있습니다.
조직 수준 인증. 기업 ID 제공자와 연결되어, 관리자가 승인하면 직원이 첫 로그인 시 자동으로 연결됩니다. 개인에게 API 키를 배포하는 작업이 사라집니다.
Anthropic 측에서 이를 순차적으로 출시하고 있다는 점에 유의하세요. 사양이 확정되었다는 것과 사용자의 로컬 Claude Code 에서 모든 것을 즉시 사용할 수 있다는 것은 다릅니다.
(가끔 이를 과장하는 기사를 보는데, 공식 표현은 "순차적으로 출시 중"입니다.)
Claude 의 커넥터 목록에는 950개 이상의 MCP 서버가 등록되어 있습니다. 숫자는 압도적이지만, 실제로 설치해야 할 만큼 많은 것은 아닙니다.
Claude Code 를 변화시키는 8가지 공식 MCP 서버
이것이 핵심 부분입니다.
선정 기준은 세 가지입니다: 제공자가 관리하는 공식 서버여야 하고, 초보자도 효과를 쉽게 느낄 수 있어야 하며, Boris 의 세 가지 원칙 중 하나를 직접 구현해야 합니다.
- Context7 MCP: 오래된 코드의 원인을 제거
Claude Code 가 잘못된 코드를 출력할 때, 그 원인은 종종 모델의 지능 부족이 아닙니다.
단지 참조하는 정보가 오래된 것뿐입니다.
더 이상 사용되지 않는 API 사용. 오래된 Next.js 문법 출력. 다른 버전의 설정 혼용. 존재하지 않는 옵션 생성. 문서에 없는 구현을 추측으로 채워넣기. 모두 이것 때문입니다.
Context7 은 라이브러리와 프레임워크의 최신 문서를 버전별로 Claude Code 에 제공하는 MCP 입니다. 기억에서 답변하는 대신, 특정 버전의 자료를 찾아본 후 구현하는 상태를 만듭니다.
실용적인 프롬프트:
Context7 을 사용하여 이 프로젝트에서 사용하는 Next.js 현재 버전의 공식 문서를 확인하세요.
확인 후, 구현을 시작하기 전에 다음을 정리하세요:
- 현재 버전에 권장되는 구현
- 더 이상 사용되지 않는 구현
- 현재 프로젝트 코드와의 차이점
- 수정이 필요한 파일
추측에 기반한 구현은 하지 말고, 문서에 설명된 방법만 사용하세요.
참고: 하나의 쿼리에 여러 개념을 혼합하지 마세요. "인증, 라우팅, 캐싱"에 대해 묻으면 광범위하고 얕은 결과를 반환합니다. 개념을 별도로 조회할 때 정확도가 더 높습니다.
공식 저장소: https://github.com/upstash/context7
- Playwright MCP: Claude 가 브라우저를 직접 조작하게 하기
이것은 Boris 의 원칙 1을 직접 구현합니다.
Claude Code 는 코드를 작성할 수 있지만, 작성한 화면이 실제로 작동하는지는 알 수 없습니다. Playwright MCP 를 연결하면 Claude 가 실제 브라우저를 열고, 버튼을 클릭하고, 양식을 작성하고, 전환을 추적하고, 오류를 잡고, 수정하고, 다시 확인할 수 있습니다.
이 시스템의 흥미로운 점은 단순히 스크린샷을 이미지로 보는 것이 아니라는 것입니다. 화면의 구조화된 정보인 접근성 트리(Accessibility Tree)를 읽습니다. 무엇이 버튼이고, 입력 필드이며, 제목인지 이해합니다. 의미를 읽기 때문에 시각적으로 유사한 요소를 혼동할 가능성이 적습니다.
실용적인 프롬프트:
구현이 완료되면 Playwright MCP 로 로컬 환경을 여세요.
다음을 실제로 작동시켜 확인하세요:
- 새 회원가입
- 로그인
- 입력 오류 시 표시
- 스마트폰 너비에서 레이아웃 깨짐
- 로그아웃
실패하면 코드만 읽고 원인을 추측하지 말고, 수정 전에 브라우저에서 재현하세요.
수정 후 동일한 작업을 다시 실행하고 성공을 확인한 후에만 완료를 보고하세요.
솔직히 말씀드리겠습니다.
Boris 자신이 웹 작업에 항상 사용한다고 말하는 것은 실제로 Playwright MCP 가 아니라 Claude Code 브라우저 확장 프로그램입니다. 로그인 상태를 그대로 공유할 수 있기 때문에 유사한 MCP 보다 더 안정적이라고 말합니다.
따라서 사용 사례는 다음과 같습니다: 로그인된 브라우저를 사용하여 실제 화면을 확인하려면 확장 프로그램을 사용하세요. 테스트로 자동화하고 동일한 절차를 반복적으로 실행하려면 Playwright MCP 를 사용하세요.
둘 다 동일한 철학을 공유합니다: "Claude 에게 브라우저를 제공하라."
공식 저장소: https://github.com/microsoft/playwright-mcp
- Figma MCP: 이미지가 아닌 디자인 데이터 읽기
디자인을 스크린샷으로 전달하는 한, Claude 는 항상 추측하고 있습니다.
여백이 몇 픽셀인지? 글꼴 크기는? 이 색상이 브랜드 색상인지 임시 색상인지? 이 부분이 재사용 가능한 컴포넌트인지? 모든 것을 이미지에서 눈으로 추측하고 있습니다.
Figma 개발자 MCP 를 연결하면 구조화된 디자인 정보에 직접 액세스할 수 있습니다. 값, 색상, 컴포넌트 구조, 디자인 토큰. 추측이 사라집니다.
실용적인 프롬프트:
Figma MCP 에서 현재 선택된 프레임을 검색하세요.
먼저 다음만 추출하고 구현을 시작하지 마세요:
- 페이지 구조
- 재사용할 컴포넌트
- 색상 및 타이포그래피 정의
- 여백 규칙
- 반응형 크기 조정 시 예상되는 변경 사항
추출된 내용을 확인한 후, 기존 프로젝트 컴포넌트를 우선하여 구현하세요.
새 컴포넌트를 만드는 경우, 먼저 기존 컴포넌트가 왜 부족한지 설명하세요.
그리고 여기에 진정한 가치가 있습니다.
Figma 에서 디자인을 가져오고, Claude Code 에서 구현하고, Playwright 에서 확인하고, 깨지면 수정합니다. 이 세 가지를 연결하면 디자인에서 검증까지 하나의 라인으로 이어집니다.
MCP 의 가치는 개별적으로보다는 이렇게 연결되었을 때 더 잘 이해됩니다.
공식 문서: https://developers.figma.com/docs/figma-mcp-server/
- Linear MCP: 티켓 읽기 및 진행 상황 작성
Boris 는 PR 에서 동료들을 @claude 로 멘션하고, 학습 내용을 규칙 파일에 추가하도록 합니다. 요컨대, 그는 이슈 관리 공간과 AI 작업 공간을 분리하지 않습니다.
공식 Linear MCP 를 연결하면 이슈 검색, 생성, 업데이트, 댓글 작성을 모두 Claude Code 내에서 할 수 있습니다. Linear 가 호스팅하는 인증이 있는 원격 연결이므로 PC 에서 서버를 계속 실행할 필요가 없습니다.
이를 통해 다음 흐름이 원활해집니다:
이슈 읽기 → 관련 코드 조사 → 구현 계획 수립 → 구현 → 테스트 → 이슈에 진행 상황 댓글 작성 → 상태 업데이트
실용적인 프롬프트:
Linear 에서 진행 중인 나에게 할당된 이슈를 확인하세요.
우선순위와 종속성을 정리한 후, 최우선 이슈에 대해 다음을 실행하세요:
- 요구사항에서 누락된 정보 식별
- 관련 코드 조사
- 구현 계획을 수립하고 구현 전에 제시
- 승인 후 구현 및 테스트
- 이슈에 수행한 작업 내용 댓글 작성
상태를 변경하기 전에 제 확인을 기다리세요.
마지막 줄은 항상 포함하세요. 상태 변경을 자동화하면 다른 팀원 입장에서는 "완료되지 않은 작업이 완료된 것으로 표시"되는 상황이 발생할 수 있습니다.
공식 문서: https://linear.app/docs/mcp
- Sentry MCP: 에러를 붙여넣지 않고 원인 추적
프로덕션 에러가 발생하면 어떻게 하시나요?
Sentry 를 열고, 스택 트레이스를 복사하고, Claude 에 붙여넣고, 의심되는 파일을 찾아서 다시 붙여넣습니다. 이런 작업이 전혀 필요 없습니다.
Sentry MCP 의 가치는 단순히 에러 목록을 보여주는 것이 아닙니다. 에러 내용, 스택 트레이스, 빈도, 영향받은 사용자, 어떤 릴리스에서 발생했는지, 관련 코드, 과거 유사 실패 사례를 하나의 조사 루프에 넣는 것입니다.
실용적인 프롬프트:
Sentry 에서 지난 24 시간 동안 가장 많은 사용자에게 영향을 미친 해결되지 않은 에러를 검색하세요.
다음 순서로 조사하세요:
- 발생 조건 분석
- 관련 코드 식별
- 재현 테스트 생성
- 재현 가능하면 최소한의 수정 구현
- 모든 테스트 실행
- 근본 원인 및 수정 사항 요약
재현되지 않으면 추측에 기반한 수정은 하지 마세요. 원인을 좁히는 데 필요한 추가 정보를 나열하고 거기서 멈추세요.
"재현되지 않으면 추측에 기반한 수정은 하지 마세요"라는 문장은 효과적입니다. 이 문장이 없으면 그럴듯해 보이는 수정이 근본 원인은 그대로 둔 채 적용되고, "수정 완료"라고 보고할 수 있습니다.
공식 문서: https://docs.sentry.io/product/sentry-mcp/
- Cloudflare MCP: 배포 대상의 상태 표시
지금까지는 개발에 대해 이야기했지만, 이것은 운영에 관한 것입니다.
Cloudflare 는 자사 서비스를 운영하기 위해 여러 공식 MCP 서버를 출시했습니다. 설정 확인, Workers 관리, 로그 분석, DNS 설정, 보안 설정, 성능 확인. 읽기뿐만 아니라 제안하고 실제로 변경하는 것까지 설계되었습니다.
이는 Claude Code 가 배포 대상에서 실제로 어떻게 동작하는지 확인한 후 코드를 개선할 수 있음을 의미합니다.
실용적인 프롬프트:
Cloudflare MCP 로 현재 프로덕션 환경 상태를 확인하세요.
다음을 조사하세요:
- 지난 24 시간 동안의 에러
- 응답 시간
- 캐시 적중률
- 보안 이벤트
- Workers 에서 발생하는 예외
그런 다음 문제를 다음 두 가지 범주로 분류하세요:
A. 코드 변경이 필요한 것
B. Cloudflare 설정만으로 개선 가능한 것
두 경우 모두 변경을 실행하기 전에 항상 계획을 제시하세요. 제가 승인할 때까지 설정을 변경하지 마세요.
인프라에 영향을 미치므로 초기 도입 시에는 읽기 전용으로 제한하세요. 처음부터 설정 변경을 허용할 필요는 없습니다.
공식 문서: https://developers.cloudflare.com/agents/model-context-protocol/cloudflare/servers-for-cloudflare/
- Stripe MCP: 결제 코드와 Stripe 설정 일치
결제 구현이 어려운 이유는 코드만 봐서는 정답을 알 수 없기 때문입니다. Stripe 쪽에 어떤 상품과 가격이 등록되어 있는지, 웹훅이 어떻게 설정되어 있는지 다른 탭에서 확인하면서 작성해야 합니다.
공식 Stripe MCP 에는 Stripe API 작업 외에도 공식 문서 및 지원 정보 검색이 포함됩니다. 구현, 설정 확인, 문서 참조가 모두 같은 공간에서 이루어집니다.
또한 Stripe 는 MCP 외에도 Agent 를 위한 Skills 를 제공합니다. MCP 로 운영하고, Skills 로 모범 사례를 강화합니다. 이 조합은 강력합니다.
실용적인 프롬프트:
Stripe MCP 와 공식 Stripe 문서를 사용하여 월간 구독 기능에 대한 구현 계획을 수립하세요.
다음을 반드시 확인하세요:
- 상품 및 가격 구성
- Checkout Session 생성 방법
- Webhook 으로 수신해야 할 이벤트
- 취소 프로세스 흐름
- 결제 실패 시 동작
- 이중 등록 방지 방법
- 테스트 방법
작업 중에는 Stripe 테스트 모드만 사용하세요. 프로덕션 데이터를 변경하지 마세요.
마지막 두 줄은 절대 삭제하지 마세요. 이 게이트를 열어두고 실행할 MCP 가 아닙니다.
공식 문서: https://docs.stripe.com/mcp
- GitHub MCP: 리뷰 응답 루프 종료
마지막입니다.
하지만 오해하지 마세요. GitHub MCP 의 가치는 "git 명령어를 실행할 수 있다"는 것이 아닙니다. Claude Code 는 이미 로컬 git 과 GitHub CLI 를 다룰 수 있습니다.
가치는 원격에만 있는 정보를 횡단할 때 발생합니다: 이슈 세부 사항, PR 리뷰 코멘트, CI 결과, 다른 저장소 상태, 내부 코드 검색, 과거 논의.
실용적인 프롬프트:
GitHub MCP 로 현재 브랜치에 해당하는 PR 을 확인하세요.
해결되지 않은 모든 리뷰 코멘트를 가져와 다음 세 가지로 분류하세요:
- 반드시 수정해야 할 사항
- 설계 결정이 필요하여 제가 결정해야 할 사항
- 수정이 필요하지 않다고 판단되는 사항 (이유 포함)
"반드시 수정해야 할 사항"만 구현하고 테스트를 통과시키세요.
설계 결정이 필요한 사항은 건드리지 말고, 쟁점과 옵션을 정리하여 제시하세요.
리뷰 코멘트 읽기, 수정, 테스트, 보고 — 모두 Claude Code 내에서 완료됩니다.
공식 저장소: https://github.com/github/github-mcp-server
단일 도구가 아닌 "스택" 구축
MCP 는 하나씩 추가할 때 효과가 덜합니다. 워크플로우에 따라 배열될 때 비로소 변화를 만듭니다.
웹 프로덕션 스택:
Figma 에서 디자인 가져오기 → Context7 로 현재 올바른 문법 확인 → Claude Code 에서 구현 → Playwright 로 브라우저 검증 → GitHub 에서 PR 및 리뷰 응답 → Cloudflare 에서 배포 및 로그 확인
SaaS 개발 스택:
Linear 에서 요구사항 가져오기 → Context7 로 기술 사양 확인 → Claude Code 에서 구현 → Stripe 로 결제 설정 및 검증 → Playwright 로 사용자 작업 테스트 → Sentry 로 프로덕션 에러 모니터링
무슨 일이 일어나고 있나요?
두 스택 모두 프로세스는 동일합니다.
정보를 얻고, 계획하고, 구축하고, 스스로 검증하고, 외부에 반영하고, 결과를 확인합니다.
이 루프는 Claude Code 를 떠나지 않고 완료됩니다.
Boris 의 "검증할 수단을 제공하라"는 단순히 하나의 브라우저를 의미하는 것이 아닙니다. 프로세스의 각 단계에서 정확성을 확인할 수단을 제공하라는 뜻입니다.
초보자는 이 세 가지만 있으면 됩니다
여덟 개를 모두 설치하라는 말이 아닙니다. 그렇게 하면 다음 장의 함정에 빠질 수 있습니다.
단계 1: Context7
목표는 잘못된 코드를 줄이는 것입니다.
읽기 중심이므로 위험이 낮습니다. 여기에서 시작하는 것이 가장 안전하고 효과를 가장 빨리 느낄 수 있습니다.
단계 2: Playwright 또는 브라우저 확장 프로그램
목표는 Claude 가 스스로 결과물을 검증하게 하는 것입니다.
웹 작업을 하고 있다면 이것이 상황을 크게 바꿉니다. 만들고, 열고, 깨진 부분을 찾고, 수정하고, 다시 엽니다. 더 이상 사람이 중간에 있을 필요가 없습니다.
단계 3: Linear 또는 GitHub
목표는 작업의 입력과 출력을 연결하는 것입니다.
티켓에서 구현, PR, 진행 상황 업데이트까지. 이 시점에서 Claude Code 는 "지시를 기다리는 코더"에서 "스스로 작업을 진행하는 멤버"로 변화합니다.
이 세 가지만으로 충분합니다. 진심입니다.
꼭 읽어야 할 함정
함정 1: MCP 가 많다고 더 똑똑해지지는 않습니다
이것이 가장 큰 오해입니다.
방대한 수의 MCP 를 연결하면 Claude 가 선택할 수 있는 도구 후보가 증가합니다. 그러면 어떻게 될까요?
어느 것을 사용해야 할지 혼란스러워집니다. 컨텍스트를 소비합니다. 유사한 도구를 혼동합니다. 요청하지 않은 작업을 수행합니다. 권한 관리는 복잡해지고 무엇이 허용되는지 파악하기 어려워집니다.
100개를 연결하는 대신, 현재 작업에 필요한 3~5개만 활성화하는 것이 더 나은 결과를 얻는 방법입니다. 프로젝트별로 연결된 것을 변경하는 것이 올바른 방법입니다.
(한때 10개 이상 연결했는데 Claude 가 계속 이상한 도구를 호출해서 "왜 갑자기 멍청해졌지?"라고 생각했습니다. 줄이니 해결되었습니다.)
함정 2: 처음부터 읽기와 쓰기를 혼합하지 마세요
초기 도입 시 다음 설계를 반드시 만드세요:
읽기는 허용. 생성은 확인 필요. 업데이트는 확인 필요. 삭제는 거부. 프로덕션 작업은 거부.
구체적으로, 처음부터 완전히 허용해서는 안 되는 것들: 프로덕션 배포, DNS 변경, 고객 데이터 변경, 프로덕션 결제 작업, 이슈 삭제, PR 병합, 데이터베이스 삭제.
MCP 의 편리함과 위험은 완벽하게 비례합니다.
함정 3: 공식 서버와 커뮤니티 제작 서버를 혼동하지 마세요
MCP 검색 사이트에는 동일한 이름의 서버가 여러 개 나타날 수 있습니다. 공식 목록에 있다고 해서 반드시 제공자의 공식 구현인 것은 아닙니다.
설치하기 전에 다음을 확인하세요:
제공자의 공식 조직에서 관리하는가? 마지막 업데이트는 언제인가? 보안 정책이 있는가? 인증 방법은 무엇인가? 얼마나 많은 권한을 요청하는가? 삭제나 프로덕션 변경을 허용하도록 설계되었는가?
권한을 많이 요청할수록 더 주의 깊게 살펴봐야 합니다.
함정 4: 외부 텍스트를 그대로 실행하지 마세요
이슈나 PR 코멘트를 읽어서 구현하는 워크플로우는 강력하지만, 그 내용은 다른 사람이 작성한 텍스트입니다.
이슈에 "이 이슈의 단계를 따르세요"라고 적혀 있고 악성 지시가 포함되어 있다면 Claude 가 읽고 따를 수 있습니다. 외부 입력을 처리하는 MCP 의 경우 직접 실행하지 말고, 먼저 수행하려는 작업을 제시하도록 하세요.
아직 확고하지 않은 영역
과장하지 않고 쓰겠습니다.
MCP 를 통해 장기 실행 작업을 외부 소스에 던지는 시스템은 공식적으로 사양에 포함되어 있지만, 각 서버가 이를 지원하는지는 또 다른 문제입니다. 사양 출시와 구현 따라잡기는 다릅니다. 사용하기 전에 서버의 현재 상태를 확인하세요.
대화 내 UI 반환 시스템도 확장 단계에 있습니다. 현재 시점에서 모든 MCP 가 조작 화면을 반환하는 것은 아닙니다.
또한 가격 및 서비스 약관은 자주 변경됩니다. 사용하기 전에 이 글의 공식 링크를 한 번 방문하세요. 특히 인증 및 권한 범위는 확인하지 않고 연결할 사항이 아닙니다.
"MCP 가 성능을 X 배 향상시킨다"와 같은 숫자도 제시하지 않겠습니다. 입증되지 않았습니다.
대신 이것을 측정하세요: 하루에 몇 분을 복사-붙여넣기, 화면 전환, 시각적 확인에 소비하고 있습니까? 그것이 MCP 로 사라지는 것입니다.
오늘 해야 할 일
모든 것을 하려고 하지 마세요. 단 한 가지만 하세요.
업무를 되돌아보고 "Claude Code 와 다른 화면 사이를 왔다 갔다 하는" 부분을 하나 찾으세요.
문서일 수도 있습니다. 이슈일 수도 있습니다. 에러 화면일 수도 있습니다. 디자인일 수도 있습니다.
그 한 가지를 없애는 MCP 만 설치하세요. 효과를 느낀 후 다음을 추가하세요.
Boris 의 원칙은 궁극적으로 이것으로 요약됩니다: Claude 에게 자신의 작업을 확인할 수단을 주세요. 그 수단을 주는 순간, Claude 는 만족할 때까지 스스로 실행하기 시작합니다.
당신이 멈춰 있는 동안, 오늘도 같은 것을 복사해서 같은 화면에 붙여넣고 있을 것입니다. 그것이 움직이는 순간, 그 왕복 여정은 다시는 돌아오지 않습니다.
오늘 밤, Claude Code 를 열고 가장 자주 이동하는 화면 하나를 생각해보세요.
모든 것은 거기서부터 시작됩니다.
