19. GSD — AI 에이전트의 컨텍스트를 항상 신선하게 유지하는 법

AI 코딩 에이전트와 한두 시간 작업하다 보면 이런 경험을 한다. 처음엔 정확하고 빠르던 응답이 점점 엉뚱해진다. 같은 파일을 두 번 수정하고, 이미 처리한 이슈를 다시 건드리고, 지시를 절반만 따른다. 원인은 컨텍스트 윈도우에 쌓인 “찌꺼기”다. GSD(Get Shit Done)는 이 문제를 근본적으로 해결하는 프레임워크로, 매 태스크마다 완전히 새로운 컨텍스트에서 작업을 이어가도록 설계됐다.

한 줄 결론: GSD는 AI 코딩 에이전트의 컨텍스트 윈도우를 항상 신선하게 유지해, 장시간 작업에서도 품질 저하 없이 코드를 작성하게 만드는 컨텍스트 엔지니어링 프레임워크다.

컨텍스트가 쌓이면 AI가 멍해진다

Claude Code나 Cursor 같은 도구로 코드를 작성할 때, AI는 대화 전체 기록을 “컨텍스트 윈도우”라는 메모리 공간에 담아둔다. 처음엔 여유가 넓어서 정확하지만, 작업이 길어지면 다음과 같은 일이 벌어진다.

이전 대화의 잡음이 간섭한다: 초반에 논의하다 취소한 내용이 나중에 영향을 미친다.
지시의 우선순위가 흐려진다: “반드시 지켜”라고 한 규칙이 뒷부분에서 무시된다.
동일 파일을 중복 수정한다: 이미 고친 버그를 다시 건드리거나, 방금 만든 함수를 또 만든다.

GSD 공식 문서는 이 현상을 “context rot(컨텍스트 부패)“라고 부른다. 컨텍스트 윈도우가 꽉 차갈수록 AI의 판단력이 흐려지는 현상이다. 이는 AI 모델 자체의 한계라기보다, 하나의 세션에 너무 많은 맥락을 우겨넣는 사용 방식의 문제에 가깝다.

GSD의 접근법 — 매번 신선한 컨텍스트로 시작

GSD가 내세우는 핵심 원칙은 단순하다. 오케스트레이터(조율자)는 가볍게 유지하고, 실제 작업은 매번 새로운 컨텍스트에서 수행한다.

구체적으로 살펴보면 다음과 같이 동작한다.

얇은 오케스트레이터가 전체 흐름만 관리한다. 이 오케스트레이터의 컨텍스트 사용량은 30~40% 수준에서 유지된다.
각 태스크(계획, 연구, 실행, 검증)는 독립된 서브에이전트에게 위임한다.
서브에이전트는 200k 토큰의 완전히 새로운 컨텍스트에서 작업을 시작한다. 이전 세션의 찌꺼기가 없다.
작업이 끝나면 결과를 마크다운 파일(PLAN.md, SUMMARY.md 등)으로 저장한다.
다음 서브에이전트는 이 파일만 읽고 이어서 작업한다.

비유하자면 건축 현장과 비슷하다. 한 공정(기초 공사)이 끝나면 현장을 치우고 상태 보고서를 남긴다. 다음 공정(골조 공사)은 완전히 새로운 인부팀이 그 보고서를 읽고 시작한다. 이전 공정에서 남은 잡동사니가 새 공정의 작업 공간을 더럽히지 않는다.

5단계 컨텍스트 적재 시스템

GSD Pro 포크는 컨텍스트를 5개 등급으로 나눠 필요한 만큼만 불러온다.

등급	크기	용도
Tier 0	~200 토큰	현재 위치와 설정만
Tier 1	~2K 토큰	계획 수립용 컨텍스트
Tier 2	~3K 토큰	실행 컨텍스트 + 의존성 그래프
Tier 3	~5K 토큰	기존 코드베이스 문서
Tier 4	~10K+ 토큰	마일스톤 전체 컨텍스트

이 등급 덕분에 간단한 작업에는 Tier 1만 로드하고, 복잡한 아키텍처 결정이 필요할 때만 Tier 3~4까지 끌어올린다. 컨텍스트 윈도우를 불필요하게 채우는 일을 최소화하는 구조다.

페이지 분할과 상태 이관 메커니즘

GSD의 작업 흐름을 다이어그램으로 보면 이해가 빠르다.

