클로드 코드, 콘텍스트 부패, 그리고 GSD

참고 영상: AgentOS, "Claude Code + GSD — 기획부터 검증까지 자동화하는 법"

참고 저장소: github.com/gsd-build/get-shit-done (GitHub 스타 44,100개, 2026년 3월 기준)

제1부  클로드 코드

1  코드를 대신 짜주는 AI

클로드 코드(Claude Code)는 보통 챗봇과 다릅니다. 내 컴퓨터의 파일을 직접 읽고, 코드를 쓰고, 터미널 명령까지 실행합니다. 말하자면 옆에 앉아서 일하는 디지털 인턴입니다. 시키면 하는 수준이 아니라, 스스로 뭘 해야 하는지 판단하고, 어떤 도구를 쓸지 골라서 실행합니다. 이걸 에이전틱 워크플로우(Agentic Workflow)라고 부릅니다.

처음 써 보면 놀랍습니다. 파일 구조를 파악하고, 코드를 짜고, 테스트까지 알아서 돌립니다. 이 순간만 보면 천재입니다. 여기에 Google Stitch 같은 무료 디자인 도구를 MCP(Model Context Protocol)로 연결하면, 기획에서 디자인, 코딩까지 한 번에 쭉 이어서 할 수 있습니다. 돈 내고 Figma를 쓰지 않아도 됩니다.

2  그런데 한 시간 뒤에 벌어지는 일: 클로드 코드의 단점

한 시간쯤 지나면 상황이 달라집니다. 아까 만든 파일을 까먹습니다. 방금 정한 규칙을 무시합니다. 심하면 자기가 짠 코드를 덮어씁니다. 이건 사용자 잘못이 아닙니다. 클로드 코드가 가진 구조적 한계입니다.

비유하면 이렇습니다. 머리가 아주 좋은 신입 인턴이 왔는데, 심한 단기기억상실증이 있습니다. 시키면 척척 해내지만, 한 시간 전에 뭘 했는지 기억을 못 합니다. 게다가 이 인턴이 앉은 책상 위에는 쓰레기가 산더미입니다. 취소된 기획서, 예전 오류 메시지, 삭제한 코드 조각들이 뒤섞여 쌓여 있습니다. 이 인턴은 쓰레기 더미를 뒤지다가 정작 중요한 설계 규칙을 놓칩니다.

이 현상에는 이름이 붙어 있습니다. 콘텍스트 부패(Context Rot)입니다.

제2부  왜 클로드 코드는 시간이 갈수록 멍청해지는가 (콘텍스트 부패)

1  메모장이 꽉 차는 문제

클로드 코드에게는 작업 기억이 있습니다. 전문 용어로 컨텍스트 윈도우(Context Window)라고 하는데, 쉽게 말하면 메모장입니다. 대화를 하면 할수록 이 메모장이 차오릅니다. 100만 토큰이든 200만 토큰이든, 메모장에는 끝이 있습니다.

메모장이 차기 시작하면 품질이 떨어집니다. 앞에서 정한 규칙을 잊어버리고, 같은 실수를 되풀이하고, 코드 스타일이 갈수록 뒤죽박죽이 됩니다. 이게 콘텍스트 부패입니다. 일할수록 클로드 코드가 점점 멍청해지는 현상입니다.

200만 토큰이라는 숫자가 크게 들리지만, 쓰레기로 가득 찬 메모장은 아무 소용이 없습니다. 쓰레기를 넣으면 쓰레기가 나옵니다.

2  가운데를 까먹는 AI: 스탠포드 '미들에서 길을 잃다' 연구

스탠포드 대학 연구팀이 밝혀낸 사실이 있습니다. 논문 이름은 "Lost in the Middle(미들에서 길을 잃다)"입니다. AI는 정보의 처음과 끝은 잘 기억하는데, 가운데에 있는 정보는 잘 잊어버립니다. 이걸 U자형 기억 곡선이라고 합니다.

