GSD(Get Shit Done) — AI 코딩의 컨텍스트 부패를 해결하는 메타프롬프팅 시스템
AI 코딩 도구로 작업해본 분이라면 이런 경험이 있을 겁니다. 처음 30분은 놀라울 정도로 깔끔한 코드가 나오다가, 1시간이 지나면 슬슬 이상해지기 시작합니다. 이미 만들어둔 함수를 무시하고 새로 만든다거나, 10분 전에 합의한 아키텍처를 잊어버린다거나, 같은 버그를 두 번 세 번 반복합니다.
이 현상에는 이름이 있습니다. Context Rot(컨텍스트 부패). 그리고 GitHub에서 2달 만에 41,000개 이상의 스타를 받으며 화제가 된 오픈소스 도구 GSD(Get Shit Done)가 바로 이 문제를 정면으로 해결하겠다고 나섰습니다.
오늘은 GSD가 실제로 어떤 원리로 작동하는지, 설치부터 실전 활용까지, 그리고 솔직한 장단점까지 한번에 정리해보겠습니다.
---
Context Rot — AI 코딩의 숨겨진 적
AI 코딩 도구는 "컨텍스트 윈도우"라는 일종의 작업 기억 공간 안에서 동작합니다. 대화가 길어질수록 이 공간이 채워지면서, AI가 참고해야 할 정보의 우선순위가 뒤섞이기 시작합니다. 초반에 내린 설계 결정이 밀려나고, 최근 대화에만 과도하게 집중하게 되는 거죠.
구체적으로 이런 증상이 나타납니다.
이건 특정 도구만의 문제가 아닙니다. Claude Code, Cursor, GitHub Copilot 등 현재 대부분의 AI 코딩 도구가 공유하는 구조적 한계입니다. 컨텍스트 윈도우라는 유한한 공간 안에서 작업하는 이상, 세션이 길어지면 품질 저하는 피할 수 없었습니다.
---
GSD는 뭘 다르게 하는가
GSD의 핵심 아이디어는 단순하면서도 영리합니다. AI 위에 AI 프로젝트 매니저를 얹는 것입니다. 이걸 "메타프롬프팅"이라고 부릅니다.
보통 우리가 AI 코딩 도구를 쓸 때는 하나의 긴 세션에서 모든 작업을 처리합니다. GSD는 이 방식을 완전히 뒤집습니다. 매 작업(태스크)마다 새로운 서브에이전트를 생성하고, 그 에이전트는 깨끗한 200K 컨텍스트 윈도우에서 해당 작업만 집중적으로 수행합니다. 이전 작업의 잔재가 남아있지 않으니, Context Rot가 발생할 여지 자체가 없는 구조입니다.
작업은 5단계 워크플로우를 따릅니다.
이 과정에서 17개의 전문 에이전트가 역할을 나눠 맡습니다. 연구 전담, 계획 전담, 실행 전담, 검증 전담, UI 전담, 디버깅 전담 등 마치 실제 개발팀처럼 구성되어 있습니다. 독립적인 태스크들은 병렬 웨이브(Parallel Wave)로 동시에 실행되기 때문에, 순차 처리 대비 작업 속도도 빨라집니다.
특히 인상적인 건 원자적 커밋 방식입니다. 태스크 하나가 완료될 때마다 자동으로 git 커밋이 생성됩니다. 덕분에 문제가 생기면 특정 태스크 단위로 정확하게 롤백할 수 있습니다.
---
설치부터 실전까지 — 5분 만에 시작하기
GSD의 설치는 놀라울 정도로 간단합니다. 터미널에서 한 줄이면 끝입니다.
```bash
npx get-shit-done-cc@latest
```
설치 과정에서 몇 가지를 선택하게 됩니다. 먼저 런타임입니다. Claude Code, Cursor, Windsurf, Gemini CLI 등 7개 AI 코딩 환경을 지원하므로, 본인이 쓰는 도구를 선택하면 됩니다. 다음으로 설치 범위를 글로벌(모든 프로젝트에 적용)과 로컬(현재 프로젝트만 적용) 중에서 고릅니다.
설치가 완료되면 프로젝트에 슬래시 커맨드 30개 이상, 전문 에이전트 17개, 자동화 훅 3개가 추가됩니다. 많아 보이지만 실제로 자주 쓰는 핵심 명령어는 다섯 가지입니다.
| 명령어 | 용도 |
|--------|------|
| `/gsd:new-project` | 새 프로젝트 시작 — 목표 정의부터 Phase 분해까지 |
| `/gsd:do "작업 설명"` | 빠른 단발성 작업 실행 |
| `/gsd:execute-phase 1` | 특정 Phase의 태스크들을 순차/병렬 실행 |
| `/gsd:verify-work 1` | Phase 완료 후 자동 검증 |
| `/gsd:debug` | 문제 발생 시 전용 디버깅 에이전트 호출 |
실제 워크플로우 예시를 보면 이해가 빠릅니다. "React로 대시보드를 만들어줘"라고 하면, GSD는 이 요청을 여러 Phase로 쪼갭니다. Phase 1은 프로젝트 초기 설정, Phase 2는 데이터 레이어, Phase 3는 UI 컴포넌트 같은 식입니다. 각 Phase 안의 태스크는 독립된 서브에이전트가 깨끗한 컨텍스트에서 처리합니다. 이 모든 계획은 프로젝트 루트의 `.planning/` 폴더에 마크다운 파일로 저장됩니다.
---
솔직한 장단점 — 언제 쓰고 언제 안 쓸까
도구를 제대로 활용하려면 장점만큼 한계도 알아야 합니다.
장점
Context Rot의 근본적 해결이 가장 큰 강점입니다. 매 태스크마다 깨끗한 컨텍스트에서 시작하니, 세션이 아무리 길어져도 코드 품질이 유지됩니다. 대형 프로젝트를 Phase에서 Task 단위로 체계적으로 분해해주는 구조화 능력도 뛰어납니다.
원자적 커밋 덕분에 변경 이력 추적과 롤백이 쉽고, 검증 단계가 워크플로우에 내장되어 있어서 "구현은 했는데 제대로 되는지 확인 안 한" 상황을 방지합니다. 그리고 MIT 라이선스의 완전한 오픈소스로, npm 패키지를 통해 누구나 무료로 사용할 수 있습니다.
단점
가장 현실적인 문제는 토큰 소비량입니다. 매 태스크마다 새 서브에이전트를 생성하는 구조 특성상, 일반적인 사용 대비 토큰 소비가 크게 늘어납니다. API 과금 모델을 쓰고 있다면 비용 계산을 미리 해봐야 합니다. Claude Code Pro 구독 기준으로도 평소 5시간 쓸 분량이 30분 만에 소진될 수 있다는 보고가 있습니다.
단순한 버그 수정이나 작은 기능 추가에 GSD를 쓰면 오히려 오버헤드가 큽니다. `.planning/` 폴더에 20개 이상의 계획 파일이 생성되는데, 작은 프로젝트에서는 부담스러울 수 있습니다.
또 하나 생각해볼 점은 지속가능성입니다. AI 모델의 컨텍스트 윈도우가 계속 커지고 있고(현재 100만 토큰 이상을 지원하는 모델도 있습니다), 모델 자체의 장기 기억 능력이 개선되면 GSD가 해결하려는 문제 자체가 줄어들 가능성이 있습니다.
추천 가이드
| 상황 | 추천 여부 |
|------|----------|
| 새 프로젝트 0에서 1 구축 | 강력 추천 |
| 대규모 리팩토링 | 추천 |
| 다중 서비스 아키텍처 설계 | 추천 |
| 단순 버그 수정 | 비추천 |
| 작은 기능 하나 추가 | 비추천 |
---
재미있는 뒷이야기 — 코드 한 줄 안 쓴 개발자
GSD를 만든 Lex Christopherson의 배경이 흥미롭습니다. 그는 원래 소프트웨어 엔지니어가 아니라 하우스 뮤직 프로듀서입니다. RUFUS DU SOL, ZHU 같은 아티스트들과 협업하며 총 7,300만 회 이상의 스트리밍을 기록한 뮤지션이죠.
더 흥미로운 건, GSD 자체도 Claude Code를 사용해서 만들었다는 점입니다. 직접 코드를 작성하지 않고, AI 코딩 도구의 한계를 AI로 해결하는 도구를 AI로 만든 셈입니다. "코드를 한 줄도 안 쓰고 GitHub 41K 스타 프로젝트를 만든 사람"이라는 타이틀이 과장이 아닌 거죠.
이 사례는 AI 코딩 도구의 가능성을 보여주는 동시에, 도구의 한계를 정확히 파악하고 그 위에 시스템을 설계하는 메타적 사고의 힘을 보여줍니다.
---
마무리
GSD는 AI 코딩 도구의 구조적 한계를 AI로 해결하는, 역설적이면서도 실용적인 접근입니다. Context Rot라는 문제를 인식하고, "긴 세션 대신 짧고 깨끗한 세션을 반복한다"는 명확한 원리로 풀어낸 점이 인상적입니다.
다만 모든 상황에 만능은 아닙니다. 토큰 비용과 오버헤드를 고려하면, 프로젝트 규모와 복잡도에 맞게 선택적으로 활용하는 것이 핵심입니다. 새 프로젝트를 처음부터 체계적으로 세우거나, 기존 코드베이스를 대규모로 정리해야 할 때 진가를 발휘합니다.
AI 코딩 도구를 쓰면서 "왜 시간이 지나면 AI가 점점 멍청해지지?"라는 의문을 가져본 적이 있다면, GSD는 한번 시도해볼 가치가 있습니다.
AI 도구 활용에 관한 더 많은 실전 리뷰는 보통리 블로그에서 확인하실 수 있습니다.