나는 예전에 Plan mode와 Superpowers를 함께 썼지만, 결국 Plan mode만으로 충분하다고 느꼈음
이런 프레임워크들은 리서치가 필요한 fire-and-forget 작업에는 좋지만, 토큰을 10배 이상 소모하는 느낌이었음
결과물의 품질 차이도 크지 않아 Max plan 한도에 자주 걸렸음
나는 Superpowers의 brainstorm·design·implementation planning 기능을 가져와 Ralph 기반 구현 레이어에 붙였음
구현 계획이 끝나면 내 입력을 묻지 않고 자동으로 진행되는데, Docker sandbox 안에서 실행해야 함
위험한 권한 설정 때문이지만, 어차피 그게 더 안전하다고 생각함
지금은 잘 작동하고 생산성도 높지만, 이건 여정의 중간 단계 같음
나는 반대로 Plan mode에서 Superpowers로 옮겼음
최신 버전 발표를 보고 다시 써봤는데, cross-check와 self-review가 여러 층으로 되어 있어서 결과가 더 안정적이었음
수동으로 할 수도 있지만, Superpowers가 그 과정을 자동화해줘서 훨씬 편했음
같은 작업을 GSD와 Plan Mode로 테스트했는데, Plan Mode는 20분 만에 기본 구현까지 끝냈고, GSD는 몇 시간 걸렸음
GSD는 프로젝트 전체 맥락을 고려한 코드였고, Plan Mode는 MVP 수준으로 딱 필요한 만큼만 구현했음
워크플로우나 작업 규모에 따라 장단이 뚜렷함
GitHub Copilot의 Plan mode가 최근 plan memory 추가 이후 이상하게 변했음
출력이 장황해지고 세부 내용은 오히려 모호해졌음
“design”, “figure out” 같은 단계만 늘어나고, 후속 질문 없이 바로 구현으로 넘어감
나도 비슷한 경험을 했음. 일주일치 Claude 구독료와 API 크레딧을 다 태워서 500줄 정도의 코드만 얻었음
테스트를 조작하거나 엉뚱한 결과를 내기도 했음
결국 직접 수동으로 가이드하면서 MVP를 완성했는데, 그게 훨씬 효율적이었음
요즘 이런 meta 프레임워크가 너무 많지만, 실제로 생산성을 증명한 건 거의 못 봤음
대부분은 토큰 낭비이자 context window 오염만 일으킴
결국 단순하게, 필요한 정보만 주고 Plan → Code → Verify 순으로 반복하는 게 제일 나았음
나는 Claude와 Codex를 결합한 미니 프레임워크를 직접 만들었음
Claude 혼자 낸 오류를 Codex가 잡아주는 걸 보면, 단일 에이전트에 전적으로 맡길 수는 없다고 느낌
나는 시각적 스펙 설계 방식을 씀
앱의 화면 흐름을 이미지로 설계하고, 그걸 구조화된 markdown으로 내보내면 LLM이 화면 단위로 문맥을 이해함
텍스트 기반 스펙보다 누락된 상태나 오류 흐름을 미리 잡을 수 있음
이런 메타 프레임워크는 결국 .vimrc나 .emacs.d 같은 개인화 도구에 불과함
만든 사람에게는 유용하지만, 다른 사람에게는 쓸모없게 느껴짐
나는 Spec-Driven 시스템은 실패할 운명이라고 봄
영어로 쓴 스펙은 실제 코드와 동작을 연결하지 못함
이미 이 문제는 자동화된 테스트로 해결되어 있음
시스템의 행동을 실행 가능한 테스트로 인코딩해야 함
LLM이 구현을 생성할 때도 테스트를 먼저 작성하고, mutation testing으로 일관성을 검증해야 함
관련 내용을 이 글과 GitHub 예제에 정리했음
자연어 스펙은 확장성이 없지만, 이를 기반으로 형식적 스펙(formal spec) 을 만들면 가능성이 있음
결국 코드 형태로 표현되어야 함
“A sufficiently detailed spec is code”라는 글도 있었는데, OpenAI의 결과를 재현하지 못했음 링크 참고
Spec Driven Development는 이름은 TDD와 비슷하지만, 방향은 정반대임
테스트를 스펙의 결과물로만 보는 건 잘못된 논리임
스펙은 테스트보다 훨씬 넓은 영역을 다룸
LLM이 테스트를 무시하거나 임의로 수정하는 경우도 많음
나는 개인용 AI 시스템을 쓰고 있는데, 공개할지 고민 중임
내 작업에 맞게 커스터마이즈되어 있어서, 공개 버전을 따로 유지보수하기가 부담스러움
다른 사람에게 직접 쓰게 하기보다는, 내 시스템을 참고해 패턴만 공유하고 싶음
유지보수는 꼭 할 필요 없음
AI 시대에는 단지 영감과 아이디어를 공유하는 것만으로도 충분히 가치 있음
팀 해커톤에서 GSD를 써봤는데, 코드베이스 이해에 너무 오래 걸렸고, 토큰 소모도 심했음
에이전트 트랜스크립트 생성 중 오류도 잦았음
작은 기능 몇 개를 만드는 데는 과도한 도구였음
배운 점은 단순함 — 좋은 스펙 작성 + Plan mode 반복이 훨씬 효율적이었음
나는 Beads의 디자인 제약이 답답해서 비슷한 툴을 직접 만들었음
내 버전은 SQLite 기반으로, GitHub와 양방향 동기화 기능을 추가했음
핵심은 모델과 먼저 대화하며 명확한 스펙 파일을 만드는 것임
파일이 있으면 모델이 잊지 않고, 세부 내용이 많을수록 출력 품질이 높아짐
Claude로 오랫동안 구상했던 아이디어를 프로토타입으로 구현했는데, 기대 이상으로 잘 나왔음
“비밀 소스”라기엔 RPI(research-plan-implement) 는 이미 공식 문서에 있는 개념임
모델은 여전히 확률적 시스템이라 완전한 기억은 불가능함
마치 새로운 비법을 발견한 것처럼 포장하는 건 과장임
둘 다 써봤는데, GSD는 과도하게 복잡하고 느림
Quick mode는 본래 목적을 잃게 만들고, Superpowers가 그 중간 지점으로 괜찮았음
구조화된 프롬프트는 확실히 도움이 됨
이런 프레임워크를 리포지토리에 넣고, AI에게 프레임워크 자체를 개선하게 시키면 창의적 작업에도 유용함
다만 이런 구조는 일시적인 해킹일 뿐, 모델이 충분히 학습되면 자연스럽게 사라질 것 같음
Superpowers는 계획 단계에서 모든 코드를 써버리고, 하위 에이전트가 그걸 그대로 복사하는 방식이라 비효율적이었음
GSD는 이런 문제를 해결했지만, 단계가 너무 많아 속도가 느림
나는 블로그를 Hugo에서 Astro로 옮기며 Superpowers를 테스트했음
Superpowers가 만든 스펙은 세세했지만 일부 기능(예: RSS, 분석)이 빠졌고, 병렬 마이그레이션을 제안한 협업 스펙이 더 유연했음
최종적으로 Claude에게 두 스펙을 비교·통합시켜 완성본을 만들었음 상세 비교 참고
굳이 CLI 래퍼가 필요한지 모르겠음
그냥 Claude skills로도 충분히 구현 가능함
GSD를 3개월간 집중적으로 써봤는데, 이전에 쓰던 speckit보다 훨씬 완성도 높음
복잡한 작업도 95%까지 자동으로 처리해줌
나머지 5%는 수동 테스트로 마무리함
이걸로 SaaS 제품(whiteboar.it) 까지 출시했음
모델 자체의 발전도 있었지만, 생산성 향상은 확실했음
나도 비슷한 경험을 했음
FreshBooks 구독료가 아까워서 GSD로 macOS Swift 앱을 직접 만들었음
영수증 자동 추출, 카테고리 분류까지 Anthropic API로 구현했음
웹앱에서 시작했지만, 카메라 연동 등 기능을 추가하며 완전한 데스크톱 앱으로 발전했음
GSD 덕분에 개인용 회계 앱을 완성했음
결국 진짜 필요한 도구는 토큰을 절약하는 도구임
하지만 아직 그런 건 없음
Claude Code도 대형 프로젝트에서는 토큰을 너무 많이 씀
Hacker News 의견들
나는 예전에 Plan mode와 Superpowers를 함께 썼지만, 결국 Plan mode만으로 충분하다고 느꼈음
이런 프레임워크들은 리서치가 필요한 fire-and-forget 작업에는 좋지만, 토큰을 10배 이상 소모하는 느낌이었음
결과물의 품질 차이도 크지 않아 Max plan 한도에 자주 걸렸음
구현 계획이 끝나면 내 입력을 묻지 않고 자동으로 진행되는데, Docker sandbox 안에서 실행해야 함
위험한 권한 설정 때문이지만, 어차피 그게 더 안전하다고 생각함
지금은 잘 작동하고 생산성도 높지만, 이건 여정의 중간 단계 같음
최신 버전 발표를 보고 다시 써봤는데, cross-check와 self-review가 여러 층으로 되어 있어서 결과가 더 안정적이었음
수동으로 할 수도 있지만, Superpowers가 그 과정을 자동화해줘서 훨씬 편했음
GSD는 프로젝트 전체 맥락을 고려한 코드였고, Plan Mode는 MVP 수준으로 딱 필요한 만큼만 구현했음
워크플로우나 작업 규모에 따라 장단이 뚜렷함
출력이 장황해지고 세부 내용은 오히려 모호해졌음
“design”, “figure out” 같은 단계만 늘어나고, 후속 질문 없이 바로 구현으로 넘어감
테스트를 조작하거나 엉뚱한 결과를 내기도 했음
결국 직접 수동으로 가이드하면서 MVP를 완성했는데, 그게 훨씬 효율적이었음
요즘 이런 meta 프레임워크가 너무 많지만, 실제로 생산성을 증명한 건 거의 못 봤음
대부분은 토큰 낭비이자 context window 오염만 일으킴
결국 단순하게, 필요한 정보만 주고 Plan → Code → Verify 순으로 반복하는 게 제일 나았음
Claude 혼자 낸 오류를 Codex가 잡아주는 걸 보면, 단일 에이전트에 전적으로 맡길 수는 없다고 느낌
앱의 화면 흐름을 이미지로 설계하고, 그걸 구조화된 markdown으로 내보내면 LLM이 화면 단위로 문맥을 이해함
텍스트 기반 스펙보다 누락된 상태나 오류 흐름을 미리 잡을 수 있음
만든 사람에게는 유용하지만, 다른 사람에게는 쓸모없게 느껴짐
나는 Spec-Driven 시스템은 실패할 운명이라고 봄
영어로 쓴 스펙은 실제 코드와 동작을 연결하지 못함
이미 이 문제는 자동화된 테스트로 해결되어 있음
시스템의 행동을 실행 가능한 테스트로 인코딩해야 함
LLM이 구현을 생성할 때도 테스트를 먼저 작성하고, mutation testing으로 일관성을 검증해야 함
관련 내용을 이 글과 GitHub 예제에 정리했음
결국 코드 형태로 표현되어야 함
링크 참고
스펙은 테스트보다 훨씬 넓은 영역을 다룸
LLM이 테스트를 무시하거나 임의로 수정하는 경우도 많음
나는 개인용 AI 시스템을 쓰고 있는데, 공개할지 고민 중임
내 작업에 맞게 커스터마이즈되어 있어서, 공개 버전을 따로 유지보수하기가 부담스러움
다른 사람에게 직접 쓰게 하기보다는, 내 시스템을 참고해 패턴만 공유하고 싶음
AI 시대에는 단지 영감과 아이디어를 공유하는 것만으로도 충분히 가치 있음
팀 해커톤에서 GSD를 써봤는데, 코드베이스 이해에 너무 오래 걸렸고, 토큰 소모도 심했음
에이전트 트랜스크립트 생성 중 오류도 잦았음
작은 기능 몇 개를 만드는 데는 과도한 도구였음
배운 점은 단순함 — 좋은 스펙 작성 + Plan mode 반복이 훨씬 효율적이었음
나는 Beads의 디자인 제약이 답답해서 비슷한 툴을 직접 만들었음
내 버전은 SQLite 기반으로, GitHub와 양방향 동기화 기능을 추가했음
핵심은 모델과 먼저 대화하며 명확한 스펙 파일을 만드는 것임
파일이 있으면 모델이 잊지 않고, 세부 내용이 많을수록 출력 품질이 높아짐
Claude로 오랫동안 구상했던 아이디어를 프로토타입으로 구현했는데, 기대 이상으로 잘 나왔음
모델은 여전히 확률적 시스템이라 완전한 기억은 불가능함
마치 새로운 비법을 발견한 것처럼 포장하는 건 과장임
나는 Superpowers를 써봤고, 이번 GSD도 비슷해 보여서 비교가 궁금했음
Quick mode는 본래 목적을 잃게 만들고, Superpowers가 그 중간 지점으로 괜찮았음
이런 프레임워크를 리포지토리에 넣고, AI에게 프레임워크 자체를 개선하게 시키면 창의적 작업에도 유용함
다만 이런 구조는 일시적인 해킹일 뿐, 모델이 충분히 학습되면 자연스럽게 사라질 것 같음
GSD는 이런 문제를 해결했지만, 단계가 너무 많아 속도가 느림
Superpowers가 만든 스펙은 세세했지만 일부 기능(예: RSS, 분석)이 빠졌고, 병렬 마이그레이션을 제안한 협업 스펙이 더 유연했음
최종적으로 Claude에게 두 스펙을 비교·통합시켜 완성본을 만들었음
상세 비교 참고
그냥 Claude skills로도 충분히 구현 가능함
GSD를 3개월간 집중적으로 써봤는데, 이전에 쓰던 speckit보다 훨씬 완성도 높음
복잡한 작업도 95%까지 자동으로 처리해줌
나머지 5%는 수동 테스트로 마무리함
이걸로 SaaS 제품(whiteboar.it) 까지 출시했음
모델 자체의 발전도 있었지만, 생산성 향상은 확실했음
FreshBooks 구독료가 아까워서 GSD로 macOS Swift 앱을 직접 만들었음
영수증 자동 추출, 카테고리 분류까지 Anthropic API로 구현했음
웹앱에서 시작했지만, 카메라 연동 등 기능을 추가하며 완전한 데스크톱 앱으로 발전했음
GSD 덕분에 개인용 회계 앱을 완성했음
결국 진짜 필요한 도구는 토큰을 절약하는 도구임
하지만 아직 그런 건 없음
Claude Code도 대형 프로젝트에서는 토큰을 너무 많이 씀
“이 Markdown 파일 묶음”의 이름이 너무 오글거림