Claude Code가 '길어지면 갑자기 멍청해지는' 현상을 방지하는 법 — 컨텍스트를 가볍게 유지하는 7가지 유형 (Context

Claude Code를 장시간 사용하다 보면, 이런 경험을 한 적이 없으신가요?

• 아침에는 날카로웠는데, 오후의 동일한 세션에서 갑자기 지시 사항을 놓치기 시작한다
• 방금 결정했을 터인 방침을 아무렇지 않게 무시하고, 반대로 행동하기 시작한다
• 수정 요청을 하나만 했는데, 관계없는 파일까지 건드리기 시작한다
• 같은 설명을 몇 번이고 다시 해야 하며, 점점 답변이 성의 없어지는 느낌이 든다

이것은 모델이 갑자기 멍청해진 것도, 컨디션이 나빠진 것도 아닙. 원인은 거의 확실하게 컨텍스트 (Context)가 넘치고 있기 때문입니다.

Claude Code의 컨텍스트 윈도우 (Context Window)는 유한합니다. 대화, 읽어들인 파일, 도구 실행 결과가 모두 그곳에 쌓여가며, 가득 차게 되면 오래된 정보가 희석되고 지시의 우선순위가 흐릿해지며 정밀도가 떨어집니다. 긴 세션에서 지능이 떨어지는 것은 지능의 문제가 아니라 메모리 관리 (Memory Management)의 문제입니다.

이 기사에서는 컨텍스트를 의도적으로 가볍게 유지하기 위한 실무 테크닉을 7가지 유형으로 소개합니다. /compact와 /clear의 구분 사용법, 능동적인 컨텍스트 관리, 조사 결과의 외부 파일화 등, 모두 오늘 세션부터 바로 시도할 수 있으며 9할은 무료 기능만으로 완결됩니다.

이 기사는 "Context Engineering (컨텍스트 엔지니어링)", 즉 LLM에게 무엇을 기억시키고 무엇을 버리게 할지를 설계한다는 사고방식의 실전편입니다. 프롬프트 (Prompt) 작성법이 아니라, 컨텍스트의 내용을 관리하는 이야기입니다.

많은 사람이 빠지는 착각이 이것입니다. "정보를 많이 줄수록 AI는 더 똑똑하게 판단해 줄 것이다".

실제로는 반대입니다. 컨텍스트는 정보를 모아두는 저금통이 아니라, 작업 중에만 물건을 펼쳐두는 책상입니다. 책상이 서류로 가득 차면, 정말로 봐야 할 한 장이 다른 99장에 파묻히게 됩니다.

컨텍스트에 쌓이는 것들
├─ 당신과의 대화 (주고받은 모든 내용)
├─ 읽어들인 파일의 내용 (grep이나 Read 결과도 전부)
...

포인트는, 지금 불필요한 것일수록 적극적으로 버리는 것입니다. "만약을 위해 남겨두자"가 가장 효과가 없습니다. 아래의 7가지 유형은 모두 "무엇을 책상에 남기고, 무엇을 치울 것인가"라는 동일한 사상으로 관통되어 있습니다.

가장 빠르게 효과를 보면서도, 가장 구분해서 사용하지 않는 것이 이 두 가지입니다. 둘 다 "컨텍스트를 가볍게 하는" 커맨드(Command)이지만, 성질이 완전히 다릅니다.

커맨드	하는 일	남는 것	사용하는 상황
/clear	대화 이력을 통째로 파기하여 비움	CLAUDE.md 등의 초기 설정만	태스크 (Task)가 완전히 전환되었을 때
/compact	이력을 요약으로 압축하여 계속 진행	압축된 문맥의 요약	같은 태스크를 계속하고 싶지만 책상이 무거울 때

판단은 심플합니다.

• 이전 태스크의 문맥을 일절 끌어오고 싶지 않다 → /clear
• 같은 작업의 연속이지만, 지금까지의 경위는 요약만으로 충분하다 → /compact

흔한 실수: 다른 태스크로 옮겼음에도 /clear를 하지 않고 계속하는 패턴. 예를 들어 "인증 버그 수정"이 끝난 후, 동일한 세션에서 "README 작성"을 시작하면, 이미 불필요한 인증 코드의 읽기 결과가 책상에 남은 채로 유지됩니다. README를 쓰는 데 인증 스택 트레이스 (Stack Trace)는 필요 없습니다.

Before (태스크를 넘어가도 치우지 않음):

1. 인증 버그 수정 (src/auth/ 를 대량으로 읽음) → 완료
2. 그대로 "다음에 README 써줘"
→ 인증 파일의 내용이 컨텍스트에 계속 자리 잡고 있음
...

After (태스크의 경계에서 /clear):

1. 인증 버그 수정 → 완료
2. /clear ← 여기서 책상을 리셋
3. "README 써줘"
...

기준:
태스크의 "테마"가 바뀌면 /clear, 테마는 같지만 대화가 길어지면 /compact. 이 한 마디만 기억해 두면 9할은 대응할 수 있습니다.

/compact를 그냥 입력하기만 하는 사람이 많지만, /compact는 인자 (Argument)로 "압축 시 무엇을 우선적으로 남길지" 지정할 수 있습니다. 이것을 사용하느냐에 따라 압축 후의 정밀도가 완전히 달라집니다.

인자 없는 /compact는 "적당히" 요약해 주지만, 그 "적당히"가 당신의 의도와 어긋날 수 있습니다. 지금 바로 중요한 결정 사항이 압축 과정에서 깎여 나갈 수 있는 것입니다.

Before (통째로 맡기기):

/compact
→ 무엇이 남을지는 모델에게 맡김. 최근의 세세한 대화가 우선시되어,
초반에 결정한 "DB는 Postgres로 통일"이라는 중요한 방침이 희석될 수 있음

After (남길 것을 지정):

/compact 지금까지의 설계 판단(DB는 Postgres, 인증은 JWT, API는 REST)과
미완료된 TODO 리스트를 반드시 남겨줘. 디버깅 중의 시행착오 상세 내용은 버려도 좋아.

이렇게 하면 요약에 "버리고 싶지 않은 핵심"이 확실히 남습니다. 요령은 두 가지입니다.

• 남길 것을 명시하기 (결정 사항, 제약 조건, 미완료 태스크)
• 버려도 되는 것도 명시하기 (시행착오 로그, 이미 해결된 에러, 다 읽은 파일의 내용)

특히 두 번째 방법이 효과적입니다. "디버깅의 중간 과정은 필요 없어"라고 말해주면, 책상 위의 커다란 쓰레기를 한꺼번에 치우는 것과 같습니다.

이것이 Context Engineering (컨텍스트 엔지니어링)의 핵심입니다. 기억해 두어야 할 정보를 컨텍스트가 아니라 파일에 기록하는 것입니다.

큰 작업을 하기 전에는 반드시 "코드베이스를 조사한다", "사양을 정리한다"라는 페이즈 (Phase)가 있습니다. 여기서 읽어들인 방대한 정보는 그대로 두면 전부 컨텍스트에 쌓이게 됩니다. 게다가 조사 내용은 이후의 세션에서도 몇 번이고 다시 참조하고 싶어지는 종류의 것입니다.

해결책은 조사 결과를 해당 세션의 메모리 (컨텍스트)에 그대로 두지 않고, .md 파일에 기록하는 것입니다.

Before (조사 결과가 컨텍스트에 쌓임):

"src/ 하위를 전부 읽어서 아키텍처를 파악해줘"
→ 수십 개의 파일 내용이 컨텍스트에 쌓임
→ 그대로 구현에 들어가면 이미 책상의 절반이 차 있음
...

After (조사 결과를 파일화):

"src/ 하위를 조사해서 아키텍처 개요를
docs/architecture-notes.md 에 정리해줘.
내용은 다음 3가지 포인트로 압축해:
...

이렇게 하면,

• 조사의 성과만 docs/architecture-notes.md에 남음
• 다음 세션에서는 "docs/architecture-notes.md를 읽어줘"라고 말하면, 수십 개의 파일을 다시 로드하지 않고도 파악 상태로 복귀할 수 있음
• 컨텍스트에는 "파일로 정리했다"라는 사실과 그 요약만 남아서 책상이 가벼워짐

외부 파일화가 효과적인 항목 목록:

정보 종류	기록할 곳의 예	파일로 만드는 것이 좋은 이유
코드베이스 조사 결과	docs/architecture-notes.md	세션을 넘나들며 재사용할 수 있음
설계 판단 · 결정 로그	docs/decisions.md	"왜 그렇게 했는지"를 잊지 않음
진행 중인 태스크의 TODO	TODO.md	/compact나 /clear로 지워지지 않음
긴 사양 · 요구사항	docs/spec.md	매번 다시 붙여넣을 필요가 없음

포인트는 컨텍스트는 휘발(삭제)되지만, 파일은 남는다는 비대칭성을 이용하는 것입니다. 기억해야 할 것은 파일로, 책상 위에는 "지금 다루고 있는 것"만 두세요.

컨텍스트가 팽창하는 가장 큰 범인은 사실 대화 그 자체보다 파일 읽기입니다. 하나의 큰 파일을 통째로 읽으면 그것만으로도 수백 줄 분량의 책상이 채워집니다.

Claude Code에게 "이 파일 읽어줘"라고 대충 부탁하면 파일 전체를 읽어버릴 때가 있습니다. 정말 필요한 것이 특정 함수 하나뿐일지라도 말입니다.

Before (통째로 읽기):

"utils.ts를 읽고 formatDate 함수를 수정해줘"
→ 2000행의 utils.ts가 전부 컨텍스트에 올라감
→ 사용하는 것은 formatDate의 20행뿐인데도

After (범위를 좁혀서 읽게 하기):

"utils.ts의 formatDate 함수만을 대상으로 수정해줘.
먼저 grep으로 formatDate의 정의 위치를 특정하고,
그 함수의 전후 맥락만 읽어서 작업해줘."

명시적으로 "먼저 찾은 다음, 필요한 범위만 읽어라"라는 절차를 지시하면 불필요한 읽기가 대폭 줄어듭니다. 이는 유형 3인 "외부 파일화"와 더불어, 책상을 가볍게 유지하는 데 가장 효과가 큰 테크닉입니다.

보충: 대량의 파일을 횡단 조사하고 싶을 때는, 조사 자체를 서브 에이전트 (Sub-agent)에게 위임하여 "결과 요약만" 받는 것도 유효합니다. 서브 에이전트의 로딩은 부모의 컨텍스트 (Context)를 소비하지 않기 때문에, 책상을 어지럽히지 않고 조사할 수 있습니다.

빌드 로그, 테스트 출력, 스택 트레이스 (Stack trace). 이것들은 단 한 번의 출력으로 컨텍스트를 단숨에 잡아먹는 지뢰입니다. 실패한 테스트의 풀 로그 (Full log)가 수백 줄에 달하는 일은 흔히 발생합니다.

그리고 까다로운 점은, 문제가 해결된 후에도 그 로그가 책상에 계속 남아 있다는 것입니다. 이미 수정한 에러의 스택 트레이스를 그 이후로 계속 안고 작업할 이유는 없습니다.

대책은 2단계로 구성됩니다.

(1) 출력을 압축해서 전달하기

에러 전문을 그대로 붙여넣는 것이 아니라, 요점만 추출하도록 지시합니다.

Before: 테스트 로그 전체를 컨텍스트에 포함시킴
After: "테스트를 실행하고, 실패한 테스트 이름과 에러의 요점
(메시지 1줄 + 해당 파일:줄 번호)만 보고해줘.
...

(2) 해결되면 책상에서 치우기

에러가 고쳐졌다면, 그 디버깅 과정의 시행착오는 더 이상 필요 없습니다. 유형 2인 /compact를 사용하여 "디버깅 과정은 버려도 OK"라고 지정하여 정리합니다.

(버그 수정 후)
/compact 버그는 수정 완료됨. 수정 내용(◯◯의 null 체크 추가)만 남기고,
디버깅 중의 시행착오와 에러 로그는 전부 버려줘

Before / After로 책상의 무게를 비교하면 다음과 같습니다.

항목
Before	실패 로그 전문 × 5회분 + 시도했던 코드 전부 + 관련 없는 로딩 파일
After	"◯◯의 null 체크를 추가하여 수정함"이라는 단 한 줄

지금까지의 테크닉은 모두 "책상이 무거워지기 전에, 또는 무거워지면 정리한다"는 능동적인 관리입니다. 그렇다면 언제 정리해야 할까요? 무거워진 뒤에 깨닫는 것은 이미 늦다는 점이 어려운 부분입니다.

실무에서 사용할 수 있는 "정리 타이밍"의 신호를 제시합니다. 이것들이 나타나면 책상이 넘치기 직전이라는 신호입니다.

컨텍스트 과부하의 황색 신호
├─ 방금 지시한 내용을 놓치기 시작함
├─ 초반에 결정한 방침과 반대되는 행동을 하기 시작함
...

이 중 하나라도 나타나면, **태스크가 동일하다면 유형 2의 /compact를, 태스크가 바뀌었다면 유형 1의 /clear**를 입력합니다. 억지로 계속 진행해도 정확도는 돌아오지 않습니다.

운용 팁: 구분점에서 미리 정리하기

황색 신호를 기다리기보다, 작업의 자연스러운 구분점에서 미리 정리하는 것이 더 안전합니다. 추천하는 습관은 다음과 같습니다.

하나의 기능 또는 하나의 버그 수정이 "완료"되면, 다음 단계로 넘어가기 전에:
├─ 성과와 결정을 파일로 기록 (유형 3)
├─ 동일한 테마를 계속한다면 /compact로 요약 (유형 2)
...

"태스크 완료 = 정리 타이밍"이라고 정해두면, 책상이 넘치기 전에 항상 리셋이 이루어집니다.

마지막은, 애초에 컨텍스트에 매번 쌓아두지 않도록 만드는 유형입니다.

매 세션마다 같은 내용을 설명하고 있지는 않나요? "이 프로젝트는 Postgres를 사용한다", "테스트는 반드시 vitest로 작성한다", "커밋 메시지는 일본어로 한다". 이것들을 대화로 매번 전달하면 그만큼 책상이 채워지고, 게다가 /clear를 할 때마다 사라져서 다시 설명해야 합니다.

이러한 변하지 않는 전제는 대화가 아니라 CLAUDE.md에 적어둡니다. CLAUDE.md는 세션의 초기 설정으로서 항상 로드되기 때문에, /clear를 해도 사라지지 않습니다.

대화에서 매번 쓸 필요가 없는 것 (→ CLAUDE.md로)
├─ 기술 스택 고정 사항 (언어·DB·프레임워크)
├─ 코딩 규약·명명 규칙
...

즉 **"불변의 전제는 CLAUDE.md에, 가변적인 태스크는 대화에"**라고 배치 장소를 분리합니다. 이렇게 하면 /clear를 가볍게 사용할 수 있게 되어, 유형 1~6의 정리가 훨씬 수월해집니다.

CLAUDE.md 내용의 설계(무엇을 쓰고 무엇을 쓰지 않을 것인가)는 그 자체로 깊이 있는 주제이므로, 여기서는 "컨텍스트를 가볍게 유지하기 위해 전제를 분리하는 그릇으로 사용한다"는 관점에만 집중했습니다.

유형	요점
1. /clear와 /compact의 구분 사용	주제가 바뀌면 /clear, 이어서 진행하면 /compact
...

긴 세션에서 정확도가 떨어지는 것은 모델의 한계가 아니라, 컨텍스트 관리 (Context Management) 설계가 누락되었기 때문입니다. 책상 위를 "지금 다루고 있는 것만" 있도록 유지한다면, Claude Code는 장시간 사용하더라도 업무 시작 직후의 날카로움을 유지할 것입니다.

7가지를 한꺼번에 모두 수행할 필요는 없습니다. 우선 **유형 1(/clear와 /compact의 구분 사용)**과 유형 3(조사 결과의 파일화) 두 가지만이라도 시도해 보세요. 그것만으로도 오후에 갑자기 성능이 떨어지는 현상이 체감될 정도로 줄어들 것입니다.

본 기사의 내용을 실제 프로젝트에서 테스트하려면, 토대가 되는 CLAUDE.md와 폴더 구조가 있어야 원활합니다. 제가 사용 중인 스타터 구성을 무료로 공개하고 있습니다.

무료 스타터 (GitHub):

더 나아가, 워크플로우(Workflow)나 서브 에이전트 (Sub-agent) 설계를 "실행 가능한 스킬 파일"로 묶은 패키지도 준비되어 있습니다. 로컬에서 /명령어로 호출할 수 있는 형태입니다.

스타터 팩 (¥1,980): CLAUDE.md 템플릿 7종 · Hooks · MCP 설정

https://streamsolty.gumroad.com/l/gliwz -
워크플로우 OS (¥9,800): 79개의 스킬 + 워크플로우 3개 + 프롬프트(Prompt) 10종

우선 무료 리포지토리부터 시도해 보시고, 더 체계적으로 사용하고 싶어질 때 검토해 주셔도 충분합니다. 기사의 내용만으로도 효과는 나타날 것입니다.

최신 팁은 X에서도 발신하고 있습니다: @k___n___t_1125