에이전트 스킬에는 패키지 관리자가 필요합니다

에이전트 스킬은 이제 잠금 파일이 생기기 전 JavaScript가 겪었던 것과 같은 실패 양상을 보인다. 모두가 유용한 파일을 로컬 설정으로 복사하고, 각 복사본은 조금씩 어긋난다.

그 신호는 같은 주에 여러 방향에서 도착했다. Microsoft의 Agent Package Manager 문서는 에이전트 작업 맥락을 팀이 매니페스트에 선언하고, 잠금 파일로 해석하며, 각 AI 클라이언트가 이미 읽는 디렉터리로 배포해야 하는 것으로 설명한다.¹ Sx는 같은 범주를 다른 방향에서 설명한다. 팀과 도구 전반에서 스킬, 규칙, 에이전트, 명령, 후크, MCP 서버, 플러그인 번들을 공유할 수 있는 AI 코딩 어시스턴트용 패키지 관리자다.²

이 범주가 중요한 이유는 Codex, Claude, Cursor, Copilot, Gemini, OpenCode 같은 도구가 더 이상 프롬프트만으로 동작하지 않기 때문이다. 이들은 프로세스 파일, 스킬 정의, 명령 파일, MCP 서버 선언, 후크 스크립트, 정책 파일, 플러그인 매니페스트 위에서 동작한다. 그런 파일들은 작업별 첫 토큰이 나타나기 전부터 에이전트의 행동을 형성한다.

TL;DR

에이전트 스킬에 패키지 관리자가 필요한 이유는 에이전트 작업 맥락이 소프트웨어 공급망이 되었기 때문이다. 유용한 스킬은 단순한 산문이 아니다. 스크립트, MCP 서버, 후크, 명령, 에이전트, 설치 범위를 끌어올 수 있다. 팀에는 그런 자산을 위한 매니페스트, 잠금 파일, 콘텐츠 검사, 출처 정책, 검토 관문, 롤백이 필요하다.

이제 올바른 질문은 “이 스킬을 어디에 붙여 넣을까?”가 아니다. 올바른 질문은 “우리가 어떤 버전을 설치했는가, 어디에서 왔는가, 누가 승인했는가, 어떤 클라이언트가 받았는가, 무엇을 실행할 수 있는가, 어떻게 되돌릴 수 있는가?”다.

패키지 관리자는 에이전트 작업을 그 자체로 안전하게 만들지 않는다. 대신 의존성 그래프를 관리할 수 있을 만큼 보이게 만든다.

핵심 요점

엔지니어링 팀에게: - 에이전트 스킬, MCP 서버, 후크, 명령, 프롬프트, 플러그인을 의존성으로 다뤄라. - 새 패키지가 공유 프로젝트에 도달하기 전에 잠금 파일을 커밋하고, 업데이트를 검토하며, 설치 및 감사 검사를 실행하라.

보안 검토자에게: - 빌드 시점 패키지 무결성과 실행 시점 안전성을 분리하라. 깨끗한 설치가 에이전트가 읽은 뒤 후크나 MCP 서버가 안전하게 동작한다는 증거는 아니다. - 공유 에이전트 작업 맥락을 신뢰하기 전에 출처 허용 목록, 고정된 커밋, 숨은 문자 검사, 비밀값 우회 참조 규칙을 요구하라.

에이전트 도구 제작자에게: - 전체 비공개 작업 흐름이 아니라 최소한의 일관된 역량을 패키징하라. - 첫 공개 릴리스부터 범위가 정해진 설치, 업데이트 검토, 롤백을 염두에 두고 만들어라.

무엇이 달라졌나?

OpenAI의 Codex Academy 페이지는 명확한 구분을 제시한다. 플러그인은 Codex를 외부 도구와 정보 출처에 연결하고, 스킬은 Codex에게 팀의 특정 프로세스를 가르친다.³ Anthropic의 플러그인 문서는 더 넓은 패키징 관점을 사용한다. 플러그인은 MCP 커넥터, 스킬, 슬래시 명령, 하위 에이전트를 재사용 가능한 역량 패키지로 묶는다.⁴

이 정의들은 운영상의 문제를 만든다. 팀은 더 이상 “조언”을 설치하지 않는다. 팀은 에이전트가 어떤 도구를 보는지, 사용자가 어떤 작업 흐름을 호출하는지, 어떤 배경 검사가 실행되는지, 어떤 지침이 작업 맥락으로 로드되는지를 바꿀 수 있는 파일을 설치한다.

