얼마 전 밤, 블로그 발행 자동화가 이미지 생성 단계에서 멈췄다. 몇 시간을 붙잡다가 나는 그 세션을 미련 없이 닫았고, 다음 세션이 5분 만에 문제를 풀었다. 이 경험이 말해주는 결론은 하나다. AI와 일하는 실력은 결국 컨텍스트 관리 싸움이라는 것. 더 좋은 모델을 고르는 것도, 세션을 새로 여는 것도, 문서를 남기는 것도 전부 같은 문제의 다른 해법이다.
이 글에서는 실제로 겪은 트러블슈팅을 따라가며 세션이 길어질수록 AI가 흐려지는 이유, 내가 기준으로 삼는 20% 경험칙, 그리고 세션과 세션을 잇는 핸드오프 3가지 방법(문서·메모리·외부 도구)을 순서대로 정리한다.
이미지 하나에 멈춘 발행 — 그날 밤 실제로 벌어진 일
AI 데이터분석 글을 발행하던 날이었다. 본문, 태그, SEO 메타, 블록 구조까지 전부 준비가 끝났는데 딱 하나, 썸네일 이미지 생성이 계속 실패했다. 큰 해상도를 요청할 때마다 정확히 180초 뒤에 504 에러가 떨어졌다.
원인을 좁히는 시도는 이렇게 흘러갔다.
- API 키와 잔액 확인 → 정상
- 작은 이미지(512×512)로 대조 실험 → 5초 만에 성공
- 모델과 해상도를 바꿔가며 재시도 → 큰 이미지만 전부 실패
결론이 나왔다. 내 설정 문제가 아니라 이미지 생성 서버 쪽의 일시 과부하. 즉, 지금 이 자리에서 내가 고칠 수 있는 문제가 아니었다.
여기서 중요한 판단을 했다. 그 무렵 세션은 이미 몇 시간 분량의 시도와 실패 로그로 가득 차 있었다. 같은 세션에서 계속 재시도하면 어떻게 될까. 실패 기록이 쌓일수록 대화는 무거워지고, AI의 응답은 미묘하게 초점을 잃는다. 그래서 재시도 대신 인수인계 문서 하나를 남기고 세션을 닫았다. 증상, 정상으로 확인된 것, 유력한 가설, 다음 세션이 시도할 것의 우선순위 — 이 네 가지만 담백하게 적었다. 돌이켜보면 이 “닫는 결정”이 그날 컨텍스트 관리의 절반이었다.
새 세션은 왜 5분 만에 풀었나
다음 세션은 상위 모델로 새로 열었다. 새 세션이 한 일은 단순했다. 인수인계 문서 하나를 읽고, 거기 적힌 1순위 제안(“시간을 두고 재시도”)을 그대로 실행했다. 첫 시도에 성공했다. 14초 만에 이미지가 나왔고, 글은 그대로 발행됐다.
덤도 있었다. 깨끗한 컨텍스트에서 다시 보니 생성 직후의 이미지 URL은 인증 키 없이도 캐시에서 그대로 서빙된다는 사실이 눈에 들어왔다. 이 발견은 키 노출 없이 업로드하는 표준 절차가 되어 프로젝트 문서에 박제됐다. 지친 세션이었다면 그냥 지나쳤을 디테일이다.
같은 문제, 같은 정보였다. 달라진 것은 컨텍스트뿐이었다.
컨텍스트 관리란 무엇인가 — 세션이 길어질수록 흐려지는 이유
LLM에게 컨텍스트 윈도우는 작업 기억이다. 대화 내용, 읽은 파일, 실행 로그가 전부 이 창 안에 쌓이고, 창이 차오를수록 오래된 내용은 요약되거나 밀려난다. 세션 후반부에 AI가 앞에서 정한 규칙을 잊거나 초점을 잃는 것은 능력의 문제가 아니라 창의 문제다.
그래서 컨텍스트 관리의 수단은 사실 세 층으로 정리된다.
| 수단 | 하는 일 | 비용 |
|---|---|---|
| 상위 모델 채택 | 더 큰 창, 더 좋은 요약·압축 | 사용료 상승 |
| 새 세션 열기 | 창을 통째로 리셋 | 인수인계 필요 |
| 세션 내 정리(컴팩트) | 창 안에서 오래된 내용 요약 | 디테일 유실 가능 |
Claude Code의 공식 베스트 프랙티스도 태스크와 태스크 사이에 컨텍스트를 자주 비우라고 권한다. 도구를 만든 쪽이 먼저 “쌓지 말고 리셋하라”고 말하는 셈이다.
내가 컨텍스트 관리 기준으로 삼는 숫자가 하나 있다. 한 세션에서 태스크 하나를 깔끔하게 끝내면, /context 명령으로 확인되는 사용량이 대략 20% 언저리에 머문다. 그 선을 훌쩍 넘어가기 시작하면 응답이 미묘하게 흐려지는 것이 체감된다. 그래서 내 원칙은 1세션 1태스크다. 태스크가 끝나면 세션에 정이 들었어도 미련 없이 닫는다.
세션을 넘길 때 무엇으로 잇는가 — 핸드오프 3가지
세션을 자주 닫으라는 말은 곧 세션 간 인수인계가 실력이 된다는 말이다. 컨텍스트 관리의 전반전이 “언제 닫을 것인가”라면, 후반전은 “무엇으로 이을 것인가”다.
| 수단 | 무엇을 담나 | 강점 | 한계 |
|---|---|---|---|
| 문서 (CLAUDE.md·SOP·인수인계 md) | 프로젝트 규칙, 절차, 특정 작업의 현재 상태 | 명시적이고 사람도 읽는다. 버전 관리 가능 | 사람이 쓰고 관리해야 하고, 쌓이면 그 자체가 컨텍스트 비용 |
| 메모리(memory) | 에이전트가 스스로 남기는 사실·상태·교훈 | 다음 세션에 자동 회수 — 시작부터 알고 출발 | 낡을 수 있어 검증이 필요 |
| 외부 도구 (Notion 등) | 팀 공유 지식, 일정, 이력 | 협업과 공유에 강함 | 에이전트가 자동으로 읽지 않는다. 연동 손이 감 |
개인 프로젝트 기준으로 체감상 가장 강력한 것은 메모리였다.
메모리는 실제로 어떻게 동작하나
Claude Code의 메모리는 파일 기반이다. 프로젝트별 메모리 폴더에 “사실 하나 = 파일 하나”로 쌓이고, 한 줄짜리 인덱스가 매 세션 시작에 자동으로 로드된다. 에이전트는 작업 중에 스스로 메모리를 기록하고, 낡은 메모리는 갱신하거나 지운다. 사람이 매번 브리핑하지 않아도 다음 세션이 이어받는 구조다.
이번 세션 전환에서 실제로 벌어진 일이 좋은 예다.
첫째, 새 세션의 첫 응답부터 AI는 “블로그 작성 스킬의 라이브 버전은 v54이고, 그간의 개선분은 아직 배포되지 않았다”는 지난 세션들의 결론을 이미 알고 시작했다. 내가 다시 설명한 적이 없다. 메모리 인덱스가 자동으로 실려 들어간 것이다.
둘째, 그 메모리에는 낡은 정보도 섞여 있었다. 기록 시점 기준의 서술을 AI가 그대로 믿지 않고 파일 수정 날짜를 직접 확인해 최신 상태로 교정했다. 메모리는 출발점이지 정답지가 아니라는 것, 그래서 회수한 메모리를 실측으로 검증하는 습관까지가 한 세트라는 것을 확인했다.
셋째, 트러블슈팅처럼 디테일이 많은 상태는 메모리보다 인수인계 문서가 나았다. 둘은 경쟁이 아니라 분업이다. 메모리는 “무엇이 어떤 상태인가”를, 문서는 “정확히 어떻게 하는가”를 나른다.
마무리 — 다음 이야기, 컨텍스트를 아끼다 생기는 부작용
정리하면 이렇다. AI 협업의 병목은 모델의 지능이 아니라 창의 상태에서 먼저 온다. 상위 모델도, 새 세션도, 문서와 메모리도 전부 컨텍스트 관리라는 하나의 기술로 수렴한다. 태스크 하나가 끝나면 닫고, 닫기 전에 다음 세션이 이어받을 것을 남긴다. 이 단순한 루프가 쌓이면 AI와의 협업 품질이 눈에 띄게 달라진다.
다만 반대 방향의 문제도 있다. 컨텍스트를 아끼려는 성향 때문에 에이전트가 정작 읽어야 할 파일을 읽지 않고 넘어가는, 일종의 lazy loading 현상이다. 겪어보니 이것도 꽤 흥미로운 주제여서, 다음 포스팅에서 따로 다룰 예정이다.
핵심 요약
- 세션이 길어질수록 AI가 흐려지는 것은 능력이 아니라 컨텍스트 윈도우의 문제다.
- 막힌 문제가 “지금 내가 고칠 수 없는 것”으로 판명되면, 재시도 대신 인수인계 문서를 남기고 세션을 닫는 편이 낫다.
- 1세션 1태스크로 끝내면 컨텍스트 사용량은 20% 언저리에 머문다 — 그 선을 넘으면 품질 저하가 체감되기 시작한다.
- 세션 간 핸드오프 수단은 문서, 메모리, 외부 도구 세 가지이며 개인 프로젝트에서는 자동 회수되는 메모리가 가장 강력하다.
- 메모리는 출발점이지 정답지가 아니다 — 회수한 내용은 실측으로 검증한다.
함께 읽으면 좋은 글
세션마다 자동으로 실려 들어가는 CLAUDE.md가 비대해지면 그 자체가 컨텍스트 비용이 된다. 문서를 계속 슬림하게 유지하는 운영 루프를 정리해뒀다.
세션 단위 협업이 익숙해지면, 일을 통째로 에이전트에게 넘기는 방식의 변화가 보이기 시작한다.
