brainstorming

brainstorming skill 개요

brainstorming skill의 용도

brainstorming skill은 막연한 아이디어를 코드 작성 전에 승인 가능한 설계안으로 정리해 가는, 구조화된 사전 구현 워크플로입니다. 핵심 역할은 추상적으로 “아이디어를 많이 내는 것”이 아니라, 범위, 가정, 요구사항, 설계 선택지를 먼저 수면 위로 끌어올려 불필요한 재작업을 줄이는 데 있습니다.

누가 brainstorming skill을 설치하면 좋은가

이 brainstorming skill은 “X를 만들어야 해”라는 말이 나오자마자 바로 구현으로 뛰어드는 일이 잦은 사용자에게 특히 잘 맞습니다. 다음 같은 작업에 특히 유용합니다.

• 기능 기획
• 컴포넌트 설계
• 동작 변경 검토
• 내부 도구 제안
• Requirements Planning을 위한 brainstorming

이미 탄탄한 스펙 작성 프로세스를 갖추고 있더라도, 이 skill은 그 프로세스 앞단에서 가볍게 쓰는 정리 단계로 여전히 가치가 있습니다.

일반적인 프롬프트와 무엇이 다른가

가장 큰 차별점은 SKILL.md에 있는 강한 게이트입니다. 에이전트는 설계안을 먼저 제시하고 승인을 받기 전까지 구현, 스캐폴딩, 코드 작성을 하면 안 됩니다. 겉으로는 단순해 보이지만, 일반적인 “이거 만들 수 있게 도와줘” 식 프롬프트와는 실제 동작이 크게 달라집니다. 보통의 어시스턴트는 이런 경우 곧바로 해법이나 코드로 건너뛰는 경우가 많기 때문입니다.

설치 전에 사용자가 실제로 궁금해하는 점

대부분의 사용자는 먼저 이 세 가지를 빠르게 확인하고 싶어 합니다.

1. 이게 나를 느리게 만들까?
2. 뻔한 질문 말고 실제로 도움이 되는 질문을 해줄까?
3. 비주얼 디자인 논의에도 도움이 될까?

답은 이렇습니다. 이 skill은 의도적으로 약간의 프로세스 오버헤드를 추가합니다. 다만 아이디어가 작을수록 그 오버헤드는 작습니다. 그리고 이 skill은 “단순한 작업”이라도 짧은 설계 단계가 필요하다고 분명히 말합니다. 숨은 가정이 비싼 실수로 이어지는 지점이 바로 그 단계이기 때문입니다.

brainstorming skill 사용 방법

brainstorming 설치 및 설정

저장소에서 skill을 추가하려면 다음을 사용하세요.
npx skills add https://github.com/obra/superpowers --skill brainstorming

설치 후에는 먼저 다음 파일부터 여는 것이 좋습니다.

• skills/brainstorming/SKILL.md
• skills/brainstorming/visual-companion.md
• skills/brainstorming/spec-document-reviewer-prompt.md

비주얼 탐색이 필요할 가능성이 있다면 다음도 함께 확인하세요.

• skills/brainstorming/scripts/start-server.sh
• skills/brainstorming/scripts/frame-template.html

brainstorming skill이 전제하는 핵심 워크플로

이 brainstorming 사용 방식은 꽤 명확한 방향성을 갖고 있습니다.

1. 프로젝트 맥락 탐색
2. 필요하면 visual companion 제안
3. 한 번에 하나씩 명확화 질문
4. 설계안 종합
5. 명시적 승인 획득
6. 그 다음에만 기획 또는 구현 단계로 이동

에이전트가 아이디어에서 바로 코드로 넘어간다면, 이 skill을 제대로 따르고 있다고 보기 어렵습니다.

더 나은 brainstorming 사용을 위해 어떤 입력을 줘야 하나

이 skill은 기능 이름만 던졌을 때보다, 배경 정보가 있을 때 훨씬 잘 작동합니다. 좋은 시작 입력에는 보통 다음이 포함됩니다.

• 해결하려는 문제
• 사용자 대상
• 현재 시스템 또는 repo 맥락
• 제약 조건
• 무엇을 “완료”로 볼지
• 이미 알고 있는 비목표 항목

약한 입력 예:

Add notifications.

더 강한 입력 예:

