plugins 딥다이브
— AI에게 일하는 방법을 배포하는 설계

1프로젝트 한줄 요약

plugins는 AI 에이전트가 따를 규칙, 특정 작업의 절차, 외부 도구 연결, 이벤트 처리 코드를 하나의 설치 단위로 묶는 방법과 사례를 제공합니다. 이 저장소에서 배울 핵심은 프롬프트 한 줄보다, 지침과 코드를 함께 검증하고 배포하는 구조입니다.

중심에는 두 종류의 JSON이 있습니다. .cursor-plugin/marketplace.json은 전체 상품 목록이고, 각 플러그인의 .cursor-plugin/plugin.json은 그 상품의 설명서입니다. 목록의 source로 디렉토리를 찾고, 개별 명세에서 스킬·규칙·훅·MCP 설정의 위치를 알아냅니다.

1-1. 처음에는 파일 세 개의 연결만 보자

# 아래는 연결 관계를 설명하기 위한 학습용 축약입니다.
.cursor-plugin/marketplace.json
  plugins[...].name   = "continual-learning"
  plugins[...].source = "continual-learning"

continual-learning/.cursor-plugin/plugin.json
  hooks = "./hooks/hooks.json"

continual-learning/hooks/hooks.json
  stop 이벤트 → Bun으로 continual-learning-stop.ts 실행

이 연결을 이해하면 거대한 파일 목록이 덜 막막해집니다. 전체 목록에서 하나를 고르고, 그 명세를 읽고, 명세가 가리키는 파일로 이동하면 됩니다. 이 글에서는 명세 → 검증 → 실행 조건 → 상태 관리 순서로 난도를 높입니다.

2왜 주목받는가

2-1. 일회성 지시를 재사용 가능한 단위로 만든다

AI에게 매번 같은 작업 방식과 도구 사용법을 설명하는 일은 번거롭습니다. 플러그인은 그 설명을 파일에 담아 버전으로 관리하고, 다른 사람도 같은 구성으로 사용할 수 있게 합니다. Cursor 공식 문서도 규칙·스킬·에이전트·명령·MCP 서버·훅을 배포 가능한 묶음으로 설명합니다.

GitHub Trending Weekly #8이라는 순위와 스타 13,682개는 관심의 크기를 보여 줍니다. 다만 별 증가의 직접 원인을 입증하는 자료는 아닙니다. 아래의 주목 요인은 저장소 구성에서 읽어 낸 해석이며, 특정 발표가 순위를 만들었다고 단정하지 않습니다.

• 공식 명세와 예제가 함께 있습니다. 필드 설명을 읽고 실제 plugin.json과 바로 비교할 수 있습니다.
• 작은 설정부터 복잡한 제어 코드까지 폭이 넓습니다. 원격 MCP 연결과 상태 복구 루프를 같은 구조 안에서 만납니다.
• 업무 절차를 코드 리뷰 대상으로 만듭니다. 스킬의 설명 변경도 Git 차이로 검토할 수 있습니다.
• 호환성을 실제 변환 코드로 다룹니다. pstack에는 Claude Code용 트리를 생성하는 도구가 있습니다.

2-2. 비슷한 확장 방식과 무엇이 다른가

비교 근거는 Claude Code 플러그인 문서, VS Code 확장 가이드와 두 마켓플레이스 파일입니다. 기능 범위가 다르므로 어느 쪽의 성능이나 품질이 더 높다는 비교로 읽으면 안 됩니다.

2-3. 공식 목록도 여러 층으로 읽어야 한다

Cursor 목록의 119개 항목은 루트 디렉토리의 플러그인 17개와 third_party/의 102개로 나뉩니다. 외부 서비스 이름이 붙은 디렉토리에 그 서비스의 백엔드 구현까지 들어 있다고 생각하면 규모를 잘못 해석하게 됩니다. Vanta 사례에서 이 저장소가 제공하는 것은 원격 연결의 선언과 사용 설명입니다.

