최근 Anthropic의 "knowledge-work-plugins"와 Claude Plugin의 구현을 연구하면서 토론할 가치가 있는 문제점을 발견했습니다. 바로 'Agent가 Skills, MCP, 그리고 Tools를 갖추었음에도 불구하고 왜 Plugin이 또 필요한가?'입니다.
하나의 SKILL md는 Agent에게 특정 작업을 완료하는 방법을 가르칠 수 있고, 하나의 MCP Server는 Agent가 외부 시스템에 접근할 수 있게 합니다. 하지만 능력이 개인 실험 단계를 넘어 팀 공유 및 기업 배포 단계로 나아가게 되면, 또 다른 문제 그룹에 직면하게 됩니다:
누가 능력을 개발하고 검증할까요? 사용자는 어떻게 이를 발견하고 설치할까요? 올바른 버전을 로드했는지 어떻게 보장할 수 있을까요? 이것이 제대로 트리거되었고 실제로 작업 결과를 개선했는지 어떻게 알 수 있을까요? 문제가 생겼을 때는 어떻게 롤백(rollback)해야 할까요?
이러한 문제들은 단발적인 에이전트 루프 (Agent Loop)만으로는 해결될 수 없으며, 독립적인 능력 엔지니어링 시스템(capability engineering system)이 필요합니다.
Claude Plugin의 방식은 Skills, Commands, Agents, MCP, Hooks 등 여러 구성 요소를 하나의 설치 가능한 능력 패키지로 조직한 다음, Claude Runtime에 전달하는 것입니다.
연구를 통해 생명 주기를 아홉 단계로 나눌 수 있습니다:
-
Author (작성): 능력은 어떻게 정의되고 캡슐화되나요?
Plugin은 표준 디렉터리, "plugin.json", 그리고 구성 요소 약속을 사용하여 원래 분산되어 있던 Prompt, Skills, 도구 설정 및 스크립트를 하나의 능력 패키지로 조직합니다.
Skill은 전문 지식과 작업 방법을 정의하고, MCP는 도구 연결을 제공하며, Agent는 특정 실행 역할을 맡고, Hooks는 실행 이벤트를 연결합니다.
Plugin은 캡슐화와 전달을 담당하므로, 스스로 에이전트 루프 (Agent Loop)를 구현할 필요가 없습니다.
-
Validate (검증): 능력이 정말 효과적인지 어떻게 알 수 있나요?
이는 Prompt Engineering에서 Software Engineering으로 넘어가는 첫 단계입니다.
Claude는 "plugin validate"를 통해 구조와 구성을 검사하고, "claude plugin eval"을 제공하여 테스트 케이스를 실행합니다. 규칙이나 모델 점수를 통해 평가할 수 있으며, Plugin이 로드되지 않은 Baseline과 비교하고 CI(지속적 통합)에 연결할 수도 있습니다.
검증하는 것은 단순한 파일 형식이 아니라: 이 Plugin을 설치했을 때 Agent가 작업을 더 신뢰성 있게 완료하는지 여부입니다.
-
Publish (배포): 재사용 가능하고 추적 가능한 능력은 어떻게 배포하나요?
Claude는 Marketplace를 사용하여 플러그인 디렉터리를 조직하며, Git 저장소와 같은 출처도 지원합니다. 기업용 버전에는 Plugin API가 있어 불변(immutable) 버전을 관리할 수 있습니다.
이를 통해 능력의 소스 코드, 배포 디렉터리, 그리고 사용자가 실제로 사용하는 버전이 분리될 수 있습니다.
-
Discover (발견): Agent와 사용자는 어떻게 적절한 능력을 찾을까요?
Marketplace는 플러그인 디렉터리, 설명, 검색 및 설치 진입점을 제공하며, 조직은 허용되는 출처를 제한적으로 구성할 수 있습니다.
하지만 여기서는 두 가지 문제를 구분해야 합니다: 사용자가 Plugin을 발견하고 설치하는 것과 Agent가 작업을 수행할 때 적절한 Skill을 선택하는 것은 서로 다른 수준의 능력 발견입니다.
전자는 소프트웨어 배포에 가깝고, 후자는 여전히 모델이 작업과 Skill 설명 간의 매칭에 의존합니다.
-
Install (설치): 종속성, 범위, 권한은 어떻게 관리하나요?
Claude Code는 user, project, local 등 설치 범위를 지원하며, 플러그인 선언된 종속성을 처리합니다.
설치는 단순히 파일을 복사하는 것을 넘어, 출처의 신뢰도, 종속성 구성, 조직 전략, 그리고 Plugin이 외부 시스템에 접근할 수 있는지 여부까지 포함합니다.
-
Load (로드): 컨텍스트와 버전은 어떻게 제어하나요?
제가 특히 흥미롭다고 생각하는 부분입니다.
Claude Code는 세 가지 상태를 명확히 구분합니다:
Declared → Fetched → Loaded.
설정에서 Plugin을 선언했다고 해서 파일이 다운로드된 것은 아니며, 다운로드되었다고 해도 현재 세션에 로드된 것은 아닙니다.
로드된 이후에는 Skill의 이름과 설명이 컨텍스트에 들어갈 수 있으며, 전체 명령어는 트리거 시점에 필요에 따라 로드됩니다.
따라서 Plugin이 많다고 해서 모든 지식이 한 번에 Prompt에 채워져야 한다는 의미는 아닙니다. 하지만 호출되지 않더라도 능력 설명은 여전히 컨텍스트 오버헤드를 가져올 수 있습니다.
-
Execute (실행): 능력은 누가 스케줄링하고 실행하나요?
Plugin 자체는 독립적인 Agent Runtime이 아닙니다.
Model, Context, Session, Tool Calls 및 Permissions를 실제로 관리하는 것은 여전히 Claude Harness입니다.
Skill은 실행 방법을 제공하고, Agent는 임무가 위임될 수 있으며, MCP는 외부 도구를 제공하고, Hooks는 실행 이벤트를 처리합니다.
이렇게 함으로써, 동일한 Runtime이 서로 다른 영역의 Plugin을 사용할 수 있게 되며, Plugin 개발자는 스케줄링 프레임워크를 반복해서 개발할 필요가 없습니다.
-
Observe (관찰): Plugin이 가치가 있는지 어떻게 알 수 있나요?
Claude는 이미 플러그인 설치, 로드, Skill 활성화, Token 비용 등의 관측 능력을 제공합니다. 조직은 OpenTelemetry 및 Analytics API를 통해 실제 사용 상황을 분석할 수 있습니다.
하지만 설치량, 트리거 횟수, 토큰 소모와 비즈니스 작업 성공률은 서로 다른 지표입니다.
Skill이 자주 호출된다고 해서 그것이 유용하다는 것을 직접적으로 증명하지 못하며, 심지어 트리거 조건 자체가 너무 광범위할 수도 있습니다.
-
유지보수(Maintain): 업그레이드, 롤백 및 취소 방법은?
기업용 플러그인 API는 불변(immutable) 버전과 'latest_version_id', 'served_version_id'라는 두 개의 포인터를 지원합니다.
새 버전을 먼저 업로드하고 검증한 다음, 사용자에게 언제 제공할지 결정할 수 있습니다. 문제가 발견되면 이전 버전으로 되돌아갈 수도 있습니다.
이는 성숙한 소프트웨어의 버전 배포 메커니즘과 매우 유사합니다.
이것은 저로 하여금 에이전트(Agent) 플랫폼의 아키텍처 경계에 대해 다시 생각하게 만듭니다.
Agent Runtime은 작업을 실행하는 역할을 하고, Plugin Platform은 기능을 제공하고 거버넌스(governance)를 담당합니다. 그리고 이 둘 사이의 실행 기록, 효과 평가 및 피드백 메커니즘이야말로 미래 기업 에이전트 플랫폼에서 가장 투자할 가치가 높은 부분일 수 있습니다.
Skill 파일은 하나의 능력을 정의합니다. 반면, Plugin의 생명주기(lifecycle)는 이 능력이 끊임없이 변화하는 모델, 도구 및 비즈니스 환경에서 어떻게 지속적으로 사용 가능하고(available), 신뢰할 수 있으며(reliable), 검증 가능한지(verifiable)에 답해야 합니다.
이는 단순히 더 나은 'SKILL md'를 작성하는 방법을 논의하는 것보다 훨씬 광범위한 범위입니다.