대화가 길어지면 쓸모없는 정보가 가운데에 쌓이고, 정확도가 30% 넘게 떨어집니다. 그래서 처음에 정한 규칙을 무시하거나, 자기가 짠 코드를 또 만들거나, 멀쩡한 코드를 엉뚱하게 덮어쓰는 일이 생기는 겁니다.

이 현상이 MCP와 만나면 더 심해집니다. MCP 도구 설명서가 55,000 토큰짜리 덩어리로 대화 중간에 떡하니 자리 잡으면, AI의 주의력이 그쪽으로 흩어집니다. 정작 사용자가 시킨 일, 예를 들어 "매출 데이터를 분석해 줘" 같은 핵심 지시가 묻혀 버립니다.

3  고치려다 더 꼬이는 악순환

이 현상 때문에 바이브 코딩이 벽에 부딪힙니다. 처음에는 잘 되니까 신나서 계속 시킵니다. 그런데 프로젝트가 커지면 메모장이 넘치면서 버그가 쏟아집니다. 그걸 고치라고 또 시키면 더 꼬입니다. 이 악순환 때문에 "AI 코딩은 시제품(프로토타입)까지만 쓸 수 있다"는 말이 나온 겁니다.

4  클로드 코드 사용자가 '수락 원숭이'가 되어가는 상황

AI 쪽 문제만 있는 게 아닙니다. 사용자 쪽에도 함정이 있습니다.

와튼 경영대학원(University of Pennsylvania Wharton School)에서 실험을 했습니다. 참가자들에게 논리 문제를 풀게 하면서 AI 도우미를 붙여 줬습니다. 그런데 이 AI가 일부러 틀린 답을 냈습니다. 결과가 충격적이었습니다. 참가자의 79.8%가 AI의 틀린 답을 의심 없이 받아들였습니다. AI 없이 혼자 풀었을 때보다 정답률이 31.5%로 떨어졌습니다. AI를 안 쓴 쪽이 오히려 더 잘 맞혔다는 뜻입니다.

이걸 인지적 항복(Cognitive Surrender)이라 부릅니다. AI가 내놓는 답을 따지지 않고 그냥 받아들이는 현상입니다. "확인" 버튼만 누르는 수락 원숭이(Accept Monkey)가 되는 순간, 코드 전체가 걷잡을 수 없이 무너집니다.

5  MCP가 토큰을 잡아먹는 문제: 꽃밭에 포크레인을 들이밀다

비용 쪽에서도 허점이 있습니다. MCP 서버를 연결하면 도구 설명서(Description)만으로 한 세션에 약 55,000 토큰(약 0.16달러)을 씁니다. 같은 일을 CLI 기반 스킬(Skills) 방식으로 하면 200에서 500 토큰이면 됩니다. 20배에서 32배 차이입니다.

실제 테스트 환경에서 MCP의 TCP 타임아웃 실패율은 28%입니다. 열 번 시도하면 세 번은 실패한다는 뜻입니다. CLI 방식의 실패율은 거의 0%입니다.

MCP를 많이 쓰는 사용자는 토큰 비용만으로 한 달에 200달러가 넘게 나갑니다. 꽃밭에 포크레인을 끌고 온 격입니다. 메모장을 쓸데없이 채워서 지능이 떨어지고, 실패율은 높고, 돈까지 더 나갑니다. 대부분의 작업은 CLI 명령 한 줄이면 끝나는데, 55,000 토큰짜리 MCP 설명서를 매번 불러들이는 건 낭비입니다.

제3부  GSD(Get Shit Done: 일좀 합시다): 부패를 막는 시스템

1  GSD가 뭔가

이 문제를 정면으로 풀겠다고 나온 도구가 GSD(Get Shit Done)입니다. GitHub에서 44,100개 스타를 받았고, 아마존, 구글, 쇼피파이(Shopify), 웹플로우(Webflow) 엔지니어들이 쓰고 있습니다.

