핵심 표면
Claude Code
-> MCP server 연결
-> 외부 도구 / 데이터 소스 접근
-> MCP prompt가 slash command로 노출될 수 있음연결 방식
MCP가 "더 많은 도구"보다 "컨텍스트 이동 비용 절감"인 이유
MCP는 외부 도구와 데이터 소스를 연결하는 open standard입니다. 핵심 가치는 "더 많은 도구"가 아니라 "컨텍스트를 옮겨 다니지 않아도 된다"는 점입니다. 디자인 문서, 이슈 트래커, 내부 도구, 문서 저장소가 연결되면 Claude Code가 코드 바깥의 작업 문맥까지 한 세션에서 자연스럽게 다룰 수 있습니다.
MCP 연결이 slash command 인터페이스와 이어지는 구조
MCP와 slash commands의 연결도 중요합니다. 공식 docs에 따르면 MCP 서버가 prompt를 노출하면 Claude Code 안에서 /mcp__server__prompt 형태의 command로 사용할 수 있습니다. 이는 단순 플러그인이 아니라 작업 인터페이스를 확장하는 구조입니다. 데이터 읽기, prompt 재사용, 팀 도구 연결이 모두 한 흐름으로 묶이기 때문에, 자주 쓰는 팀 워크플로를 slash command로 만들어 두면 반복 비용이 크게 줄어듭니다.
MCP server
-> data / tool access
-> reusable prompt
-> /mcp__server__prompt 형태로 노출 가능어떤 도구를 먼저 연결해야 하는가
연결 우선순위는 "실제로 자주 다시 찾는 자료와 도구"를 기준으로 잡아야 합니다. 코딩 작업 중 이슈 트래커를 자주 들락날락한다면 그쪽을 먼저 연결하고, 설계 문서를 자주 참조한다면 문서 저장소를 연결하는 식입니다. 처음부터 연결 수를 늘리면 세션마다 어떤 도구가 활성화되어 있는지 파악하기 어려워지고 권한 관리도 복잡해집니다.
연결이 늘수록 권한 관리를 더 신중히 봐야 하는 이유
MCP 연결이 많아질수록 무엇을 읽을 수 있는지, 어떤 prompt가 자동 노출되는지, 어떤 도구가 세션에 들어오는지를 팀 기준으로 관리해야 합니다. 특히 민감한 내부 데이터가 연결된 MCP 서버는 권한 범위를 좁게 유지하고, 세션마다 활성화된 도구 목록을 /mcp로 확인하는 습관이 필요합니다.
현재 공식 docs 기준으로 /mcp는 단순 목록 확인뿐 아니라 연결 상태 점검, OAuth 인증, 토큰 정리, 사용 가능한 tools/prompts 확인까지 맡습니다. 또한 MCP prompt는 연결된 서버에서 동적으로 발견되므로, 연결 직후 어떤 command가 생겼는지도 /mcp와 / 목록에서 같이 확인하는 편이 안전합니다.
언제 어떤 연결을 쓸까
| 상황 | 적합한 선택 |
|---|---|
| 코드 바깥 맥락을 한 세션에서 다루고 싶을 때 | MCP 서버 연결 |
| 이슈 트래커, 문서 저장소, 내부 도구 접근 | 해당 MCP 서버 추가 |
| 자주 쓰는 팀 워크플로를 명령으로 등록 | MCP prompt → slash command 활용 |
| 연결 도구 현황 확인 | /mcp 명령 사용 |
| 민감 데이터가 포함된 연결 | 권한 범위 최소화 후 연결 |
| 세션마다 거의 안 쓰는 연결 | 나중에 추가하거나 비활성 상태 유지 |
주의할 점
MCP는 연결 수를 늘리는 것이 목표가 아닙니다. 실제로 자주 다시 찾는 자료와 도구부터 연결해야 컨텍스트와 권한 관리가 단순해집니다. 연결이 많아질수록 세션에 어떤 도구가 노출되는지 파악하기 어려워지므로, 기본은 "적게 연결하고 명확하게 쓰기"입니다.
❌ 이슈 트래커, 문서 저장소, 내부 DB, 디자인 도구를 한꺼번에 연결
❌ 어떤 서버가 어떤 prompt를 노출하는지 팀 규칙 없음이 상태는 세션마다 도구 목록이 과도하게 길어지고, 권한과 책임 경계도 흐려지기 쉽습니다.
참고 링크
2 sources