GitHub Superpowers v1.1.0: Agent Team 오케스트레이션과 Plan Mode

작성일: 2026년 2월 6일
카테고리: Claude Code, AI 개발 도구, 프로젝트 관리
키워드: GitHub Superpowers, Claude Code, Agent Teams, Plan Mode, 멀티에이전트, 파이프라인

요약

GitHub Superpowers v1.1.0을 릴리즈했다. Claude Code의 Plan Mode와 Agent Teams를 활용하여 v1.0.0에서 드러난 두 가지 문제를 해결한다. 구현 계획 단계에서 코드 수정을 물리적으로 차단하고, 에이전트 간 직접 통신으로 리뷰 피드백 루프를 즉시 작동시킨다.

v1.0.0에서 드러난 두 가지 문제

GitHub Superpowers v1.0.0은 설계부터 PR까지 자동 추적하는 워크플로우를 제공했다. 직접 사용하면서 구조적 한계 두 가지가 드러났다.

문제 1: 계획 단계에서 코드가 수정된다

writing-plans 스킬은 코드베이스를 탐색하고 구현 계획(impl.md)을 작성하는 단계다. 읽기만 해야 하는데, Edit과 Write 도구가 열려 있었다.

writing-plans 스킬 시작
→ 코드베이스 탐색 (Edit/Write 가능 — 위험!)
→ AskUserQuestion으로 수동 승인
→ impl.md 저장

에이전트가 "이 부분은 수정이 필요하겠군" 하면서 계획 단계에서 코드를 직접 고치는 일이 발생했다. 계획과 실행이 뒤섞이면 무엇이 의도된 변경이고 무엇이 실수인지 구분할 수 없다.

건축 설계사가 도면을 그리면서 동시에 벽을 쌓기 시작하는 것과 같다. 도면이 완성되기 전에 벽이 올라가면, 나중에 설계를 변경할 때 이미 쌓은 벽을 허물어야 한다.

문제 2: 리뷰어가 구현자에게 직접 말할 수 없다

v1.0.0의 서브에이전트 구조는 모든 소통이 Lead를 경유했다.

lead → Task(implementer) → 결과 수신
lead → Task(spec-reviewer, 구현 결과 전달) → 결과 수신
lead → Task(quality-reviewer, 리뷰 결과 전달) → 결과 수신

spec-reviewer가 코드에서 문제를 발견하면, Lead에게 보고 → Lead가 implementer에게 전달 → implementer가 수정 → Lead가 재리뷰 요청. 4단계의 중계가 필요했다.

전화기 없는 사무실에서 모든 대화를 중앙 게시판에 적어야 하는 상황과 비슷하다. 전달 과정에서 컨텍스트가 손실되고, 피드백 루프가 느려졌다.

v1.1.0의 해결 방식

1. Plan Mode로 계획과 실행 분리

Claude Code의 Plan Mode를 활용하여 물리적으로 Edit과 Write를 차단했다.

EnterPlanMode
→ 코드베이스 탐색 (Edit/Write 물리적 차단)
→ plan file에 구현 계획 작성
→ ExitPlanMode (사용자 승인 게이트)
→ 승인 후 impl.md 저장

Plan Mode에 진입하면 Glob, Grep, Read 등 읽기 도구만 사용할 수 있다. 에이전트가 아무리 코드를 수정하고 싶어도 도구 자체가 존재하지 않는다.

핵심은 "규칙으로 금지"가 아니라 "도구 제거로 차단"이라는 점이다. 프롬프트에 "코드를 수정하지 마세요"라고 써봤자, 컨텍스트가 길어지면 에이전트가 잊어버린다. 도구 자체가 없으면 잊을 것도 없다.

구분	v1.0.0	v1.1.0
코드 수정 방지	규칙으로 금지 (위반 가능)	도구 자체가 없음 (위반 불가)
승인 방식	AskUserQuestion (수동)	ExitPlanMode (내장 게이트)
실수 가능성	존재	원천 차단

2. Agent Team 파이프라인: 직접 소통

Agent Teams의 SendMessage를 활용하여 에이전트 간 직접 통신을 구현했다.

TeamCreate("impl-feature")
  ├─ implementer (general-purpose) ←→ spec-reviewer (Explore)
  │                                 ←→ quality-reviewer (Explore)
  └─ lead: 완료 알림만 수신

피드백 루프가 4단계에서 2단계로 줄었다:

implementer 구현 완료
  → SendMessage("spec-reviewer", "Task 1 구현 완료. 리뷰 부탁.")

spec-reviewer 이슈 발견
  → SendMessage("implementer", "반환 타입이 스펙과 다릅니다. file:line 참조.")

implementer 수정 후
  → SendMessage("spec-reviewer", "수정 완료. 재리뷰 부탁.")

spec-reviewer 승인
  → SendMessage("quality-reviewer", "스펙 준수 확인. 품질 리뷰 부탁.")

quality-reviewer 승인
  → SendMessage("lead", "Task 1 파이프라인 통과.")

Lead는 최종 결과만 수신한다. 중간 과정의 피드백은 당사자끼리 직접 해결한다.

3. 리뷰어는 코드를 수정할 수 없다

리뷰어의 역할은 코드를 읽고 판단하는 것이다. 수정하는 것이 아니다.

이를 보장하기 위해 리뷰어 에이전트의 타입을 Explore로 설정했다:

에이전트	타입	Edit/Write	역할
implementer	general-purpose	사용 가능	코드 구현
spec-reviewer	Explore	차단	스펙 준수 검토
quality-reviewer	Explore	차단	코드 품질 검토

