Microsoft는 APM — Agent Package Manager를 출시했습니다. 3.2k개의 스타, apm.yml, 락파일(lockfile), 정책 파일(policy files), SBOM 내보내기, 하나의 매니페스트(manifest)로 구성된 8개의 코딩 에이전트까지. 이는 매우 진지한 작업물입니다.

저는 에이전트 플러그인 마켓플레이스(agent plugin marketplaces)를 스캐폴딩(scaffolding)하고 관리하는 agkit을 유지 관리하고 있습니다. 그래서 APM이 등장했을 때, 솔직한 첫 반응은 여러분이 예상할 법한 것이었습니다. '내 도구가 할 일이 남아있기는 할까?'

다음에 이어질 내용은 적절한 비판적 시각을 가지고 읽어주시기 바랍니다. 저는 중립적인 입장이 아닙니다. 하지만 저는 그 질문에 제대로 답하기 위해 일주일 동안 APM의 문서와 이슈 트래커(issue tracker)를 살펴보았고, 그 답은 "아니오"나 "당연히 예" 중 어느 하나보다 더 흥미로운 것으로 밝혀졌습니다. 두 도구는 표면적으로는 거의 완전히 겹치지만, 밑바닥에서는 한 가지 사항에 대해 의견이 다릅니다. 그 한 가지 사항이 바로 결정의 핵심입니다.

쉬운 답변, 그리고 그것이 틀린 이유

편안한 이야기는 저절로 써 내려가기 쉽습니다: APM은 설치하고, agkit은 게시한다. 소비자 대 생산자. 동일한 문제의 두 절반. 모두가 악수를 나누며 마무리되는 그림이죠.

하지만 이는 틀렸으며, 이 생각이 퍼지기 전에 바로잡을 가치가 있습니다. 왜냐하면 APM도 마켓플레이스를 완벽하게 게시할 수 있기 때문입니다:

• apm init --marketplace는 자체 마켓플레이스를 게시할 프로젝트를 시작합니다.
• apm marketplace init은 apm.yml에 marketplace: 블록을 추가하고 .claude-plugin/을 생성합니다.
• 주변에는 check, outdated, migrate, package와 같은 작성 도우미(authoring helpers)들이 있습니다.
• apm pack은 해당 블록으로부터 .claude-plugin/marketplace.json을 빌드합니다. 이것이 바로 게시 단계이며, 해당 파일이 아티팩트(artifact)입니다.
• microsoft/apm-action은 게이트(gate), 매트릭스-팩(matrix-pack), sha256 사이드카(sidecars), marketplace.json 드리프트 탐지(drift detection), gh release create를 포함한 전체 릴리스 과정을 실행합니다.

따라서 두 도구 모두 디스크에 있는 기술을 가져와 다른 사람들이 이름과 버전으로 설치할 수 있는 무언가로 변환합니다. 만약 하나를 다른 하나보다 선택해야 할 이유를 찾고 있다면, "생산자 대 소비자"는 그 이유가 될 수 없습니다.

그들이 실제로 의견을 달리하는 부분

APM authors in apm.yml plus .apm/ and compiles marketplace.json with apm pack; agkit's marketplace.json is itself the source of truth, read as-is by Claude Code and Copilot

APM의 신뢰할 수 있는 원천 (source of truth)은 apm.yml과 .apm/<type>/ 트리입니다. marketplace.json은 그 결과물로 나오는 것입니다. apm pack은 컴파일러 (compiler)이며, APM은 이를 의도적으로 설계했습니다. GitHub Action은 어떤 CLI가 출력을 소비하는지 가정하지 않고, 단지 사용자의 outputs: 맵에 선언된 대로 출력할 뿐입니다 — 예: claude=marketplace.json, codex=plugins.toml. 설계 단계부터 벤더 중립적 (Vendor-neutral)입니다. 여기서 카탈로그는 **빌드 아티팩트 (build artifact)**입니다.

