Superpowers 완벽가이드 4편: 설계가 먼저인 작업 흐름

요약#

참고 자료#

• obra/superpowers - GitHub README
• brainstorming - SKILL.md
• Jesse Vincent - Superpowers: How I’m using coding agents in October 2025

바로 써먹는 시작 템플릿#

설계 중심 흐름을 바로 체감하고 싶다면, 아래 문장으로 시작하면 됩니다.

• 이 작업은 구현보다 설계부터 정리해주세요.
• 대안 2~3개를 비교한 뒤 추천안을 주세요.
• 한 번에 하나씩 질문하면서 범위를 좁혀주세요.
• 설계를 승인하기 전에는 코드를 시작하지 마세요.

TIP

Superpowers의 설계 단계는 문서를 예쁘게 만들기 위한 절차가 아닙니다.
무엇을 만들고 있는지부터 정확히 합의하기 위한 절차입니다.

문제 상황#

코딩 에이전트가 무서운 이유는 코드를 못 써서가 아닙니다.
애매한 요구사항도 그럴듯한 코드로 빠르게 바꿔버릴 수 있기 때문입니다.

이 속도는 처음에는 장점처럼 보입니다.
하지만 조금만 생각해보면, 잘못된 전제가 빠르게 코드가 되는 순간부터 문제가 시작됩니다.

• 요구사항이 아직 모호한데 구조가 먼저 정해집니다
• 최소 범위가 정해지지 않았는데 구현이 커집니다
• 사용자가 원한 것과 에이전트가 이해한 것이 어긋납니다
• 이미 코드를 쓴 뒤라서 되돌리기 비용이 커집니다

그래서 Superpowers는 구현 속도를 더 올리는 쪽보다, 시작 순서를 더 엄격하게 만드는 쪽을 택합니다.
핵심은 코드를 늦게 쓰는 것이 아니라, 잘못 쓸 코드를 줄이는 것입니다.

왜 설계가 먼저일까요?#

공식 README는 기본 흐름을 brainstorm -> plan -> implement 순서로 설명합니다.
이 순서만 봐도 Superpowers가 구현보다 앞에 두는 것이 무엇인지 바로 드러납니다.

핵심은 간단합니다.
설계는 구현의 준비 단계가 아니라, 구현을 안전하게 만드는 첫 번째 필터입니다.

설계를 먼저 두면 좋은 점은 세 가지입니다.

brainstorming은 실제로 무엇을 할까요?#

brainstorming skill은 단순히 아이디어를 떠올리는 단계가 아닙니다.
실제로는 설계를 위한 대화 프로토콜에 가깝습니다.

공식 skill 문서를 기준으로 보면, 큰 흐름은 이렇습니다.

이 흐름에서 중요한 점은 두 가지입니다.

• 질문은 한 번에 하나씩 묻습니다
• 설계 승인이 있기 전에는 구현 단계로 넘어가지 않습니다

즉, brainstorming은 “아이디어를 내는 단계”보다 “아이디어를 실행 가능한 설계로 좁히는 단계”라고 보는 편이 더 정확합니다.

왜 한 번에 하나씩 질문할까요?#

일반적인 대화에서는 질문을 많이 던질수록 더 철저해 보일 수 있습니다.
하지만 설계 단계에서는 오히려 반대인 경우가 많습니다.

질문이 한꺼번에 쏟아지면 사용자는 대충 대답하게 됩니다.
대답이 대충이면, 에이전트는 그 빈틈을 다시 추측으로 메웁니다.

그래서 brainstorming은 한 번에 하나씩 묻는 방식을 강하게 밀어붙입니다.
이 방식은 느려 보이지만, 실제로는 답변 품질을 높입니다.

설치 전 흔한 흐름

1
사용자: 관리자 페이지 만들어줘.
2
에이전트: 사용자 관리, 권한 관리, 로그, 검색, 정렬, 대시보드, 알림도 같이 넣겠습니다.

설치 후 설계 중심 흐름

1
사용자: 관리자 페이지 만들어줘.
2
에이전트: 먼저 이 페이지의 핵심 목적부터 좁히겠습니다. 지금 가장 중요한 것은 사용자 조회인가요, 권한 변경인가요?

차이는 분명합니다.
하나는 기능을 늘리고, 다른 하나는 목적을 좁힙니다.

왜 대안을 꼭 비교할까요?#