플러그인의 설치 단위를 이해하려면, 저장소에 있는 파일과 외부 실행 환경이 맡은 일을 나눠 읽어야 합니다.

3기술 스택 전체 지도

3-1. 전체 기술 지형

루트에는 package.json, Cargo.toml, pyproject.toml, go.mod, Dockerfile이 없습니다. 저장소 전체를 하나의 서버로 설치하는 구조로 설명하면 부정확합니다. 의존성은 일부 스킬의 scripts/ 아래에 있고, 나머지 많은 플러그인은 문서와 JSON으로 구성됩니다.

3-2. 백엔드에 해당하는 실행 코드

orchestrate/skills/orchestrate/scripts/package.json은 클라우드 에이전트를 조정하는 독립 패키지입니다. 주요 진입점은 orchestrate/skills/orchestrate/scripts/cli.ts이며, 실행 제어는 orchestrate/skills/orchestrate/scripts/core/loop.ts와 orchestrate/skills/orchestrate/scripts/core/agent-manager.ts가 맡습니다. orchestrate/skills/orchestrate/scripts/schemas.ts는 계획과 상태 데이터를 검사하며, 저장과 복구는 파일·Git·SDK에 걸쳐 이루어집니다.

여기서 ^가 붙은 숫자는 허용 범위이고, 잠금 파일의 숫자는 그 범위를 실제로 해석한 버전입니다. bun-types 1.3.13은 타입 정의 패키지의 버전이므로 Bun 실행 파일의 고정 버전으로 바꿔 읽으면 안 됩니다.

orchestrate/skills/orchestrate/scripts/tsconfig.json에는 strict: true, noEmit: true, moduleResolution: "bundler", allowImportingTsExtensions: true가 있습니다. 타입 검사에서는 JavaScript 파일을 출력하지 않고, 실행은 Bun이 맡도록 구성한 사례입니다.

3-3. 다른 스킬은 다른 의존성을 가진다

pstack/skills/poteto-mode/scripts/package.json은 commander 14.0.0을 고정하지만, bun-types와 typescript는 latest로 선언합니다. pstack/skills/poteto-mode/scripts/bun.lock에는 각각 1.3.14, 7.0.2가 기록되어 있습니다. 따라서 저장소 전체의 TypeScript 버전이 하나라고 표현할 수 없습니다.

3-4. 프론트엔드는 어디에 있는가

추적 파일에는 .tsx가 없고, React·Next.js 앱용 루트 패키지도 없습니다. 화면 코드의 구체적 사례는 cursor-team-kit/skills/pr-review-canvas/template.html, cursor-team-kit/skills/pr-review-canvas/styles.css, cursor-team-kit/skills/pr-review-canvas/renderer.js입니다.

renderer.js의 loadPrDiffs()는 문서에 포함된 차이 데이터를 읽고, renderDiff()는 가져오기 문장과 공백만 바뀐 차이를 정리한 뒤 표를 만듭니다. detectMoves()는 최소 3줄과 비교 구간의 70% 일치라는 경험적 조건으로 이동을 추정합니다. 이는 정밀한 구문 분석기가 아니라 리뷰 표시를 돕는 휴리스틱입니다.

esc()가 코드 문자열의 특수문자를 이스케이프하는 점도 배울 만합니다. 표시할 코드가 HTML 구조로 해석되지 않게 하는 기본 경계입니다. 소스 경로가 비슷해 보여도 독립 플러그인 pr-review-canvas/와 이 보조 자산의 위치는 구분해야 합니다.

3-5. 인프라·빌드: CI가 실제로 하는 일

.github/workflows/validate-plugins.yml은 지정 경로가 바뀐 Pull Request에 반응합니다. ubuntu-latest에서 actions/checkout@v4, actions/setup-node@v4를 쓰고 Node.js 20을 선택합니다. 이 값은 CI 환경의 선택이지 모든 플러그인의 최소 실행 버전 선언은 아닙니다.

