대형 기술 프로젝트 중 하나를 사용한 후 이곳에 도착한 사람들이 계속해서 던지는 질문이 있습니다: "저는 이미 컬렉션(collection)에서 기술을 가져오고 있고, 제 에이전트가 이미 그것들을 설치하고 있는데 — 레지스트리(registry)가 추가로 무엇을 더해주나요?"

타당한 질문입니다. 여기 홍보 문구가 아닌 지형도로 작성된 솔직한 지도가 있습니다.

세 가지 경쟁자가 아닌 세 가지 계층

에이전트 기술(agent-skills) 생태계는 세 가지 뚜렷한 계층으로 자리 잡았습니다. 대부분의 프로젝트는 이 중 정확히 하나에 매우 뛰어납니다.

2. 런타임(Runtime) — 하네스(harness). openclaw/openclaw는 기술이 실제로 실행되는 곳입니다: 크로스 플랫폼(cross-platform)이며, 개인 비서 형태를 띠고, 자체적인 대규모 퍼스트 파티(first-party) skills/ 트리를 배포하며, ClawHub를 배포 및 게시 경로로 사용합니다. 하네스는 호출(invocation), 샌드박싱(sandboxing) 및 사용자 대면 루프(user-facing loop)를 소유합니다.

3. 인프라스트럭처(Infrastructure) — 레지스트리(registry). 그것이 바로 SkillHub입니다. 이것은 기술 컬렉션이 아니라, 레지스트리 및 거버넌스(governance) 플랫폼입니다. 이는 위의 두 가지와는 다른 질문에 답합니다: 기술이 귀하의 소유이며 비공개일 때, 누가 그것을 게시할 수 있는지, 프로덕션(production)에서 실행 중인 버전은 무엇인지, 누가 승인했는지, 그리고 지난 화요일에 무슨 일이 있었는지에 대한 답입니다.

이것은 계층 1과 2에 대한 비판이 아닙니다. 레지스트리는 '취향(taste)'을 배포하기에는 잘못된 도구이며, 큐레이션된 공개 컬렉션은 승인 기록이 포함된 회사의 내부 배포 실행 지침(runbook)을 300명의 엔지니어에게 배포하기에는 잘못된 도구입니다.

상호 운용성(interop)은 이미 존재하며 — 그것이 핵심입니다

SkillHub CLI installing into the generic user-level target

• 동일한 형식. SkillHub는 동일한 SKILL.md 레이아웃을 사용하므로, 어떤 Agent Skill 폴더의 스킬이라도 재포장 과정 없이 프라이빗 레지스트리 (private registry)로 즉시 게시됩니다.
• ClawHub 호환 엔드포인트 (ClawHub-compatible endpoints). 서버는 호환 계층 (compatibility layer)을 제공하여, 기존의 ClawHub 스타일 레지스트리 클라이언트가 SkillHub 배포 환경에서도 계속 작동할 수 있도록 합니다. 네이티브 CLI API가 주요 인터페이스이며, 호환 계층은 사용자가 이를 시도하기 위해 클라이언트를 새로 작성할 필요가 없도록 존재합니다.
• 하네스 중립적인 설치 대상 (A harness-neutral install target). CLI 0.1.9 버전에서 사용자 레벨의 ~/.agents/skills 디렉토리로의 설치 기능이 추가되었습니다. 이는 단독으로 사용하거나 ~/.codex/skills 및 ~/.claude/skills와 같은 에이전트 전용 위치와 함께 사용할 수 있으며, 충돌하는 목적지를 방지하기 위한 정규 경로 (canonical-path) 확인 절차를 포함합니다. .agents/는 조용히 크로스 하네스 (cross-harness) 관례로 자리 잡고 있습니다. 결국 이 디렉토리는 컬렉션(collections) 자체가 배포되는 출발지이기 때문입니다.

우리가 명시적으로 시도하지 않는 것

타인의 큐레이션 (curation)을 대신하려는 것이 아닙니다. 스킬의 품질은 편집 작업이며, 컬렉션들이 그 작업에 더 능숙합니다. 만약 귀하의 팀이 내놓은 답이 "우리는 그냥 공개 컬렉션을 설치하면 충분하다"라면, 그것은 완벽한 답변입니다. 프라이빗 스킬이 있고 이를 승인해야 하는 사람이 생기기 전까지는 레지스트리가 필요하지 않습니다.

우리가 실제로 답변을 듣고 싶은 질문

만약 귀하가 하나 이상의 하네스 (harness)에서 스킬을 실행한다면, 의견이 아닌 재현 가능한 구체적인 불호환성 사례를 듣고 싶습니다:

• 한 하네스에서는 요구하지만 다른 하네스에서는 거부하는 SKILL.md 프론트매터 (frontmatter) 필드.
• 하나의 툴체인 (toolchain)에서는 검증되지만 다른 곳에서는 실패하는 패키지.
• 하네스에 필요한 메타데이터 블록 (호출 힌트, 권한 선언 등)이지만 공유 형식 내에 거처할 곳이 없는 경우.

크로스 하네스 스킬 검증은 우리가 가장 직접적인 경험을 가지고 있는 문제 영역이며, 구체적인 오류 사례는 표준에 대한 논쟁보다 훨씬 더 유용합니다.

토론 스레드: https://github.com/iflytek/skillhub/discussions/691