MoodturnPost 
Superpowers 완벽가이드 3편: 처음 시작할 때 바뀌는 대화 흐름
요약
핵심 요지
- 문제 정의: 보통 코딩 에이전트는 요청을 받으면 너무 빨리 구현으로 들어가서, 아직 정해지지 않은 요구사항까지 사실처럼 받아들이기 쉽습니다
- 핵심 주장:
Superpowers1를 설치한 뒤 가장 크게 달라지는 것은 코드가 아니라 첫 대화의 흐름입니다 - 주요 근거:
using-superpowers2는 관련skill3 확인을 응답보다 먼저 요구하고,brainstorming4은 한 번에 하나씩 질문하며 설계 승인 전 구현을 막습니다 - 한계: 질문이 늘어나기 때문에 처음에는 느리게 느껴질 수 있습니다. 다만 그 느려짐은 재작업을 줄이기 위한 의도적인 단계입니다
문서가 설명하는 범위
- 설치 후 첫 대화에서 무엇이 달라지는지
- 왜 에이전트가 예전보다 더 많이 묻는지
- 설계와 계획이 대화에 끼어드는 이유
- 어떤 질문으로 시작하면 흐름을 더 잘 탈 수 있는지
읽는 시간: 10분 | 난이도: 초급
참고 자료
- obra/superpowers - GitHub README
- using-superpowers - SKILL.md
- brainstorming - SKILL.md
- Jesse Vincent - Superpowers: How I’m using coding agents in October 2025
바로 써먹는 시작 템플릿
설치가 끝났다면, 아래 문장만으로도 Superpowers의 첫 대화 흐름을 체감할 수 있습니다.
이 기능을 바로 구현하지 말고, 먼저 요구사항부터 좁혀주세요.대안 2~3개를 비교한 뒤 추천안을 제시해주세요.설계를 승인하기 전에는 코드를 쓰지 마세요.이 작업을 시작하기 전에 관련 skill이 있는지 먼저 확인해주세요.
TIP이 템플릿의 핵심은 더 영리한 문장을 쓰는 데 있지 않습니다.
에이전트가 바로 코딩하는 대신, 먼저 생각하고 묻고 정리하게 만드는 데 있습니다.
문제 상황
일반적인 코딩 에이전트와 대화하면 첫 몇 문장이 꽤 비슷하게 흘러갑니다.
사용자가 기능을 말하면 에이전트는 곧바로 구현 방향을 정하고, 종종 아직 확정되지 않은 조건까지 스스로 채워 넣습니다.
처음에는 이 속도가 편해 보입니다.
하지만 실제로는 이 단계에서 가장 많은 오해가 생깁니다.
- 요구사항이 아직 모호한데 구현이 먼저 시작됩니다
- 사용자의 의도가 하나로 좁혀지지 않았는데 구조가 먼저 결정됩니다
- 확인되지 않은 가정이 코드와 테스트에 섞입니다
- 구현이 빨라진 만큼 되돌리는 비용도 같이 커집니다
그래서 Superpowers가 바꾸는 첫 번째 대상은 모델의 능력이 아닙니다.
대화의 순서입니다.
무엇이 가장 먼저 달라질까요?
공식 README와 skill 문서를 함께 보면, 설치 후 가장 큰 변화는 아주 단순합니다.
에이전트가 더 이상 바로 코딩하지 않는다는 점입니다.
README는 이 흐름을 brainstorm -> plan -> implement로 설명합니다.
Jesse Vincent의 글도 이제는 별도 프롬프트를 붙여넣지 않아도, 프로젝트나 작업을 시작한다고 판단하면 먼저 계획 대화 쪽으로 기본값이 바뀐다고 설명합니다.
즉, 설치 전과 후의 차이는 이렇게 요약할 수 있습니다.
| 구분 | 설치 전 대화 | 설치 후 대화 |
|---|---|---|
| 첫 반응 | 바로 구현 제안 | 관련 skill부터 확인 |
| 질문 방식 | 필요한 만큼 한꺼번에 묻거나, 아예 안 묻기도 함 | 한 번에 하나씩 좁혀 감 |
| 설계 단계 | 생략되기 쉬움 | 승인 전까지 유지 |
| 구현 시작 | 비교적 빠름 | 설계와 계획 뒤에 시작 |
| 사용자의 느낌 | 빠르지만 불안정 | 조금 느리지만 설명 가능 |
핵심은 답변이 길어지는 것이 아닙니다.
작업을 시작하는 순서가 바뀌는 것입니다.
첫 대화는 왜 더 많이 묻게 될까요?
using-superpowers는 관련 skill이 있을 가능성이 조금이라도 있으면, 응답 전에 먼저 확인하라고 요구합니다.
이 규칙 하나만으로도 첫 대화의 리듬이 꽤 달라집니다.
예전에는 이런 흐름이 흔했습니다.
설치 전 대화 예시
사용자: 간단한 대시보드 페이지 만들어줘.에이전트: React 컴포넌트를 만들고 카드 4개를 배치하겠습니다.이 방식은 빠르지만, 실제로는 중요한 질문이 빠져 있습니다.
- 어떤 정보를 보여줘야 하는가
- 읽기 전용인가, 상호작용이 있는가
- 기존 프로젝트 패턴을 따라야 하는가
- 모바일 우선인가, 데스크톱 우선인가
반대로 Superpowers가 붙은 뒤에는 대화가 이런 식으로 바뀝니다.
설치 후 대화 예시
사용자: 간단한 대시보드 페이지 만들어줘.에이전트: 먼저 관련 skill이 있는지 확인하겠습니다. 이 페이지는 읽기 전용인가요, 아니면 필터와 정렬 같은 상호작용이 필요한가요?겉으로 보면 질문 하나가 늘어난 것뿐입니다.
하지만 실제로는 그 질문 하나가 나중의 구조와 테스트 방향을 바꿉니다.
질문이 많아지는 것이 왜 좋은가요?
brainstorming 문서는 아주 작은 작업도 설계 단계를 건너뛰지 말라고 요구합니다.
그리고 질문은 한 번에 많이 던지는 대신, 하나씩 좁혀 가라고 안내합니다.
이 방식이 좋은 이유는 두 가지입니다.
잘못된 확신을 늦춥니다
코딩 에이전트의 위험한 순간은 모를 때가 아니라, 대충 아는데 안다고 믿을 때입니다.
한 번에 하나씩 묻는 방식은 이 성급한 확신을 늦춥니다.
사용자가 흐름을 따라갈 수 있습니다
질문이 다섯 개, 여섯 개가 한 번에 쏟아지면 대답하는 사람도 대충 답하게 됩니다.
반대로 한 번에 하나씩 묻고 확인하면, 설계가 어디에서 좁혀지고 있는지 사용자도 따라갈 수 있습니다.
즉, 질문이 많아지는 것이 중요한 게 아닙니다.
질문이 더 구조화된다는 점이 중요합니다.
설계 승인은 왜 필요할까요?
brainstorming은 구현 전에 설계를 제시하고, 사용자 승인을 받으라고 요구합니다.
처음 쓰는 사람에게는 이 단계가 조금 과해 보일 수 있습니다.
하지만 바로 이 지점이 Superpowers의 핵심입니다.
코드를 빨리 쓰는 능력보다, 어떤 코드를 써야 하는지 합의하는 능력을 먼저 두기 때문입니다.
간단한 기능 하나도 실제로는 아래 순서를 거칩니다.
이 흐름은 느려 보이지만, 실제로는 뒤쪽 속도를 더 올립니다.
초반 합의가 선명할수록 구현 단계에서 뒤집는 일이 줄어들기 때문입니다.
사용자가 체감하는 변화는 무엇일까요?
설치 후 첫 세션에서 사용자가 바로 느끼는 변화는 보통 세 가지입니다.
예전보다 늦게 코드를 씁니다
이건 기능이 덜 좋은 것이 아니라, 더 많은 맥락을 확보한 뒤 시작한다는 뜻입니다.
README도 구현보다 앞에 brainstorm과 plan이 놓여 있다고 설명합니다.
질문의 성격이 달라집니다
“원하세요?” 수준의 피상적 질문보다, 범위를 줄이기 위한 질문이 많아집니다.
예를 들면 이런 식입니다.
- 이 기능의 성공 기준은 무엇인가
- 기존 구조를 유지해야 하는가
- 지금 필요한 최소 범위는 어디까지인가
대안 제시가 먼저 나옵니다
brainstorming은 접근 방식을 하나만 밀어붙이지 않고, 2~3개의 대안을 비교하게 만듭니다.
그래서 사용자는 구현 결과를 받기 전에 선택지를 먼저 보게 됩니다.
그렇다면 사용자는 어떻게 말해야 할까요?
좋은 소식은 복잡한 프롬프트가 필요 없다는 점입니다.
오히려 짧고 분명한 시작 문장이 더 잘 맞습니다.
좋은 시작 문장 예시
이 작업은 바로 구현하지 말고, 먼저 범위를 좁혀주세요.좋은 시작 문장 예시 2
대안을 2개 정도 비교한 뒤 추천안을 제시해주세요.좋은 시작 문장 예시 3
설계를 승인하기 전에는 코드 변경을 시작하지 마세요.이런 문장이 잘 먹히는 이유는, Superpowers가 이미 관련 skill을 먼저 찾고 따르는 흐름을 갖고 있기 때문입니다.
사용자는 복잡한 규칙을 외우기보다, 지금 무엇을 원하지 않는지만 분명히 말해도 충분한 경우가 많습니다.
느려진 게 아니라 앞당겨진 것입니다
처음 쓰는 분들은 종종 이렇게 느낍니다.
”예전보다 말이 많아졌고, 시작이 느려졌다.”
겉으로 보면 맞습니다.
하지만 실제로는 구현이 느려진 것이 아니라, 원래 뒤에서 터졌어야 할 문제가 앞에서 드러난 것입니다.
- 요구사항 충돌
- 범위 과대화
- 테스트 기준 부재
- 설계 미합의
이런 문제를 초반 대화에서 꺼내면 당장은 느려 보입니다.
하지만 구현 뒤에 다시 뜯어고치는 비용과 비교하면 훨씬 싸게 끝나는 경우가 많습니다.
그래서 Superpowers가 바꾸는 것은 답변 스타일이 아니라, 실패 시점입니다.
뒤늦은 실패를 앞당겨서, 더 작은 비용으로 고치게 만듭니다.
마무리
설치 뒤 첫 대화가 달라지는 이유는 간단합니다.
Superpowers는 코딩 에이전트에게 더 빨리 답하라고 가르치지 않고, 더 올바른 순서로 시작하라고 가르치기 때문입니다.
관련 skill 확인, 한 번에 하나씩 묻는 질문, 설계 승인, 계획 수립은 모두 같은 방향을 가리킵니다.
곧바로 코드를 뽑는 대신, 먼저 무엇을 만들고 있는지 분명히 하자는 방향입니다.
다음 글에서는 이 흐름을 한 단계 더 좁혀서, 왜 Superpowers가 구현보다 설계를 먼저 놓는지, 그리고 그 설계 대화가 실제로 어떻게 진행되는지를 이어서 설명하겠습니다.
Footnotes
공유
이 글이 도움이 되었다면 다른 사람과 공유해주세요!
