GSD_초보자_실습워크북.pdf 을 참조할 것
GSD(Get Shit Done)
AI 코딩의 컨텍스트 부패를 해결하는 프레임워크
오늘 다룰 내용
-
01. 문제
컨텍스트 부패와 바이브 코딩의 한계 -
02. GSD 개념
GSD란 무엇이고 어떤 철학으로 만들어졌는가? -
03. 3대 메커니즘
핵심 매커니즘 3가지가 무엇인가?
신선한 컨텍스트, XML, 마크다운 파일 -
04. 5단계 워크플로우
Discuss → Plan → Excute → Verify → Ship -
05. 각 단계별 산출물
Project, Reqirements, Plan, Summary -
06. 실전 예제
01. 문제
컨텍스트 부패(Context Rot)
-
대화가 쌓이면 토큰이 쌓이고, 응답 품질이 점진적으로 저하됨
-
처음에는 정확하던 코드가 점점 엉성해지고, 지시를 무시하기 시작
-
스스로 "간결하게 하겠습니다" 라고 말하며 코너를 깎는다
-
컨텍스트 길이가 증가할수록 모든 모델에서 성능이 일관되게 하락
-
시작·끝 정보는 잘 찾지만 중간에 묻힌 정보의 정확도는 15~20% 하락
Lost in the Middle
체감 임계점
Claude Code에서 컨텍스트 사용량이 70~80%에 도달하는 순간 품질 저하 시작
바이브 코딩의 한계
-
요구를 말로만 던지면 일관성 없는 결과물이 돌아옴
-
스케일이 커질수록 무너지기 쉬움
-
중·대형 프로젝트에서 큰 약점을 보임
압축
-
Compaction은 이미 부패한 토큰을 요약해서 다시 주입
-
썩은 정보가 더 짧고 단단하게 압축된 채 맥락에 박혀 버림
-
구조적 해법이 필요 → 컨텍스트를 분리할 것
02. GSD 개념
정의
Claude Code 등 AI 코딩 CLI(Command Line Interface)위에 얹는
경량 메타 프롬프팅 · 컨텍스트 엔지니어링 · 스펙 기반 개발 시스템
복잡함은 시스템 안에
"The Complexity is in the system not in your workflow"
system
- context engineering
- XML prompt formatting
- subagent orchestration
- state management
우리가 보는 것
- 잘 동작하는
/커맨드
사용자가 영리해질 필요 없이, 시스템이 영리해지는 구조
03. 3대 매커니즘
01. Fresh Context per Task
작업당 신선한 컨텍스트
-
각 테스크는 200k 토큰의 깨끗한 서브 에이전트에서 실행
메인 세션에서 코드를 작성하지 않음 (지휘자 역할)
쌓이는 쓰레기 토큰이 0에 수렴 -
30~40% 사용량을 유지해 빠르고 반응성있게
-
매번 새 200K 컨텍스틀 가진 서브에이전트에서 실행
02. XML 구조화 프롬프트
-
name(이름), files(대상 파일), action(행동), verify(검증), done(완료조건)의
모호성 제거 포맷 -
verify: 검증 절차가 플랜 안에 내장됨
XML format이 주는 효과
- Precise instructions (정밀한 지시)
- No guessing (추측 금지)
- Vadlidation built in (검증 내장)
03. Markdown 컨텍스트 파일
-
Project, Requirements, Roadmap, State 필요한 만큼 주입
-
컨텍스트를 한 군데에 모아두지 않고 쪼개서 저장함
PROJECT.md: 프로젝트 비전, 항상 로드
REQUIREMENTS.md: v1/v2 요구사항과 페이즈 추적
ROADMAP.md: 지금까지의 진척과 다음 방향
STATE.md: 결정 사항과 세션 간 메모리
{N}-CONTEXT.md: 페이즈 별 Discuss 결과
{N}-{M}-PLAN.md: 원자 단위 XML 태스크 플랜
{N}-{M}-SUMMARY.md: 실행 결과와 변경 이력
에이전트는 필요한 파일만 컨텍스트에서 끌어다 씀
오케스트레이터 패턴
-
GSD가 일하는 방식을 한 단어로 표현한다면 Orchestrator
-
Main Orchestrator는 무거운 작업을 직접 하지 않음
Researcher: 도메인 조사
Planner: Task 생성
Checker: 검증
Executor x N (waves): 병렬 구현
Verifier/Debugger: 검사
위와 같은 에이전트에게 작업을 위임
04. 5단계 워크플로우
1. Discuss
- 회색 영역(결정이 되지 않은 부분) 식별
2. Plan
- 리서치 + XML 플랜 + 검증 루프
3. Execute
- 플랜들을 wave 단위로 병렬 실행
4. Verify
- 사용자와 함께 수동 검수
5. Ship
- PR 생성 후 마감
milestone 단위로 해당 사이클을 반복
01. Initialize & Discuss
-
Question: 이해할 때 까지 묻고 또 물음(목표, 제약, 기술 선호, 엣지 케이스)
-
Research: 도메인 조사용 병렬 에이전트 spawn
-
Discuss: 레이아웃, 인터랙션, 빈 상태, 에러 처리 등 회색 영역 결정
SpecKit의 Clarify와 비슷하지만,
phase로 나눠서 해당 단계에 대해서만 작업함
산출물
PROJECT.md, REQUIREMENTS.md, ROADMAP.md, STATE.md, {N}-CONTEXT.md
02. Plan + 검증 루프
-
Researches: 어떻게 구현할지 조사
-
Plan: 2~3개의 원자 단위 XML 태스크 플랜 생성
-
Verifies: 체커가 6가지 차원으로 검사 → 통과할 때 까지 루프
-
planner와 checker는 적대관계에 있음
GAN(Generative Adversarial Network) Style Loop
산출물
{N}-RESEARCH.md, {N}-{M}-PLAN.md
- 각 플랜이 새 컨텍스트 윈도우 하나로 실행될 만큼 충분히 작음
03. Execute (웨이브 병렬 실행)
산출물
{N}-{M}-SUMMARY.md, {N}-VERIFICATION.md, commit per task
04. Verify (수동 UAT)
- Extract: 검증 가능한 산출물 추출
- Walkthrogh: "이메일로 로그인 가능한가요?" → Yes/No
- Diagnose: 실패 시 디버그 에이전트 자동 spawn
- Fix Plan: 검증된 수정 플랜을 바로 실행할 수 있게 발급
산출물
{N}-UAT.md, fix plans (issue 발견 시)
05. Ship & Milestone
- ship: 검증된 작업으로 PR 생성
- Complete Milestone: 마일스톤 아카이브 + 릴리스 태깅
- New Milestone: 다음 버전 시작
- BMAD, SpecKit, Taskmaster는 한 컨텍스트 안에서 모든 단계를 돔
Todo 달력 만들기 실습 PDF에서 추가로 살펴보기