GSD는 코드를 대신 짜주는 도구가 아닙니다. 코드는 클로드 코드가 짭니다. GSD는 클로드 코드가 잘 짜도록 만들어 주는 도구입니다. 메모장(컨텍스트)을 관리해 주는 게 본질이어서, 메타프롬프팅 시스템이라고 부릅니다.

만든 사람의 소개가 이 도구의 철학을 압축합니다. "나는 솔로 개발자다. 코드를 안 짠다. 클로드 코드가 짠다." 스프린트니 레트로스펙티브니 하는 의례적 절차를 '엔터프라이즈 코스프레(대기업 흉내)'라 부르며 거부합니다.

2  설치 방법

설치는 터미널에서 한 줄이면 끝납니다.

이 명령을 치면 화면에 선택지가 나옵니다.

가. 어떤 AI 도구에 설치할 건지 고릅니다. 클로드 코드 말고도 OpenCode, Gemini CLI, Codex, GitHub Copilot, Cursor, Windsurf, Antigravity까지 모두 8가지 도구를 지원합니다.

나. 어디에 설치할 건지 고릅니다. 전역(Global)을 고르면 내 컴퓨터의 모든 프로젝트에서 쓸 수 있고, 로컬(Local)을 고르면 지금 작업 중인 프로젝트에서만 씁니다.

물어보는 거 없이 바로 설치하고 싶으면 이렇게 칩니다.

클로드 코드에 전역으로 설치한다는 뜻입니다. 설치가 끝나면 클로드 코드 안에서 /gsd:help를 쳐서 잘 들어갔는지 확인합니다.

GSD를 쓸 때는 클로드 코드를 권한 생략 모드로 실행하는 걸 권장합니다.

이렇게 하면 파일을 만들거나 고칠 때마다 일일이 허락을 구하지 않아서, 작업이 끊기지 않고 쭉 이어집니다.

3  GSD가 만드는 파일들

GSD는 프로젝트 폴더 안에 .planning/이라는 폴더를 만들고, 여기에 모든 정보를 마크다운 파일로 저장합니다.

1-CONTEXT.md — 1단계에서 사용자가 내린 결정들

1-RESEARCH.md — 1단계에서 조사한 내용

1-01-PLAN.md — 1단계 첫 번째 세부 계획

1-01-SUMMARY.md — 1단계 첫 번째 계획 실행 결과

1-VERIFICATION.md — 1단계 검증 결과

이 파일들이 클로드 코드의 영구 기억이 됩니다. 대화가 길어져서 메모장이 넘쳐도, 이 파일들은 사라지지 않습니다.

4  GSD 작업 흐름: 6단계

GSD의 작업 흐름은 여섯 단계입니다. 슬래시 커맨드(/)를 쳐서 각 단계를 실행합니다.

가. 코드베이스 분석: /gsd:map-codebase

이미 코드가 있는 프로젝트에 GSD를 처음 붙일 때 씁니다. 여러 개의 AI 에이전트가 동시에 돌면서 기존 코드의 구조, 기술 스택, 문제점을 파악합니다. 새 프로젝트라면 이 단계는 건너뜁니다.

나. 프로젝트 초기화: /gsd:new-project

이 명령을 치면 GSD가 질문을 쏟아냅니다. "뭘 만들 건가? 기술 스택은? 제약 조건은? 예외 상황은?" 머릿속에 있는 막연한 기획을 억지로라도 구체적으로 만드는 과정입니다. 질문에 답하다 보면 PROJECT.md, REQUIREMENTS.md, ROADMAP.md 같은 문서가 자동으로 만들어집니다.

--auto 옵션을 붙이면 GSD가 질문 없이 알아서 문서를 만들어 줍니다.

다. 단계별 논의: /gsd:discuss-phase 1

