5장. 컨텍스트 관리의 기술

좋은 모델을 쓰는데도 결과가 들쭉날쭉할 때가 있다. 많은 사람은 여기서 더 비싼 모델, 더 긴 프롬프트, 더 많은 예시를 찾는다. 그런데 실제 원인은 의외로 단순하다. 세션이 더러워졌기 때문이다.

이전 장에서 CLAUDE.md를 프로젝트의 헌법이라고 불렀다면, 이번에는 그 헌법을 올려두는 책상 정리법을 다룰 차례다. 헌법이 아무리 좋아도 책상 위에 테스트 로그, 오래된 가설, 방금 끝난 다른 작업의 대화, 필요 없는 MCP 도구 설명, 중복된 파일 읽기가 산처럼 쌓여 있으면 판단력이 흐려진다. 솔로 빌더에게 이건 치명적이다. 혼자 만들고, 혼자 디버깅하고, 혼자 배포하는 사람에게 한 번의 문맥 오염은 곧 한 시간의 삽질이 된다.

클로드 코드를 잘 쓰는 사람과 그냥 오래 켜 두는 사람의 차이는 프롬프트 문학이 아니라 세션 운영 습관에서 벌어진다. 성능보다 중요한 것은, 맥락을 얼마나 깨끗하게 유지하느냐다.

컨텍스트 윈도우는 대화창이 아니라 작업대다

컨텍스트 윈도우를 단순히 "지금까지의 채팅 기록" 정도로 생각하면 바로 실수한다. 실제로는 훨씬 많은 것이 들어간다. 세션이 시작되기도 전에 루트 CLAUDE.md, 자동 메모리, MCP 도구 이름과 설명, 스킬 설명 같은 시작 정보가 이미 실려 있다. 작업을 시작한 뒤에는 당신의 메시지, Claude의 응답, 읽은 파일 내용, 도구 실행 결과, 심지어 터미널에 직접 보이지 않는 내부 정보까지 계속 쌓인다.¹

즉, 당신이 아직 아무 말도 안 했는데 배낭은 이미 어느 정도 차 있는 셈이다. 그래서 컨텍스트 관리는 "얼마나 많이 넣을까"가 아니라, 처음부터 무엇이 자동으로 들어와 있는지 이해하는 일에서 시작한다.

실전에서 많은 사람이 놓치는 포인트는 세 가지다.

• 메시지 기록은 생각보다 빨리 불어난다.

• 파일을 많이 읽을수록 그 내용은 세션의 공기처럼 계속 남아 있다.

• 연결한 도구와 MCP 서버도 공짜가 아니다.

특히 MCP는 편리하지만, 세션 안에서 불필요한 도구 설명까지 함께 예산을 잡아먹을 수 있다. 컨텍스트 분해 화면을 보면 메시지뿐 아니라 시스템 프롬프트, 스킬, MCP 도구, 아직 쓰지도 않은 지연 로드 도구들이 각각 얼마나 자리를 차지하는지 드러난다. 그래서 "왜 벌써 답이 둔해졌지?"라는 질문의 범인은 대화 길이만이 아닐 때가 많다.²

클로드 코드에는 이를 확인하는 /context가 있다. 이 명령은 지금 세션에서 무엇이 얼마나 공간을 쓰는지 카테고리별로 보여준다.¹ 이걸 한 번만 봐도 감이 잡힌다. 아, 내가 모델을 못 쓰는 게 아니라, 방금 npm test의 장황한 실패 로그와 열다섯 개 파일 읽기가 작업대를 다 차지했구나.

중요한 건 한계는 보통 "딱 꽉 찬 순간"이 아니라 그 이전부터 시작된다는 점이다. 세션이 압박을 받으면 Claude는 앞에서 했던 제약을 잊고, 이미 정한 결정을 흔들고, 조금 전 읽은 파일 구조도 흐릿하게 기억하기 시작한다. 모순된 답, 같은 질문의 반복, 엉뚱한 API 가정이 나타나면 거의 항상 컨텍스트 압력 신호다.⁶

요컨대, 컨텍스트 윈도우는 메모장보다 RAM에 가깝다. 많이 실을수록 든든해 보이지만, 정리되지 않은 채로 오래 켜 두면 결국 느려지고 헷갈린다.

/compact는 압축이고, /clear는 리셋이다

긴 세션을 다루는 핵심은 모든 것을 기억하게 만드는 데 있지 않다. 버릴 것과 남길 것을 구분하는 데 있다. 여기서 가장 중요한 두 명령이 /compact와 /clear다.

/compact는 지금까지의 긴 대화를 짧은 구조화된 요약으로 압축해, 중요한 사실만 남기고 대화 기록의 부피를 줄인다. 반면 /clear는 현재 대화 이력을 비워서 사실상 새 작업대처럼 다시 시작하게 만든다.⁴

