[Tech Deep Dive] '바이브 코딩(Vibecoding)'의 환상과 절망, 그리고 GSD(Get Shit Done) 프레임워크가 찾은 해답
안녕하세요, 10년 차 개발자이자 기술의 이면을 들여다보길 좋아하는 탐험가입니다. 최근 X(트위터)나 레딧을 보면 온통 ‘바이브 코딩(Vibecoding)’ 이야기뿐입니다. Cursor를 켜거나 Claude Code에 대고 ‘유저 인증 붙인 To-Do 앱 만들어줘’라고 치면 눈앞에서 코드가 뚝딱 완성되는 시대죠. 처음엔 다들 환호했습니다. ‘이제 개발자 끝난 거 아니야?’ 하면서요.
하지만 현업에서 이런 툴로 조금만 규모 있는 프로젝트를 굴려보신 분들이라면, 며칠 못 가 깊은 절망감에 빠져본 경험이 있으실 겁니다. 요구사항이 조금만 복잡해지고, 수정 요청을 대여섯 번 반복하다 보면 어느 순간 AI가 완전히 ‘바보’가 되어버리거든요. A를 고치면 B가 망가지고, 아까 알려준 컨텍스트는 까맣게 잊어버린 채 엉뚱한 라이브러리를 임포트하고 있는 그 참담한 광경. 결국 꼬일 대로 꼬인 코드를 수습하느라 직접 키보드를 잡고 밤을 새우다 보면 이런 회의감이 듭니다. ‘내가 AI를 부리는 건지, AI가 싸질러 놓은 똥을 치우는 건지 모르겠다.’
그래서 엔터프라이즈급 AI 프레임워크라는 BMAD, SpecKit, Beads 같은 도구들에 눈을 돌려보기도 합니다. 그런데 이 녀석들은 또 너무 무겁습니다. 나 혼자 주말에 사이드 프로젝트 하나 만들려는데, 무슨 50명짜리 대형 엔지니어링 조직에서나 할 법한 애자일 스프린트와 회고(Retrospective)를 강요하죠. ‘나는 그냥 내 아이디어를 코드로 당장 구현하고 싶을 뿐인데, 왜 내가 엔터프라이즈 코스프레를 해야 하지?’
이런 전 세계 수많은 개발자들의 딥빡(?)을 정확히 타겟팅하며 2026년 초 혜성처럼 등장한 오픈소스 프로젝트가 있습니다. 이름부터 아주 날것의 냄새가 진동하는 GSD(Get Shit Done) 입니다. TÂCHES라는 개발자가 만든 이 프레임워크는 최근 깃허브에서 엄청난 속도로 4만 개가 넘는 별을 쓸어 담으며 AI 개발의 새로운 표준으로 자리 잡고 있습니다. 오늘 커피 한 잔과 함께 이 발칙하고도 강력한 프레임워크의 속살을 낱낱이 파헤쳐 보겠습니다.
TL;DR (The Core)
바쁘신 분들을 위해 한 줄로 요약하겠습니다. GSD는 단일 채팅창에 의존하던 기존 AI 코딩의 한계를 깨고, 상태(State)를 마크다운 파일로 외부화하여 매 작업마다 초기화된 컨텍스트(Fresh Context)에서 AI 에이전트를 실행시키는 초경량 메타 프롬프팅 및 스펙 기반 개발 시스템입니다.
Deep Dive: Under the Hood (도대체 속에서 무슨 일이 벌어지고 있는가?)
표면적으로 보면 GSD는 그저 Claude Code, OpenCode, Gemini CLI 같은 도구 위에 씌워진 래퍼(Wrapper)처럼 보일 수 있습니다. 하지만 내부 아키텍처를 뜯어보면, AI가 코드를 작성하는 ‘패러다임’ 자체를 완전히 뒤집어 놓았다는 것을 알 수 있습니다.
1. 컨텍스트 부패(Context Rot)와의 전쟁
우선 기존 방식의 가장 큰 문제인 ‘컨텍스트 부패(Context Rot)’ 를 이해해야 합니다. LLM은 본질적으로 비상태성(Stateless)을 가집니다. 그래서 우리가 에디터에서 AI와 채팅을 할 때, 시스템은 백그라운드에서 지금까지의 ‘모든’ 대화 기록을 프롬프트에 욱여넣어 모델에게 전달합니다. 처음엔 문제없죠. 하지만 Claude 3.5 Sonnet 같은 모델의 20만 토큰 컨텍스트 창이 꽉 차기 시작하면 어떻게 될까요? 모델의 Attention 메커니즘은 과거의 ‘실수했던 코드’, ‘폐기된 아이디어’, ‘수정 지시사항’ 등 쓰레기 정보들 사이에서 길을 잃습니다. GSD의 철학은 여기서 출발합니다.
‘제발 단일 채팅 스레드를 빌드 시스템으로 취급하지 마라.’
2. State Externalization (상태의 외부화)
GSD는 대화창에서 AI가 기억을 유지해야 한다는 강박을 버렸습니다. 대신, 모든 상태와 진행 상황을 철저하게 외부 파일로 뺍니다. 프로젝트를 시작하면 GSD는 다음의 4가지 핵심 아키팩트를 생성합니다.
PROJECT.md: 이 프로젝트의 근본적인 목적과 절대 변하지 않는 핵심 규칙.REQUIREMENTS.md: 구현해야 할 구체적인 기능 명세.ROADMAP.md: 전체 작업의 마일스톤.STATE.md: 현재까지 완료된 작업과 지금 당장 직면한 문제점 등 ‘현재의 스냅샷’. AI는 더 이상 과거의 긴 채팅 로그를 뒤지지 않습니다. 오직 이 파일들만 읽고 현재 자신이 무엇을 해야 하는지 파악합니다. 인간 개발자가 프로젝트에 새로 투입되었을 때 온보딩 문서를 읽는 것과 완벽히 동일한 아키텍처입니다.
3. Fresh Context Execution (초기화된 컨텍스트와 멀티 에이전트 오케스트레이션)
이 부분이 GSD의 진정한 마법입니다. GSD는 워크플로우를 Discuss -> Plan -> Execute -> Verify 단계로 쪼갭니다. 가장 흥미로운 건 Execute(실행) 단계입니다. Planner 에이전트가 앞으로 해야 할 일을 작고 검증 가능한 단위(Plan)로 쪼개놓으면, Executor 에이전트는 각 Plan을 실행할 때마다 완전히 새로운(빈) 컨텍스트 창을 띄웁니다. 즉, Step 1을 수행한 AI의 메모리는 Step 2를 수행하는 AI에게 전달되지 않습니다. Step 2의 AI는 오직 STATE.md와 자신에게 할당된 ‘목표’, 그리고 ‘현재 코드베이스의 상태’만을 주입받고 작업을 시작하죠. 이렇게 하면 200k의 컨텍스트 윈도우를 온전히 ‘순수한 구현’ 그 자체에만 쏟아부을 수 있습니다. 쓰레기 컨텍스트가 누적되지 않으니 AI의 퍼포먼스가 프로젝트 극초반의 날카로운 상태로 끝까지 유지되는 것입니다.
4. Atomic Git Commits와 방탄(Bulletproof) 검증
에이전트가 코드를 짰다고 바로 다음으로 넘어가지 않습니다. Verification 에이전트가 등판해 방금 작성된 코드가 Plan의 요구사항을 충족했는지 검증합니다. 통과하면? 작업 단위로 즉시 독립적인 Git Commit(Atomic Commit)을 생성합니다. 만약 프로젝트가 꼬인다면, 우리는 과거처럼 AI에게 ‘아까 그거 다시 되돌려봐’라고 구차하게 사정할 필요가 없습니다. 그냥 git bisect를 돌려서 문제가 발생한 정확한 커밋을 찾아 깔끔하게 롤백하면 그만입니다. 코어 로직의 불안정성을 Git의 견고함으로 덮어버린, 매우 엔지니어링다운 해결책이죠.
Hands-on: 당장 내 프로젝트에 어떻게 적용할까?
‘그래서 이거 당장 어떻게 쓰나요?’ 하시는 분들을 위해 실무적인 적용 시나리오를 그려보겠습니다. 사용법은 허무할 정도로 간단합니다. 터미널을 열고 아래 명령어를 치면 끝입니다. npm i get-shit-done-cc@latest 그다음 빈 디렉토리에서 /gsd:new-project를 입력하면 GSD 오케스트레이터가 가동되며 당신에게 묻습니다. ‘무엇을 만들고 싶으신가요?’
적용 시나리오 1: 풀스택 MVP의 안정적인 런칭 혼자서 React 프론트엔드와 Node.js 백엔드, DB 스키마까지 며칠 만에 뽑아내야 할 때 진가를 발휘합니다. 처음 Discuss 단계에서 ‘이러이러한 스펙의 서비스를 만들 건데, JWT 인증을 쓰고 DB는 PostgreSQL로 할게’라고 던져주면, GSD가 알아서 ROADMAP.md를 쪼갭니다. 당신은 그저 각 플랜이 실행되고 커밋되는 과정을 지켜보거나, 중간중간 STATE.md가 업데이트되는 방향이 맞는지 조타수 역할만 하면 됩니다. 실제로 이 시스템으로 30일 만에 AI 네이티브 음악 소프트웨어를 만들어 월 3만 달러 매출을 낸 사례도 커뮤니티에 보고된 바 있죠.
적용 시나리오 2: 더러운 레거시 마이그레이션 기존 바이브 코딩으로는 절대 불가능했던 영역입니다. 예를 들어 수백 개의 파일이 얽힌 구형 Vue 코드를 React로 포팅한다고 가정해 봅시다. GSD의 플랜 모드를 활용해 마이그레이션 단계를 20개로 잘게 쪼개도록 지시합니다. 각 단계는 오직 할당된 컴포넌트 하나만 변환하고 독립적으로 테스트 및 커밋을 진행하므로, 중간에 AI가 환각(Hallucination)을 일으켜 전체 구조를 망가뜨리는 대참사를 원천 차단할 수 있습니다.
Honest Review: 진짜 장단점 (마냥 완벽하기만 할까?)
시니어 개발자의 눈으로 냉정하게 평가해 보겠습니다. 이 도구, 확실히 혁신적이지만 치명적인 트레이드오프(Trade-off)도 존재합니다.
👍 압도적인 장점: ‘완성’을 경험하게 해 줍니다. 기존 AI 도구들이 장난감 수준의 데모를 만드는 데 그쳤다면, GSD는 실제 프로덕션 레벨까지 프로젝트를 멱살 잡고 끌고 갑니다. 컨텍스트가 무너지지 않으니, 프로젝트 후반부로 갈수록 생산성이 기하급수적으로 떨어지던 문제가 완벽히 해결됩니다. 정말 이름값(Get Shit Done)을 제대로 하죠.
👎 치명적인 단점 1: 생각보다 무겁고 비쌉니다. 매 Task마다 Fresh Context를 띄운다는 건, AI에게 매번 수천~수만 토큰 분량의 PROJECT.md와 코어 로직을 새로 읽힌다는 뜻입니다. 캐싱 기능이 완벽하게 지원되지 않는 특정 모델 API를 물려 쓸 경우, 토큰 연소 속도(Token Burn Rate)가 상상을 초월할 수 있습니다. 깃허브나 해커뉴스에서도 ‘결과물은 좋은데 10배 많은 토큰을 태운다’는 지적이 단골 논쟁거리죠.
👎 치명적인 단점 2: 기획력 없이는 파멸을 맞이합니다. 바이브 코딩은 내가 개떡같이 말해도 AI가 찰떡같이 만들어주는 맛이 있었습니다. 하지만 GSD는 철저한 ‘스펙 주도 개발(Spec-driven development)’입니다. REQUIREMENTS.md에 모호함이 있다면? AI는 그 모호함을 기가 막히게 효율적인 방식으로 아주 견고한 ‘쓰레기’로 만들어버립니다. 즉, 이 도구를 100% 활용하려면 개발자에게 ‘글로 명확한 명세를 작성하는 능력’이 강제됩니다.
Closing Thoughts: AI 시대, 개발자의 스탠스
GSD 프레임워크 코드를 뜯어보고 직접 돌려보면서 저는 확신했습니다. AI는 우리를 대체할 마법 지팡이가 아니라, 비결정론적(Non-deterministic) 컴파일러일 뿐이라는 사실을요.
우리가 C언어나 자바 코드를 짤 때 메모리 누수와 아키텍처를 고민하듯, 이제는 ‘자연어로 작성된 스펙과 컨텍스트의 흐름’을 엔지니어링해야 하는 시대가 도래했습니다. GSD는 그 과도기에서 ‘프롬프트 엔지니어링’이라는 모호한 기술을 ‘컨텍스트 아키텍처 설계’라는 어엿한 소프트웨어 공학의 영역으로 끌어올린 기념비적인 프로젝트입니다.
단순히 AI 에디터의 자동완성에 감탄하며 시간을 보내고 계신가요? 이번 주말에는 그 익숙한 굴레에서 벗어나 GSD를 한번 설치해 보시길 권합니다. 스펙을 정의하고, 에이전트가 독립된 환경에서 계획을 실행하며, 원자적 커밋(Atomic Commit)으로 족적을 남기는 이 견고한 워크플로우를 경험하고 나면, 다시는 과거의 ‘바이브 코딩’으로 돌아가기 힘드실 겁니다.
기술은 계속 발전하고 도구는 변하겠지만, 결국 언제나 핵심은 변하지 않습니다. 제대로 된 목표를 세우고, 견고한 구조 위에서 묵묵히 결과를 만들어내는 것. 말 그대로, Get Shit Done 하는 것 말이죠.
References
- https://github.com/gsd-build/get-shit-done
- https://medium.com/@agentnative/get-sh-t-done-meta-prompting-and-spec-driven-development-for-claude-code-and-codex-2026
- https://www.reddit.com/r/ClaudeCode/comments/1iwsxyz/get_shit_done_the_1_cc_framework_for_people_tired/
- https://medium.com/@solodev/i-tested-gsd-claude-code-meta-prompting-system-that-ships-faster-no-agile-bs-2026
