앞선 두 편에서 진단을 마쳤습니다. 컨텍스트 윈도우는 유한하고(1편), 채운다고 다 쓰이는 것도 아니며 길어질수록 오히려 성능이 떨어집니다(2편). 그럼 처방은 하나로 모입니다. 컨텍스트를 관리해야 합니다. 그리고 Claude Code를 비롯한 코딩 에이전트들이 이를 위해 쥐여주는 가장 기본 도구가 /clear와 /compact입니다.
두 명령 모두 “컨텍스트를 줄인다”는 점은 같습니다. 그래서 아무거나 쓰거나, 잔량 경고가 뜰 때까지 둘 다 안 쓰는 경우가 많은데요. 동작 원리가 완전히 달라서 상황에 맞지 않게 쓰면 작업 맥락을 통째로 날리거나, 반대로 지저분한 컨텍스트를 계속 끌고 다니게 됩니다. 이번 편에서는 두 명령이 내부에서 정확히 뭘 하는지부터 보고, 언제 뭘 쓸지 기준을 세웁니다.
/clear, 이력을 지우고 백지에서 시작한다
/clear의 동작은 단순합니다. 지금까지의 대화 이력을 전부 버립니다. 다음 턴의 모델은 시스템 프롬프트와 CLAUDE.md 같은 상시 로드 파일, 그리고 방금 입력한 새 메시지만 들고 시작해요. 1편에서 본 구조를 떠올리면 의미가 명확합니다. 매 턴 이력 전체를 다시 보내는 게 대화의 실체이므로, 이력을 지운다는 건 모델에게 보낼 꾸러미를 초기화한다는 뜻입니다.
잃는 것은 대화 맥락 전부, 얻는 것은 깨끗한 컨텍스트입니다. 2편에서 본 lost in the middle도, 낡은 파일 버전과 실패 로그가 일으키는 혼선도 이력이 사라지면 같이 사라집니다. 토큰 잔량은 최대로 회복되고 매 턴 재전송되는 입력이 줄어드니 응답도 빨라지고 비용도 내려갑니다.
그래서 /clear의 자리는 작업 경계입니다. 버그 하나를 고치고 커밋까지 마쳤다면, 다음 기능 작업은 이전 버그의 스택 트레이스나 시행착오를 알 필요가 없습니다. 오히려 섞이면 해로울 뿐이죠. 작업이 끝날 때마다 /clear로 끊고 가는 것만으로 세션 후반 품질 저하의 상당 부분이 예방됩니다.
/compact, 이력을 요약본으로 갈아 끼운다
/compact는 다르게 접근합니다. 이력을 버리는 대신, 모델에게 지금까지의 대화를 요약시키고 원본 이력을 그 요약본으로 교체합니다. 수만 토큰짜리 이력이 요약 수천 토큰으로 줄어드니 잔량은 회복되면서 작업의 큰 줄기는 남습니다.
핵심은 이게 손실 압축이라는 점입니다. 요약은 모델이 “중요해 보이는 것”을 고르는 과정이고 뭐가 살아남을지 사용자가 통제할 수 없습니다. 파일 경로, 시도했다가 접은 접근법, 에러 메시지의 정확한 문구처럼 구체적인 디테일이 요약 과정에서 뭉개지기 쉬워요. compact 직후의 에이전트가 방금까지 만지던 파일을 다시 읽어보는 것도, 요약본만으로는 정확한 상태를 모르기 때문입니다.
다행히 통제 수단이 아예 없지는 않습니다. Claude Code의 /compact는 뒤에 지시를 붙일 수 있어요. “/compact 이번 마이그레이션에서 확정한 스키마 변경과 남은 파일 목록 위주로 남겨줘”처럼 쓰면 요약의 초점을 지정할 수 있습니다. 무엇이 중요한지는 사용자가 제일 잘 아니, 압축을 맡기더라도 방향은 잡아주는 겁니다.
선택 기준, 이어갈 맥락이 있는가
기준은 질문 하나로 정리됩니다. 다음 턴의 에이전트가 지금까지의 맥락을 알아야 하는가.
- 작업이 끝났고 다음 작업은 별개다 → /clear. 고민할 것 없이 기본값입니다.
- 같은 작업이 이어지는데 잔량이 부족하다 → /compact. 단, 남길 것을 지시어로 지정합니다.
- 같은 작업인데 에이전트가 헛돌기 시작했다 → 의외로 /clear가 낫습니다. 시행착오로 오염된 컨텍스트는 요약해도 오염이 농축될 뿐입니다. 현재 상태와 다음 할 일을 정리시켜 파일로 남기고, /clear 후 그 파일로 다시 시작하는 쪽이 깨끗합니다.
세 번째 경우가 힌트를 줍니다. clear와 compact 사이에 제3의 길이 있어요. 컨텍스트에서 살릴 내용을 파일로 내려두는 겁니다. “지금까지 결정사항과 남은 작업을 PLAN.md에 정리해줘”라고 시킨 뒤 /clear하고, 새 세션에서 PLAN.md를 읽히면 요약의 불확실성 없이 필요한 맥락만 정확히 넘어갑니다. 요약을 모델에게 맡기는 /compact와 달리 남길 내용이 눈에 보이는 파일로 존재하니 검증도 수정도 가능하죠. 이 “외부화” 패턴은 6편에서 메모리를 다룰 때 더 깊게 들어갑니다.
auto-compact를 기다리면 안 되는 이유
Claude Code는 잔량이 임계치에 닿으면 자동으로 compact를 실행합니다. 안전장치로는 훌륭하지만, 이것에 의존하는 건 다른 문제입니다.
auto-compact의 발동 시점은 토큰 잔량이 정합니다. 작업 흐름과 무관하다는 뜻이에요. 리팩터링이 반쯤 진행돼 파일 다섯 개가 수정 중이고 테스트가 깨져 있는 최악의 타이밍에 압축이 걸릴 수 있습니다. 이 시점의 요약은 어중간한 중간 상태를 뭉뚱그리고, 이후 에이전트는 미묘하게 어긋난 이해를 들고 작업을 이어갑니다. 2편에서 본 context poisoning이 요약을 통로로 일어나는 셈입니다.
그래서 숙련자일수록 잔량 표시를 게이지처럼 관리합니다. 논리적 매듭(커밋, 테스트 통과, 결정 확정)마다 상태를 파일로 정리해 두고 잔량이 20~30% 남았을 때 매듭을 지으며 스스로 /clear나 /compact 타이밍을 정하는 거죠. 압축은 피할 수 없더라도, 언제 어떻게 압축될지는 통제하는 겁니다.
정리
- /clear는 이력 삭제, /compact는 요약 교체입니다. 전자는 맥락을 버리고 잔량을 최대로 회복하며, 후자는 맥락의 줄기를 남기는 대신 디테일이 손실됩니다.
- 기본값은 작업 경계마다 /clear입니다. 이어갈 맥락이 있을 때만 /compact를 쓰고, 남길 내용을 지시어로 지정합니다.
- 에이전트가 헛돌면 요약 대신 상태를 파일로 정리시키고 /clear로 재시작하는 편이 깨끗합니다.
- auto-compact는 안전장치일 뿐, 압축 타이밍은 작업 매듭에 맞춰 직접 정하는 게 좋습니다.
여기까지가 대화 이력 관리입니다. 그런데 /clear를 해도 사라지지 않고 매 턴 실려 가는 컨텍스트가 있습니다. 시스템 프롬프트, CLAUDE.md, 도구 정의 같은 상시 로드 영역인데요. 다음 편에서는 이 고정 비용을 설계하는 법을 다룹니다. CLAUDE.md에 뭘 넣고 뭘 빼야 하는지가 핵심입니다.