17. Superpowers — 10만 스타, AI 코딩에 TDD를 강제하는 프레임워크

GitHub 스타 14만 개를 돌파한 obra/superpowers는 AI 코딩 에이전트가 “알아서 잘하겠지”라는 기대를 부수고, 테스트 주도 개발(TDD)의 Red-Green-Refactor 사이클을 기계적으로 강제한다. 코드를 먼저 쓰면 삭제하고 다시 시작하라고 한다. 느리지만 확실한 이 방식이 왜 수십만 개발자의 선택을 받았는지 파헤쳐본다.

한 줄 결론

Superpowers는 AI 코딩 에이전트에게 프로세스를 제약한다 — 똑똑한 주니어 엔지니어에게 “마음대로 해”가 아니라 “이 매뉴얼대로만 해”라고 지시하는 방식으로, 놀라울 정도로 일관된 품질의 코드를 뽑아낸다.

AI 코딩에서 TDD가 왜 중요한가

AI 에이전트는 빠르다. 질문하자마자 수십 줄의 코드를 쏟아낸다. 문제는 그 코드가 “작동하는 것처럼 보이지만 실제로는 검증되지 않았다”는 점이다. 개발자가 직접 코딩할 때는 본능적으로 엣지 케이스를 떠올리지만, AI는 프롬프트에 명시되지 않은 조건을 자연스럽게 무시한다.

더 심각한 문제는 컨텍스트 누적이다. 긴 세션에서 에이전트가 앞서 작성한 코드를 “맥락”으로 삼아 새 코드를 쓰기 시작하면, 초기의 작은 오해가 눈덩이처럼 불어난다. 테스트 없이 이 걸 잡아내는 건 거의 불가능하다.

TDD는 이 문제에 대한 구조적 답이다. “테스트를 먼저 쓰고, 실패를 확인하고, 최소한의 코드로 통과시킨다”는 사이클이 AI의 자유도를 의도적으로 제한한다. 테스트가 통과하면 그 코드는 검증된 것이고, 실패하면 수정하면 된다. AI의 “창의적 해석”이 끼어들 여지가 없다.

Superpowers가 하는 일

Superpowers는 Jesse Vincent가 만든 에이전트 스킬 프레임워크다. Claude Code, Cursor, GitHub Copilot, Gemini CLI 등 주요 코딩 에이전트에 설치할 수 있다. 핵심 아이디어는 단순하다.

코딩 에이전트에게 “스킬”이라는 형태로 프로세스를 주입하고, 그 프로세스를 강제한다.

단순한 프롬프트 추가가 아니다. 각 스킬은 SKILL.md 파일로 정의되며, 에이전트가 특정 활동(기획, 계획, 구현, 디버깅, 리뷰 등)을 시작할 때마다 해당 스킬을 반드시 읽고 따르도록 되어 있다. “권장”이 아니라 “의무”다.

공식 GitHub 리포(github.com/obra/superpowers)에 따르면, 2025년 10월 9일 첫 커밋 이후 약 6개월 만에 14만 스타, 포크 1.2만 개를 기록했다. MIT 라이선스로 공개되어 있다.

핵심 철학 세 가지

테스트 주도 개발 — 코드를 먼저 쓰면 안 된다. 테스트를 먼저 쓴다. 실패를 확인한다. 그 다음에 최소한의 코드를 쓴다.
체계적 접근 — 추측이 아니라 근거 위에서 디버깅하고, 검증하고, 진행한다.
복잡성 감소 — 단순함이 1차 목표다. YAGNI(지금 필요 없는 건 만들지 마), DRY(반복하지 마)를 강제한다.

