컨텍스트 부패(Context Rotting) — 윈도우의 한계가 만드는 망각
2.1 들어가며 — 어제까지 멀쩡하던 코드가 오늘 무너지는 이유
Chapter 1 은 한 번의 질문 을 정교하게 다듬는 자세 — 역할 / 맥락 / 형식 / 루프의 4 슬롯 — 으로 끝났다. 그러나 그 4 슬롯은 한 번의 호출 안에서만 작동한다. 우리가 AI 와 연속된 대화 를 이어가는 순간, 새로운 적이 등장한다. 그 적의 이름은 컨텍스트 부패(Context Rotting) — 시간이 지날수록 모델이 이전에 합의한 결정을 망각 하고, 망각된 결정에 어긋나는 새 코드를 멀쩡한 듯 생성해 결국 시스템 전체를 무너뜨리는 현상이다 concept/context-rot.
이 챕터의 첫 단어를 부패(Rot) 로 고른 이유는 분명하다. 오염(Contamination) 이라면 처음부터 더럽다는 뜻이지만, 부패 는 처음에는 멀쩡하다가 시간이 지나며 망가진다 는 뜻이다. 컨텍스트는 우리가 처음 AI 와 대화를 시작할 때는 깨끗하다. 4 슬롯이 정확히 기록되어 있고, 합의한 아키텍처가 또렷하다. 그런데 30 분이 지나고, 1 시간이 지나고, 며칠이 지나면, 같은 AI 가 이전 결정을 잊고 다른 패턴으로 코드를 짠다. 어제 우리가 PostgreSQL 14 의 무중단 마이그레이션 으로 합의했던 결정이, 오늘은 MySQL 의 잠금 패턴 으로 답변되어 돌아온다.
본 장은 이 부패의 해부학 이다. 왜 모델이 망각하는지(트랜스포머 아키텍처의 구조적 한계 + 컨텍스트 윈도우의 토큰 상한), 어떻게 부패가 누적되는지(4 단계 메커니즘), 어떤 증상 으로 표면화되는지(미들웨어 흩어짐 · 함수 중복 정의 · 기술 스택 중간 변경), 그리고 왜 이 한계가 곧 컨텍스트 엔지니어링 이라는 새 패러다임을 강제했는지를 차례로 짚는다. 본 장의 결론을 미리 박자면 — AI 가 망각하는 것이 잘못이 아니라, 우리가 영구 지시어를 박지 않은 것이 잘못이다.
2.2 핵심 개념 — Stateless · 컨텍스트 윈도우 · Lost in the Middle
2.2.1 모든 것의 근원 — Stateless 모델
오늘날 우리가 쓰는 모든 LLM(Large Language Model, 대규모 언어 모델) 은 Stateless (무상태) 다. 즉 이전 대화 의 어떤 정보도 모델 내부 에 저장되지 않는다. 우리가 ChatGPT(챗지피티) 와 1 시간 동안 대화를 이어가더라도, 매 메시지마다 모델은 처음 만난 사람처럼 입력을 받는다. 대화의 연속성 처럼 보이는 것은 사실 클라이언트 (브라우저·IDE) 가 이전 대화를 매번 다시 통째로 보내주는 기법이다.
이 점이 결정적이다. 대화가 길어질수록 클라이언트가 보내야 하는 텍스트의 양 이 기하급수적으로 늘어난다. 첫 질문 1 KB, 다음 질문 + 이전 대화 5 KB, 그 다음 질문 + 더 긴 이전 대화 12 KB ... 이렇게 누적되다가 어느 순간 모델이 한 번에 처리할 수 있는 컨텍스트 윈도우 의 한계를 넘는다.
2.2.2 컨텍스트 윈도우 — 모델의 단기 기억 용량
컨텍스트 윈도우(Context Window) 는 한 번의 추론 에서 모델이 함께 처리할 수 있는 입력 + 출력 토큰의 최대치 다 term/context-window. 이는 사실상 모델의 단기 기억 용량 이다. 2022년 GPT-3.5 시대에는 이 윈도우가 4K8K 토큰 (대략 한국어 3,0006,000 자) 에 불과했고, GPT-4 가 128K 로 확장됐으며, 2026 년 현재 Claude Opus 4.7 은 1M (백만) 토큰까지 처리한다. 외형상 윈도우가 250 배 커진 셈이다.
그러나 이 250 배 확장 이 250 배의 안정성 을 의미하지는 않는다. 윈도우가 커진다고 그 안에 들어간 정보가 모두 동등하게 활용 되지는 않기 때문이다. 여기서 두 번째 적이 등장한다.
2.2.3 Lost in the Middle — 중간에서 길을 잃는다
Lost in the Middle 은 입력이 길어질수록 모델이 문맥의 중간에 위치한 중요한 정보를 놓치는 현상이다. 트랜스포머(Transformer) 아키텍처의 attention 메커니즘은 입력의 시작과 끝 에 주의를 더 많이 기울이는 통계적 편향이 있어, 긴 입력의 가운데 에 기록된 결정 사항은 모델이 체계적으로 잊는다. 그래서 1M 토큰의 윈도우를 꽉 채워서 작업을 시키면, 시작 부분의 시스템 프롬프트와 끝 부분의 마지막 질문 사이의 수백 K 토큰 이 사실상 주의 사각지대 가 된다.
이 두 효과 — Stateless 누적 + Lost in the Middle — 이 결합되면 무엇이 일어나는가. 대화가 길어질수록 이전에 합의한 결정 이 문맥의 중간 에 묻히고, 묻힌 결정은 체계적으로 망각 된다. 30 분 전에 "우리는 PostgreSQL 14 만 쓴다" 라고 합의했던 결정이, 한 시간 뒤 MySQL 의 잠금 패턴 으로 답변되어 돌아온다. AI 의 잘못이 아니라, 모델 아키텍처의 구조적 한계 가 그렇게 만든다.
2.2.4 더 깊은 원인 — 메모리 하드웨어의 물리적 한계
여기서 한 단계 더 내려가야 한다. 왜 컨텍스트 윈도우는 본질적으로 제한되는가. 왜 1M 토큰을 처리하면서도 모델이 중간을 놓치는가. 그 답은 결국 물리 메모리 에 있다. 트랜스포머의 attention 연산은 모든 토큰 쌍 사이의 관계 를 동시에 메모리에 올려야 한다. 토큰 수가 N 이면 attention 행렬의 크기는 N² 이다. 1K 토큰 → 100 만 셀, 100K 토큰 → 100 억 셀, 1M 토큰 → 1 조 셀. KV 캐시(Key-Value Cache) · FlashAttention · sparse attention 같은 압축 알고리즘이 이 제곱 폭발 을 완화하지만, 완전히 없애지는 못한다. 결국 한계는 GPU 의 HBM(High Bandwidth Memory, 고대역폭 메모리) 용량으로 회귀한다.
여기서 산업 전체를 흔드는 비대칭이 등장한다. AI 모델의 크기와 컨텍스트 수요는 매년 약 10 배씩 성장하지만, HBM 생산 능력은 연 30~50% 성장에 그친다. Samsung·SK Hynix·Micron 의 HBM 팹(Fab) 은 새 라인 하나를 지어 양산까지 18~24 개월 이 걸리는데, 그 사이에 GPT 와 Claude 의 모델 세대는 두 번 바뀐다. NVIDIA H100·H200·B200 GPU 한 장에 박히는 HBM 이 80GB → 141GB → 192GB 로 증가하는 동안, 같은 GPU 한 장의 가격은 4 만 달러를 넘었고, 데이터센터급 H100 클러스터의 시간당 임대료가 분 단위로 정해진다. 이것이 메모리 수요 폭발 의 정체다.
따라서 컨텍스트 부패는 알고리즘의 미숙함 에서 비롯된 일시적 문제가 아니다. 물리적 자원의 절대량 제약 에서 비롯된 구조적 문제이며, 압축 기술의 발전 속도가 모델 성장 속도를 따라가지 못하는 한 앞으로 5~10 년은 지속될 제약이다. 그래서 사용자가 할 수 있는 일은 분명하다 — 무한정 커지지 않는 윈도우 안에 어떤 정보를 어떤 밀도로 박을지 통제하는 것. 본 장 §2.4 의 4 가지 처방이 모두 이 통제 의 다른 표현이다.
2.3 역사적 · 기술적 맥락 — 부패의 4 단계 메커니즘
2.3.1 1 단계 — 대화 시작 (깨끗한 컨텍스트)
처음 AI 와 대화를 시작할 때, 우리는 보통 명확한 의도 와 짧은 맥락 을 기록한다. 4 슬롯이 정확히 채워지고, 합의한 결정 사항이 컨텍스트의 맨 앞 (즉 attention 이 가장 잘 닿는 위치) 에 놓인다. 첫 시간은 마법 같다. AI 가 우리의 의도를 정확히 읽고, 합의한 패턴 안에서 깨끗한 코드를 짠다.
2.3.2 2 단계 — 시간 누적 (윈도우 한계 접근)
대화가 30 분, 1 시간을 넘어가면 컨텍스트가 윈도우의 한계에 가까워진다. 모델은 이전 메시지의 일부를 잘라내거나, 요약 하거나, attention 가중치를 분산 시킨다. 이 시점에서 모델은 이전 결정의 디테일 을 부분적으로 잊기 시작한다. 우리는 알아채지 못한다. AI 의 응답은 여전히 유창하기 때문이다. 망각이 시작된 신호는 유창함 속에 숨어 있다.
2.3.3 3 단계 — 충돌 생성 (망각된 결정에 어긋나는 코드)
망각이 누적되면 모델이 이전 결정과 충돌하는 새 코드 를 작성한다. 이 단계가 가장 위험하다. 새 코드는 문법적으로 정확 하고 논리적으로 그럴듯 하다. 그러나 시스템 전체의 일관성 을 깨뜨린다. 동일한 함수가 두 곳에서 다르게 정의되고, 미들웨어가 6 개 파일에 무질서하게 흩어지며, 어제까지 PostgreSQL 로 합의했던 데이터 계층이 오늘 갑자기 SQLite 코드 조각 을 끌어온다. 이 단계의 학술적 명칭이 요구사항 표류(Requirements Drift) 다.
2.3.4 4 단계 — 재작성 강제 (3 개월의 벽)
충돌이 누적되면 결국 전체 재작성 외에는 답이 없는 지점이 온다. 이 지점이 바로 concept/vibe-coding 의 3 개월의 벽 이다. 의도 중심 개발 (Lovable, Replit, v0, Bolt 같은) 로 시작한 프로젝트가 약 3 개월쯤에 도달하면, 누적된 부패가 임계치를 넘어 작은 변경 한 번이 시스템 전체를 깨뜨리는 상태가 된다. Anthropic(앤스로픽) 의 RCT(Randomized Controlled Trial, 무작위 대조 시험) 연구가 보고한 디버깅 능력 17% 하락 도 이 메커니즘과 같은 뿌리에서 나온다 — 인간이 멘탈 모델(Mental Model) 을 잃었기 때문에 부패한 시스템을 더 이상 통제할 수 없게 된 것이다.
2.3.5 역사가 반복된다 — 라운드오프 에러의 교훈
누적이 시스템을 무너뜨린다 는 패턴은 컴퓨팅 역사상 처음이 아니다. 1960~70 년대, 부동소수점(floating-point) 연산이 과학·공학 시뮬레이션의 기본 도구로 자리 잡던 시기에 같은 모양의 문제가 등장했다 — 라운드오프 에러(round-off error) 의 누적. 32 비트 또는 64 비트 부동소수점 변수는 실수를 근사 로 저장한다. 0.1 + 0.2 가 0.30000000000000004 가 되는 그 미묘한 오차가 한 번의 연산에서는 무시할 만하지만, 시간 적분(time integration) 으로 수억 번 반복되는 천체역학·기상 모델·회로 해석에서는 결과를 점차 무의미하게 만들었다. NASA 의 Apollo 항법 코드가 이 문제로 주기적 재정렬 절차를 박았던 사실은 잘 알려져 있다.
당시 수학자와 엔지니어들의 답은 알고리즘과 자세의 결합 이었다. Kahan summation algorithm (1965, William Kahan) 은 보상 항(compensation term) 을 별도 변수로 추적해 합산 시 사라진 비트를 다음 항에 되살려 누적 오차를 0 에 수렴시켰다. Lagrange 보간 다항식(Lagrange Interpolation Polynomial) 과 Lagrange 방정식 은 이산 표본점 사이를 수학적으로 정확한 함수 로 재구성해 데이터 누락에서 오는 표류를 줄였다. 라그랑지안 역학에서 파생된 심플렉틱 적분기(Symplectic Integrator) 는 에너지 보존이라는 불변량(invariant) 을 유지하면서 적분해, 장기 시뮬레이션의 발산을 구조적으로 차단했다. 셋 모두 같은 자세를 공유한다 — 물리·수학적 한계는 인정하되, 그 한계 안에서 보정 장치를 설계한다.
오늘의 컨텍스트 부패는 이 역사의 반복이다. 하드웨어가 메모리의 절대량을 제한하고, 트랜스포머 아키텍처가 attention 의 N² 폭발을 강제한다. 한계는 받아들여야 한다. 그러나 한계를 받아들인 위에서 보정 장치를 설계할 수 있다 — 영구 지시어 는 Kahan 의 보상 항 과 같은 자리이고, 마이크로 태스크 분해 는 시간 적분 단계 축소 와 같은 자리이며, Git Worktree 격리 는 불변량을 유지하는 격리된 적분기 와 같은 자리다. §2.4 의 4 가지 처방이 모두 이 역사적 자세 의 LLM 시대 표현이다. 패턴이 같으니 처방의 형태도 닮는다 — 그래서 우리는 1960 년대 수치해석 교과서에서 현재 컨텍스트 부패의 처방 원리 를 미리 읽을 수 있다.
2.4 도구의 관점 — 부패의 증상과 4 가지 처방
2.4.1 전형적 증상 3 가지
[[DIAGRAM:2-1]]
부패가 일어나고 있는 시스템은 다음 세 가지 증상으로 표면화된다.
첫째, 미들웨어가 6 개 파일에 무질서하게 흩어진다. 인증 미들웨어가 라우터 A 에 한 번, 라우터 B 의 데코레이터에 한 번, 글로벌 미들웨어 스택에 한 번 — 같은 책임이 세 곳에서 다르게 기록된다. AI 는 매번 이미 있는 것을 모르는 상태로 새로 짠다. 둘째, 이미 정의된 함수를 다시 정의한다. validate_email() 이 utils 에 기록되어 있는데, AI 가 같은 모듈에 check_email_format() 을 새로 만든다. 셋째, 기술 스택을 중간에 바꾼다. PostgreSQL 합의 위에서 시작했던 프로젝트가 갑자기 ORM 코드 조각이 SQLAlchemy 에서 Prisma 로, 다시 raw SQL 로 대화 한 번마다 바뀐다.
이 세 증상이 모두 보이면 시스템은 3 개월의 벽 직전이다.
2.4.2 처방 4 가지 — 영구 지시어 / 마이크로 태스크 / Worktree / Subagent
[[DIAGRAM:2-2]]
부패는 AI 의 잘못 이 아니라 우리가 영구 지시어를 안 박은 잘못 이다. 그래서 처방도 AI 를 바꾸는 것 이 아니라 우리가 환경을 바꾸는 것 이다 concept/context-rot.
첫째, 영구 지시어(Persistent Instructions). CLAUDE.md, .cursorrules, AGENTS.md 같은 파일에 프로젝트의 핵심 결정 을 박아두면, AI 가 매 세션 시작 시 자동으로 다시 읽는다. 컨텍스트 윈도우의 맨 앞 에 항상 같은 결정 이 박히므로, 시간이 흘러도 망각되지 않는다. 이 영구 지시어가 본 책 3 장의 핵심 주제다. 둘째, 마이크로 태스크 분해. 한 세션의 작업 단위를 짧게 자르면 부패 누적이 차단된다. 한 번에 하나의 함수 만 짜고 새 세션을 열면, 컨텍스트는 항상 깨끗한 상태로 시작 한다. 셋째, Git Worktree 격리. 실패한 세션을 별도 worktree 로 분리 해서, 부패한 컨텍스트가 본 시스템의 main 브랜치에 침투하지 못하게 한다. 넷째, 서브에이전트(Subagent) 격리. 큰 에이전트가 작은 에이전트에게 일부 작업을 격리된 컨텍스트로 위임 하면, 부모 에이전트의 부패가 자식에게 전파되지 않는다.
이 4 가지 처방은 본 책 3 부 — 자율형 에이전트를 위한 하네스 엔지니어링 의 핵심 카드들이다. 본 장은 진단 만 박고, 처방의 자세한 설계는 7~9 장으로 미뤄둔다.
여기서 한 가지 미묘한 점을 짚어 두자. 위 4 가지 처방은 모두 도구 자체 가 아니라 우리가 도구를 쓰는 자세 다. 영구 지시어 파일은 도구가 자동으로 채워주지 않는다 — 사용자가 매 프로젝트에서 직접 쓴다. 마이크로 태스크 분해는 AI 가 알아서 자르지 않는다 — 사용자가 의식적으로 끊는다. Worktree 격리와 서브에이전트 위임도 기본값이 아니다 — 사용자가 명시적으로 활성화한다. 즉 컨텍스트 부패의 처방은 기술의 진보로 자동 해결되는 문제 가 아니라 사용자의 자세 변화로만 작동하는 문제 다. 이 점이 본 책 전체에서 반복적으로 등장하는 AI-native 의 정의를 다시 확인시켜 준다 — AI 가 일하는 환경을 설계하는 사람.
2.5 닫으며 — 한 줄에서 시스템으로의 강제 이동
본 장의 핵심 한 줄은 이것이다 — 컨텍스트 윈도우는 커지지만, 그 안의 정보가 동등하게 활용되지는 않는다. 그래서 시간이 지날수록 부패가 누적되고, 누적된 부패는 결국 전체 재작성 을 강제한다. 이 한 줄이 프롬프트 엔지니어링의 시대 — 한 번의 질문을 잘 짜는 자세 가 왜 부족한가 를 설명한다. 한 번의 질문이 아무리 정교해도, 그것이 연속된 대화의 흐름 에 박히지 않으면 망각된다.
그래서 산업이 한 발 더 나갔다. 한 번의 질문 최적화 (프롬프트 엔지니어링) 에서 시스템 단위의 정보 통제 (컨텍스트 엔지니어링) 로. 영구 지시어 파일을 박고, RAG (검색 증강 생성) 로 외부 지식을 끌어오고, MCP (Model Context Protocol, 모델 컨텍스트 프로토콜) 로 도구와 데이터에 표준화된 접근 채널을 만들고, 컨텍스트의 밀도 를 통제한다. 이것이 본 책 다음 챕터의 주제다.
다음 Chapter 3 은 그 도약 — 컨텍스트 엔지니어링의 부상 — 으로 들어간다. 거기서 우리는 Karpathy(카파시) 와 Lütke(뤼트케) 가 트위터에 던진 한 줄이 어떻게 한 시대의 패러다임 을 바꿨는지, 그리고 그 패러다임이 어떤 실무 도구 로 박혔는지를 본다.
본 장이 남기는 한 가지 통찰이 더 있다 — 모델의 진화 가 우리의 자세 진화 를 자동으로 끌고 가지 않는다는 점이다. 컨텍스트 윈도우가 4K 에서 1M 으로 250 배 커지는 동안, 우리는 그만큼 더 많은 정보를 던져 넣는 자세 만 키웠고, 그만큼 더 정밀하게 통제하는 자세 는 키우지 않았다. 부패는 그 격차에서 자란다. 도구가 커지면 사용자도 그만큼 섬세해져야 한다 — 이 비대칭이 본 책의 모든 후속 챕터에서 반복된다.
2.6 용어 정리
- 컨텍스트 부패 (Context Rot / Context Rotting): 시간이 지날수록 모델이 이전 결정을 망각하고 누적된 충돌이 시스템을 무너뜨리는 현상 — 오염 이 아닌 부패 (처음엔 멀쩡)
- Stateless (무상태): LLM 이 이전 대화 를 내부에 저장하지 않는 특성. 매 호출마다 클라이언트가 전체 대화를 다시 보내야 함
- 컨텍스트 윈도우 (Context Window): 한 번의 추론에서 모델이 처리할 수 있는 입력 + 출력 토큰 최대치. 모델의 단기 기억 용량
- Lost in the Middle: 입력이 길수록 모델이 문맥 가운데 의 중요한 정보를 놓치는 트랜스포머 attention 의 통계적 편향
- 트랜스포머 (Transformer): 현대 LLM 의 기반 아키텍처. attention 메커니즘으로 토큰 간 관계를 계산 — 토큰 수 N 에 대해 메모리 N² 폭발
- HBM (High Bandwidth Memory, 고대역폭 메모리): GPU 에 박히는 고속 메모리 — 컨텍스트 윈도우 크기의 물리적 상한 결정. Samsung / SK Hynix / Micron 양산
- KV 캐시 (Key-Value Cache): 트랜스포머 attention 의 중간 결과를 메모리에 저장해 반복 계산을 회피하는 압축 기법 — 메모리 절약은 가능하나 N² 폭발 자체를 없애지는 못함
- FlashAttention / Sparse Attention: attention 메모리 사용을 줄이는 알고리즘적 최적화 — 한계 완화는 되나 물리 메모리 상한 이 최종 제약
- 라운드오프 에러 (Round-off Error): 부동소수점 연산의 근사 표현에서 비롯되는 오차 — 한 번은 무시할 수준이나 시간 적분 시 컨텍스트 부패와 같은 모양 의 누적 발산
- Kahan summation algorithm (1965, William Kahan): 보상 항을 별도 변수로 추적해 누적 합산의 라운드오프 오차를 0 에 수렴시키는 알고리즘 — 영구 지시어 의 수치해석 원형
- Lagrange 보간 다항식 / Lagrange 방정식 (Lagrange Interpolation Polynomial): 이산 표본점을 정확한 함수로 재구성해 표류를 줄이는 고전 수치해석 기법
- 심플렉틱 적분기 (Symplectic Integrator): 라그랑지안 역학의 불변량(invariant) 을 유지하면서 적분해 장기 시뮬레이션의 발산을 차단 — Worktree 격리 의 물리학 원형
- 요구사항 표류 (Requirements Drift): 망각된 결정에 어긋나는 새 코드가 누적되면서 시스템 전체의 일관성이 표류하는 현상
- 3 개월의 벽 (Three-Month Wall): 의도 중심 개발 프로젝트가 약 3 개월쯤 도달하는 작은 변경 한 번이 전체를 깨는 임계점
- 영구 지시어 (Persistent Instructions):
CLAUDE.md/.cursorrules/AGENTS.md같은 파일에 프로젝트의 핵심 결정을 박아 매 세션 자동 리로드 시키는 기법 - 마이크로 태스크 분해 (Micro-Task Decomposition): 한 세션의 작업 단위를 짧게 잘라 부패 누적을 차단하는 전략
- Git Worktree 격리 (Git Worktree Isolation): 실패한 세션을 별도 worktree 로 분리해 부패가 main 에 침투하지 못하게 하는 전략
- 서브에이전트 (Subagent): 큰 에이전트가 작은 에이전트에게 격리된 컨텍스트로 작업을 위임하는 패턴 — 부패 격리
2.7 더 읽을거리
위키 카드:
- concept/context-rot — 컨텍스트 부패 메커니즘 4 단계와 4 가지 처방
- term/context-window — 컨텍스트 윈도우의 정의, 모델별 크기, 통제·채움
- concept/vibe-coding — 3 개월의 벽과 17% 디버깅 저하 통계
- entity/karpathy — 컨텍스트 윈도우 통제 능력 = 새 레버리지 명제
1차 출처:
- Liu et al. "Lost in the Middle: How Language Models Use Long Contexts", 2023
- Karpathy Software 3.0 진화론 (X 시리즈 포스트)
- Anthropic 디버깅 능력 RCT 연구 (2026, 17% 하락 보고)
Diagram 명세 블록
[[DIAGRAM:2-1]] 컨텍스트 부패의 3 가지 전형적 증상
┌────────────────────────────────────────────────────────────────────┐
│ [Diagram 2-1] 컨텍스트 부패의 3 가지 전형 증상 │
├────────────────────────────────────────────────────────────────────┤
│ │
│ 증상 ① 미들웨어가 6 개 파일에 무질서하게 흩어진다 │
│ ──────────────────────────────────────── │
│ router_a.py : @auth_required(...) │
│ router_b.py : if not request.user: abort(401) │
│ middleware.py : class AuthMiddleware: ... │
│ decorators.py : def check_login(): ... │
│ (같은 책임이 4 곳에서 다른 형태로 기록됨) │
│ │
│ 증상 ② 이미 정의된 함수를 다시 정의한다 │
│ ──────────────────────────────────── │
│ utils/email.py : def validate_email(addr): ... │
│ api/users.py : def check_email_format(s): ... ← 중복 │
│ forms/signup.py : def is_valid_email(e): ... ← 또! │
│ │
│ 증상 ③ 기술 스택을 중간에 바꾼다 │
│ ──────────────────────────── │
│ 1주차: SQLAlchemy + PostgreSQL │
│ 2주차: Prisma 코드 조각이 등장 (왜?) │
│ 3주차: raw SQL + sqlite3 import 가 갑자기 기록됨 │
│ │
│ ╳ 세 증상이 모두 보이면 *3 개월의 벽* 직전 │
│ ╳ 원인: AI 의 잘못 ❌ → 영구 지시어 부재 ✓ │
│ │
├────────────────────────────────────────────────────────────────────┤
│ 출처: concept/context-rot, lesson/vbc-failures-and-causes │
└────────────────────────────────────────────────────────────────────┘
[[DIAGRAM:2-2]] 부패의 4 단계 + 처방 4 가지
┌────────────────────────────────────────────────────────────────────┐
│ [Diagram 2-2] 컨텍스트 부패의 4 단계 메커니즘 + 4 처방 │
├────────────────────────────────────────────────────────────────────┤
│ │
│ 단계 행위 결과 │
│ ──── ────── ────── │
│ 1 시작 → 초기 설계 의도 컨텍스트 적재 → 일관된 패턴 (마법) │
│ │ │
│ ▼ │
│ 2 누적 → 대화 길이 → 윈도우 한계 근접 → AI 가 결정 부분 망각 │
│ │ │
│ ▼ │
│ 3 충돌 → 망각 결정 어긋난 새 코드 → 요구사항 표류 │
│ │ │
│ ▼ │
│ 4 재작성 → 충돌 코드 누적 → 전체 재작성 (3개월 벽) │
│ │
│ ───────────── 처방 4 가지 (본 책 3 부에서 자세히) ────────────── │
│ │
│ ① 영구 지시어 CLAUDE.md / .cursorrules / AGENTS.md │
│ (Persistent Instr.) → 매 세션 자동 리로드 = 결정 영구 보존 │
│ │
│ ② 마이크로 태스크 분해 한 세션의 작업 단위를 짧게 │
│ (Micro-Task) → 부패 누적 차단 │
│ │
│ ③ Git Worktree 격리 실패 세션을 별도 worktree 로 │
│ (Worktree Isolation) → 부패가 main 에 침투 못함 │
│ │
│ ④ 서브에이전트 격리 격리된 컨텍스트로 작업 위임 │
│ (Subagent Isolation) → 부모 컨텍스트 부패 차단 │
│ │
├────────────────────────────────────────────────────────────────────┤
│ 출처: concept/context-rot 의 4 단계 표 + 4 전략 표 │
└────────────────────────────────────────────────────────────────────┘