# CI 설정에 기록된 검사 순서. 실행 명령의 구조를 읽기 위한 예시입니다.
npm install --no-save ajv ajv-formats
node scripts/validate-plugins.mjs
node scripts/generate-pstack-harness-trees.mjs --check
node --test pstack/skills/*/scripts/test/*.test.mjs

ajv와 ajv-formats는 이 명령에 버전이 고정되어 있지 않습니다. 또 이 워크플로에는 orchestrate의 bun test 단계가 없습니다. 테스트 파일이 많다는 사실과 CI가 그 테스트를 실제로 실행한다는 사실은 별도로 확인해야 합니다.

기술 스택을 읽을 때는 선언된 의존성, 잠금 버전, 실제 import, CI 실행 경로를 함께 대조해야 합니다.

4아키텍처 심화 분석

4-0. 전체 시스템 구조

윗부분은 플러그인의 공통 포장 방식입니다. 아랫부분의 상태 루프는 orchestrate라는 개별 플러그인의 구현입니다. 모든 플러그인이 이 루프를 통과하거나 같은 저장소를 사용하는 구조는 아닙니다.

4-1. 패턴 ① 선언적 계약과 여러 단계의 검증

schemas/plugin.schema.json의 required는 ["name"]입니다. 설명·버전·작성자는 실용적으로 중요해도 스키마상 필수는 아닙니다. additionalProperties: false는 최상위의 알 수 없는 필드를 거부합니다.

// schemas/plugin.schema.json의 핵심 부분
{
  "type": "object",
  "required": ["name"],
  "additionalProperties": false,
  "properties": {
    "name": {
      "type": "string",
      "minLength": 1,
      "pattern": "^[a-z0-9]([a-z0-9.-]*[a-z0-9])?$"
    }
  }
}

예를 들어 displayName을 displayNmae으로 잘못 쓰면 허용 필드가 아니므로 거부됩니다. 반면 version은 일반 문자열로만 검사합니다. 엄격한 버전 정규식은 minClientVersions가 참조하는 semver 정의에 붙어 있습니다.

scripts/validate-plugins.mjs는 154줄입니다. loadJSON()으로 파일을 읽고, new Ajv({ allErrors: true })로 검증기를 만든 뒤 addFormats()로 URI·이메일 같은 형식 검사를 추가합니다. fail()은 오류 수를 누적하고 마지막 종료 코드에 반영합니다.

1. 전체 목록 검사: Cursor 마켓플레이스를 marketplace.schema.json으로 검증합니다.
2. 개별 항목 검사: resolve(root, entry.source)로 디렉토리를 찾고 명세의 존재와 스키마를 검사합니다.
3. 교차 검사: 목록의 이름과 명세의 이름이 일치하는지 확인합니다.
4. 호환 명세 검사: Claude 목록의 명세 존재·이름을 확인하고, 같은 소스의 여러 매니페스트 버전을 비교합니다.

여기서 allErrors: true는 스키마 오류를 여러 개 모으는 설정입니다. loadJSON()에는 별도 예외 처리가 없어, JSON 문법 자체가 잘못되면 파싱 예외로 중단될 수 있습니다. 모든 종류의 오류가 끝까지 누적된다고 일반화하면 안 됩니다.

create-plugin/skills/review-plugin-submission/SKILL.md는 중복 이름·frontmatter·선언 경로도 점검하라고 안내합니다. 이는 검토 절차의 범위이며, 루트 검증기가 전부 자동화했다는 뜻은 아닙니다.

4-2. 패턴 ② 이벤트를 조건으로 거르는 기억 갱신 훅

continual-learning/hooks/continual-learning-stop.ts의 main()은 표준 입력의 JSON 이벤트를 읽습니다. shouldCountTurn()은 status === "completed"이면서 loop_count === 0인 경우만 횟수로 셉니다.

// 실제 shouldTrigger 조건. 모든 조건을 동시에 만족해야 합니다.
const shouldTrigger =
  countedTurn &&
  turnsSinceLastRun >= effectiveMinTurns &&
  minutesSinceLastRun >= effectiveMinMinutes &&
  hasTranscriptAdvanced;

기본 문턱은 완료 10회와 120분입니다. 대화 기록 파일의 수정 시각도 앞으로 나아가야 합니다. lastRunAtMs가 0인 첫 실행에서는 지난 시간을 Infinity로 보므로, 최초 갱신 전에 반드시 120분을 기다리는 로직은 아닙니다.

조건이 맞으면 상태를 저장하고 followup_message를 JSON으로 출력합니다. 훅이 직접 AGENTS.md를 편집하는 것은 아닙니다. 후속 메시지가 스킬과 기억 갱신 에이전트에게 증분 처리를 요청합니다.

직전의 generation_id를 저장하는 것은 같은 이벤트를 연속으로 다시 처리하지 않으려는 장치입니다. 전체 이벤트 이력을 보관하는 중복 제거 시스템은 아닙니다. 같은 이벤트가 항상 정확히 한 번만 처리된다는 보장으로 확대해서 읽으면 안 됩니다.

상태 파일이 없거나 손상되었거나 버전이 다르면 loadState()는 초기 상태를 반환합니다. 입력 파싱·상태 저장 등의 오류가 main()의 예외 처리에 도달하면 표준 오류로 기록하고, 표준 출력에는 빈 JSON을 내보내며 종료 코드 0을 반환합니다. 보조 학습 기능의 실패로 주 작업을 중단시키지 않으려는 선택이며, 그만큼 오류 로그를 따로 살펴야 합니다.

4-3. 패턴 ③ 상태를 다시 맞추는 조정 루프

orchestrate/skills/orchestrate/scripts/core/agent-manager.ts의 AgentManager.load()가 계획과 저장된 상태를 읽어 관리자 객체를 만듭니다. runOrchestrateLoop()는 이 객체를 받아 기존 실행에 재연결을 시도한 뒤, 의존 조건을 만족한 대기 작업을 시작하는 과정을 반복합니다. 한 번의 명령 호출보다, 중단 후 다시 호출했을 때의 동작이 중요한 코드입니다.

orchestrate/skills/orchestrate/scripts/schemas.ts의 상태 열거형은 pending, running, handed-off, error, cancelled, pruned입니다. 작업 종류는 worker, subplanner, verifier로 구분합니다.

// orchestrate/skills/orchestrate/scripts/core/agent-manager.ts — depsSatisfied() 원문
depsSatisfied(task: TaskState): boolean {
  for (const dep of task.dependsOn ?? []) {
    const ds = this.getTask(dep);
    if (!ds || ds.status !== "handed-off") return false;
  }
  return true;
}

이 함수의 조건은 의존 작업의 인계 완료입니다. handed-off 자체가 제품의 정확성 검증을 뜻하지는 않습니다. 인계 메시지에 보고된 검증 수준은 live-ui-verified, unit-test-verified, type-check-only 같은 별도 verification 값으로 기록합니다. 이 값은 작업자나 검증자가 보고한 내용을 파싱한 것이므로, 값 자체가 검증의 증거는 아닙니다.

루프는 spawnReadyPending()으로 시작 가능한 작업을 살피며, 진행할 일이 남으면 다음 순회까지 최대 10초를 기다립니다. 중지 신호인 Andon이 활성화되어 있으면 새 작업 생성을 멈춥니다. pendingCouldStillSpawn()는 의존 관계를 재귀적으로 보면서 실패한 의존성이나 순환 때문에 진행할 수 없는 경우를 판별합니다.

waitAndHandoff()는 결과 인계 파일을 먼저 쓴 뒤 상태를 바꾸도록 구성되어 있습니다. 다음 작업이 handed-off를 보았는데 정작 읽을 결과 파일이 없는 순서를 피하려는 설계입니다. 다만 파일 이름 변경만으로 여러 프로세스의 동시 쓰기나 전체 Git 작업까지 트랜잭션이 되는 것은 아닙니다.

syncStateToGit()는 우선 로컬 상태를 저장하며, 계획의 syncStateToGit 설정이 켜졌을 때 Git 스냅샷도 기록합니다. 함수 이름만 보고 모든 실행에서 원격 동기화가 보장된다고 해석하지 않는 것이 중요합니다.

오래 실행되는 자동화에서는 일을 시작하는 코드만큼, 상태를 남기고 다시 이어 가는 코드가 중요합니다.

4-4. 패턴 ④ 하나의 원본에서 실행 환경별 산출물 생성

scripts/generate-pstack-harness-trees.mjs는 pstack/의 내용을 바탕으로 harness/pstack/claude-code/를 만듭니다. 호환판을 사람이 따로 편집해 두 벌의 문서가 서서히 어긋나는 문제를 줄이는 방식입니다.

1. walk()가 파일을 순회합니다. node_modules와 .DS_Store는 제외합니다.
2. classify()가 Cursor 전용 용어 사용 여부를 모읍니다. 별도의 검사 루프가 스킬 폴더 이름과 frontmatter 이름을 비교합니다.
3. render()가 스킬·에이전트·가이드·호환 문서·라이선스·명세를 복사 대상으로 구성합니다.
4. 필요한 스킬에는 Claude Code용 어댑터 문서를 읽으라는 안내를 넣고, 포함하지 않는 파일의 링크를 GitHub 주소로 바꿉니다.
5. --check에서는 예상 파일과 현재 파일의 바이트·실행 권한 차이를 비교해 불일치가 있으면 실패합니다.

이 생성기는 모든 문장을 다른 실행 환경에 맞게 자동 번역하는 도구는 아닙니다. 알려진 용어 목록과 어댑터 안내를 이용한 변환입니다. 또한 harness/를 pstack/ 밖에 두어 Cursor가 플러그인 폴더를 복사할 때 호환판까지 함께 설치하지 않게 했습니다.

4-5. 최신 커밋에서 읽는 작은 설계 사례: Vanta 지역 선택

커밋 8b3326d의 제목은 Vanta 지역 선택 PR의 병합을 가리킵니다. 현재 파일에서는 third_party/vanta/.cursor-plugin/plugin.json의 variables.properties.VANTA_MCP_HOST.enum에 미국·유럽·호주의 세 호스트가 선언되어 있습니다.

// third_party/vanta/mcp.json 원문 구조
{
  "mcpServers": {
    "vanta": {
      "type": "http",
      "url": "https://${VANTA_MCP_HOST}/mcp",
      "placement": "server"
    }
  }
}

서버 URL을 지역마다 복사해 별도 플러그인을 만드는 대신, 설정 변수를 끼워 넣습니다. minClientVersions.cursor는 3.13.0입니다. 변수 값의 저장과 URL 치환은 클라이언트가 담당하며, 이 저장소의 JSON은 허용 값과 URL 형식을 선언합니다.

third_party/vanta/README.md 기준으로 인증은 OAuth 로그인 방식이며, 지역을 바꾸면 다시 로그인해야 합니다. 도구 호출 권한은 연결을 승인한 Vanta 사용자의 권한을 따릅니다.

5디렉토리 구조 해부

5-1. 파일 수와 코드 규모를 오해하지 않는 법

커밋 8b3326d에는 추적 파일이 1,223개 있습니다. 이 중 171개 파일은 harness/ 아래에 있으므로, 이를 제외한 파일은 1,052개입니다. 생성된 호환판이 원본 내용을 상당 부분 포함하므로 전체 줄 수만으로 독립 구현량을 판단하면 부풀려질 수 있습니다.

SKILL.md는 전체 171개, 생성 트리를 제외하면 114개입니다. 플러그인 119개와 스킬 114개는 서로 다른 단위입니다. MCP 설정 중심의 플러그인에는 스킬이 없을 수 있고, 하나의 플러그인에는 여러 스킬이 들어갈 수 있습니다.

5-2. 추천하는 소스 읽기 순서

1. .cursor-plugin/marketplace.json에서 이름 하나와 source를 찾습니다.
2. 그 디렉토리의 .cursor-plugin/plugin.json에서 명시된 구성 요소를 찾습니다.
3. SKILL.md의 frontmatter와 본문을 구분하고, 호출되는 스크립트가 있는지 확인합니다.
4. 실행 코드가 있다면 입력·판단·출력·저장 위치를 각각 적습니다.
5. 검증기와 CI가 그 파일의 어떤 성질을 확인하는지 역으로 추적합니다.

디렉토리를 이해했다는 것은 파일 이름을 외웠다는 뜻보다, 변경할 책임과 검사할 책임을 구분했다는 뜻입니다.

6학습 포인트 (기술별)

6-1. JSON Schema: 타입과 업무 규칙은 다르다

name이 문자열인지 확인하는 것과, 다른 플러그인과 이름이 겹치지 않는지 확인하는 것은 다른 문제입니다. 스키마는 문서의 모양을, 검증기 코드는 파일 사이의 관계를 주로 담당합니다.

• 배울 것: required, properties, additionalProperties, oneOf, $ref의 역할.
• 읽을 곳: schemas/plugin.schema.json의 mcpServers는 문자열·객체·배열을 허용합니다.
• 실습 아이디어: 허용되는 데이터 모양 세 가지를 써 보고, 실행 환경이 각각 어떻게 읽어야 할지 설명합니다.

6-2. Markdown·frontmatter: 문서도 인터페이스다

create-plugin/skills/create-plugin-scaffold/SKILL.md의 앞부분은 이름과 설명을 제공하고, 본문은 입력·절차·결과를 안내합니다. 같은 파일 안에서 발견을 위한 메타데이터와 작업을 위한 지침이 역할을 나눕니다.

# 학습용 스킬 예시
---
name: explain-manifest
description: 플러그인 명세의 필수 필드와 연결 경로를 설명할 때 사용합니다.
---

# 명세 설명
1. name과 구성 요소 경로를 찾는다.
2. 스키마에 있는 제약과 비교한다.
3. 확인된 사실과 확인하지 못한 동작을 나눠 설명한다.

Agent Skills 명세는 SKILL.md의 frontmatter와 name·description을 정의합니다. 플러그인 이름의 정규식과 스킬 이름의 제약이 완전히 같다고 가정하지 말고 각각 확인하는 연습을 해 보세요.

6-3. TypeScript·Zod: 정적 타입 밖에서 들어오는 데이터

외부 JSON을 as SomeType으로 단언해도 데이터의 실제 내용이 바뀌지는 않습니다. orchestrate/skills/orchestrate/scripts/schemas.ts는 Zod로 런타임 검증을 하고, orchestrate/skills/orchestrate/scripts/tools/generate-json-schemas.ts의 writeSchema()는 같은 정의를 JSON Schema로 내보냅니다.

• 배울 것: 컴파일 때의 타입 검사와 실행 때의 데이터 검사를 구별합니다.
• 읽을 곳: PlanTaskSchema의 z.discriminatedUnion("type", ...).
• 실습 아이디어: worker와 verifier의 필수 정보가 왜 다른지 표로 정리합니다.

6-4. 파일 입출력·이벤트: 아무 일도 하지 않는 경우를 설계한다

continual-learning 훅은 매번 학습을 실행하지 않습니다. 상태·횟수·시간·기록 변경을 함께 확인합니다. 자동화를 만들 때는 성공 조건뿐 아니라 반복 호출, 입력 누락, 손상된 상태 파일의 처리도 중요합니다.

• 배울 것: 표준 입력과 출력의 계약, 수정 시각을 이용한 증분 판단, 직전 이벤트 중복 방지.
• 읽을 곳: loadState(), getTranscriptMtimeMs(), shouldCountTurn().
• 실습 아이디어: 상태 파일이 없을 때와 버전이 다를 때 어떤 초기값으로 돌아가는지 추적합니다.

6-5. 상태 머신·테스트: 시간이 걸리는 기능을 빠르게 검토한다

runOrchestrateLoop()는 now와 sleep을 옵션으로 받습니다. 테스트가 실제 한 시간을 기다리는 대신 가짜 시계를 주입할 수 있게 만든 것입니다. orchestrate/skills/orchestrate/scripts/__tests__/checkpoint-restart.test.ts는 제한 시간 뒤 종료 코드 100과 상태 저장 요청을 확인합니다.

orchestrate/skills/orchestrate/scripts/core/handoff.ts의 parseHandoffVerification()도 좋은 입문 사례입니다. 예전 형식의 pass를 가장 강한 검증 성공이 아닌 type-check-only로 보수적으로 옮깁니다. orchestrate/skills/orchestrate/scripts/__tests__/handoff-verification-parser.test.ts는 잘못된 값·빈 값·줄바꿈 차이·이전 형식 등을 나눠 다룹니다.

좋은 테스트를 설계하려면 성공 여부 하나보다, 입력 조건에 따라 달라지는 관찰 가능한 결과를 먼저 정해야 합니다.

6-6. HTML·JavaScript: 코드를 화면에 안전하게 표시하기

renderer.js의 esc()는 문자열의 &, <, >를 바꿉니다. 차이 내용에 태그처럼 생긴 코드가 있어도 화면의 구조로 해석되지 않게 하려는 처리입니다.

실습 아이디어: 문자열 <div>안녕</div>를 그대로 표시하려면 어떤 문자가 바뀌어야 하는지 적어 보세요. 코드를 보여 주는 기능에서는 표시 대상과 문서 구조를 구분하는 일이 기본입니다.

7하드웨어 / 시스템 요구사항

저장소 전체에 적용되는 공식 CPU·RAM 최소 사양은 명시되어 있지 않습니다. 아래 표는 파일에서 확인할 수 있는 실행 조건과, 소스 학습에 필요한 조건을 구분한 것입니다.

추적 파일의 내용 크기는 합계 약 10.5MB이며 .git과 설치 의존성은 포함하지 않은 값입니다. 원격 에이전트의 자원 사용량이나 패키지 설치 후 디스크 사용량을 이 숫자로 추정해서는 안 됩니다.

orchestrate가 사용하는 인증 값과 선택적 Slack 연동은 기능 사용을 위한 조건입니다. 읽기 중심 실습에는 실제 계정·인증 정보·네트워크 요청이 필요하지 않습니다.

8직접 해볼 수 있는 실습 과제

다섯 과제는 저장소 스크립트 실행이나 외부 서비스 접속 없이 진행할 수 있습니다. 원본은 읽기 대상으로 두고, 학습용 메모·JSON 예제·상태표를 별도 파일에 작성하세요. 각 과제의 완료 기준은 다음 단계로 넘어갈 만큼 이해했는지 판단하는 기준입니다.

{ "name": "study-plugin" }
{ "name": "Study_Plugin" }
{ "name": "study-plugin", "displayNmae": "학습" }
{ "name": "study-plugin", "version": "banana" }

9관련 기술 심화 학습 로드맵

주당 학습량은 개인의 경험에 따라 조절하세요. 앞 주의 결과물이 다음 주의 입력이 되도록 순서를 잡았습니다. 운영 계정이나 실제 에이전트 실행은 이 로드맵의 필수 조건이 아닙니다.

9-1. 진도가 막힐 때 돌아갈 지점

• 파일 연결이 헷갈리면: source와 hooks처럼 경로를 담는 필드만 먼저 따라갑니다.
• TypeScript가 어려우면: 타입 선언을 잠시 접고 main()의 입력·조건·출력만 적습니다.
• 루프가 복잡하면: 작업을 두 개로 줄이고 의존성이 있는 한 경우만 종이에 추적합니다.
• CI가 낯설면: 각 명령의 입력 파일과 실패할 때의 종료 코드를 대응시킵니다.

9-2. 다음 저장소에서도 사용할 읽기 질문

어떤 데이터가 들어오는가? 그 데이터는 어디서 검사되는가? 무엇이 상태로 남는가? 프로세스가 사라져도 일을 이어 갈 수 있는가? 문서의 약속 중 CI가 확인하는 것은 무엇인가? 이 다섯 질문은 플러그인뿐 아니라 배치 처리·작업 큐·외부 API 연동을 읽을 때도 유용합니다.

학습의 도착점은 모든 파일을 읽는 것이 아니라, 작은 설계 변경의 영향과 검증 방법을 설명할 수 있는 상태입니다.

10핵심 키워드 사전

11참고 링크

11-1. 공식 저장소와 분석에 사용한 소스

• cursor/plugins 공식 저장소 — 플러그인 명세와 공식 목록.
• 분석 기준 커밋의 전체 파일 — 이후 변경과 구분할 기준점.
• Cursor 마켓플레이스 · Claude Code 마켓플레이스 — 두 목록의 실제 등록 범위.
• 개별 명세 스키마 · 목록 스키마 — 필수 필드와 타입.
• 플러그인 검증기 · CI 설정 — 실제 자동 검사 범위.
• 제작 스킬 · 제출 검토 스킬 — 절차상의 약속과 코드 검사의 차이.
• 기억 갱신 훅 · 훅 설정 · 해당 README — 기본값을 교차 확인할 자료.
• orchestrate 의존성 선언 · 잠금 파일 — 버전 범위와 해석 결과.
• 조정 루프 · AgentManager — 시작·인계·복구와 상태 저장.
• 계획·상태 데이터 계약 · JSON Schema 생성기 — 타입과 스키마를 연결하는 방식.
• 결과 인계 파서 · 체크포인트 테스트 — 결과 해석과 시간 제어 사례.
• 호환 트리 생성기 · pstack 스크립트 의존성 · 잠금 파일.
• 리뷰 캔버스 렌더러 — 문자열 처리와 차이 표시의 사례.
• Vanta 명세 · MCP 설정 · 사용 설명 — 지역 변수와 원격 실행 경계.

11-2. 관련 기술의 공식 문서

• Cursor 플러그인 문서 — 구성 요소와 설치 개념.
• Agent Skills 명세 — 스킬 구조와 frontmatter 제약.
• Claude Code 플러그인 문서 · VS Code 확장 가이드 — 다른 확장 방식과 비교.
• MCP 아키텍처 — 호스트·클라이언트·서버의 역할.
• JSON Schema 안내 · Ajv 시작 안내 — 선언과 검증기의 관계.
• TypeScript 문서 · Zod 문서 · Bun 문서 — 타입·런타임 검증·실행 환경.
• GitHub Actions 문서 — Pull Request와 자동 검사.
• GitHub Trending Weekly — 주간 관심 저장소 목록. 순위는 시점에 따라 바뀝니다.

11-3. 현재 상태 (2026-10-23 GitHub 기준)

11-4. 언어별 대략적인 줄 수

추적 파일의 확장자별 줄바꿈 수를 합산했습니다. 빈 줄·주석·테스트를 포함하며 바이너리 이미지는 아래 집계에서 제외했습니다. 오른쪽 열은 harness/ 전체를 뺀 값입니다. 서로 다른 언어의 줄 수는 개발 난이도나 품질의 점수가 아닙니다.

TypeScript 테스트·지원 파일은 생성 트리 제외 기준 34개, 7,883줄입니다. 이 수치는 __tests__/ 또는 이름에 .test.가 있는 TypeScript 파일을 센 값입니다. 다른 언어의 테스트는 포함하지 않으며, 모든 테스트의 실행 성공을 뜻하지 않습니다.