flowchart TD
    A["아이디어 입력"] --> B["brainstorming<br/>요구사항 정제 + 설계"]
    B --> C["using-git-worktrees<br/>독립 워크스페이스 생성"]
    C --> D["writing-plans<br/>태스크 분해 + 계획서"]
    D --> E["subagent-driven-development<br/>서브에이전트에 태스크 위임"]
    E --> F{"test-driven-development<br/>RED: 테스트 작성"}
    F --> G["테스트 실행 → 실패 확인"]
    G --> H["GREEN: 최소 코드 작성"]
    H --> I["테스트 실행 → 통과 확인"]
    I --> J["REFACTOR: 정리"]
    J --> K{"모든 태스크 완료?"}
    K -->|아니오| F
    K -->|예| L["requesting-code-review<br/>코드 리뷰"]
    L --> M["finishing-a-development-branch<br/>병합/PR/정리"]

7단계 워크플로우 상세

Superpowers는 코딩 에이전트가 프로젝트를 시작하면 자동으로 7단계 프로세스에 돌입한다. 사용자가 특별한 명령을 입력할 필요가 없다 — 에이전트가 “프로젝트를 시작하려는구나”라고 판단하면 즉시 brainstorming 스킬이 활성화된다.

1단계: brainstorming — 설계 대화

코드를 한 줄도 쓰기 전에, 에이전트가 질문을 던진다. 목적이 뭔지, 어떤 제약이 있는지, 성공 기준이 무엇인지 하나씩 묻는다. 일방적인 질문이 아니라, 2~3가지 접근법을 제안하고 장단점을 비교해준다.

이 과정에서 에이전트는 프로젝트 컨텍스트(파일 구조, 기존 코드, 최근 커밋)를 먼저 파악하고, 프로젝트가 너무 크면 하위 프로젝트로 분해할 것을 제안한다. 대화가 끝나면 설계 문서를 docs/superpowers/specs/에 저장하고, 사용자 승인을 기다린다.

핵심 제약: 설계 승인 전에는 절대 코드를 작성하지 않는다. 아무리 간단한 작업이라도 마찬가지다. “너무 단순해서 설계가 필요 없다”는 생각 자체가 Superpowers가 경계하는 안티패턴이다.

2단계: using-git-worktrees — 독립 워크스페이스

설계가 승인되면 git worktree를 생성한다. 메인 브랜치에 영향을 주지 않는 독립 작업 공간이다. 같은 프로젝트에서 여러 작업을 병렬로 진행할 때 충돌을 방지한다.

새 브랜치를 만들고, 프로젝트 셋업을 실행하고, 테스트가 깨끗한 베이스라인에서 시작하는지 확인한다.

3단계: writing-plans — 실행 계획서

승인된 설계를 바탕으로 구현 계획서를 작성한다. 이 계획서는 “열정은 넘치지만 맥락이 없는 주니어 엔지니어”가 읽어도 따라할 수 있을 만큼 상세해야 한다.

각 태스크는 2~5분이면 끝나는 단위로 쪼갠다. “테스트 작성”이 한 단계, “테스트 실행”이 한 단계, “최소 코드 작성”이 한 단계, “통과 확인”이 한 단계. 파일 경로, 코드 스니펫, 검증 방법까지 포함한다. 계획서는 docs/superpowers/plans/에 저장된다.

4단계: subagent-driven-development — 서브에이전트 실행

이 단계가 Superpowers의 가장 독특한 부분이다. 계획서의 각 태스크를 새로운 서브에이전트에게 위임한다. 메인 에이전트는 코디네이터 역할만 하고, 실제 구현은 맥락이 오염되지 않은 깨끗한 에이전트가 수행한다.

각 태스크마다 세 가지 역할이 순환한다:

구현자 — 태스크를 TDD로 구현
스펙 리뷰어 — 구현이 계획서와 일치하는지 확인
코드 품질 리뷰어 — 코드 품질을 평가

스펙 리뷰에서 불일치가 발견되면 구현자가 수정하고 다시 리뷰받는다. 품질 리뷰에서 문제가 있어도 마찬가지다. 모든 리뷰를 통과해야 다음 태스크로 넘어간다.

