---
original_title: "wshobson/agents — Multi-harness agentic plugin marketplace"
creative_title: "한 번 쓰고 다섯 군데로 배달한다 — AI 에이전트 마켓플레이스의 설계도"
source_url: "https://github.com/wshobson/agents"
created: 2026-08-28
purpose: "AI 코딩 에이전트 자산을 '단일 소스 → 다중 배포' 구조로 관리하는 오픈소스 사례를 분석하고, 강의·콘텐츠 제작에 차용 가능한 설계 패턴을 추출한다."
---

# 한 번 쓰고 다섯 군데로 배달한다 — AI 에이전트 마켓플레이스의 설계도

원문: https://github.com/wshobson/agents

---

## Core Synthesis

### 쉬운 설명

이 저장소는 AI 코딩 도구에 끼워 넣을 수 있는 **"전문가 설정 세트"를 모아놓은 가게**입니다. Python 전문가, 보안 점검 전문가, 데이터 분석 전문가처럼 역할별로 나눠진 에이전트가 202개, 지식 묶음(Skills)이 180개, 슬래시 명령어가 105개 들어 있습니다. 전부 그냥 Markdown 텍스트 파일이라서, 코딩 없이 글만 써서 만들 수 있습니다.

가장 영리한 점은 **원본은 딱 한 벌만 관리한다**는 것입니다. `plugins/` 폴더의 Markdown 하나를 고치면, `make generate` 명령 한 줄로 Claude Code, Codex CLI, Cursor, OpenCode, Gemini CLI, GitHub Copilot 각각의 형식에 맞게 자동 변환됩니다. 그리고 플러그인을 설치해도 **그 플러그인의 내용만** AI에게 읽힙니다. 202개를 다 읽히면 AI가 헷갈리고 비용도 폭증하기 때문입니다. 별 38,900개가 붙은 이유는 에이전트 개수가 많아서가 아니라, 이 관리 구조가 깔끔해서입니다.

**Core Message**
개발자 wshobson(Seth Hobson)이 만든 이 저장소는, AI 에이전트를 도구별로 따로따로 만들던 기존 방식을 뒤집어 **하나의 Markdown 원본에서 5개 이상의 도구용 결과물을 자동 생성하는 구조**를 제시합니다. 핵심 주장은 "에이전트를 많이 만드는 것"이 아니라 **"필요한 것만 골라 컨텍스트에 올리고, 나머지는 잠들어 있게 하는 것"**이 성능과 비용을 좌우한다는 것입니다. 여기에 프롬프트 품질을 정적 검사·LLM 심사·몬테카를로 3단계로 채점하는 `plugin-eval`을 붙여, 프롬프트를 감이 아니라 **측정 가능한 자산**으로 다룹니다.

**Core Keywords**

- Multi-harness (다중 하네스 배포)
- Single source of truth (`plugins/` 단일 원본)
- Progressive disclosure (점진적 공개)
- Agent Skills / SKILL.md
- Plugin marketplace (`/plugin marketplace add`)
- Tiered model strategy (모델 계층 배분)
- Orchestrator (다중 에이전트 조율, 16개)
- plugin-eval (3계층 품질 평가)
- Monte Carlo reliability testing
- `make garden` (드리프트·죽은 링크 탐지)
- MCP (Model Context Protocol)
- Context budget (컨텍스트 예산)

**Key Framework/Mechanism**

**"단일 원본 → 계층 분배 → 측정" 3단 구조**

1. **Layer 1 — 단일 원본(Single Source)**
   모든 에이전트·스킬·명령어를 `plugins/` 아래 Markdown으로만 작성합니다. 도구별 코드를 따로 쓰지 않고, 어댑터가 각 도구의 고유 형식(Codex는 8KB 스킬 용량 제한, OpenCode는 `permission:` 블록, Gemini는 TOML)으로 변환합니다.

2. **Layer 2 — 점진적 공개(Progressive Disclosure)**
   플러그인 단위로 격리되어, 설치한 플러그인의 구성 요소만 컨텍스트에 로드됩니다. 예를 들어 `python-development` 하나를 설치하면 에이전트 3개 + 명령어 1개 + 스킬 16개만 올라옵니다.

3. **Layer 3 — 모델 계층 배분(Tiered Model Strategy)**
   작업 난이도에 따라 5단계로 모델을 배정합니다. Tier 0 Fable 5(초장기 자율 작업, 옵트인·고비용) → Tier 1 Opus(아키텍처·보안·코드리뷰) → Tier 2 inherit(사용자 선택) → Tier 3 Sonnet(문서·테스트·디버깅) → Tier 4 Haiku(배포·SEO 등 빠른 작업).

4. **Layer 4 — 3계층 품질 측정(plugin-eval)**
   Static(구조 검사, 2초 미만, 무료) → LLM Judge(4개 항목 의미 평가, 약 30초, Haiku+Sonnet) → Monte Carlo(50~100회 반복 실행으로 신뢰도 통계, 약 2~5분). 깊이를 선택해서 비용과 정확도를 맞바꿉니다.

**Why This Works:**
- 원본이 하나라서 수정 비용이 도구 수에 비례해 늘지 않습니다.
- 안 쓰는 200여 개가 컨텍스트를 먹지 않아 정확도와 비용이 함께 개선됩니다.
- 쉬운 작업에 비싼 모델을 쓰지 않아 낭비가 줄어듭니다.
- 품질을 숫자로 재기 때문에 "좋아진 것 같다"가 아니라 개선 여부를 증명할 수 있습니다.
- `make validate` / `make garden`으로 구조 붕괴와 죽은 링크를 자동 감지해 노후화를 늦춥니다.

