Claude Code 세션 제한에 걸리는 이유를 알아냈습니다. 생각과는 다르더군요.
I figured out why I keep hitting my Claude Code session limit before lunch. It's not what I thought.
핵심 요약
Claude Code의 세션 제한은 작업량 때문이 아니라, 비효율적인 API 호출 방식 때문에 발생합니다.
- 비효율적 API 호출 — 모든 읽기, 검색, 편집 작업이 개별 API 호출로 처리되어 토큰 비용이 급증함.
- 세션 기록 누적 — 매 호출마다 이전 기록을 다시 입력받아 컨텍스트 비용이 기하급수적으로 증가함.
- 작업 배치 처리 — 검색과 읽기를 하나로 묶고 편집을 한 번에 처리하는 플러그인으로 효율성을 크게 개선함.
- 모델 성능 유지 — 모델이나 작업 계획을 바꾸지 않고도 호출 횟수를 줄여 세션 제한 문제를 해결함.
한동안 Max 모델을 사용해 왔습니다. 작업 도중에 계속 제한에 걸리길래 제가 너무 많은 일을 시키는 줄 알았죠. 그런데 알고 보니 제가 너무 많이 시킨 게 아니었습니다. 제 도구들이 내부적으로 엄청나게 비효율적으로 작동하고 있었던 겁니다.
단일 리팩토링 작업을 추적해 봤습니다. 파일 몇 개에 걸친 이름 변경 작업이었죠. Claude Code가 이걸 끝내는 데 161번의 턴을 돌더군요. 읽기, grep, 편집 하나하나가 전부 별도의 API 호출이었습니다. 호출할 때마다 그 이전의 모든 내용을 입력 토큰으로 다시 집어넣는 방식이었죠. 60번째 턴쯤 되면 세션 기록 전체에 대한 컨텍스트 비용을 지불하고 있는 셈입니다.
이걸 깨닫고 나서 호출을 배치로 처리할 방법을 찾기 시작했습니다. 검색과 읽기를 하나의 호출로 합치고 모든 편집을 한 번의 왕복(roundtrip)으로 몰아넣는 Claude Code 플러그인을 찾았죠. 같은 작업을 52번의 턴으로 끝냈습니다.
계획을 바꾼 것도, 모델을 바꾼 것도 아닙니다. 그저 작업당 왕복 횟수를 줄였을 뿐입니다.


