Claude Code + GSD — 기획부터 검증까지 자동화하는 법

게시 2026/03/28

By BLUEBUG

44 분읽는 시간

Context Rot에서 Context Engineering으로: 완전 분석 가이드

영상 출처: Claude Code + GSD — 기획부터 검증까지 자동화하는 법
게시일: 2026년 3월 23일 | #ClaudeCode #GSD #ContextEngineering #Anthropic
문서 작성: 2026년 3월 28일 (검색 기반 사실 검증 포함)

영상 개요 및 핵심 주제
Context Rot — AI가 멍청해지는 구조적 이유
바이브코딩의 한계와 그 배경
GSD란 무엇인가
GSD의 5단계 워크플로우 상세 분석
Wave 기반 병렬 실행 — 핵심 실행 메커니즘
GSD가 작동하는 세 가지 이유
더 큰 그림 — Context Engineering의 등장
Prompt Engineering vs Context Engineering
GSD 없이도 적용할 수 있는 3가지 원칙
사실 검증 — 검색을 통한 확인
GSD 설치 및 사용법
결론 및 시사점

1. 영상 개요 및 핵심 주제

이 영상은 Claude Code를 사용하면서 누구나 경험하는 불편한 현상, 즉 처음에는 놀랍도록 유능하게 작동하던 AI가 시간이 지날수록 점점 퇴보하는 이유를 구조적으로 분석한다. 그리고 이 문제를 시스템 수준에서 해결하는 도구인 GSD(Get Shit Done) 의 원리를 상세히 풀어낸다. 마지막으로는 GSD라는 특정 도구를 넘어서 Context Engineering 이라는 새로운 패러다임 전환을 제시한다.

영상이 던지는 핵심 질문은 하나다: AI에게 일을 잘 시키려면 무엇이 필요한가? 그 답은 “좋은 프롬프트”가 아니라 “올바른 컨텍스트 설계”라고 영상은 주장한다. 이 주장은 2025~2026년 AI 개발 생태계에서 폭넓게 공유되기 시작한 관점이기도 하다.

2. Context Rot — AI가 멍청해지는 구조적 이유

컨텍스트 윈도우란 무엇인가

Claude Code를 포함한 모든 LLM 기반 AI 도구에는 컨텍스트 윈도우(Context Window) 라는 개념이 있다. 이것은 AI가 한 번의 세션에서 참조할 수 있는 정보의 총량을 의미한다. 쉬운 비유로는 “작업 메모장”이다. 대화를 나누고, 코드를 요청하고, 수정을 거듭할수록 이 메모장에 내용이 쌓인다.

Claude의 경우 최대 약 200,000 토큰의 컨텍스트를 지원하는데, 이는 영문 소설 한 권 분량에 해당하는 방대한 양처럼 들린다. 하지만 실제 프로젝트가 진행되면 놀랍도록 빠르게 소진된다. 코드 파일들, 오류 메시지들, 대화 내역, 수정 요청들이 모두 누적되기 때문이다.

Context Rot 현상의 실체

Context Rot(컨텍스트 부패) 는 컨텍스트 윈도우가 채워져 가면서 AI 출력 품질이 점진적으로 저하되는 현상을 가리킨다. 영상은 이를 “컨텍스트가 썩는 것”이라고 표현한다. 구체적으로는 다음과 같은 증상이 나타난다:

한 시간 정도 작업을 진행하고 나면 AI가 30분 전에 만든 파일을 마치 없는 것처럼 취급한다. 초반에 함께 정한 코딩 컨벤션을 슬며시 무시하기 시작한다. 심한 경우에는 자신이 직접 작성한 코드를 덮어쓰거나, 이미 해결한 버그를 다시 만들어낸다. 이것은 사용자의 실수가 아니다. AI 도구의 구조적 한계다.

검색을 통해 확인한 바에 따르면, 이 현상은 연구로도 입증되었다. 컨텍스트 윈도우 사용량이 50%를 초과하는 시점부터 AI의 정확도가 의미 있게 하락하기 시작한다. 30% 이하일 때는 피크 품질로 작동하다가, 50%가 넘으면 요약 지향적으로 바뀌고, 70%를 넘어서면 환각(hallucination)과 요구사항 망각이 본격화된다.