brainstorming은 2~3개의 접근을 비교하라고 요구합니다.
이 지점이 중요한 이유는, 에이전트도 사람처럼 첫 번째 떠오른 답에 쉽게 매달릴 수 있기 때문입니다.

대안을 비교하면 최소한 다음이 가능해집니다.

• 지금 필요한 최소 범위를 고를 수 있습니다
• 과한 구조를 피할 수 있습니다
• 사용자가 원하는 복잡도와 일치시킬 수 있습니다
• 추천안의 이유를 설명할 수 있습니다

예를 들어 같은 요청도 설계 단계에서는 이렇게 바뀔 수 있습니다.

접근 비교 예시

1
옵션 A: 가장 빠른 단일 페이지
2
옵션 B: 목록과 상세를 분리한 구조
3
옵션 C: 향후 확장을 고려한 관리자 프레임 구조
4
추천: 지금 요구사항이 작으므로 A부터 시작하고, 필요 시 B로 확장

이 비교가 없으면 구현은 보통 가장 큰 구조나 가장 익숙한 구조로 흘러갑니다.
Superpowers는 바로 이 습관을 막으려는 쪽에 가깝습니다.

설계 승인은 왜 마지막 방어선일까요?#

많은 분이 설계 승인을 “중간 확인” 정도로 생각합니다.
하지만 실제로는 구현 전에 남아 있는 마지막 방어선에 가깝습니다.

설계 승인이 필요한 이유는 다음과 같습니다.

• 사용자가 원한 방향과 에이전트의 해석이 같은지 확인합니다
• 구현 전에 범위를 다시 줄일 수 있습니다
• 아직 코드를 쓰지 않았기 때문에 수정 비용이 낮습니다
• 이후 단계의 계획과 테스트 기준이 더 선명해집니다

즉, 설계 승인은 절차를 늘리는 장식이 아닙니다.
구현을 시작해도 되는 최소 조건을 확인하는 단계입니다.

설계가 먼저면 정말 더 빨라질까요?#

겉으로 보면 설계 단계는 느립니다.
질문하고, 비교하고, 설명하고, 승인까지 받으니 당연히 시간이 더 들 것처럼 보입니다.

하지만 실제로는 자주 반대로 작동합니다.
초반 10분의 설계가 뒤쪽 2시간의 재작업을 줄이는 경우가 많기 때문입니다.

특히 아래 상황에서는 설계 선행이 거의 필수에 가깝습니다.

• 기능 이름은 명확하지만 범위가 넓을 때
• 사용자 의도와 에이전트 해석이 쉽게 어긋날 때
• 기존 코드베이스 규칙을 따라야 할 때
• 나중에 계획과 테스트까지 이어져야 할 때

README가 설계 뒤에 곧바로 writing-plans를 두는 이유도 같습니다.
설계가 선명해야 계획이 구체적이 되고, 계획이 구체적이어야 구현이 덜 흔들립니다.

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

설계가 먼저인 흐름에서는 에이전트가 예전보다 덜 시원하게 느껴질 수 있습니다.
하지만 그 대신 더 설명 가능하고, 더 예측 가능한 흐름을 얻게 됩니다.

사용자가 기대하면 좋은 변화는 이렇습니다.

• 바로 코드를 주지 않아도 정상입니다
• 질문이 늘어나도 이상이 아닙니다
• 대안 비교가 나오면 오히려 좋은 신호입니다
• 설계 승인을 묻는 시점이 구현의 출발선입니다

이 흐름을 이해하고 나면, “왜 아직 안 만들었지?”보다 “지금 무엇을 확정하고 있지?”에 더 집중하게 됩니다.
그 순간부터 Superpowers의 장점이 보이기 시작합니다.

마무리#

Superpowers가 설계를 먼저 두는 이유는 단순합니다.
코드를 빨리 쓰는 능력보다, 어떤 코드를 써야 하는지 먼저 합의하는 능력이 더 중요하다고 보기 때문입니다.

brainstorming은 그 철학을 실제 대화 흐름으로 바꿉니다.
질문으로 범위를 좁히고, 대안을 비교하고, 설계를 제시하고, 승인을 받은 뒤 다음 단계로 넘어갑니다.

다음 글에서는 이 설계를 실제 작업 단위로 바꾸는 단계, 즉 writing-plans를 중심으로 큰 작업을 왜 작은 계획으로 나누는지 이어서 설명하겠습니다.