agkit의 신뢰할 수 있는 원천 (source of truth)은 .claude-plugin/marketplace.json 그 자체입니다. Claude Code와 Copilot은 해당 파일을 있는 그대로 읽기 때문에 컴파일할 것이 아무것도 없습니다. agkit sync는 완전히 반대 방향으로 작동합니다. README 플러그인 테이블과 AGENTS.md 목록은 카탈로그로부터 _파생 (derived from)_되므로, 서로 어긋날(drift) 수 없습니다. 여기서 카탈로그는 **신뢰할 수 있는 원천 (source of truth)**입니다.

파일명은 같습니다. 방향은 정반대입니다. 그 외의 모든 것은 여기서 비롯됩니다.

컴파일 단계가 제공하는 이점

진정한 추상화 계층 (abstraction layer)은 그 가치를 증명해야 하며, APM은 이를 해냅니다:

• 하나의 매니페스트 (manifest), 다양한 생태계. 한 번만 선언하면 Copilot, Claude Code, Cursor, OpenCode, Codex, Gemini, Windsurf, Kiro 전반에 배포할 수 있습니다. 특정 벤더가 형식을 변경하더라도 그것은 사용자의 문제가 아니라 APM의 문제입니다.
• 거버넌스 (governance)를 적용할 지점. 사람들이 직접 편집하는 파일은 잠금(lock), 해시(hash), 스캔(scan) 및 통제할 수 없습니다. 카탈로그가 생성되면, apm.lock.yaml은 무결성 해시(integrity hashes)를 통해 해결된 트리를 고정(pin)할 수 있고, apm-policy.yml은 엔터프라이즈에서 조직, 저장소로 이어지는 엄격한 상속을 통해 소스를 제한할 수 있으며, apm lock export는 CycloneDX 또는 SPDX를 출력할 수 있습니다.
• 계약으로서의 재현성 (Reproducibility). git clone && apm install은 하나의 약속입니다. 마켓플레이스는 단지 제안일 뿐입니다.

그에 따른 비용

추상화는 배워야 할 대상이며, 실행해야 할 빌드 과정이고, 이전에는 존재하지 않았을 버그가 발생할 수 있는 지점입니다.

APM의 자체 저작 가이드(authoring guide)는 이 중 한 가지 측면에 대해 매우 솔직하게 서술하고 있습니다. apm pack은 관대합니다. .apm/<type>/ 디렉토리와 agents/ 또는 skills/와 같은 루트 컨벤션(convention) 디렉토리 모두에서 프리미티브(primitive)를 수집합니다. 반면 apm install은 더 엄격하며, 프리미티브 단위로 동작합니다. 그 결과, 만약 플러그인 루트에 instructions/를 작성한다면, 번들은 깔끔하게 패키징(pack)되지만 설치(install) 시에는 조용히 불완전한(silently incomplete) 상태가 됩니다. 마켓플레이스 발행사들에 대한 그들의 권장 사항은 모든 프리미티브에 대해 .apm/<type>/를 사용하는 것입니다. 왜냐하면 이것이 두 명령 모두에서 대칭을 이루는 유일한 레이아웃이기 때문입니다.

이는 날카로운 모서리(sharp edge, 주의가 필요한 지점)에 대한 훌륭한 문서화입니다. 또한 이는 컴파일 단계가 없을 때는 존재할 수 없는 유형의 버그이기도 합니다. 즉, 당신이 편집하는 파일이 에이전트가 읽는 파일 그 자체라면, "패키징은 되지만 설치는 되지 않는" 상태는 프로젝트에서 발생할 수 없는 상태가 됩니다.

agkit의 직관성이 제공하는 이점

