GSD (Get Shit Done) 심층 분석

서론

Ralph Wiggum 심층 분석에서 우리는 핵심 문제 하나를 알아보았습니다: Context Rot — 대화가 길어질수록 Claude의 컨텍스트 윈도우가 실패한 코드, 오래된 논의, 관련 없는 정보로 가득 차면서 출력 품질이 지속적으로 하락하는 현상입니다.

Ralph의 해결책은 "모든 것을 재시작"하는 것이었습니다: bash 무한 루프로 매번 완전히 새로운 Claude 인스턴스를 실행하고, 파일 시스템을 통해 상태를 전달합니다. 단순하고 효과적이지만, 명확한 한계도 있습니다 — 이것은 단지 하나의 방법론일 뿐, 프로젝트 이해도 없고, 단계별 계획도 없으며, 품질 검증도 없습니다. 스펙을 직접 작성하고, 작업을 직접 편성하고, "완료되었는지"를 직접 판단해야 합니다.

Chase AI가 영상에서 정확하게 요약한 것처럼: Ralph Loop은 극히 강력한 무기이지만, 대부분의 사람들에게 필요한 것은 하나의 무기가 아니라 전체 무기고입니다. Ralph 루프는 전적으로 사전 준비에 의존합니다: PRD가 충분히 좋은가? 기능 정의가 충분히 긴밀한가? "완료"가 어떤 모습인지 알고 있는가? 이 질문들에 대한 답이 정확하지 않다면, 루프를 아무리 많이 돌려도 garbage in, garbage out일 뿐입니다.

만약 단순히 Claude를 반복 실행하는 것이 아니라, 프로젝트를 진정으로 이해하고 안정적으로 코드를 전달하는 시스템을 원한다면 어떨까요?

이것이 바로 **GSD (Get Shit Done)**가 하는 일입니다.

GSD란 무엇인가

GSD의 창시자는 TÂCHES (GitHub: glittercowboy)이며, 독립 개발자입니다. 그의 동기는 매우 직접적입니다:

"나는 50명 규모의 소프트웨어 회사가 아닙니다. 기업 드라마를 하고 싶지 않습니다. 나는 그저 좋은 것을 만들고 싶은 크리에이티브한 사람일 뿐입니다."

그의 라이브 스트리밍에서 TÂCHES는 충격적인 사실을 보여주었습니다: 그는 코드를 직접 작성하지 않습니다. 그는 GSD를 사용하여 4시간 만에 완전한 macOS 네이티브 음악 생성 앱(Sample Digger)을 처음부터 구축했으며, 전 과정에서 코드를 직접 작성하지 않았습니다. 그의 자기 포지셔닝은 프로그래머가 아니라 "고위 프로젝트 매니저"입니다 — 비전을 설명하고, 핵심 결정을 내리고, 결과를 검증합니다. GSD는 이러한 작업 방식을 가능하게 합니다.

"This has like 100x'd my ability to make cool shit with Claude Code because it's just created this systematization."

—— TÂCHES

다른 스펙 주도 개발 도구들 — BMAD, SpecKit — 은 각각의 가치가 있지만, 복잡한 기업 워크플로우를 도입하는 경향이 있습니다: 스프린트 세레모니, 스토리 포인트, 이해관계자 싱크. 독립 개발자나 소규모 팀에게 이러한 프로세스 자체가 부담입니다. Chase AI가 평가한 것처럼: "It's not enterprise theater. We understand that you're just one person, you just want some sort of scaffolding around Claude Code to make sure it executes the tasks it says it's going to execute in an effective way."

GSD의 설계 철학은 복잡성을 시스템 안에 숨기는 것입니다. 사용자는 몇 가지 간단한 명령만 필요하고, 시스템이 배후에서 모든 컨텍스트 관리, 작업 편성, 품질 검증을 처리합니다. 프로젝트 출시 한 달 만에 약 3,000개의 GitHub 스타와 14,000건의 npm 설치를 달성했으며, TÂCHES는 거의 매일 15-20회 업데이트합니다.

GSD의 도구 생태계 내 위치

