요즘 Claude Code 관련 도구가 빠르게 늘어나면서 "뭘 써야 할지 모르겠다" 는 질문을 종종 봅니다. 그런데 단순히 "이게 제일 좋다" 고 말하기는 어렵습니다. 도구마다 전제하는 워크플로우가 다르고, 본인 작업 패턴과 맞지 않으면 좋은 도구도 결국 안 쓰게 됩니다.

그래서 한 번 카테고리별로 정리해봤습니다. 도구별 장단점 위주로 보고, 마지막에 "어떤 워크플로우에 어떤 도구가 맞는지" 를 정리하겠습니다.

GitHub 스타 수가 중심은 아닙니다. 스타 수는 관심도와 채택 신호일 수는 있지만, 품질 보증서는 아닙니다. 특히 AI 코딩 도구는 마케팅, 밈, 유명인 효과, 실제 생산성 개선이 뒤섞여 움직입니다. 그래서 이 글에서는 스타 수보다 도구가 전제하는 워크플로우를 기준으로 보겠습니다.

기준 시점: 2026년 5월 19일 확인 기준입니다. AI 코딩 도구 생태계는 변화가 빠르기 때문에, 실제 도입 전에는 각 프로젝트의 최신 README와 릴리스 상태를 다시 확인하는 편이 안전합니다.

두 카테고리부터 분리

먼저 큰 분류 두 가지를 분리해야 합니다. 이걸 안 하고 비교하면 "사과와 오렌지 비교" 가 됩니다.

카테고리 A: 독립 코딩 하네스

자체 LLM 호출, 자체 UI/UX, 자체 실행 흐름을 가진 도구입니다. Anthropic API, OpenAI API, Gemini, 로컬 LLM, Ollama, OpenAI-compatible endpoint 등을 직접 연결합니다. Claude Code 없이도 단독으로 돌아갑니다.

카테고리 B: Claude Code 플러그인/확장

Claude Code 위에 워크플로우를 얹는 도구입니다. LLM 호출과 도구 실행은 기본적으로 Claude Code가 담당합니다. 플러그인은 컨벤션, 명령어, 문서 구조, 에이전트 프롬프트, hook, MCP, workflow layer 같은 "위에 얹는 것" 을 제공합니다.

이 둘은 결이 다릅니다.

"Claude Code만 쓰겠다" 면 B 카테고리에서 고르는 게 맞고, "여러 모델을 직접 비교하고 싶다" 면 A 카테고리를 보는 게 맞습니다.

카테고리 A: 독립 코딩 하네스

aider

aider는 오래전부터 널리 쓰인 CLI 기반 AI pair programming 도구입니다. git-native 설계가 강하고, repo map을 통해 큰 코드베이스 컨텍스트를 관리합니다.

장점

• 안정성이 비교적 검증된 편입니다. 오래 운영된 도구라 엣지 케이스가 많이 다듬어졌습니다.

• git-native 설계가 강점입니다. aider가 파일을 수정하면 변경사항을 커밋으로 남길 수 있어, 나중에 되돌리거나 추적하기 쉽습니다.

• Claude, GPT, Gemini, 로컬 LLM, OpenAI-compatible endpoint 등 다양한 모델을 연결할 수 있습니다.

• repo map 기능으로 전체 저장소 구조를 요약해 큰 코드베이스에서도 어느 정도 맥락을 유지합니다.

단점

• 학습 곡선이 있습니다. 커맨드 체계와 git 워크플로우에 익숙해야 자연스럽게 씁니다.

• TUI/GUI 중심 도구가 아니라, 시각적 피드백은 약한 편입니다.

• 한국어 인터페이스는 없습니다. 영어 기반 CLI가 부담스러운 사용자에게는 진입 장벽이 있습니다.

cline

cline은 VS Code/JetBrains 확장으로 많이 알려져 있지만, 현재는 CLI, SDK, Kanban까지 확장된 AI 코딩 에이전트 플랫폼에 가깝습니다.

장점

• IDE 통합이 강합니다. 코드 변경을 IDE 안에서 바로 검토하고 승인할 수 있어 기존 IDE 중심 워크플로우와 잘 맞습니다.

