MCP 도입은 기능 추가가 아니라 예산 배분이다

연결 층은 넷 중에서 성격이 다르다. 커맨드·스킬·훅은 에이전트가 이미 가진 능력을 언제 어떻게 쓸지 정하지만, MCP는 에이전트가 만질 수 있는 대상 자체를 늘린다. 앞 편의 4자 비교표가 MCP 행에만 트리거를 적지 않고 "연결 계층"이라고 쓴 이유가 그것이다.

그래서 판단하는 질문도 다르다. 나머지 셋은 "이 일을 자동화할 것인가"를 묻지만, MCP는 붙일 수 있느냐가 아니라 붙일 자리가 컨텍스트에 있느냐를 묻는다. 이 글은 그 판단을 네 구간으로 나눠 본다 — 왜 표준이 필요했는가, 실무에서 무엇을 붙이는가, 셸 명령이 더 나은 경우는 언제인가, 붙인 도구가 무엇을 잠식하는가.

이 글이 옮긴 원 자료의 작성 기준일은 2026-07-26이고, 그 안의 생태계 규모 수치만 2026년 4월 기준으로 따로 표기돼 있다. 제품 사양·명령·화면은 그 시점의 것이다.

용어 정리

앞 편의 용어표에서 이 글이 쓰는 행만 추렸다.

MCP — 외부 시스템 연결의 표준

왜 필요한가 — N×M 문제

MCP 이전에는 AI 앱과 외부 서비스를 잇는 커넥터를 조합마다 따로 만들어야 했다. AI 앱이 N개, 서비스가 M개면 N×M개의 통합이 필요했다.

각 서비스가 MCP 서버 하나만 만들면 모든 AI 클라이언트가 그대로 쓸 수 있다. 이것이 MCP가 "경쟁 제품"이 아니라 HTTP 같은 공통 규격으로 자리 잡은 이유다.

표준화 궤적

네 행 중 마지막이 성격이 다르다. 앞 셋은 개별 벤더가 규격을 발표하고 채택하고 지원한 사건이고, 마지막은 관리 주체가 특정 벤더에서 중립 재단으로 넘어간 사건이다. 뒤에 나올 선별 5기준에서 「유지보수 주체」가 한 항목을 차지하는 것도 같은 축을 본다. 이 연결은 원 자료에 없다. 두 표를 나란히 놓고 이 글에서 묶은 것이다.

원 자료가 인용한 생태계 규모(2026년 4월 기준): 활성 서버 12,000개 이상, 월간 SDK 다운로드 9,700만 건.

이 두 수치는 원 자료가 인용한 값이며, 원 자료 스스로 직접 측정치가 아니라고 밝히고 있다.

아키텍처 3요소

Client ↔ Server는 1:1이지만 Host가 여러 Client를 관리하므로 여러 서버를 동시에 쓸 수 있다. 오른쪽 열이 셋 중 하나에만 값이 있다는 점이 실무의 요약이다 — 사용자가 실제로 결정하는 것은 서버 목록뿐이다.

3가지 Primitives

원 자료의 정리는 이렇다 — Tools만 알아도 MCP 활용의 90%는 가능하다.

전송 방식 — stdio vs HTTP

2026년 기준 흐름은 원격 방식으로 이동 중이다. Azure·Google Cloud·AWS의 공식 MCP가 모두 원격 방식으로 출시됐다.

스코프

조직 관점에서 의미 있는 건 project다. .mcp.json을 커밋하면 신규 입사자가 클론만 해도 동일한 도구 환경을 갖게 된다.

필수 MCP 6종 — 무엇을 왜 붙이는가

6종 요약표

맨 오른쪽 열이 설치 순서와 이어진다.

여섯 행 중 인증이 불필요한 것이 셋(Context7·Playwright·YouTube Transcript), 브라우저 로그인이 필요한 것이 셋이다. 뒤의 인증 절에서 이 3:3이 그대로 순서가 된다.

설치 명령 패턴

# 원격 HTTP 방식 — URL만 등록
claude mcp add --transport http notion https://mcp.notion.com/mcp
claude mcp add --transport http supabase https://mcp.supabase.com