안드레이 카파시(Andrej Karpathy)는 이 구조를 설명하기 위해 유용한 비유를 제시했다: LLM은 CPU, 컨텍스트 윈도우는 RAM이다. RAM이 잡동사니로 가득 차면 CPU가 제대로 작동하지 못하듯, 컨텍스트 윈도우가 저품질 정보로 채워지면 LLM도 제대로 작동하지 못한다.

3. 바이브코딩의 한계와 그 배경

바이브코딩이란

2025년 2월, 역시 안드레이 카파시가 처음 사용한 용어인 바이브코딩(Vibe Coding) 은 AI에게 원하는 기능을 자연어로 설명하고 생성된 코드를 거의 그대로 수용하는 개발 방식을 의미한다. “이런 느낌으로 만들어 줘”라고 말하면 AI가 알아서 만드는 방식이다.

초기에는 이 방식이 개발자들에게 엄청난 흥분을 불러일으켰다. 복잡한 기능을 단 몇 분 만에 구현하고, 익숙하지 않은 언어나 프레임워크로도 빠르게 프로토타입을 만들 수 있었기 때문이다.

바이브코딩이 프로토타입을 넘어서지 못하는 이유

문제는 프로젝트 규모가 커질수록 드러난다. 처음에는 코드가 잘 나온다. 흥분해서 계속 기능을 추가하다 보면 컨텍스트가 포화 상태에 가까워진다. 이 시점부터 버그가 폭발적으로 증가한다. 버그를 고치려고 AI에게 다시 요청하면 수정 과정에서 다른 부분이 망가진다. 이 악순환이 반복되면서 AI 코딩은 “프로토타입까지만”이라는 인식이 굳어졌다.

GSD의 개발자가 직접 표현한 바에 따르면, “단일 채팅 스레드를 빌드 시스템으로 취급하는 것이 근본 문제”다. 채팅창 하나에 모든 것을 집어넣는 방식은 스케일업이 불가능한 구조다.

4. GSD란 무엇인가

이름과 철학

GSD는 Get Shit Done의 약자다. 이름 자체가 도구의 철학을 잘 담고 있다: 엔터프라이즈 흉내를 내지 말고, 실제로 결과물을 만들자는 것. 개발자 본인의 소개에 따르면, “나는 솔로 개발자다. 코드를 직접 짜지 않는다. Claude Code가 짠다.” 스프린트, 스토리 포인트, 스탠드업 미팅, 레트로스펙티브 — 이런 것들이 다 필요 없다는 입장이다.

GSD가 하는 일

영상에서 강조하는 중요한 구분이 있다. GSD는 코드를 대신 짜주는 도구가 아니다. 코드는 여전히 Claude Code가 짠다. GSD는 Claude Code가 코드를 더 잘 짤 수 있도록 만드는 도구다. 컨텍스트를 관리하고, 작업을 구조화하고, AI에게 올바른 정보를 올바른 타이밍에 올바른 형태로 전달하는 것이 GSD의 역할이다. 그래서 영상은 이를 메타 프롬프팅 시스템(meta-prompting system) 이라고 부른다.

설치 방법

설치는 간단하다. 터미널에서 다음 명령어 하나면 된다:

npx get-shit-done-cc@latest

이 명령을 실행하면 Claude Code 내부에 /gsd: 접두어로 시작하는 슬래시 커맨드들이 추가된다. Claude Code, Gemini CLI, GitHub Copilot, OpenCode 등 주요 AI 코딩 도구를 모두 지원하며, Mac, Windows, Linux에서 모두 동작한다.

GitHub 스타 및 채택 현황

2026년 3월 기준으로 GSD는 GitHub에서 32,000개 이상의 스타를 기록했다. Amazon, Google, Shopify의 시니어 엔지니어들이 실제 프로덕션 환경에서 사용하고 있다고 보고되었다. Hacker News 프런트 페이지에 오르기도 했으며, 한 개발자는 GSD 워크플로우를 통해 사흘 분량의 작업을 하루로 압축했다고 보고했다.

5. GSD의 5단계 워크플로우 상세 분석

GSD의 핵심 워크플로우는 초기화 → 논의 → 계획 → 실행 → 검증의 5단계로 구성되어 있으며, 각 단계는 명확한 산출물을 만들어낸다.

1단계: 초기화 (`/gsd:new-project`)

/gsd:new-project를 입력하면 GSD가 질문을 쏟아낸다. 무엇을 만들 것인지, 기술 스택은 무엇인지, 제약 조건은 무엇인지, 엣지 케이스는 어떻게 처리할 것인지. 이 질문들의 목적은 사용자의 머릿속에 있는 애매한 아이디어를 시스템이 강제로 구체화시키는 것이다.