• 레포지토리에 있는 것이 곧 배포되는 것입니다. 빌드도, 아티팩트(artifact)도, 그 사이의 괴리(drift)도 없습니다. git push가 곧 릴리스(release)입니다. 레지스트리도, 계정도, 발행 토큰(publish token)도 필요 없습니다.
• 도입 비용 제로. npx agkit init dev-toolkit, Node 22+ 환경이라면 아무것도 설치할 필요가 없습니다. 첫 번째 플러그인이 존재하기도 전에 매니페스트(manifest) 형식, 락파일(lockfile), 릴리스 파이프라인을 도입해야 하는 상황과 비교해 보십시오.
• 플러그인이 릴리스의 단위입니다. agkit bump commit-crafter --tag는 마지막 commit-crafter@x.y.z 태그 이후 해당 플러그인의 디렉토리를 수정한 커밋만을 읽어, conventional-commit 규칙을 적용하고, 매니페스트 버전을 작성하며, 변경 로그(changelog) 항목을 생성하고, 파생된 파일들을 동기화한 뒤 태그를 지정합니다. 하나의 플러그인에 범위가 지정된(scoped) semantic-release이므로, 활발한 플러그인이 조용한 플러그인을 릴리스에 끌어들이는 일이 발생하지 않습니다.
• 벤더링(vendoring) 없는 참조. agkit add octo-org/changelog-skill changelog --ref v1.2.0를 사용하면 다른 사람의 플러그인을 복제(cloning)하지 않고도 당신의 카탈로그에 추가할 수 있습니다. 당신의 레포지토리에는 하나의 JSON 항목이 추가될 뿐이며, 에이전트는 설치 시점에 소스를 확인(resolve)합니다.

그에 따른 비용

당신은 플랫폼의 모델을 상속받으며, 여기에는 플랫폼의 미래도 포함됩니다. 만약 Anthropic과 GitHub가 카탈로그 형식을 변경한다면, agkit은 그들을 따를 뿐입니다. 당신을 대신해 그 변화를 흡수할 레이어가 없습니다. 그것이 당신이 동의하고 있는 계약입니다.

그리고 더 가혹한 한계가 있습니다. agkit에는 락파일(lockfile), 무결성 해시(integrity hashes), 정책 파일(policy file), SBOM(Software Bill of Materials), 그리고 공급망 스캐닝(supply-chain scanning)이 없습니다. 만약 당신의 보안 팀이 "이것들이 이 조직이 허용하는 유일한 소스이다"라고 명시하고 모든 설치 시점에 이를 강제해야 한다면, agkit은 그들에게 제공할 수 있는 것이 아무것도 없습니다. 이것은 제가 말을 아끼려는 로드맵상의 공백이 아닙니다. 도구가 잘못된 것이며, APM이 올바른 도구입니다.

그들은 상호 보완합니다 — 그리고 그것이 실제 정답입니다

이 부분은 제가 예상치 못했던 발견이었으며, 이 글이 싸움이 아닌 이유이기도 합니다.

An agkit-published repo is consumed either natively by Claude Code and Copilot, or through APM, which adds a lockfile, SHA pinning, scanning, policy and SBOM on top of the same catalog

APM은 .github/plugin/marketplace.json과 .claude-plugin/marketplace.json 모두를 있는 그대로(as-is) 읽습니다. APM은 두 방언(dialect)을 모두 정규화합니다. Copilot CLI는 repository와 ref 필드를 사용하고, Claude Code는 source를 문자열 또는 객체로 사용하는데, APM은 이 둘을 자신의 표준 의존성 표현(canonical dependency representation)으로 매핑합니다. 그런 다음 각 항목을 Git URL로 해결(resolve)하며, 이 시점에서 해당 마켓플레이스에서 설치된 플러그인은 다른 모든 APM 의존성과 동일한 버전 고정(version locking), 보안 스캐닝, 거버넌스(governance)를 적용받게 됩니다.

발행자의 입장에서 이 내용을 다시 읽어보십시오. agkit으로 발행된 마켓플레이스는 이미 APM 의존성입니다. 당신은 아무것도 할 필요가 없습니다. 당신은 플랫폼이 정의한 형식을 발행했을 뿐이며, APM은 그 형식을 유창하게 구사합니다.