이 표는 핵심적인 트레이드오프를 보여줍니다: Ralph는 최저의 시스템 복잡도로 최고의 실행 자율성을 교환했습니다 — 시작한 후 잠자러 갈 수 있습니다; 반면 GSD는 높은 시스템 복잡도로 계획 품질과 인간 검증을 교환했습니다 — 각 단계마다 개입할 기회가 있습니다. SpecKit과 BMAD는 중간 지대에 위치하며, 계획 능력을 제공하지만 GSD의 컨텍스트 엔지니어링과 Ralph의 자율 실행이 부족합니다.

GSD와 Ralph는 모순되지 않습니다. GSD는 Ralph의 핵심 원칙 — 신선한 컨텍스트, 파일을 진실의 원천으로 사용 — 을 계승하되, 그 위에 완전한 프로젝트 이해 및 실행 체계를 구축했습니다. Ralph가 "AI에게 작업을 주고 반복 시도하게 하는 것"이라면, GSD는 "당신이 무엇을 원하는지 이해하고, 어떻게 할지 연구하고, 어떻게 단계별로 나눌지 계획하고, 실행하고 검증하는 것"입니다.

Chase AI의 요약이 매우 정확합니다: Ralph 루프는 당신이 완전한 청사진을 가지고 온다고 가정합니다 — GSD는 그 청사진을 구축하는 것을 도와줍니다. GSD는 당신의 반쯤 형성된 아이디어를 받아, 깊이 있게 질문하고, 대신 조사하고, 완전한 PRD를 생성하고, 이를 원자적 작업으로 분해한 다음, 프로젝트를 처음부터 끝까지 전달합니다. 그리고 코드를 실행할 때는 Ralph 루프를 강력하게 만드는 바로 그 기본 원칙을 사용합니다: 서브에이전트의 신선한 컨텍스트와 가능한 한 작고 정확한 작업.

핵심 워크플로우

GSD의 워크플로우는 논의 → 계획 → 실행 → 검증의 순환이며, 각 단계마다 명확한 입력과 출력이 있습니다.

1. 프로젝트 초기화

/gsd:new-project

하나의 명령으로 전체 프로세스가 시작됩니다. 시스템은 다음을 수행합니다:

1. 질문 — 당신의 아이디어를 완전히 이해할 때까지 계속 질문합니다 (목표, 제약, 기술 선호, 엣지 케이스)
2. 조사 — 병렬 에이전트를 파견하여 관련 분야를 조사합니다 (선택 사항이지만 권장)
3. 요구사항 추출 — v1, v2, 범위 밖의 내용을 구분합니다
4. 로드맵 — 요구사항에 대응하는 단계별 계획을 생성합니다

로드맵을 승인하면 구축이 시작됩니다. TÂCHES의 경험에 따르면: 초기 설명이 상세할수록 시스템의 추가 질문이 줄어들고, 모호할수록 질문이 늘어납니다. 그는 시작 전에 대략적인 비전 문서를 준비할 것을 권장합니다 — 기술 스택이나 구현 세부사항을 알 필요는 없고, 원하는 것을 설명하기만 하면 됩니다.

산출물 파일: PROJECT.md, REQUIREMENTS.md, ROADMAP.md, STATE.md

기존 코드베이스가 있나요? 먼저 /gsd:map-codebase를 실행하면, 시스템이 병렬 에이전트를 파견하여 기술 스택, 아키텍처, 관례, 잠재적 문제를 분석합니다. 이후 /gsd:new-project가 기존 코드베이스를 기반으로 계획을 수립할 수 있습니다.

2. 논의 단계

/gsd:discuss-phase 1

로드맵의 각 단계에는 한두 줄의 설명만 있으며, 이것만으로는 원하는 것을 구축하기에 충분하지 않습니다. 논의 단계의 역할은 조사와 계획 전에 구현 선호도를 포착하는 것입니다.

시스템은 현재 단계를 분석하고, "회색 지대" — 여러 가지 합리적인 구현 방식이 있는 의사결정 포인트 — 를 식별합니다:

• 시각적 기능 → 레이아웃, 인터랙션, 빈 상태 처리
• API/CLI → 응답 형식, 오류 처리, 상세 수준
• 콘텐츠 시스템 → 구조, 톤, 깊이, 플로우