**Why This Matters**

- **생산성**: 도구 6개에 각각 대응하던 작업이 명령어 한 줄(`make generate-all`)로 줄어듭니다. 유지보수 대상이 6벌에서 1벌로 감소합니다.
- **인지 부하**: 202개 에이전트를 외울 필요가 없습니다. 필요한 플러그인만 설치하는 방식이라 사용자가 기억해야 할 표면적이 작습니다.
- **확장성**: 새 AI 도구가 나와도 어댑터 하나만 추가하면 됩니다. 원본 콘텐츠는 손대지 않습니다.
- **기존 가정 반박**: "에이전트는 많을수록 좋다"는 통념을 반박합니다. 전부 로드하면 오히려 성능이 떨어지므로, **선택적 로딩이 개수보다 중요**합니다.
- **학습 가능성**: 전부 Markdown이라 프로그래밍 지식 없이 읽고 고칠 수 있습니다. 강의 소재로서 진입 장벽이 낮습니다.
- **품질의 객관화**: 프롬프트 품질을 채점 가능한 대상으로 만든 사례입니다. 이 발상 자체가 커리큘럼 자산 관리에도 그대로 적용됩니다.

**What to Remember**

- **원본은 한 벌만 유지하라.** 결과물이 여러 형식으로 필요하면 원본을 복제하지 말고 **변환기를 만들어라.** md → Notion → Oopy 3층 구조에 그대로 대응되는 원리다.
- **전부 올리지 말고 필요한 것만 올려라.** 프롬프트·규칙·자료를 통째로 넣지 말고 작업 단위로 쪼개서 그때그때 불러라.
- **작업 난이도에 따라 모델을 나눠 써라.** 요약·분류는 Haiku급, 설계·검토는 Opus급으로 배정해 비용을 통제하라.
- **품질 검사를 3단계로 설계하라.** 형식 검사는 자동화(무료), 의미 판단만 LLM에게, 신뢰도 확인은 반복 실행으로. 결정론과 LLM 판단을 섞는 방식 그대로다.
- **직접 배포는 하지 마라.** CLI 설치·`make` 빌드·6개 도구 대응이 필요하므로, 수강생 배포용이 아니라 **강의에서 시연할 소재**로만 다뤄라.
- **숫자는 반드시 당일 확인하라.** 플러그인 개수와 지원 도구 목록이 수 주 단위로 바뀐다. 강의 자료에 숫자를 박아 넣지 마라.

**Bottom Line**
이 저장소의 진짜 가치는 202개 에이전트가 아니라 **"단일 원본 → 자동 변환 → 선택적 로딩 → 측정"이라는 관리 구조**에 있습니다. 도구 자체는 관망하되, 이 4단 구조는 지금 바로 차용하십시오. 오늘 당장 본인의 프롬프트·수업 자료 중 두 곳 이상에 중복 복사된 파일을 하나 골라, 원본 한 벌만 남기고 나머지를 변환으로 만드는 실험을 시작하십시오.

---

## 전문가 의견 (사실 기반)

이 저장소는 2026년 8월 28일 기준 **별 38.9k, 포크 4.1k, 커밋 546개, MIT 라이선스**의 개인(wshobson) 프로젝트로, README에는 **91 플러그인 / 202 에이전트 / 180 스킬 / 105 명령어 / 16 오케스트레이터**로 표기되어 있습니다. 다만 교차 검색 결과에는 **93 플러그인 / 181 스킬**, 지원 하네스에 Gemini CLI 대신 **Google Antigravity**가 들어간 버전이 함께 잡힙니다. 즉 **수 주 단위로 숫자와 지원 대상이 바뀌는 저장소**이며, 이는 강의 자료에 수치를 고정해 넣으면 곧바로 낡는다는 뜻입니다(저장소 스스로도 `make garden`으로 드리프트를 감지합니다). 이해관계 측면에서 이 프로젝트는 상업 제품 판매가 아닌 MIT 오픈소스이나, 외부 연동(Pensyve/HOL Guard 등 `git-subdir` 항목)은 제3자 상용 서비스와 연결될 수 있으므로 무비판 수용은 권하지 않습니다. 또한 "202개 에이전트"는 **품질이 검증된 202개가 아니라 존재하는 202개**이며, 저장소가 `plugin-eval`을 별도로 만든 사실 자체가 개별 품질 편차를 인정한다는 방증입니다. 결론적으로 도구로서의 직접 도입 가치는 중간(설치 복잡도·다중 하네스 의존·잦은 변경 때문에 커리큘럼 후보로는 부적합)이지만, **설계 패턴으로서의 차용 가치는 높습니다.** 특히 '점진적 공개'와 '3계층 품질 평가'는 컨텍스트 비용과 재현성 문제를 동시에 다루는 드문 사례로, 10분 단위 실습 콘텐츠의 구조 설계에 그대로 옮길 수 있습니다.

---

**자체 평가: 88/100**
- 원문 fetch + 교차 검색으로 수치 충돌(91 vs 93 플러그인, Gemini CLI vs Antigravity)을 잡아내 명시함 (+)
- 도구/패턴 분리, 배포 계층 원칙 등 기존 판단 기준과 일관되게 평가함 (+)
- 감점 12점: 하위 문서(`docs/plugins.md`, `docs/plugin-eval.md`)를 직접 열지 않아 plugin-eval의 4개 평가 항목 구체 내역과 개별 플러그인 품질을 확인하지 못함. 실사용 후기·이슈 트래커를 확인하지 않아 실제 작동 안정성은 미검증 상태.