AI 스킬 프레임워크 Superpowers 6

요약: Superpowers 6는 훨씬, 정말 훨씬 빨라졌고, 같은 수준의 고품질 결과를 얻는 데 쓰는 토큰도 크게 줄었습니다. 토큰을 최대한 많이 쓰는 것이 목표라면 이번 릴리스는 건너뛰어도 되겠지만, 빌드가 최대 50% 빨라지고 비용이 최대 60% 저렴해지는 것이 중요하다면 Superpowers 6가 마음에 들 것입니다.

일주일 전만 해도 우리는 Superpowers 5.2 릴리스를 준비하고 있었습니다. 이미 “개선 하나만 더” 넣겠다며 릴리스를 몇 번 미룬 상태였습니다.

Pi, Antigravity, Kimi Code 지원을 추가했습니다.

Codex, OpenCode, Cursor에서 Superpowers가 더 잘 동작하도록 만들었습니다.

여러 Superpowers skill을 모델과 harness에 덜 의존하도록 다시 작성했습니다. 덕분에 어디서든 더 안정적으로 동작합니다. 또 Superpowers에 새 coding agent harness 지원을 추가하는 방법을 설명하는 새 contribution guide도 작성했습니다.

Visual Brainstorming을 더 쓰기 쉽고, 더 안전하고, 더 안정적으로 만들기 위해 여러 작업을 했습니다.

그리고 수많은 버그를 고쳤습니다. 그중에는 code review subagent가 가끔 단일 task가 아니라 전체 branch를 review하게 만들던 특히 까다로운 버그도 있었습니다.

멋진 릴리스가 될 예정이었습니다.

그런데 Anthropic이 Fable을 출시했다가 다시 내렸습니다. Fable에 접근할 수 있었던 며칠 동안, 저는 그것을 최대한 잘 활용해 보기로 했습니다.

Superpowers 사용자에게서 가장 자주 듣는 불만은 잘 알려져 있습니다. 토큰이 비싸고, Superpowers가 토큰을 아주 많이 쓴다는 것입니다. Superpowers로 소프트웨어를 만드는 일은 Superpowers 없이 만드는 것보다 느리기도 합니다. 사실 “느리다”는 부분은 문제가 되지 않아야 합니다. 빌드 과정에서 autonomous subagent가 주도하는 development orchestration 중에 일어나는 일이기 때문입니다.

하지만 실제로는 중요합니다. 느린 것은 즐겁지 않습니다. 비싼 것도 마찬가지입니다.

Superpowers 빌드가 더 오래 걸리고 비용이 더 많이 들었던 이유 중 상당수는, 동시에 많은 사용자에게 좋은 결과를 만들어 주는 이유이기도 합니다. Superpowers는 구현을 손대지 않고 진행할 수 있도록 앞단에서 많은 planning 작업을 하고, 구현 중에는 엄격한 red-green TDD를 강제하며, 그런 다음 Superpowers 내부 orchestrator가 모든 변경을 두 가지 기준으로 review합니다.

1. agent가 요청받은 것을 정확히 구현했는가. 더도 덜도 아닌가.

2. 작업 품질이 충분한 수준인가.

Superpowers가 하는 일의 성격상, 테스트하지 않은 구현을 대충 밀어 넣고 끝내는 방식보다 느릴 수밖에 없습니다.

하지만 느리고 비싸다는 사실이 저를 기쁘게 만든 적은 한 번도 없습니다.

Fable이 나왔을 때, 저는 Subagent Driven Development를 얼마나 잘 최적화할 수 있는지 확인해 보기로 했습니다.

아마 토큰 사용량을 15% 정도 줄일 수 있기를 바랐던 것 같습니다.

그 정도는 얻었습니다. 그리고 훨씬 더 많은 것도 얻었습니다.

첫 번째 공략 지점은 coordinator에서 reviewer로 넘어가는 handoff였습니다. Fable은 수천 건의 Subagent Driven Development session을 분석했고, code review subagent와 spec-compliance review subagent가 review 중에 git 명령을 매우 많이 실행할 때가 있다는 사실을 발견했습니다. review할 commit을 찾는 방법을 글로 설명하던 지시를, 잘 정리된 diff와 다른 metadata를 담은 review package를 미리 생성하는 shell script로 바꾸기만 해도 토큰 사용량과 wall-clock time이 약 10% 줄었습니다.