이 방식의 장점은 서브에이전트가 신선한 컨텍스트로 시작한다는 점이다. 앞선 태스크의 오해나 오류를 물려받지 않는다. 토큰 소모는 늘어나지만, 재작업이 줄어들어 장기적으로는 오히려 효율적이라고 프로젝트 측은 주장한다.

5단계: test-driven-development — TDD 강제 사이클

모든 구현 태스크는 Red-Green-Refactor 사이클을 따른다. Superpowers의 TDD 스킬은 매우 엄격하다:

RED: 실패하는 테스트를 하나 쓴다. 실행해서 실패를 확인한다. 실패 이유가 “기능이 없어서”인지 확인한다(오타로 실패하는 건 의미 없다).
GREEN: 테스트를 통과시키는 최소한의 코드만 쓴다. 추가 기능, 리팩토링, “개선”은 금지.
REFACTOR: 테스트가 통과한 상태에서만 정리한다. 중복 제거, 이름 개선, 헬퍼 추출. 새 동작 추가는 금지.

가장 논란이 되는 규칙은 **“코드를 먼저 쓰면 삭제하고 다시 시작하라”**이다. Superpowers는 명시적으로 “테스트 없이 쓴 코드를 ‘참고용’으로 남겨두지 마라, ‘수정해서’ 쓰지 마라, ‘보지도 마라‘“고 지시한다. 삭제는 삭제다.

예외는 있다 — 일회성 프로토타입, 생성 코드, 설정 파일. 하지만 이 예외조차 “사용자에게 물어봐야” 허용된다.

6단계: requesting-code-review — 코드 리뷰

태스크가 완료될 때마다, 그리고 전체 구현이 끝나면 코드 리뷰가 진행된다. 계획서 대비 구현을 점검하고, 이슈를 심각도별로 분류한다. Critical 이슈는 진행을 차단한다.

7단계: finishing-a-development-branch — 마무리

모든 태스크가 완료되면 테스트를 최종 검증하고, 사용자에게 옵션을 제시한다: 로컬 병합, GitHub PR 생성, 작업 보류, 또는 폐기. worktree를 정리하고 브랜치를 마무리한다.

설치 및 사용법

Superpowers는 Claude Code 공식 플러그인 마켓플레이스에 등록되어 있으며, Cursor, GitHub Copilot, Gemini CLI, OpenCode, Codex까지 폭넓게 지원한다.

Claude Code

# 마켓플레이스 등록
/plugin marketplace add obra/superpowers-marketplace
 
# 플러그인 설치
/plugin install superpowers@superpowers-marketplace

설치 후 Claude Code를 재시작하면, 세션 시작 시 자동으로 Superpowers 프롬프트가 주입된다. 별도 명령 없이 프로젝트를 시작하면 자동으로 brainstorming 스킬이 활성화된다.

Cursor

에이전트 채팅에서 /add-plugin superpowers를 입력하거나, 플러그인 마켓플레이스에서 “superpowers”를 검색해 설치한다.

OpenCode / Codex

이 두 도구는 마켓플레이스가 없어 수동 설정이 필요하다. 각각의 INSTALL.md 지시를 따른다:

Codex: https://raw.githubusercontent.com/obra/superpowers/main/.codex/INSTALL.md
OpenCode: https://raw.githubusercontent.com/obra/superpowers/main/.opencode/INSTALL.md

Gemini CLI

gemini extensions install https://github.com/obra/superpowers

장단점

장점

품질 일관성: TDD 강제로 AI가 뽑는 코드의 품질 편차가 크게 줄어든다. “잘되는 날은 잘되는데 아닌 날은 처참하다”는 AI 코딩의 고질적 문제를 구조적으로 해결한다.
컨텍스트 오염 방지: 서브에이전트 방식 덕분에 앞선 태스크의 오류가 뒤로 전파되지 않는다. 깨끗한 상태에서 각 태스크에 임한다.
검증 가능성: 모든 코드가 테스트를 통해 검증되므로, “이게 진짜 작동하는 건가?”라는 불안이 줄어든다.
재현성: 같은 계획서를 주면 비슷한 품질의 코드가 나온다. 프로세스가 표준화되어 있다.

