Superpowers 완벽가이드 6편: 테스트와 리뷰를 중심에 두는 구현 흐름

요약#

참고 자료#

• obra/superpowers - GitHub README
• test-driven-development - SKILL.md
• requesting-code-review - SKILL.md
• subagent-driven-development - SKILL.md
• Jesse Vincent - Superpowers: How I’m using coding agents in October 2025

바로 써먹는 시작 템플릿#

구현 단계에서도 흐름이 흔들리지 않게 만들고 싶다면, 아래 문장으로 시작하면 됩니다.

• 계획에 따라 한 단계씩 구현해주세요.
• 테스트를 먼저 쓰고, 실패를 확인한 뒤 구현해주세요.
• 각 작업이 끝날 때마다 리뷰를 거친 뒤 다음 단계로 넘어가주세요.
• 한 번에 크게 구현하지 말고, 최소 구현과 검증을 반복해주세요.

TIP

Superpowers의 구현 흐름은 빨리 많이 만드는 데 있지 않습니다.
작게 만들고 바로 확인하면서, 잘못된 방향을 빨리 끊는 데 있습니다.

문제 상황#

설계도 끝났고 계획도 정리됐는데, 구현 단계에서 다시 흔들리는 경우는 생각보다 많습니다.
이유는 단순합니다. 코드를 쓰기 시작하는 순간 사람과 에이전트 모두 다시 속도에 끌리기 쉽기 때문입니다.

이때 흔히 나타나는 문제는 비슷합니다.

• 테스트보다 구현이 먼저 나옵니다
• 한 단계씩이 아니라 한 번에 크게 만듭니다
• 리뷰는 마지막에 몰아서 하게 됩니다
• 중간 검증 없이 “거의 됐다”는 판단이 늘어납니다
• 잘못 만든 구조가 뒤늦게 발견됩니다

그래서 Superpowers는 구현 단계도 자유 구간으로 두지 않습니다.
계획 다음에는 구현이 아니라, 검증을 끼운 구현 흐름이 시작됩니다.

구현은 어떻게 시작될까요?#

공식 README는 설계와 계획 뒤에 구현 단계가 오고, 여기서 subagent-driven-development나 executing-plans, TDD, requesting-code-review가 이어진다고 설명합니다.
이 흐름을 단순화하면 이렇게 볼 수 있습니다.

구현 흐름

중요한 점은 구현이 단독으로 움직이지 않는다는 것입니다.
항상 테스트와 리뷰가 붙어서 움직입니다.

왜 테스트를 구현보다 먼저 둘까요?#

test-driven-development 문서는 아주 강한 표현을 씁니다.
실패하는 테스트를 먼저 확인하지 않았다면, 그 테스트가 올바른 것을 검증하는지 알 수 없다고 말합니다.

핵심은 이겁니다.

• 먼저 테스트를 씁니다
• 테스트가 실제로 실패하는지 봅니다
• 그 실패를 통과시키는 최소 구현만 추가합니다
• 다시 테스트가 통과하는지 봅니다

즉, 구현은 테스트를 증명하는 것이 아니라, 테스트가 요구한 조건을 맞추는 과정이 됩니다.

이 방식이 중요한 이유는 분명합니다.

왜 큰 구현 대신 작은 구현을 반복할까요?#

Superpowers의 구현 흐름은 한 번에 많이 만드는 방식과 거리가 멉니다.
계획 단계에서 이미 작업을 잘게 나눴다면, 구현 단계도 그 리듬을 따라가야 합니다.

작은 구현이 좋은 이유는 이렇습니다.

• 실패 원인을 찾기 쉽습니다
• 리뷰 범위가 줄어듭니다
• 테스트 결과를 바로 연결해 볼 수 있습니다
• 다음 단계로 넘어가도 되는지 판단이 쉬워집니다

설계 단계가 범위를 줄였다면, 구현 단계는 변화량을 줄입니다.
이 두 가지가 함께 있어야 코드가 덜 흔들립니다.

왜 subagent-driven-development가 중요할까요?#

README와 skill 문서를 보면, Superpowers는 구현 작업을 한 명의 거대한 세션에 몰아넣기보다, 작업 단위별로 분리된 subagent⁵에게 맡기는 흐름을 강조합니다.

여기서 핵심은 context를 분리하는 것입니다.

• 각 작업은 필요한 정보만 받습니다
• 이전 작업의 잡음이 다음 작업으로 덜 새어 나갑니다
• 구현자와 검토자의 역할을 분리할 수 있습니다
• 컨트롤러는 전체 흐름만 조정합니다