해당 단계에서 애매한 부분을 GSD가 찾아서 물어봅니다. "화면은 카드 형태로 할 건가, 표 형태로 할 건가?" "오류 메시지는 팝업으로 띄울 건가, 화면 안에 넣을 건가?" 이런 질문들입니다.

이 단계를 건너뛰면 클로드 코드가 마음대로 정합니다. 나중에 "이거 아닌데" 하고 뒤엎으면 시간이 두세 배 더 걸립니다. 그래서 미리 정해 두는 겁니다. 결과는 1-CONTEXT.md에 저장됩니다.

라. 계획 수립: /gsd:plan-phase 1

여기서 진짜 재미있는 일이 벌어집니다. GSD가 먼저 조사(리서치)를 합니다. 어떤 라이브러리가 좋은지, 어떤 방식이 맞는지 살펴봅니다. 그다음 계획서를 만듭니다. 할 일 이름, 고칠 파일, 뭘 해야 하는지, 끝나면 어떻게 확인하는지가 다 적혀 있습니다.

계획서를 만든 뒤에는 gsd-plan-checker라는 검사 에이전트가 "이 계획대로 하면 목표가 달성되나?"를 따집니다. 안 되면 통과할 때까지 다시 짭니다.

계획서 하나의 크기는, 에이전트 하나가 혼자 끝낼 수 있는 분량으로 맞춥니다. 너무 크면 쪼개고, 너무 작으면 합칩니다. 이걸 원자적(Atomic) 계획이라 합니다.

마. 실행: /gsd:execute-phase 1

GSD가 계획서들을 웨이브(Wave)라는 묶음으로 나눕니다. 서로 관련 없는 계획서들은 같은 웨이브 안에서 동시에 돌리고, 앞 계획이 끝나야 시작할 수 있는 건 다음 웨이브로 넘깁니다.

여기서 핵심이 나옵니다. 계획서 하나를 실행할 때마다 새로운 서브 에이전트(sub-agent)가 뜹니다. 이 에이전트는 깨끗한 메모장(20만 토큰)을 가지고 태어나서, 맡은 계획서 하나만 처리합니다. 본체(오케스트레이터)는 교통정리만 하기 때문에 메모장의 30에서 40%만 차 있습니다. 아무도 메모장이 꽉 차지 않으니까, 콘텍스트 부패가 일어나지 않습니다.

일 하나가 끝날 때마다 자동으로 git commit이 됩니다. 나중에 문제가 생기면 git bisect로 정확히 어느 작업에서 고장 났는지 찾을 수 있습니다.

GSD 안에는 다섯 종류의 전문 에이전트가 있습니다.

바. 검증: /gsd:verify-work 1

코드가 있는지, 테스트가 통과하는지 자동으로 확인합니다. 거기서 끝이 아니라 사용자한테 직접 해 보라고 합니다. "로그인이 되나? 버튼 누르면 동작하나?" 기계가 통과시킨 것과 사람이 써 봤을 때 되는 것은 다르니까요. 문제가 있으면 gsd-debugger가 원인을 찾고 수정 계획서를 만듭니다.

이 사이클을 한 바퀴 돌고 나면, 다음 단계로 넘어갑니다.

5  그 밖의 슬래시 커맨드

6  모델 프로필 설정

7  왜 기존 방식보다 나은가

가. 메모장 격리

팀장이 프로젝트를 혼자 다 하면 머리가 터집니다. 그래서 팀원 네 명한테 일을 나눠 줍니다. "전체를 다 알 필요 없어. 네 담당 부분만 해. 이 기획서 보고 해." 그 기획서가 Plan 단계에서 만든 PLAN.md입니다. 팀원은 기획서만 읽으면 되니까 머리가 깨끗합니다. 팀장(오케스트레이터)은 "이거 먼저, 저거 다음"이라고 순서만 잡아 줍니다. 누구의 메모장도 꽉 차지 않습니다.

나. 정리된 문서로 전달