Add in-app notifications for failed background imports. Users are operations staff, not end customers. We already have email alerts, but they are too slow for live triage. Keep scope to the admin dashboard only. Do not add mobile push or user preference management in v1.

두 번째처럼 주면 brainstorming skill이 훨씬 날카로운 후속 질문을 던질 수 있을 만큼 구조가 생깁니다.

거친 아이디어를 강한 첫 프롬프트로 바꾸는 방법

brainstorming에 실무적으로 쓸 수 있는 프롬프트 템플릿은 다음과 같습니다.

Use the brainstorming skill for Requirements Planning.
Context: [project/repo/product]
Problem: [what is happening now]
Target user: [who is affected]
Constraints: [timeline, stack, compliance, UX, compatibility]
Non-goals: [what not to solve]
Please ask clarifying questions one at a time, then present a proposed design for approval before any implementation.

이 템플릿은 skill이 의도한 흐름과 잘 맞고, 질문이 뻔하고 넓게 흘러갈 가능성을 줄여줍니다.

brainstorming에서 명확화 질문은 어떻게 이뤄져야 하나

작아 보이지만 중요한 포인트가 하나 있습니다. 이 skill은 질문을 한 번에 하나씩 던지도록 설계되어 있습니다. 긴 탐색용 설문지처럼 한꺼번에 쏟아내는 방식이 아닙니다. 그 이유는 앞선 답변이 다음 질문의 방향을 바꾸는 경우가 많기 때문입니다. 에이전트가 질문 15개를 한꺼번에 던진다면, 이 brainstorming 가이드가 의도한 상호작용형 정제 과정이 사라집니다.

visual companion은 언제 써야 하나

이 저장소에는 브라우저 기반 visual companion이 포함되어 있습니다. 사용자가 눈으로 봐야 선택지를 더 잘 이해할 수 있는 경우에 활용하세요.

• 와이어프레임
• 레이아웃 비교
• UI 흐름
• 아키텍처 다이어그램
• 상태 또는 관계 시각화

주제가 UI라는 이유만으로 무조건 쓸 필요는 없습니다. 예를 들어 “이걸 wizard로 할까, modal로 할까?” 같은 개념적 질문은 텍스트만으로도 충분할 수 있습니다. 반면 “이 두 가지 wizard 레이아웃 중 어떤 쪽이 더 명확한가?” 같은 질문은 비주얼 경로에 매우 잘 맞습니다.

visual companion은 실제로 어떻게 서빙되나

이 비주얼 헬퍼는 단순 문서가 아니라, 로컬 세션을 실행하기 위한 스크립트까지 포함합니다.

• scripts/start-server.sh
• scripts/stop-server.sh
• scripts/server.cjs
• scripts/helper.js

start-server.sh는 임의의 높은 포트에서 로컬 서버를 띄우며, 세션 파일을 /tmp 아래나 .superpowers/brainstorm/ 같은 프로젝트 디렉터리 안에 저장할 수 있습니다. 목업을 세션 간에 유지하고 싶다면 이 점이 특히 유용합니다.

visuals에 의존하기 전에 확인할 실무 환경 포인트

비주얼 워크플로는 브라우저에서 접근 가능한 환경을 전제로 합니다. 원격 컨테이너, VM, SSH 기반 워크플로에서 사용한다면 다음을 꼭 확인하세요.

• --host
• --url-host
• 세션 디렉터리의 영속성

로컬 전용 환경에서는 기본값으로도 무난합니다. 하지만 공유 환경이나 원격 환경에서는 브라우저 피드백을 중심으로 워크플로를 짜기 전에 네트워크 구성을 먼저 잡아두는 편이 좋습니다.

빠르게 적응하려면 어떤 파일부터 읽어야 하나

가장 짧은 경로로 실제 사용 품질까지 끌어올리고 싶다면, 다음 순서로 읽는 것이 좋습니다.

1. 동작 계약을 이해하기 위한 SKILL.md
2. 브라우저 지원이 언제 유용한지 보는 visual-companion.md
3. “구현 가능한 수준”이 무엇인지 가늠하는 spec-document-reviewer-prompt.md
4. 비주얼 경로가 필요할 때의 scripts/start-server.sh

이 순서로 보면 먼저 판단 로직을 익히고, 그다음 선택적 도구를 붙일 수 있습니다.

brainstorming의 좋은 출력은 어떤 모습이어야 하나

