목차
이 글은 Anthropic 엔지니어링 블로그에 2025년 6월 26일 게재된 “Desktop Extensions: One-click MCP server installation for Claude Desktop” 을 읽고, 내용을 정리한 글입니다. 원문: https://www.anthropic.com/engineering/desktop-extensions
한 줄로 말하면 #
MCP 서버 설치를 ‘터미널 + JSON 편집’에서 ‘더블클릭 한 번’으로 바꾸자, 비개발자에게도 문이 열렸다.
어떤 문제를 해결하려 했나 #
MCP(Model Context Protocol, 모델 컨텍스트 프로토콜) 는 Claude에 외부 도구를 붙이는 표준입니다. 노션 검색, 슬랙 메시지 읽기, DB 조회 — 다 MCP 서버로 만들 수 있어요.
문제는, MCP 서버를 설치하려는 일반 사용자가 부딪히는 벽이었습니다.
“이 서버 쓰려면 먼저 Node.js를 설치하시고요. 그다음에 GitHub에서 코드를 받아서요. config.json 파일을 열고 경로를 직접 적어주시고요. 의존성 패키지가 충돌 안 나게 버전을 맞추셔야 하고요…”
비개발자에겐 첫 줄에서 막힙니다. MCP가 아무리 강력해도, 설치 절차 자체가 보급의 장벽이었어요.
해결책: Desktop Extensions (.mcpb 파일) #
핵심 발상은 단순합니다. 앱 설치만큼 쉽게 만들자. 파일 하나 더블클릭, 설치 버튼 한 번 — 끝.
1. 사용자 경험 — Before / After #
[Before]
Node.js 설치 → GitHub 코드 다운로드 → config.json 직접 편집
→ Claude Desktop 재시작 → 의존성 오류 디버깅 → (포기)
[After]
.mcpb 파일 다운로드 → 더블클릭 → "설치" 클릭 → 끝비기술 사용자가 끝까지 도달할 수 있는 절차로 압축됐습니다. 게다가 Claude Desktop에 확장 디렉토리(스토어 형태) 가 내장돼 있어, 파일을 따로 받을 필요도 없습니다.
2. .mcpb 파일이 뭐로 생겼나 #
.mcpb는 사실 그냥 ZIP 파일입니다. 안에 든 건 이렇게 단순해요.
my-extension.mcpb (ZIP)
├── manifest.json ← 메타데이터 (필수)
├── server/ ← MCP 서버 코드
├── dependencies/ ← 의존성 패키지 (번들)
└── icon.png ← 아이콘 (선택)manifest.json에는 확장 이름·버전·필요한 사용자 설정(API 키 등)이 들어갑니다. 사용자 설정은 자동으로 친절한 입력 UI 로 변환돼 보입니다.
"user_config": {
"api_key": {
"type": "string",
"sensitive": true,
"required": true
}
}이렇게 적어두면 Claude Desktop이 자동으로:
- 설치 시 API 키 입력 창을 띄우고
- 민감 정보(
sensitive: true)는 OS 키체인에 저장하고 - 입력값을 서버에 안전하게 전달합니다
개발자 입장에선 npm install -g @anthropic-ai/mcpb 후 mcpb init(대화형 초기화)과 mcpb pack(번들링) 두 명령으로 끝납니다.
3. 보안과 엔터프라이즈 안전장치 #
“누구나 만들어 배포할 수 있다” = “악성 확장도 가능하다"는 문제가 있죠. 이걸 다층 안전장치로 막습니다.
| 계층 | 안전장치 |
|---|---|
| 개인 | 민감 정보는 OS 키체인, 자동 업데이트로 취약 버전 차단 |
| 조직 | Group Policy(Windows) / MDM(macOS)로 허용 목록 사전 설정 |
| 조직 | 특정 확장·게시자 차단, 확장 디렉토리 자체 비활성화 가능 |
| 조직 | 사내 전용 비공개 확장 디렉토리 배포 |
기업에선 “승인된 확장만 설치 가능” 같은 정책을 통째로 걸 수 있어, 보급과 통제를 동시에 잡았습니다.
핵심 결론 #
MCP가 안 퍼지는 이유를 찾을 때, 사람들은 본능적으로 “기능이 부족한가? 더 강력한 도구가 필요한가?“를 묻습니다. 이 글이 보여주는 답은 다릅니다.
“보급의 문제가 기능인 줄 알았는데, 사실은 설치 마찰이 문제였다.”
좋은 도구도 첫 5분 안에 설치되지 않으면 안 쓰입니다. 포장(packaging)이 기술만큼 중요한 결정 요소라는 얘기예요. SWE-bench 글의 “도구 인터페이스 설계가 모델 성능만큼 중요하다"와 정확히 같은 정신입니다.
내 작업에 적용한다면 #
이 글의 본질은 “좋은 도구를 만드는 것 ≠ 보급되는 도구를 만드는 것” 입니다. 포장이 보급을 결정합니다.
시나리오 1 — 일반적인 데이터 분석 과정 #
분석가가 만든 좋은 분석 도구가 본인만 쓰고 사라지는 일이 흔합니다. 동료에게 넘기려고 보면 “파이썬부터 깔아야 하고, 데이터 경로를 환경변수로 잡아야 하고…” 끝없이 막힙니다.
[Before — 보급 안 되는 분석 도구]
Jupyter 노트북 + 환경 설정 README 5페이지
→ 동료가 한 명도 끝까지 설치 못 함
[After — 포장된 분석 도구]
분석 로직을 CLI 또는 컨테이너로 패키징
- 의존성 번들링 (Docker/Poetry/uv)
- 데이터 경로·API 키 같은 사용자 설정은 자동 UI/프롬프트로
- "실행하면 결과 리포트가 나온다"는 단순 인터페이스핵심: 분석 도구의 가치는 “결과를 누가 재현할 수 있느냐"로 결정됩니다. 분석 정확도만큼 재현성 포장에 시간을 들여야 합니다.
시나리오 2 — 웹 사이트를 자동으로 운영할 때 #
운영 자동화 스크립트도 똑같은 함정에 빠집니다. 만든 사람만 알고, 다른 운영자는 손도 못 댑니다.
[Before — 한 사람 머릿속에만 있는 자동화]
"crontab에 등록된 deploy.sh — 경로와 권한은 내가 알아"
→ 만든 사람 휴가 가면 운영 멈춤
[After — 포장된 운영 자동화]
운영 작업을 명시적 단위로 포장
- CMS 플러그인 / GitHub Action / 셸 스크립트 패키지
- 사용자 설정은 단일 설정 파일로 노출 (.env, config.yaml)
- README 첫 줄에 "X 명령 한 번으로 동작" 약속
- 권한·롤백·로그 같은 운영 안전장치 동봉핵심: 자동화는 “내가 안 보는 동안에도 다른 사람이 굴릴 수 있어야” 진짜 자동화입니다. 포장이 안 된 자동화는 결국 한 명의 의존성으로 남습니다.
Anthropic 엔지니어링 블로그를 오래된 순서대로 읽고 정리합니다.