Claude Code의 플러그인 참조는 그 형태를 직접 보여준다. 플러그인에는 스킬, 명령, 에이전트, 후크, MCP 서버 선언, 모니터, 바이너리, 설정, 매니페스트가 포함될 수 있다.⁵ CLI는 사용자, 프로젝트, 로컬 같은 설치 범위를 지원하며, 버전 해석은 플러그인 메타데이터, 마켓플레이스 메타데이터, git 커밋 SHA에서 올 수 있다.⁶

이것이 의존성 시스템처럼 보이는 이유는 실제로 의존성 시스템이기 때문이다.

복사 붙여넣기가 무너지는 이유

복사해 붙여넣기는 한 개발자가 한 스킬을 시험할 때는 작동한다. 팀에서는 실패한다.

첫 번째 실패는 표류다. 한 저장소에는 어제의 스킬이 있다. 다른 저장소에는 브랜치 버전이 있다. 세 번째 개발자는 어떤 문장이 모델을 거슬리게 한다는 이유로 로컬 복사본을 수정한다. 지난주에 좋은 결과를 만든 버전이 무엇인지 아무도 모른다.

두 번째 실패는 범위다. 디자인 검토 스킬은 디자인 비중이 큰 저장소에 속한다. 데이터베이스 마이그레이션 스킬은 백엔드 서비스에만 속할 수 있다. 비밀값 검사 후크는 거의 모든 곳에 속한다. 전역 설치는 작업 맥락을 부풀리고 우발적 활성화를 늘린다. 프로젝트별 복사 붙여넣기는 유용한 작업을 묻어 버린다.

세 번째 실패는 신뢰다. 스킬 파일에는 절차적 지침이 들어갈 수 있다. 플러그인에는 후크가 들어갈 수 있다. MCP 서버는 데이터와 도구에 연결될 수 있다. 슬래시 명령은 여러 단계의 작업 흐름을 실행할 수 있다. 패키지 관리자는 그 작업 흐름이 신뢰받을 자격이 있는지 결정할 수 없지만, 설치자가 파일의 출처와 트리에 들어온 버전을 답하도록 강제할 수 있다.

네 번째 실패는 롤백이다. 새 스킬이 에이전트의 판단을 약화시키면 팀에는 되돌릴 수 있는 하나의 의존성 변경이 필요하다. 수동 복사본은 롤백을 발굴 작업으로 만든다.

패키지 관리자가 더하는 것

Microsoft APM은 패키지 관리자 형태를 명시적으로 제시한다. apm.yml은 의존성을 선언한다. apm.lock.yaml은 두 개발자가 바이트 단위로 동일한 작업 맥락을 설치할 수 있도록 해석된 패키지를 고정한다. APM은 .github/, .claude/, .cursor/, .codex/, AGENTS.md, .gemini/, .opencode/, .windsurf/ 같은 기존 클라이언트 디렉터리에 기록한다. 새로운 실행 환경을 발명하지 않는다.¹

빠른 시작 문서는 실무 산출물 세트를 보여준다. apm.yml, apm.lock.yaml, git에서 무시되는 apm_modules/ 캐시, 클라이언트 중립 스킬, 대상별 출력 파일이다. 같은 페이지는 APM이 전이 의존성을 해석하고, 패키지 콘텐츠에서 숨은 Unicode를 검사하며, 정확한 커밋과 콘텐츠 해시를 잠금 파일에 기록한다고 말한다.⁷

의존성 작업 흐름은 익숙해 보인다.

Microsoft 문서는 잠금 파일 규율도 분명히 적고 있다. 생성된 잠금 파일을 커밋하고, 절대 손으로 편집하지 않으며, 팀이 실제로 어떤 버전을 실행하는지 답하기 위해 그것을 검사하라는 것이다.⁸

그 규율은 이전의 많은 설정 파일보다 에이전트에 더 중요하다. 에이전트 작업 맥락은 행동을 확률적으로 바꾼다. 한 줄짜리 지침이 모델이 무엇을 거부하는지, 어떤 도구를 선호하는지, 증거를 위해 멈추는지, 릴리스를 완료된 것으로 취급하는지를 바꿀 수 있다.

Sx도 같은 압력을 보여준다

Sx는 다른 제품 표면에서 출발하지만 같은 범주에 도착한다. README는 sx를 AI 코딩 어시스턴트용 패키지 관리자라고 부르며, 스킬, MCP 설정, 명령, 관련 자산을 관리한다고 말한다.² 조직, 저장소, 경로, 팀, 사용자, 봇 ID 전반의 설치 범위를 지원한다.⁹

범위 지정 세부 사항은 중요하다. 좋은 에이전트 작업 맥락은 모든 곳에 로드되어서는 안 된다. 패키지 관리자는 누가 그 자산을 받는지, 어떤 저장소에서, 어떤 경로 아래에서, 어떤 봇 또는 사람 ID를 위해 받는지 답해야 한다.