flowchart TD
    A["오케스트레이터<br/>컨텍스트 30~40%"] --> B["Phase N 논의<br/>/gsd-discuss-phase"]
    B --> C["Phase N 계획<br/>/gsd-plan-phase"]
    C --> D{"독립 실행 가능한<br/>계획 단위 분할"}
    D --> E["Plan 01 실행<br/>서브에이전트 (새 컨텍스트)"]
    D --> F["Plan 02 실행<br/>서브에이전트 (새 컨텍스트)"]
    D --> G["Plan 03 실행<br/>서브에이전트 (새 컨텍스트)"]
    E --> H["결과를 마크다운으로 저장<br/>SUMMARY.md + git commit"]
    F --> H
    G --> H
    H --> I["오케스트레이터가 결과 수집<br/>→ 다음 Wave 또는 검증"]
    I --> J["검증 /gsd-verify-work"]
    J --> K["다음 Phase 반복"]

핵심은 매 계획 단위(Plan)마다 서브에이전트가 새 컨텍스트를 받는다는 점이다. 오케스트레이터는 “어떤 계획을 실행할지”와 “결과가 무엇인지”만 관리하고, 코드 작성 자체는 각 서브에이전트가 깨끗한 상태에서 수행한다.

상태를 저장하는 파일 구조

GSD는 프로젝트 상태를 마크다운 파일로 관리한다. 이 파일들이 이전 작업의 기억을 담당한다.

파일	역할
`PROJECT.md`	프로젝트 비전, 항상 로드
`REQUIREMENTS.md`	v1/v2 범위가 정리된 요구사항
`ROADMAP.md`	전체 로드맵, 완료된 Phase 표시
`STATE.md`	현재 결정사항, 장애물, 위치 기억
`N-CONTEXT.md`	Phase N의 구현 결정 사항
`N-M-PLAN.md`	Phase N의 M번째 실행 계획 (XML 구조)
`N-M-SUMMARY.md`	실행 결과 요약
`.planning/research/`	생태계 조사 결과

이 파일 구조 덕분에 세션을 완전히 종료하고 다시 시작해도, 새 에이전트가 STATE.md와 ROADMAP.md만 읽으면 정확히 중단 지점부터 이어갈 수 있다.

설치와 사용법

GSD는 npm 기반으로 설치한다. Claude Code, OpenCode, Gemini CLI, Codex, Copilot, Cursor 등 다양한 런타임을 지원한다.

# 설치 (런타임과 위치를 대화형으로 선택)
npx get-shit-done-cc@latest
 
# Claude Code 글로벌 설치
npx get-shit-done-cc --claude --global
 
# 모든 런타임에 설치
npx get-shit-done-cc --all --global

설치 후 Claude Code에서 /gsd-help를 입력하면 사용 가능한 명령을 확인할 수 있다. 기본 작업 흐름은 다음과 같다.

/gsd-new-project       → 프로젝트 초기화 (질문 → 조사 → 요구사항 → 로드맵)
/gsd-discuss-phase 1   → Phase 1 구현 방식 논의
/gsd-plan-phase 1      → Phase 1 조사 + 계획 수립
/gsd-execute-phase 1   → Phase 1 실행 (각 Plan마다 새 컨텍스트)
/gsd-verify-work 1     → 결과 검증
/gsd-next              → 다음 단계 자동 감지

기존 코드베이스에 적용할 때는 /gsd-map-codebase를 먼저 실행해 프로젝트 구조를 스캔하는 것이 좋다.

실행 권장 설정

GSD는 자동화에 최적화돼 있어, Claude Code를 다음 플래그로 실행하는 걸 권장한다.

claude --dangerously-skip-permissions

매번 git commit과 date 명령에 승인을 누르는 건 자동화의 의미가 퇴색되기 때문이다. 보안이 걱정된다면 .claude/settings.json에서 특정 명령만 허용하는 방식도 가능하다.

장단점

강점

컨텍스트 부패 원천 차단: 매 태스크마다 새 컨텍스트로 시작하므로 품질 저하가 발생하지 않는다.
대규모 프로젝트에 강하다: 수십 개 파일, 수천 줄의 코드를 다루는 장시간 작업에서 일관성을 유지한다.
깔끔한 Git 이력: 태스크마다 개별 커밋을 남겨 git bisect로 문제 지점을 정확히 찾을 수 있다.
병렬 실행: 독립적인 계획은 동시에 실행(Wave)해 작업 시간을 줄인다.
광범위한 런타임 지원: Claude Code, OpenCode, Gemini CLI, Codex, Copilot, Cursor, Cline 등 12개 이상의 도구에서 동작한다.

약점

초기 설정 비용: 프로젝트를 시작할 때 질문→조사→요구사항→로드맵 단계를 거쳐야 한다. “바로 코드 짜고 싶은” 순간에는 번거롭게 느껴질 수 있다.
파일 관리 오버헤드: .planning/ 디렉토리에 수십 개의 마크다운 파일이 생성된다. 작은 프로젝트에는 과한 구조다.
런타임별 차이: 모든 런타임에서 동일한 기능을 제공하지 않는다. Claude Code가 가장 완성도가 높고, 다른 도구는 일부 기능이 제한적일 수 있다.
토큰 소모: 서브에이전트를 반복적으로 생성하므로 전체 토큰 사용량은 증가한다. 다만 품질 저하로 인한 재작업 비용과 비교하면 장기적으로는 효율적이다.