여기서 내리는 모든 결정이 이후의 조사와 계획 품질에 직접 영향을 미칩니다. 이 단계를 건너뛸 수도 있지만 (시스템이 합리적인 기본값을 사용합니다), 심도 있는 논의를 하면 시스템이 기대에 더 부합하는 결과물을 구축할 수 있습니다.

산출물 파일: {phase}-CONTEXT.md

3. 계획 단계

/gsd:plan-phase 1

시스템은 다음을 수행합니다:

1. 조사 — 논의 단계의 결정을 지침으로 삼아 현재 단계를 어떻게 구현할지 조사합니다
2. 계획 — 2-3개의 원자적 작업 계획을 생성하며, XML 구조화 형식을 사용합니다
3. 검증 — 계획이 요구사항을 충족하는지 확인하고, 통과할 때까지 반복 수정합니다

중요한 설계 이념은 Goal-Backward Planning (목표 역추적 계획)입니다. "무엇을 구축해야 하는가"에서 출발하는 것이 아니라, "목표를 달성하기 위해 어떤 조건이 성립해야 하는가?"를 묻고 — 거기서 역으로 계획과 작업을 도출합니다. TÂCHES는 이 방식이 "출력 품질을 극적으로 향상시켰다"고 말합니다. 각 작업이 자신과 다른 작업의 관계를 이해하며, 단순한 할 일 목록이 아니기 때문입니다.

각 계획은 충분히 작아서 완전히 새로운 컨텍스트 윈도우에서 실행할 수 있습니다. 이것이 핵심입니다 — 품질 저하가 없습니다.

산출물 파일: {phase}-RESEARCH.md, {phase}-{N}-PLAN.md

4. 실행 단계

/gsd:execute-phase 1

시스템은 다음을 수행합니다:

1. 웨이브 실행 — 독립적인 작업은 병렬로 실행하고, 의존성이 있는 것은 순차적으로 실행합니다
2. 신선한 컨텍스트 — 각 계획은 완전히 새로운 200k 토큰 컨텍스트에서 실행되며, 누적된 쓰레기가 전혀 없습니다
3. 원자적 커밋 — 각 작업은 독립적으로 git commit합니다
4. 목표 검증 — 코드베이스가 단계에서 약속한 기능을 구현했는지 확인합니다

TÂCHES의 라이브 데모에서 그는 3개의 완전한 단계 개발을 완료했으며, 메인 컨텍스트 윈도우는 시종일관 24%를 유지했습니다. GSD Executor 서브에이전트는 1,000줄 미만의 컨텍스트만 로드하면 하나의 완전한 단계를 완수할 수 있습니다 — 10개의 계획을 연속으로 실행해도 컨텍스트는 여전히 50% 미만입니다. 이것은 Claude Code에서 직접 작업하는 경험과 완전히 다릅니다: 더 이상 "러시안 룰렛을 하면서, 언제 컨텍스트 윈도우의 벽에 부딪힐지 도박하는 것"이 아닙니다.

산출물 파일: {phase}-{N}-SUMMARY.md, {phase}-VERIFICATION.md

5. 검증 단계

/gsd:verify-work 1

자동화된 검증은 코드가 존재하는지, 테스트가 통과하는지 확인할 수 있습니다. 하지만 기능이 기대한 대로 작동하는지는 당신이 직접 확인해야 합니다.

시스템은 다음을 수행합니다:

1. 테스트 가능한 산출물 추출 — 지금 할 수 있어야 하는 일들의 목록을 나열합니다
2. 하나씩 검증 안내 — "이메일로 로그인할 수 있나요?" 예/아니오, 또는 문제 설명
3. 실패 자동 진단 — 디버그 에이전트를 파견하여 근본 원인을 찾습니다
4. 수정 계획 생성 — 바로 실행할 수 있는 수정 방안을 만듭니다

모두 통과하면 다음 단계로 진행합니다. 문제가 있으면 /gsd:execute-phase를 다시 실행하여 수정 계획을 실행합니다.