질문에 답하다 보면 다음과 같은 문서들이 자동으로 생성된다:

PROJECT.md — 프로젝트 비전과 목표
REQUIREMENTS.md — 기능 요구사항과 비기능 요구사항
ROADMAP.md — 마일스톤과 페이즈 구분

2단계: 논의 (`/gsd:discuss-phase`)

/gsd:discuss-phase를 실행하면 GSD가 해당 단계의 모호한 부분들을 찾아낸다. 레이아웃을 카드로 갈 것인가 테이블로 갈 것인가. 에러 처리를 토스트로 할 것인가 인라인으로 할 것인가. 이런 세부 결정들을 미리 확정하는 단계다.

이 단계를 건너뛰면 Claude Code가 알아서 결정을 내린다. 문제는 그 결정이 사용자가 원하는 방향이 아닐 수 있다는 것이다. 나중에 “이거 아닌데”라고 수정 요청을 하면 그게 또 컨텍스트를 소모하고 더 많은 문제를 만든다. 논의 단계는 이런 후퇴를 방지하는 장치다.

--batch 옵션을 붙이면 질문을 그룹으로 묶어 더 빠르게 논의를 진행할 수도 있다.

3단계: 계획 (`/gsd:plan-phase`)

영상에서 “진짜 마법이 일어나는 단계”라고 소개하는 핵심 단계다. /gsd:plan-phase를 실행하면 세 가지 일이 순서대로 일어난다.

첫째, 리서치. GSD가 먼저 어떤 라이브러리가 적합한지, 어떤 패턴을 사용해야 하는지를 조사한다.

둘째, XML 형식의 계획서 생성. 이 계획서는 단순한 할 일 목록이 아니다. 각 태스크마다 구체적인 내용이 명시된다:

  
<task>
  <name>로그인 API</name>
  <files>src/auth/</files>
  <action>JWT 구현</action>
  <verify>200 OK</verify>
</task>

태스크 이름, 수정할 파일 경로, 구체적 행동, 그리고 검증 방법까지 모두 포함된다. 검증 조건은 명확하다: “이 curl 명령을 쳤을 때 200이 나와야 한다”, “이 테스트를 돌렸을 때 통과해야 한다”.

셋째, 자체 검증. GSD는 생성된 계획서가 목표 달성에 충분한지를 스스로 검토한다. 불충분하다고 판단되면 통과할 때까지 계획서를 다시 짠다. 이 자체 검증 루프가 GSD를 다른 도구들과 구분짓는 중요한 특징이다.

4단계: 실행 (`/gsd:execute-phase`)

/gsd:execute-phase를 실행하면 3단계에서 만든 계획서들이 실제로 실행된다. 이 단계의 핵심은 Wave 기반 병렬 실행과 서브 에이전트 컨텍스트 격리이며, 이는 다음 섹션에서 별도로 상세 분석한다.

5단계: 검증 (`/gsd:verify-work`)

/gsd:verify-work를 실행하면 자동화된 검증이 진행된다. 코드가 실제로 존재하는지 확인하고, 테스트가 통과하는지 확인한다. 여기까지가 자동 검증이다.

그런데 검증은 자동화에서 그치지 않는다. GSD는 사용자에게 직접 확인을 요청한다: “로그인이 실제로 되나요? 버튼을 누르면 동작하나요?” 이것이 UAT(사용자 수락 테스트) 단계다.

문제가 발견되면 GSD는 디버그 에이전트를 별도로 띄워서 원인을 분석하고 수정 계획서를 만든다. 그 후 /gsd:execute-phase를 다시 실행하면 수정이 완료된다.

초기화 → 논의 → 계획 → 실행 → 검증
   ↑                              ↓
   └──── 문제 발견 시 재실행 ←────┘

이 사이클이 각 페이즈(Phase)마다 반복된다. 한 마일스톤이 끝나면 /gsd:complete-milestone으로 마무리하고, 다음 마일스톤으로 넘어가는 구조다.

6. Wave 기반 병렬 실행 — 핵심 실행 메커니즘

실행 단계에서 일어나는 일을 더 깊이 이해할 필요가 있다. 이것이 GSD가 Context Rot을 구조적으로 방지하는 핵심 메커니즘이기 때문이다.

Wave란 무엇인가

