GitHub Superpowers v1.2.0: Opus 쿼터 100%가 만든 토큰 효율화

작성일: 2026년 2월 10일
카테고리: Claude Code, AI 개발 도구, 프로젝트 관리
키워드: GitHub Superpowers, Claude Code, Token Optimization, Opus 4.6, Serena, Agent Skills

요약

GitHub Superpowers v1.2.0을 릴리즈했다. v1.1.0의 체계적 워크플로우가 Opus 주간 쿼터를 3주 연속 100% 소진시키는 문제를 일으켰다. v1.2.0은 작업 규모별 경로 분기, 스펙 인라인, Serena 메모리 선로드로 토큰 효율화를 달성한다.

문제: 체계적 워크플로우의 부작용

v1.1.0에서 설계 → 구현 계획 → GitHub 이슈 → TDD → 검증 → PR의 풀 사이클을 도입했다. 품질은 올라갔지만, 부작용이 생겼다.

Opus 주간 쿼터 3주 연속 100%

Claude Max 구독은 월 정액이지만 주간 사용 한도가 존재한다. v1.1.0 워크플로우를 imprun-semu-ai 개발에 적용한 결과:

• 1주차 (1/27~2/2): 쿼터 100% 도달
• 2주차 (2/3~2/9): 쿼터 100% 도달
• 3주차 (2/10~): 이미 빠르게 소진 중

10일 만에 API 환산 $1,861(일평균 $186)을 사용하며, Anthropic 평균($6/일)의 31배에 달했다.

왜 토큰이 그렇게 많이 드는가

기능 하나를 구현하는 데 6단계 풀 사이클을 돌린다:

graph LR
    A["설계"] --> B["구현 계획"]
    B --> C["GitHub Issue"]
    C --> D["TDD 구현"]
    D --> E["검증"]
    E --> F["PR"]

    style A stroke:#2563eb,stroke-width:3px
    style B stroke:#7c3aed,stroke-width:3px
    style C stroke:#16a34a,stroke-width:3px
    style D stroke:#ea580c,stroke-width:3px
    style E stroke:#dc2626,stroke-width:3px
    style F stroke:#16a34a,stroke-width:3px

각 단계에서 에이전트가 코드베이스를 탐색하고, 문서를 읽고, 계획하고, 검증한다. 문제는 세 가지였다:

1. 버튼 하나 옮기는 작업에도 풀 사이클 — 1~2 파일 변경에 brainstorming부터 시작
2. 매 Task마다 design.md를 처음부터 읽음 — 같은 설계 문서를 10번 구현하면 10번 읽음
3. 프로젝트 탐색을 매번 처음부터 — 이전 세션에서 학습한 내용이 다음 세션에 전달되지 않음

v1.2.0의 해결 방식

1. 작업 규모별 경로 분기

모든 작업에 풀 사이클을 돌리는 것이 문제의 핵심이었다. v1.2.0에서는 작업 규모를 먼저 판단하고, 규모에 맞는 경로를 선택한다.

경로	기준	스킬 체인
Quick	1~2 파일, 명확한 범위	TDD → verification → commit
Standard	3~5 파일, 기존 패턴	writing-plans → executing-plans → verification → PR
Full	6+ 파일, 설계 필요	brainstorming → writing-plans → creating-issues → executing-plans → verification → PR

버그 수정이나 작은 기능 추가는 Quick 경로로 진입한다. TDD로 테스트부터 작성하고, 구현하고, 검증하고, 커밋. brainstorming이나 GitHub Issue 생성 같은 오버헤드가 없다.

graph TB
    A["요청 수신"] --> B{"규모 판단"}
    B -->|"1-2 파일"| C["Quick Path"]
    B -->|"3-5 파일"| D["Standard Path"]
    B -->|"6+ 파일"| E["Full Path"]

    C --> F["TDD → 검증 → 커밋"]
    D --> G["계획 → 실행 → 검증 → PR"]
    E --> H["설계 → 계획 → 이슈 → 실행 → 검증 → PR"]

    style C stroke:#16a34a,stroke-width:3px
    style D stroke:#ea580c,stroke-width:3px
    style E stroke:#dc2626,stroke-width:3px

v1.1.0에서는 모든 작업이 Full Path로 진입했다. v1.2.0에서는 대부분의 일상 작업이 Quick이나 Standard로 처리된다.

2. Design-Aware Task: 스펙 인라인

v1.1.0의 writing-plans가 생성하는 impl.md는 Task 목록만 나열했다. 구현할 때 에이전트가 design.md를 별도로 찾아 읽어야 했다.

v1.2.0에서는 각 Task에 필요한 스펙을 직접 인라인한다:

## Task 2: Pipeline Metrics Collector 구현

**Design Reference**: design.md §3.2 "Metrics Collection"

**구현 스펙**:
- VictoriaMetrics에 push하는 MetricsCollector 서비스
- 수집 대상: pipeline_duration, stage_success_count, stage_failure_count
- 인터페이스: IMetricsCollector (push, flush)

**수용 기준**:
- [ ] MetricsCollector가 VictoriaMetrics에 메트릭을 push한다
- [ ] 실패 시 로그만 남기고 파이프라인을 중단하지 않는다
- [ ] 단위 테스트가 push/flush를 검증한다

