Superpowers 완벽가이드 7편: 여러 에이전트로 확장하는 고급 흐름

요약#

참고 자료#

• obra/superpowers - GitHub README
• dispatching-parallel-agents - SKILL.md
• using-git-worktrees - SKILL.md
• finishing-a-development-branch - SKILL.md
• subagent-driven-development - SKILL.md
• Jesse Vincent - Superpowers: How I’m using coding agents in October 2025

바로 써먹는 시작 템플릿#

여러 에이전트를 무리 없이 쓰고 싶다면, 아래 문장으로 시작하면 됩니다.

• 이 작업을 독립 단위로 나눈 뒤, 병렬 가능한 것만 분리해주세요.
• 같은 파일을 건드리는 작업은 병렬로 보내지 말아주세요.
• 병렬 작업이 필요하면 worktree부터 준비해주세요.
• 모든 작업이 끝나면 브랜치 정리 옵션까지 제시해주세요.

TIP

Superpowers의 고급 흐름은 에이전트를 많이 쓰는 데 있지 않습니다.
서로 간섭하지 않는 작업만 안전하게 나누는 데 있습니다.

문제 상황#

작업이 커지면 누구나 이런 유혹을 느낍니다.
”에이전트가 똑똑하니 여러 명을 동시에 돌리면 더 빨라지지 않을까?”

겉으로 보면 맞는 말입니다.
하지만 실제로는 병렬화 자체보다 병렬화 조건이 더 중요합니다.

• 같은 파일을 여러 에이전트가 동시에 건드립니다
• 서로 영향을 주는 작업을 독립 작업처럼 나눕니다
• 한 작업의 결과가 다른 작업의 전제인데도 동시에 시작합니다
• 작업 공간이 분리되지 않아 브랜치와 변경 내역이 엉킵니다
• 구현은 끝났는데 마지막 정리 흐름이 없어 상태가 지저분하게 남습니다

그래서 Superpowers는 여러 에이전트를 많이 쓰는 법보다, 언제 나눠도 되는지를 먼저 따집니다.
고급 흐름의 핵심은 속도보다 통제입니다.

언제 여러 에이전트를 써야 할까요?#

dispatching-parallel-agents는 기준이 꽤 분명합니다.
문제가 여러 개여도, 서로 독립적이지 않으면 한 에이전트가 함께 보는 편이 낫다고 말합니다.

핵심 기준은 이것입니다.

• 서로 다른 문제 영역인가
• 공유 상태가 거의 없는가
• 한 작업 결과가 다른 작업의 선행 조건이 아닌가
• 에이전트들이 같은 파일을 중심으로 충돌하지 않는가

즉, 병렬화는 “일이 많다”가 아니라 “독립적이다”일 때만 성립합니다.

병렬화 판단 기준

이 표를 보면 기준이 단순해집니다.
많이 나누는 것이 좋은 것이 아니라, 깨끗하게 나눌 수 있을 때만 좋은 것입니다.

여러 에이전트는 어떤 흐름으로 움직일까요?#

고급 흐름은 보통 아래 순서로 이해하면 됩니다.

고급 흐름

이 흐름에서 중요한 점은 두 가지입니다.

• 병렬화보다 먼저 분리 기준이 나옵니다
• 구현이 끝난 뒤에도 정리 단계가 남아 있습니다

즉, 여러 에이전트를 쓴다는 것은 구현 단계만 늘어나는 것이 아니라, 시작과 끝의 통제가 더 중요해진다는 뜻입니다.

왜 subagent-driven-development가 기반이 될까요?#

6편에서 본 subagent-driven-development는 작업 단위마다 맥락을 분리하고, 구현 뒤에 두 단계 리뷰를 붙이는 흐름이었습니다.
7편에서는 이 구조가 왜 고급 확장의 기반이 되는지가 중요합니다.

여러 에이전트를 쓸 때 가장 먼저 망가지는 것은 집중력보다 문맥입니다.
한 세션에 많은 작업을 몰아넣으면, 이전 결정과 예외 처리와 임시 가정이 섞이기 쉽습니다.

그래서 Superpowers는 작업별로 새 subagent⁶를 두는 쪽을 선호합니다.

• 각 작업은 필요한 정보만 받습니다
• 구현자와 검토자의 역할을 분리할 수 있습니다
• 한 작업의 잡음이 다른 작업으로 덜 번집니다
• 컨트롤러는 전체 흐름과 통합만 담당합니다

즉, 여러 에이전트를 쓴다는 것은 단순한 분업이 아니라, 문맥 오염을 줄이는 방식입니다.

왜 git worktree가 같이 따라올까요?#

여기서부터가 진짜 고급 흐름입니다.
using-git-worktrees는 단순히 브랜치를 하나 더 만드는 기능이 아니라, 병렬 작업의 물리적 충돌을 줄이는 장치입니다.

같은 저장소에서 병렬 작업을 할 때 흔한 문제는 이렇습니다.

• 브랜치를 바꾸다 현재 작업이 섞입니다
• 설치 상태가 섞여 기준선이 흐려집니다
• 어느 변경이 어느 흐름에서 나온 것인지 추적이 어려워집니다

git worktree는 이 문제를 꽤 직접적으로 막습니다.

• 브랜치마다 별도 작업 디렉터리를 둘 수 있습니다
• 현재 작업 공간을 유지한 채 다른 작업을 열 수 있습니다
• 병렬 흐름이 파일 시스템 수준에서도 분리됩니다
• 시작 전에 baseline 테스트를 확인해 기준선을 맞출 수 있습니다