• Kanban 기반 병렬 작업과 worktree 지원이 강점입니다. 각 작업 카드를 별도 worktree와 터미널에서 돌릴 수 있어, 여러 에이전트 작업을 병렬로 진행하기 좋습니다.

• Human-in-the-loop 승인 흐름이 잘 잡혀 있습니다. 위험한 파일 변경이나 명령 실행을 단계적으로 확인할 수 있습니다.

단점

• 승인 단계가 많아 자동화 흐름이 자주 끊길 수 있습니다.

• IDE 중심 워크플로우가 맞지 않는 사용자에게는 무겁게 느껴질 수 있습니다.

• 컨텍스트 관리가 IDE/프로젝트 단위에 묶이는 경향이 있습니다.

opencode

opencode는 터미널, IDE, 데스크톱을 모두 지원하는 오픈소스 AI 코딩 에이전트입니다. Claude Code와 비슷하게 터미널 중심으로 쓰기 좋지만, Claude Code 플러그인이 아니라 독립 도구입니다.

장점

• TUI/CLI 중심 사용성이 깔끔합니다.

• 터미널, IDE, 데스크톱 등 여러 surface를 지원합니다.

• 멀티 세션을 지원해 같은 프로젝트 안에서 여러 에이전트를 병렬로 돌리는 흐름에 적합합니다.

• 성장 속도가 빠르고, 커뮤니티 관심도가 높습니다.

단점

• 빠르게 성장 중인 만큼 버전 변화와 인터페이스 변화가 있을 수 있습니다.

• aider처럼 오래 축적된 git-native pair programming 경험과는 성격이 다릅니다.

• Claude Code와 비슷한 사용감을 줄 수는 있지만, Claude Code 자체의 플러그인 생태계와는 별개입니다.

crush

crush는 charmbracelet 계열의 터미널 기반 AI 코딩 에이전트입니다. Charm 생태계답게 TUI 미감과 터미널 사용성이 강점입니다.

장점

• 터미널 UI 완성도가 높습니다. 시각적 사용감이 중요한 사용자에게 매력적입니다.

• 멀티 모델을 지원하고, 세션 기반 작업 흐름을 제공합니다.

• LSP 컨텍스트를 활용해 코드 이해를 보강합니다.

• MCP 확장도 지원합니다.

단점

• 비교적 신생 도구라 실전 사례와 문서가 aider만큼 축적되지는 않았습니다.

• 일부 기능은 아직 검증 중인 영역으로 보는 편이 안전합니다.

• 미감과 사용성은 강하지만, 본인의 실제 개발 흐름과 맞는지는 별도로 확인해야 합니다.

카테고리 B: Claude Code 플러그인/확장

Claude Code 플러그인/확장 생태계는 빠르게 커지고 있습니다. 다만 여기서는 숫자 경쟁보다, 실제로 워크플로우를 어떻게 바꾸는지를 기준으로 보겠습니다.

superpowers

superpowers는 Jesse Vincent가 만든 에이전틱 스킬 프레임워크입니다. Claude Code뿐 아니라 Codex, Gemini CLI, OpenCode, Cursor 등 여러 AI 코딩 도구에서 쓸 수 있도록 설계된 스킬/워크플로우 패키지에 가깝습니다.

장점

• 방법론이 명확합니다. 브레인스토밍, 작은 작업 단위 분해, TDD, 서브에이전트 활용, 코드 리뷰 같은 시니어 개발자의 반복 패턴을 스킬로 정리합니다.

• 에이전트가 바로 코드를 짜기보다, 먼저 요구사항을 좁히고 작업 단위를 분해하는 흐름을 유도합니다.

• Claude Code에만 묶이지 않습니다. 여러 AI 코딩 환경에서 같은 방식론을 재사용하려는 방향입니다.

• 특정 런타임보다 "일하는 방식" 을 정리하는 성격이 강합니다.

단점

• TDD와 구조화된 개발 루프가 중심이라, 테스트 인프라가 없는 코드베이스나 일회성 스크립트에는 과할 수 있습니다.

• 슬래시 커맨드와 스킬 사용법을 익혀야 합니다.

• 영어 기반입니다.

feature-dev