성공적인 brainstorming 세션은 검토 가능한 수준으로 구체화된 설계안으로 끝나야 합니다. 예를 들면 다음이 포함되어야 합니다.

• 목표와 사용자
• 범위 경계
• 핵심 결정 사항
• 열려 있는 리스크나 가정
• 구현 계획으로 넘어갈 수 있을 정도의 구체성

결과물이 느슨한 아이디어 목록에 그친다면, 세션이 너무 이르게 끝난 것입니다.

Requirements Planning을 위한 brainstorming 사용법

Requirements Planning을 위한 brainstorming에서는 이 skill을 스펙 작성 전 단계로 사용하면 좋습니다.

1. 문제와 제약을 명확히 한다
2. 설계 또는 요구사항의 형태를 잡는다
3. 승인을 받는다
4. 스펙을 작성한다
5. 필요하면 spec reviewer 프롬프트 템플릿을 실행한다

이 용도는 이 skill이 특히 강한 영역 중 하나입니다. 기획이 굳어지기 전에 범위 드리프트와 모호함을 먼저 잡아낼 수 있기 때문입니다.

brainstorming skill FAQ

brainstorming skill은 큰 프로젝트에만 필요한가?

아니요. 이 skill은 “작은 작업은 설계를 건너뛰어도 된다”는 생각을 명확히 부정합니다. 아주 작은 변경이라면 설계도 짧을 수는 있지만, 설계 단계 자체는 여전히 중요합니다. 특히 겉보기엔 단순해 보이지만 실제로는 가정 검증이 빠지기 쉬운 변경에서 가치가 크게 드러납니다.

일반적인 brainstorming 프롬프트보다 더 낫나?

대체로 그렇습니다. 특히 목적이 아이디어 양산이 아니라, 실행 가능한 수준의 명확성 확보라면 더 그렇습니다. 일반적인 brainstorming 프롬프트는 선택지를 많이 만들어낼 수 있습니다. 반면 이 brainstorming skill은 맥락을 이해하고, 선택지를 좁히고, 승인 가능한 설계안을 만드는 식의 수렴적 사고가 필요할 때 더 적합합니다.

brainstorming skill은 초보자도 쓰기 쉬운가?

네. 특히 아직 기획 습관이 잡히지 않은 1인 개발자나 개인 빌더에게 유용합니다. 이 구조는 초보자가 자주 하는 실수, 즉 요구사항과 트레이드오프를 먼저 분명히 하지 않은 채 가장 그럴듯한 첫 아이디어를 바로 구현해버리는 문제를 보완해줍니다.

언제 brainstorming이 잘 맞지 않나?

다음 같은 경우에는 건너뛰거나 아주 짧게 가져가도 됩니다.

• 작업이 순전히 기계적이고 이미 완전히 명세되어 있는 경우
• 설계나 동작 결정을 해야 하는 상황이 아닌 경우
• 사용자가 이미 상세 스펙을 승인했고 실행만 필요할 경우

다만 이런 경우에도, 이 skill의 강한 게이트가 현재 워크플로와 충돌하지 않는지는 확인해야 합니다. 이 skill은 의도적으로 엄격하게 설계되어 있습니다.

이 skill이 코드를 생성하나?

아니요. 그리고 그건 의도된 동작입니다. brainstorming skill은 승인이 있기 전에는 구현 단계로 넘어가지 않도록 설계되어 있습니다. 코드 생성이 필요하다면, 먼저 이 skill로 설계를 정리한 뒤 승인 후에 planning 또는 implementation skill로 넘기세요.

visual companion이 꼭 있어야 가치가 있나?

아니요. 브라우저 경로는 선택 사항입니다. 텍스트만으로 진행하는 brainstorming 사용만으로도 요구사항, 범위, 기술적 트레이드오프 논의에서 대부분의 가치를 얻을 수 있습니다. 비주얼 도구의 진짜 효용은 의사결정 대상 자체가 시각적인 경우에 가장 큽니다.

brainstorming skill을 더 잘 활용하는 방법

brainstorming skill에 더 풍부한 프로젝트 맥락 주기

결과를 가장 빠르게 개선하는 방법은 논의를 실제 맥락에 단단히 연결하는 것입니다.

• 관련 파일이나 폴더
• 현재 동작 방식
• 최근 변경 사항
• 이미 알려진 기술적 제약
• 영향을 받는 사용자

