Claude Code에 플러그인 마켓플레이스와 Agent Skills가 들어오면서, 한동안 README 한 줄짜리였던 확장들이 2026년 들어 GitHub star 수만~수십만 단위로 올라왔습니다. star가 많다고 다 좋은 도구는 아니지만, 적어도 “사람들이 실제로 설치해서 쓰고 있다"는 신호는 됩니다. 이 글은 그중 개발 작업에 직접 쓰이는 것들을 골라, 무엇을 잘하고 언제 켜는지 정리한 것입니다.
핵심 질문 하나를 먼저 깔아두겠습니다. plan을 누가 들고 있는가. 어떤 도구는 방법론(문서)이 plan을 쥐고 Claude를 가이드하고, 어떤 도구는 Claude가 매 턴 직접 오케스트레이션하고, 또 어떤 기능은 plan을 아예 코드로 옮겨버립니다. 이 차이가 도구를 고르는 기준이 됩니다.
Superpowers — 코드 짜기 전에 한 발 물러서게 만드는 프레임워크
obra/superpowers는 현재 이 분야 star 1위입니다(215,499 stars). 제작자는 Jesse Vincent(obra)이고, Anthropic 공식 플러그인 마켓플레이스에 등재돼 있어 /plugin install superpowers@claude-plugins-official로 바로 설치됩니다. 설명 문구 그대로 “an agentic skills framework & software development methodology that works"입니다.
동작 방식이 특징적입니다. 코딩 에이전트를 켜는 순간부터 작동하는데, 요청을 받자마자 코드를 짜지 않습니다. 한 발 물러서서 “진짜 뭘 하려는 건지” 되묻고, 거기서 spec을 뽑아낸 뒤 읽기 쉬운 단위로 설계를 제시합니다. 승인을 받으면 그때 구현 계획으로 넘어가는데, red/green TDD와 YAGNI, DRY를 강조합니다. 실제 태스크 수행은 subagent-driven-development로 각 단위를 처리하고 리뷰까지 붙입니다. 이 과정에서 스킬이 자동으로 트리거됩니다.
대표 스킬을 보면 성격이 드러납니다. brainstorming은 코드 작성 전에 활성화되어 요구사항을 정제하고, using-git-worktrees는 설계 승인 후 격리된 워크스페이스를 만듭니다. 그 외 writing-plans, subagent-driven-development, 그리고 code-reviewer 에이전트가 묶여 있습니다. Claude Code 외에 Codex CLI/App, Factory Droid, Gemini CLI, OpenCode, Cursor, GitHub Copilot CLI에서도 동작합니다.
여기서 plan은 방법론이 들고 있습니다. Superpowers는 “어떻게 진행할지"의 절차를 스킬 묶음으로 정의해두고, Claude가 그 절차를 따라가도록 가이드합니다.
AWS AI-DLC — 엔터프라이즈 제약을 차단으로 강제하는 방법론
awslabs/aidlc-workflows는 AWS Labs 공식 저장소입니다(2,636 stars). 설명은 “AI-Driven Life Cycle (AI-DLC) adaptive workflow steering rules for AI coding agents”. 이름 그대로 플러그인이라기보다 steering rules 기반의 방법론입니다. Kiro Steering Files를 기반으로 프로젝트 워크스페이스 안에서 동작하고, Claude Code에서는 CLAUDE.md project memory로 워크플로우를 구현합니다.
3단계 적응형 워크플로우로 구성됩니다.
| 단계 | 하는 일 |
|---|---|
| Inception | 요구 분석과 설계 |
| Construction | per-unit 구현/테스트 루프 |
| Operations | 운영 단계 |
Construction의 per-unit loop가 실무적으로 쓸모 있습니다. 복잡한 프로젝트를 병렬화 가능한 work package로 분해하고, 각 package마다 functional design → NFR → code generation → test cycle을 돈다는 구조입니다. 큰 작업을 한 번에 밀어붙이지 않고 단위로 쪼개 검증한다는 점에서 Superpowers의 subagent-driven 접근과 결이 비슷합니다.
엔터프라이즈 환경에서 의미가 큰 부분은 Extension system입니다. HIPAA, 내부 SDK 규칙, 보안 baseline 같은 blocking constraint를 레이어링할 수 있고, 위반 시 경고에 그치지 않고 실제로 차단(blocker)합니다. 코딩 에이전트가 만든 결과물이 조직 정책을 우회하지 못하게 막는 장치입니다. 세션 연속성도 워크스페이스 파일(aidlc-docs/aidlc-state.md)로 관리되어, Cursor에서 시작한 작업을 Claude Code로 이어받는 크로스 하니스가 가능합니다. 지원 대상은 Kiro(구 Amazon Q Developer), Cursor, Cline, Claude Code, GitHub Copilot입니다.
방법론 정의 문서는 AWS DevOps 블로그에 있고, 비공식 Claude Code 플러그인 래퍼인 ijin/aidlc-cc-plugin(17 stars)도 참고용으로 존재합니다.
AI-DLC에서 plan은 워크스페이스의 steering 문서가 들고 있습니다. 상태와 제약이 파일로 박혀 있고, 어떤 하니스로 들어와도 그 문서를 읽어 같은 절차를 잇습니다.
Dynamic Workflows — plan을 코드로 옮긴 네이티브 기능
여기서 분류를 분명히 해야 합니다. Dynamic Workflows는 플러그인도 스킬도 아닙니다. 2026년 5월 28일 Claude Opus 4.8과 함께 출시된 Claude Code 네이티브 기능이고, 현재 research preview입니다(공식 발표, 공식 문서).
정의는 이렇습니다. dynamic workflow는 서브에이전트를 대규모로 오케스트레이션하는 JavaScript 스크립트입니다. Claude가 작업 설명을 받아 스크립트를 직접 작성하면, 런타임이 그 스크립트를 백그라운드에서 실행하고, 세션은 응답 가능한 상태를 유지합니다. 최대 1,000개의 subagent를 병렬로 돌릴 수 있습니다.
핵심 차이가 여기 있습니다. subagent든 skill이든 agent team이든, 보통은 Claude가 매 턴마다 “다음에 뭘 시킬지"를 판단하며 오케스트레이션합니다. 반면 workflow는 그 plan을 코드로 옮깁니다. 루프, 조건 분기, fan-out이 스크립트 안에 결정론적으로 적혀 있고, 런타임이 그대로 집행합니다. Claude의 턴마다 판단이 끼어들지 않으니 대규모 반복 작업에서 흔들림이 줄어듭니다.
활성화는 두 가지입니다. 프롬프트에 “workflow” 키워드를 넣거나, effort 메뉴의 ‘ultracode’ 설정(effort=xhigh에 자동 workflow 판단이 붙음)을 켜는 방식입니다.
OpenAI Codex 플러그인 — 경쟁사가 Claude Code 안으로 들어왔다
이 글에서 가장 흥미로운 사건은 여기입니다. 2026년 3월 30일, OpenAI가 경쟁사 Anthropic의 Claude Code용 공식 플러그인을 직접 출시했습니다. 레포 이름은 openai/codex-plugin-cc이고, 설명은 한 줄로 명확합니다 — “Use Codex from Claude Code to review code or delegate tasks.” 출시 두 달여 만에 20,000 stars를 넘겼습니다. 자사 에이전트(Codex CLI)를 두고도, 경쟁사 도구 안에서 자사 모델을 쓰게 만드는 플러그인을 공식 채널로 낸 셈입니다.
동작 구조부터 정리합니다. 이 플러그인은 Claude Code 안에서 슬래시 커맨드로 로컬에 깔린 Codex CLI(와 Codex app server)를 호출합니다. 즉 Claude Code 세션을 유지한 채 특정 작업만 Codex(GPT 계열)에게 넘기는 구조입니다. 인증·설정·레포 체크아웃은 이미 깔린 Codex 그대로를 씁니다. 설치는 마켓플레이스를 추가(/plugin marketplace add openai/codex-plugin-cc)하고 플러그인을 설치(/plugin install codex@openai-codex)한 뒤 /codex:setup으로 준비 상태를 확인하는 흐름입니다.
커맨드는 두 갈래입니다.
| 커맨드 | 하는 일 |
|---|---|
/codex:review | 현재 변경분/브랜치(--base main)에 대한 read-only 코드 리뷰 |
/codex:adversarial-review | 설계·트레이드오프·실패 모드를 challenge하는 steerable 리뷰 (포커스 텍스트 지정 가능) |
/codex:rescue | Codex 서브에이전트에게 버그 조사·수정 등 작업 위임 |
/codex:status / /codex:result / /codex:cancel | 백그라운드 잡 진행 확인·결과 조회·취소 |
리뷰 쪽이 실무적으로 핵심입니다. /codex:review는 Codex 안에서 /review를 돌린 것과 같은 품질의 리뷰를 Claude Code 워크플로우 안에서 받게 해줍니다. /codex:adversarial-review는 한발 더 나가, “이 캐싱·재시도 설계가 맞았는지 challenge해봐” 식으로 결정 자체를 압박 테스트합니다. auth, 데이터 손실, 롤백, 레이스 컨디션 같은 위험 영역을 콕 집어 다른 모델 패밀리의 시선으로 검증받는 용도입니다. 멀티파일 변경 리뷰는 시간이 걸리니 --background로 돌리고 /codex:status·/codex:result로 확인하는 패턴을 권장합니다.
더 공격적인 옵션이 review gate입니다. /codex:setup --enable-review-gate를 켜면 Stop hook이 Claude의 응답에 맞춰 Codex 리뷰를 돌리고, 문제가 발견되면 stop을 막아 Claude가 먼저 고치게 강제합니다. 사실상 “Claude가 작성 → Codex가 게이트” 루프를 자동화하는 장치인데, 공식 문서도 Claude/Codex 루프가 길어져 usage limit을 빠르게 소진할 수 있다고 경고합니다. 적극 모니터링할 때만 켜라는 단서가 붙습니다.
plan 축에서 보면 이건 앞의 세 도구와 결이 다릅니다. plan을 어디 두느냐의 문제가 아니라, 결과물을 누가 검증하느냐의 문제입니다. 같은 모델 패밀리가 자기 코드를 자기가 리뷰하면 같은 맹점을 공유하기 쉽습니다. codex-plugin-cc는 그 검증을 다른 벤더의 모델에게 위임해 교차 LLM 리뷰를 만듭니다. 경쟁 관계인 두 모델을 한 워크플로우 안에서 견제용으로 묶는다는 발상이 핵심입니다.
참고로 스킬 포맷 자체도 벤더를 넘어 표준화되고 있습니다. OpenAI는 openai/skills “Skills Catalog for Codex"도 운영하는데, 이쪽은 Codex용 스킬 모음이지만 Agent Skills 개방 표준(“write once, use everywhere”)을 따르기 때문에 같은 포맷이 Claude Code에서도 동작합니다. 같은 표준을 쓰는 vercel-labs/agent-skills, remotion-dev/skills도 있습니다. 플러그인(codex-plugin-cc)은 “경쟁사 도구 안에서 자사 모델을 호출"하는 직접 통합이고, 스킬 카탈로그(openai/skills)는 “포맷 표준 덕에 호환"되는 간접 호환이라는 점에서 둘은 층위가 다릅니다.
네 가지를 한 축에 놓으면
앞의 셋(Superpowers / AI-DLC / Dynamic Workflows)은 같은 “에이전트가 큰 작업을 단위로 쪼개 처리한다"는 목표를 두고도 plan을 두는 위치가 다릅니다. codex-plugin-cc는 결이 하나 다른데, plan의 위치가 아니라 결과물을 누가 검증하느냐라는 별도 축을 건드립니다. 네 가지를 한 표에 놓으면 이렇게 갈립니다.
| 도구 | 분류 | 무엇이 다른가 |
|---|---|---|
| Superpowers | 플러그인(스킬 묶음) | plan을 방법론이 절차로 가이드 |
| AI-DLC | steering rules 방법론 | plan을 워크스페이스 문서가 상태/제약으로 보유 |
| Dynamic Workflows | Claude Code 네이티브 기능 | plan을 **코드(스크립트)**가 결정론적으로 보유 |
| openai/codex-plugin-cc | OpenAI 공식 플러그인 | plan 위치가 아니라 검증 주체 — 다른 벤더 모델로 교차 리뷰 |
앞의 세 도구는 “plan을 어디에 둘 것인가"의 선택지입니다. 방법론에 두면 사람이 읽고 고치기 쉽고, 문서에 두면 하니스를 넘나들며 상태가 유지되고, 코드에 두면 실행이 결정론적이고 대규모로 확장됩니다. 셋은 경쟁 관계라기보다 plan의 위치를 고르는 문제입니다.
codex-plugin-cc는 그 축과 직교합니다. plan을 어디에 두든, 만들어진 결과물을 같은 모델 패밀리가 자기검증하느냐 다른 벤더 모델이 교차검증하느냐를 가르기 때문입니다. 그래서 앞 셋 중 무엇을 쓰든 그 위에 얹어 “검증 레이어"로 함께 돌릴 수 있습니다 — 대체재가 아니라 보완재에 가깝습니다.
그 외 알아둘 만한 도구
- hesreallyhim/awesome-claude-code (45,454 stars) — 스킬, 훅, 슬래시 커맨드, 오케스트레이터, 플러그인을 모은 큐레이션 리스트입니다. 뭐가 있는지부터 훑을 때 출발점으로 둘 만합니다.
- SuperClaude-Org/SuperClaude_Framework (23,133 stars) — “configuration framework that enhances Claude Code with specialized commands, cognitive personas, and development methodologies”. Superpowers처럼 커맨드와 방법론을 묶은 프레임워크 계열입니다.
- ryoppippi/ccusage (15,409 stars) — “Analyze coding (agent) CLI token usage and costs from local data.” 로컬 데이터에서 토큰/비용을 분석하는 유틸 CLI입니다. 워크플로우 도구가 아니라 사용량 가시성을 주는 쪽입니다.
선택 가이드
정리하면 이렇게 고르면 됩니다.
- 코드부터 짜는 습관을 막고 spec → 설계 → TDD 구현으로 강제하고 싶다면 Superpowers.
- 조직 보안/규정 제약을 실제 차단으로 박아두고, 하니스를 넘나들며 상태를 잇고 싶다면 AI-DLC.
- 수백 단위의 반복 작업을 결정론적 스크립트로 대규모 병렬 실행하고 싶다면 Dynamic Workflows(플러그인 설치 아님, 네이티브 기능).
- 뭐가 있는지부터 보고 싶으면 awesome-claude-code, 토큰 비용이 궁금하면 ccusage.
- Claude Code 안에서 Codex(GPT 계열)에게 코드 리뷰·작업을 위임하고, 다른 모델 패밀리로 교차 검증하고 싶으면 openai/codex-plugin-cc. 표준 포맷의 OpenAI 스킬을 가져다 쓰고 싶으면 openai/skills(Codex 카탈로그, Claude Code 호환).
star 순위는 인기의 지표일 뿐이고, 본인 워크플로우에서 plan을 어디에 두고 싶은지가 선택의 축입니다.
References
- obra/superpowers
- awslabs/aidlc-workflows
- AI-Driven Development Life Cycle — AWS DevOps Blog
- ijin/aidlc-cc-plugin
- Introducing Dynamic Workflows in Claude Code
- Dynamic Workflows — Claude Code Docs
- openai/codex-plugin-cc — Use Codex from Claude Code
- Introducing Codex Plugin for Claude Code — OpenAI Developer Community
- openai/skills — Skills Catalog for Codex
- Agent Skills open standard
- vercel-labs/agent-skills
- remotion-dev/skills
- hesreallyhim/awesome-claude-code
- SuperClaude-Org/SuperClaude_Framework
- ryoppippi/ccusage