보통은 채팅으로 이것저것 시킵니다. "이거 만들어 줘." "아 그거 말고." "아까 그 파일 다시 고쳐 줘." 이 대화가 전부 메모장에 쌓이는데, 이 가운데 쓸모 있는 정보가 얼마나 될까요? GSD는 대화 대신 정리된 마크다운 파일을 전달합니다. 잡다한 10만 토큰보다 핵심만 추린 2만 토큰이 훨씬 낫습니다.

다. 스스로 확인하는 구조

팀원한테 일을 시킬 때 "다 하면 이거 확인해 봐"까지 적어 줍니다. 팀장한테 "끝났어요" 하기 전에 본인이 먼저 점검합니다. 이 세 가지, 메모장 격리, 정리된 문서, 스스로 확인을 합치면 콘텍스트 부패가 구조적으로 일어날 수 없는 환경이 됩니다.

제4부  자동 메모리 청소: autodream과 /dream

1  잠자면서 기억을 정리하는 AI

GSD가 작업 도중(세션 안에서) 부패를 막는다면, 클로드의 autodream 기능은 작업 사이(세션과 세션 사이)의 기억을 깨끗하게 유지합니다. 사람이 잠을 잘 때 뇌가 낮에 받은 정보를 정리하는 것처럼, AI도 세션이 끝난 뒤 낡은 정보를 걸러내고 꼭 필요한 것만 남깁니다.

2  네 단계로 기억을 정리합니다

가. 훑어보기(Orientation) — 흩어져 있는 기억 파일과 코드베이스를 쭉 읽어서 전체 지도를 그립니다.

나. 신호 찾기(Gather Signal) — 사용자의 코딩 스타일, 설계 결정, 되풀이되는 패턴처럼 쓸모 있는 정보를 골라냅니다.

다. 다듬기(Consolidation) — "어제"처럼 시간이 지나면 뜻이 바뀌는 표현을 정확한 날짜(예: 2026-03-27)로 바꾸고, 서로 모순되는 내용을 정리합니다. 프레임워크를 바꿨는데 옛날 정보가 남아 있는 경우가 대표적입니다.

라. 가지치기(Prune and Index) — 쓸모없어진 농담, 오류 메시지, 취소된 계획을 지웁니다. 남은 정보를 압축하고 색인을 달아서, 다음 세션을 열 때 빠르게 읽을 수 있게 합니다.

3  안전장치

autodream은 24시간이 지나고 5번 이상 세션을 열었을 때만 자동으로 돌아갑니다. 여러 사람이 동시에 같은 프로젝트를 쓸 때 기억이 꼬이지 않도록 잠금(Lock) 장치가 있습니다. 코드를 크게 뜯어고친 직후에는 dream 명령어를 직접 쳐서 기억을 수동으로 정리하는 게 좋습니다.

제5부  오토 모드와 일괄 코드 리뷰

1  오토 모드: 문지기 AI가 지키는 자동 실행

클로드 코드에는 오토 모드(Auto Mode)가 있습니다. 사람이 매번 "확인" 버튼을 누르지 않아도 AI가 알아서 코드를 짜고 실행합니다. 위험하게 들리지만 안전장치가 있습니다.

2단계 방어 체계입니다. 코드를 짜는 AI 뒤에 문지기 AI(Gatekeeper)가 서 있습니다. 이 문지기가 실행 직전에 코드를 검사합니다. 서버를 무단으로 띄우려 하거나, 파일 시스템에 위험한 접근을 시도하면 차단합니다. 문지기 AI의 오류율은 0.4%입니다. 사람이 코드 리뷰하는 것보다 낮은 수치입니다.

2  일괄 코드 리뷰: 여러 전문가가 동시에 훑는다

GSD의 실행 단계에서 볼 수 있는 장면입니다. 여러 AI 전문 에이전트가 동시에 코드를 리뷰합니다. 한 테스트에서 69줄짜리 엉킨 코드를 넣었더니, 1분 29초 만에 33줄로 압축해서 돌려줬습니다. 중복을 찾아내고, 논리적으로 맞지 않는 부분을 잡아내고, 깔끔하게 다듬은 겁니다.

