Superpowers 완벽가이드 5편: 큰 작업을 작은 계획으로 나누는 구조

요약#

참고 자료#

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

바로 써먹는 시작 템플릿#

설계 다음 단계에서 계획을 더 선명하게 만들고 싶다면, 아래 문장으로 시작하면 됩니다.

• 이 설계를 구현 계획으로 쪼개주세요.
• 각 단계는 2~5분 안에 끝날 정도로 잘게 나눠주세요.
• 파일 경로, 테스트, 검증 명령까지 포함해주세요.
• 큰 단계가 아니라 바로 실행 가능한 체크리스트로 정리해주세요.

TIP

writing-plans의 핵심은 멋진 계획 문서를 만드는 데 있지 않습니다.
실제로 손을 대야 할 작업을 더 이상 추측하지 않아도 되게 만드는 데 있습니다.

문제 상황#

설계가 끝나면 많은 사람이 안도합니다.
무엇을 만들지 정했으니, 이제 구현만 하면 된다고 생각하기 쉽습니다.

하지만 실제로는 이 지점에서 또 다른 문제가 시작됩니다.
설계가 아무리 좋아도, 구현 단위가 너무 크면 다시 모호함이 돌아오기 때문입니다.

• 어디부터 손대야 하는지 애매합니다
• 파일을 어떻게 나눌지 중간에 다시 흔들립니다
• 테스트를 언제 쓰는지가 뒤로 밀립니다
• 커밋 단위가 커져서 되돌리기 어렵습니다
• 구현자가 중간에 스스로 해석을 추가하게 됩니다

그래서 Superpowers는 설계 다음에 곧바로 구현을 두지 않습니다.
그 사이에 writing-plans를 넣어서, 큰 작업을 작고 검증 가능한 단계로 바꾸게 만듭니다.

왜 계획을 잘게 나눌까요?#

공식 README는 설계 뒤에 writing-plans가 오고, 그 다음에 구현이 이어진다고 설명합니다.
이 순서가 중요한 이유는 간단합니다.

설계는 방향을 정하지만, 계획은 움직이는 단위를 정합니다.
방향만 있고 단위가 없으면, 구현은 다시 감각과 추측에 의존하게 됩니다.

writing-plans가 강조하는 핵심은 다음과 같습니다.

• 각 단계는 2~5분 단위의 한 행동이어야 합니다
• 정확한 파일 경로가 있어야 합니다
• 테스트와 검증 명령이 포함되어야 합니다
• 커밋도 계획에 들어가야 합니다

즉, 계획은 “이제 구현하면 됩니다”라는 선언이 아닙니다.
어디를 어떻게 바꾸고 무엇으로 확인할지를 미리 확정하는 단계입니다.

writing-plans는 실제로 무엇을 할까요?#

writing-plans skill은 구현 계획을 그냥 할 일 목록처럼 쓰지 않습니다.
문서를 보면 목표, 아키텍처, 기술 스택, 파일 구조, 작업 단계, 테스트, 커밋까지 포함하는 구조를 요구합니다.

큰 흐름은 이렇게 이해하면 됩니다.

이 흐름에서 핵심은 “계획도 구현처럼 구체적이어야 한다”는 점입니다.
추상적인 계획은 구현자에게 다시 해석 부담을 넘기기 때문입니다.

왜 파일 구조를 먼저 정할까요?#

writing-plans 문서는 작업을 나누기 전에 파일 구조부터 정리하라고 요구합니다.
무엇을 만들기 전에 어디에 둘지를 먼저 정하라는 뜻입니다.

이 단계가 중요한 이유는 파일 경계가 곧 책임 경계가 되기 때문입니다.

• 어떤 파일이 무엇을 맡는지 분명해집니다
• 같이 바뀌는 코드가 어디에 있어야 하는지 드러납니다
• 하나의 파일이 너무 많은 일을 하지 않도록 제어할 수 있습니다
• 구현 단계에서 “일단 여기 넣자”가 줄어듭니다

즉, 파일 구조는 나중에 정리할 정리 작업이 아닙니다.
계획 단계에서 이미 설계 결정을 잠그는 역할을 합니다.

왜 2~5분 단위가 중요할까요?#

이 부분이 Superpowers에서 가장 흥미로운 지점 중 하나입니다.
writing-plans는 각 단계를 아주 작게 쪼개라고 요구합니다.

예를 들면 이런 식입니다.

