Claude Code의 새로운 숨겨진 기능 Swarms, 멀티 에이전트 팀 모드 공개
(twitter.com/NicerInPerson)- Swarms는 Claude Code 내부에 존재하지만 공개되지 않았던 멀티 에이전트 오케스트레이션 기능
- 사용자는 더 이상 단일 AI 코더와 대화하지 않고 팀 리드 역할의 AI와 상호작용
- 팀 리드는 직접 코드를 작성하지 않고 계획 수립과 작업 분배, 결과를 종합하여, 하위 에이전트에게 역할을 분배
- 승인된 계획 이후 전문화된 작업자 에이전트들이 병렬로 실행되어 실제 구현을 담당
- Claude Code가 단일 도구를 넘어 팀 단위 개발 프로세스로 확장되는 흐름을 보여줌
작동 방식
- 사용자가 계획을 승인하면 Delegation Mode로 전환됨
- 전문 작업자 에이전트들이 여러개 생성되어 병렬로 작업 수행
- 각 작업자는 코드 작성, 분석, 수정 등 실질적인 구현 작업 담당
- 작업자 간 메시지를 통해 진행 상황과 의존성 조율 수행
- 모든 결과는 팀 리드에게 집계되어 최종 응답으로 반환됨
claude-sneakpeek 도구
- claude-sneakpeek Repo는 Claude Code의 기능 플래그가 열린 병렬 빌드 제공
- Swarms 모드를 포함한 미공개 기능을 체험 가능하며, 기존 Claude Code 설치와 완전히 분리된 환경으로 실행됨
- 별도의 설정, 세션, MCP 서버, 인증 정보 사용
-
클로드 코드에 내장되어 있지만 아직 공개되지 않은 추가 기능들이 제공됨
- Swarm mode를 통한 네이티브 멀티 에이전트 실행 지원
- Delegate mode를 통한 백그라운드 에이전트 생성
- 팀원 간 메시징과 작업 소유권 관리 기능 제공
-
별도 모델 및 제공자 지원
- Z.ai, MiniMax, OpenRouter 지원하며, cc-mirror를 통한 로컬 모델 연동 가능
Hacker News 의견들
-
솔직히 미친 소리처럼 들릴 수도 있지만, 가장 높은 품질의 코드를 얻은 적이 있음
비용은 10배쯤 들었지만, 여러 하위 에이전트를 가진 전체 “프로젝트 팀”을 Opus 인스턴스 하나로 관리하게 했음
작업은 레거시 Java 서버를 C# .NET 10으로 포팅하는 것이었고, 9명의 에이전트와 7단계 Kanban, 분리된 Git Worktree 구조를 사용했음
각 역할은 다음과 같았음 —
Manager(Claude Opus 4.5): Kanban 상태에 따라 에이전트를 깨우는 글로벌 이벤트 루프
Product Owner(Claude Opus 4.5): 전략 담당, 스코프 크리프 방지
Scrum Master(Opus 4.5): 백로그 우선순위 지정 및 티켓 배정
Architect(Sonnet 4.5): 설계 전담, 구현은 하지 않음
Archaeologist(Grok-Free): 필요할 때만 레거시 Java 디컴파일을 읽음
CAB(Opus 4.5): 디자인 및 코드 단계에서 기능을 거부하는 게이트키퍼
Dev Pair(Sonnet 4.5 + Haiku 4.5): AD-TDD 루프, Junior가 실패 테스트 작성, Senior가 수정
Librarian(Gemini 2.5): 문서 관리 및 회고 트리거
솔직히 “이게 꼭 필요하냐?” 하면 아마 “아니오”겠지만, AI 에이전트들이 협업하는 걸 보는 게 너무 재밌었음
초기 프로세스 버전은 여기 이미지에 있음- 기술적인 세부사항을 공유해줄 수 있는지 궁금함
순수 프롬프트 기반인지, 플러그인인지, 아니면 스크립트로 반복 호출하는 구조인지 알고 싶음
Kanban은 어디에 존재하는지도 궁금함 - 나도 이와 비슷한 구조를 쓰고 있음
코디네이터 하나와 백엔드, 프론트엔드, DB 전문가 같은 전문화된 에이전트 몇 명으로 구성된 형태임
핵심은 코디네이터임. 내 인지 부하를 줄이고, 전체 진행 상황을 잘 추적해줌 - 일반적으로 Scrum Master는 티켓을 직접 배정하지 않음
- 다음 단계는 네가 만든 걸 서비스화하는 것이라고 생각함
“원숭이랑 말하고 싶지 않다, 오르간 연주자와 말하고 싶다”는 말처럼, 처음엔 매니저와 프로그램 매니저 인터뷰로 시작하고, 이후엔 그들이 알아서 진행하며 데모와 업데이트만 요청하는 식이 될 것 같음. 웃김 - 이게 풍자인지 진심인지 궁금함
- 기술적인 세부사항을 공유해줄 수 있는지 궁금함
-
사실 이건 Claude에 내장된 sub agent 기능을 활용한 것임
Go로 30만 줄짜리 tmux 추상화 같은 걸 만들 필요 없음
Claude에게 백그라운드 sub agent로 병렬 작업을 시키면 됨
프롬프트 전달, 진행 추적, 리포팅용 파일을 두는 게 좋고, 각 에이전트를 별도 worktree로 제한하는 걸 추천함
내가 이 패턴을 workforest.space에 정리 중임
대부분은 오케스트레이터를 따로 만들고 있지만, 사실 Claude 자체가 최고의 오케스트레이터임- 이건 단순 sub agent가 아님
기존 도구들과의 차이는 대화 단위가 아니라 작업 단위 추상화라는 점임
Claude Code는 제3자 앱 문제로 대화 중심이라 한계가 있었는데, Claude Code Web이 그걸 처음으로 확장함
이 방식은 AI가 스스로 작업을 조율하게 하며, 사용자가 계속 프롬프트를 던질 필요가 없음
복잡하지만 AI가 다른 AI를 관리하는 구조로 진화하고 있음 - 사실 이건 새로운 기능이라기보다, Claude Code가 이미 가진 sub agent를 실제 구현에 활용하도록 한 것임
다만 계획 세부사항이 부족해서 신뢰성은 아직 떨어짐 - 기존 sub agent와는 다름
메인 에이전트가 위임 중심의 컨텍스트 모드로 전환되고, 팀 기반 태스크 시스템과 메일박스 시스템이 통합된 형태임
플러그인으로는 구현할 수 없는 수준의 통합임 - “stacked PR” 시각화 덕분에 개념을 바로 이해했음
나는 커밋을 PR처럼 쌓아두고 리베이스로 정리하는데, 이게 꽤 고통스러웠음
이제는 브랜치를 2~3개로 나누고, 충돌을 최소화하며 관리하는 방식으로 개선할 수 있을 것 같음 - 나도 메인 Claude 인스턴스를 매니저 역할로 두고, 구현 에이전트들을 관리하게 함
컨텍스트를 깔끔히 유지하면서 품질 높은 결과를 내는 데 도움이 됨
- 이건 단순 sub agent가 아님
-
나는 코드가 더 짧고 품질 높은 방향으로 발전하길 원함
하지만 지금의 흐름은 반대로 가는 것 같음
모델이 더 견고해지고, 상식과 피드백 루프가 강화되면 유용하겠지만, 현재로선 “코드가 많을수록 좋다”는 식으로 오히려 문제를 키움
멋진 데모는 가능하지만, 실제 운영 환경에서는 10~100배 더 복잡한 코드가 될 것 같음- 나도 비슷한 경험이 있음
Claude가 CI에 테스트 커버리지 통계를 추가하라 했더니, nyc가 설치 안 돼 있다고 bash로 Istanbul을 재구현하려고 함
결국 “그냥 nyc 설치해”라고 말해야 했음 - 아직 이 기능이 공개되지 않은 걸 보면, Anthropic도 모델이 충분히 준비되지 않았다고 판단한 듯함
그래도 이런 실험이 모델의 한계를 넓히는 데 도움이 될 것 같음
지금은 아니더라도 2026년쯤엔 가능할지도 모름
- 나도 비슷한 경험이 있음
-
HN에서 주기적으로 AI 코딩 에이전트 인기 순위를 조사하는 투표가 있었으면 좋겠음
언어별 TIOBE Index처럼, 어떤 모델이 인기를 얻고 있는지 추세를 보고 싶음- 그냥 마음에 드는 걸 하나 골라 쓰면 됨
순위 경쟁은 결국 돌고 도는 하이프 사이클임 - 비슷한 설문을 막 시작했음. 참여 환영함 → agentic-coding-survey.pages.dev
- 커뮤니티 의견은 아니지만, 나는 lmarena 리더보드를 자주 참고함
MiniMax 2.1이 대부분의 GPT보다 위에 있는 게 흥미로웠음
openrouter.ai에서 모델의 처리량과 비용도 대략 파악 가능함 - 나는 Zvi Mowshowitz의 뉴스레터로 최신 동향을 따라감
덕분에 Opus 4.5를 출시 일주일 만에 메인으로 쓰게 됨 - 내 에이전트 스킬이 skills.sh 디렉토리 상위 10위 안에 있음
그 사용자층의 약 80%가 Claude Code, 75%가 darwin-arm64 환경임
- 그냥 마음에 드는 걸 하나 골라 쓰면 됨
-
Claude가 너무 많은 코드를 생성해서 리뷰가 어려워지는 문제가 있음
일부는 “테스트만 통과하면 됐다”라고 하지만, 장기 유지보수 프로젝트에서는 불안함
장기 운영 프로젝트에서 YOLO식 코드 생성을 해본 사람들의 경험이 궁금함- 실제 프로 환경에서는 한 번에 하나의 에이전트만 다루는 게 충분함
코드 품질이 아직 낮고, 디버깅도 자주 틀림
그래도 검색·이해·아이디어 확장에는 유용함
개인용 실험 프로젝트라면 YOLO 접근도 괜찮음 - 나는 Graphite/Cursor에서 일하는 입장이지만, CC에게 변경사항을 stack 형태로 관리하게 하고, 자동 리뷰 에이전트를 붙이면 대규모 변경도 이해하기 쉬움
이렇게 하면 코드 생성은 자동화하면서도 시스템 이해도는 유지할 수 있음 - Claude Code가 코드를 작성하면, 내가 만든 “codex-review” 스킬로 마지막 커밋을 리뷰하게 함
Codex에게 리뷰 포인트를 제안하게 하고, 실제 리뷰에서 그 정확도를 검증함 - 지금은 너무 이른 시점이라 결과를 보기 어렵지만, 올해 말쯤엔 모래 위에 지은 성 같은 프로젝트들이 어떤 결과를 내는지 보게 될 것 같음
- 실제 프로 환경에서는 한 번에 하나의 에이전트만 다루는 게 충분함
-
“이제 AI 코더가 아니라 팀 리드와 대화하는 것”이라는 문구가 있었는데,
정작 그 트윗조차 AI가 쓴 것 같아 웃김- 맞음, 이런 수사적 표현이 AI에서 너무 자주 반복됨
-
2026년에는 에이전트 오케스트레이터가 주요 트렌드가 될 것 같음
기존 소프트웨어 용어(팀 리드, 팀 멤버 등)를 그대로 쓰는 게 이해도와 수용성을 높일 것임- 동의함. Gas Town 같은 복잡한 개념들은 모델의 비정상적 행동을 보정하기 위한 우회책일 뿐임
Anthropic이 자체 모델을 조율할 수 있다면 이런 레이어는 불필요해질 것임
결국 핵심은 메시징과 태스크 관리임 - 하지만 나는 Polecats 같은 개념이 과도한 인간화(anthropomorphization) 를 막는 데 도움이 된다고 생각함
- 동의함. Gas Town 같은 복잡한 개념들은 모델의 비정상적 행동을 보정하기 위한 우회책일 뿐임
-
“팀 리드와 팀 전체에게, 이 버튼을 빨갛게 만들어라”라는 말이 재밌었음
- “수석 엔지니어! 아키텍처 필요! 마케팅팀, 셀럽 광고! 제품팀, 로드맵! ML팀, 학습 데이터 반영! 재무팀, ROI 계산! 운영팀, 24/7 커버!”
결국 결론은 “좋아, 이제 버튼을 빨갛게 만들어!”였음. 완벽한 풍자임 - Claude가 단순히 프롬프트로 할 수 있다 해도, 우리는 그걸로 끝났다고 인정하지 않을 것임
이 영상을 보면 느낌이 옴 - 기본 시스템 프롬프트가 swarm 모드를 언제 써야 하는지 잘 판단하도록 되어 있음
CLAUDE.md에서 추가 지침을 주면, 사소한 작업에는 swarm 모드를 쓰지 않게 조정 가능함
- “수석 엔지니어! 아키텍처 필요! 마케팅팀, 셀럽 광고! 제품팀, 로드맵! ML팀, 학습 데이터 반영! 재무팀, ROI 계산! 운영팀, 24/7 커버!”
-
최근 2.1.9 버전에서 메인 루프가 하위 에이전트를 오케스트레이션하는 방식이 완전히 달라졌음
“FTSChunkManager agent가 아직 실행 중이지만 진행 중이니 기다리자” 같은 로그가 뜨고, 스택 트레이스와 JSON 출력이 함께 나옴 -
Claude Code 데스크톱 앱에서 이런 동작을 직접 봤음
마스터 태스크 아래에서 수많은 워커 리더 에이전트들이 코드베이스를 탐색하고, 리포트와 TODO 리스트를 작성함
다른 시스템이 그걸 종합해 마스터 스키마와 계획을 만듦
나는 devops, frontend, architecture, security 채팅을 각각 만들고, 각 채팅이 끝나면 로그를 남기고 서로 업데이트를 주고받음
SSH로 droplet에 연결해 터미널을 쓰게 하면, Claude가 스스로 빌드·수정·테스트·검증을 반복함
이렇게 3일 만에 이 프로젝트를 완성했음- 사실 이건 단순히 여러 병렬 탐색 에이전트를 띄워서 결과를 합치는 기본 기능임
- oh-my-opencode와 매우 유사한 동작임