/context, /compact, /clear 사용 시점

대화가 꽤 오래 이어졌습니다. 해결책 하나를 이미 거절하고 이유까지 설명했는데, 메시지가 열 개쯤 오간 뒤 에이전트가 똑같은 해결책을 다시 제안합니다. 모든 내용을 지우고 처음부터 다시 시작하고 싶은 마음이 드는 것도 당연합니다.

거절한 해결책이 반복되는 것은 눈에 띄는 신호지만, 아직 원인이라고 단정할 수는 없습니다. 답변 하나만으로 대화가 쌓인 탓이라고 할 수 없습니다. 요구사항이 서로 모순되거나 에이전트가 30분 전에 읽은 파일 버전을 참고하는 경우에도 똑같이 보일 수 있습니다.

대화 자체를 다루는 명령 세 가지를 살펴보겠습니다. /context는 컨텍스트 창이 무엇으로 채워졌는지 보여 주고, /compact는 대화 기록을 간결한 요약으로 줄이며, /clear는 새 대화를 시작합니다. 문법보다 흥미로운 건 셋 중 무엇을 고르느냐입니다. 실행 전에 무엇을 보존하고 실행 후 무엇을 대조할지, 그리고 문제가 애초에 대화 분량과 관계없다는 것을 어떻게 알아챌지 살펴봅니다.

먼저 문제를 찾으세요

무언가를 압축하거나 지우기 전에 상황을 네 가지로 나눠 보세요. 겉으로는 비슷해 보입니다. 네 경우 모두 에이전트가 "듣지 않는" 것 같지만, 필요한 조치는 서로 다릅니다.

• 입력 정보가 부족합니다. 보상을 지급하는 규칙을 아무도 알려 주지 않았고, 읽어 본 파일에도 없습니다. 대화를 줄인다고 없던 정보가 생기지는 않습니다. 빠진 내용을 직접 제공해야 합니다.
• 정보가 오래됐습니다. 대화에는 30분 전에 읽은 파일 내용이 남아 있지만, 디스크의 파일은 이미 달라졌습니다. 이럴 때 필요한 것은 압축이 아니라 다시 읽기입니다.
• 요구사항이 서로 모순됩니다. 채팅에서는 한 가지로 이야기했는데 저장된 작업 명세에는 다른 내용이 적혀 있습니다. 어떤 요구사항이 유효한지 직접 결정하고 원본을 수정하세요. 파일에 적혀 있다는 이유만으로 자동으로 맞는 것은 아닙니다.
• 불필요한 내용이 쌓였습니다. 거절된 해결책이 많고, 명령 출력이 길며, 작업과 관계없는 파일 이야기가 이어집니다. 이런 경우라면 컨텍스트를 정리하는 것이 실제로 도움이 됩니다.

컨텍스트 창 사용량은 이 목록의 다섯 번째 항목도, 모든 오류를 설명해 주는 이유도 아닙니다. 비율이 높다고 에이전트가 그 탓에 실수했다는 뜻은 아니며, 낮다고 대화에 문제가 없다는 뜻도 아닙니다. 확인 순서는 간단합니다. 요구사항, 파일의 최신 상태, 출력의 최신 상태를 살핀 뒤에야 대화 자체를 확인하세요.

컨텍스트 창의 사용량을 확인하세요

문제가 대화 자체에 있다고 의심된다면 /context를 확인하세요. 이 명령은 시스템 부분, 프로젝트 지침, 읽은 파일과 명령 출력, 대화, 남은 공간처럼 카테고리별로 컨텍스트 창의 사용량을 보여 줍니다. 어떤 정보가 더는 작업에 필요하지 않은지는 여러분이 판단해야 합니다. 명령은 읽은 내용의 의미를 평가하지 않으며, 메시지 합계를 보여 주는 줄만으로는 어떤 파일이 불필요한지 알 수 없습니다.

"몇 퍼센트를 넘으면 압축해야 한다" 같은 보편적인 기준은 없습니다. 컨텍스트 창의 크기도 모델과 설정에 따라 다릅니다. 비율이 아니라 무엇이 차지하고 있는지 살펴보세요. 편집기 탭을 닫는다고 이미 읽은 내용이 대화에서 사라지지는 않는다는 점도 기억하세요.

압축 후에도 작업을 이어가세요

/compact 명령은 대화 기록을 간결한 요약으로 줄이며, 여러분은 같은 작업을 계속합니다. 컨텍스트 창이 차면 Claude Code가 자동으로 압축하기도 합니다. 직접 명령을 실행하는 경우는 대규모 새 작업에 들어가기 전처럼 적절한 시점을 고르고, 요약의 초점을 지정하고 싶을 때입니다.

가장 큰 제약은 대화가 아니라 요약이 보존된다는 점입니다. 요약에 포함되지 않은 세부 내용이 컨텍스트 창에 남아 있다고 기대할 수는 없습니다. "이런 조건을 보존해 주세요"라고 말해도 요약의 완전성이 보장되지는 않습니다. 그것은 요청일 뿐, 보장 장치는 아닙니다.

보존할 내용

명령을 실행하기 전에 작업 목표와 범위, 결정 사항, 확인된 사실, 다음 단계를 짧게 메모해 두세요. 몇 분이면 됩니다. 대신 메모는 대화에 대한 기억과 달리 파일이나 검사 출력과 대조할 수 있습니다. 별도 파일까지 만들 필요는 없고, 기존 작업 문서에 적으면 됩니다.

다음은 보상을 중복 지급하지 않도록 하는 학습 과제의 상태입니다. 실제 검사를 했다는 보고가 아니라 예시입니다.