계획 단계에서 만들어진 여러 개의 태스크 계획서는 의존성(dependency) 분석을 거쳐 Wave라는 단위로 묶인다.

서로 의존성이 없는 태스크들, 즉 독립적으로 실행할 수 있는 것들은 같은 Wave에 배치되어 동시에 실행된다. 반면 특정 태스크가 완료되어야 시작할 수 있는 의존성이 있는 태스크들은 다음 Wave에 순차적으로 배치된다.

WAVE 1 (동시 실행)         WAVE 2 (동시 실행)
┌──────────┐ ┌──────────┐  ┌──────────┐ ┌──────────┐
│  Plan 01 │ │  Plan 02 │→ │  Plan 03 │ │  Plan 04 │
└──────────┘ └──────────┘  └──────────┘ └──────────┘
각 에이전트: Fresh 200K    메인 컨텍스트: 30~40%    태스크마다: git commit

서브 에이전트와 신선한 컨텍스트

여기서 가장 중요한 부분이 나온다. 각 계획서가 실행될 때 새로운 서브 에이전트가 생성된다. 이 서브 에이전트는 완전히 신선한(fresh) 상태의 컨텍스트, 즉 200,000 토큰 전부를 오로지 그 하나의 계획서를 실행하는 데만 사용한다.

메인 오케스트레이터(팀장)는 교통 정리만 한다: “이거 먼저 해, 이거 끝나면 저거 해.” 덕분에 메인 컨텍스트는 30~40%만 사용된다. 나머지 작업은 각자의 신선한 컨텍스트를 가진 서브 에이전트들이 처리한다.

이 구조에서는 어떤 에이전트도 컨텍스트가 가득 차지 않는다. Context Rot이 구조적으로 발생할 수 없는 환경이 만들어지는 것이다.

자동 Git 커밋

태스크 하나가 끝날 때마다 자동으로 Git 커밋이 이루어진다. 이것의 이점은 단순히 버전 관리의 편리함이 아니다. 문제가 발생했을 때 git bisect를 사용하면 정확히 어느 태스크에서 버그가 발생했는지를 추적할 수 있다. 수백 줄의 코드 변경 사항 속에서 문제의 원인을 찾아 헤매는 것이 아니라, 원자적(atomic) 단위의 커밋 덕분에 정확한 지점을 특정할 수 있다.

7. GSD가 작동하는 세 가지 이유

영상은 GSD의 효과성을 설명하는 세 가지 핵심 원리를 제시한다.

핵심 1: 컨텍스트 격리 (Context Isolation)

앞서 설명한 서브 에이전트 구조다. 영상의 비유가 직관적이다: 여러분이 팀장이라고 상상해 보자. 프로젝트를 혼자 다 처리하려면 머리가 터진다. 그래서 팀원들에게 작업을 나눠 준다. 팀원들에게는 “전체 프로젝트를 다 알 필요 없어. 네 담당 부분만 알면 돼. 대신 이 기획서를 보고 해”라고 한다.

그 기획서가 바로 3단계에서 만든 Plan XML 파일이다. 각 팀원(서브 에이전트)은 기획서만 읽으면 되니까 머리가 깨끗하다. 팀장(오케스트레이터)은 교통 정리만 하니까 역시 머리가 안 터진다. 아무도 컨텍스트가 가득 차지 않는다.

핵심 2: 구조화된 전달 (Structured Delivery)

우리가 보통 Claude Code를 쓰는 방식을 생각해보자: 채팅으로 이것저것 시키고, 수정하고, 다시 시키고, 취소하고. 이 모든 대화 스토리가 전부 컨텍스트에 쌓인다. 그중에서 실제로 유용한 정보는 얼마나 될까?

GSD는 각 단계의 산출물을 구조화된 마크다운 파일로 저장한다.

PROJECT.md — 프로젝트 비전 (what we’re building)
REQUIREMENTS.md — 요구사항 (what it needs to do)
STATE.md — 현재 상태와 주요 결정사항 (where we are)
PLAN.md — 실행 계획서 (what to do next)

서브 에이전트에게는 이 파일들만 딱 전달된다. 채팅 히스토리 없이. 잡다한 내용이 섞인 100,000 토큰보다 핵심만 정리된 20,000 토큰이 훨씬 나은 결과를 만든다. 컨텍스트의 양이 아니라 질이 결과를 결정한다는 것이 핵심 통찰이다.