둘의 차이를 감각적으로 기억하면 쉽다.

• /compact는 회의록을 남기고 책상을 정리하는 것

• /clear는 회의실 자체를 바꾸는 것

/compact가 특히 좋은 순간은 이렇다. 한 차례 조사와 구현이 끝났고, 이제 다음 단계로 넘어가야 할 때다. 예를 들어 인증 버그를 추적하느라 관련 파일 8개를 읽고 테스트를 몇 번 돌렸다고 해 보자. 이제 원인은 찾았고 수정 방향도 정해졌다. 이때 그대로 구현을 이어가면, 앞선 추적 과정의 군더더기까지 계속 짊어지고 간다. 이럴 때 /compact를 먼저 실행하면 "문제 원인, 결정 사항, 수정 파일, 남은 TODO" 같은 핵심만 남기고 가볍게 다음 단계로 진입할 수 있다.⁴

게다가 압축 뒤에 살아남는 정보와 사라지는 정보는 완전히 같지 않다. 시스템 프롬프트와 출력 스타일은 유지되고, 프로젝트 루트의 CLAUDE.md와 자동 메모리는 디스크에서 다시 주입된다. 반면 경로 기반 규칙이나 하위 디렉터리의 중첩 CLAUDE.md는 요약 과정에서 사라졌다가, 다시 그 경로의 파일을 읽을 때 재로딩된다. 호출했던 스킬 본문은 다시 들어오지만 크기 제한이 있어 너무 큰 스킬은 앞부분만 남고, 오래된 것부터 밀려날 수 있다.¹

이 차이는 꽤 중요하다. 예를 들어 apps/web/CLAUDE.md에만 들어 있는 UI 규칙을 믿고 작업하다가 /compact 후에 전혀 다른 파일만 만지면, Claude는 그 세부 규칙을 잠시 놓칠 수 있다. 이럴 때는 "왜 아까는 잘 알던 규칙을 갑자기 어기지?"가 아니라, 그 규칙이 다시 로드될 조건이 아직 안 생겼구나라고 이해해야 한다.

/clear는 성격이 다르다. 이건 이어 가기보다 끊어야 할 때 쓴다. 예를 들어 오전에는 결제 웹훅 중복 처리 문제를 디버깅했고, 오후에는 랜딩 페이지 카피와 가격표 UI를 손보려 한다고 해 보자. 둘은 같은 프로젝트 안에 있지만, 세션 입장에서는 거의 다른 일이다. 이럴 때 /compact로 억지로 이어 붙이면 오전의 로그와 가설이 오후 작업의 판단에 섞인다. 그때는 미련 없이 /clear가 낫다.⁴

간단히 정리하면 이렇다.

• 같은 작업의 다음 단계로 간다: /compact

• 전혀 다른 일로 넘어간다: /clear

• 어제 하던 같은 일을 오늘 이어간다: /resume

• 같은 문제를 다른 가설로 갈라 실험한다: /fork

/resume은 저장된 세션을 다시 여는 도구다. 가장 최근 세션을 계속 이어 가거나, 특정 세션을 골라 복구할 수 있다.⁴⁵ 다만 여기서 중요한 건 /resume이 기억력의 대체재는 아니라는 점이다. 세션을 되살리는 기능이지, 나쁜 세션을 좋은 세션으로 정화해 주는 기능은 아니다. 어제의 세션이 이미 오염돼 있었다면, 오늘 다시 열어도 여전히 오염돼 있다.

그래서 실전에서는 이런 순서가 좋다. 길게 달린 세션을 그냥 믿고 닫지 말고, 끝나기 전에 /compact로 정리하고, 필요한 핵심을 문서나 메모리에 남긴 뒤 종료한다. 다음 날에는 무조건 /resume부터 하는 것이 아니라, 정말 이어야 하는 작업인지 먼저 생각한다. 어제와 오늘의 목적이 다르면 새 세션이 더 낫다.

Memory는 헌법이 아니라 작업 기억이다

세션은 매번 새로 시작된다. 이 사실을 받아들이면 오히려 일이 쉬워진다. 세션을 영원히 늘이는 대신, 세션을 넘어 유지되어야 할 정보가 무엇인지 구분하게 되기 때문이다.

클로드 코드에는 크게 두 종류의 지속 컨텍스트가 있다. 하나는 당신이 쓰는 CLAUDE.md, 다른 하나는 Claude가 학습해 두는 자동 메모리다. 전자는 프로젝트의 규칙과 구조 같은 안정적인 사실, 후자는 반복된 교정과 운영 중 배운 점 같은 진화하는 사실에 가깝다.³

