한참 프롬프트 주고받다가 어느 순간 AI가 전혀 딴 얘기를 하고 있거나, 처음 의도와 다른 곳을 고쳐버린 경험 있으실 거예요. 대화가 길어질수록 맥락이 흐려지는, 이른바 "컨텍스트 로트" 현상입니다.
뭔데
GSD(Get Shit Done)는 TÂCHES가 만든 메타프롬프팅·컨텍스트 엔지니어링·스펙 기반 개발 시스템이에요. "Git. Ship. Done."이라는 슬로건대로, 바이브코딩을 아예 없애기보다는 요구사항 정리 → 설계 → 작업 분해 → 실행이라는 단계를 스킬과 슬래시 커맨드로 강제해주는 쪽에 가깝습니다.
원래 저장소(gsd-build/get-shit-done)가 64.5k 스타까지 찍고 지금은 아카이브됐고, 개발이 open-gsd/gsd-core로 옮겨갔습니다. 새 저장소는 아직 9.4k 스타로, 이전 규모를 따라잡는 중이에요.
뭘 해결하나
agents/, commands/gsd, skills/, hooks/ 구조로 구성돼 있고, 실제 사용은 이런 식입니다.
```
/gsd-new-project # 신규 프로젝트를 요구사항부터 단계별로 시작
/gsd-onboard # 기존 코드베이스에 맞춰 온보딩
```
새 프로젝트를 무작정 "이거 만들어줘"로 시작하는 대신, 요구사항을 먼저 정리하고 설계를 확인받은 뒤 작업 단위로 쪼개서 진행하게 유도합니다. 세션이 길어져도 각 단계의 산출물이 남아있어서 맥락을 다시 잡기 쉬운 구조예요.
어떻게 시작하나
```
npx @opengsd/gsd-core@latest
```
실행하면 대화형으로 런타임(Claude Code, OpenCode, Copilot 등)과 전역/로컬 설치 여부를 물어봅니다.
언제 쓰고 언제 쓰지 마라
여러 세션에 걸쳐 진행되는 중대형 프로젝트, 혹은 "분명 계획 없이 시작했다가 산으로 갔다"는 경험이 반복되는 분이라면 도움이 됩니다.
다만 이미 Superpowers나 spec-kit 같은 스펙 기반 워크플로를 쓰고 있다면 철학이 상당 부분 겹칩니다(둘 다 이 도구도감에 이미 있어요). 굳이 두 개를 겹쳐 쓸 필요는 없고, 하나를 골라서 익숙해지는 편이 낫습니다. 그리고 빠르게 던지고 버릴 프로토타입 코드에는 단계가 오히려 번거로울 수 있어요.
한계
저장소 이전이 얼마 안 돼서 문서나 이슈 트래커가 아직 재정비되는 중입니다. 설치 전에 새 저장소의 최근 이슈를 한 번 훑어보는 걸 추천해요.
출처: [open-gsd/gsd-core (GitHub)](https://github.com/open-gsd/gsd-core), [gsd-build/get-shit-done (아카이브된 원 저장소)](https://github.com/gsd-build/get-shit-done)
댓글 0
첫 댓글을 남겨보세요!