핵심 3: 원자적 계획 (Atomic Planning)

GSD는 계획서를 만들 때 하나의 계획서가 하나의 서브 에이전트 컨텍스트 안에서 완결될 수 있는 크기로 쪼갠다. 너무 크면 쪼개고, 너무 작으면 합친다. 그리고 각 계획서 안에 검증 단계가 포함되어 있어서, 실행하는 에이전트가 스스로 완료 여부를 확인할 수 있다.

팀원에게 일을 시킬 때 “다 하면 이거 확인해 봐”까지 지시하는 것과 같다. 팀장한테 “다 했어요”라고 보고하기 전에 본인이 먼저 체크하는 구조다.

이 세 가지를 합치면 Context Rot이 구조적으로 발생할 수 없는 환경이 만들어진다.

8. 더 큰 그림 — Context Engineering의 등장

영상의 후반부에는 흥미로운 반전이 나온다. GSD가 해결하는 것이 단순히 Context Rot만이 아니라는 주장이다.

GSD가 진짜 해결하는 것은 AI와 인간 사이의 커뮤니케이션 문제다. 우리가 Claude Code에게 일을 잘 못 시키는 이유는 머릿속에 있는 것을 정확하게 전달하지 못하기 때문이다. “대충 이런 느낌으로 만들어 줘”라고 하면 대충 이런 느낌으로 나온다. 당연한 결과다.

GSD는 이 전달 과정을 시스템화한다. 질문으로 애매한 것을 구체화시키고, 문서로 정리하고, 구조화된 형태로 전달한다. 이것이 컨텍스트 엔지니어링(Context Engineering) 이다.

Context Engineering의 정의

영상에서 제시하는 정의는 명확하다: AI에게 올바른 컨텍스트를 올바른 타이밍에 올바른 형태로 전달하는 기술.

이 개념을 가장 명확하게 정의한 것은 전 OpenAI 수석 연구원이자 Tesla AI 디렉터였던 안드레이 카파시(Andrej Karpathy)다. 2025년 6월 그는 다음과 같이 말했다:

“Context engineering is the delicate art and science of filling the context window with just the right information for the next step.” — 안드레이 카파시

이 발언은 Shopify CEO 토비 뤼트케(Tobi Lütke)의 지지를 받으며 AI 개발 커뮤니티에서 빠르게 확산되었다. 컨텍스트 엔지니어링은 2025년 중반부터 본격적인 담론으로 부상했고, 2026년 초에는 Gartner가 공식 정의를 발표하고 기업들이 관련 직책의 채용 공고를 올리기 시작했다.

9. Prompt Engineering vs Context Engineering

영상이 제시하는 두 패러다임의 비교는 다음과 같다:

구분	Prompt Engineering	Context Engineering
핵심 질문	어떻게 말하냐	무엇을, 언제, 얼마나 보여주냐
스코프	단일 프롬프트 최적화	전체 컨텍스트 윈도우 설계
비유	대사 하나를 잘 외우는 것	무대, 조명, 의상, 대본 전체를 설계하는 것
시대적 맥락	2022~2024년 주류	2025년부터 부상

더 풍부한 비유로 설명하자면: 프롬프트 엔지니어링이 배우에게 “이 대사를 이렇게 읽어”라고 지시하는 것이라면, 컨텍스트 엔지니어링은 스크립트 전체를 쓰고, 무대를 설계하고, 조명을 배치하고, 배우들의 동선을 짜는 것이다.

GSD의 모든 행동이 이 관점에서 설명된다:

왜 질문을 많이 하냐? → 올바른 컨텍스트를 추출하기 위해
왜 문서를 만드냐? → 컨텍스트를 구조화하기 위해
왜 서브 에이전트를 쓰냐? → 각 에이전트에게 필요한 컨텍스트만 전달하기 위해

결국 GSD의 핵심은 커맨드 몇 개가 아니다. AI에게 일을 제대로 시키려면 컨텍스트를 설계해야 한다는 원칙이다.

안드레이 카파시가 추가로 언급한 중요한 통찰도 있다: 컨텍스트 엔지니어링은 LLM 앱이 성공하는 데 필요한 “비자명한 소프트웨어 레이어(non-trivial software layer)”의 일부다. 여기에는 컨텍스트 관리뿐 아니라 메모리, RAG, 툴 호출, 상태 관리, 제어 흐름 등이 포함된다.

10. GSD 없이도 적용할 수 있는 3가지 원칙