비유하면 이렇다.

CLAUDE.md는 가게 벽에 붙어 있는 운영 원칙이다. "주문은 이런 형식으로 받는다", "결제는 이 경로로 처리한다", "테스트는 이 명령으로 돌린다."

Memory는 사장 수첩이다. "이 공급사는 금요일 오후엔 답이 늦다", "이 모듈은 에러 메시지가 misleading하다", "사용자가 말한 '느리다'는 대개 DB가 아니라 썸네일 생성 구간 문제였다."

공식 문서도 이 둘을 분리해서 설명한다. CLAUDE.md는 프로젝트·사용자·조직 차원의 지침이고, 자동 메모리는 Claude가 스스로 축적한 패턴과 학습이다. 둘 다 세션 시작 때 로드되지만, 자동 메모리는 앞부분 일부만 제한적으로 읽힌다. 문서 기준으로 첫 200줄 또는 25KB까지만 반영된다.³

이 제한 때문에 Memory를 잘 쓰려면 길게 적는 것보다 앞부분에 중요한 사실을 남기는 습관이 중요하다. 메모리를 일기장처럼 길게 늘어놓으면 정작 핵심이 묻힌다. 좋은 Memory는 대개 짧고, 반복 가능하고, 다음 세션에서 바로 도움이 되는 내용이다.

메모리에 잘 어울리는 정보는 보통 이런 종류다.

• Claude가 두 번 이상 같은 실수를 한 이유와 교정 방식

• 빌드나 배포에서 자주 부딪히는 실제 함정

• 특정 모듈의 비직관적인 동작 방식

• 당신의 반복적 선호, 예를 들어 커밋 메시지 톤이나 보고 방식

반대로 메모리에 넣기 애매한 것도 있다.

• 오늘만 유효한 TODO 목록

• 장문의 회의 로그

• 원본 에러 로그 전체

• 이미 CLAUDE.md에 더 잘 들어가 있는 고정 규칙

메모리를 확인할 때는 /memory가 유용하다. 어떤 메모리 파일이 로드됐는지 점검할 수 있고, 필요하면 수정 흐름도 잡을 수 있다.¹⁵ 순간적으로 남길 가치가 있는 사실이 생겼다면 #로 사실을 추가하는 방식도 쓸 수 있다.⁵ 예를 들어 "이 프로젝트에서 Stripe 웹훅 재전송은 정상 케이스다" 같은 문장은 나중에 중복 버그를 볼 때 꽤 큰 차이를 만든다.

핵심은 단순하다. 고정 규칙은 CLAUDE.md로, 반복 학습은 Memory로, 오늘의 작업 상태는 문서 파일로 남겨라. 이 셋이 섞이면 금방 지저분해진다.

좋은 세션은 이어 가는 세션이 아니라, 다시 시작하기 쉬운 세션이다

솔로 빌더는 종종 한 세션에 모든 것을 넣으려 한다. 아이디어 정리, DB 설계, 버그 수정, 테스트, 배포, 마케팅 문구까지 한 대화에서 처리하려 한다. 당장은 편해 보여도 결국 세션은 점점 둔해지고, Claude는 과거 작업의 그림자를 끌고 현재 문제를 본다.

오히려 잘 운영된 세션의 특징은 중단과 재개가 쉽다는 데 있다. 다시 시작해도 금방 복구될 수 있도록 핵심을 바깥 파일에 남겨 두고, 세션 안에는 당장의 작업에 필요한 맥락만 담는다.

실전 루틴은 생각보다 단순하다.

아침에 새 작업을 시작할 때는 먼저 범위를 좁힌다. "오늘은 결제 실패 원인 분석"처럼 하나의 결과로 세션을 정의한다. 필요하면 /memory로 로드된 메모리를 확인하고, 관련 파일만 읽힌다. 시작부터 "프로젝트 전체를 이해해 줘"라고 말하는 순간, 이미 컨텍스트 세금을 과하게 내기 시작한다.¹⁶

작업 중간에는 일정한 간격으로 /context를 확인한다. 체감이 이상해질 때까지 기다리지 말고, 분해 화면을 보고 메시지와 도구 출력이 커졌는지 확인하는 편이 훨씬 낫다.¹²

하나의 서브태스크가 끝났으면 /compact를 실행한다. 이때는 그냥 압축하지 말고, 무엇을 남길지 지시하는 편이 좋다. 예를 들어 "결정 사항, 변경 파일, 남은 TODO만 요약"처럼 말하면 쓸모 있는 압축이 된다.⁴

작업 성격이 바뀌면 /clear하거나 새 세션으로 넘어간다. 이때 아까까지 맥락이 많았으니 아깝다는 생각이 들 수 있다. 하지만 오래된 맥락이 새 작업을 방해하는 비용이 훨씬 크다.