• 실패하는 테스트를 작성하기
• 테스트가 실제로 실패하는지 실행하기
• 최소 구현 추가하기
• 테스트가 통과하는지 확인하기
• 커밋하기

중요한 점은, 이 다섯 개가 한 덩어리가 아니라 각각 한 단계라는 점입니다.

작은 단위가 좋은 이유는 분명합니다.

왜 테스트까지 계획에 넣을까요?#

많은 계획 문서는 기능 단계만 적고 테스트는 마지막에 밀어둡니다.
하지만 writing-plans는 처음부터 테스트를 단계 안에 넣습니다.

공식 문서가 이 구조를 강조하는 이유는 분명합니다.
Superpowers 전체 철학이 TDD³, 검증, 증거 중심 흐름 위에 있기 때문입니다.

계획에 테스트가 들어가면 좋은 점은 다음과 같습니다.

• 구현보다 앞서 성공 기준이 보입니다
• “됐는지 아닌지”를 말로 다투지 않게 됩니다
• 구현자 마음대로 완료 선언하기 어려워집니다
• 다음 단계로 넘어갈 근거가 분명해집니다

그래서 Superpowers는 테스트를 구현 뒤의 선택 사항으로 두지 않습니다.
계획 안에 미리 끼워 넣어서, 구현 전체를 그 기준에 맞추게 만듭니다.

왜 커밋까지 계획에 넣을까요?#

처음 보면 조금 과하다고 느껴질 수 있습니다.
하지만 writing-plans는 frequent commits를 매우 강하게 강조합니다.

이유는 단순합니다.

• 커밋 단위가 작아야 되돌리기 쉽습니다
• 어떤 변화가 어느 단계와 연결되는지 분명해집니다
• 코드 리뷰가 더 쉬워집니다
• 실패한 실험을 버리기가 쉬워집니다

즉, 커밋은 작업이 끝난 뒤의 정리 버튼이 아닙니다.
작업 단위를 분리하는 경계선입니다.

Superpowers는 이 경계선까지 계획 단계에서 미리 정해두려 합니다.
그래야 구현자가 나중에 감으로 뭉뚱그려 커밋하지 않게 됩니다.

좋은 계획은 어떻게 생겼을까요?#

writing-plans 문서를 보면 좋은 계획의 기준은 꽤 선명합니다.

좋은 계획의 특징

• exact file paths가 있습니다
• 단계마다 한 행동만 들어 있습니다
• 테스트와 검증 명령이 포함됩니다
• 기대 결과가 적혀 있습니다
• 커밋 단위가 보입니다
• 큰 덩어리 대신 체크박스 단위로 추적할 수 있습니다

반대로 좋지 않은 계획은 보통 이렇습니다.

나쁜 계획의 예

1
- 로그인 기능 구현
2
- 테스트 추가
3
- 검증

이건 계획처럼 보이지만 실제로는 제목만 있는 상태에 가깝습니다.
무엇을 어디에서 어떻게 바꾸는지, 무엇으로 확인하는지가 비어 있기 때문입니다.

계획이 구체적일수록 구현은 쉬워질까요?#

보통은 그렇습니다.
그리고 Superpowers가 바로 그 점을 노립니다.

구현이 어려운 이유는 종종 코딩 실력보다, 모호한 계획 때문입니다.
무엇을 해야 할지 모호하면, 구현자는 그 빈칸을 매번 자기 판단으로 채워야 합니다.

반대로 계획이 선명하면 구현은 더 단순한 작업이 됩니다.

• 어느 파일을 만질지 압니다
• 어떤 테스트부터 써야 할지 압니다
• 어떤 명령으로 검증할지 압니다
• 어디까지가 한 단계인지 압니다

Jesse Vincent의 글이 설계 뒤에 바로 계획을 놓는 것도 같은 맥락입니다.
좋은 계획이 있으면, 이후의 서브에이전트나 실행 흐름이 더 오래 흔들리지 않고 갈 수 있기 때문입니다.

마무리#

Superpowers가 큰 작업을 작은 계획으로 나누는 이유는 단순합니다.
좋은 설계만으로는 아직 구현이 안전해지지 않기 때문입니다.

writing-plans는 설계를 실행 가능한 작업 단위로 번역합니다.
파일 구조를 정하고, 단계를 2~5분 단위로 나누고, 테스트와 검증과 커밋까지 계획 안에 포함시킵니다.

다음 글에서는 이 계획을 실제 구현으로 옮기는 단계, 즉 subagent-driven-development, TDD, 코드 리뷰가 어떻게 이어지는지 설명하겠습니다.