따라서 이 대립은 생산자 대 소비자의 구도가 아니었습니다. 핵심은 이것입니다:

당신은 작성(author) 방식을 선택합니다. 당신의 사용자는 소비(consume) 방식을 선택합니다.

이것은 서로 다른 두 사람이, 서로 다른 시점에 내리는 두 가지 결정이며, 어느 도구도 상대방의 선택을 강요하지 않습니다. 1인 유지관리자는 agkit을 사용하여 카탈로그를 게시하고 git push를 합니다. 시차가 세 시간이나 나는 규제 대상 은행은 락파일(lockfile), 고정된 SHA(pinned SHA), 유니코드 스캔(Unicode scan) 및 정책 게이트(policy gate)를 거쳐 apm install commit-crafter@dev-toolkit을 통해 그중 하나의 플러그인을 설치합니다. 아무도 툴체인(toolchain)에 합의할 필요가 없었습니다. 그들은 합의할 가치가 있는 유일한 것인 파일 형식(file format)에 합의했습니다.

그렇다면 어느 것을 선택해야 할까요?

agkit을 선택하세요: 당신이 게시(publishing)를 할 때 사용합니다. 다른 사람들이 이름으로 설치하기를 원하는 기술을 보유하고 있고, 카탈로그가 직접 읽을 수 있는 파일이기를 원하며, git push가 전체 릴리스 파이프라인(release pipeline)이 되기를 원할 때 적합합니다.

APM을 선택하세요: 당신이 소비(consuming)하거나 거버넌스(governing)를 수행할 때 사용합니다. 모든 개발자와 CI 러너(CI runner)가 바이트 단위로 동일한(byte-identical) 에이전트 설정을 갖추어야 하거나, "무엇이 어디로부터 디스크에 도달했는가"에 답해야 하거나, 조직 내 누군가가 준수 기한(compliance deadline)이 부과된 공급망(supply chain)에 대한 의견을 가지고 있을 때 적합합니다.

둘 다 사용하세요: 명백한 구성 방식입니다. agkit으로 게시하고, 거버넌스가 필요한 사람들이 그 앞에 APM을 배치하도록 하십시오. 카탈로그는 상관하지 않습니다.

솔직한 마무리

APM은 저의 프로젝트보다 더 큰 프로젝트이며, 조직의 지원을 받고, 더 빠르게 움직이며, 제가 해결하려는 문제가 아닌 다른 문제를 해결하고 있습니다. APM의 작성(authoring) 영역은 꾸준히 성장해 왔습니다. 만약 APM이 결국 카탈로그를 출력물(output)이 아닌 소스(source)로 취급하는 방향으로 수렴한다면, agkit의 존재 이유는 희박해질 것입니다.

저는 그러한 결과를 받아들일 것입니다. 제가 agkit을 만든 이유는 금요일 오후 6시에 수동으로 marketplace.json을 조립하는 것이 번거로운 일이기 때문이지, 생태계에 추상화(abstraction)가 부족했기 때문이 아닙니다. 만약 그 번거로운 일이 사라진다면, 그 도구는 어떤 방식으로든 제 역할을 다한 것입니다.

그때까지는: 파일이 인터페이스입니다. 당신을 좋은 결과로 인도하는 도구를 선택하십시오.

• agkit — npm · 문서(docs) · 소스(source)
• APM — github.com/microsoft/apm · 문서(docs)
• 이전: Claude 코딩 기술을 압축하는 것을 멈추세요: 15분 만에 플러그인 마켓플레이스 구축하기

APM v0.25.0 및 agkit 0.9.2와 비교, 2026년 7월. 둘 다 빠르게 변화하고 있으니 인용하기 전에 문서를 확인하세요. agkit은 MIT 라이선스를 따르며 Anthropic, GitHub, Microsoft, OpenAI 또는 Cursor와는 무관합니다.