하루를 마칠 때는 다음에 이어야 할 최소 정보만 남긴다. 무엇을 바꿨는지, 무엇이 아직 안 됐는지, 다음 시작점이 어디인지 정도면 충분하다. 내일의 나에게 넘겨줄 바통은 길고 친절한 소설보다 짧고 선명한 메모가 낫다.

컨텍스트 폴루션을 막는 5가지 패턴

문맥 오염은 대개 거창한 이유로 생기지 않는다. 작은 습관이 계속 쌓여서 생긴다. 아래 다섯 가지만 지켜도 세션의 체감 품질이 크게 달라진다.

• 한 세션, 한 결과물

  "로그인 버그 수정" 세션에서 갑자기 가격 정책 카피를 쓰기 시작하지 않는다. 기능 하나, 버그 하나, 조사 하나처럼 결과 기준으로 세션을 자른다. 같은 프로젝트라도 목표가 달라지면 새 세션이 더 낫다.⁶

• 참조하고, 퍼붓지 않는다

  긴 파일을 통째로 붙여넣는 대신 필요한 경로와 파일만 읽게 한다. src/ 전체를 읽히기보다 auth.ts와 jwt.ts를 지정하는 식이 낫다. 문제를 설명할 때도 배경설명을 길게 덧붙이기보다 원본 에러 로그, 실패 테스트, 재현 단계처럼 밀도 높은 데이터가 더 유용하다.⁶

• 조용한 명령을 쓴다

  도구 출력은 생각보다 비싸다. 실패한 테스트 200줄, 장황한 git log --all, 끝없이 이어지는 빌드 로그는 곧바로 세션을 탁하게 만든다. 필요한 범위만 돌리고, 필요한 길이만 본다. Claude가 볼 출력은 많아야 좋은 것이 아니라, 적절해야 좋다.⁶

• 지속 정보는 대화가 아니라 디스크에 둔다

  설계 결정, 현재 상태, 다음 시작점은 채팅 기록 속에만 두지 말고 파일로 남긴다. 진행 로그, 짧은 상태 문서, 작업 요약 파일이 있으면 다음 세션에서 필요한 것만 읽어 오면 된다. 긴 대화 히스토리를 억지로 보존하는 것보다 훨씬 경제적이다.³

• 넓은 탐색은 격리한다

  조사성 작업은 본 세션을 오염시키기 쉽다. 여러 파일을 뒤지고 비교하고 자료를 훑는 일은 별도 세션이나 서브에이전트로 보내는 편이 낫다. 서브에이전트는 별도의 컨텍스트 윈도우에서 일하고, 큰 파일 읽기 대신 요약만 돌아오므로 메인 세션을 훨씬 깨끗하게 유지할 수 있다.¹

여기에 하나를 더 보태자면, 쓰지 않을 MCP 연결을 너무 많이 달아두지 않는 것도 중요하다. 도구가 많다고 늘 똑똑해지는 것은 아니다. 오늘 안 쓸 도구는 오늘 세션의 책상 위에 없어도 된다.²

혼자 만드는 사람일수록 더 자주 버려야 한다

컨텍스트 관리는 기억을 많이 쌓는 기술이 아니다. 좋은 기억만 남기고 나머지를 버리는 기술이다.

이걸 이해하면 큰 모델에 대한 태도도 달라진다. 1M 컨텍스트가 있으면 편해지는 건 맞다. 하지만 더 큰 창은 더 많은 쓰레기를 쌓을 공간이 되기도 한다. 넓은 창이 정리를 대신해 주지는 않는다. 오히려 방이 넓을수록 정리 습관이 더 중요해지는 것과 비슷하다.

솔로 빌더에게 진짜 생산성은 "한 세션을 얼마나 오래 끌고 가느냐"가 아니라, "필요할 때 얼마나 빨리 맑은 상태로 다시 시작하느냐"에서 나온다. /compact는 이어 가기 위한 기술이고, /clear는 버리기 위한 기술이며, Memory는 반복 교정을 자산으로 바꾸는 기술이다. 이 셋을 함께 쓰면 Claude는 단순히 말을 잘하는 도구가 아니라, 점점 덜 헤매는 작업 파트너가 된다.

혼자 일할수록 더 잘 버려야 한다. 그래야 더 빨리 만든다.

참고

¹Explore the context window - Claude Code Docs

²Claude Code Context Window Explained: How to Read the Live Breakdown

³How Claude remembers your project

⁴Managing Claude Code's Context: a practical handbook

⁵Claude Code Cheat Sheet: Every Command, Shortcut, and Slash Command (2026)

⁶Understanding Context Windows and Token Limits