Explore 타입은 Edit, Write, NotebookEdit 도구가 제공되지 않는다. Plan Mode와 동일한 원리로, 규칙이 아닌 도구 제거로 원천 차단한다.

리뷰어가 "이렇게 고치는 게 좋겠다"고 판단하면, implementer에게 SendMessage로 피드백을 보내고 수정을 맡긴다. 역할 분리가 시스템 레벨에서 강제된다.

4. 병렬 실행 + 에이전트 간 실시간 공유

v1.0.0에서는 독립 작업을 병렬로 실행할 수 있었지만, 에이전트들이 서로의 존재를 몰랐다. Domain A를 수정하다가 Domain B에 영향을 주는 문제를 발견해도 알릴 방법이 없었다.

v1.1.0에서는 팀 안에서 관련 이슈를 즉시 공유한다:

agent-a: Domain A 작업 중 관련 이슈 발견
  → SendMessage("agent-b", "abort flow에서 batch state 관련 이슈 발견. 확인 필요.")

agent-b: 알림 수신 후 자체적으로 대응

agent-a 완료 → SendMessage("lead", "Domain A 완료. 변경 파일: ...")
agent-b 완료 → SendMessage("lead", "Domain B 완료. agent-a 알림 반영함.")
agent-c 완료 → SendMessage("lead", "Domain C 완료.")

fire-and-forget에서 실시간 협업으로 전환된 것이다.

5. Task 의존성 분석

executing-plans 스킬이 impl.md의 Task 간 의존성을 분석하여 최적 실행 방식을 추천한다:

의존성 분석 결과:
- 독립 그룹 A: Task 1 (DB 스키마), Task 3 (프론트엔드) — 병렬 가능
- 순차 체인 B: Task 2 → Task 4 (Task 1 이후)
- 순차 체인 C: Task 5 (Task 2, 3 이후)

추천: Agent Team 병렬 (독립 Task를 동시 실행, 의존 Task는 순차)

방식	적합한 경우
Agent Team 파이프라인	Task 간 의존성이 많을 때 (순차 + 리뷰)
Agent Team 병렬	독립 Task가 50% 이상일 때 (동시 실행)
수동 실행 (워크트리)	단계별 직접 제어가 필요할 때

사용자가 판단할 필요 없이, 의존성 그래프를 기반으로 최적의 실행 전략을 제안한다.

6. 백그라운드 병렬 검증

검증 단계에서 테스트, 린트, 빌드를 순차 실행하면 각각의 완료를 기다려야 한다. 세 명령은 서로 독립적이므로 동시 실행이 가능하다.

# v1.0.0: 순차 실행 (총 3번 대기)
npm test        → 대기... → 완료
npm run lint    → 대기... → 완료
npm run build   → 대기... → 완료

# v1.1.0: 백그라운드 병렬 실행 (1번만 대기)
Bash(command: "npm test", run_in_background: true)       # → task_id_1
Bash(command: "npm run lint", run_in_background: true)    # → task_id_2
Bash(command: "npm run build", run_in_background: true)   # → task_id_3

run_in_background로 동시 실행하면 대기 시간이 가장 긴 명령 하나의 시간으로 수렴한다.

변경된 스킬 목록

스킬	변경 내용
writing-plans	EnterPlanMode/ExitPlanMode 통합
subagent-driven-development	TeamCreate + SendMessage 파이프라인, Explore 리뷰어
dispatching-parallel-agents	Agent Team 병렬 + 에이전트 간 소통
executing-plans	Task 의존성 분석 + 3가지 실행 모드
verification	백그라운드 병렬 검증
using-github-superpowers	Plan Mode, Agent Team 설명 추가

업그레이드

/plugin update github-superpowers

기존 설정(.github/github-superpowers.json)은 변경 없이 그대로 사용된다.

설계 원칙의 확장

v1.0.0의 4가지 원칙에 하나가 추가되었다:

• Test-Driven Development — 테스트 먼저, 항상
• GitHub as Source of Truth — GitHub Issue로 진행 상태 추적
• 자동화된 연결 — 설계 → 구현 → GitHub 자동 연동
• Evidence over Claims — 성공 선언 전 백그라운드 병렬 검증
• Agent Team Orchestration — 에이전트 간 직접 소통으로 협업 (v1.1.0)

v1.1.0을 만들면서 얻은 핵심 교훈은 "규칙보다 구조"다. "코드를 수정하지 마세요"라는 프롬프트는 지켜질 수도 있고 안 지켜질 수도 있다. 하지만 Edit 도구를 제거하면 100% 지켜진다. "리뷰어는 코드를 고치지 않습니다"라는 규칙도 마찬가지다. Explore 타입으로 설정하면 시스템이 강제한다.

AI 에이전트의 행동을 제어하는 가장 확실한 방법은 할 수 있는 것 자체를 제한하는 것이다.

참고 자료

공식 문서

• GitHub Superpowers 소스 코드
• Claude Code Agent Teams 문서
• Claude Code Plan Mode 문서

관련 블로그

• GitHub Superpowers: Claude Code에서 설계부터 PR까지 자동 추적하기
• Superpowers 플러그인: Claude Code를 체계적인 개발 파트너로 만드는 방법
• Claude Code Agent Teams: 여러 AI가 함께 코딩하는 시대
• Claude Opus 4.6 출시: 100만 토큰 컨텍스트와 에이전트 팀의 시대