Superpowers를 사용한 후, 나의 AI 에이전트는 마침내 진짜 동료처럼 느껴지기 시작했다

저는 한동안 에이전트 기반 개발 (agentic development)을 해왔습니다. 코딩 에이전트 (coding agents)에게 실제 작업을 맡기고, 제가 방향을 잡는 동안 에이전트가 코드를 작성하고 리팩토링 (refactor)하도록 두는 방식이었죠. 실패 양상은 항상 동일했습니다. 제가 잘못된 고도 (altitude)에서 무언가를 설명하면, 에이전트는 자신의 가설로 그 간극을 기쁘게 채워버렸고, 결국 우리 둘 다 잘못된 방향을 향해 자신 있게 질주하게 되었습니다. 해결책은 결코 "더 똑똑한 모델"이 아니었습니다. 그것은 바로 구조 (structure)였습니다.

그것이 바로 Superpowers가 제공하는 것입니다. 이는 Jesse Vincent (MIT, 활발히 유지 관리 중, 현재 v5.x 버전)가 만든 오픈 소스 방법론 (open source methodology)으로, 조합 가능한 기술 (composable skills) 세트와 에이전트가 실제로 이를 사용하게 만드는 지침 (instructions)을 함께 제공합니다. 이는 Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot CLI 및 기타 몇 가지 도구에서 실행됩니다. 실제 업무에 몇 주간 적용해 본 후의 솔직한 피드백이며, 대부분의 내용은 제 작업 방식을 바꾼 단 하나의 기술인 브레인스토밍 (brainstorming)에 초점을 맞추고 있습니다.

설치 방법 및 작동 원리

Github 저장소:

https://github.com/obra/superpowers

설치는 에이전트당 한 줄의 명령어로 가능합니다:
Claude Code에서는 다음과 같이 실행합니다:

/plugin install superpowers@claude-plugins-official

Gemini CLI는 다음을 사용합니다:

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

Cursor는 다음을 사용합니다:

/add-plugin superpowers

그리고 Codex와 Copilot CLI는 각자의 마켓플레이스에서 이를 가져옵니다.

나중에 기억해야 할 명령어는 없습니다. using-superpowers라고 불리는 메타 기술 (meta skill)이 에이전트의 루프 (loop)에 연결됩니다. 각 메시지마다 적용 가능한 기술이 있는지 확인하며, 결정적으로 에이전트가 계획 모드 (plan mode)에 진입하기 전에 "우리가 이미 브레인스토밍을 했나요?"라고 묻습니다. 만약 하지 않았다면, 브레인스토밍이 가장 먼저 실행됩니다. 기술들은 정중한 제안이 아니라 필수적인 워크플로우 (workflows)로 취급되며, 에이전트는 자신이 어떤 기술을 실행 중인지 알리고 각 체크리스트 항목을 할 일 (todo)로 추적합니다.

전체 파이프라인 (pipeline)이 이 모든 것을 일관성 있게 만듭니다:

**브레인스토밍 (brainstorming)**은 거친 아이디어를 승인된 설계와 문서화된 사양 (spec)으로 변환합니다.
**git-worktrees 사용 (using-git-worktrees)**은 격리된 브랜치를 생성하고, 작업이 시작되기 전에 깨끗한 테스트 기준점 (baseline)을 검증합니다.
**계획 작성 (writing-plans)**은 승인된 설계를 2~5분 단위의 작업으로 세분화하며, 각 작업에는 정확한 파일 경로, 실제 코드, 그리고 검증 단계가 포함됩니다. 기준은 맥락을 전혀 모르는 열정적인 주니어 개발자라도 이를 실행할 수 있어야 한다는 것입니다.
**서브에이전트 주도 개발 (subagent-driven-development)**은 작업당 새로운 서브에이전트 (subagent)를 배정하고, 각 작업에 대해 2단계 리뷰를 수행합니다. 첫 번째는 사양 준수 여부이며, 두 번째는 코드 품질입니다. (executing-plans는 인간의 체크포인트가 포함된 배치 (batch) 방식의 대안입니다.)
**테스트 주도 개발 (test-driven-development)**은 실제 RED-GREEN-REFACTOR를 강제하며, 테스트가 작성되기 전에 작성된 코드는 삭제합니다.
**코드 리뷰 요청 (requesting-code-review)**은 작업 사이에 실행되며, 중요한 결함이 발견되면 진행을 차단합니다.
**개발 브랜치 마무리 (finishing-a-development-branch)**는 테스트를 검증하고 머지 (merge), PR, 유지 또는 폐기 결정 사항을 사용자에게 전달한 뒤, 워크트리 (worktree)를 정리합니다.