feature-dev는 Anthropic 공식 Claude Code 플러그인 중 하나입니다. 기능 개발을 단계적으로 진행하도록 돕는 구조화된 workflow plugin입니다.

장점

• 요구사항 정리, 코드베이스 탐색, 설계, 구현, 테스트, 리뷰, 요약으로 이어지는 7단계 흐름을 제공합니다.

• 코드베이스 탐색과 설계, 리뷰를 별도 전문 에이전트 역할로 나누어 처리합니다.

• Anthropic 공식 플러그인이라 Claude Code와의 호환성 측면에서 상대적으로 안전합니다.

• 기능 개발이라는 명확한 사용처가 있습니다.

단점

• "기능 개발" 에 특화되어 있어, 디버깅·리팩토링·운영 자동화 같은 작업에는 별도 접근이 필요합니다.

• 작은 수정에는 과합니다. 한두 줄 고치는 작업에 7단계 workflow를 태우는 것은 비효율적입니다.

• Claude Code 안에서의 공식 workflow이지, 독립 에이전트 런타임은 아닙니다.

claude-flow 계열

claude-flow 계열 도구는 Claude Code 위에 swarm, memory, MCP, agent orchestration을 얹는 방향의 프로젝트입니다. 이 영역은 이름과 repo, 브랜딩이 빠르게 바뀌는 편이라 실제 도입 전에는 현재 유지되는 repo와 문서를 직접 확인해야 합니다.

장점

• 멀티 에이전트 오케스트레이션을 본격적으로 다룹니다.

• memory, MCP, swarm 같은 개념을 묶어 장기 작업 흐름을 만들려는 방향입니다.

• 단일 에이전트보다 복잡한 작업 분해와 역할 분담에 초점을 둡니다.

단점

• 개념 자체가 복잡합니다. 에이전트 하나로 충분한 작업에는 과합니다.

• 설정과 운영 복잡도가 있습니다.

• "멀티 에이전트" 라는 말이 실제 품질 향상으로 이어지는지는 프로젝트와 작업 성격에 따라 다릅니다.

gstack

gstack은 Y Combinator CEO Garry Tan이 공개한 Claude Code 설정/스킬 묶음입니다. CEO, Designer, Engineering Manager, Release Manager, Doc Engineer, QA 같은 역할 기반 도구들을 포함합니다.

장점

• 제품 의사결정과 출시 흐름을 Claude Code workflow에 넣으려는 방향이 뚜렷합니다.

• "이 기능이 진짜 필요한가" 같은 제품 관점의 질문을 workflow에 포함합니다.

• 자동 PR, 브라우저 QA, 릴리스 관리 같은 흐름과 잘 맞습니다.

• 빠른 출시와 제품 판단이 중요한 팀에는 참고할 만합니다.

단점

• 제품 의사결정자 + 빠른 출시 흐름에 맞춰져 있어, 깊은 엔지니어링 검증이 핵심인 작업에는 부분적으로만 맞을 수 있습니다.

• 특정 개인/조직의 작업 방식이 강하게 반영되어 있어, 그대로 쓰기보다 필요한 부분만 가져오는 편이 현실적입니다.

• 영어 기반입니다.

BKit

BKit은 Claude Code 위에 PDCA, Sprint, Quality Gates, 한국어 트리거를 얹는 플러그인입니다. PDCA는 Plan-Do-Check-Act의 약자로, 제조업 품질관리에서 시작된 반복 개선 사이클입니다. 독립 코딩 하네스라기보다는 Claude Code workflow를 문서화된 프로세스 안에서 운영하도록 돕는 쪽에 가깝습니다. 이건 다모앙에서 매번 칭찬일색인 앙님이 계셔서 글쓰는 김에 한번 분석해 보았습니다.

장점

• 한국어 사용자를 의식한 트리거와 예시가 있습니다.

• PDCA/Sprint 기반 문서 컨벤션을 제공합니다.

• Quality Gates, MCP state reader, hook guardrail, sprint lifecycle 같은 코드 레이어가 있어 단순 프롬프트 묶음으로만 보기는 어렵습니다.

• 런타임 의존성이 거의 없어 설치 부담은 낮은 편입니다.

단점

