Automata V.27 | 이 세가지 방법으로 클로드 코드 사용량을 더 많이 절약할 수 있어요!

얼마 전 클로드 사용량을 아껴줄 수 있는 툴들을 소개하는 특집을 진행했었죠!

오늘을 클로드 코드 특집 2탄으로 클로드 코드나 다른 코딩 에이전트 사용 패턴으로 클로드 코드 사용량을 효율적으로 관리할 수 있는 방법 세 가지를 준비해 봤어요! 

🗄️ 클로드 사용량, 프롬프트 캐시만 잘 지켜도 반은 아껴요

클로드 세션이 생각보다 빨리 닳는다고 느끼신 적 있으신가요? Opus 같은 고성능 모델을 쓰거나 너무 많은 subagent를 동시에 돌리는 것도 이유가 되겠지만, 프롬프트 캐싱을 제대로 활용하지 못해서 사용량이 과하게 소진되는 경우도 적지 않아요.

프롬프트 캐시?

LLM은 대화를 처리할 때 세션 맨 첫 단어부터 새로 들어온 입력까지 전체 대화를 다시 계산한 뒤에야 출력 토큰을 내놓아요. 앞선 대화 내용은 어차피 잘 바뀌지 않는데, 매번 처음부터 다시 계산하면 낭비가 클 수밖에 없죠. 이런 반복 계산을 줄이려고 여러 LLM 서버는 새 입력이 들어오기 전까지의 연산 결과를 미리 계산해 저장해 두는데, 이게 바로 프롬프트 캐싱이에요.

중요한 포인트는 프롬프트 캐싱으로 처리되는 작업인 기존 입출력 처리보다 훨씬 적은 사용량으로 처리된다는 점이에요!

다만 프롬프트 캐시가 영구히 남아있는 건 아니에요. 클로드는 캐시 유효 시간(TTL)이 한 시간으로 제한되어 있어서, 한 시간 넘게 캐시를 쓰지 않으면 그대로 삭제돼요. 같은 대화를 다시 시작해도 캐시가 사라진 뒤라면 대화 토큰 전체를 처음부터 다시 계산하게 됩니다.

프롬프트 캐싱과 토큰 과다 사용은 어떤 관계가 있을까요? 문제는 긴 대화 세션을 오래 쉬었다가 다시 이어갈 때 생겨요. 예를 들어 클로드 코드로 사이트에 새 기능을 추가하려고 긴 대화를 이어가다가 퇴근하고, 다음 날 같은 세션에서 작업을 이어가는 경우가 대표적이죠. 하룻밤 사이 캐시가 만료됐다면 그동안 쌓인 대화를 전부 다시 계산하는 셈이라 토큰이 그만큼 더 소모돼요.

또 문제되는 상황은 세션 중 대화 맥락이 조금만 바뀌어도 캐시를 아예 쓸 수 없게 되는 경우예요. 모델을 바꾸거나 MCP 연결을 추가·해제하면 시스템 프롬프트 자체가 달라지기 때문에 캐시가 무효화되고, 그동안의 대화 연산을 전부 다시 처리하게 돼요.

반대로 세션 중에 캐시를 그대로 유지하는 동작도 있어요. /rewind로 이전 턴으로 되감거나 스킬·커맨드를 호출하는 정도로는 캐시가 깨지지 않아요. 되감은 지점까지의 기록은 이미 캐시된 접두부와 같아서 그대로 캐시를 히트하고, 스킬 지침이 뒤에 붙는 정도는 그 뒷부분만 새로 계산하면 되거든요.

세션 대화 중간에 오래 자리를 비워야 한다면, 자리를 비우기 전 아래 프롬프트로 새 세션에서 이어갈 HANDOFF.md 문서를 만들어달라고 요청하세요. 그리고 다시 작업을 이어가려면 새 세션에서 클로드가  HANDOFF.md 문서를 읽게 하고 작업을 이어가는 걸 추천해요.

지금까지의 작업 맥락을 정리한 HANDOFF.md 파일을 만들어줘. 다음 내용을 포함해줘.