영상은 “GSD를 설치하라”는 단순한 광고로 끝나지 않는다. GSD를 쓰지 않더라도 이 시스템에서 배울 수 있는 세 가지 원칙을 제시한다.

원칙 1: 대화를 줄이고 문서를 늘려라

Claude Code에게 채팅으로 이것저것 즉흥적으로 시키는 대신, 구조화된 문서로 지시하라는 것이다. 구체적으로는 두 가지다:

CLAUDE.md 파일 활용: 프로젝트의 전체 구조, 코딩 컨벤션, 아키텍처 결정 사항을 이 파일에 정리해 두면 Claude Code가 매 세션마다 참조한다. “이렇게 만들어 줬으면 좋겠어”를 매번 말할 필요가 없다.

스킬 파일 활용: 반복되는 지시 사항들을 스킬 파일로 정리해 두면 컨텍스트 효율이 크게 올라간다. 예를 들어, “에러 처리는 항상 이 방식으로, 테스트는 항상 이 구조로”를 문서화해 두는 것이다.

컨텍스트의 질이 올라가면 결과의 질도 올라간다.

원칙 2: 큰 작업은 쪼개서 시켜라

“이 앱 전체를 만들어 줘”는 최악의 프롬프트다. 모든 것이 하나의 컨텍스트에 쌓이면서 Context Rot이 가속화된다.

대신 이렇게 해야 한다: “로그인 API부터 만들어 줘. 스펙은 이거야. 끝나면 이 테스트로 확인해 줘.” 원자적으로 시키면 컨텍스트가 넘칠 일이 없다. 하나가 끝나면 새 세션을 열거나 컨텍스트를 리셋하고 다음 작업으로 넘어가는 것이 훨씬 효율적이다.

원칙 3: 검증을 자동화하라

테스트 코드를 먼저 작성하고, Claude Code에게 구현을 맡기는 테스트 주도 개발(TDD) 방식이다. 테스트가 통과하면 된 것이고, 안 되면 다시 시키면 된다.

안전망이 있으면 Claude Code에게 더 자유롭게 맡길 수 있다. 결과물이 틀렸을 때 즉시 알아차릴 수 있는 검증 체계가 있다면, 중간중간 직접 확인하면서 컨텍스트를 소모할 필요가 없다.

11. 사실 검증 — 검색을 통한 확인

영상에서 제시된 주요 주장들을 검색을 통해 검증한 결과를 정리한다.

✅ 확인된 사실

Context Rot 현상 — 실제로 확인된 현상이다. 컨텍스트 윈도우 사용량이 50%를 초과하면 품질이 유의미하게 하락하며, 70%를 넘어서면 환각과 요구사항 망각이 본격화된다는 것이 실무 개발자들의 공통 보고다.

GSD의 GitHub 스타 수 — 2026년 3월 기준 약 31,900~32,000개로, 영상이 제시한 “빠르게 올라가고 있다”는 내용이 사실로 확인된다.

Amazon, Google, Shopify 엔지니어 사용 — 여러 기술 미디어 보고에서 해당 기업 시니어 엔지니어들의 사용이 언급되었다. 다만 이는 공식 회사 정책이 아닌 개인 채택 수준이다.

안드레이 카파시의 Context Engineering 정의 — 2025년 6월 25일 X(트위터)에 게시된 것으로 확인된다. GSD를 언급한 것이 아니라 일반적인 LLM 앱 개발 방법론에 대해 언급한 것이며, GSD는 이 개념을 자신의 시스템 설계 철학으로 채택한 것이다.

GSD가 Context Rot의 유일한 해결책이라는 주장 — 이것은 다소 과장이다. BMAD, SpecKit, Taskmaster 등 유사한 spec-driven development 도구들이 존재한다. 다만 GSD의 서브 에이전트 기반 컨텍스트 격리는 차별화된 접근이라는 점은 인정된다.

“솔로 개발자” 설명 — GSD 공식 GitHub에서 확인된다. 개발자 본인이 직접 “I’m a solo developer. I don’t write code — Claude Code does”라고 소개하고 있다.

설치 명령어 — npx get-shit-done-cc@latest가 맞다. 다만 최신 버전에서는 Claude Code뿐 아니라 --claude, --gemini, --codex, --all 등 다양한 옵션이 추가되었다.

