블로그 예약 발행 캡처 규칙을 막 정리했을 때였다. 뭔가 마무리된 느낌이 들어서 Claude 사용량 한도를 열어봤다.
5시간 한도 72%. 주간 한도 50%.
잠깐, 이게 벌써?
사용량 계기판에서 72%를 발견한 순간
Claude Code에는 사용량 계기판(usage dashboard, 내가 얼마나 썼는지 보여주는 화면)이 있다. 5시간 단위로 사용량을 제한하는 방식인데, 확인했더니 이미 72%가 찍혀 있었다.
이해가 안 됐다. 딱히 엄청난 작업을 한 것도 아니었다. 블로그 글 몇 편 만들고, 이것저것 설정 잡은 게 전부였다. 그런데 72%라니.
그래서 Claude한테 직접 물어봤다. 왜 이렇게 됐냐고.
돌아온 답이 좀 뜻밖이었다.
Claude 사용량 한도, 세션을 208MB까지 키운 게 진짜 범인이었다
세션(session, 대화창 하나를 열고 나서 닫기 전까지의 전체 대화 묶음)이 208MB, 줄 수로는 23,829줄까지 쌓여 있었다.
하루 종일 같은 대화창을 끊지 않고 계속 이어서 썼다. 작업이 바뀌어도 그냥 계속 입력했다. 새 창을 열 생각을 못 했다.
문제는 Claude가 대화하는 방식에 있다. 매 턴(turn, 내가 한 번 입력하고 Claude가 한 번 답하는 한 쌍)마다 지금까지 나눈 대화 전체를 처음부터 다시 읽는다. 토큰(token, AI가 글을 읽고 쓸 때 세는 단위. 대략 글자 두세 개 분량)으로 환산해서 전부 처리한다는 뜻이다.
세션 초반에는 괜찮다. 대화가 짧으니까. 그런데 세션이 쌓일수록, 한마디 할 때마다 처리해야 하는 양이 눈덩이처럼 불어난다. 나는 그 세션을 208MB까지 키웠다. 한마디 할 때마다 208MB짜리 대화를 통째로 들고 시작한 셈이다.
직접 명령을 돌려서 확인한 숫자다. 줄 수 23,829줄, 용량 208MB, 그 안에 이미지가 들어간 메시지만 1,420건. 이게 근본 원인이었다.
이미지 토큰(페이지 스냅샷)은 텍스트보다 훨씬 비싸다
두 번째 원인은 Playwright(플레이라이트, 브라우저를 코드로 자동 조작하는 도구)였다.
랭크매스 점수를 확인하려고 워드프레스 편집기를 열었다 닫았다를 반복했다. 포스트 하나 점수 보는 데 편집기를 6번 넘게 열었다.
문제는 브라우저를 열 때마다 딸려오는 것이 있다는 점이다. 페이지 스냅샷이 자동으로 첨부된다. Claude가 화면 상태를 파악하려면 이게 필요하다.
이미지 토큰은 텍스트 토큰보다 훨씬 무겁다. 글자 몇 백 개짜리 텍스트와, 화면 전체 이미지 한 장은 비교가 안 된다. 그걸 6번 넘게 반복했다. 거기에 208MB짜리 세션 문맥까지 매번 붙었다.
단순 계산이다. 비쌀 수밖에 없었다.
이 글을 올리는 과정에서도 똑같은 일이 반복됐다. REST API로 랭크매스 키워드를 저장했는데, 응답을 확인해보니 값이 안 찍혀 있었다. 저장이 씹힌 거다. 결국 편집기를 다시 열어서 UI에 직접 입력하고 저장 버튼을 눌러야 했다.
REST로 넣은 값은 저장 응답에 안 찍히는데, 편집기에서 직접 입력하고 저장하면 “글 업데이트 되었습니다” 토스트가 뜨고 새로고침해도 유지됐다. 편집기를 또 열어야 했다는 뜻이다. 방금 원인으로 지목한 그 습관을, 그 글을 쓰면서 또 반복한 셈이다.
Opus 모델을 너무 많이 쓴 것도 한몫했지만
세 번째는 모델 선택이었다. 그날 모델을 여러 번 바꿨는데, Opus(오퍼스, Claude 모델 중 가장 고성능이지만 가장 무거운 버전)를 꽤 자주 썼다.
Opus는 Sonnet(소네트, Opus보다 가볍고 빠른 중간 성능 모델)보다 5시간 한도를 훨씬 빨리 깎아먹는다. 같은 작업을 해도 Opus로 하면 한도 소모가 더 크다.
이것도 분명히 한몫했다. 하지만 솔직히 말하면, 세션 길이 앞에서는 부차적인 문제였다. 세션이 짧았다면 Opus를 좀 썼어도 이 정도는 아니었을 것이다.
블로그 생성 파이프라인은 별개였다, 한도 안 깎았음
처음엔 블로그 글 여러 편 만든 게 원인이라고 생각했다. 틀렸다.
블로그 글을 만드는 파이프라인은 API 키로 따로 돌아간다. 종량제(사용한 만큼만 별도로 돈 내는 방식) 결제라서 Claude Code의 5시간 사용량 한도와는 완전히 별개다.
글 열 편을 만들어도 이 계기판 숫자는 안 움직인다. 계기판에 찍힌 72%는 순전히 대화 자체에서 나왔다. 파이프라인 탓이 아니었다.
이건 좀 중요한 포인트다. 자동화 작업과 대화 사용량은 별도로 추적해야 한다. 같은 숫자로 묶어서 보면 원인을 잘못 짚는다.
지금부터 /clear로 세션을 끝내기로 결심한 이유
해결책은 단순하다. /clear를 쓰면 된다.
/clear는 Claude Code에서 현재 세션을 완전히 초기화하는 명령어다. 대화 기록을 싹 지우고 새 세션으로 시작한다. 208MB짜리 짐을 내려놓고 가볍게 다시 출발하는 것이다. 공식 문서에도 세션이 길어질수록 토큰 사용량이 늘어난다고 나와 있다.
왜 지금까지 안 썼냐면, 솔직히 필요성을 몰랐다. 대화가 길어지면 Claude가 문맥을 더 잘 기억하니까 오히려 좋은 거 아닌가 싶었다. 착각이었다.
문맥이 길어지면 Claude가 더 많이 읽어야 한다. 비용이 는다. 속도도 느려진다. 문맥을 오래 유지하는 건 장점만 있는 게 아니다.
사용량 한도는 어디서 확인하나
Claude Code에서 /usage를 입력하면 사용량 화면이 열린다. 여기서 Current session의 사용률과 리셋 시각을 볼 수 있다. Current week(모든 모델)의 사용률과 리셋 시각도 함께 나온다.
나는 이 화면에서 사용률이 17%, 28%, 36%로 올라가는 것을 직접 확인했다. 화면 아래에는 사용량이 많았던 이유도 나온다. 내 경우에는 150k 넘는 긴 문맥이 가장 큰 비중이었고, Playwright 같은 MCP 서버도 13~16%를 차지했다고 나왔다.
사용량 초기화는 언제 되나
/usage 화면에는 Current session 옆에 리셋 시각이 찍힌다. 내 계정에서는 Asia/Tokyo 기준 11:19pm이었다.
같은 화면을 두 번 열어봤다. 두 번째는 몇 분 뒤였고, 사이에 대화를 몇 번 주고받았다. 그래도 사용률 17%와 리셋 11:19pm이 그대로였다. 리셋 시각이 메시지를 보낼 때마다 밀리지는 않았다.
첫 사용 시점과 맞춰 보면
이 세션 기록에서 오늘 첫 활동은 6시 25분 무렵이다. 화면의 리셋 11:19pm에서 5시간을 빼면 6시 19분이라 6분 차이가 난다. 같은 계정으로 열어 둔 다른 창이 6시 19분쯤 먼저 쓰였을 수도 있다. 그래서 “처음 사용한 시점부터 5시간”이라고 단정하지는 않는다.
확인하지 못한 것도 있다. Pro 요금제의 리셋 규칙은 공식 문서에서 찾지 못했다. 위 내용은 내 화면에서 본 관찰이고, 다른 날 같은 시각에 리셋되는지는 아직 보지 못했다.
이제 작업 하나가 끝나면 /clear를 친다. 새 작업은 새 세션에서 시작한다. 이걸 습관으로 만들어야 한다. 모르고 넘어갔다면 72%가 아니라 100%를 진작에 찍었을 것이다.
계기판을 더 자주 봐야겠다는 생각도 든다. 이상한 걸 발견했을 때 그냥 넘기지 않고 물어본 덕분에 이 구조를 이해했다. 눈치채지 못했으면 다음 번에도 같은 실수를 반복했을 것이다.