# 로컬 stdio 방식 — 실행 명령을 등록
claude mcp add context7 -- npx -y @upstash/context7-mcp@latest
claude mcp add playwright -- npx @playwright/mcp@0.0.41
claude mcp add youtube-transcript -- npx @fabriqa.ai/youtube-transcript-mcp@latest

설정 파일로 직접 관리할 수도 있다. 팀 공유용은 프로젝트 루트의 .mcp.json에 둔다.

{
  "mcpServers": {
    "notion":   { "type": "http", "url": "https://mcp.notion.com/mcp" },
    "supabase": { "type": "http", "url": "https://mcp.supabase.com" },
    "context7": { "command": "npx", "args": ["-y", "@upstash/context7-mcp"] },
    "playwright": { "command": "npx", "args": ["@playwright/mcp@0.0.41"] }
  }
}

주의: API 키·토큰은 설정 파일에 직접 쓰지 않는다.

반드시 ${ENV_VAR} 형태로 환경변수를 참조하고, 비밀값은 커밋 대상이 아닌 로컬 설정 파일로 분리한다.

인증 방식 3종

설치 순서는 무인증 3종 먼저 → OAuth 3종 나중이 효율적이다. 무인증은 바로 동작 확인이 되므로 환경 문제를 먼저 걸러낼 수 있다.

권한 설계에서 주목할 점

부서별 배급 관점

원 자료는 7개 부서 × 6종 MCP 매트릭스로 "필요한 것만 배급"을 강조한다. 요지는 다음과 같다.

전원에게 전부 주지 않는다는 원칙이 핵심이다. 이유는 보안뿐 아니라 뒤에 나올 토큰 비용 때문이다.

트러블슈팅 3대 문제

진단은 다음 순서로 좁힌다.

claude mcp list                       # 등록 목록·상태
node --version                        # 런타임 버전 (18+ 필요)
rm -rf ~/.npm/_npx                    # 캐시 초기화
npx -y @upstash/context7-mcp --help   # 패키지 단독 실행 확인

gws — Google Workspace를 CLI로 붙이기

MCP 커넥터 vs gws CLI

판단 기준은 간단하다. 대화 중 편의는 커넥터, 자동화 파이프라인은 CLI다. 훅이나 배치에서 쓰려면 CLI여야 한다.

단일 호출 패턴

gws는 Google의 REST API 전체를 하나의 문법으로 감싼다.

gws <서비스> <리소스> <메서드> --params '<JSON>'

인증 시 스코프를 지정한다는 점이 중요하다. 나중에 필요한 서비스가 추가되면 스코프 누락 오류가 나므로 통합 재인증이 필요하다.

대표 명령

# Drive 검색
gws drive files list \
  --params '{"q": "name contains '\''보고서'\''", "pageSize": 10}'

# Sheets 데이터 추가
gws sheets spreadsheets values append \
  --params '{"spreadsheetId":"ID","range":"Sheet1!A1","valueInputOption":"USER_ENTERED"}' \
  --json '{"values":[["이름","점수"],["홍길동",95]]}'

# Gmail 읽음 처리
gws gmail users messages modify \
  --params '{"userId":"me","id":"MSG_ID"}' \
  --json '{"removeLabelIds":["UNREAD"]}'

End-to-End 파이프라인 구조

원 자료의 통합 예제는 네 단계를 컨베이어 벨트처럼 잇는다. 각 단계의 출력이 다음 단계의 입력이 된다.

이 구조가 시사하는 바는 AI가 분석 엔진이 아니라 파이프라인의 한 스테이지라는 점이다. 앞뒤는 결정론적 CLI가 맡고, 판단이 필요한 중간만 AI가 맡는다. 재현성과 디버깅 관점에서 중요한 설계다.

실무 함정

앞의 트러블슈팅 표와 형태는 같은데 걸리는 층이 다르다.

MCP 쪽 세 증상은 연결 자체가 서지 않는 문제(인증·런타임·팝업)이고, CLI 쪽 다섯 증상은 연결이 선 다음에 나는 문제다 — 인증 스코프, 대상 문서의 공유 설정, 데이터 형식 셋으로 갈린다. 두 표를 이렇게 층으로 나눈 것은 이 글의 정리이며, 원 자료는 두 표를 나란히 둘 뿐이다.