• 거버넌스 시스템이 무거운 편입니다. PDCA, Sprint, Quality Gate를 전제로 하기 때문에 가벼운 수정이나 빠른 프로토타이핑에는 절차 부담이 큽니다. 학습할 개념과 자산도 많은 편입니다.

• 컨텍스트 비용이 큰 구조입니다. 44개 skill, 34개 agent, 19개 MCP tool, 21개 hook 이벤트 정의가 세션 시작 시 컨텍스트에 주입되는 구조라, 실제 작업에 쓸 컨텍스트 윈도우가 줄어듭니다. LLM은 선택지가 많아질수록 도구 선택 정확도가 떨어지는 경향이 있는데, 100개 가까운 도구 정의가 동시에 노출되면 잘못된 도구를 호출하거나 컨텍스트 오염에 의한 환각(할루시네이션)이 늘 수 있습니다. 같은 카테고리 안에서도 superpowers처럼 핵심 스킬만 두고 명시적 슬래시 커맨드로 호출하는 설계와 비교하면, "기능을 많이 얹을수록 좋다" 는 전통 SaaS 사고에 가까운 구조입니다.

• 같은 카테고리 B 안에서도 적용 범위가 좁은 편입니다. PDCA/Sprint 기반 프로세스가 필요한 사용자에게 매칭되고, 그 외 일반적인 Claude Code 사용자에게는 superpowers나 feature-dev 같은 방법론 중심 플러그인이 더 자연스럽게 맞을 수 있습니다.

어떤 워크플로우에 어떤 도구가 맞나

도구 선택의 기준

도구를 고를 때 "GitHub 스타 수" 나 "마케팅 카피" 가 첫 번째 기준이 되면 안 됩니다.

가장 먼저 볼 것은 이것입니다.

내 워크플로우와 도구가 전제하는 워크플로우가 맞는가?

예를 들어 aider는 git-native CLI pair programming에 강합니다. cline은 IDE 승인 흐름과 worktree 병렬 작업에 강합니다. opencode와 crush는 터미널 중심 독립 에이전트에 가깝습니다. superpowers와 feature-dev는 Claude Code 위에 개발 루프를 얹는 쪽입니다. BKit은 Claude Code 위에 PDCA/Sprint 기반 프로세스 운영을 얹는 쪽입니다.

이걸 구분하지 않으면 도구 비교가 엉망이 됩니다. 당연히 결과도 좋지만은 않을 겁니다.

특히 Claude Code 플러그인을 볼 때는 "무엇을 새로 실행해주는가" 와 "어떤 절차를 추가하는가" 를 구분해야 합니다. 어떤 도구는 실제 실행 능력을 넓혀주고, 어떤 도구는 작업을 더 체계적으로 기록하게 만들고, 어떤 도구는 팀 단위 컨벤션을 강제합니다. 셋 다 쓸모는 있지만, 같은 가치로 보면 안 됩니다.

또 하나 볼 것은, 도구가 하는 일이 "코드를 더 잘 고치는 것" 인지, "작업 절차를 더 잘 기록하는 것" 인지입니다. 후자는 나쁜 것이 아니지만, 이미 본인 workflow가 있는 사용자에게는 생산성 향상보다 절차 증가로 느껴질 수 있습니다.

AI 코딩 도구는 앞으로도 계속 늘어날 겁니다. 그래서 더더욱 도구 이름이나 마케팅톤 보다 구조를 봐야 합니다. 그리고 이런건 매우 쉽습니다. 레포 주소만 넣고 에이전트한테 봐달라고 하면 되니까요.

• 독립 하네스인지, Claude Code 플러그인인지

• 직접 LLM을 호출하는지, Claude Code에 의존하는지

• 상태를 실제로 관리하는지, 문서 컨벤션만 제공하는지

• 검증을 로컬 코드로 하는지, 에이전트 프롬프트에 맡기는지

• 작업 비용을 줄이는지, 새로운 절차를 추가하는지

• 컨텍스트 윈도우를 효율적으로 쓰는지, 도구/스킬 정의로 채우는지

이걸 확인하면 마케팅 노이즈에 덜 흔들립니다. 이제 생각은 외주를 주셔도 되지만 이해는 인간지능이 해야합니다.