Claude Code가 원하는 결과를 만들고 있다면, 대화가 길다는 이유만으로 세션을 비울 필요는 없습니다. 컨텍스트를 정리하는 데도 설명과 재탐색이 들기 때문입니다. 먼저 줄일 대상은 필요한 기억이 아니라 같은 자료를 다시 읽고, 끝난 이야기를 되풀이하고, 불분명한 요청을 고치는 데 쓰는 토큰입니다.
좋은 세션 관리는 작업에 필요한 목표·근거·검증 기준을 유지하면서 불필요한 입력을 덜 쌓는 방식입니다. 같은 작업을 이어갈 때와 다른 작업으로 넘어갈 때를 구분하면, 매번 처음부터 설명하거나 한 대화에 모든 일을 몰아넣는 일을 줄일 수 있습니다.
1. 컨텍스트 크기와 사용 토큰을 구분하기
컨텍스트는 Claude가 이번 판단에 참고하는 작업 공간입니다. 사용자의 메시지뿐 아니라 읽은 파일, 도구 출력, 프로젝트 지침, 이전 응답도 들어갑니다. 짧게 질문했더라도 큰 로그를 여러 번 가져오면 작업 공간은 커질 수 있습니다. Claude Code의 컨텍스트 설명
반면 사용 토큰은 여러 요청을 수행하면서 누적됩니다. 현재 컨텍스트가 작다는 사실만으로 작업 전체의 사용량이 적었다고 볼 수는 없습니다. 짧은 세션을 여러 번 열어 같은 코드를 다시 탐색했다면 그 과정도 계산에 들어갑니다. 입력 캐시와 모델별 과금도 있어 컨텍스트 크기, 누적 토큰, 청구액은 같은 숫자가 아닙니다.
현재 대화의 구성을 보고 싶을 때는 Claude Code 세션 안에서 다음 명령을 사용합니다. Windows·macOS·Linux 공통이며 운영체제 터미널에 직접 입력하는 명령은 아닙니다.
/context
사용량은 설치한 버전의 사용량 화면에서 따로 확인합니다. 현재 공식 안내의 명령은 다음과 같습니다.
/usage
구독에 포함된 사용량과 API 비용 추정치를 구분해야 합니다. 세션의 금액 표시가 실제 청구서와 같은 뜻은 아니며, 외부 게이트웨이를 사용한다면 실제 모델 제공자의 사용량도 대조합니다. 토큰을 덜 썼다고 정액 구독료가 곧바로 내려가는 것도 아닙니다. 사용량과 비용 확인
- 탐색관련 위치를 찾지 못해 같은 파일과 로그를 반복해서 읽는지 봅니다.
- 요청목표와 완료 조건이 모호해 수정 지시를 되풀이하는지 봅니다.
- 전환새 작업에 필요 없는 이전 대화가 계속 섞이는지 봅니다.
- 검수토큰이 줄어도 결과 품질과 사람의 검수 시간이 나빠지지 않았는지 확인합니다.
2. 세션은 대화 길이보다 작업 단위로 나누기
한 세션에는 서로 연결된 목표를 두는 편이 관리하기 쉽습니다. 결제 콜백의 중복 처리 버그를 조사하고 수정한 뒤 회귀 테스트를 확인하는 일은 같은 작업입니다. 그 과정에서 찾아낸 예외 조건을 다음 수정에서도 써야 하므로, 매 단계마다 새 세션을 열면 오히려 재설명이 늘 수 있습니다.
반대로 그 버그를 마친 뒤 소개 페이지 문구를 고친다면 이전 결제 로그를 계속 들고 갈 이유는 작습니다. 필요한 프로젝트 규칙은 유지하되 대화는 새 작업으로 구분할 수 있습니다. Anthropic도 관계없는 작업 사이에서 컨텍스트를 정리하고, 구체적인 목표와 검증 방법을 전달하는 방식을 권합니다. Claude Code 모범 사례
| 구분 | 역할 | 설명 | 예시 |
|---|---|---|---|
| 같은 목표·진전 있음 | 현재 세션 유지 | 필요한 판단과 코드 맥락을 재사용합니다. 대화 길이만으로 정리를 강제하지 않습니다. | 원인 조사 → 최소 수정 → 회귀 테스트 |
| 같은 목표·기록 많음 | compact로 요약 | 이어갈 상태를 지정하고 누적 탐색을 요약합니다. 중요한 조건이 남았는지 확인합니다. | 여러 가설을 조사했지만 해결할 버그는 하나 |
| 다른 목표로 전환 | 새 세션 또는 clear | 끝난 작업의 대화를 새 작업에 끌고 가지 않습니다. 필요한 결과만 별도로 남깁니다. | 결제 버그 완료 → 소개 페이지 문구 수정 |
/clear는 대화 기록을 비우는 명령이며, 파일 변경을 되돌리는 명령이 아닙니다. 세션을 바꿔도 디스크에는 수정한 코드가 남습니다. 이어받는 작업이라면 현재 변경 상태를 먼저 확인해야 합니다. 아래는 세 운영체제 터미널에서 공통으로 사용할 수 있는 Git 명령입니다.
git status --short
git diff
새 세션으로 넘어갈 때 필요한 것은 이전 대화의 전부가 아니라 현재 작업 상태입니다. 이 상태를 어떻게 남기느냐가 다음 탐색의 양을 바꿉니다.
3. 긴 대화 대신 다음 판단에 필요한 상태 남기기
가상의 결제 콜백 버그를 생각해 보겠습니다. 같은 이벤트가 두 번 들어왔을 때 주문 상태가 중복 변경됩니다. 처음에는 화면 새로고침을 의심했지만, 동일 이벤트 ID를 서버에 두 번 전달하는 테스트에서도 재현됐다고 가정합니다.
이제 중요한 정보는 처음 읽은 로그 전체보다 서버 입력만으로도 재현된다는 근거와 실패 후 재시도를 보존해야 한다는 조건입니다. 다음처럼 현재 상태를 짧게 남기면 같은 가설을 처음부터 조사하는 일을 줄일 수 있습니다. 파일 경로와 결과는 실제로 확인한 내용으로 바꿉니다.
목표: 같은 이벤트 ID의 콜백이 반복되어도 주문 상태를 한 번만 변경합니다.
범위: 콜백 처리 함수와 그 회귀 테스트. 공개 응답 형식은 유지합니다.
현재 증거: 동일 이벤트를 두 번 넣는 테스트에서 상태 변경이 두 번 발생했습니다.
제외한 가설: 화면 새로고침만의 문제는 아닙니다. 서버 입력으로도 재현됩니다.
보존 조건: 실패 이벤트를 성공 처리하지 않고 재시도 가능성을 남깁니다.
다음 행동: 관련 함수와 위 테스트를 읽고 원인을 확인합니다.
완료 기준: 중복·정상·실패 후 재시도 사례를 확인하고 diff를 설명합니다.
상태 메모는 매 응답마다 만들 필요는 없습니다. 접근 방향이 확정됐을 때, 작업을 중단할 때, 다른 세션으로 넘길 때처럼 다시 탐색할 가능성이 있는 경계에서 남깁니다. 장기 보존이 필요하면 프로젝트의 작업 메모에 관련 파일·테스트 이름과 함께 기록합니다.
같은 작업의 대화가 커졌다면 다음처럼 요약에 남길 항목을 지정할 수 있습니다. Claude Code 세션 안에서 입력합니다.
/compact 현재 목표, 수정 파일, 마지막 검증 결과, 제외한 가설, 변경 금지 조건과 다음 행동을 보존해 주세요.
Claude Code에는 자동 요약도 있으므로 대화를 관리하려고 매번 수동 요약을 할 필요는 없습니다. 요약은 원문 전체를 그대로 유지하는 방식이 아니어서, 이어갈 때 중요한 조건을 확인하는 것이 좋습니다. 컨텍스트와 요약 동작
이 사례에서 '중복을 막는다'만 남기고 '실패한 이벤트는 재시도할 수 있어야 한다'를 지우면, 토큰은 줄어도 구현이 잘못될 수 있습니다. 줄여야 할 것은 근거 없는 가설의 반복이고, 남겨야 할 것은 다음 결정에 영향을 주는 반례입니다.
4. 파일·로그는 범위를 좁혀 읽고 필요하면 넓히기
“프로젝트 전체를 읽고 문제를 찾아 주세요”보다 현재 증상, 진입점, 확인할 조건을 먼저 주면 탐색 범위를 정하기 쉽습니다. 파일을 무조건 적게 읽게 하는 것이 목표는 아닙니다. 처음부터 관련 없는 출력까지 모두 대화에 넣지 않고, 근거가 부족할 때 범위를 넓히는 방식입니다.
결제 사례에서는 다음처럼 요청할 수 있습니다.
결제 콜백에서 같은 이벤트 ID가 두 번 처리되는 경로를 조사해 주세요.
먼저 콜백 진입점과 이벤트 처리 기록을 쓰는 함수, 관련 테스트를 찾습니다.
긴 로그 전체 대신 재현 요청·오류 앞뒤 문맥·관련 파일 위치를 우선 확인합니다.
근거가 부족하면 필요한 범위를 넓히고 이유를 설명해 주세요.
조사가 끝나면 원인 후보·근거 위치·다음 검증만 간결하게 정리해 주세요.
이 요청은 조사에 쓸 단서와 결과 형식을 함께 정합니다. 도구 결과에서 파일 경로가 사라지거나 오류의 앞뒤 문맥이 잘리면 원인을 놓칠 수 있으므로, 무조건 몇 줄 이내로 자르라는 제한보다 필요한 근거를 우선하는 편이 낫습니다. 구체적인 범위와 검증 가능한 기준을 주는 원칙은 공식 모범 사례와 연결됩니다.
이미 읽은 로그를 다시 가져오기 전에 현재 판단에 새 정보가 필요한지도 확인합니다. 같은 테스트를 다시 실행하는 것과 같은 오래된 출력을 다시 읽는 것은 다릅니다. 코드를 바꿨다면 새 테스트 결과가 필요하지만, 코드와 조건이 그대로인데 긴 출력을 반복해서 붙이는 것은 추가 근거가 되지 않을 수 있습니다.
5. 반복 규칙은 짧게, 큰 조사는 독립적으로
매번 지킬 프로젝트 명령과 제약은 CLAUDE.md에, 이번 오류의 진행 상황은 작업 메모에 둡니다. 일회성 디버깅 로그까지 상시 지침에 쌓으면 다른 작업에서도 불필요한 정보가 따라옵니다. /memory에서 지침 파일을 확인하고 오래되거나 충돌하는 내용을 정리할 수 있습니다. 대화를 비워도 파일에 저장된 규칙은 남습니다. 프로젝트 메모리 안내
예를 들어 '항상 모든 테스트를 세 번 실행'보다 '변경한 동작의 회귀 테스트와 프로젝트 필수 검사를 실행하고 결과를 기록한다'가 검증 목적을 분명히 합니다. 필요한 검사를 생략하는 것이 아니라, 이유 없이 반복하는 명령을 줄이는 방향입니다. 규칙의 구조는 AGENTS.md·CLAUDE.md 작성법에서 이어집니다.
특정 작업에서만 필요한 상세 절차는 Skill 같은 별도 지침으로 나눌 수 있습니다. 다만 어떤 내용이 상시 로드되고 어떤 내용이 필요할 때 들어오는지는 기능별로 다릅니다. 파일을 나눴다는 사실만으로 입력 비용이 사라지는 것은 아닙니다. 확장 기능과 컨텍스트 사용
독립적인 대규모 조사는 서브에이전트에 맡겨 주 대화에는 근거가 있는 요약을 받을 수도 있습니다. 예를 들어 “파일은 수정하지 말고, 중복 이벤트 처리 경로·근거 위치·확인하지 못한 부분을 반환해 주세요”라고 범위를 정합니다. 작은 함수 하나를 읽는 일까지 나누면 준비와 통합이 더 들 수 있습니다.
주 세션의 컨텍스트를 줄이는 것과 전체 토큰을 줄이는 것은 다릅니다. 서브에이전트도 별도 컨텍스트에서 요청을 수행하고, 결과를 합치는 데도 비용이 듭니다. 긴 출력을 주 대화에 남기지 않는 효과와 작업 전체의 사용량을 따로 판단해야 합니다. 서브에이전트의 독립 컨텍스트
6. 절약 기준은 완료한 작업의 결과와 총비용
짧은 답변이나 낮은 컨텍스트 표시만으로 효율을 판단하기는 어렵습니다. 결제 사례에서는 동일 이벤트 두 번, 정상 이벤트 한 번, 일시 실패 후 재시도라는 조건을 끝까지 확인해야 합니다. 검증을 생략해 토큰을 줄였는데 사람이 뒤에서 오류를 고친다면 전체 비용은 늘 수 있습니다.
비슷한 크기의 작업을 비교할 때는 다음 네 가지를 함께 남겨 보세요.
- 미리 정한 완료 조건을 통과했는가
- 재탐색·재설명·재시도가 얼마나 필요했는가
- 작업에 사용한 여러 세션과 서브에이전트의 사용량은 얼마인가
- 사람이 결과를 확인하고 고치는 데 얼마나 걸렸는가
같은 작업을 새 세션 세 개로 나눴다면 마지막 세션만 보지 말고 세 개를 함께 봅니다. 입력 캐시나 사용 모델이 달랐다면 토큰 수만으로 비용을 단정하지 않습니다. 실제 지출과 검수 시간을 함께 비교하는 방법은 AI 코딩 도구 비용 계산으로 이어집니다.
잘 진행되는 작업은 이어가고, 다른 작업은 구분하며, 다시 쓸 근거만 짧게 남기면 됩니다. 같은 실패를 반복할 때도 컨텍스트 탓으로 단정하기 전에 요구·코드·환경을 확인하세요. 세션 관리는 대화를 항상 짧게 만드는 일이 아니라 좋은 결과에 필요한 정보를 유지하면서 불필요한 반복을 줄이는 습관입니다.
VIEW—
