GSD 소개
최근 Claude Code와 같은 AI 코딩 어시스턴트의 발전으로, 개발자가 원하는 것을 설명하기만 하면 AI가 알아서 코드를 생성해 주는 소위 바이브코딩(Vibecoding) 시대가 열렸습니다. 하지만 이러한 방식은 장난감 수준의 프로젝트를 넘어서는 순간 치명적인 한계에 부딪힙니다. AI의 컨텍스트 윈도우가 누적된 대화와 코드 조각들로 가득 차면서 코드의 품질이 급격히 떨어지는 컨텍스트 오염(Context Rot) 현상이 발생하기 때문입니다. 결국 AI는 전체적인 아키텍처를 잃어버리고 일관성 없는 코드를 뱉어내기 시작합니다.
개발자 TÂCHES가 구축한 GSD(Get Shit Done) 는 바로 이러한 문제를 근본적으로 해결하기 위해 탄생했습니다. GSD는 Claude Code, OpenCode, Gemini CLI, Codex 등의 AI CLI 도구를 위한 가볍고 강력한 메타 프롬프팅(Meta-prompting), 컨텍스트 엔지니어링 및 스펙 주도 개발(Spec-driven development) 시스템입니다. 복잡한 시스템의 얽힘을 개발자의 워크플로우가 아닌 GSD 내부 시스템으로 추상화하여, 개발자는 단지 몇 가지 명령어만으로 고품질의 결과물을 지속적으로 얻을 수 있습니다.
GSD는 단순히 프롬프트를 전달하는 것을 넘어, 하위 에이전트(Subagent) 오케스트레이션, XML 프롬프트 포맷팅, 엄격한 상태 관리(State management)를 백그라운드에서 처리합니다. 무의미한 엔터프라이즈급 롤플레잉이나 복잡한 설정 없이 시스템이 요구사항을 추출하고 검증하며, 개발자는 "그냥 잘 작동하는(It just works)" 개발 환경을 경험할 수 있습니다.
GSD vs. 일반적인 바이브코딩 비교
단순히 AI에게 "이러이러한 기능을 만들어줘"라고 지시하는 기존 방식과 GSD의 접근법은 명확한 차이가 있습니다. 기존의 일반적인 바이브코딩(Vibecoding) 방식은 컨텍스트 윈도우 내에 모든 요구사항과 이전 작업 내역이 계속 누적됩니다. 결국 AI는 엉뚱한 가정을 하거나 기존 코드를 망가뜨리는 환각(Hallucination) 상태에 빠지며, 규모가 커질수록 프로젝트가 붕괴됩니다.
이에 반해, GSD (Context Engineering) 방식은 프로젝트를 원자 단위(Atomic)의 페이즈로 쪼개고, 각 작업마다 완전히 비워진 200k 토큰의 새로운 컨텍스트(Fresh Context) 를 제공합니다. 시스템이 자동으로 상태를 추적하는 STATE.md 파일을 통해 AI가 현재 위치를 정확히 파악하도록 통제(Leash)하므로, 프로젝트가 아무리 커져도 코드 품질이 일정하게 유지됩니다.
GSD 워크플로우 및 상세 동작 / 명령어
GSD는 명확한 마크다운 파일들(PROJECT.md, ROADMAP.md, STATE.md, CONTEXT.md 등)을 통해 프로젝트의 상태를 관리하며, 크게 5단계의 모듈화된 파이프라인으로 작동합니다.
┌──────────────────────────────────────────────────┐
│ NEW PROJECT │
│ /gsd:new-project │
│ Questions -> Research -> Requirements -> Roadmap│
└─────────────────────────┬────────────────────────┘
│
┌──────────────▼─────────────┐
│ FOR EACH PHASE: │
│ │
│ ┌────────────────────┐ │
│ │ /gsd:discuss-phase │ │ <- Lock in preferences
│ └──────────┬─────────┘ │
│ │ │
│ ┌──────────▼─────────┐ │
│ │ /gsd:ui-phase │ │ <- Design contract (frontend)
│ └──────────┬─────────┘ │
│ │ │
│ ┌──────────▼─────────┐ │
│ │ /gsd:plan-phase │ │ <- Research + Plan + Verify
│ └──────────┬─────────┘ │
│ │ │
│ ┌──────────▼─────────┐ │
│ │ /gsd:execute-phase │ │ <- Parallel execution
│ └──────────┬─────────┘ │
│ │ │
│ ┌──────────▼─────────┐ │
│ │ /gsd:verify-work │ │ <- Manual UAT
│ └──────────┬─────────┘ │
│ │ │
│ Next Phase?────────────┘
│ │ No
└─────────────┼──────────────┘
│
┌───────────────▼──────────────┐
│ /gsd:audit-milestone │
│ /gsd:complete-milestone │
└───────────────┬──────────────┘
│
Another milestone?
│ │
Yes No -> Done!
│
┌───────▼──────────────┐
│ /gsd:new-milestone │
└──────────────────────┘
초기 설정 및 설치 (Getting Started)
GSD는 Mac, Windows, Linux 환경을 모두 지원하며, Node.js 환경에서 아래 명령어로 즉시 실행할 수 있습니다.
npx get-shit-done-cc@latest
프로젝트 초기화 (Initialize Project)
기존 코드베이스가 있는 프로젝트인지, 완전히 새로운 프로젝트인지에 따라 시작 방식이 다릅니다.
/gsd:new-project(새로운 프로젝트용)
새로운 프로젝트를 시작할 때 사용하는 단일 명령어 흐름입니다. 시스템은 사용자의 아이디어, 목표, 제약사항, 기술 선호도를 완전히 이해할 때까지 질문을 던집니다. 이후 병렬 에이전트가 도메인을 조사하고 V1과 V2의 요구사항을 분리하여 ROADMAP.md를 생성합니다. 개발자가 로드맵을 승인하면 본격적인 빌드 준비가 완료됩니다.
/gsd:map-codebase(기존 프로젝트용)
작업을 시작하기 전 병렬 에이전트를 생성하여 기존의 기술 스택, 아키텍처, 컨벤션 등을 완벽히 분석합니다. 이 과정을 거치면 이후의 계획 수립 단계에서 기존 패턴을 자동으로 로드합니다.
논의 단계 (Discuss Phase)
명령어:
/gsd:discuss-phase [페이즈 번호]
로드맵에 적힌 1~2줄의 짧은 설명을 실제 구현 가능한 수준으로 구체화하는 단계입니다. 시각적 기능(레이아웃, 인터랙션), API 통신(응답 형식, 에러 처리), 데이터 구조 등 모호한 부분(Gray areas)에 대해 시스템이 사용자에게 질문합니다. 여기서 결정된 내용들은 {phase_num}-CONTEXT.md 파일로 저장되며, 다음 단계의 리서치와 계획 수립의 명확한 가이드라인이 됩니다.
계획 단계 (Plan Phase)
명령어:
/gsd:plan-phase [페이즈 번호]
작성된 컨텍스트를 바탕으로 시스템이 구현 방법을 스스로 조사(Research)합니다. 이후 XML 구조로 이루어진 2~3개의 원자적(Atomic) 작업 계획을 생성합니다. 중요한 점은 생성된 계획이 초기 요구사항을 완벽히 충족하는지 검증(Verify)하며, 통과할 때까지 자체 루프를 돈다는 것입니다.
실행 단계 (Execute Phase)
┌────────────────────────────────────────────────────────────────────┐
│ PHASE EXECUTION │
├────────────────────────────────────────────────────────────────────┤
│ │
│ WAVE 1 (parallel) WAVE 2 (parallel) WAVE 3 │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Plan 01 │ │ Plan 02 │ → │ Plan 03 │ │ Plan 04 │ → │ Plan 05 │ │
│ │ │ │ │ │ │ │ │ │ │ │
│ │ User │ │ Product │ │ Orders │ │ Cart │ │ Checkout│ │
│ │ Model │ │ Model │ │ API │ │ API │ │ UI │ │
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
│ │ │ ↑ ↑ ↑ │
│ └───────────┴──────────────┴───────────┘ │ │
│ Dependencies: Plan 03 needs Plan 01 │ │
│ Plan 04 needs Plan 02 │ │
│ Plan 05 needs Plans 03 + 04 │ │
│ │
└────────────────────────────────────────────────────────────────────┘
명령어:
/gsd:execute-phase [페이즈 번호]
계획된 작업들을 실제 코드로 구현하는 핵심 단계로, 다음과 같은 특징이 있습니다:
- Fresh Context: 각 계획은 오염되지 않은 200k 토큰의 새로운 컨텍스트 환경에서 실행되어 AI의 성능 저하("이제 간결하게 대답하겠습니다"와 같은 현상)를 방지합니다.
- 병렬/순차 실행: 의존성이 없는 작업은 웨이브(Waves) 형태로 병렬 실행하고, 의존성이 있는 작업은 순차적으로 실행합니다.
- 원자적 커밋(Atomic Commits): 모든 작업은 완료될 때마다 개별적으로 커밋(Commit)되어 롤백과 추적이 용이합니다.
작업 결과 검증 (Verify Results)
작업이 끝나면 GSD 시스템은 "이메일로 로그인이 가능합니까?" 등과 같이 테스트 가능한 결과물을 추출하여 사용자에게 확인을 받습니다. 만약 문제가 있다면 자동으로 디버그 에이전트를 스폰하여 근본 원인을 진단하고 수정 계획을 생성하여 즉각적인 재실행을 준비합니다.
퀵 모드 (Quick Mode)
명령어:
/gsd:quick
빠르게 기능을 추가해야 할 때 유용한 기능입니다. 리서치나 계획 검증 같은 선택적 단계를 건너뛰어 속도를 높이면서도, GSD의 핵심인 '원자적 커밋'과 '상태 추적' 기능은 그대로 유지하여 속도와 안정성의 균형을 맞춥니다.
라이선스
GSD 프로젝트는 MIT 라이선스로 공개 및 배포 되고 있습니다.
GSD 사용자 가이드 문서
GSD 프로젝트 GitHub 저장소
이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다. 
파이토치 한국 사용자 모임
이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일
로 보내드립니다! (기본은 Weekly지만 Daily로 변경도 가능합니다.)
아래
쪽에 좋아요
를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~ 