아끼다 똥 된다.
1주일 내내 필요할 때 못 쓰는 상황을 피하기 위해 사용량 페이스를 조절하고 있습니다.
리셋주간이 다가옵니다. 정작 그 타이밍에 일은 바쁜데, 이걸 쓰기에는 애매한 상황들이 겹칩니다.
어제가 딱 그랬어요.
리셋 직전 남은 토큰, 이렇게 쓰면 덜 아깝다
Claude Code를 쓰다 보면 묘한 상황이 생깁니다.
“7시에 사용량 초기화인데… 지금 6시 50분이고 아직 40%나 남았네?”
평소에는 토큰이 부족해서 아껴 쓰다가, 정작 리셋 시간이 가까워지면 남은 사용량이 아깝게 느껴집니다.
예전에 Claude Code 사용량을 조금이라도 효율적으로 쓰는 방법을 ‘꼼수 팁’ 형태로 정리한 적이 있는데, 이번에는 그 후속편입니다.
2026.07.21 - [분류 전체보기] - AI 사용량 리셋, 조금 덜 억울하게 쓰는 소소한 꼼수
꼼수 팁 VER.2의 핵심은 ‘리셋 직전에 일을 시켜두면 남은 사용량을 털어낼 수 있을까?’입니다.
상황은 이렇습니다
예를 들어 Claude Code 사용량 화면이 다음과 같다고 가정해 봅니다.
- 사용량 리셋: 오후 7시
- 현재 시간: 오후 6시 50분
- 남은 사용량: 40%
이럴 때 자연스럽게 이런 생각이 듭니다.
“6시 58분쯤 큰 작업을 3~4개 던져놓으면
지금 남은 40%를 쓰는 걸까?
아니면 7시 이후 새로 충전되는 사용량을 쓰는 걸까?”
개발자 입장에서는 꽤 중요한 문제입니다.
리셋되면 남은 40%는 사실상 사라지는 셈이니까요.
결론부터 말하면
명령을 입력한 시각보다 실제 Claude 모델 호출이 발생하는 시점이 중요하다고 보는 것이 안전합니다.
예를 들어 6시 58분에 Claude Code에 이런 요청을 했다고 해봅니다.
프로젝트 전체 테스트를 수행하고,
실패하는 테스트를 분석해서 수정한 뒤,
전체 테스트를 다시 실행해줘.
겉으로 보면 명령 하나지만 Claude Code 내부에서는 대략 이런 작업이 이어질 수 있습니다.
사용자 명령
↓
프로젝트 파일 탐색
↓
Claude 추론
↓
코드 수정
↓
테스트 실행
↓
결과 분석
↓
Claude 재추론
↓
추가 수정
↓
테스트 재실행
즉 Claude Code는 단순히 ‘프롬프트 한 번 = 사용량 한 번’으로 움직이는 도구가 아닙니다.
Agent 방식이라 작업을 수행하면서 여러 차례 모델을 호출할 수 있습니다.
따라서 6시 58분에 작업을 시작했더라도,
- 6시 59분에 발생한 호출 → 기존 사용량
- 7시 01분에 발생한 후속 호출 → 새 사용량
처럼 나뉠 가능성을 생각해야 합니다.
그래서 6시 58분 몰아넣기는 생각보다 효율이 낮다
처음에는 저도 이런 방법을 생각했습니다.
6:58
작업 A
작업 B
작업 C
작업 D
“일단 여러 개 넣어놓으면 남은 토큰을 알아서 먹겠지?”
그런데 Claude Code 특성상 꼭 그렇게 되지는 않습니다.
작업 A를 수행하는 동안 이미 7시가 넘어가 버리면 작업 B, C, D는 사실상 새로운 사용량 구간에서 수행될 가능성이 높기 때문입니다.
즉,
리셋 직전에 작업을 ‘예약’해놓는 것과
리셋 전에 실제 모델을 ‘일하게 하는 것’은 다릅니다.
제가 생각하는 가장 현실적인 방법
리셋 직전에 사용량이 많이 남아 있다면 20~30분 정도 여유를 두고 무거운 작업을 하나 던지는 방법이 가장 좋습니다.
예를 들어 7시 리셋이라면:
6시 30~40분
다음과 같은 작업을 시킵니다.
현재 프로젝트 전체를 분석해서
중복 코드, 잠재 오류, 사용하지 않는 코드,
구조 개선 포인트를 찾아줘.
수정 가능한 부분은 직접 수정하고
테스트까지 실행해줘.
또는
현재 구현된 기능을 기준으로
전체 테스트를 수행하고,
실패하거나 취약한 부분을 분석해서 보완해줘.
이런 작업은 Claude Code가 상당히 오래 움직입니다.
파일을 읽고, 코드를 분석하고, 수정하고, 테스트까지 수행하기 때문에 남아 있는 사용량을 자연스럽게 소진시키기 좋습니다.
리셋 직전 시키기 좋은 작업들
개인적으로는 단순 코딩보다 프로젝트 전체를 훑는 작업이 적합하다고 봅니다.
1. 전체 코드 리뷰
현재 프로젝트 전체 코드를 검토해서
- 중복 코드
- 잠재 버그
- 예외 처리 누락
- 성능 문제
- 유지보수성이 떨어지는 부분
을 찾아줘.
중요도 순서대로 정리하고
안전하게 수정 가능한 부분은 직접 수정해줘.
2. 테스트 보강
현재 프로젝트의 테스트 코드를 분석해줘.
테스트가 부족한 핵심 로직을 찾아서
Vitest 테스트를 추가하고
전체 테스트를 실행해줘.
테스트 생성은 생각보다 토큰을 꽤 씁니다.
특히 여러 패키지가 있는 프로젝트라면 Claude가 코드를 읽는 것만으로도 상당한 컨텍스트를 사용합니다.
3. 리팩터링 후보 찾기
프로젝트 구조를 분석해서
리팩터링이 필요한 부분을 찾아줘.
단, 기능 변경은 하지 말고
안전하게 개선 가능한 부분만 수정해줘.
이 방식의 장점은 불필요한 대규모 코드 변경을 방지하면서도 Claude에게 충분한 분석 작업을 맡길 수 있다는 것입니다.
4. 문서화
의외로 괜찮은 방법입니다.
현재 프로젝트를 분석해서
docs/PROJECT_OVERVIEW.md
문서를 작성해줘.
프로젝트 구조,
패키지 역할,
주요 데이터 흐름,
빌드 및 실행 방법,
주의해야 할 설계 규칙을 정리해줘.
나중에 Claude Code나 Codex에게 프로젝트를 다시 맡길 때도 유용합니다.
즉 토큰을 버리는 게 아니라 개발 자산으로 바꾸는 셈입니다.
제가 가장 추천하는 조합
사용량이 30% 정도 남았다면 저는 아마 이렇게 사용할 것 같습니다.
1. 프로젝트 전체 코드 리뷰
↓
2. 테스트 부족 부분 추가
↓
3. 테스트 전체 실행
↓
4. 발견된 문제 수정
↓
5. 변경 내용 문서화
이걸 한 번의 큰 프롬프트로 요청하는 겁니다.
Claude Code가 알아서 탐색하고 수정하고 테스트하게 놔두면 됩니다.
하지만 너무 큰 작업은 주의
여기서 한 가지 함정도 있습니다.
남은 토큰이 아깝다고 이렇게 시키는 겁니다.
프로젝트 전체를 완벽하게 리팩터링해줘.
이건 추천하지 않습니다.
Claude Code가 예상보다 광범위하게 코드를 바꿔버릴 수 있기 때문입니다.
특히 리셋 직전에는 사람이 변경 사항을 꼼꼼하게 확인할 시간도 부족할 수 있습니다.
그래서 저는 항상 이런 제한을 붙이는 편입니다.
기존 기능과 API 동작은 변경하지 않는다.
대규모 구조 변경은 하지 않는다.
안전하게 수정 가능한 범위만 변경한다.
수정 후 반드시 테스트를 실행한다.
이 몇 줄만 추가해도 사고 가능성이 꽤 줄어듭니다.
핵심은 ‘토큰 태우기’가 아니라 ‘남은 사용량을 자산으로 바꾸기’
처음에는 단순히 이런 생각이었습니다.
“어차피 7시에 사라질 토큰인데 어떻게든 써버리자.”
그런데 몇 번 사용하다 보니 조금 생각이 달라졌습니다.
남은 사용량을 억지로 코드 생성에 사용하는 것보다,
- 코드 리뷰
- 테스트 생성
- 문서화
- 기술 부채 탐색
- TODO 정리
- 아키텍처 분석
같은 평소에는 토큰이 아까워서 잘 시키지 않는 작업에 사용하는 것이 훨씬 효율적입니다.
특히 AI 코딩 도구를 사용하다 보면 기능 구현에만 집중하게 되고, 정작 테스트나 문서화는 계속 뒤로 밀리기 쉽습니다.
리셋 직전 남는 사용량은 그런 작업을 처리하기 꽤 좋은 타이밍입니다.
정리
7시 리셋을 기준으로 보면 이런 전략이 가장 현실적입니다.
시간추천 행동
| 6:00 | 평소 개발 작업 |
| 6:30 | 남은 사용량 확인 |
| 6:35~6:45 | 코드 리뷰·테스트·문서화 같은 장시간 작업 시작 |
| 6:50 | 새 대형 작업 추가는 신중하게 |
| 6:58 | 여러 명령 몰아넣기는 큰 효과 기대하기 어려움 |
| 7:00 | 사용량 리셋 |
| 7:00 이후 | 새 작업 시작 |
한 줄로 정리하면,
리셋 2분 전에 명령을 쌓아두기보다, 20~30분 전에 Claude Code가 실제로 오래 일할 만한 작업을 하나 시키는 편이 낫다.
Claude Code 꼼수 팁 VER.2
이번 팁은 사실 거창한 꼼수라기보다는 사용량을 조금 덜 아깝게 쓰는 방법에 가깝습니다.
Claude Code를 많이 사용하는 사람이라면 아마 한 번쯤은 경험했을 겁니다.
평소에는 토큰이 부족해서 아껴 쓰는데…
이상하게 리셋 10분 전에는 40%가 남아 있습니다.
그럴 때는 급하게 기능 하나 더 만들려고 하지 말고,
“프로젝트 전체 한번 훑어봐.”
라고 시켜보는 것도 꽤 괜찮습니다.
리셋과 함께 사라질 뻔한 사용량이
테스트 코드 몇 개와 문서 하나로 남는다면,
그 정도면 나름 성공적인 Claude Code 토큰 막차 탑승 아닐까요.
'study > TIP' 카테고리의 다른 글
| 애드센스 승인 도전기 1 (2) | 2026.08.20 |
|---|---|
| 공공데이터 + 바이브 코딩, 생각보다 할 수 있는 게 많다 (1) | 2026.08.19 |
| 서비스가 혼잡했습니다. Claude 모델 과부하 원인은? 529·429·사용량 제한 차이 정리 (0) | 2026.08.14 |
| 노숙에도 명당이 있을까? 공항·역·공원 현실 체크와 진짜 필요한 생존 정보 (0) | 2026.08.12 |
| 당근, 그리고 AI, 거래실패 공유 (0) | 2026.07.28 |