즉, subagent-driven-development는 단순한 병렬 처리 도구가 아닙니다.
작업별 맥락을 격리해서 품질을 안정시키는 구현 방식에 가깝습니다.

왜 리뷰를 마지막이 아니라 중간마다 할까요?#

일반적으로 리뷰는 구현이 모두 끝난 뒤 한 번에 하는 것으로 생각하기 쉽습니다.
하지만 requesting-code-review는 그보다 훨씬 앞에서 움직입니다.

문서가 강조하는 핵심은 이렇습니다.

• 각 작업 뒤 리뷰
• 큰 기능 뒤 리뷰
• 병합 전 리뷰

이 구조가 중요한 이유는 문제를 작을 때 잡기 위해서입니다.
후반에 한꺼번에 리뷰하면, 잘못된 패턴이 이미 여러 파일로 번져 있을 가능성이 큽니다.

반대로 중간마다 리뷰하면 이런 이점이 있습니다.

• 문제를 작은 범위에서 잡을 수 있습니다
• 다음 작업이 잘못된 전제 위에 쌓이지 않습니다
• 구현자도 피드백을 빠르게 반영할 수 있습니다
• “이제 와서 다 바꿔야 하나”가 줄어듭니다

즉, 리뷰는 끝난 뒤의 감상이 아니라, 구현을 안전하게 이어가기 위한 제동 장치입니다.

구현 흐름은 실제로 어떻게 보일까요?#

Superpowers의 구현 리듬은 보통 이렇게 요약할 수 있습니다.

구현 흐름 예시

1
1. 계획에서 한 작업을 꺼냅니다
2
2. 실패하는 테스트를 먼저 씁니다
3
3. 테스트가 정말 실패하는지 확인합니다
4
4. 최소 구현으로 통과시킵니다
5
5. 다시 테스트를 돌립니다
6
6. 리뷰를 요청합니다
7
7. 문제가 없으면 다음 작업으로 넘어갑니다

이 흐름에서 중요한 것은 “한 번 더 확인”이 계속 들어간다는 점입니다.
실패 확인, 통과 확인, 리뷰 확인이 반복되기 때문에, 구현 속도는 조금 느려 보여도 방향은 더 안정적으로 유지됩니다.

왜 느려 보이는데 더 빠를 수 있을까요?#

이 질문은 결국 비용의 위치에 대한 이야기입니다.
Superpowers는 비용을 뒤로 미루지 않고 앞쪽으로 당깁니다.

• 테스트를 먼저 써서 실패를 빨리 봅니다
• 작은 구현만 해서 범위를 빨리 확인합니다
• 중간 리뷰로 오류를 빨리 잡습니다
• 다음 단계로 넘기기 전에 계속 검증합니다

겉으로는 비효율처럼 보일 수 있습니다.
하지만 생산 코드가 커진 뒤 문제를 찾는 것보다, 작은 단계에서 틀린 방향을 끊는 편이 훨씬 싸게 끝나는 경우가 많습니다.

그래서 이 흐름은 느린 구현이 아니라, 비싼 실패를 줄이는 구현이라고 보는 편이 맞습니다.

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

구현 단계에서 사용자가 기대하면 좋은 변화는 다음과 같습니다.

• 바로 많은 코드가 나오지 않아도 정상입니다
• 테스트 이야기가 먼저 나와도 이상이 아닙니다
• 리뷰가 자주 끼어들어도 흐름이 깨진 것이 아닙니다
• 각 단계가 작게 끝나는 것이 오히려 좋은 신호입니다

이 흐름에 익숙해지면, “왜 이렇게 천천히 가지?”보다는 “왜 이 단계가 아직 리뷰를 안 거쳤지?”를 보게 됩니다.
그 지점에서 Superpowers의 구현 철학이 보이기 시작합니다.

마무리#

Superpowers는 구현 단계조차 감각에 맡기지 않습니다.
계획을 한 작업씩 꺼내고, 테스트를 먼저 만들고, 최소 구현을 넣고, 리뷰를 거친 뒤 다음 단계로 넘어가게 만듭니다.

즉, 구현은 더 이상 “코드를 쓰는 시간”만이 아닙니다.
테스트와 리뷰를 붙여서, 작은 단위로 계속 증명해 나가는 시간에 가깝습니다.

다음 글에서는 이 흐름을 더 넓게 확장해서, 여러 에이전트를 함께 쓰는 고급 작업 방식과 병렬 흐름이 어디서 빛을 발하는지 설명하겠습니다.