Sx는 감사와 사용량도 일급 표면으로 다룬다. README는 도입 데이터를 위한 sx stats와 최근 팀 또는 설치 변경을 위한 sx audit를 나열한다.⁹ 이것은 다음 층을 가리킨다. 에이전트 패키지에는 배포뿐 아니라 사용 증거도 필요하다. 아무도 호출하지 않는 스킬은 불필요한 무게다. 모두가 호출하지만 반복해서 고치는 스킬은 개정이 필요하다. 유용한 작업을 막는 후크에는 조용한 삭제가 아니라 변경 요청이 필요하다.

Sx의 가장 강한 아이디어는 마켓플레이스가 아니다. 가장 강한 아이디어는 범위가 정해진 배포와 관찰된 도입이다.

패키지 관리자가 증명할 수 없는 것

패키지 관리자는 의존성 그래프를 보이게 만들 수 있다. 모든 패키지를 가치 있게 만들 수는 없다.

Microsoft의 보안 문서는 그 경계를 명확히 말한다. APM은 프롬프트, 지침, 스킬, 후크, MCP 서버 선언을 위한 빌드 시점 공급망을 방어한다. 목표는 재현성, 무결성, 출처, 배포 전 콘텐츠 안전성이다.¹⁰ 같은 페이지는 APM이 실행 시점에 MCP 서버를 샌드박스 처리하지 않고, 의존성 코드에 대한 멀웨어 분석을 수행하지 않으며, 패키지에 서명하지 않고, 에이전트가 작업 맥락을 읽은 뒤 무엇을 하는지 검사하지 않는다고 말한다.¹¹

그 경계는 도입 방식을 결정해야 한다.

설치 성공을 신뢰 결정으로 취급하지 마라. 설치 성공은 검토를 계속할 이유로 취급하라. 검토는 여전히 눈에 보이는 지침, 실행 가능한 후크, MCP 전송 방식, 환경 변수 처리, 업데이트 정책, 패키지가 수행한다고 주장하는 실제 일을 살펴봐야 한다.

규칙은 단순하다. 패키지 관리자는 에이전트 작업 맥락을 관리 가능하게 만들 뿐, 본질적으로 좋게 만들지는 않는다.

최소 기준

팀은 프로세스를 개선하기 위해 하나의 생태계 승자를 기다릴 필요가 없다. 여섯 가지 규칙으로 시작할 수 있다.

1. 모든 에이전트 자산을 목록화하라. 스킬, 명령, 후크, MCP 서버, 에이전트, 플러그인 번들, 프롬프트 파일, 프로젝트 지침을 나열하라. 팀이 자산을 목록화할 수 없다면 관리할 수도 없다.

2. 개인, 프로젝트, 조직 범위를 분리하라. 개인 실험이 프로젝트 기본값이 되어서는 안 된다. 프로젝트 표준이 전역 작업 맥락이 되어서는 안 된다. 조직 패키지는 명시적인 소유권을 가져야 한다.

3. 공유하기 전에 버전을 고정하라. 공유 패키지에는 태그나 커밋 SHA를 사용하라. 떠 있는 브랜치는 릴리스 작업 흐름이 아니라 실험에 속한다.

4. 잠금 파일을 커밋하라. 재현성에는 매니페스트 의도만이 아니라 해석된 트리가 필요하다.

5. 실행 시점 표면을 별도로 검토하라. 후크, 바이너리, 셸 명령, MCP 서버는 평범한 지침형 스킬보다 더 엄격한 검토가 필요하다. 이들은 실행하거나 연결할 수 있으므로 더 높은 위험을 가진다.

6. 롤백을 지루하게 만들어라. 나쁜 패키지 업데이트는 하나의 의존성 변경과 하나의 재설치 명령으로 되돌릴 수 있어야 한다. 롤백에 복사한 파일을 기억해야 한다면 그 시스템은 아직 준비되지 않았다.

실용적인 도입 지도

작게 시작하라.

먼저 무해한 스킬 하나를 패키징하라. 글쓰기 평가 기준, 테스트 체크리스트, 검토 형식 같은 것이 좋다. 그것을 하나의 저장소에 설치하라. 올바른 클라이언트가 그것을 보는지 확인하라. 잠금 파일이 그것을 고정하는지 확인하라. 제거가 작동하는지 확인하라.

다음으로 사람들이 이미 수동으로 호출하는 명령을 패키징하라. 팀이 설치와 롤백 경로를 이해할 때까지 후크와 MCP 서버는 피하라.