에이전트는 이 Task만 보고 구현할 수 있다. design.md를 매번 처음부터 읽을 필요가 없다.

3. Serena 메모리 선로드

Claude Code는 세션이 끝나면 컨텍스트가 사라진다. 다음 세션에서 "이 프로젝트는 NestJS 모노레포이고, Prisma를 ORM으로 쓰고, BullMQ로 파이프라인을 돌린다"는 사실을 처음부터 다시 탐색해야 한다.

Serena MCP의 메모리 시스템을 워크플로우에 통합하여 이 문제를 해결했다.

로드 시점:

• brainstorming Step 0: project_overview, architecture_and_conventions 로드
• writing-plans Step 1.5: codebase_structure, style_and_patterns 로드

저장 시점:

• closing-issues: 이슈 종료 후 새 모듈, 아키텍처 변경, 설계 결정을 edit_memory/write_memory로 저장

축적된 프로젝트 지식을 세션 시작 시 즉시 로드하면, 에이전트가 탐색해야 할 범위가 줄어든다. "이 프로젝트 구조가 뭐지?"부터 시작하는 대신 "apps/worker/src/pipeline에 새 스테이지를 추가하면 된다"에서 시작할 수 있다.

4. Plan Stress Test

구현 계획이 불완전하면 구현 단계에서 재작업이 발생한다. 재작업은 토큰 낭비의 주요 원인 중 하나다.

v1.2.0의 writing-plans에 Step 3.5 셀프체크 게이트를 추가했다:

체크 항목	검증 내용
구현 충분성	모든 Task가 합쳐지면 요구사항을 충족하는가
스펙 완전성	각 Task의 구현 스펙이 모호함 없이 작성되었는가
AC 분배	수용 기준이 Task 전체에 빠짐없이 분배되었는가
테스트 가능성	각 수용 기준을 테스트 코드로 검증할 수 있는가

4개 항목을 모두 통과해야 ExitPlanMode가 가능하다. 불완전한 계획이 구현 단계로 넘어가는 것을 차단한다.

5. MVP Check-in Gate

대규모 기능을 구현할 때, 전체 Task의 ~50% 시점에서 진행 상태를 점검한다. AskUserQuestion으로 사용자에게 현재까지의 구현이 설계 의도와 맞는지 확인한다.

이 게이트가 없으면 10개 Task를 모두 구현한 뒤 "방향이 틀렸다"는 피드백을 받게 된다. 중간 점검으로 후반부 재작업을 방지한다.

6. Opus 4.6 톤 최적화

v1.1.0은 Opus 4.5를 위해 설계되었다. Opus 4.5는 지시를 정확히 따르되 자율 판단이 약한 편이었다. 그래서 <EXTREMELY-IMPORTANT> 태그로 강제 호출을 유도했다.

Opus 4.6은 지시 이해도와 자율 판단 능력이 향상되었다. 강제 호출이 오히려 불필요한 스킬 로드를 유발할 수 있다.

구분	v1.1.0 (Opus 4.5)	v1.2.0 (Opus 4.6)
스킬 호출	EXTREMELY-IMPORTANT 강제	자율 판단 기반
규칙 표현	Iron Law / Red Flags 테이블	"왜 이렇게 하는가" 설명
코드 스니펫	줄 수 제한	충실도 기준 (DTO는 전체, 로직은 시그니처만)

변경 요약

스킬	추가/변경 내용
using-github-superpowers	Quick/Standard/Full 경로 분기
brainstorming	Serena 메모리 선로드 (Step 0)
writing-plans	Design-Aware Task, Plan Stress Test, Serena 메모리 선로드, 코드 스니펫 충실도 기준
executing-plans	Design Document 사전 로드, MVP Check-in Gate
closing-issues	Serena 메모리 업데이트
test-driven-development	Why-first 규칙
verification	Why-first 규칙

업그레이드

/plugin update github-superpowers

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

설계 원칙의 확장

v1.1.0의 5가지 원칙에 하나가 추가되었다:

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

v1.2.0을 만든 동기는 순수하게 실용적이다. Opus 주간 쿼터를 3주 연속 100% 소진하면서, 체계적 워크플로우의 비용을 체감했다. 품질과 효율은 트레이드오프다. 모든 작업에 최고 수준의 프로세스를 적용하는 것보다, 작업의 규모와 복잡도에 맞는 적절한 프로세스를 선택하는 것이 더 현명하다.

v1.2.0의 효과는 향후 사용 리포트에서 검증할 예정이다.

참고 자료

관련 블로그

• GitHub Superpowers v1.1.0: Agent Team 오케스트레이션과 Plan Mode
• GitHub Superpowers: Claude Code에서 설계부터 PR까지 자동 추적하기
• Superpowers 플러그인: Claude Code를 체계적인 개발 파트너로 만드는 방법
• Claude Code 사용 리포트: 1월 29억, 2월 10일만에 30억 토큰

도구

• Serena MCP - 시맨틱 코드 분석 및 메모리 시스템
• ccusage - Claude Code 사용량 분석 도구