즉, 여러 에이전트를 쓰는 고급 흐름에서 worktree는 선택 기능이 아니라 안전장치에 가깝습니다.

worktree는 왜 baseline 테스트까지 확인할까요?#

using-git-worktrees는 worktree를 만든 뒤 프로젝트 셋업을 하고, 깨끗한 테스트 기준선을 확인하라고 요구합니다.
이 단계가 중요한 이유는 병렬 작업에서는 “원래 깨져 있던 것”과 “내가 새로 깨뜨린 것”을 구분하기 더 어려워지기 때문입니다.

baseline 테스트가 필요한 이유는 다음과 같습니다.

• 새 작업이 기존 문제를 가리지 않게 합니다
• 작업 시작 시점의 상태를 분명히 남깁니다
• 병렬 에이전트가 실패 원인을 잘못 떠안지 않게 합니다
• 통합 뒤 어떤 흐름이 문제를 만들었는지 추적하기 쉬워집니다

즉, worktree의 핵심은 격리만이 아닙니다.
격리된 공간에서 출발 상태까지 명확히 만드는 데 있습니다.

언제 병렬화하면 안 될까요?#

이 부분이 오히려 더 중요합니다.
dispatching-parallel-agents도 병렬화 금지 조건을 분명히 적어둡니다.

병렬화하면 안 되는 상황

• 실패들이 서로 연결되어 있을 때
• 시스템 전체 상태를 같이 이해해야 할 때
• 어디가 문제인지 아직 모르는 탐색 단계일 때
• 여러 에이전트가 같은 파일이나 같은 자원을 만질 때

예를 들어 인증 구조를 바꾸는 작업과, 그 인증 구조에 기대는 UI 변경은 얼핏 별개로 보일 수 있습니다.
하지만 실제로는 계약이 바뀌는 순간 서로 엮입니다.

이럴 때 병렬화는 속도가 아니라 혼선을 만듭니다.
그래서 고급 흐름일수록 “언제 안 나눌 것인가”를 더 엄격하게 판단해야 합니다.

구현이 끝난 뒤에는 왜 finishing-a-development-branch가 필요할까요?#

고급 흐름은 구현이 끝났다고 바로 끝나지 않습니다.
오히려 병렬 작업이 많을수록 마지막 정리가 더 중요해집니다.

finishing-a-development-branch는 구현 완료 후 다음 네 가지 선택지를 정확히 제시하라고 요구합니다.

브랜치 정리 옵션

1
1. 로컬에서 base branch로 병합
2
2. 푸시하고 Pull Request 생성
3
3. 브랜치를 그대로 유지
4
4. 작업을 폐기

중요한 점은 이 선택지가 단순한 편의 메뉴가 아니라는 것입니다.

• 테스트가 통과했는지 먼저 확인합니다
• base branch를 확인합니다
• 선택지별로 후속 행동을 분리합니다
• 폐기할 때는 명시적 확인을 요구합니다
• worktree 정리 여부도 선택지에 따라 달라집니다

즉, 마무리는 감으로 정하는 것이 아니라, 마지막까지 절차로 정리하는 단계입니다.

왜 마지막 정리까지 구조화해야 할까요?#

작업이 클수록 끝맺음이 흐려지기 쉽습니다.
특히 여러 에이전트가 참여하면 “일단 다 됐다”는 말만으로는 실제 상태를 설명하기 어렵습니다.

마지막 정리를 구조화하면 좋은 점은 분명합니다.

• 병합 가능한 상태인지 아닌지 명확해집니다
• 브랜치를 남길지 치울지 결정이 분리됩니다
• 폐기 작업에서 실수를 줄일 수 있습니다
• worktree 정리까지 일관되게 처리할 수 있습니다

결국 고급 흐름의 완성도는 구현 속도보다, 끝냈을 때 상태가 얼마나 깨끗한가에 달려 있습니다.

사용자는 무엇을 기대하면 될까요?#

이 고급 흐름에 익숙해지면 사용자는 여러 가지 변화를 체감하게 됩니다.

• 에이전트를 많이 쓰더라도 아무 작업이나 병렬화하지 않습니다
• 독립 작업과 순차 작업을 먼저 구분합니다
• 병렬 작업 전 worktree 이야기가 나와도 정상입니다
• 구현이 끝난 뒤에도 브랜치 정리 단계가 남아 있어도 이상이 아닙니다

이 흐름은 처음에는 느슨해 보이지 않고, 오히려 더 빡빡해 보입니다.
하지만 그 빡빡함 덕분에 작업 수가 많아져도 전체 상태를 잃지 않게 됩니다.

마무리#

Superpowers의 고급 흐름은 여러 에이전트를 무작정 동시에 돌리는 방식이 아닙니다.
독립적인 작업만 나누고, git worktree로 작업 공간을 분리하고, 구현 뒤에는 브랜치 정리까지 절차로 마무리하는 방식입니다.

즉, 이 시리즈의 마지막 단계는 더 빠른 자동화가 아니라 더 안정적인 확장입니다.
질문으로 설계를 시작하고, 작은 계획으로 구현을 나누고, 테스트와 리뷰를 거친 뒤, 마지막에는 여러 에이전트까지 통제 가능한 흐름으로 확장하는 것이 Superpowers가 말하는 완전한 워크플로입니다.