기저에 깔린 철학은 명확합니다: 테스트 우선, 임시방편 (ad hoc)보다는 체계적인 방식, 복잡성 감소를 최우선 목표로 설정, 그리고 주장보다는 증거를 중시하는 것입니다. 이 중 어느 것도 시니어 개발자에게 새로운 것은 아닙니다. 핵심은 이제 에이전트가 제가 모든 단계를 감시하지 않아도 이 철학을 따른다는 점입니다.

브레인스토밍 (brainstorming) 자세히 살펴보기

브레인스토밍 (Brainstorming)은 정문과 같으며, 이후의 모든 하류 (downstream) 과정을 위한 계약을 설정합니다. 에이전트가 당신이 무언가를 만들고 있다는 것을 감지하는 순간, 에이전트는 키보드에 손을 대지 않습니다. 대신 기존 프로젝트의 컨텍스트 (context)를 탐색한 다음, 소크라테스식 루프 (Socratic loop)를 실행합니다. 즉, 한 번에 하나의 질문을 던지고, 가능한 경우 객관식으로 제시하며, 당신의 마지막 답변을 바탕으로 각 질문을 쌓아 올립니다. 에이전트는 첫 번째 생각에 바로 매몰되기보다 두세 가지의 뚜렷한 접근 방식을 제안합니다. 그런 다음 실제로 읽을 수 있을 만큼 짧은 섹션 단위로 설계를 제시하고, docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md에 명세서 (spec)를 작성한 뒤, 이를 커밋 (commit)합니다. 이어 플레이스홀더 (placeholder), 모순, 범위 확장 (scope creep)에 대해 자체 검토 (self review)를 수행하고, 어떤 작업이 진행되기 전에 당신에게 해당 파일을 검토해 달라고 요청합니다.

엔지니어로서 저에게 눈에 띄는 두 가지 설계 결정이 있습니다. 첫째, 이 스킬 (skill)은 오직 writing-plans로만 작업을 넘깁니다. frontend-design, mcp-builder 또는 그 어떤 구현 (implementation) 스킬로도 넘어가는 것을 명시적으로 거부하는데, 이것이 바로

가장 강력한 부분은 또한 가장 단순한 부분입니다. 의도 (intent)와 구현 (implementation) 사이에는 엄격한 관문 (gate)이 존재하며, 에이전트는 명시적인 승인 없이는 그 선을 넘지 않습니다.

저는 이것이 마찰 (friction)이 될 것이라고 예상했습니다. 하지만 오히려 이것은 제가 반드시 유지하고 싶을 만큼 소중한 부분이 되었습니다. 에이전트와 작업하며 겪었던 대부분의 재작업 (rework)은 모호한 의도가 문자 그대로의 실행자 (literal executor)를 만났을 때 발생했습니다. 이 관문은 단 한 줄의 코드가 생성되기 전에 대화 속의 모호함을 제거하여 문서화하도록 강제합니다. 코드가 존재할 시점에는 이미 모든 가정이 가시화되어 논의 가능한 상태가 됩니다.

사양서 (spec)가 채팅 메시지가 아닌 확정된 파일 (committed file)이라는 점은 전문가들이 높게 평가할 디테일입니다. 이는 저장소 (repo) 내에 날짜와 주제를 가진 실제 산출물 (artifact)로서, 해당 사양을 정당화하는 코드 바로 옆에 위치합니다. 몇 달 후, 이 파일은 "왜 이것이 이런 방식으로 구축되었는가"라는 질문에 답을 해줍니다. 에이전트가 구축한 코드베이스에서 보통 답을 찾을 수 없는 바로 그 질문에 말이죠. 이것은 조용히 제가 가진 가장 유용한 문서 (documentation)가 되었습니다.

피드백 2: 깊이(depth)에 들어가기 전 범위(scope) 평가

두 번째로 가치 있는 점은 미묘합니다. 질문이 시작되기도 전에, 브레인스토밍 (brainstorming) 단계에서 범위를 평가합니다. 만약 당신이 실제로 여러 개의 독립적인 하위 시스템 (subsystems)인 것을 건네준다면, 에이전트는 세부 사항을 다듬기를 거부하는 대신 이를 각각의 사양 (spec), 계획 (plan), 구현 주기 (implementation cycle)를 갖는 하위 프로젝트 (sub-projects)로 분해 (decompose)하도록 도와줍니다. 이 단 하나의 동작만으로도 하나의 거대하고 구축 불가능한 사양을 만들어내는 전형적인 실패를 방지하며, 이는 신중한 테크 리드 (tech lead)가 모호한 에픽 (epic)에 대해 반대 의견을 내는 방식과 닮아 있습니다.