목표: 완료된 한 게임에서 보상은 한 번만 지급됩니다. 새 게임에서는 다시 지급할 수 있습니다.
범위: src/reward-flow.js와 기존 보상 검사; 화면 스타일은 변경하지 않습니다.
확인됨: 첫 지급 후 같은 게임에서 다시 버튼을 누르면 점수가 또 올라갑니다.
근거: 재현 기록과 초기 상태는 TASK_SPEC.md에 명시되어 있습니다.
거절됨: 중복 클릭 처리를 수정하지 않고 버튼을 숨기는 방안.
다음 단계: 핸들러를 확인하고 수정안을 제안합니다. 수정과 테스트는 아직 수행하지 않았습니다.

마지막 줄을 눈여겨보세요. 재현을 확인한 것과 문제를 수정한 것은 다릅니다. 메모에도 이 차이가 드러나야 압축 후에 "확인했다"가 "고쳤다"로 바뀌지 않습니다. 여기서 작업 문서는 학습용이므로 경로는 여러분의 것으로 바꾸세요.

메모를 대조한 뒤 초점을 지정해 압축할 수 있습니다.

/compact 중복 보상 지급 수정에 집중하세요. 목표, TASK_SPEC.md의 범위, 확인된 재현, 거절된 해결책, 다음 단계를 보존하세요. 수정과 테스트는 아직 수행하지 않았다고 표시하세요.

압축 후 대조할 내용

압축한 뒤 문장 중간에서 곧바로 작업을 이어 가지 마세요. 먼저 정확해야 할 내용을 대화에 다시 제공하고 확인 질문을 하세요.

TASK_SPEC.md와 최신 src/reward-flow.js를 읽으세요. 제약 조건과 다음 단계를 간단히 말해 주세요. 요약이 파일과 다르면 차이를 알려 주세요. 아직 코드는 수정하지 마세요.

답변은 전체적인 인상이 아니라 메모의 각 항목과 대조하세요. 이 예시에서는 세 가지를 확인합니다.

• "다음 단계" 항목에 수정과 테스트를 완료했다고 쓰지 않았는가;
• "범위"에 있는 화면 스타일 변경 금지가 그대로 남아 있는가;
• "목표"의 새 게임 관련 조건이 빠지지 않았는가.

에이전트가 같은 내용을 다른 말로 표현하는 것은 괜찮습니다. 조건이 빠졌다면 수정 전에 원본에서 다시 가져오세요. 여기서 확인하는 것은 대화 상태이지 코드가 아닙니다. 이 대조만으로 다음 수정이 올바른지 증명할 수는 없습니다.

새 작업을 시작하세요

/clear 명령은 이전 대화 기록 없이 새 대화를 시작합니다. 디스크의 파일과 프로젝트 지침은 그대로 남고, 자동 메모리가 켜져 있다면 그것도 사용될 수 있습니다. 그러므로 여기서 "처음부터"란 대화 기록에 관한 말입니다. 이전 대화가 삭제되는 것은 아니며 /resume으로 돌아갈 수 있습니다.

이 명령은 claude --continue와 쉽게 혼동됩니다. 두 동작은 정반대입니다. /clear는 세션 안에서 입력해 쌓인 기록에서 벗어납니다. claude --continue는 실행할 때 터미널에서 입력해 현재 폴더의 마지막 대화와 전체 기록을 이어갑니다. 문제가 대화 기록에 있었다면 --continue는 바로 그 대화로 돌아갑니다.

대화를 비우기 전에 다음에 필요한 내용, 즉 메모와 관련 경로, 검사 출력을 저장하세요. 새 대화에는 암시가 아니라 명확한 요구사항이 필요합니다. 목표와 제약 조건, 경로를 알려 주세요. 파일을 지정할 때는 @파일을 사용할 수 있습니다. 다만 파일을 언급하면 무엇을 읽을지는 안내되지만, 다른 파일에 대한 접근이 제한되지는 않습니다.

조치를 선택하세요

순서는 간단합니다. 잠시 멈추고 확인 질문을 한 뒤, 컨텍스트 창이 무엇으로 채워졌는지 알기 어렵다면 사용량을 살펴보세요. 그런 다음 조치 하나를 선택하고 결과를 대조합니다. 메시지 수를 셀 필요는 없습니다. 대화의 구성과 다음에 하려는 일을 살펴보세요.

작업 방식이 달라지는 점

명령 세 가지 자체가 무언가를 수정해 주지는 않습니다. 달라지는 것은 긴 작업을 진행하는 방식입니다.

• 이상한 답변을 받으면 대화보다 먼저 요구사항과 파일의 최신 상태를 확인합니다.
• 압축하거나 기록을 비우기 전에 파일과 대조한 메모를 만들고, 압축 후에는 답변을 항목별로 대조합니다.
• 새 작업에는 이전 대화의 잔여 내용이 아니라 그 작업에 맞는 요구사항을 제공합니다.

요청 하나만 비교해도 차이가 분명합니다. 기존 표현:

너 헷갈렸어. 다시 시작하자.

바꾼 표현:

지금 작업은 src/reward-flow.js에서 보상 중복 지급을 수정하는 것입니다.
TASK_SPEC.md를 읽고 제약 조건과 다음 단계를 말해 주세요. 아직 코드는 수정하지 마세요.

두 번째 표현은 확인 가능한 답변을 이끌어 냅니다. 파일과 대조해 제약 조건과 다음 단계가 맞는지 확인하면 차이를 바로 찾을 수 있습니다. 첫 번째 발언은 대조할 근거가 없습니다.