이것이 GSD와 Ralph 루프의 가장 큰 이념적 차이입니다: Ralph는 hands-off입니다 — 시작한 후 놓아두고 실행하게 합니다; GSD는 각 단계가 끝난 후 인간 검증 단계가 있습니다. Chase AI는 Ralph 루프가 "정복하러 가는 타입"이라고 지적했습니다 — 스스로 작동하며 뒤돌아보지 않습니다; GSD는 각 핵심 노드에서 개입하여 방향을 바로잡을 수 있도록 보장하며, 오류가 무인 감독 하에서 겹겹이 쌓이는 것을 방지합니다.

또한 GSD는 전용 디버그 프로세스도 제공합니다. 검증에서 문제가 발견되면, /gsd:debug가 격리된 디버그 서브에이전트를 시작합니다. 이 에이전트는 자체적인 가설-증거-해결 워크플로우를 가지고 있으며, 독립적인 디버그 문서를 생성하여 전체 조사 과정을 추적하고, 메인 컨텍스트를 오염시키지 않습니다.

산출물 파일: {phase}-UAT.md

순환 반복

/gsd:discuss-phase 2 → /gsd:plan-phase 2 → /gsd:execute-phase 2 → /gsd:verify-work 2
...
/gsd:complete-milestone → /gsd:new-milestone

각 단계는 완전한 논의 → 계획 → 실행 → 검증 순환을 거칩니다. 컨텍스트는 신선하게 유지되고, 품질은 일관되게 유지됩니다.

모든 단계가 완료되면 /gsd:complete-milestone이 마일스톤을 아카이브하고 버전을 표시합니다. 그런 다음 /gsd:new-milestone이 다음 버전의 구축을 시작합니다.

왜 효과적인가: 기술 원리

GSD의 안정성은 우연이 아닙니다. 그 뒤에는 네 가지 핵심 기술적 지원이 있습니다.

Context Engineering

Claude Code는 올바른 컨텍스트를 제공받을 때 매우 강력합니다. 대부분의 사람들은 올바른 컨텍스트를 어떻게 제공해야 하는지 모릅니다. GSD가 이 문제를 대신 처리합니다.

각 파일에는 Claude의 품질 저하 임계값에 기반한 크기 제한이 있습니다. 제한 이내로 유지하면 일관된 고품질 출력을 얻을 수 있습니다. 메인 컨텍스트 윈도우는 30-40%로 유지되며, 실제 작업은 서브에이전트의 완전히 새로운 200k 컨텍스트에서 수행됩니다.

Chase AI는 Context Rot에 대해 직관적인 설명을 했습니다: 컨텍스트 윈도우가 아무리 크더라도 — Sonnet, Opus, 심지어 백만 토큰 윈도우라도 — 앞부분의 토큰이 뒷부분보다 더 효과적입니다. 이것은 버그가 아니라 LLM의 고유한 특성입니다. Claude Code에 내장된 autocompact은 부분적으로만 완화할 수 있습니다. GSD의 방안은 더 철저합니다: 각 원자적 작업이 완전히 새로운 서브에이전트에서 실행되어, 모든 작업이 Claude의 최고 성능을 발휘할 수 있도록 보장합니다.

TÂCHES 자신의 데이터가 이를 뒷받침합니다: 그는 월 $200의 Max 플랜에서 매월 약 $30,000의 Opus 토큰을 소비합니다. 이것은 많아 보이지만, 각 작업이 신선한 컨텍스트에서 실행되기 때문에 재작업이 극히 드물고, 실제 효율은 저하된 컨텍스트에서 반복적으로 수정하는 것보다 훨씬 높습니다.

XML Prompt Formatting

각 계획은 Claude에 최적화된 구조화 XML입니다:

<task type="auto">
  <name>Create login endpoint</name>
  <files>src/app/api/auth/login/route.ts</files>
  <action>
    Use jose for JWT (not jsonwebtoken - CommonJS issues).
    Validate credentials against users table.
    Return httpOnly cookie on success.
  </action>
  <verify>curl -X POST localhost:3000/api/auth/login returns 200 + Set-Cookie</verify>
  <done>Valid credentials return cookie, invalid return 401</done>