Wave 기반 병렬 실행 — GSD GitHub에서 공식 확인된다. 의존성 없는 태스크는 같은 Wave에서 동시 실행되고, 의존성 있는 태스크는 다음 Wave에서 순차 실행된다.

태스크마다 Git 커밋 — GSD가 자동으로 각 태스크 완료 시 커밋을 생성하며, git bisect를 통한 문제 추적이 가능하다는 내용이 공식 문서에서 확인된다.

⚠️ 부분적으로 검증된 내용

메인 컨텍스트 30~40% 사용 — 구체적인 수치는 영상이 제시한 것이며, 정확한 측정값이라기보다는 개략적인 추정치로 보아야 한다. 실제로는 프로젝트 규모와 계획서 수에 따라 달라진다.

카네기 멜론대 연구 — AI 코딩 도구를 2개월 이상 사용하면 오히려 개발 속도가 느려진다는 연구가 언급되었는데, 이는 별도의 검증이 필요하다. 해당 연구가 존재하지만 맥락 해석에 있어 주의가 필요하다.

12. GSD 설치 및 사용법

기본 설치

  
# 인터랙티브 설치 (도구 선택)
npx get-shit-done-cc@latest

# Claude Code에만 전역 설치
npx get-shit-done-cc --claude --global

# 모든 AI 코딩 도구에 설치
npx get-shit-done-cc --all --global

설치 후 Claude Code에서 /gsd:help를 입력하면 사용 가능한 커맨드 목록을 확인할 수 있다.

주요 커맨드

/gsd:new-project        → 새 프로젝트 시작, 질문을 통한 요구사항 도출
/gsd:discuss-phase      → 현재 페이즈의 모호한 부분 논의 및 확정
/gsd:plan-phase         → 리서치 + XML 계획서 생성 + 자체 검증
/gsd:execute-phase      → Wave 기반 서브 에이전트 병렬 실행
/gsd:verify-work        → 자동 검증 + 사용자 수동 확인 + 디버그
/gsd:ship               → 검증된 작업의 PR 생성
/gsd:complete-milestone → 마일스톤 완료 및 아카이브
/gsd:new-milestone      → 다음 마일스톤 시작
/gsd:progress           → 현재 진행 상황 확인
/gsd:quick "..."        → 전체 워크플로우 없이 간단한 작업 실행

주의사항

GSD는 모든 상황에 적합하지 않다. 단순한 버그 수정이나 작은 기능 추가에 GSD의 전체 워크플로우를 적용하면 오히려 토큰 소비가 증가한다. 간단한 작업에는 일반 Claude Code를, 복잡한 다중 페이즈 프로젝트에는 GSD를 활용하는 것이 최적이다.

13. 결론 및 시사점

영상의 결론은 다음과 같이 요약된다.

Claude Code가 작업할수록 멍청해지는 것은 Context Rot이다. 컨텍스트가 채워지면서 품질이 썩는 현상이다. GSD는 이를 서브 에이전트 격리, 구조화된 문서 전달, 원자적 계획 실행으로 해결했다. 더 큰 그림에서 보면 이것은 Context Engineering이다. AI에게 무엇을, 언제, 어떤 형태로 전달하느냐의 문제.

그리고 이 원칙은 GSD를 쓰지 않더라도 바로 적용할 수 있다: 문서로 정리하고, 작업을 쪼개고, 검증을 자동화하라.

영상이 마지막으로 던지는 통찰이 특히 주목할 만하다. 컨텍스트 윈도우가 아무리 커져도 컨텍스트 엔지니어링은 사라지지 않는다. 왜냐하면 윈도우가 아무리 커도 쓰레기를 많이 넣으면 쓰레기가 나오기 때문이다. 무엇을 넣느냐가 항상 핵심이다.

이것은 단순히 개발 도구의 사용법이 아니다. AI와 협업하는 시대에 인간이 담당해야 할 고유한 역할이 무엇인지를 가리킨다. 코드를 직접 작성하는 능력에서, AI에게 올바른 컨텍스트를 설계하는 능력으로 중심이 이동하고 있다. Context Engineering은 그 이동의 현재 위치다.

참고 자료

이 문서는 영상 내용을 기반으로 웹 검색을 통한 사실 검증과 추가 정보를 포함하여 작성되었습니다. 2026년 3월 28일 기준 정보입니다.

AI, Claude Code

AI claude-code GSD get-shit-done meta-prompting-system context-rot context-engineering context-isolation structured-delivery atomic-planning Claude.write