1. 지금까지 진행한 작업의 목표와 전체 배경
2. 지금까지 완료한 작업과 변경된 파일 목록
3. 지금 진행 중이던 작업과 다음에 이어서 해야 할 일
4. 반드시 지켜야 할 결정 사항이나 제약 조건
5. 새 세션을 시작할 때 먼저 확인해야 할 파일이나 명령어

새 세션에서 이 파일만 읽어도 바로 작업을 이어갈 수 있도록 최대한 구체적으로 적어줘.

🤔 세션 시작 전 이 두 가지만 생각해 보세요

세션을 시작하기 전에 이 두 가지만 챙겨도 같은 사용량으로 훨씬 오래 작업할 수 있어요. 바로 어떤 모델을 쓸지, 그리고 어떤 추론 레벨로 설정할지예요.

클로드 코드나 코덱스로 처리하는 작업이 전부 Sonnet이나 Opus, GPT-5.6 같은 큰 모델을 필요로 하는 건 아니에요. 파일 이름을 바꾸거나 간단한 grep을 돌리는 정도의 작업까지 매번 최상위 모델로 처리하면, 정작 복잡한 리팩터링이 필요한 순간에 쓸 사용량을 미리 써버리는 셈이죠. 어떤 모델을 고를지는 결국 작업 복잡도와 원하는 결과물 품질에 달려 있어서, 세션 안에서도 작업이 바뀔 때마다 모델을 직접 바꿔보면서 자기만의 기준을 만들어가는 게 중요해요.

추론 레벨(/effort)을 적절히 맞춰두는 것도 비슷한 효과가 있어요. 레벨을 낮추면 모델이 간단한 작업까지 과하게 확인하거나 불필요하게 재검토하는 일을 줄일 수 있고, 반대로 복잡한 디버깅이나 여러 파일에 걸친 리팩터링처럼 신중해야 하는 작업에서는 레벨을 높여서 충분히 생각하게 만들 수 있어요.

모델과 추론 레벨을 조합하는 예시를 들어볼게요. 오탈자를 고치거나 변수 이름을 바꾸는 작업이라면 작은 모델에 낮은 추론 레벨을 맞춰서 빠르게 처리하고, 여러 파일에 걸친 아키텍처 변경이나 까다로운 버그를 추적할 때는 큰 모델에 높은 추론 레벨을 맞춰서 충분히 생각할 시간을 주는 식이에요. 세션 중간에 작업 성격이 바뀌면 그때그때 모델과 추론 레벨을 다시 조정해주면 돼요.

⏰ 클로드 5시간 한도를 전략적으로 쓰는 방법

5시간 사용량을 전략적으로 관리하면 여러 윈도우에 걸쳐 사용량을 훨씬 효율적으로 쓸 수 있어요. 아래 그림을 보면서 좀 더 자세히 설명해볼게요.

Claude 5시간 사용 윈도우: 예약 워밍업 vs 미예약

클로드의 5시간 사용량 윈도우는 자정이나 오전 5시처럼 정해진 시각에 리셋되는 게 아니라 그날 처음 보낸 메시지 시점을 기준으로 잡혀요. 평소처럼 오전 9시에 첫 메시지를 보내면 윈도우는 오후 2시에 리셋되는데, 오전 중에 작업을 몰아서 하는 사람이라면 정오쯤 한도에 도달해 오후 2시까지 두 시간을 날리는 경우가 많아요. 그림 위쪽 "예약 없이" 케이스가 이 상황이에요.

반면 실제 작업보다 두 시간쯤 앞선 오전 7시에 가벼운 메시지 하나를 미리 보내두면 윈도우 자체가 그만큼 일찍 열리면서 리셋 시점도 함께 앞당겨져요. 그림 아래쪽처럼 오전 7시에 짧은 프롬프트를 보내면 윈도우는 정오에 리셋되고, 마침 실제 작업 중간에 새 사용량이 열려서 공백 없이 두 번째 세션으로 바로 넘어가요. 

클로드 코드에서는 짧은 프롬프트를 날리는 작업을 매일 자동으로 보내도록 예약할 수 있는데,  아래 단계를 따라하면 돼요.

클로드 코드를 사용할 때 언제 가장 집중적으로 작업하는지 사용 패턴을 먼저 파악한 다음, 리셋 시점이 그 시간대 한복판에 오도록 트리거를 맞추는 게 이 전략의 중점이에요.