</task>

정확한 지시, 추측 불필요, 검증이 각 작업에 내장되어 있습니다.

Multi-Agent Orchestration

각 단계는 동일한 패턴을 사용합니다: 가벼운 오케스트레이터가 전문화된 에이전트를 파견하고, 결과를 수집하며, 다음 단계로 라우팅합니다.

오케스트레이터는 절대로 무거운 작업을 하지 않습니다. 에이전트를 파견하고, 기다리고, 결과를 통합합니다. 결과적으로: 전체 단계를 실행할 수 있습니다 — 심층 조사, 여러 계획 생성 및 검증, 수천 줄의 코드 병렬 작성, 자동 검증 — 그러면서도 메인 컨텍스트 윈도우는 30-40%를 유지합니다.

Atomic Git Commits

각 작업이 완료되면 즉시 독립적으로 커밋합니다:

abc123f docs(08-02): complete user registration plan
def456g feat(08-02): add email confirmation flow
hij789k feat(08-02): implement password hashing
lmn012o feat(08-02): create registration endpoint

장점: git bisect로 특정 실패 작업을 정확히 찾을 수 있고, 각 작업을 독립적으로 롤백할 수 있으며, 명확한 히스토리 기록이 향후 세션에서 Claude가 코드 진화를 이해하는 데 도움이 됩니다.

GSD의 한계

GSD는 강력하지만, 할 수 없는 것을 이해하는 것도 똑같이 중요합니다.

GSD는 인간이 가이드하는 워크플로우이며, 자율 에이전트가 아닙니다

GSD는 지속적으로 실행될 수 없습니다. 각 단계 경계 — discuss에서 plan으로, execute로, verify로 — 에서 수동으로 명령을 입력해야 합니다. "앱 하나 만들어줘"라고 말하고 잠자러 갈 수 없습니다.

이것은 Ralph의 AFK 모드와 뚜렷한 대조를 이룹니다. Ralph는 "시작한 후 잠자러 가도록" 설계되었습니다 — bash 무한 루프가 작업이 완료되거나 실패할 때까지 계속 실행됩니다. GSD는 각 핵심 노드에서 당신이 현장에 있을 것을 요구합니다: 로드맵 승인, 논의 질문 답변, 계획 트리거, 실행 시작, 검증 결과 확인.

TÂCHES는 라이브 스트리밍에서 4시간 동안 계속 명령을 입력했습니다: new-project, discuss-phase 1, plan-phase 1, execute-phase 1, verify-work 1, discuss-phase 2...... 매번 전환할 때마다 엔터 키를 눌러야 했습니다. 이것은 우연이 아닙니다 — 의도적인 설계 선택입니다.

의도적인 설계 트레이드오프

Ralph는 계획 능력을 희생하여 실행 자율성을 얻었고, GSD는 실행 자율성을 희생하여 계획 품질과 인간 검증을 얻었습니다. 이것은 설계 트레이드오프이지 결함이 아닙니다.

• Ralph의 장점: 잠자는 동안 전체 기능을 완성하게 할 수 있습니다. 하지만 스펙이 충분히 좋지 않으면, 잘못된 방향으로 전속력으로 질주합니다.
• GSD의 장점: 각 단계가 끝난 후 방향을 교정할 수 있습니다. 하지만 전 과정에 현장에 있어야 하며, 자리를 비울 수 없습니다.

이상적인 상태는 무엇일까요? GSD의 논의, 계획, 실행, 검증이 자동 순환으로 연결된다면 — Ralph의 bash loop과 비슷하지만, GSD의 구조화된 계획과 품질 검증을 갖춘 — 그것이 두 세계의 최상의 조합이 될 것입니다. 하지만 현재 그런 도구는 아직 없습니다. 이것이 아마도 다음으로 탐구할 가치가 있는 방향일 것입니다.

영상 자료

아래 영상은 GSD의 사용 방법과 효과를 보다 직관적으로 이해하는 데 도움이 됩니다.

I Created GSD For Claude Code. This Is How I Use It.