한 번에 하나의 질문만 던지는 루프 (loop)와 결합되어, 저에게 미친 영향은 예상치 못한 것이었습니다. 이제 저는 에이전트를 열기도 전에 문제를 분해하고, 접근 방식 (approaches)과 트레이드오프 (tradeoffs)를 생각하며 사고합니다. 이 기술은 결과물뿐만 아니라 운영자 (operator)를 훈련시켰습니다.

솔직한 비판

이것은 공짜가 아니며, 진지하게 검토하려는 분들을 위해 몇 가지 비용 (costs)을 언급할 가치가 있습니다.

이 게이트(gate)는 일률적으로 적용되므로, 단 한 줄의 변경 사항도 새로운 서비스를 만드는 것과 동일한 절차를 거쳐야 합니다. 사소한 편집의 경우 설계 단계가 마치 서류 작업처럼 느껴지며, 때로는 그저 변경 사항(diff)만 확인하고 싶을 때도 있습니다. 서브에이전트(subagent) 중심 모델 또한 실제적인 대가가 따릅니다. 작업마다 새로운 서브에이전트를 생성하고 2단계 검토(two-stage review)를 거치는 방식은 충실도(fidelity)를 위해 실제 소요 시간(wall clock time)과 토큰(tokens)을 희생하는 구조인데, 이는 중대한 기능을 구현할 때는 올바른 트레이드오프(trade-off)이지만, 빠른 프로토타이핑(quick spike)을 할 때는 잘못된 선택입니다. 또한 TDD(테스트 주도 개발) 강제성은 진정으로 엄격합니다. 테스트가 작성되기 전에 작성된 코드를 삭제하는 것은 원칙적이지만, 문제의 형태를 여전히 탐색 중인 탐색적 작업(exploratory work) 단계에서는 당신과 충돌할 것입니다.

다행인 점은 계층 구조가 명시적이고 합리적이라는 것입니다. 스킬(Skills)이 모델의 기본 동작을 재정의할 수 있지만, CLAUDE.md, AGENTS.md 또는 GEMINI.md에 작성된 당신의 직접적인 지시가 항상 우선합니다. 따라서 만약 어떤 스킬이 "항상 TDD를 수행하라"고 말하고 당신의 프로젝트 설정이 하지 말라고 되어 있다면, 당신의 프로젝트 설정이 승리합니다. 이것은 주관적인 기본 설정(opinionated default)일 뿐, 감옥이 아닙니다. 실제로 저는 한 개 이상의 파일을 가로지르는 작업에는 게이트를 켜두고, 일회성 작업에는 강도를 낮춥니다.

내가 이를 계속 사용하는 이유

나를 사로잡은 것은 속도가 아니라, 예상치 못한 상황(surprises)의 급격한 감소였습니다. 이제 코드는 내가 구상한 것과 일치하는데, 그 이유는 우리가 먼저 글로써 그 구상을 합의했기 때문입니다. PR(Pull Request)은 더 작아졌고, 사양(specs)은 존재하며, 작업 루프는 마치 일방적인 지시를 내리는 것이 아니라, 내가 설계를 대충 넘기려는 것을 허용하지 않는 누군가와 페어 프로그래밍(pairing)을 하는 것처럼 느껴집니다.

아이러니하게도 가장 가치 있는 기능은 '거절'입니다. "아직 안 됩니다, 좀 더 생각해 봅시다"라고 말하는 에이전트가 모든 것에 "네"라고 답하는 에이전트보다 훨씬 더 유용하다는 것이 밝혀졌습니다.

만약 당신이 에이전트를 활용해 개발하면서 요청한 것과 결과물 사이의 간극을 느껴본 적이 있다면, 주말을 투자할 가치가 있습니다. Superpowers는 Jesse Vincent과 Prime Radiant 팀이 만든 오픈 소스이며, 브레인스토밍(brainstorming)부터 시작하는 것이 좋습니다.

에이전트가 코드를 작성하기 전에 설계를 먼저 해보려고 시도해 보셨나요? '선(先) 사고(think-first)' 게이트가 도움이 되었는지, 아니면 방해가 되었는지 듣고 싶습니다.