Superpowers + OpenSpec 통합 워크플로우
superpowers와 openspec은 상호 보완적인 장점을 가짐. 구현 크기에 따라 다른 워크플로우 적용이 핵심.
각 도구의 강점
| 도구 | 강점 |
|---|---|
| superpowers | 심층적인 브레인스토밍, TDD, 동시 구현 |
| openspec | 사양을 항상 최신 상태로 유지 (main spec + delta spec) |
OpenSpec의 spec 구조
- main spec: 현재 프로젝트의 전체 사양
- delta spec: 이번 변경에 대한 사양 (구현 완료 후 main spec에 반영)
1. 규모가 큰 구현/수정
초기 구현, 큰 기능 추가, 기존 구현의 큰 변경.
1.1 superpowers로 구현 진행
/superpowers:brainstorming → 구현 방향 논의
/superpowers:write-plan → 구체적인 구현 계획 작성
/superpowers:execute-plan → 구현 실행
1.2 openspec으로 사양 동기화
/opsx:propose → superpowers plan 기반으로 사양 생성, tasks 모두 완료 처리
/opsx:archive → delta spec을 main spec에 동기화
이미 구현되어 있으므로
/opsx:apply는 건너뛰고 바로 archive.
2. 규모가 크진 않지만 별도 사양이 필요한 구현
기존 OpenSpec 워크플로우 그대로 사용:
/opsx:propose → /opsx:apply → /opsx:archive
superpowers의 심층적인 계획 단계가 필요 없을 정도의 규모지만, 사양은 남겨야 하는 경우.
3. 규모가 작은 구현/수정
별도 사양을 작성하기엔 번거로운 작은 수정들.
문제
- 사양 반영 없이 누적 → 에이전트가 원하는 방향과 다른 제안
- 프로젝트 중후반부로 갈수록 복잡성 증가
- 이전 자료 찾아서 인지시켜야 함 → 시간/토큰 낭비
해결: spec-patch 커맨드
작은 수정 후 사양에 반영하는 커맨드:
정리
| 변경 크기 | 워크플로우 |
|---|---|
| 큰 수정 | superpowers로 계획·실행 → openspec으로 spec 동기화 |
| 중간 수정 | openspec 워크플로우 (/opsx:propose → apply → archive) |
| 작은 수정 | 바로 수정 → spec-patch로 동기화 |
핵심 인사이트
사양 유지에 따른 토큰 소모는 있지만, 프로젝트 중후반부로 갈수록 사양 없이 진행하는 쪽이 더 큰 소모를 만들 수 있다.
에이전트가 이전 결정을 모르면 시행착오가 반복되고, 그때마다 다시 맥락을 설명하면서 시간과 토큰 소모, 그리고 우리의 피로도가 누적된다.