이 skill 자체도 에이전트에게 먼저 프로젝트 맥락을 탐색하라고 지시합니다. 그 맥락이 어디에 있는지 사용자가 먼저 짚어주면 훨씬 좋아집니다.

제약 조건과 비목표를 초반에 명시하기

약한 brainstorming 결과물은 경계가 충분히 정의되지 않았을 때 자주 나옵니다. 무엇을 유지해야 하고 무엇을 피해야 하는지 초반부터 알려주세요.

• 하위 호환성
• 성능 한계
• 컴플라이언스 또는 보안 요구사항
• 일정 또는 인력 제약
• 명시적으로 범위 밖인 기능

이렇게 해야 더 좁고, 실제 의사결정에 도움이 되는 설계안이 나옵니다.

아이디어가 아니라 설계를 요청하기

구현 가능한 수준의 결과물을 원한다면, 그렇게 분명히 말하는 것이 좋습니다. brainstorming skill이 다음을 포함한 상태로 마무리되도록 요청하세요.

• 제안된 설계안
• 가정 사항
• 아직 해결되지 않은 질문
• 명시적인 승인 체크포인트

이렇게 하면 세션이 끝없이 아이디어만 뻗어나가는 방향을 피하고, 실제로 쓸 수 있는 산출물 쪽으로 수렴합니다.

visual brainstorming에는 더 강한 프롬프트 쓰기

비주얼 작업에서는 “목업 보여줘” 정도로만 말하지 마세요. 무엇을 비교해야 하는지 구체적으로 적는 편이 좋습니다.

Show two dashboard layout options for failed import alerts: one optimized for fast triage, one optimized for detail review. Keep the existing navigation shell. Highlight which option better supports keyboard-heavy operators.

이 정도로 써야 visual companion이 보기 좋은 화면이 아니라, 의사결정을 돕는 출력을 만들 가능성이 높아집니다.

가장 흔한 실패 패턴: 성급한 해결책 점프를 경계하기

가장 큰 실패 패턴은 문제를 제대로 이해하기도 전에 구현 세부사항으로 뛰어드는 것입니다. 그런 흐름이 보이면 세션을 이렇게 되돌리세요.

Pause implementation thinking. What assumptions are we making about the user workflow, edge cases, and scope boundaries?

이렇게 해야 brainstorming 가이드가 본래 목적에 맞게 유지됩니다.

첫 번째 결과물은 한 번의 리뷰 패스로 다듬기

초기 설계안이 나온 뒤에는 처음부터 다시 시작하기보다, 초점을 좁힌 수정 요청을 하는 편이 낫습니다.

• 무엇이 모호한가?
• 무엇이 과하게 설계되었는가?
• 무엇이 구현 계획 수립을 방해하는가?
• 승인을 위해 빠진 것은 무엇인가?

이때 저장소의 spec-document-reviewer-prompt.md가 특히 유용합니다. 겉모습을 다듬는 수준이 아니라, 실제 계획 수립을 막는 요소를 기준으로 리뷰 강도를 맞춰주기 때문입니다.

brainstorming 산출물은 작게 유지하되, 의사결정에는 충분해야 한다

흔한 실수 중 하나는 설계안에 불필요한 디테일을 과하게 불리는 것입니다. 더 좋은 brainstorming이 곧 더 긴 brainstorming을 뜻하지는 않습니다. 단순한 작업이라면 목적, 범위, 제약, 접근 방식, 승인 여부를 담은 몇 개의 짧고 밀도 있는 문단만으로도 충분할 수 있습니다. 기준은 문서 길이가 아니라, 다음 단계가 이전보다 덜 추측에 의존해도 되는 상태인지입니다.

brainstorming 뒤에는 spec review 단계를 붙이기

이 skill을 본격적으로 도입할 생각이라면, 생성된 스펙이나 설계를 후속 리뷰하는 단계를 함께 두는 것이 좋습니다. 포함된 reviewer 템플릿은 다음을 점검합니다.

• placeholders
• 모순
• 모호한 요구사항
• 지나치게 넓은 범위
• 요청되지 않은 복잡성

이 과정을 더하면 brainstorming skill은 단순히 채팅에서 끝나는 도구가 아니라, 실제 전달 워크플로 안에서 더 실용적인 도구가 됩니다.