---
type: knowledge
domain: ai-dev
status: active
last-reviewed: 2026-07-05
---

# 개발 세션 컨텍스트 운용

> 한 줄 정의
> 코딩 AI의 컨텍스트 윈도우를 **예산**으로 다루는 운용법 — 무엇을 넣고, 무엇을 파일로 빼고, 언제 세션을 자르는가. RAG 관점의 일반론은 [[Context Engineering]], 여기는 개발 세션 특화다.

## 해결하는 문제

- 컨텍스트가 차오르면 성능이 조용히 떨어진다: 앞의 지시를 잊고, 스타일이 흔들리고, 이미 고친 것을 다시 깬다.
- 요약(컴팩션)은 손실 압축이다 — 대비 없이 맞으면 작업 상태가 증발한다.

## 핵심 원리

### 1. 컨텍스트는 예산이다
- 세션 시작 시 큰 그림(목표·제약·완료 조건)을 먼저 고정하고, 세부는 필요할 때 가져온다(JIT).
- **마지막 20% 구간에서 대규모 리팩토링·다중 파일 작업을 시작하지 않는다** — 남은 예산보다 큰 작업은 다음 세션으로.
- 넣지 않는 것: 통째 파일 덤프(필요 부분만), 반복된 시행착오 로그, 이미 결론 난 논의.

### 2. 상태를 파일로 외부화한다
- 컨텍스트는 휘발성, 파일은 영속성. **세션이 죽어도 파일만 있으면 이어진다**가 설계 기준이다.
- 최소 세트:
  - `plan.md` — 목표·완료 조건·단계 체크박스 (진행되면 체크)
  - 진행 로그 — 결정·막힌 것·다음 단계를 한 줄씩 append
  - spec — 요구사항의 단일 진실 ([[PROJECT-SPEC-TEMPLATE]])
- 루프·장기 작업이면 상태 파일이 필수다: 매 반복이 "파일 읽기 → 한 단위 작업 → 파일 갱신"으로 닫혀야 한다.

### 3. 세션 분할 기준

| 자르는 시점 | 이유 |
|------------|------|
| 완료 조건 1묶음 검증 완료 | 자연스러운 커밋 경계 |
| 역할 전환 (구현 → 리뷰) | Judge 독립성 → [[AI 페어 개발 원리]] 2절 |
| 방향 전환 (설계 변경 결정) | 낡은 맥락이 새 방향을 오염시킨다 |
| 같은 오류 3회 루프 | 컨텍스트가 실패 패턴에 잠김 — 새 세션 + 상태 파일 재시작이 더 빠르다 |

### 4. 상시 규칙 파일(CLAUDE.md 류)은 짧고 검증 가능하게
- 모든 턴에 실리는 고정 비용이다. 길수록 개별 규칙의 준수율이 떨어진다.
- 좋은 규칙: 명령형 + 검증 가능 ("모든 외부 호출에 타임아웃"). 나쁜 규칙: 태도 선언 ("신중하게 코딩한다").
- 프로젝트 지식은 규칙 파일이 아니라 **라우팅 가능한 문서**로 (이 볼트의 [[START-HERE#프로젝트 유형별 라우팅|프로젝트 라우팅]] 구조가 그 사례 — 전부 읽지 않고 필요한 것만).

### 5. 컴팩션에 대비한다
- 요약에서 살아남는 것은 구조화된 것이다: 결정·완료 조건·다음 단계를 상태 파일에 두면 요약 손실이 0이 된다.
- 긴 작업 전 "지금까지의 결정 요약을 진행 로그에 기록해"가 보험이다.

## 안티패턴

- **"일단 다 읽어" 시작** — 레포 전체·문서 전체 주입. 예산 소진 + 신호 희석.
- **대화가 유일한 상태 저장소** — 세션 종료 = 작업 증발.
- **한 세션 만능주의** — 구현·리뷰·기획을 같은 컨텍스트에서. 편향과 오염.
- **규칙 파일 비대화** — 지켜지지 않는 50개 규칙 < 지켜지는 10개.

## 관련 문서

- [[AI 페어 개발 원리]] · [[개발 파이프라인 분업]] · [[Context Engineering]] · [[Context Compaction]] · [[State Management]]