Brainstorming & Design
첫 번째이자 가장 중요한 규칙: 사용자가 설계를 승인할 때까지 코드를 작성할 수 없습니다.
왜 Brainstorming이 먼저인가
소프트웨어 개발에서 가장 비용이 많이 드는 실수는 잘못된 것을 올바르게 만드는 것입니다. 완벽한 코드, 완전한 테스트 커버리지, 깔끔한 아키텍처가 있어도 — 실제 문제를 해결하지 못하는 것을 납품할 수 있습니다.
Brainstorming은 형식적인 절차가 아닙니다. 오해가 버그가 되기 전에 표면으로 드러나는 단계입니다. 범위가 명확해지고, 접근 방식이 비교되며, 모든 사람이 "완료"가 실제로 무엇을 의미하는지 합의하는 단계입니다.
Superpowers에서 brainstorming은 hard gate로 강제됩니다: AI는 사용자가 설계를 검토하고 승인할 때까지 명시적으로 프로덕션 코드 작성이 금지됩니다. 이것은 부드러운 권고가 아닙니다. 행동 제약입니다.
Hard Gate
╔══════════════════════════════════════════════════════════════╗
║ HARD GATE: NO CODE MAY BE WRITTEN UNTIL THE USER ║
║ HAS EXPLICITLY APPROVED THE PROPOSED DESIGN. ║
╚══════════════════════════════════════════════════════════════╝
brainstorming skill을 호출하면, AI는 코드 생성이 차단된 모드로 진입합니다. 접근 방식을 설명하기 위한 의사 코드, 다이어그램, 파일 구조 스케치, 예시 코드 스니펫은 작성할 수 있지만 — 여러분이 "승인" 또는 이에 상응하는 확인을 할 때까지 실제 구현 코드는 없습니다.
이 gate는 조기에 작성된 코드가 낭비된 노력의 주요 원인이기 때문에 존재합니다. 코드가 존재하면, 그것을 유지하려는 심리적 압박이 생깁니다. 사람들은 이미 작성한 코드를 옹호합니다. 너무 일찍 내려진 구현 결정에 의해 설계 결정이 제약됩니다. Hard gate는 이 함정을 방지합니다.
7단계 Brainstorming 프로세스
1단계: 탐색 (Explore)
AI는 이해를 확인하기 위해 요청을 자신의 말로 재진술하는 것으로 시작합니다. 요청된 기능이 아닌 — 해결되는 핵심 문제를 파악합니다.
예시: "결제 후 사용자가 주문 상태를 추적할 수 없는 것이 실제 문제인 것 같습니다. 맞나요?"
2단계: 질문 (Question)
AI는 명확화 질문을 합니다 — 한 번에 하나씩. 미리 10개의 질문 목록을 제시하지 않습니다. 하나의 질문, 답을 기다린 후, 필요하면 다음 질문.
이 규칙은 묶어서 하는 질문이 압도적이고 종종 절반의 답변만 얻기 때문에 존재합니다. 순차적인 질문은 더 정확한 정보와 더 자연스러운 대화로 이어집니다.
3단계: 접근 방식 (Approaches)
AI가 충분한 정보를 얻으면, 2~3가지 뚜렷한 접근 방식을 제시합니다. 각 접근 방식은 다음을 포함합니다:
- 간략한 설명
- 관련된 핵심 기술적 결정
- 트레이드오프 (장단점, 칭찬만이 아닌)
- 복잡성에 대한 대략적인 추정
4단계: 제시 (Present)
접근 방식은 적절한 경우 권장 사항과 함께 명확하게 제시됩니다. AI는 "상황에 따라 다릅니다" 뒤에 숨지 않고 — 그 의견 뒤의 가정을 명확히 하면서 의견을 제시합니다.
5단계: 사양 (Spec)
여러분이 접근 방식을 선택하거나 수정한 후, AI는 설계 사양서를 작성합니다 — 무엇을 만들고, 무엇을 만들지 않으며, 각 부분이 어떻게 맞춰지는지 간략하게 설명하는 문서입니다. 이것이 구현 계획의 북극성이 됩니다.
6단계: 검토 (Review)
여러분이 사양서를 검토합니다. 변경, 명확화, 또는 다른 접근 방식을 요청할 수 있습니다. AI는 사양서가 정확할 때까지 반복합니다.
7단계: 전환 (Transition)
여러분이 사양서를 승인하면, brainstorming이 종료됩니다. AI는 gate가 해제됐음을 확인하고 계획 단계로 전환합니다. 승인된 사양서가 계획 작성의 입력이 됩니다.
한 번에 하나의 질문 규칙
이 규칙은 명시적으로 짚고 넘어갈 만큼 중요합니다.
잘못된 접근:
"도움을 드리기 전에 다음이 필요합니다: (1) 어떤 데이터베이스를 사용하시나요? (2) 인증이 필요한가요? (3) REST API인가요 GraphQL인가요? (4) 배포 대상은 무엇인가요? (5) 캐싱이 필요한가요?"
이것은 압도적이고 사용자가 모든 것에 한꺼번에 답하려 해서 종종 모호한 답변을 얻습니다.
올바른 접근:
"어떤 데이터베이스를 사용하시나요?"
답을 기다린 후:
"이 기능에 사용자 인증이 필요한가요?"
답을 기다린 후 계속합니다.
순차적인 질문은 대화처럼 느껴집니다. 묶어서 하는 질문은 양식 같은 느낌입니다. 대화가 더 좋은 정보를 만들어냅니다.
가능한 경우 객관식으로
질문에 알려진 일반적인 답변이 있는 경우, AI는 개방형 질문보다 선택지로 제시해야 합니다.
덜 유용:
"어떤 종류의 데이터 저장소가 필요한가요?"
더 유용:
"데이터 저장소로 어떤 것이 적합한가요? A) PostgreSQL (관계형, ACID 준수) B) MongoDB (문서 저장소, 유연한 스키마) C) Redis (인메모리, 캐싱/세션) D) 기타 (직접 명시해 주세요)"
객관식은 인지 부하를 줄이고, 실제 옵션으로 대화를 고정시키며, brainstorming 단계를 가속화합니다.
트레이드오프와 함께 2~3가지 접근 방식 제시
AI가 접근 방식을 제시할 때, 다음 구조를 따라야 합니다:
## Approach A: [이름]
**Description:** [이 접근 방식이 하는 것]
**Technical decisions:** [이 접근 방식이 내리는 핵심 선택들]
**Pros:** [장점]
**Cons:** [단점, 솔직하게]
**Best for:** [이 접근 방식이 적합한 경우]
## Approach B: [이름]
...
## Recommendation
[AI의 권장 접근 방식과 그 뒤의 이유]
AI는 하나의 접근 방식만 제시해서는 안 되고(그것은 선택이 아닙니다) 세 가지 이상도 안 됩니다(그것은 결정 마비입니다). 둘에서 셋이 유용한 범위입니다.
Visual Companion (v5.0 기능)
Superpowers v5.0은 Visual Companion을 도입했습니다 — AI가 brainstorming 출력의 일부로 ASCII 다이어그램, 플로우차트, 아키텍처 스케치를 생성하는 기능입니다.
이러한 시각 자료는 외부 도구 없이도 복잡한 설계를 전달하는 데 도움이 됩니다. 예를 들어:
User → [API Gateway] → [Auth Service]
↘
[Order Service] → [Database]
↗
[Inventory Service]
설계에 여러 컴포넌트, 데이터 흐름, 또는 상태 전환이 포함된 경우, AI에게 사양서에 visual companion을 포함하도록 요청하세요.
피해야 할 Anti-Pattern
Brainstorming 단계는 다음과 같은 방식으로 실패하는 경우가 많습니다:
| Anti-Pattern | 어떻게 보이는가 | 왜 해로운가 |
|---|---|---|
| 코딩으로 서두르기 | "그냥 구현을 시작하고 조정하면 됩니다" | 매몰 비용 오류가 즉시 발동 |
| 거짓 동의 | AI가 "이해했습니다"라고 하지만 요구사항을 확인하지 않음 | 오해가 구현까지 살아남음 |
| 단일 접근 방식 | AI가 하나의 옵션을 제안하고 승인을 요청 | 진정한 설계 선택이 아님 |
| 과도한 사양화 | 기본 흐름이 합의되기 전에 설계 문서가 모든 엣지 케이스를 다룸 | 분석 마비 |
| 범위 확장 수용 | AI가 "하는 김에" 기능을 추가 | 구현을 부풀리고 납품을 지연 |
| 모호한 승인 | 사용자가 읽지 않은 사양서에 "괜찮아 보이네요"라고 말함 | Gate가 형식적인 것이 됨 |
Pre-Planning 체크리스트
Brainstorming에서 계획으로 전환하기 전에 다음을 확인하세요:
어느 항목이라도 체크되지 않았다면, 계획으로 진행하지 마세요. Brainstorming으로 돌아가 간극을 채우세요.
Brainstorming 세션 시작하기
Brainstorming skill을 명시적으로 호출하려면:
"저는 [기능]을 추가하고 싶습니다. 코드를 작성하기 전에 brainstorming을 해봅시다."
또는 사용 가능한 경우 slash command를 사용하세요:
/brainstorm I want to build a notification system
AI는 brainstorming 모드로 진입하고 hard gate가 활성화됩니다. 여러분이 설계가 승인됐다고 말할 때까지 아무것도 만들어지지 않습니다.
Brainstorming의 규율은 복리 이자를 낳습니다. 코딩 전에 요구사항을 맞추는 데 소비된 매 시간은 이후 재작업 3~5시간을 절약합니다. Hard gate는 관료적인 장애물이 아닙니다 — 투자입니다.