Claude Code 토큰·비용 아끼는 법: 컨텍스트 관리와 세션 끊기 타이밍 가이드

Claude Code를 쓰다 보면 처음에는 빠르게 진행되던 작업이 어느 순간 느려지고, 같은 설명을 반복하거나 엉뚱한 파일을 건드리기 시작합니다. 대화가 길어질수록 지금 필요한 정보와 이미 끝난 작업이 한 컨텍스트에 섞이기 때문입니다. 토큰 비용을 아끼는 일은 단순히 말을 줄이는 것이 아니라, 에이전트가 읽고 판단해야 할 범위를 관리하는 일에 가깝습니다.

긴 세션이 비싸고 복잡해지는 이유

컨텍스트는 작업 메모리다

에이전트는 대화 내용, 사용자가 붙인 코드, 실행 결과, 읽은 파일을 바탕으로 다음 행동을 정합니다. 작업이 길어지면 과거의 가설, 실패한 시도, 더 이상 필요 없는 로그까지 판단 재료로 남습니다. 그러면 매 요청마다 처리해야 할 정보가 늘고, 핵심 요구사항이 묻힐 수 있습니다.

긴 대화가 항상 좋은 것은 아니다

한 세션에서 기획, 구현, 디버깅, 리팩터링을 모두 처리하면 흐름은 편해 보입니다. 하지만 목표가 바뀔 때마다 이전 결정이 새로운 작업을 방해할 수 있습니다. 특히 에러 로그를 여러 번 붙이거나 전체 파일을 반복해서 읽게 하면 비용과 혼란이 함께 커집니다.

처음부터 읽을 범위를 좁히는 법

작업 목표를 한 문장으로 고정하기

세션을 시작할 때 “무엇을 바꿀지”와 “무엇을 건드리지 않을지”를 함께 적어보세요.

목표: 결제 완료 콜백의 중복 처리를 수정한다.
범위: app/api/payment와 관련 테스트만 확인한다.
제외: UI 개편, 스키마 변경, 의존성 업데이트.
완료 조건: 재현 테스트가 통과하고 변경 파일을 요약한다.

이렇게 쓰면 에이전트가 프로젝트 전체를 탐색하려는 경향을 줄일 수 있습니다. 큰 작업을 시작하기 전에는 계획 먼저 시키는 Claude Code 워크플로우처럼 먼저 조사 범위와 실행 순서를 합의하는 편이 좋습니다.

필요한 파일만 단계적으로 열기

처음부터 저장소 전체를 읽게 하기보다 진입점, 관련 모듈, 테스트 순서로 요청하세요. 파일을 읽은 뒤에는 “현재 가설과 다음에 볼 파일을 먼저 말해줘”라고 물으면 불필요한 탐색을 줄이는 데 도움이 됩니다. 프로젝트 공통 규칙은 CLAUDE.md 작성법처럼 별도 문서로 정리해 매번 긴 설명을 반복하지 않게 하세요.

세션을 끊어야 하는 신호

다음 중 두 가지 이상이 보이면 새 세션을 고려할 만합니다.

같은 파일이나 로그를 다시 읽고 있다.
이미 폐기한 가설을 다시 제안한다.
요청하지 않은 파일을 계속 수정한다.
구현보다 과거 대화 설명에 더 많은 시간을 쓴다.
목표가 “버그 수정”에서 “구조 개선”처럼 바뀌었다.
변경 사항을 요약해도 현재 상태를 명확히 설명하지 못한다.

새 세션을 열기 전에는 현재 상태를 짧게 인계하세요. “완료한 것, 실패한 것, 확인된 원인, 남은 작업, 읽어야 할 파일”을 다섯 줄 안팎으로 정리하면 됩니다. 긴 원문 로그 대신 재현 명령과 핵심 에러만 남기는 것이 효과적입니다.

토큰을 아끼는 요청 습관

결과 형식을 먼저 정하기

“살펴봐줘”보다 “원인 후보 세 개와 각각 확인할 파일을 표로 정리해줘”가 낫습니다. 원하는 출력 형식을 정하면 불필요한 장황한 설명을 줄일 수 있습니다. 코드 수정도 한 번에 여러 요구를 섞기보다 조사, 패치, 테스트를 나누어 요청하세요.

이미 아는 정보는 다시 붙이지 않기

에이전트가 직접 확인할 수 있는 파일이라면 코드를 통째로 복사하기보다 경로와 확인할 함수명을 알려주세요. 로그도 전체를 붙이기보다 발생 시각, 요청 흐름, 핵심 스택 트레이스만 남기고 원본은 파일로 제한하는 방식이 좋습니다.

작업 단위를 작게 닫기

한 번의 요청이 끝나면 변경 파일, 테스트 결과, 남은 위험을 요약하게 하세요. Claude Code 디버깅 잘 시키는 법에서 다룬 것처럼 재현과 검증을 분리하면 실패한 시도가 다음 판단을 계속 오염시키는 일을 줄일 수 있습니다.

새 세션을 시작하는 인계 템플릿

작업 목표: 
현재 상태: 
완료한 변경: 
확인한 사실: 
실패한 시도: 
다음 작업: 
수정 금지 범위:

이 템플릿은 새 세션의 첫 메시지로 그대로 사용할 수 있습니다. 핵심은 과거 대화를 복원하는 것이 아니라, 현재 의사결정에 필요한 사실만 전달하는 데 있습니다.

조코헌트 집계를 보면 출시 첫 24시간 안에 업보트나 댓글을 하나라도 받은 프로덕트는 47%이고, 댓글을 받은 프로덕트는 28%입니다. 모든 작업을 완벽하게 한 세션에서 끝내려 하기보다, 작은 변경을 닫고 실제 반응을 확인하는 흐름이 1인 빌더에게 더 현실적일 수 있습니다.

토큰 절약의 기준은 짧게 말하는 것이 아닙니다. 에이전트가 지금 필요한 파일과 목표만 보도록 만들고, 목표가 바뀌면 세션도 함께 나누는 것입니다. 다음 작업을 시작할 때마다 “이 대화가 아직 같은 문제를 다루고 있는가?”를 확인해보세요.