실전 시나리오 — GSD가 빛나는 순간

시나리오 1: 풀스택 SaaS 앱 신규 개발

인증, 결제, 대시보드가 포함된 SaaS 앱을 처음부터 만들어야 한다고 하자. 일반적인 Claude Code 세션으로는 컨텍스트가 70~80%를 넘어가는 시점부터 오작동이 잦아진다.

GSD를 사용하면 Phase 1(인증)이 끝날 때 오케스트레이터 컨텍스트는 여전히 30~40%다. Phase 2(결제)는 완전히 새 서브에이전트가 1-SUMMARY.md를 읽고 시작한다. Phase 3(대시보드)도 마찬가지. 마지막 Phase까지 품질이 일정하게 유지된다.

시나리오 2: 대규모 리팩토링

기존 Express + MongoDB 앱을 NestJS + PostgreSQL로 마이그레이션하는 작업. 파일이 50개 이상, 테이블이 12개, 라우트가 30개 이상인 상황에서는 단일 세션으로 처리가 불가능에 가깝다.

GSD는 /gsd-map-codebase로 기존 구조를 먼저 스캔한다. 그 다음 /gsd-new-project에서 마이그레이션 계획을 수립하고, 각 도메인(User, Order, Product 등)을 별도 Phase로 나눈다. 각 Phase는 독립된 서브에이전트가 처리하므로, User 마이그레이션에서 발생한 오류가 Order 마이그레이션에 영향을 주지 않는다.

시나리오 3: 간단한 수정 작업

버그 수정이나 기능 추가 같은 간단한 작업에는 /gsd-quick을 쓴다. 전체 흐름을 생략하고 바로 실행에 들어가면서도, GSD의 핵심 보장(개별 커밋, 상태 추적)은 그대로 누린다.

/gsd-quick
> What do you want to do? "다크모드 토글 추가"

다른 컨텍스트 관리 전략과의 비교

GSD만 컨텍스트를 관리하는 건 아니다. 여러 접근법을 비교해보면 GSD의 특징이 더 선명해진다.

전략	방식	장점	한계
GSD	매 태스크마다 서브에이전트 새 생성	컨텍스트 부패 원천 차단	파일 오버헤드
수동 세션 분할	작업 단위로 세션을 직접 끊고 새로 시작	도구 의존성 없음	이관 정보 누락 위험
SUMMARY 명령	세션 말미에 요약을 요청해 다음 세션에 복사	간단	요약 누락 발생
CLAUDE.md	프로젝트 규칙을 CLAUDE.md에 적어두고 매 세션 로드	규칙은 보존	작업 맥락은 보존 안 됨
Compact	Claude Code 내장 `/compact` 명령으로 컨텍스트 압축	세션 유지	압축 과정에서 정보 손실

GSD의 차이점은 “수동”이 아닌 “자동화된 시스템”이라는 데 있다. 개발자가 언제 세션을 끊을지 판단할 필요 없이, 프레임워크가 알아서 분할하고 상태를 보존한다.

칠판 치트시트

┌─────────────────────────────────────────────────────┐
│  GSD 핵심 정리                                        │
│                                                       │
│  1. 오케스트레이터는 가볍게 (30~40%)                    │
│  2. 실제 작업은 매번 새 컨텍스트 서브에이전트            │
│  3. 상태는 마크다운 파일로 (PROJECT → PLAN → SUMMARY)   │
│  4. 설치: npx get-shit-done-cc@latest                 │
│  5. 시작: /gsd-new-project → discuss → plan → execute │
└─────────────────────────────────────────────────────┘

프로젝트 현황

GSD는 GitHub에서 빠르게 성장하고 있다. 원본 리포지토리(gsd-build/get-shit-done)는 2025년 12월에 만들어져 2026년 4월 기준 약 4.9만 스타를 기록 중이며, 매우 활발하게 유지보수되고 있다(가장 최근 커밋은 2026년 4월 7일). TÂCHES가 만들었고 MIT 라이선스로 공개됐다.

GSD Pro는 원본의 포크로, 롤백/복구, 5단계 컨텍스트 적재, 모델 라우팅 등을 추가한 확장판이다. 원본과 upstream 동기화를 유지하면서 추가 기능을 제공한다.

Discord 커뮤니티와 X(@gsd_foundation) 계정도 활발하게 운영되고 있어, 도입 시 참고할 만하다.

다음 읽기

이 글은 AI의 assistance를 받아 작성되었습니다 (2026-04-08).

일하는 ai

탐색기