GSD 저자 TÂCHES의 4시간 라이브 스트리밍. macOS 네이티브 AI 음악 생성 앱 Sample Digger를 처음부터 전 과정 코드 직접 작성 없이 구축. GSD Executor 서브에이전트, 목표 역추적 계획, 디버깅 워크플로우, 멀티 모델 전환, 10단계 후에도 메인 컨텍스트가 24%를 유지하는 방법을 시연합니다.YouTube

The New Claude Code Meta

Chase AI가 GSD가 솔로 개발자의 새로운 메타인 이유를 분석합니다. Context Rot 원리, 서브에이전트 실행이 출력 품질을 보장하는 방법, GSD의 3대 핵심 문서(Project/Roadmap/State), 그리고 GSD로 My Fitness Pal 클론을 구축한 실제 경험을 심층 설명합니다.YouTube

Stop Using Ralph Loops (Use This Instead)

Chase AI가 Ralph 루프 사용자 관점에서 GSD를 평가합니다. 핵심 논점: Ralph 루프는 강력한 무기이지만, GSD는 전체 무기고입니다. Ralph의 hands-off 모드와 GSD의 human-in-the-loop 검증을 비교하고, 전체 설치 및 실행 과정을 시연하며, 토큰 비용 트레이드오프를 논의합니다.YouTube

마치며

GSD는 AI 프로그래밍 도구 진화의 한 방향을 대표합니다: "AI가 코드를 작성하게 하는 것"에서 "AI가 안정적으로 프로젝트를 전달하게 하는 것"으로.

Ralph Wiggum은 핵심적인 통찰을 증명했습니다 — 신선한 컨텍스트가 누적된 컨텍스트보다 더 가치 있다는 것. GSD는 이 기반 위에 프로젝트 이해(new-project), 의사결정 포착(discuss), 구조화된 계획(plan), 병렬 실행(execute), 품질 검증(verify)을 추가하여 완전한 폐쇄 루프를 형성했습니다.

독립 개발자와 소규모 팀에게 GSD의 가치는 복잡한 엔지니어링 실천을 몇 가지 간단한 명령으로 캡슐화한 것에 있습니다. 서브에이전트 편성이나 XML 프롬프트 엔지니어링을 이해할 필요가 없습니다 — 원하는 것을 설명하고, 시스템이 처리하도록 하면 됩니다.

Chase AI의 말이 적절합니다: GSD는 "기술 배경이 아닌 사람이지만, 여전히 Claude Code에서 지속 가능하고 반복 가능한 방식으로 프로젝트를 처음부터 끝까지 구축하고 싶은" 사람에게 적합합니다. 그리고 TÂCHES의 라이브 스트리밍이 이를 증명했습니다 — "아마 Hello World HTML 페이지 정도밖에 직접 작성할 수 없을 것"이라고 자칭하는 사람이 GSD로 완전한 네이티브 데스크톱 애플리케이션을 구축했습니다.

이것은 마법이 아닙니다. 올바른 복잡성을 올바른 곳에 배치하는 것입니다 — 시스템이 편성의 복잡성을 담당하고, 인간은 창의성과 의사결정에 집중합니다. 그리고 그 한계도 존중할 가치가 있습니다: GSD는 인간이 항상 현장에 있는 것을 선택했으며, 이것은 제약이면서 동시에 안정성의 원천입니다.

실습을 시작하고 싶으신가요? GSD 실전 가이드를 계속 읽어보세요 — 완전한 명령 참조, 구성 상세 설명, 실전 워크플로우 데모와 자주 묻는 질문을 다룹니다.

관련 읽을거리:

• Ralph Wiggum 심층 분석 — Context Rot 문제와 Ralph 방법론의 완전한 해설
• 스펙 주도 개발이란 무엇인가 — Vibe Coding에서 스펙 주도 개발로의 패러다임 전환
• Claude Subagent 완전 가이드 — 컨텍스트를 깨끗하게 유지하는 또 다른 방법
• Claude 시스템 아키텍처 전체 해설 — Hooks, Subagent 등 컴포넌트의 전체 아키텍처
• 나의 Claude Code 모범 사례 — Claude Code 일상 사용 팁