그날 밤 잠자리에 들면서, 저는 Fable에게 제가 자는 동안 eval의 wall clock time과 token cost를 15% 더 줄일 방법을 찾아보라고 했습니다.

잠자리에 들기 전, 내부 Slack에는 code reviewer와 spec compliance reviewer를 합치면 어떤 일이 일어나는지 평가해 봐야 한다는 메모를 올렸습니다.

밤사이에 무슨 일이 일어나길 기대했는지는 잘 모르겠습니다. 하지만 아침에 일어나 보니 Fable이 독자적으로 같은 결론에 도달했고, 그것을 테스트했으며, eval suite 전체에서 제가 요청했던 추가 15% 절감을 달성했다는 사실을 확인하게 될 줄은 몰랐습니다.

다음 날 밤에는 조금 더 욕심을 냈습니다.

/goal once this is done, run an autoresearch loop to improve cost-efficiency of the superpowers build loop. test with opus as the coordinator. make an hypothesis log. run experiments. run at least 25 experiments.

Fable은 전체 autoresearch harness를 만들고 밤새 실행했습니다. Fable이 만든 것은 GitHub에서 확인할 수 있습니다.

**The ==autoresearch== loop is complete: 25 experiments closed** (plus 4 logged as backlog), opus as coordinator throughout, every hypothesis pre-registered with a prediction in the log, now durable at evals `docs/experiments/2026-06-11-build-loop-==autoresearch==.md` (a76ddc9). Loop spend ≈ $165.

What the loop found

**The ship candidate (E27):** opus controller + elicited plan + conditional haiku implementers + terse reviewer contract + narration recipe + final-review tier pin → **fractals $6.24/$6.60** (the combo config on hand plans was $11.67--14.84). Planted-defect gates 2/3, with the one fail forensically attributed to reviewer variance plus judge strictness --- the terse contract was explicitly exonerated by reading the reviewer's reports. The N=5 gate battery is still owed before any of it ships as skill text.

**Wins with numbers:** terse reviewer contract (−41% reviewer output, verdicts intact), narration recipe (−54%, zero variance), conditional implementer tiering (~$0.5--1/run, and E22 proved it correctly _refuses_ haiku on prose plans), fixture-realism replicated on svelte (−24% scope-matched).

**Things now provably dead:** capping controller thinking **backfires** --- turns rose 92→138 and output doubled; thinking buys turn efficiency. Plan word budgets slash test content −62% even when code is exempted. Sonnet plan generation keeps fidelity but collapses task structure. Implementation bodies in plans are marginal --- tests + interfaces + structure carry the whole load (E28).

**Risk finding worth remembering:** reviewers given only the diff package produce _confident_ spec verdicts that silently redefine "spec" as the global constraints --- 0/5 flagged the missing brief. Same failure family as the haiku-reviewer advocacy.

**Six leads closed as already-optimal** (report reads, cache health, reviewer floor, haiku fixers, todo bookkeeping, dispatch re-derivation) --- recorded so nobody re-buys them.

Three of my own measurement bugs were caught and corrected mid-loop by the manual-inspection discipline (a grep counting template echoes as self-review catches, a harness that never inlined the diff, a scorer regex missing newlines) --- one retracted verdict was re-measured clean (−74% became the honest −41%).

요약하면, 약 36시간의 작업과 보조금이 없었다면 $650에 달했을 토큰 사용 끝에, Anthropic eval benchmark 기준으로 Superpowers 빌드의 wall-clock runtime은 50%, token spend는 60% 줄어든 것으로 나타났습니다.

그런 다음 Codex를 대상으로 eval을 실행했습니다. 결과는 좋지 않았습니다. 같은 수준의 개선이 나오지 않을 수도 있다고 걱정하긴 했지만, 결과는 개선이 전혀 없음이었습니다.

몇 분간 살펴본 뒤 원인을 찾았습니다. Codex에서는 eval이 아직 host OS로부터 충분히 격리되어 있지 않았습니다. 그래서 우리는 계속 Superpowers 5.1.0을 benchmark하고 있었습니다.