그다음 MCP 서버 선언을 패키징하되, 자격 증명은 패키지에 넣지 마라. 환경 변수 참조와 별도의 비밀값 저장소를 사용하라. 패키지는 실행 시점 의존성을 설명해야지 비밀값을 담아서는 안 된다.

후크는 마지막에 온다. 후크는 적절한 순간에 품질을 강제할 수 있지만, 작업을 막거나 취약한 가정을 숨기거나 잘못된 신뢰 모델 아래에서 스크립트를 실행할 수도 있다. 팀에 출처 정책, 검토 소유권, 롤백이 생긴 뒤에만 후크를 배포하라.

그 순서는 위험 기울기를 존중한다.

검토 패킷

공유 에이전트 패키지가 프로젝트에 들어가기 전에 하나의 검토 패킷을 요구하라. 지루하게 유지하라.

그 패킷은 최악의 실패를 막는다. 팀이 “스킬을 설치했다”고 말하지만 실제로는 플러그인, MCP 서버, 후크 두 개, 아무도 검토하지 않은 명령을 설치하는 상황이다.

판단의 층은 여전히 중요하다

에이전트 패키지는 수량을 부추길 것이다. 설치가 싸게 느껴지기 때문에 팀은 스킬 40개를 설치할 수 있다. 싼 작업 맥락에도 비용은 있다.

추가되는 모든 스킬은 주의를 두고 경쟁한다. 모든 명령은 선택지를 더한다. 모든 후크는 가능한 차단 지점을 더한다. 모든 MCP 서버는 동작 표면을 넓힌다. 패키지 관리자가 해결하는 것은 배포이지 판단이 아니다.

올바른 기준은 작고 날카로운 상태를 유지한다. 일을 개선하는 것을 설치하고, 에이전트를 부풀리는 것을 제거하며, 검토를 통과한 것을 고정하고, 사람들이 실제로 무엇을 쓰는지 관찰하라.

그것이 에이전트 패키지에 대한 Steve 기준이다. 최대 번들을 공개하지 마라. 일관된 번들을 공개하라.

빠른 요약

에이전트 스킬에 패키지 관리자가 필요한 이유는 에이전트 작업 맥락이 이제 의존성 코드처럼 행동하기 때문이다. 스킬은 프로세스를 담을 수 있다. 플러그인은 명령, 후크, MCP 서버, 에이전트를 담을 수 있다. 패키지는 모든 개발자의 에이전트 설정 행동을 바꿀 수 있다.

패키지 관리자의 일은 그런 자산을 좋게 만드는 것이 아니다. 그 일은 자산을 선언하고, 고정하고, 배포하고, 감사하며, 롤백을 가능하게 만드는 것이다. 팀의 일은 여전히 더 어렵다. 어떤 자산이 존재할 자격이 있는지 결정해야 한다.

FAQ

에이전트 스킬은 정말 의존성인가?

그렇다. 공유 스킬은 에이전트가 작업을 수행하는 방식을 바꾼다. 플러그인은 명령, 후크, MCP 서버, 에이전트 정의도 추가할 수 있다. 그런 파일들은 여러 기계에서 행동에 영향을 주므로, 팀은 코드 의존성에 적용하는 것과 같은 진지함으로 추적해야 한다.

패키지 관리자가 플러그인 검토를 대체하는가?

아니다. 패키지 관리자는 출처, 버전, 해시, 범위, 설치된 파일을 기록한다. 검토는 여전히 패키지가 무엇을 말하는지, 무엇을 실행할 수 있는지, 어떤 MCP 서버를 선언하는지, 그 역량이 프로젝트에 속하는지 살펴봐야 한다.

팀은 비공개 작업 흐름을 패키징해야 하는가?

팀은 비공개 운영 세부 사항이 아니라 반복 가능한 수행 과업을 패키징해야 한다. 공개 패키지는 일반적인 검토 관문, 마이그레이션 체크리스트, 문서화 작업 흐름을 제공할 수 있다. 비공개 프롬프트, 민감한 파일 경로, 자격 증명, 내부 소스 맵, 독점적인 채점 내부 구조를 실어서는 안 된다.

팀은 무엇을 먼저 패키징해야 하는가?

이미 수동으로 잘 작동하는 저위험 스킬로 시작하라. 팀에 매니페스트, 잠금 파일, 출처 정책, 설치 검토, 롤백 경로가 생길 때까지 MCP 서버와 후크는 피하라.

에이전트 작업에 가장 중요한 패키지 관리자 기능은 무엇인가?

잠금 파일이 가장 하중을 지탱하는 기능이다. 발견 기능은 도움이 되고 설치 명령은 기분 좋지만, 재현 가능한 에이전트 작업 맥락에는 정확한 출처 참조, 콘텐츠 해시, 배포된 파일 기록이 필요하다.

References