/clear vs /compact

완전 동감함. 컨텍스트 잘 지켜보다가 조금이라도 커지면 바로 /handoff /clear /pickup 루틴 쓸 준비 해야 함. 난 보통 opus-4-6[1M] 쓸 때 25% 정도 차면 서브 에이전트한테 작업 넘기고 깔끔하게 핸드오프할 지점 찾으라고 시킴.

난 그래서 openspec을 씀.

아니, 이 사람 조언은 듣지 마셈. 긴 작업 진행 상황에서 진짜 중요한 것만 남기려면 더 나은 메모리 전략(.MD 파일 같은 거 쓰면 됨)을 써서 /clear 하는 게 맞음.

여기 몇 가지 문제가 있음: 1. 950k context 세션을 유지했는데, 이러면 안 됨. 최대치가 1m이라 해도 context window가 커질수록 모델이 멍청해짐. 내용 까먹고, hallucination 발생하고, 전반적으로 성능이 떨어짐. context window 크기를 200-300k 정도로 유지하는 걸 목표로 하셈. 이걸 달성할 수 있는 여러 전략이 있음. 2. context window가 큰 세션에 cache가 만료된 상태로 돌아왔음. Cache read는 10% 비용만 들지만, 1시간 cache를 다시 쓰려면 cache write에 200% 비용이 들어감. 그래서 어제 이어서 하는 대신 오늘 대화를 다시 시작하느라 토큰을 20배나 태운 거임. 세션은 끝내야 함. 1 세션 = 1 작업 원칙을 지키고, 메타 대화를 추적하려면 문서에 기록해두셈. 필요할 때마다 문서에서 읽어와서 관련 내용을 context에 새로 채우는 식으로 하셈. 3. 만료된 cache에 compact를 돌렸음. 이건 위에서 말한 것처럼 전체 기록을 다시 cache하는 동시에, 전체 내용을 요약해서 context에 다시 쓰는 꼴임(이건 input 비용의 5배가 드는 write임). Compaction은 보통 뭐가 중요한지 구분 못 해서 별로임. 차라리 대화에서 얻은 인사이트를 문서로 정리하고 세션을 끝내는 게 나음. 다음 날 필요한 작업에 맞춰서 새 세션을 시작하셈. 그러면 30k 정도로도 필요한 모든 걸 갖추고 시작할 수 있음.

Compacting을 하면 즉시 캐시가 무효화되고, 사실상 잘려 나가거나 압축된 기록을 가진 새로운 채팅이 로드됨. 장기 세션의 99% 경우에서, compact 비용 + 캐시 무효화 비용을 지불할 뿐만 아니라 그냥 /clear보다 훨씬 안 좋음.

난 기본적으로 모든 세션을 눈에 띄는 문제 없이 최대 컨텍스트까지 돌리는데, 800k가 넘어가면 아주 초반 컨텍스트를 '까먹기' 시작함. 주로 그 시점엔 위에 컨텍스트가 너무 쌓여 있어서 그런 건데, 그냥 콜드 스타트를 위해 문서들을 최신 상태로 유지함. /clear도 당연히 콜드 캐시로 시작하지만, 적어도 내가 제어할 수 있는 완전한 컨텍스트를 새로운 에이전트에게 줄 수 있고, 마지막에 compact 안 된 에이전트가 세션 끝에 기록을 남기니까.

난 compact 써서 좋은 경험을 한 적이 거의 없음. 품질이랑 결과가 거의 항상 영향을 받거든. 반면에 긴 컨텍스트로 세션을 돌리면 모든 턴이 세션 내내 캐싱되니까 가장 효율적인 방식으로 캐시를 치는 셈이고, 무작위로 잘려 나간 게 아니라 채팅의 실제 기록을 얻을 수 있음. 난 /compact가 필요한 이유를 전혀 모르겠음. 나한테는 항상 안 좋은 결과만 나왔거든.

예상했던 결과임. 레포지토리가 컨텍스트가 되도록 워크플로우를 설계하고 자주 clear를 해.

지금은 캐시(컨텍스트 대부분이 이 캐시가 됨)가 '웜(warm)' 상태로 유지되는 1시간짜리 유휴 윈도우가 있어. 그 시간이 지나면 시스템이 캐시를 비워버리지.

'콜드(cold)' 세션에서 Claude가 무언가를 수행해야 하는 작업을 하면 시스템이 전체 컨텍스트를 다시 로드해야 해.

캐시를 다시 로드하지 않고 할 수 있는 작업 목록은 다음과 같아:

클라이언트 & 세션 제어

• /exit (또는 /quit) – Claude Code 세션을 즉시 종료함.

• /clear (또는 /reset, /new) – 현재 대화 기록을 삭제함. 이전 캐시를 '저장'하는 건 아니지만, 아주 작고 새로운 캐시로 다음 작업을 시작하게 해서 비대해진 컨텍스트를 다시 로드하는 비용을 내지 않게 해줌.

• /background – 활성 세션을 분리해서 백그라운드 에이전트로 완전히 실행되게 하고, 현재 터미널을 자유롭게 해줌.

• /color [color|default] – 프롬프트 바의 시각적 테마나 색상을 로컬에서 업데이트함.

상태 & 정보 명령어

• /usage – 플랜 제한과 현재 크레딧 또는 토큰 사용량 지표를 로컬에서 불러옴.

• /tasks – 채팅 로그를 다시 보내지 않고 이 세션에서 실행 중인 백그라운드 작업이나 활성 서브 에이전트 목록을 보여줌.

• /help – 사용 가능한 명령어와 자동 완성 가이드라인의 클라이언트 측 카탈로그를 표시함.