사람 한 명이 하면 한 시간은 걸릴 작업입니다. 여러 에이전트가 각자 깨끗한 메모장을 가지고 동시에 달려드니까 이런 속도가 나옵니다.

제6부  claude.md: AI를 위한 신입사원 안내서

1  2분 투자로 수십 시간을 아끼는 법

클로드 코드를 처음 실행하면 프로젝트 폴더에서 claude.md라는 파일을 찾습니다. 이 파일이 있으면 읽고 시작하고, 없으면 맨바닥에서 출발합니다.

비유하면 신입사원이 첫 출근했을 때 받는 안내서입니다. "우리 팀은 코드 스타일을 이렇게 쓴다. 모르는 게 있으면 먼저 물어봐라. 테스트는 반드시 돌려라." 이런 내용이 적혀 있으면 신입이 헤매는 시간이 줄어듭니다.

claude.md도 마찬가지입니다. 코딩 스타일, 질문 규칙, 포맷 지침을 적어 두면, 클로드 코드가 엉뚱한 방향으로 빠지는 일이 확 줄어듭니다. 작성하는 데 2분이면 됩니다. 그 2분이 디버깅에 들어갈 수십 시간을 아껴 줍니다.

제7부  AI가 스스로 진화하는 시대: 사카나 AI 사이언티스트와 오토하니스

1  AI가 논문을 쓰고 스스로 심사한다: 사카나 AI 사이언티스트

사카나(Sakana) AI가 만든 AI 사이언티스트(AI Scientist)라는 시스템이 있습니다. 이 시스템은 기존 논문을 읽고, 새로운 연구 아이디어를 스스로 제안하고, PyTorch로 실험 코드를 짜고, 실험을 돌리고, 데이터를 분석하고, 그래프를 만들고, LaTeX으로 논문을 쓰고, 자기가 쓴 논문을 자기가 심사합니다.

이 시스템이 쓴 논문을 네이처(Nature) 블라인드 리뷰에 넣었더니, 10점 만점에 6.33점을 받았습니다. 사람이 쓴 논문의 55%보다 높은 점수입니다. AI가 연구 아이디어를 내고, 코드를 짜고, 논문을 쓰고, 심사까지 하는 전 과정을 혼자 해낸 겁니다.

2  싸고 작은 AI가 비싼 AI를 이기다: 오토하니스(AutoHarness)

오토하니스(AutoHarness)라는 연구가 있습니다. 작고 저렴한 AI 모델(Gemini 2.0 Flash)한테 스스로 검증 코드를 짜게 했습니다. 규칙을 지키는지 확인하는 코드를 AI가 직접 만들고, 환경에서 피드백을 받아서 고치고, 다시 돌리는 과정을 반복하게 한 겁니다.

결과가 놀라웠습니다. 이 작은 모델이 GPT-4보다 성능 지표에서 앞섰습니다. 비싼 모델을 쓰는 것보다 스스로 확인하는 구조를 갖추는 게 더 중요하다는 뜻입니다. GSD의 철학과 정확히 같습니다. 검증 시스템이 모델 크기를 이깁니다.

제8부  컨텍스트 엔지니어링: 프롬프트 다음 단계

1  GSD가 진짜 풀고 있는 문제

GSD가 풀고 있는 문제를 콘텍스트 부패에 한정하면 절반만 보는 겁니다. 진짜 문제는 AI와 사람 사이의 소통입니다.

클로드 코드한테 일을 잘 못 시키는 이유는, 머릿속에 있는 걸 정확하게 전달하지 못하기 때문입니다. "대충 이런 느낌으로 만들어 줘"라고 하면 "대충 이런 느낌"으로 나옵니다. GSD는 이 전달 과정을 체계적으로 바꾸었습니다. 질문으로 애매한 걸 또렷하게 만들고, 문서로 정리하고, 깔끔한 형태로 넘깁니다.

