# Get Shit Done - 메타 프롬프트·명세 기반 개발 시스템 > Clean Markdown view of GeekNews topic #27622. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27622](https://news.hada.io/topic?id=27622) - GeekNews Markdown: [https://news.hada.io/topic/27622.md](https://news.hada.io/topic/27622.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-19T03:36:52+09:00 - Updated: 2026-03-19T03:36:52+09:00 - Original source: [github.com/gsd-build](https://github.com/gsd-build/get-shit-done) - Points: 12 - Comments: 1 ## Summary **Get Shit Done(GSD)**는 **명세 기반 개발(SDD)**을 자동화해 AI 코드 생성의 일관성과 품질을 유지하도록 돕는 경량 메타 프롬프트 시스템입니다. **컨텍스트 엔지니어링**과 **멀티 에이전트 오케스트레이션**을 결합해 코드 문맥 손실(context rot)을 방지하며, `/gsd:new-project` 등 간단한 명령으로 아이디어 정의부터 실행·검증까지의 전 과정을 자동화합니다. 복잡한 절차를 최소화하면서도 각 작업을 **원자적 Git 커밋**으로 관리해 추적성과 복구성을 확보합니다. ## Topic Body - **Claude Code**등에서 **명세 기반 개발(SDD)** 을 자동화하는 경량 시스템으로, 복잡한 워크플로 없이 프로젝트를 완성하도록 지원 - **컨텍스트 엔지니어링**과 **XML 기반 프롬프트 구조화**, **멀티 에이전트 오케스트레이션**을 통해 AI 코드 품질 저하(context rot)를 방지 - `/gsd:new-project`, `/gsd:plan-phase`, `/gsd:execute-phase` 등 명령으로 **아이디어 정의 → 계획 → 실행 → 검증**의 전체 개발 주기를 자동화 - 각 작업 단위별 **원자적 Git 커밋**과 병렬 실행(wave execution)으로 추적성과 효율성을 확보 - **Amazon, Google, Shopify, Webflow** 엔지니어들이 사용하는 도구로, AI 기반 개발의 신뢰성과 생산성을 높이는 시스템 --- ### 개요 - **Get Shit Done(GSD)** 는 **Claude Code, OpenCode, Gemini CLI, Codex, Copilot, Antigravity** 등 다양한 AI 개발 환경에서 작동하는 **경량 메타 프롬프트 및 컨텍스트 관리 시스템** - AI가 코드 작성 중 문맥 품질이 저하되는 **context rot** 문제를 해결하며, 명세 기반으로 일관된 결과를 생성 - Mac, Windows, Linux에서 모두 동작하며, `npx get-shit-done-cc@latest` 명령으로 설치 가능 ### 제작 배경 (Why I Built This) - 대규모 조직용 도구들이 불필요하게 복잡한 절차를 요구하는 문제를 해결하기 위해 제작 - GSD는 **복잡성은 시스템 내부에, 워크플로는 단순하게** 설계되어 있음 - 내부적으로 **컨텍스트 엔지니어링, XML 프롬프트 포맷팅, 서브에이전트 오케스트레이션, 상태 관리**를 수행 - 사용자는 단순한 명령만으로 프로젝트를 완성할 수 있음 ### 주요 기능 및 워크플로 (How It Works) - 전체 개발 과정은 **6단계**로 구성 1. **프로젝트 초기화**: 아이디어, 제약, 기술 스택 등을 질의 후 `PROJECT.md`, `ROADMAP.md` 등 생성 2. **디스커스 단계**: 구현 세부사항을 정의해 `CONTEXT.md` 생성 3. **플랜 단계**: 병렬 리서치와 계획 수립, XML 구조의 작업 단위 생성 4. **실행 단계**: 의존성 기반 **wave 병렬 실행**, 각 작업별 커밋 및 검증 5. **검증 단계**: 자동 테스트 및 사용자 확인, 실패 시 자동 수정 계획 생성 6. **반복 및 마일스톤 완료**: 각 단계 반복 후 릴리스 태깅 - **Quick Mode**는 단일 작업을 빠르게 처리하며, `--discuss`, `--research`, `--full` 플래그로 세부 제어 가능 ### 핵심 기술 (Why It Works) - **컨텍스트 엔지니어링**: 프로젝트 전반의 문맥을 파일 단위로 관리 (`PROJECT.md`, `REQUIREMENTS.md`, `STATE.md` 등) - **XML 프롬프트 포맷팅**: 각 작업을 명확히 정의하고 검증 절차를 포함 - **멀티 에이전트 오케스트레이션**: 리서치·계획·실행·검증 단계별 전문 에이전트 병렬 운영 - **원자적 Git 커밋**: 각 작업 단위별 커밋으로 추적성과 복구 용이성 확보 - **모듈형 설계**: 단계 추가·삽입·수정이 자유로워 유연한 프로젝트 관리 가능 ### 명령 체계 (Commands) - **핵심 워크플로**: `/gsd:new-project`, `/gsd:plan-phase`, `/gsd:execute-phase`, `/gsd:verify-work` - **UI 설계 지원**: `/gsd:ui-phase`, `/gsd:ui-review` - **코드베이스 분석**: `/gsd:map-codebase` - **프로젝트 관리**: `/gsd:add-phase`, `/gsd:insert-phase`, `/gsd:complete-milestone` - **유틸리티**: `/gsd:quick`, `/gsd:health`, `/gsd:stats`, `/gsd:debug`, `/gsd:note` 등 ### 설정 및 구성 (Configuration) - 설정 파일 `.planning/config.json`에서 **모드, 단계 세분화, 모델 프로필, 워크플로 에이전트, 병렬화, Git 브랜칭 전략** 등을 제어 - 모델 프로필은 `quality`, `balanced`, `budget`, `inherit` 중 선택 가능 - `workflow.research`, `workflow.plan_check`, `workflow.verifier` 등 토글로 품질·속도 조정 가능 ### 보안 및 문제 해결 (Security & Troubleshooting) - `.env`, `secrets/`, `*.pem`, `*.key` 등 민감 파일은 **Claude Code의 deny list**에 추가해 접근 차단 - 설치 후 명령 인식 오류 시 런타임 재시작 또는 재설치 권장 - Docker 환경에서는 `CLAUDE_CONFIG_DIR` 설정으로 경로 문제 해결 - `--uninstall` 옵션으로 모든 구성요소 제거 가능 ### 커뮤니티 및 라이선스 - OpenCode, Gemini CLI, Codex용 커뮤니티 포트 지원 - **MIT 라이선스**로 공개 - “Claude Code is powerful. GSD makes it reliable.” — Claude Code의 신뢰성을 강화하는 도구 ## Comments ### Comment 53319 - Author: neo - Created: 2026-03-19T03:36:53+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47417804) - 나는 예전에 **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** 순으로 반복하는 게 제일 나았음 - Apenwarr의 글 [“The AI Developer’s Descent Into Madness”](https://apenwarr.ca/log/20260316)를 보면, “에이전트가 자기 프레임워크를 만드는” 상황을 풍자적으로 표현했음 - 나는 Claude와 Codex를 결합한 **미니 프레임워크**를 직접 만들었음 Claude 혼자 낸 오류를 Codex가 잡아주는 걸 보면, 단일 에이전트에 전적으로 맡길 수는 없다고 느낌 - 나는 **시각적 스펙 설계** 방식을 씀 앱의 화면 흐름을 이미지로 설계하고, 그걸 구조화된 markdown으로 내보내면 LLM이 화면 단위로 문맥을 이해함 텍스트 기반 스펙보다 **누락된 상태나 오류 흐름**을 미리 잡을 수 있음 - 이런 메타 프레임워크는 결국 **.vimrc나 .emacs.d** 같은 개인화 도구에 불과함 만든 사람에게는 유용하지만, 다른 사람에게는 쓸모없게 느껴짐 - 나는 **Spec-Driven 시스템**은 실패할 운명이라고 봄 영어로 쓴 스펙은 실제 코드와 동작을 연결하지 못함 이미 이 문제는 **자동화된 테스트**로 해결되어 있음 시스템의 행동을 실행 가능한 테스트로 인코딩해야 함 LLM이 구현을 생성할 때도 테스트를 먼저 작성하고, **mutation testing**으로 일관성을 검증해야 함 관련 내용을 [이 글](https://www.joegaebel.com/articles/principled-agentic-software-development)과 [GitHub 예제](https://github.com/JoeGaebel/outside-in-tdd-starter)에 정리했음 - 자연어 스펙은 확장성이 없지만, 이를 기반으로 **형식적 스펙(formal spec)** 을 만들면 가능성이 있음 결국 코드 형태로 표현되어야 함 - “A sufficiently detailed spec is code”라는 글도 있었는데, OpenAI의 결과를 재현하지 못했음 [링크](https://hn.algolia.com/?q=https%3A%2F%2Fhaskellforall.com%2F2026%2F03%2Fa-sufficiently-detailed-spec-is-code) 참고 - Spec Driven Development는 이름은 TDD와 비슷하지만, 방향은 정반대임 - 테스트를 스펙의 결과물로만 보는 건 **잘못된 논리**임 스펙은 테스트보다 훨씬 넓은 영역을 다룸 LLM이 테스트를 무시하거나 임의로 수정하는 경우도 많음 - 나는 개인용 **AI 시스템**을 쓰고 있는데, 공개할지 고민 중임 내 작업에 맞게 커스터마이즈되어 있어서, 공개 버전을 따로 유지보수하기가 부담스러움 다른 사람에게 직접 쓰게 하기보다는, 내 시스템을 참고해 **패턴만 공유**하고 싶음 - 유지보수는 꼭 할 필요 없음 AI 시대에는 단지 **영감과 아이디어**를 공유하는 것만으로도 충분히 가치 있음 - 팀 해커톤에서 GSD를 써봤는데, 코드베이스 이해에 너무 오래 걸렸고, **토큰 소모**도 심했음 에이전트 트랜스크립트 생성 중 오류도 잦았음 작은 기능 몇 개를 만드는 데는 과도한 도구였음 배운 점은 단순함 — **좋은 스펙 작성 + Plan mode 반복**이 훨씬 효율적이었음 - 나는 Beads의 디자인 제약이 답답해서 비슷한 툴을 직접 만들었음 내 버전은 **SQLite 기반**으로, GitHub와 양방향 동기화 기능을 추가했음 핵심은 모델과 먼저 대화하며 **명확한 스펙 파일**을 만드는 것임 파일이 있으면 모델이 잊지 않고, 세부 내용이 많을수록 출력 품질이 높아짐 Claude로 오랫동안 구상했던 아이디어를 프로토타입으로 구현했는데, 기대 이상으로 잘 나왔음 - “비밀 소스”라기엔 **RPI(research-plan-implement)** 는 이미 공식 문서에 있는 개념임 모델은 여전히 **확률적 시스템**이라 완전한 기억은 불가능함 마치 새로운 비법을 발견한 것처럼 포장하는 건 과장임 - 나는 [Superpowers](https://github.com/obra/superpowers)를 써봤고, 이번 GSD도 비슷해 보여서 비교가 궁금했음 - 둘 다 써봤는데, **GSD는 과도하게 복잡**하고 느림 Quick mode는 본래 목적을 잃게 만들고, Superpowers가 그 중간 지점으로 괜찮았음 - 구조화된 프롬프트는 확실히 도움이 됨 이런 프레임워크를 리포지토리에 넣고, AI에게 **프레임워크 자체를 개선**하게 시키면 창의적 작업에도 유용함 다만 이런 구조는 일시적인 해킹일 뿐, 모델이 충분히 학습되면 자연스럽게 사라질 것 같음 - Superpowers는 계획 단계에서 모든 코드를 써버리고, 하위 에이전트가 그걸 그대로 복사하는 방식이라 비효율적이었음 GSD는 이런 문제를 해결했지만, **단계가 너무 많아** 속도가 느림 - 나는 블로그를 Hugo에서 Astro로 옮기며 Superpowers를 테스트했음 Superpowers가 만든 스펙은 세세했지만 일부 기능(예: RSS, 분석)이 빠졌고, **병렬 마이그레이션**을 제안한 협업 스펙이 더 유연했음 최종적으로 Claude에게 두 스펙을 비교·통합시켜 완성본을 만들었음 [상세 비교](https://annjose.com/redesign/#two-specs-one-project) 참고 - 굳이 CLI 래퍼가 필요한지 모르겠음 그냥 Claude skills로도 충분히 구현 가능함 - GSD를 3개월간 집중적으로 써봤는데, 이전에 쓰던 **speckit보다 훨씬 완성도 높음** 복잡한 작업도 95%까지 자동으로 처리해줌 나머지 5%는 수동 테스트로 마무리함 이걸로 **SaaS 제품(whiteboar.it)** 까지 출시했음 모델 자체의 발전도 있었지만, **생산성 향상**은 확실했음 - 나도 비슷한 경험을 했음 FreshBooks 구독료가 아까워서 GSD로 **macOS Swift 앱**을 직접 만들었음 영수증 자동 추출, 카테고리 분류까지 **Anthropic API**로 구현했음 웹앱에서 시작했지만, 카메라 연동 등 기능을 추가하며 완전한 데스크톱 앱으로 발전했음 GSD 덕분에 개인용 회계 앱을 완성했음 - 결국 진짜 필요한 도구는 **토큰을 절약하는 도구**임 하지만 아직 그런 건 없음 Claude Code도 대형 프로젝트에서는 토큰을 너무 많이 씀 - 하나 추천하자면 [RTK AI](https://www.rtk-ai.app/)와 [GitHub 저장소](https://github.com/rtk-ai/rtk)가 있음 - “이 Markdown 파일 묶음”의 이름이 너무 **오글거림** - “Languages” 폴더 아래에 두면 좀 나았을 듯함 - 그래도 “gstack”보단 낫지 않음?