1.7세션 상태와 재개

"세션을 이어서 한다"고 할 때 실제로 복원해야 하는 상태는 세 층위로 나뉩니다.

1. 대화 상태 — 지금까지의 메시지, 도구 호출과 결과. 모델이 "무슨 이야기를 했는지" 아는 근거입니다.
2. 작업 상태 — 무엇이 완료되고 무엇이 남았는지, 내려진 결정, 발견된 제약. 대화 이력 안에 흩어져 있지만, 이력 원문과는 다른 압축된 진실입니다.
3. 환경 상태 — 파일 시스템, git 브랜치, 실행 중인 프로세스, DB. 이것은 대화 밖 세계에 이미 존재하며, 재개 시 다시 읽을 수 있습니다.

이 구분이 중요한 이유: 층위마다 보존 전략이 다르기 때문입니다. 환경 상태는 저장할 필요가 없습니다 — 재개 후 다시 조회하면 됩니다(git status, 파일 읽기). 대화 상태는 세션 로그로 보존됩니다. 문제는 작업 상태입니다. 이력 원문에 흩어진 결정과 맥락은 재개 시점에 다시 조립하기 비싸므로, 명시적 문서로 추출해 두는 것이 표준입니다.

<!-- 작업 상태를 파일로 외부화한 예: PROGRESS.md -->
## 진행 상황 (마지막 갱신: 3단계 완료 시점)
- [x] 스키마 마이그레이션 작성 (migrations/004_*.sql)
- [x] API 핸들러 수정 — 결정: 페이지네이션은 cursor 방식 (offset은 성능 문제로 기각)
- [ ] 프런트엔드 연동  ← 다음 작업
- 주의: tests/fixtures/의 시드 데이터는 마이그레이션과 버전이 묶여 있음

시험에서는 "재개에 반드시 저장해야 하는 것"을 묻습니다. 파일 시스템 상태를 통째로 직렬화한다는 선택지는 오답입니다 — 환경 상태는 재조회 가능하며, 저장할 가치가 있는 것은 재구성 비용이 큰 작업 상태입니다.

Claude Code는 세션 이력을 로컬에 보존하며, 두 가지 재개 명령을 제공합니다.

• claude --continue (또는 -c) — 현재 디렉터리의 가장 최근 세션을 즉시 이어서 시작합니다.
• claude --resume (또는 -r) — 과거 세션 목록에서 선택해 재개합니다. 특정 세션 ID를 인자로 줄 수도 있습니다.

재개된 세션은 이전 대화 이력 전체를 그대로 복원하므로, 모델은 중단 지점의 맥락을 가진 채 다음 지시를 받습니다. SDK에서도 세션 ID를 지정해 이어서 실행하는 resume 옵션을 제공하므로, 무인 파이프라인에서 "어제 실행의 맥락으로 오늘 작업"이 가능합니다.

재개와 구별해야 할 것이 **컴팩션(compaction)**입니다. 컨텍스트 윈도우가 한계에 가까워지면 Claude Code는 이력을 요약해 압축합니다. 재개가 "끊긴 세션을 다시 여는 것"이라면, 컴팩션은 "진행 중인 세션의 이력을 압축하는 것"입니다. 컴팩션은 요약이므로 세부 정보가 손실될 수 있습니다 — 그래서 중요한 결정·제약은 컴팩션이 지워도 되살아나도록 파일(CLAUDE.md, 진행 문서)에 적어 두라는 것이 공식 권장입니다.

# 어제 하던 리팩터링 세션을 이어서
claude --continue

# 지난주 세션 목록에서 골라 재개
claude --resume

# 무인 모드로 특정 세션 이어서 실행
claude -p "남은 테스트를 마저 수정해줘" --resume <session-id>

시험 함정: --continue와 --resume의 차이(최근 세션 자동 vs 목록 선택), 그리고 "컴팩션은 정보 손실이 없다"(오답 — 요약은 본질적으로 손실 압축)가 단골입니다.

긴 작업의 신뢰성은 "컨텍스트 안에 얼마나 담느냐"가 아니라 "컨텍스트 밖에 얼마나 잘 내려놓느냐"가 결정합니다. 상태 외부화(state externalization)의 대표 패턴을 정리합니다.

진행 문서 패턴 — 에이전트가 작업하며 PROGRESS.md 같은 파일을 계속 갱신합니다. 세션이 어떻게 끝나든, 새 세션은 이 파일을 읽는 것으로 시작합니다. 갱신 시점을 "각 하위 작업 완료 직후"로 규칙화하면 손실 구간이 최소화됩니다.

환경을 진실로 쓰는 패턴 — git 커밋이 곧 체크포인트입니다. 하위 작업마다 커밋하면, 재개 세션은 git log로 완료 내역을 재구성할 수 있습니다. 테스트 스위트는 "현재 어디까지 되어 있는가"를 언제든 다시 물을 수 있는 검증 수단입니다.

구조화 저장소 패턴 — 멀티 세션·멀티 에이전트 시스템에서는 작업 큐와 상태를 DB나 태스크 보드로 관리합니다. 세션은 일회용 워커가 되고, 상태는 전부 바깥에 삽니다.

# 일회용 워커 패턴: 상태는 큐에, 세션은 stateless
while task := queue.pop():
    result = run_agent_session(
        prompt=f"작업: {task.goal}\n완료 기준: {task.done_criteria}",
        context_files=["PROGRESS.md"],   # 외부화된 상태를 주입
    )
    queue.mark_done(task.id, summary=result.summary)
    update_progress_file(task.id, result.summary)

설계 원칙은 하나로 수렴합니다. 컨텍스트 윈도우는 작업 기억이지 저장소가 아닙니다. 잃으면 안 되는 것은 파일·커밋·큐로 내려놓고, 세션은 언제 끊겨도 되는 소모품으로 취급하는 시스템이 견고한 시스템입니다. 이 원칙은 5도메인(컨텍스트 관리)과도 직결되므로 함께 복습해 두면 좋습니다.