2  프롬프트 엔지니어링과 뭐가 다른가

프롬프트 엔지니어링은 "어떻게 말하느냐"의 문제였습니다. 컨텍스트 엔지니어링은 "무엇을, 언제, 얼마만큼 보여주느냐"의 문제입니다. 한 차원이 다릅니다.

이 눈으로 보면 GSD가 하는 모든 것이 이해됩니다. 왜 질문을 많이 하는가, 쓸 만한 정보를 뽑아내려고. 왜 문서를 만드는가, 정보를 정돈하려고. 왜 서브 에이전트를 쓰는가, 각 에이전트한테 꼭 필요한 정보만 주려고. GSD의 핵심은 슬래시 커맨드 몇 개가 아닙니다. "AI한테 일을 제대로 시키려면, 넘겨주는 정보를 설계해야 한다"는 원칙입니다.

제9부  지금 바로 쓸 수 있는 세 가지 원칙

GSD를 깔지 않더라도 가져갈 수 있는 원칙이 있습니다.

1  대화를 줄이고 문서를 늘리십시오

클로드 코드한테 채팅으로 이것저것 시키지 말고, claude.md에 프로젝트 구조와 규칙을 정리하십시오. 스킬 파일에 되풀이되는 지시를 적어 두십시오. 정보의 질이 올라가면 결과의 질이 올라갑니다.

2  큰 작업은 쪼개서 시키십시오

"이 앱 전체를 만들어 줘"는 최악입니다. "로그인 API부터 만들어 줘. 스펙은 이거야. 끝나면 이 테스트로 확인해 줘." 이렇게 작은 단위로 시키면 메모장이 넘칠 일이 없습니다.

3  검증을 자동으로 돌리십시오

테스트 코드를 먼저 짜고, 클로드 코드한테 구현을 맡기십시오. 테스트가 통과하면 된 거고, 안 되면 다시 시키면 됩니다. 안전망이 있으면 마음 놓고 맡길 수 있습니다. AI가 내놓는 결과를 따지지 않고 "확인" 버튼만 누르는 수락 원숭이가 되지 마십시오. 최종 설계자이자 감독으로서 결과물을 꼼꼼히 살펴야 합니다.

제10부  맺음말: 누가 누구를 훈련시키는가

클로드 코드가 일할수록 멍청해지는 건 콘텍스트 부패입니다. 메모장이 차면서 품질이 썩는 현상입니다. GSD는 이걸 메모장 격리, 정리된 문서 전달, 작은 단위 계획 실행으로 해결했고, autodream은 세션 사이의 기억 청소로 장기적 일관성을 지켜 줍니다.

사카나 AI 사이언티스트는 연구 아이디어를 내고 논문까지 씁니다. 오토하니스의 작은 AI는 스스로 검증 코드를 만들어서 비싼 AI를 이겼습니다. autodream은 매일 밤 스스로 기억을 정리합니다. AI는 이미 스스로 계획하고, 스스로 검증하고, 스스로 기억을 관리하는 단계에 들어섰습니다.

그렇다면 키보드 앞에 앉은 사람의 역할은 뭘까요. 코드를 치는 게 아닙니다. "어떻게 말하느냐"도 아닙니다. "무엇을, 언제, 어떤 모습으로 넘겨주느냐"가 승부를 가릅니다.

한 가지 질문이 남습니다. 우리가 AI를 다루는 작업 흐름을 설계하고 있다고 생각했는데, 어쩌면 AI가 우리를 훈련시키고 있는 건 아닐까요. 더 정확하게 지시하고, 더 체계적으로 생각하고, 더 엄격하게 검증하도록. 시스템이 바뀌고 있는 게 아니라, 사람이 바뀌고 있는 건지도 모릅니다.