Get Shit Done: Claude Code를 위한 Meta-Prompting, Context Engineering, Spec-Driven 개발 시스템

Who Should Read

Claude Code, Gemini CLI 같은 AI 코딩 도구를 이미 쓰고 있는데 context가 길어질수록 결과물이 나빠지거나, 혼자 또는 소규모 팀으로 빠르게 프로덕트를 만들고 싶은 개발자.

Core Mechanics

• GSD는 'context rot' 문제를 해결하는 데 초점을 맞춘다. context window가 채워질수록 Claude의 출력 품질이 떨어지는 현상인데, GSD는 내부적으로 context engineering과 XML 프롬프트 포맷팅을 써서 이 문제를 관리한다.
• 사용자에게 보이는 인터페이스는 명령어 몇 개뿐이지만, 내부에서는 XML 프롬프트 포맷팅, 서브에이전트 오케스트레이션, 상태 관리 등이 돌아간다. 복잡성을 시스템 안에 숨겨서 워크플로우를 단순하게 유지하는 게 핵심 설계 철학이다.
• Claude Code 외에도 OpenCode, Gemini CLI, Codex, Copilot, Antigravity 등 여러 AI 코딩 도구를 지원한다. 설치는 `npx get-shit-done-cc@latest` 한 줄로 되고 Mac, Windows, Linux 모두 동작한다.
• BMAD, Speckit 같은 기존 spec-driven 도구들은 스프린트, 스토리 포인트, Jira 워크플로우 같은 엔터프라이즈 프로세스를 요구하는데, GSD는 솔로 개발자나 소규모 팀을 타겟으로 그런 복잡성을 없애고 핵심 기능에만 집중했다.
• README에서 `--dangerously-skip-permissions` 플래그를 기본 워크플로우로 권장한다. 내부적으로 서브에이전트가 `node gsd-tools.cjs`, `git checkout -b`, `eslint`, 테스트 러너 등을 동적으로 실행하기 때문에 매번 권한 승인을 받으면 자율 모드가 작동하지 않기 때문이다.
• gsd-plan-checker가 실행 전에 요구사항 커버리지와 의존성 그래프를 검증하지만, 실제로 어떤 명령어가 실행될지는 확인하지 않는다. gsd-verifier는 실행 후 목표 달성 여부만 체크하고, 실행 과정에서 뭔가 잘못됐는지는 보지 않는 보안 공백이 있다.
• 한 사용자는 GSD로 한 달 안에 25만 줄의 코드를 작성했다고 주장했다. 3개월간 사용한 다른 사용자는 복잡한 태스크의 95%를 GSD가 처리하고 나머지 5%만 수동 테스트로 마무리했다고 말했다.

Evidence

• 토큰 소모가 매우 크다는 경험담이 여럿 올라왔다. 한 사용자는 GSD를 쓰다 보통은 안 닿는 세션 한도에 30분 만에 도달하고, 주간 한도도 화요일에 다 써버렸다고 했다. 또 다른 사용자는 Plan 모드만 써도 충분해져서 GSD를 그만뒀는데, 토큰을 10배 더 쓰면서도 결과물 품질 차이는 없었다고 밝혔다.
• 보안 우려가 구체적으로 제기됐다. `--dangerously-skip-permissions`를 기본으로 쓰는 설계 때문에, 플래너가 파괴적인 명령어를 생성해도 plan-checker가 잡지 못한다는 점이 지적됐다. AI가 생성한 코드에 하드코딩된 크레덴셜이 들어가거나, API 라우트에 인증 미들웨어가 빠지거나, 디버그 엔드포인트가 프로덕션에 배포되는 사례가 이미 있다는 경험도 공유됐다.
• 결과물에 만족하지 못했다는 의견도 있었다. 플랜 단계에서 좋은 질문을 해주는 '러버덕' 역할은 유용했지만, 실제 구현 품질은 기대에 못 미쳤다는 사용자가 있었다. 결국 Claude Opus로 플랜을 만들고 메모리에 기록하면서 스스로 진행하는 방식이 더 낫다고 결론 냈다.
• 복잡한 레거시 코드베이스나 프로덕션 환경에서의 검증이 없다는 비판도 나왔다. '25만 줄 코드를 읽지도 않고 썼다'는 식의 지표는 AI 코딩 에이전트의 진짜 가치를 보여주기보다 오히려 하이프처럼 보인다는 의견이다. 진짜 증거는 '10년 된 대형 코드베이스에서 실제 기능을 프로덕션에 배포했다'는 식이어야 한다고 했다.
• Superpowers, openspec 같은 유사 도구와의 비교 요청이 많았다. GSD가 토큰을 더 많이 쓰는 대신 결과물이 더 좋냐는 질문에는 명확한 답이 없었다. openspec은 워크플로우를 직접 커스터마이징할 수 있어서 점점 자신만의 방식으로 단순화해갈 수 있다는 장점이 언급됐다.

How to Apply

• Claude Code로 혼자 SaaS나 사이드 프로젝트를 빠르게 만들고 싶다면, `npx get-shit-done-cc@latest`로 설치 후 플랜 단계에서 GSD가 던지는 질문에 답하면서 스펙을 구체화하는 용도로만 써도 도움이 된다. 실제 생성은 직접 Claude Code로 해도 된다.
• `--dangerously-skip-permissions` 없이 자율 모드를 쓰고 싶다면, README의 granular permissions 가이드를 참고해 safe reads와 git 작업만 허용하는 권한 프로파일을 먼저 설정하라. 보안 리뷰 없이 자율 모드를 프로덕션 코드베이스에 바로 붙이는 건 위험하다.
• GSD 자율 모드로 대량의 코드를 생성했다면, AI가 생성한 코드에서 자주 발견되는 패턴인 하드코딩된 크레덴셜, 인증 없는 API 라우트, 디버그 엔드포인트가 배포됐는지를 자동으로 검사하는 스크립트나 lint 규칙을 별도로 추가해야 한다.
• 토큰 예산이 걱정된다면 GSD 전체를 쓰는 대신, Plan 단계만 GSD로 하고 실제 구현은 직접 Claude Code에서 진행하는 하이브리드 방식을 시도해볼 수 있다. 실제 사용자 경험에 따르면 이 방식이 토큰 대비 결과물 품질 면에서 더 효율적이었다는 의견이 있다.

Code Example

# 설치
npx get-shit-done-cc@latest

# 기본 사용 (자율 모드 - 보안 주의)
# README 권장 워크플로우지만 프로덕션 코드베이스에는 위험할 수 있음
claude --dangerously-skip-permissions

# GSD 내부 서브에이전트가 실행하는 작업들 (gsd-executor.md 기반)
# node gsd-tools.cjs
# git checkout -b <branch>
# eslint
# 테스트 러너 등을 동적으로 생성해서 실행

Terminology

Related Resources

• GSD GitHub Repository
• Superpowers (유사 도구, 비교 대상으로 자주 언급됨)