클로드 코드 한도가 빨리 닳을 때 확인할 것

버튼 하나를 고쳐 달라고 했는데 파일을 여러 번 읽고 같은 테스트를 반복한다. 수정은 끝나지 않았고 사용량만 늘어난다. 이럴 때는 세션에서 어떤 일이 되풀이되는지부터 보는 편이 좋다.

클로드 코드 개발진은 작업 비용을 설명하며 재시도 횟수와 대화 길이, 캐시 재사용을 함께 보라고 권한다. 긴 대화에서 짧게 한 번 더 요청해도 앞선 맥락이 다음 요청에 다시 들어가기 때문이다. 그렇다고 매번 대화를 지우면 이어서 쓸 정보까지 잃는다. Anthropic 개발 글

아래 예시는 회원 초대 기능을 고치는 가상의 작업이다. 실제 프로젝트에서 측정한 절감 수치를 뜻하지 않는다.

시작할 때 테스트 이름까지 적는다

“초대 기능을 고쳐 줘”만 남기면 정상 동작의 기준부터 모델이 짐작해야 한다. 만료된 초대를 처리하는 문제인지, 같은 이메일로 두 번 보내는 문제인지에 따라 수정할 코드가 다르다.

요청에 증상과 재현 조건, 바꿔도 되는 범위, 확인 방법을 같이 적어 보자. 아래처럼 짧아도 된다.

실제 파일 경로와 테스트 명령을 알고 있다면 함께 넣는다. 모른다면 관련 테스트를 찾는 일부터 요청하면 된다. 없는 테스트 명령을 그럴듯하게 채울 필요는 없다.

이 예시에서 완료 여부는 화면을 고쳤다는 설명만으로 정하지 않는다. 만료 링크가 거부되는지, 정상 링크가 여전히 열리는지를 확인한다. 작업 전에 이 기준을 적어 두면 검토할 때도 같은 질문을 다시 꺼내기 쉽다.

• 범위: 초대 확인 API와 관련 테스트부터 확인한다.
• 성공 기준: 정상·만료·이미 사용한 링크의 기대 동작을 적는다.
• 검증: 실행한 검사와 실행하지 못한 검사를 구분해 남긴다.

막혔을 때는 실패 원인부터 나눈다

테스트가 계속 실패한다고 곧바로 추론 강도를 높일 이유는 없다. 테스트 서버가 꺼졌거나 필요한 권한이 없으면 모델이 더 생각해도 검사를 끝낼 수 없다. 요구사항을 잘못 이해했다면 설명을 고치는 쪽이 빠르다.

재시도 전에 실패를 한 문장으로 적게 해 보자. 원인에 따라 다음 행동이 달라진다.

실패 원인	다음에 확인할 것
테스트 실행 불가	테스트 서버와 필요한 권한
요구사항 오해	증상과 기대 동작의 차이
수정 누락	빠진 호출부와 경계 조건

같은 오류를 반복한다면 새로 확인한 근거가 무엇인지 물을 수 있다.

추론 강도를 높일 만한 경우도 있다. 수정은 됐지만 다른 호출부를 놓치거나 경계 조건을 빠뜨리는 작업이다. Anthropic의 실험에서는 높은 추론 강도가 예외 상황 점검에 도움을 줬다. 다만 특정 벤치마크와 예제의 결과이므로 모든 프로젝트에서 같은 효과를 기대할 수는 없다. Spending your effort

단순한 이름 변경을 할 때와 여러 권한 조건을 검토할 때를 같은 설정으로 묶지 않아도 된다. 현재 모델이 지원하는 설정을 확인하고 작업에 맞게 조절한다. 올린 뒤에는 실패가 줄었는지까지 봐야 한다.

대화를 정리하기 전에 남길 것을 고른다

관련 없는 작업으로 넘어갈 때는 /clear로 새 대화를 시작할 수 있다. 같은 작업을 계속한다면 /compact에 보존할 내용을 지정하는 방법이 있다. 현재 공식 문서도 작업 전환과 맥락 요약을 구분한다. Claude Code 비용 관리 문서

초대 기능을 내일 이어서 고친다면 이렇게 남길 수 있다.

요약이 끝나면 빠진 내용이 없는지 확인한다. 특히 마지막 오류와 다음에 실행할 검사가 남아 있어야 한다. 긴 로그 전체를 붙여 두는 것보다 다시 확인할 위치를 적는 편이 읽기 쉽다.

/compact도 대화를 읽고 요약하는 작업이므로 사용량이 든다. 이미 끝난 일을 정리하려고 의무적으로 실행할 필요는 없다. 작업 도중 모델이나 도구 구성을 자주 바꾸는 습관도 살펴보자. 변경에 따라 캐시를 다시 만들어야 할 수 있다. Anthropic 개발 글

끝난 뒤에는 완료 결과와 사용량을 같이 남긴다

/usage에서는 세션 사용량과 플랜 사용량을 확인할 수 있다. 구독 사용자에게 표시되는 세션의 달러 환산값을 실제 추가 청구액으로 읽으면 안 된다. 공식 문서는 세션 비용 추정치와 구독 한도를 구분한다. Claude Code 비용 관리 문서

처음부터 복잡한 기록장을 만들 필요는 없다. 끝난 작업 하나에 다음만 남겨 보자.

• 작업과 모델, 추론 강도
• 통과한 검사와 실행하지 못한 검사
• 사람이 다시 설명하거나 수정을 되돌린 횟수
• /usage에 표시된 사용량과 눈에 띄는 캐시 정보

다음에 비슷한 작업을 할 때 요청 방식을 하나만 바꿔 비교한다. 재현 조건을 먼저 붙여 보거나, 확인할 테스트를 미리 지정하는 식이다. 서로 다른 작업의 사용량만 비교해 “이 설정이 몇 퍼센트 절약된다”고 결론 내리지는 않는다.

다음 세션에서는 작업을 한 문장으로 좁히고 검사 방법 하나를 먼저 적어 보자. 끝나면 사용량과 통과한 테스트를 함께 남긴다. 한도를 더 쓰기 전에 같은 수정을 몇 번 되풀이했는지 확인할 기록이 생긴다.

참고 자료

• 요즘IT, 「클로드 코드 토큰 한도 아끼는 방법 7가지」 · 관련 읽을거리
• Addy Osmani, What a task costs on Opus 5.5 · 2026-09-25
• Thariq Shihipar, Spending your effort · 2026-09-25
• Claude Code, Manage costs effectively · 2026-10-16 확인

명령어와 사용량 화면은 설치 버전, 모델, 로그인 방식에 따라 다를 수 있다. 이 글은 2026년 10월 16일 확인한 문서를 기준으로 작성했다.