누가 트리거하는가 — 확장 메커니즘을 가르는 하나의 축

에이전트에 기능을 붙이는 방법은 하나가 아니다. 같은 일을 슬래시 명령으로 만들 수도 있고, AI가 알아서 읽는 문서로 둘 수도 있고, 이벤트에 걸리는 스크립트로 박아 둘 수도 있다. 셋 다 "자동화"라고 불리는데 동작 시점과 실행 보장은 서로 다르다.

여기에 외부 시스템을 붙이는 MCP까지 더하면 넷이 된다. 이 글은 그 넷 — MCP·커맨드·스킬·훅 — 을 하나의 축으로 가른다. 누가 트리거하는가. 축이 하나면 선택이 판단 흐름도로 정리되고, 그러면 "무엇이 더 좋은가"라는 질문이 "이 일은 어느 칸인가"로 바뀐다. 마지막으로 그 넷을 한 단위로 묶어 배포하는 플러그인과, 조직이 이것들을 세우는 순서를 본다.

이 시리즈는 원 자료 작성 기준일(2026-07-26) 정리다. 제품 사양·명령·화면은 그 시점의 것이다. 원 자료 안에서 생태계 규모 수치만 2026년 4월 기준으로 따로 표기돼 있고, 그 수치는 MCP 편에서 각주와 함께 다룬다.

용어 정리

이 시리즈 전체에서 반복되는 용어를 먼저 정리한다. 뒤의 두 편은 여기서 각자 쓰는 행만 다시 추린다.

한눈에 보기 — 확장 메커니즘 4종 지도

AI 에이전트를 실무에 투입할 때 손대는 지점은 결국 네 곳이다. 무엇에 연결할 것인가(MCP), 사람이 언제 부를 것인가(Commands), AI가 언제 알아서 할 것인가(Skills), 무조건 걸리게 할 것인가(Hooks).

핵심은 플러그인이 나머지 넷을 감싸는 배포 단위라는 점이다. 개별 설정을 다섯 군데에 흩어 두는 대신, 하나의 매니페스트로 묶어 조직에 배포한다.

층위 정리

4자 비교 — 판별 축은 "누가 트리거하는가"

Commands·Skills·Hooks·MCP는 이름만으로는 경계가 흐릿하다. 판별 축은 "누가 트리거하는가" 하나다. 정확히는 이 축이 가르는 것은 셋이고, MCP는 축 위가 아니라 그 아래 연결 층에 있다 — 아래 표의 MCP 행에 트리거 대신 「연결 계층」이 적힌 이유다.

성질 비교

굵게 표시된 두 칸이 모두 훅 열에 있다.

「실행 보장」과 「차단 능력」이 그 두 행이다. 나머지 셋은 차단 능력이 모두 「없음」으로 적혀 있고, 이 차이가 정책을 어디에 둘 것인가를 가른다. 같은 일을 세 가지로 만들 수 있어도, 반드시 걸려야 하는 일은 갈 곳이 하나뿐이라는 뜻이다.

선택 판단 흐름도

한 문장 요약

반복 업무를 원클릭으로 → Commands.

AI가 상황 보고 전문 기술을 써 주길 → Skills.

보안·품질 정책을 항상 자동으로 → Hooks.

AI가 만질 수 있는 시스템 자체를 늘리려면 → MCP.

다섯으로 세는 목록과 넷으로 세는 목록

같은 대상을 다른 수로 세는 자료가 이 블로그 안에 이미 있다. 하네스를 만드는 다섯 가지는 메모리·스킬·에이전트·커맨드·훅 다섯을 든다. 이 글의 원 자료는 MCP·Commands·Skills·Hooks 넷을 놓고, 그 위에 배포 층으로 플러그인을 더한다. 두 목록이 겹치는 것은 셋이다.

두 목록이 어긋나는 이유는 열거 기준이 다르기 때문이다. 하네스 쪽은 컨텍스트 관리를 상위 목적으로 공유하는 수단을 묶는다 — 그 글의 도식은 다섯 위에 Context Management (WHY) 한 노드를 두고, "최상위 노드가 다섯 중 하나가 아니라 다섯의 이유라는 점이 이 도식의 전부"라고 적는다. 이 글은 무엇을 확장 가능한가로 센다. 기준이 다르면 같은 도구를 놓고도 목록에 들고 나는 것이 달라진다. 메모리와 에이전트는 컨텍스트 관리 수단이지만 확장 지점은 아니고, MCP와 플러그인은 확장 지점이지만 그 글이 다섯으로 센 목록에는 오르지 않았다.

그 글의 컨텍스트 분해표는 아홉 행에 토큰 값을 붙이는데, MCP 도구 행만 값이 —이고 옆 칸에 필요 시 로드라고 적혀 있다. 다만 이 표가 다섯의 선정 기준을 그대로 보여주는 것은 아니다 — 커맨드와 훅은 이 표에 행 자체가 없는데도 다섯에 들어 있다. 그 글은 MCP를 다섯에서 뺀 이유를 따로 밝히지 않는다. 확인되는 것은 값이 —라는 사실까지다. 이 값이 이 시리즈의 원 자료와 어떻게 갈리는지는 MCP 편에서 따로 본다.

그 글이 다섯에 붙인 정의는 다음과 같다.

두 목록을 하나로 합치지 않는다.

같은 이름의 구성물이라도 어느 기준으로 세었는지에 따라 이웃이 달라진다. 어느 쪽이 맞는 목록인지 정하는 대신, 기준이 다르다는 사실만 남긴다.

이 대조는 원 자료에 없다. 두 자료를 나란히 놓고 이 글에서 만든 것이다.

조직 도입 관점 — 확장 메커니즘을 표준으로 굳히기

지금까지의 내용을 조직 도입 순서로 재배열하면 다음과 같다.

순서에서 눈여겨볼 점은 안전장치(2번)가 자동화(3·4번)보다 앞선다는 것이다. 도구를 붙여 능력을 키운 직후, 능력이 잘못 쓰이는 경로부터 막는다. 자동화의 편의는 그다음이다.

앞의 층위표와 배열이 다르다.

층위표는 연결 → 실행 → 통제 → 배포로 놓았지만, 도입 순서에서는 통제가 실행보다 앞이다. 층위는 무엇이 무엇 위에 얹히는가를 그린 것이고 도입 순서는 무엇을 먼저 세워야 사고 경로가 먼저 막히는가를 그린 것이라, 같은 네 층을 놓고도 배열이 갈린다.

다음 편

넷을 가르는 축은 여기까지다. 다음 편은 그중 연결 층 하나만 떼어, 무엇을 붙일지 고르고 몇 개까지 붙일지 정하는 문제를 본다. 그다음이 나머지 셋과 플러그인의 실제 구성이다.