Claude Code에서 긴 작업을 시작하기 전에: compact 시점과 서브에이전트·사용량 관리
Claude Code에서 긴 작업을 시작하기 전에 다음 단계에 필요한 맥락을 확인하세요. compact 시점, 하위 에이전트의 작업 범위, 대기와 재개 중 중복 실행을 관리하고 사용량과 완료 결과를 함께 평가합니다. 구독 한도와 토큰 사용량, 외부 플러그인의 경계도 구분합니다.
목차

Claude Code에 코드 읽기, 수정, 테스트를 오랫동안 맡기려 할 때 컨텍스트부터 서둘러 비울 필요는 없습니다. 그렇다고 “1M을 다 활용하겠다”는 이유만으로 지난 대화를 전부 남겨 둘 필요도 없습니다.
먼저 확인할 것은 따로 있습니다. 다음 단계에 원래 정보 중 어떤 세부 사항이 여전히 필요한가요? 위임하려는 작업은 독립적으로 끝낼 수 있나요? 작업이 끝난 뒤에는 사용량 숫자가 작아졌다는 사실만이 아니라, 무엇을 근거로 이번 변경이 효과적이었다고 판단할 건가요?
9월 19일, ZryMiller는 자신의 작업 방식을 바꿨다고 공유했습니다. 이전에는 자주 compact를 실행했지만, 자신이 기본값이라고 부른 1M 윈도로 돌아간 뒤 사용 경험이 크게 좋아졌다고 느꼈고, 첫 앱 출시를 준비 중이라고 밝혔습니다. 다만 원문에는 비교 가능한 작업, 변경 전후 사용량, 앱의 최종 출시 결과가 없습니다. 참고할 만한 개인 경험이지만, “압축하지 않으면 모든 긴 작업이 더 잘된다”는 결론을 뒷받침하지는 못합니다.
“자주 압축하기”와 “절대 압축하지 않기” 중 하나를 고르기보다, 구체적인 작업 단계가 끝나는 시점에 판단하는 편이 좋습니다.
먼저 현재 무엇을 사용하고 있는지 확인하기
터미널에서 claude --version을 실행하고 클라이언트 버전을 기록합니다. 세션에 들어간 뒤에는 /status로 계정과 현재 모델을 확인하고, /model로 선택 가능한 모델과 관련 설정을 살펴본 다음, /context로 컨텍스트 사용 현황을 확인합니다. 사용량 정보가 필요할 때는 /usage를 실행합니다. 이 명령들은 서로 다른 정보를 보여 주는 도구이지, 같은 것을 재는 척도가 아닙니다. 공식 명령어 레퍼런스 · 사용량 안내
이번 논의에 등장하는 정식 모델명은 Claude Fable 5.1이며, Claude API의 모델 ID는 claude-fable-5-1입니다. 공식 사양에 기재된 컨텍스트 윈도는 1M 토큰입니다. 모델명, Claude Code 버전, effort 설정은 서로 다른 항목입니다. 기록할 때 단순히 “Fable 사용”이나 “Ultra 사용”이라고만 적지 마세요. 공식 모델 사양
모델이 1M을 지원한다고 해서 모든 계정, 모델, 접속 경로에 같은 이용 조건이 자동으로 적용되는 것은 아닙니다. 예를 들어 공식 문서는 Opus의 1M 이용을 Max, Team, Enterprise에서는 플랜에 포함되는 경우와 Pro에서는 usage credits가 필요한 경우로 구분합니다. 구독 플랜에서 Sonnet 4.6의 1M을 이용할 때도 usage credits가 필요합니다. 이 조건을 다른 모델에 그대로 적용하지 마세요. 클라이언트 설정, 모델 매핑, 게이트웨이 지원 여부도 확인해야 합니다. 선택기에 [1m]을 붙인다고 서버 측 모델의 능력이 저절로 확장되지는 않습니다. 1M 이용 조건과 모델 설정
혼동하기 쉬운 세 가지 수치도 구분해야 합니다. 컨텍스트 사용량은 현재 요청에 담아야 할 내용의 양입니다. 누적 토큰 사용량은 요청들이 처리한 입력, 출력, 캐시된 내용의 양을 기록한 것입니다. 구독 한도는 해당 사용량 집계 기간에 계정에 적용되는 제한입니다. 5시간이나 1주일은 한도를 집계하는 기간이지, 작업이 5시간이나 1주일 내내 실행될 수 있다는 보장이 아닙니다. 캐시에 적중한 내용도 컨텍스트 공간을 차지하지만, API 요금에는 별도의 캐시 단가가 적용될 수 있습니다. 따라서 “컨텍스트 30% 사용”을 “5시간 한도 30% 소진”으로 환산할 수 없으며, 1M 역시 무료로 반복 처리할 수 있는 토큰 할당량이 아닙니다. 컨텍스트와 캐시 · API 요금 구조
compact를 실행하기 전에 다음 단계가 무엇에 의존하는지 살펴보기
프런트엔드, API, 데이터베이스에 걸친 오류를 조사하고 있다고 가정해 보겠습니다. 방금 읽은 코드 조각, 실패한 요청 하나, 특정 경계 조건을 아직 검증 가능한 결론으로 정리하지 못한 상태입니다. 이때 “대화가 길어졌다”는 이유만으로 압축하면, 다음 단계에서 대조해야 할 핵심 세부 정보를 잃을 수 있습니다.
반대로 원인이 명확해졌고 관련 파일과 근거 위치를 기록했으며, 합의된 계획에 따라 구현 일부만 수정하면 되는 상황이라면 앞서 진행한 많은 검색 과정이 현재 윈도에 계속 남아 있을 필요는 없을 수 있습니다.
압축하기 좋은 시점은 보편적인 사용률로 정해지지 않습니다. 한 단계가 끝났고, 신뢰할 수 있는 기록을 바탕으로 다음 작업을 이어 갈 수 있는지가 기준입니다. 이는 작업 방식에 관한 제안이지, 모델에 정해진 임곗값이 아닙니다.
먼저 Claude에게 지정한 작업 기록에 필요한 상태를 적도록 요청합니다. 확인된 사실과 근거 위치, 실제로 수정한 파일, 실행한 검사와 실제 결과, 미해결 문제, 다음 단계가 포함되어야 합니다. 대화를 통째로 복사할 필요는 없으며, 검증하지 않은 추측을 결론처럼 기록해서도 안 됩니다.
그다음 유지할 내용을 명시해 기본 /compact 명령을 사용할 수 있습니다. 압축 작동 방식
/compact 현재 목표, 확인된 결론과 근거 위치, 수정한 파일, 실행한 검사와 실제 결과, 미해결 문제, 다음 단계를 유지하세요. 중복 검색과 이미 배제한 가능성에 관한 논의는 제거하세요.
이 문장은 요약에 대한 요청이지, “정보가 전혀 손실되지 않는다”는 보장이 아닙니다. 수정을 계속하기 전에 Claude에게 압축된 컨텍스트를 바탕으로 다음 단계를 설명하게 하고, 주요 제약을 실제 파일 및 작업 기록과 대조하세요. 경계 조건이 빠졌다면 먼저 복원해야 합니다. 구현이 엉뚱한 방향으로 진행된 뒤 재작업할 때까지 기다리지 마세요.
다음 일이 이전과 무관한 새 작업이라면, 현재 결과와 인수인계 정보를 저장한 뒤 /clear로 새 세션을 여는 편이 대체로 간단합니다. 원래 대화로 돌아가야 할 때는 /resume을 사용합니다. 세션을 비워도 이미 발생한 사용량이 반환되거나 구독 한도가 초기화되지는 않습니다. 세션 명령어 · 사용량 표시에서 초기화되는 범위
Claude Code에는 이미 자동 압축 기능이 있으므로 이 방법을 적용하기 위해 플러그인을 설치할 필요는 없습니다. v2.1.221 이상에서는 /autocompact도 제공합니다. 인수 없이 실행하면 현재 자동 압축 윈도를 보여 주고, /autocompact auto는 모델에 맞춰 조정된 윈도 설정으로 되돌립니다. 후자는 모델에 선호를 전달하는 데 그치지 않고 설정을 저장합니다. 모델의 최대 컨텍스트 윈도와 자동 압축 윈도는 같은 개념이 아닙니다. 자동 압축 명령어
HKTECH_AI는 한 번의 compact가 5시간 한도의 약 15%를 소모할 수 있다고 추정했습니다. 게시물에는 청구 내역이나 계산 방법이 없으므로 이 비율을 사용 규칙으로 삼아서는 안 됩니다. 실제로 비교해야 할 것은 압축 이후 후속 요청에 반복해서 담는 내용이 줄었는지, 그리고 그 대가로 다시 읽기, 재설명, 오류 수정이 필요해졌는지입니다.
서브에이전트로 역할을 나눌 때는 “한 번에 하나”를 어떻게 적용하는지 구분하기
SHCH는 Fable이 계획과 판단을 맡고, Sonnet 기반 Scout가 검색하며, Opus 기반 Builder가 명확한 작업을 수행하는 구성을 공유했습니다. 특히 한 번에 서브에이전트 하나만 호출하라고 조언했습니다.
공개한 Builder 스크린샷에는 기존 계획을 따르고, 계획에 문제가 있으면 멈춰서 보고하며, 추가 서브에이전트를 시작하지 않고, 검사 결과를 설명하라는 내용이 강조되어 있습니다. 이런 지시는 역할과 책임을 명확히 한다는 점에서 가치가 있습니다. 하지만 이미지 속 “추가 서브에이전트를 시작하지 말라”는 여전히 프롬프트상의 제약이지, 소프트웨어가 강제하는 상한이 아닙니다. 작성자는 여러 메인 세션을 동시에 실행한다고도 했으며, 확인 가능한 변경 전후 사용량을 공개하지 않았습니다. 따라서 이 구성을 “계정 전체에서 에이전트 하나만 실행”하는 방법으로 해석할 수 없고, 일정 비율의 절감 효과를 약속할 수도 없습니다.
일반 서브에이전트는 별도의 컨텍스트에서 시작해 위임받은 작업과 관련 설정을 전달받습니다. 메인 세션의 전체 대화 이력이 자동으로 주어지지는 않으며, 기존 대화를 상속하는 것은 fork 서브에이전트입니다. 중간 정보가 많은 조사 과정을 서브에이전트에 맡기면 메인 세션이 직접 담는 과정 정보는 줄일 수 있습니다. 다만 서브에이전트의 요청도 토큰을 처리하고, 반환한 결과 역시 메인 세션에 들어옵니다. 서브에이전트의 컨텍스트 범위
따라서 “동시에 몇 개를 실행할까?”보다 “이 작업을 위임할 가치가 있을까?”를 먼저 물어야 합니다. 단순한 검색에 계획자, 조사자, 실행자 전체 구성이 필요하지는 않습니다. 같은 파일을 반복해서 수정할 두 작업 역시 동시 실행에 적합하다고 볼 수 없습니다. 정말 독립적이며 산출물이 명확한 조사가 병렬 비교에 더 알맞습니다.
작업 지시를 다음처럼 구체적으로 작성할 수 있습니다.
목표: 이번에 합의한 변경을 완료하고 직접 관련된 검사를 통과합니다.
허용 변경 범위: 이번 요청에 해당하는 구현과 관련 테스트입니다.
진행 방식: 단순 검색은 직접 수행합니다. 위임이 꼭 필요하다면 해당 하위 작업에 필요한 배경과 산출물 요구사항만 전달하고, 한 번에 서브에이전트 하나를 배정합니다. 대기 중에는 같은 상태를 반복해서 조회하지 않습니다.
완료 조건: 인수 기준에 맞게 결과를 제공하고 관련 검사가 통과하면 멈춥니다. 막힌 경우 완료한 내용과 원인을 설명하고, 같은 작업을 다시 시작하지 않습니다.
이 역시 행동에 관한 지시입니다. 기본 서브에이전트 생성을 실제로 제한하려면 클라이언트 제어 항목을 사용해야 합니다. Claude Code v2.1.217 이상은 동시 실행 상한과 위임 깊이 제어를 지원합니다. 다음은 macOS와 Linux의 Bash/Zsh 실행 예시로, 불필요한 병렬 실행을 조사할 때 보수적인 출발점으로 쓸 수 있습니다. 환경 변수 레퍼런스
CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS=1 \
CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=1 \
claude
첫 번째 변수는 한 세션에서 Agent 도구로 새 서브에이전트를 만들 때 동시 실행 검사를 설정합니다. 두 번째 변수는 서브에이전트를 한 단계로 제한해 추가적인 중첩 위임을 막습니다. 프롬프트가 아니며, 이미 실행 중인 다른 세션을 소급해서 바꾸지도 않습니다. 환경 변수 레퍼런스
다만 이것은 “모든 곳에서 항상 에이전트가 하나 이하”임을 보장하는 전역 잠금이 아닙니다. 공식 문서에는 예외가 명시되어 있습니다. ultracode 세션은 이 동시 실행 제한을 적용하지 않습니다. 수동 /subtask 호출과 완료된 서브에이전트의 재개는 동일한 신규 생성 검사로 차단되지 않으며, 워크플로와 agent teams에는 각각 별도의 제한이 있습니다. 여러 메인 세션과 외부에서 시작한 프로세스도 이 설정 하나로 함께 통제할 수 없습니다. 동시 실행 제한과 예외
직접 만든 스케줄러에 진정한 전역 상한이 필요하다면, 시작·재개·재시도를 공통 큐나 동시 실행 잠금으로 관리해야 합니다. 프롬프트에 “한 번에 하나”라고 쓰는 것만으로는 부족합니다. 이는 자체 스케줄링 구현에 속하며, 별도로 설명되지 않은 Claude Code 설정이 아닙니다.
결과를 기다리는 것과 모델에게 계속 진행 상황을 물어보게 하는 것은 다릅니다
LeeLeepenkman의 불만은 단순히 “서브에이전트를 사용했다”는 것이 아니었습니다. Fable 5.1이 muse에 큰 프롬프트를 준 다음 약 5초마다 폴링해 컨텍스트가 빠르게 늘어났다고 설명했습니다. 원문에는 muse의 구체적인 구현, 요청 기록, 문제 해결 후 결과가 없습니다. 따라서 5초를 Claude Code의 고정 폴링 간격이라고 표현해서는 안 됩니다.
현재 기본 백그라운드 서브에이전트에는 완료 알림이 있으며, 결과는 후속 턴에서 메인 세션으로 전달됩니다. 실행 상태는 /tasks로 확인할 수 있습니다. 이는 모델이 “끝났나요?”라는 새 요청을 계속 보내게 하는 것과 다릅니다. 백그라운드 서브에이전트와 결과 알림
조사할 때는 세션의 도구 기록을 펼쳐 같은 작업을 추적하세요. 반복 조회가 새로운 정보를 주었나요? 이미 끝난 작업을 다시 시작하지 않았나요? 상태 조회가 실제로 새로운 모델 호출을 발생시켰나요? Ctrl+O를 누르면 더 자세한 대화 보기를 열 수 있지만, 화면 새로고침 횟수를 모델 요청 횟수로 그대로 간주할 수는 없습니다. 요청 단위 사용량이 필요하다면 실제로 접속한 제공자의 기록도 대조해야 합니다. 상호작용과 세션 보기
기본 알림을 사용한다면, 대체로 모델이 실행하는 고빈도 확인 루프를 덧붙일 필요가 없습니다. 외부 도구가 폴링만 지원한다면 프로그램이 합리적인 간격으로 상태 변화를 확인하고, 시간 제한을 두며, 새 결과나 이상이 생겼을 때만 모델에 정보를 넘길 수 있습니다. 여기서 줄이자는 것은 새 정보가 없는 모델 호출이지, 필요한 진행 상황 모니터링 자체가 아닙니다.
이용 한도가 회복되면 먼저 남은 작업을 확인하기
intwerpret는 더 극적인 경험을 보고했습니다. 사용 한도에 도달한 뒤 대기 후 자동 계속을 선택했고, 이후 39개 에이전트가 나타나 한도를 다시 소진했으며, 결국 Codex로 돌아갔다고 주장했습니다. 자료에는 클라이언트 버전, 작업 내용, 전체 설정, 재개 기능이 어느 구성 요소에서 제공되었는지가 없습니다. 이후 작업을 끝냈는지도 알 수 없습니다.
이 경험은 재개 절차를 점검할 이유가 되지만, “Claude Code 자동 재개는 반드시 에이전트 39개를 시작한다”는 증거는 아닙니다. 작성자가 쓴 “Ultra”라는 표현만으로 앞에서 설명한 ultracode 모드가 실행 중이었다고 볼 수도 없습니다.
반대로 이제 모든 자동 계속 기능을 서드파티 스크립트의 동작으로 돌릴 수도 없습니다. 공식 상호작용 문서에는 사용 한도 회복 후 이어서 실행하는 기본 기능이 기록되어 있습니다. v2.1.234부터 조건에 맞는 대화형 구독 세션은 한도 회복을 기다린 뒤 작업을 계속할 수 있습니다. 이는 API 키, -p, 모든 백그라운드 모드의 동작과 같다는 뜻이 아닙니다. 재개 역시 사용자가 마지막으로 준 원래 작업을 단순히 재전송하는 것이 아닙니다. 기본 대기 및 자동 계속 기능
작업이 무인 상태에서 재개되기를 원하지 않는다면 /config에서 **Continue automatically at usage limit(사용 한도 회복 후 자동 계속)**을 끄세요. 해당 설정을 지원하는 버전에서는 다음 명령도 사용할 수 있습니다.
/config autoContinueAtUsageLimit=false
이미 대기 중이라면 그 대기 자체도 취소해야 합니다. 입력란이 빈 상태에서 Esc를 누르거나, /rate-limit-options에서 **Don’t continue automatically(자동으로 계속하지 않음)**를 선택하세요. 기본 설정을 바꾸는 것과 이미 선택한 한 번의 대기를 취소하는 것은 별개의 작업입니다. 자동 계속 취소 및 설정
그다음 /tasks와 실제 파일 상태를 확인합니다. 아직 실행 중인 작업, 완료된 작업, 검증 한 번만 더 하면 되는 작업은 무엇인가요? 기존 결과는 재사용하고, 미완료 작업에는 이어서 할 목표를 명시하세요. 전체 요구사항을 다시 보내 작업 분해부터 반복하게 하지 마세요.
특히 커밋, 배포, 메시지 전송처럼 외부에 영향을 주는 동작이라면, 이전 시도가 이미 성공했는지 먼저 확인해야 합니다. 한도 회복은 “요청을 계속할 수 있는가”만 해결할 뿐, “다음 실행이 중복되지 않는가”까지 보장하지는 않습니다.
사용량이 개선됐는지 판단하기 전에 완성된 결과를 보기
chasemdev는 Fable이 계속 직접 코드를 쓰게 한 것이 아니라 Opus 서브에이전트를 조율하게 했다고 설명했습니다. 그런데도 곧 주간 한도에 도달할 것으로 예상했습니다. 여기서 “곧”은 작성자의 당시 예상이지, 검증된 최종 사용량 결과가 아닙니다. 다만 기록에서 놓치기 쉬운 점을 짚어 줍니다. 메인 모델만 보지 말고 서브에이전트가 사용한 모델과 수행한 작업까지 포함해야 합니다.
현재 /usage의 Session 영역은 세션 토큰 사용량과 로컬에서 계산한 비용 추정치를 보여 줍니다. 구독 사용자는 같은 화면에서 플랜 사용량도 볼 수 있습니다. Session에 나오는 달러 금액은 구독 청구서가 아니며, API 제공자의 최종 청구액과 같다고도 할 수 없습니다. 종량제 사용자는 실제 제공자의 청구서를 기준으로 삼아야 합니다. 현재 /usage의 의미
구독 사용량의 로컬 귀속 정보도 하나의 단서일 뿐입니다. 서브에이전트, 플러그인, 스킬 등의 분류는 이 기기의 최근 이력을 바탕으로 합니다. 다른 기기와 웹의 전체 사용량을 포함하지 않으며, 어떤 플러그인이 “얼마나 낭비를 유발했는지”를 입증하는 인과관계의 증거도 아닙니다. Showing last-known usage가 보이면 표시된 데이터의 시각을 기록하고, 새로고침한 뒤 비교하세요. 귀속 범위와 캐시된 수치
복잡한 평가 시스템을 만들 필요는 없습니다. 범위가 명확하고 안전하게 재현할 수 있는 작업을 고른 뒤 인수 기준을 먼저 적고, 시작과 종료 시점에 다음 내용을 기록하세요.
| 기록할 내용 | 확인할 질문 |
|---|---|
| 작업, 시작 시점의 코드 버전, 모델, effort, 클라이언트 버전 | 전후에 같은 종류의 작업과 설정을 비교하고 있나요? |
/context와 압축 과정 | 압축 후 제약이 빠지거나 다시 읽기, 재설명이 필요하지 않았나요? |
| 서브에이전트와 대기 동작 | 어떤 작업이 새로 생성되거나 재개됐고, 최대 몇 개가 동시에 실행됐으며, 새 정보 없는 반복 조회가 있었나요? |
| 사용량 수치, 시각, 한도 초기화 경계 | 중간에 한도가 초기화됐거나 다른 세션이 섞였나요? API 기록에 관련 모델을 모두 포함했나요? |
| 실제 산출물과 검사 결과 | 요구사항을 완료했나요? 관련 검사를 통과했나요? 사람이 다시 해야 할 작업이 얼마나 남았나요? |
한 번에 한 가지 방식만 바꾸세요. 예를 들어 조사를 마친 뒤 compact를 실행하거나, 새 서브에이전트의 동시 실행 수를 제한하는 식입니다. 원래 인수 기준을 유지하고, 사용량을 낮게 보이게 하려고 작업 범위를 몰래 줄이지 마세요. 비교할 때 캐시 상태가 달랐는지도 적어 둡니다. 두 실행에서 모델, 코드 버전, 작업 규모가 달랐다면 차이 전부를 compact의 효과로 돌려서는 안 됩니다.
토큰을 조금 덜 썼더라도 요구사항이 빠지거나 검증을 사람에게 넘겼다면 개선이라고 할 수 없습니다. 반대로 컨텍스트를 더 오래 유지했지만 반복 조사 없이 한 번에 작업을 끝냈다면, 윈도 점유율이 높다는 이유만으로 낭비라고 판단할 수도 없습니다.
독립적인 API 사용과 구독 사용은 더욱 분리해서 기록해야 합니다. 청구 경로를 바꿔도 원래 구독 한도가 초기화되거나 클라이언트의 위임, 대기, 압축 동작이 자동으로 바뀌지는 않습니다. 가치가 있는 변화인지 판단하려면 특정 모델의 단가가 아니라 같은 작업을 완료하는 데 필요한 총사용량과 재작업을 비교해야 합니다. 과금 방식의 차이 · API 토큰 과금 구조
압축 시점 판단을 플러그인에 맡기기 전에 외부로 보내는 내용을 확인하기
Kun Chen의 출발점은 실용적인 질문이었습니다. “when should i /compact my session”, 즉 현재 세션을 언제 압축해야 하느냐는 것입니다. 그가 만든 compact-adviser는 TypeSafe의 Jev를 사용해 압축하기 적절한 작업 경계에 도달했는지 판단합니다. 제안만 하는 모드와 사용자가 명시적으로 선택해야 하는 자동 모드를 제공합니다. 프로젝트 설명
이 글의 확인 대상은 커밋 d1655faa16a22b68bff60c3d7deb0123e1e52a53으로 고정했으며, 해당 Claude Code 플러그인 매니페스트의 버전은 0.1.4입니다. 프로젝트는 Node.js 22 이상, Claude Code 2.1.274 이상을 요구하며, 2.1.275에서 검증했다고 밝힙니다. Claude Code 연동은 실험적인 함수 hooks에 의존하고 CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1이 필요합니다. 이는 프로젝트가 제시한 호환 조건이지, 이 글을 위해 직접 설치해 테스트한 결과가 아닙니다. 고정 버전 매니페스트 · 버전 및 연동 요구사항
더 중요한 점은 hint 모드가 자동으로 압축하지 않는다는 뜻일 뿐, 로컬에서 판단하거나 컨텍스트를 외부에 보내지 않는다는 뜻은 아니라는 것입니다. 프로젝트의 보안 문서에 따르면, 설치 후 시작 환경, 저장된 설정, 작업 디렉터리의 .env에서 키를 얻을 수 있고 호출 조건이 충족되면 선택된 세션 내용이 TypeSafe로 전송됩니다. 사용자 제약, 최근에 표시된 응답과 도구 결과, 기존 요약, 생성된 산출물 이름 등이 포함됩니다. 공유 동의를 별도로 확인하는 독립적인 스위치는 없습니다. 발췌 내용에도 코드나 업무 정보가 들어갈 수 있으며, 민감 정보 제거에 최선을 다한다는 설명이 민감한 내용이 전혀 없다는 보장은 아닙니다. 컨텍스트 외부 전송 범위
이미 설치했다면 /compact-adviser off로 끄거나, 시작할 때 다음을 사용할 수 있습니다.
COMPACT_ADVISER_DISABLE=1 claude
프로젝트 설명에 따르면 이 설정은 플러그인의 요청, 제안, 자동 압축을 중지합니다. 꺼지는 것은 플러그인이지 Claude Code 자체의 자동 압축이 아닙니다. 업무 내용을 추가로 TypeSafe에 보낼 수 없는 환경이라면 auto에서 hint로만 바꾸지 말고, 플러그인을 비활성화하거나 제거해야 합니다. 비활성화 방법
작성자가 언급한 40개 세션 평가는 프로젝트 자체 평가이며 데이터셋은 공개되지 않았습니다. 이를 근거로 자신의 작업에서도 세부 사항이 사라지지 않는다고 보장할 수는 없습니다. 플러그인이 “압축하기 적절하다”고 판단하더라도, 결국 확인할 것은 압축 후 작업을 올바르게 이어 갈 수 있는지입니다. 평가의 한계
플러그인 없이도 이 모든 것을 먼저 실천할 수 있습니다. 작업 단계가 끝날 때 상태를 저장하고 다음 단계에 정말 필요한 정보를 남기세요. 서브에이전트에는 명확하고 독립적인 일을 맡기고, 대기와 재개 과정에서 중복 시작을 피하며, 산출물과 사용량 기록을 함께 보고 효과를 판단하세요.
긴 작업을 관리하는 목적은 윈도를 가득 채우거나 각각의 요청이 가장 저렴해 보이도록 만드는 것이 아닙니다. 작업을 앞으로 나아가게 하지 않는 일을 줄이고, 이미 시작한 일을 신뢰할 수 있게 마무리하는 것입니다.