붙일 수 있다와 붙여야 한다는 다르다 — 확장 메커니즘 12문답
MCP가 무엇을 해결하고 커맨드·스킬·훅이 무엇으로 갈리는지, 도구를 늘리면 무엇이 나빠지고 외부 서버를 무엇으로 거르는지를 결론부터 정리한다. 마지막 셋은 「MCP만 있으면」·「훅이면 완전히」·「스킬이면 자동으로」라는 과신을 교정하는 문항이다.
에이전트에 무언가를 붙이려고 하면 곧바로 네 개의 이름이 한꺼번에 나온다. MCP·커맨드·스킬·훅이다. 이름이 넷이라 어려워 보이지만 갈리는 축은 하나뿐이고, 정작 어려운 것은 그다음 — 무엇을 몇 개까지 붙일 것인가 쪽이다.
이 글은 확장 메커니즘에 걸린 열두 문항에 결론부터 답한다. 넷 중 셋은 오해를 교정하는 문항이다. "MCP만 붙이면 된다", "훅을 걸면 보안이 끝난다", "스킬이면 알아서 돈다" 같은 직관이 왜 절반만 맞는지가 실제로는 더 자주 문제가 된다.
도입 순서와 규약 파일은 도입과 표준화 Q&A, 에이전트 설계와 멀티에이전트는 에이전트 설계 Q&A, 운영·권한·비용·장애는 운영과 거버넌스 Q&A에 있다. 수치마다 그 값의 출처 성격을 먼저 밝히는 규칙은 도입과 표준화 Q&A의 마지막 문항에 있다.
핵심 판정 기준 정리
확장 구간에서 반복해 등장하는 갈림길들이다. 값이 아니라 무엇으로 가르는가가 요점이다. 아래 분류는 이 글이 열두 문항을 배열하며 정리한 것이다.
| 판정 | 기준 | 왜 그 기준인가 |
|---|---|---|
| 넷 중 무엇을 쓰나 | 누가 트리거하는가 | 사람(커맨드) / AI(스킬) / 이벤트(훅). MCP는 트리거가 아니라 연결 계층이다 |
| 예외 없이 걸려야 하나 | 훅만 차단할 수 있다 | 나머지 셋은 실행을 끊는 능력이 없다. 그래서 규정은 훅에 둔다 |
| 도구를 하나 더 붙일까 | 상시 점유하는 토큰만큼 값을 하는가 | 도구 정의는 쓰지 않아도 매 세션 자리를 차지한다 |
| 외부 서버를 쓸까 | 유지보수 주체와 최근 업데이트 | 스타 수는 방치 여부를 말해 주지 않는다 |
| 도구가 안 붙을 때 | 본체와 도구의 의존성이 다르다 | 앱이 아니라 도구 쪽 런타임·경로를 먼저 본다 |
| 에이전트를 어디에 놓나 | 판단이 필요한 구간에만 | 앞뒤가 결정론적이어야 재현과 디버깅이 된다 |
| 스킬이 안 불릴 때 | description이 라우팅 키 | 짧으면 매칭이 안 된다 |
| 스킬을 얼마나 설계할까 | 필요해진 뒤에 요소를 늘린다 | 차이는 완성도가 아니라 필요 여부다 |
| 차단으로 끝인가 | 대안까지가 한 세트 | 사유 없이 막으면 같은 시도가 반복된다 |
Q. MCP는 무엇을 해결하는 프로토콜인가
AI 앱과 외부 서비스를 잇는 연결의 개수를 N×M에서 M으로 줄이는 표준이다.
이전에는 조합마다 커넥터를 따로 만들어야 했다. AI 앱이 N개, 서비스가 M개면 통합이 N×M개 필요하다. 각 서비스가 서버를 하나만 만들면 모든 클라이언트가 그대로 쓸 수 있고, 그러면 M개로 끝난다. MCP가 "경쟁 제품"이 아니라 공통 규격으로 자리 잡은 이유가 여기 있다.
프로토콜 3요소와 전송 방식·스코프, 실무 서버들의 인증·권한 설계는 MCP 도입은 예산 배분이다에 있다.
Q. Commands·Skills·Hooks·MCP는 무엇으로 갈리나
누가 트리거하는가 하나로 갈린다. MCP는 그 축 위에 있지 않다 — 연결 계층이다.
트리거 주체가 사람이면 커맨드, 모델의 판단이면 스킬, 런타임 이벤트면 훅이다. 그리고 넷 중 실행을 끊을 수 있는 것은 훅뿐이므로 편의는 커맨드와 스킬에, 보안과 규정은 훅에 둔다. 넷을 한 번에 배포하는 번들이 플러그인이다.
트리거 주체·실행 보장·차단 능력을 한 표에 놓은 대조는 누가 트리거하는가, 각각의 파일 구조와 배포는 커맨드·스킬·훅과 플러그인 번들에 있다.
Q. 도구를 많이 붙이면 무엇이 나빠지나
쓰지 않는 도구도 매 세션 토큰을 점유한다. 그래서 도구를 늘리는 것은 기능 추가가 아니라 예산 배분 결정이다.
도구 정의는 호출 여부와 무관하게 컨텍스트에 상주한다.
판단 기준은 "붙일 수 있으니 붙인다"가 아니라 "이 도구가 상시 점유하는 토큰만큼 값을 하는가" 다. CLI 대비 토큰 배수와 대형 서버 하나가 소모한 실측치, 원 자료의 권장 운영선 수치는 MCP 도입은 예산 배분이다에 있다.
Q. 외부 MCP 서버는 무엇을 보고 고르나
유지보수 주체와 최근 업데이트가 먼저다. 스타 수는 방치 여부를 말해 주지 않는다.
원 자료는 다섯 기준(스타 수·최근 업데이트·유지보수 주체·도구 수·문서 품질)을 등급으로 매기고, C 등급이 하나라도 나오면 보안 체크리스트를 돌린다.
경계할 근거도 함께 제시된다. 원 자료가 인용한 외부 스캔 조사에서 공개 MCP 서버의 취약점 비율과 유형별 분포가 보고됐다.
각 기준이 무엇을 대신 재는지, 등급 임계값과 그 스캔 실태 수치, 붙이기 전 최소 확인 항목은 MCP 도입은 예산 배분이다에 있다.
Q. MCP 도구가 동작하지 않으면 어디부터 보나
에이전트 본체가 아니라 도구 쪽 런타임부터다. 둘은 의존성이 다르다.
에이전트 앱은 단독으로 설치·실행되지만 도구 서버 다수는 별도 런타임 위에서 기동한다. 그래서 "앱은 깔았는데 도구가 안 붙는" 상황의 1순위 원인은 설정이 아니라 런타임 부재나 경로 미등록이다. 원 자료의 비유로는 건물은 지었는데 전기가 안 들어온 사무실이다.
런타임과 경로를 확인한 다음이 연결 계층이다 — 전송 방식이 맞는지, 어느 스코프에 등록됐는지 순으로 좁힌다. 전송 방식과 스코프의 구분은 MCP 도입은 예산 배분이다에 있다.
Q. 에이전트는 파이프라인의 어느 자리에 서나
판단이 필요한 중간 구간에만 선다. 앞뒤는 결정론적 명령이 맡는다.
데이터를 읽어 오고, 분석하고, 문서를 만들고, 발송하는 네 단계짜리 흐름을 놓고 보면 AI가 필요한 것은 두 번째 하나다. 나머지는 같은 입력에 같은 출력이 나와야 하는 구간이라 CLI가 맡는 편이 낫다. 이 배치의 실익으로 원 자료가 드는 것은 재현성과 디버깅이다.
AI를 분석 엔진이 아니라 파이프라인의 한 스테이지로 보는 관점의 상세는 MCP 도입은 예산 배분이다에 있다.
Q. 스킬이 잘 호출되지 않는 이유는 무엇인가
description이 라우팅 키인데 너무 짧기 때문이다.
스킬은 AI가 상황을 보고 스스로 여는 문서다. 그 판단의 입력이 description 한 필드다. 두 단어짜리 한 줄이면 매칭할 근거가 없어 선택되지 않는다.
원 자료의 description 작성 요령 세 가지와 스킬 파일의 구조, 나머지 필드는 커맨드·스킬·훅과 플러그인 번들에 있다.
Q. 스킬은 처음부터 정교하게 설계해야 하나
아니다. 파일 하나로 먼저 돌리고 필요해진 뒤에 요소를 늘린다.
먼저 SKILL.md 한 장으로 돌리고 참조 문서와 스크립트는 필요해진 뒤에 붙인다. 차이는 완성도가 아니라 필요 여부다.
한 장짜리와 요소를 다 갖춘 것이 둘 다 동작한 비교 사례, 복잡도 점진 3단계와 각 단계를 올리는 조건은 커맨드·스킬·훅과 플러그인 번들에 있다.
Q. 위험한 명령은 실제로 무엇이 막나
패턴 판정 → 종료코드 차단 → 대안 제시까지가 한 세트다. 셋째가 빠지면 같은 시도가 반복된다.
훅은 도구 실행 직전에 입력에서 실제 명령을 꺼내 정규식으로 검사하고, 위반이면 종료코드 2로 도구 호출을 끊는다. 원 자료의 판정 규칙은 일곱 개다.
설계상 중요한 것은 차단 자체가 아니라 차단 사유를 함께 돌려준다는 점이다. 사유와 대체 수단이 함께 오지 않으면 에이전트는 우회를 시도하고, 사유에 "팀 리드에게 문의"처럼 다음 행동이 적혀 있으면 사람에게 에스컬레이션한다.
일곱 개 정규식이 각각 무엇을 겨냥하는지, 차단 규칙 전문과 훅 5종의 배치는 Rules·Hooks·Skills 3계층에, 선언형 권한 정책과 훅이 이루는 층은 deny가 항상 이긴다에 있다.
Q. MCP만 붙이면 되는 것 아닌가
연결은 된다. 다만 토큰 예산과 권한 설계가 함께 따라온다.
MCP는 접근 대상을 늘리는 계층이지 통제하는 계층이 아니다. 연결한 순간 둘이 같이 생긴다 — 도구 정의가 상시 점유하는 컨텍스트, 그리고 그 서버가 만질 수 있는 범위다. 어느 쪽도 프로토콜이 대신 정해 주지 않는다.
붙이는 순서도 뒤집히기 쉽다. 원 자료의 도입 순서는 연결 대상을 최소로 정하고 안전장치를 자동화보다 먼저 거는 쪽이다. 그 순서의 근거는 누가 트리거하는가, 예산으로 보는 판단은 MCP 도입은 예산 배분이다에 있다.
Q. 훅으로 보안이 완전히 보장되나
아니다. 타임아웃 시 통과 처리라 가용성이 우선하는 설계다.
훅은 이벤트가 나면 예외 없이 실행되지만, 그 실행이 제때 끝나지 않으면 작업이 멈추는 대신 통과된다. 즉 훅은 "반드시 걸리는 장치"이지 "절대 뚫리지 않는 장치"가 아니다. 훅이 늘수록 지연이 쌓인다는 문제도 같은 축에 있어, 매처로 적용 범위를 좁히는 운영이 함께 필요하다.
그래서 훅만으로 끝내지 않고 서버 쪽 권한 통제를 함께 건다. 클라이언트에서 거는 게이트와 서버가 애초에 허용하지 않는 범위는 다른 층이고, 한쪽이 열려도 다른 쪽이 남아야 한다.
타임아웃이 통과 방향으로 설계된 근거는 커맨드·스킬·훅과 플러그인 번들, 매처로 적용 범위를 좁히는 운영 규약과 지연 문제는 Rules·Hooks·Skills 3계층에 있다.
Q. 스킬이면 다 자동으로 되나
아니다. 트리거가 확률적이다.
스킬은 AI가 상황을 보고 여는 것이라 열리지 않을 수 있다. 앞의 문항처럼 description을 고치면 확률은 올라가지만 1이 되지는 않는다. 그러므로 판정은 성능이 아니라 요구 수준으로 한다 — 반드시 실행돼야 하는 일이면 스킬에 두지 않는다.
이 판정은 이 편 두 번째 문항의 트리거 축과 같은 것이다. 스킬이 안 걸린다는 증상의 해법이 두 갈래인 이유가 여기 있다 — 확률을 올리든지, 결정론적인 층으로 옮기든지다. 옮길 때의 형태는 커맨드·스킬·훅과 플러그인 번들과 누가 트리거하는가에 있다.
용어 정리
| 용어 | 뜻 |
|---|---|
| MCP | AI 앱과 외부 시스템을 잇는 표준 연결 규격. 통합 수를 N×M에서 M으로 줄인다 |
| N×M 문제 | 클라이언트 N개와 서비스 M개를 조합마다 따로 이어야 했던 상태 |
| MCP 서버 | 특정 서비스를 MCP 규격으로 노출하는 프로세스. 도구 목록을 제공한다 |
| 커맨드 | 사람이 이름으로 호출하는 수동 워크플로우 파일 |
| 스킬 | 모델의 판단으로 열리는 절차 문서(SKILL.md) |
description | 스킬의 라우팅 키. 이 필드로 호출 여부가 판정된다 |
| 훅(Hook) | 런타임 이벤트에 걸리는 스크립트. 도구 실행 직전 단계에서 차단할 수 있다 |
| 종료코드 2 | 훅이 도구 실행을 거부하는 신호 |
| 플러그인 | 위 넷을 한 벌로 묶어 배포하는 번들 |
| 스코프 | 설정이 적용되는 범위(개인·프로젝트·조직). 팀 표준은 프로젝트 이상에 둔다 |
| Tool Poisoning | 정상처럼 보이지만 숨은 악성 명령을 포함한 도구 |
| 토큰 예산 | 도구 정의가 상시 점유하는 컨텍스트를 한정된 자원으로 다루는 관점 |
여기까지가 "무엇을 붙이고 무엇으로 막나"의 판단이다. 붙이고 나면 다음 질문은 "그 도구들을 누가 들고 일하나"로 옮겨 간다. 에이전트 한 명을 어떻게 규정하고, 여럿을 어떤 구조로 묶고, 사람이 최종 결정하는 자리를 어디에 두는지는 에이전트 설계 Q&A에서 이어 다룬다.