Skill MCP 컨텍스트 로딩Skill and MCP Context Loading
📅
들어가기 전에 🔗
코딩 에이전트에 스킬과 MCP 서버를 여러 개 연결해 두면, 사용하지도 않은 기능이 매번 컨텍스트를 차지한다고 생각하기 쉽습니다.
하지만 실제 비용은
언제 무엇이 로드되는지
에 따라 달라집니다.
스킬의 짧은 설명, MCP 도구의 정의, 도구를 호출한 뒤 받은 결과는 서로 다른 정보입니다.
이 셋을 한 덩어리로 취급하면 잘못된 부분을 줄이게 됩니다.이번 글에서는 Skill과 MCP의 로딩 경로를 나누어 보고, 실제 작업에서 어떤 부분을 먼저 점검해야 하는지 정리합니다.
Skill 메타데이터에서 전체 지침으로, MCP 서버 설명에서 도구 정의와 호출 결과로 이어지는 로딩 단계
로딩 단계 🔗
컨텍스트 절약은 정보를 무조건 줄이는 일이 아니라, 필요한 정보를 필요한 단계에 배치하는 일입니다.
Skill은 반복 작업의
방법
을, MCP는 외부 데이터 조회와 실행 도구
를 제공합니다.
OpenAI Docs에 따르면 모델은 먼저 Skill의 이름과 설명을 보고, 요청에 맞을 때 전체 지침을 읽습니다.
MCP 서버는 도구와 데이터에 접근하는 역할을 하며, Skill은 그 도구를 어떤 순서와 기준으로 사용할지 안내합니다.
OpenAI Developers의 Skill과 MCP 역할 설명↗| 단계 | Skill | MCP |
|---|---|---|
| 발견 | 이름·설명으로 적합성 판단 | 서버·도구 설명으로 기능 탐색 |
| 선택 | SKILL.md와 필요한 참조 문서 로드 | 필요한 도구 정의 로드 |
| 실행 | 지침에 따라 작업 수행 | 도구 호출 결과가 컨텍스트에 추가 |
여기서 중요한 점은
도구 정의를 늦게 불러오는 것과 호출 결과를 작게 받는 것은 다른 최적화
라는 점입니다.
정의를 아껴도 한 번의 검색 결과가 지나치게 길면 다시 컨텍스트가 커집니다.Skill 설계 🔗
Skill의 설명은 기능 목록 전체가 아니라,
어떤 요청에서 이 스킬을 써야 하는지
알려주는 짧은 표지판입니다.
설명이 모호하면 모델이 불필요한 스킬을 읽거나 필요한 스킬을 놓칠 수 있습니다.
OpenAI는 스킬 설명을 명확하고 짧게 쓰고, 상세 절차와 예시는 필요한 때 읽는 참조 파일로 나누라고 권장합니다.
OpenAI Developers의 스킬 컨텍스트 설계↗review-pr/
├── SKILL.md
├── references/
│ ├── security.md
│ └── performance.md
└── scripts/
└── summarize-diff.sh예를 들어 PR 리뷰를 요청했을 때
SKILL.md는 검토 순서와 결과 형식을 알려줍니다.
보안 변경이면 references/security.md를, 성능 변경이면 references/performance.md를 읽으면 됩니다.
모든 리뷰에서 두 문서를 모두 읽도록 지시하면 작은 문구 수정에도 같은 비용을 반복합니다.---
name: review-pr
description: PR의 코드 변경을 리뷰하고, 동작 오류와 검증 누락을 찾을 때 사용합니다.
---
변경된 코드와 관련 테스트를 확인합니다.
인증·권한 변경이면 references/security.md를 읽습니다.
성능 경로 변경이면 references/performance.md를 읽습니다.👍
참조 파일을 분리했더라도 SKILL.md에 “작업 전 references 전체를 읽는다”라고 적으면 효과가 없습니다. 읽을 조건까지 함께 적어야 합니다.
Skill의 짧은 설명과 작업별 참조 문서 로딩을 비교한 인포그래픽
MCP 도구 🔗
MCP는 외부 시스템의 기능을 도구로 노출합니다.
도구가 많으면 이름, 설명, 입력 스키마 같은 정의가 컨텍스트를 차지할 수 있습니다.
OpenAI의 Tool Search 문서는 큰 도구 목록에서 정의를 필요할 때 불러오면 토큰 사용을 줄일 수 있다고 설명합니다.
다만 검색 단계가 추가되며, 사용 가능한 설정은 실행 환경마다 다릅니다.
OpenAI Docs의 Tool Search 가이드↗
Claude Code도 MCP 도구 검색으로 정의를 지연 로드하며, 도구 이름과 서버 지침을 먼저 보고 필요한 도구를 찾는 방식을 문서화합니다.
Claude Code의 MCP 도구 검색 문서↗
따라서 실무에서 순서는 이렇습니다.
- 자주 쓰는 도구와 드물게 쓰는 도구를 구분합니다.
- 서버·도구 이름과 설명에 실제 사용 조건을 적습니다.
- 실행 환경이 제공하는 도구 검색 또는 허용 도구 설정을 확인합니다.
- 도구 호출 결과에서 불필요한 본문과 필드를 줄입니다.
예를 들어 “이번 PR의 실패한 CI만 확인”하는 작업에는 전체 빌드 로그보다 실패한 작업 이름, 오류 메시지, 관련 로그 링크가 먼저 필요합니다.
상세 로그는 원인을 좁힌 다음 호출하는 편이 효율적입니다.
🖐️
도구 정의를 지연 로드한다고 외부 서버의 응답 크기까지 자동으로 줄어들지는 않습니다. 토큰 절약 효과를 판단할 때는 도구 목록과 호출 결과를 함께 확인합니다.선택 기준 🔗
Skill과 MCP 중 무엇을 추가해야 할지 헷갈릴 때는 정보의 성격으로 판단합니다.
| 필요한 것 | 적합한 위치 | 예시 |
|---|---|---|
| 반복 가능한 작업 순서 | Skill | PR 리뷰 절차와 출력 형식 |
| 작업에 따라 선택할 상세 지침 | Skill 참조 파일 | 보안 리뷰 체크리스트 |
| 현재 상태의 조회·실행 | MCP 도구 | CI 결과 조회, 이슈 생성 |
| 저장소 전체의 공통 규칙 | AGENTS.md | 테스트 명령, 변경 경계 |
예를 들어 “CI 실패 원인 분석”은 스킬 하나와 MCP 서버 하나를 함께 쓸 수 있습니다.
스킬은 분석 순서를 정하고, MCP는 현재 CI 결과를 가져옵니다.
두 역할을 구분하면 정적인 절차를 매번 외부에서 길게 받아오거나, 실시간 데이터를 스킬 파일에 복사하는 일을 피할 수 있습니다.
Skill 지침과 MCP 도구를 선택하고 호출 결과를 줄이는 의사결정 인포그래픽
점검 방법 🔗
설정을 바꾼 뒤에는 실제로 비용과 품질이 함께 나아졌는지 확인합니다.
단순한 작업, 외부 데이터가 필요한 작업, 복합 작업을 하나씩 정해 같은 조건에서 비교하면 됩니다.
- 새 세션에서 기본으로 노출되는 Skill 설명과 MCP 도구 정의를 확인합니다.
- 작업 중 실제로 로드된 Skill 본문과 참조 파일을 기록합니다.
- 호출한 도구와 응답 크기, 입력 토큰, 총 소요 시간을 비교합니다.
- 정답률이나 검증 누락이 악화되지 않았는지 함께 봅니다.
토큰 수만 줄고 필요한 도구를 못 찾게 되면 최적화에 실패한 것
입니다.
작업 완수율과 응답 시간을 함께 보아야 합니다.
OpenAI Docs도 도구 로딩 방식을 고를 때 대표 작업으로 완수율, 입력 토큰, 지연 시간을 비교하라고 권장합니다.
OpenAI Docs의 도구 로딩 전략↗결론 🔗
Skill과 MCP의 컨텍스트 비용은 설치 개수만으로 판단할 수 없습니다.
설명 메타데이터 → 전체 지침·도구 정의 → 호출 결과
의 순서로 무엇이 실제로 들어오는지 확인해야 합니다.Skill에는 짧은 진입점과 조건부 참조 문서를 두고, MCP에는 찾기 쉬운 도구 설명과 필요한 만큼의 결과를 돌려주는 설계를 적용해 보시기 바랍니다.