단점

느리다: 설계 대화, 계획서 작성, 서브에이전트 배포, 이중 리뷰까지 거치면 시간이 꽤 걸린다. “빠른 프로토타입 하나 만들자”에는 명백히 오버스펙이다.
토큰 소모: 서브에이전트를 매 태스크마다 새로 띄우므로 토큰 사용량이 늘어난다. API 과금 기준으로는 비용이 꽤 된다.
유연성 제한: 엄격한 프로세스가 양날검이다. “이번엔 그냥 대충 만들고 싶은데”라는 순간에는 오히려 방해가 된다.
학습 곡선: 14개의 스킬과 각각의 규칙을 이해하는 데 시간이 필요하다. 처음에는 “왜 이렇게까지 엄격해야 하지?”라는 의문이 들 수 있다.

실전 시나리오

시나리오 1: 신규 API 엔드포인트 추가

Express.js 프로젝트에 “사용자 프로필 수정” 엔드포인트를 추가해야 한다고 가정하자.

Superpowers 없이 Claude Code에게 맡기면 대략 이렇게 진행된다: “프로필 수정 API 만들어줘” → Claude가 라우터, 컨트롤러, 서비스 레이어를 한 번에 작성 → 테스트는 나중에 추가 → 돌려보니 엣지 케이스 누락 → 수정 요청 → 또 누락… 이 패턴이 익숙할 것이다.

Superpowers를 쓰면 흐름이 다르다:

brainstorming — “프로필 수정”이 구체적으로 뭘 의미하는지 질문이 온다. 닉네임만? 프로필 이미지도? 이메일 변경은 인증 필요한지? 2~3가지 설계안을 제시한다.
writing-plans — 승인된 설계를 8~~12개의 태스크로 분해한다. 각 태스크는 2~~5분 단위.
subagent-driven-development — 태스크별로 새 에이전트가 TDD로 구현한다. “빈 이메일 거부 테스트” → 실패 확인 → “이메일 검증 로직” → 통과 → 리팩토링.
review — 스펙 리뷰어가 계획서대로 구현됐는지 확인하고, 품질 리뷰어가 코드 품질을 평가한다.

결과적으로 2~3시간이 걸리지만, 엣지 케이스가 빠짐없이 테스트로 덮여 있다. 나중에 수정이 필요해도 테스트가 있으니 안심하고 고친다.

시나리오 2: 버그 수정

“가끔 빈 이메일이 저장된다”는 버그가 들어왔다.

Superpowers의 TDD 스킬이 작동한다:

실패하는 테스트를 먼저 쓴다: test('rejects empty email')
실행해서 실패를 확인한다
최소한의 코드로 통과시킨다
리팩토링

“벌써 수정 코드를 알겠는데?”라고 생각해도, Superpowers는 테스트 먼저를 고집한다. 버그 수정 코드를 먼저 쓰면 삭제하고 다시 하라고 한다.

칠판 치트시트

Superpowers = AI 코딩 에이전트에 TDD + 서브에이전트 구조를 강제하는 스킬 프레임워크

핵심 흐름: brainstorm → worktree → plan → 서브에이전트 TDD → 리뷰 → 병합
명심: 코드 먼저 쓰면 삭제. 테스트 먼저. 실패 확인. 최소 통과. 정리.
적합: 프로덕션 코드, 장기 유지보수 프로젝트, 품질이 비용보다 중요한 작업
부적합: 빠른 프로토타입, 탐색적 코딩, 30분 안에 결과 봐야 하는 작업

다음 읽기

🤖 이 글은 AI가 공식 GitHub 리포지토리, 개발자 블로그, 소스 코드를 기반으로 작성했습니다. 최신 정보는 github.com/obra/superpowers에서 확인하세요.

일하는 ai

탐색기