Claude Code 사용량 제한을 일주일 내내 유지하는 방법
How I've managed to make my Claude Code Max limits last an entire week
핵심 요약
문서화, 역할 분담, 모델 최적화 및 단계적 테스트를 통해 Claude Code 사용 효율을 극대화한 경험담입니다.
- 문서화 활용 — 코드베이스를 상세히 문서화하여 Claude가 매번 프로젝트를 재학습하는 시간을 줄임
- 역할 기반 워크플로우 — Claude를 단일 개발자가 아닌 아키텍트와 여러 워커로 나누어 병렬 작업 수행
- 모델 최적화 — 작업 난이도에 따라 모델을 선택하고, 실패 시 모델을 교체하는 전략 도입
- 테스트 효율화 — 전체 통합 테스트 대신 단계별 테스트를 도입하여 토큰 낭비 방지
지난 3주 동안 Claude Code를 주간 사용량 제한에 걸리지 않으면서 거의 24시간 내내 돌릴 방법을 연구해 봤다.
이런 설정을 하기 전에는 며칠 만에 주간 제한을 다 써버리기 일쑤였다.
이제는 일주일 내내 사용량을 분산해서 하루에 14% 정도씩 쓰고, 주말쯤 되면 98% 근처까지 딱 맞게 사용하고 있다.
내가 어떻게 세팅했는지, 뭐가 효과가 있었고 어떤 문제에 부딪혔는지 공유해 보려고 한다.
우선 내 세팅부터 말해줄게.
나는 주로 개발 중인 SaaS 애플리케이션에 Claude Code를 쓰고 있다. 지금은 코드 라인 수가 30만 줄이 넘어가고, 모듈, 함수, 클래스, 도구, 스킬, 연동 기능까지 엄청나게 복잡해진 상태다.
프로젝트가 꽤 커지다 보니 그냥 Claude Code 켜서 바로 수정하라고 시키는 건 점점 비효율적이더라.
나는 Proxmox 서버에 올린 전용 VM에서 Claude Code를 돌린다.
이놈은 별도의 RAM, 스테이징 환경, Supabase 인스턴스가 할당된 개발용 VM에 접근할 수 있고, 필요하면 오버플로우용 VM도 하나 더 붙여서 쓴다.
Claude Code는 항상 tmux 세션 안에서 돌아가니까 원격으로 접속했다가 끊어도 계속 작업하게 둘 수 있어서 편하다.
1. 문서화가 진짜 큰 차이를 만들었다
가장 먼저 집중한 건 코드베이스를 제대로 문서화하는 거였다.
각 모듈이 뭔지, 어떻게 돌아가는지, 의존성은 어떤지, 파일들은 어디에 있는지 설명하는 마크다운 파일들을 싹 다 정리했다.
코딩 표준, 테스트 요건, 보안, 개발 절차, 릴리스 규칙 같은 걸 다룬 파일들을 연결해 둔 꽤 방대한 엔지니어링 정책 문서도 만들어 뒀다.
핵심은 Claude가 새로운 작업을 시작할 때마다 애플리케이션이 어떻게 돌아가는지 처음부터 다시 파악할 필요가 없게 만드는 거다.
물론 이 문서들을 유지보수하는 게 시간이 좀 걸리긴 하는데, 매번 똑같은 걸 설명하는 것보다는 훨씬 효율적이다.
2. Claude Code를 그냥 개발자 한 명으로 취급하는 걸 그만뒀다
이게 아마 제일 큰 변화일 거다.
새 세션을 시작할 때, 나는 Claude한테 수석 소프트웨어 아키텍트 역할을 하라고 지시하는 초기 프롬프트를 넣는다.
이놈의 첫 번째 임무는 뭘 하기 전에 관련 문서, 최근 개발 노트, 프로젝트 상태를 먼저 읽는 거다.
프로젝트 파악이 끝나면 준비됐다고 보고를 올린다.
그 시점부터는 이 수석 아키텍트가 작업 계획을 짜고, 업무를 분담하고, 적절한 모델을 고르고, 결과물을 검토하고, 개발 과정을 관리한다.
Claude 세션 하나가 다 하는 게 아니라, 수석이 병렬로 돌아가는 여러 작업자(worker)들을 조율하는 방식이다.
각 작업자는 자기 브랜치에서 따로 움직이니까, 서로 방해하지 않으면서 애플리케이션의 여러 부분을 동시에 개발할 수 있다.
3. 모델 선택이 진짜 중요하다
내가 도입한 규칙 중 하나는, 수석 아키텍트가 업무를 배정할 때 토큰 사용량을 반드시 고려해야 한다는 거다.
모든 작업에 제일 똑똑한 모델이 필요한 건 아니거든.
어떤 작업은 비교적 단순한데, 어떤 건 복잡한 아키텍처나 디버깅, 혹은 더 강력한 추론이 필요한 결정이 필요하다.
수석은 무조건 제일 비싼 모델을 쓰는 게 아니라, 작업마다 가장 적절한 모델을 골라야 한다.
이게 꽤 도움이 됐는데, 동시에 내가 겪은 가장 큰 문제 중 하나를 불러오기도 했다.
가끔 수석이 능력이 부족한 모델한테 작업을 던져주는데, 그 모델이 제대로 끝내질 못하는 거다.