마켓플레이스와 선별 기준 — 거버넌스가 시작되는 곳

마켓플레이스 3곳

용도가 갈린다. 탐색은 mcp.so, 설치는 Smithery, 검증은 GitHub 공식 저장소.

품질 평가 5기준

원칙은 C등급 항목이 하나라도 있으면 보안 체크리스트를 반드시 실행한다는 것이다. 공식 벤더 제공물은 체크리스트를 건너뛸 수 있다.

보안 실태 — 66%

원 자료가 인용한 2026년 초 스캔 결과: 1,808개 MCP 서버 중 66%에서 보안 취약점 발견.

이 스캔 결과는 원 자료가 인용한 값이며, 원 자료 스스로 직접 측정치가 아니라고 밝히고 있다.

관련 위협 용어로 Tool Poisoning(정상처럼 보이나 숨은 악성 명령 포함)과 공급망 공격(유사 패키지명 배포)이 함께 제시된다.

원칙은 하나다.

공식 벤더 우선. 비공식은 체크리스트 통과 후 설치.

최소 확인 3항목: 소스가 공개되어 있는가, API 키가 환경변수로 처리되는가, 최소 권한 원칙이 적용되어 있는가.

도입 의사결정 흐름

첫 분기가 가장 중요하다. CLI 한 줄로 되는 일에 MCP를 붙이는 것이 가장 흔한 낭비다. 앞 절의 gws가 그 분기의 실물이다 — 같은 서비스를 커넥터로도 CLI로도 붙일 수 있고, 훅과 배치에서 쓸 것이라면 답이 이미 정해져 있다.

흔한 실수와 토큰 예산

원 자료가 인용한 벤치마크: MCP는 CLI 대비 최대 35배 토큰을 더 소비하며, 도구가 많은 대형 서버 하나가 55,000 토큰을 소모한 사례가 있다.

이 벤치마크 수치 둘도 원 자료가 인용한 값이며, 원 자료 스스로 직접 측정치가 아니라고 밝히고 있다.

이어지는 원 자료의 판단은 다음과 같다.

이 지점이 리더 입장에서 중요하다. MCP 도입은 기능 추가가 아니라 컨텍스트 예산 배분 결정이다.

도구를 늘릴수록 에이전트가 실제 업무 맥락에 쓸 수 있는 공간이 줄고, 호출당 비용과 지연이 함께 올라간다.

따라서 "붙일 수 있으니 붙인다"가 아니라 "이 도구가 몇 토큰을 상시 점유하고, 그만한 값을 하는가"로 판단해야 한다.

같은 단어 「상시」가 두 자료에서 반대로 쓰인다

이 블로그의 하네스를 만드는 다섯 가지는 세션 시작 비용을 아홉 행으로 분해하는데, **MCP 도구 행만 값이 —이고 옆 칸이 필요 시 로드**다. 그리고 그 표 아래에 이렇게 적혀 있다 — "MCP 도구만 필요 시 로드라 도구를 많이 붙여도 상시 비용이 되지 않는다." 그 글은 2026년 3월 자료 기준임을 스스로 밝히고 있다.

이 글이 옮긴 원 자료는 바로 위 인용에서 반대 방향으로 쓴다 — "이 도구가 몇 토큰을 상시 점유하고, 그만한 값을 하는가"로 판단하라는 것이다. 원 자료 전체는 2026-07-26 작성 기준이나, 해당 절에는 시점 표기가 없다.

두 서술을 합치지 않고 그대로 둔다.

어느 쪽이 맞는지, 혹은 무엇이 달라져서 갈렸는지를 판정할 근거가 두 자료 안에 없다. 병기해 두는 것은 이 글의 처리이며, 원 자료에는 이 대조가 없다.

실무에서 쓸 수 있는 것은 판정이 아니라 확인 방법 쪽이다. 붙인 뒤 컨텍스트 분해를 직접 재 보면 적어도 내 환경에서 MCP 도구가 얼마를 차지하는지는 수치로 나온다.

다음 편

연결 층은 여기까지다. 다음 편은 나머지 셋 — 커맨드·스킬·훅과 이들을 묶는 플러그인 — 을 파일 단위까지 내려가 본다.