조금 손본 뒤에는... 네. 모든 결과가 그대로 유지됐습니다.

가장 큰 개선은 spec compliance review agent와 code quality review agent를 합치고, reviewer에게 넘기는 review “packet”을 미리 만들어 reviewer가 git을 거의 실행하지 않아도 되게 한 것, 그리고 특정 task에 어떤 종류의 agent가 필요한지 orchestrator에게 알려 주는 guidance를 바꾼 데서 나왔습니다.

우리는 Superpowers eval suite를 열심히 다듬어 왔고, 그것이 없었다면 이번 변경을 측정하고 테스트하는 일은 불가능했을 것입니다. 이 suite는 아직 비교적 초기 단계지만, 덕분에 여러 supported harness에서 Superpowers 변경을 만들고 테스트할 수 있으며, 점점 늘어나는 coding agent 집합을 대상으로 그 변경이 어떤 효과를 내는지 정량화할 수 있습니다. eval suite는 https://github.com/prime-radiant-inc/superpowers-evals 에서 확인할 수 있습니다.

Superpowers 6에서 우리와 우리의 robot buddies가 만들어 낸 개선을 매우 자랑스럽게 생각합니다. 새 버전이 마음에 드실 것이라고 생각합니다.

지금 바로 https://github.com/obra/superpowers에서 설치할 수 있습니다. 앞으로 며칠에 걸쳐 first party plugin marketplace에도 차례로 반영될 예정입니다.

PS: 채용 중입니다! Superpowers를 full time으로 함께 만들어야 할 사람이 떠오른다면 이 공고를 공유해 주세요: https://primeradiant.com/jobs/superpowers-community-engineer/

^{source https://blog.fsck.com/2026/06/15/Superpowers-6/}

HN에서는 Superpowers 6의 속도와 토큰 절감 주장보다, 이런 스킬 기반 개발 절차가 지금도 필요한지를 두고 판단이 갈렸다. 회의적인 사용자는 최신 Codex나 Claude Code만으로도 충분하다고 봤다. 복잡한 프롬프트와 워크플로가 컨텍스트를 차지하고 실행 턴을 늘리며, 작은 버그 수정에도 계획·TDD·산출물 생성을 붙여 오히려 비용과 시간을 키운다는 경험이 반복됐다.

꾸준히 쓰는 쪽은 Superpowers를 단순한 프롬프트 묶음이 아니라 작업을 체계화하는 방법론으로 받아들였다. 먼저 요구사항을 따져보고 계획을 세운 뒤, 테스트와 리뷰를 통해 모델이 성급하게 구현으로 뛰어들지 못하게 하는 점을 장점으로 꼽았다. 긴 명세를 여러 세션에 걸쳐 처리하거나, 여러 저장소와 얽힌 큰 정리 작업을 끝까지 밀고 가야 할 때 상태와 절차가 남는다는 점도 가치로 언급됐다.

다만 이 장점은 모든 작업에 똑같이 적용되지 않는다. 일반화된 스킬일수록 개인이나 팀의 실제 개발 방식과 어긋날 수 있고, TDD 자체를 토큰 낭비로 보는 사용자도 있었다. 실제 운용도 상시 적용보다는 Claude가 필요할 때 선택하게 두거나, 특정 모델과 조합할 때만 쓰는 방식에 가까웠다. 어떤 사용자에게는 큰 프로젝트를 가능하게 한 도구였지만, 다른 사용자에게는 같은 절차가 작은 작업을 무겁게 만드는 요인이었다.

버전 6에서 토큰 사용량과 실행 시간이 줄었다는 체감도 있었지만, Superpowers를 쓰지 않았을 때와 비교한 기준이 부족하다는 지적도 남았다. 결국 도입 여부는 도구 자체의 주장보다 작업 성격으로 판단해야 한다. 작은 수정이 많은 환경인지, 긴 명세와 검증 절차가 필요한 구현이 많은지, 그리고 절차가 주는 안정성이 추가 비용과 시간을 넘어서는지를 실제 프로젝트에서 비교해봐야 한다.