▲

Get Shit Done - 메타 프롬프트·명세 기반 개발 시스템

 (github.com/gsd-build)
3P by GN⁺ 14시간전 | ★ favorite | 댓글 1개
  • 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의 신뢰성을 강화하는 도구
▲
GN⁺ 14시간전  [-]
Hacker News 의견들

  • 나는 예전에 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”를 보면, “에이전트가 자기 프레임워크를 만드는” 상황을 풍자적으로 표현했음
    • 나는 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) 는 이미 공식 문서에 있는 개념임
      모델은 여전히 확률적 시스템이라 완전한 기억은 불가능함
      마치 새로운 비법을 발견한 것처럼 포장하는 건 과장임

  • 나는 Superpowers를 써봤고, 이번 GSD도 비슷해 보여서 비교가 궁금했음

    • 둘 다 써봤는데, 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도 대형 프로젝트에서는 토큰을 너무 많이 씀

  • “이 Markdown 파일 묶음”의 이름이 너무 오글거림

    • “Languages” 폴더 아래에 두면 좀 나았을 듯함
    • 그래도 “gstack”보단 낫지 않음?
답변달기