며칠 전에 사용량 한도가 72%까지 찍혔다. 5시간 한도 기준이었다. 그냥 넘어가기엔 숫자가 너무 선명했다.
사용량 72%까지 치솟은 후 도구 찾기 시작
원인은 세 가지였다. 세션 길이, Playwright(웹 브라우저를 자동으로 조종하는 도구) 반복 실행, Opus(Claude의 가장 고성능 모델) 과다 사용. 이 셋이 합쳐져서 사용량을 갉아먹고 있었다.
결론이 나고 나서 GitHub(개발자들이 코드를 공유하는 플랫폼)에서 화제인 도구 카드들을 캡처하기 시작했다. 보이는 족족 저장했다. 그리고 Claude Code(터미널에서 쓰는 AI 코딩 도구)한테 하나씩 물어봤다.
이게 효과가 있을 것 같았다. 적어도 처음엔.
GitHub에서 본 8개 도구, 모두 안 맞았던 이유
확인한 도구가 총 8개였다. claude-mem, find-skills, VibeSec, Ruflo, ponytail, graphify, OmniRoute, ECC. 이름만 보면 뭔가 있어 보였다. GitHub AI 에이전트 도구 7개를 검증했을 때도 결론은 똑같았다 — 하나도 안 맞았다.
결과는 전부 똑같았다. 이미 내 환경에 있거나, 내 상황에 안 맞는다는 답이 돌아왔다. 8번 다 그랬다. 한 번도 “이거 설치해봐”로 끝나지 않았다.
그래서 마지막에 방향을 바꿨다. 도구 이름을 들이밀지 않고 이렇게 물었다. “지금 상황에서 실질적으로 효과도 있으면서 사용량을 현저히 줄일 수 있는 플러그인 있으면 추천해줘.”
질문을 바꾸니 답이 달랐다.
결국 답은 이미 내 환경에 있었다
headroom MCP 도구가 나왔다. MCP(Model Context Protocol)는 AI 모델이 외부 도구를 쓸 수 있게 연결해주는 규격이다. GitHub 카드로 본 적 없는 이름이었다.
확인해보니 이미 내 설정 파일(~/.claude/settings.json)에 들어가 있었다. 연결까지 돼 있는 상태였다. 그런데 이번 세션 동안 이 도구가 실행된 횟수는 0회였다.
있는데 안 쓰고 있었다.
이건 좀 웃겼다. 지난주에도 비슷한 일이 있었다. blog-automation이라는 스킬(Claude Code에 등록해두는 작업 단위)이 몇 달째 삭제된 폴더를 가리키고 있었다는 걸 뒤늦게 발견했다. 그때는 없는 걸 가리키고 있었고, 이번엔 있는 걸 안 쓰고 있었다. 패턴이 똑같다. 설치하고 나면 신경을 끊어버린다. 그게 문제다.
headroom으로 직접 테스트한 압축 결과
발견하고 바로 테스트했다. 지어낸 숫자를 쓰기 싫어서, 실제로 도구를 호출했다.
테스트에 쓴 파일은 내 메모리 파일(MEMORY.md)이었다. 크기는 11.8KB. Claude Code가 작업 중에 참고하는 메모 파일이다.
구분
토큰 수
압축 전 원본
2,118
압축 후
675
절감률
68%
68% 절감. 원본의 3분의 1 수준으로 줄었다.
원본 손실이 걱정됐는데, 그 부분을 제일 먼저 확인했다. 압축된 내용은 해시값으로 묶여서 저장된다. 요약해서 버리는 구조가 아니었다. 압축해서 보관하고, 필요하면 원본을 다시 꺼낼 수 있는 구조였다. 이 부분은 안심해도 된다.
설치 후 잊혀지는 도구, 워크플로에 끼워 넣기
새로 깔 게 없었다. 8개를 확인하고, 결국 답은 9번째였는데, 그것도 이미 갖고 있던 거였다.
문제는 도구가 없는 게 아니었다. 워크플로에 넣지 않은 게 문제였다. 설정 파일에만 있고 실제로 쓰지 않으면 없는 것과 다르지 않다.
그래서 규칙을 하나 만들었다. 앞으로 큰 파일을 읽거나 API 응답을 받을 때 headroom을 먼저 거친다. 순서에 박아넣지 않으면 또 잊어버린다. 이번에 확인했다.
주기적으로 내 설정 파일을 열어서 연결된 도구 목록을 확인해야 한다. 설치했다고 끝이 아니다. 실제로 쓰이고 있는지 보지 않으면 모른다. 이건 귀찮아도 해야 한다.
다음에 사용량 점검할 때는 도구 목록부터 열어볼 생각이다. GitHub 카드를 캡처하기 전에.
CLAUDE.md 정리를 한 번도 안 했다면 점검해볼 만하다. Claude Code(AI 코딩 도우미)를 쓰다 보면 어느 순간 CLAUDE.md 파일이 여러 개가 된다. 내 환경에는 세 개가 있었다. 그냥 두면 되는 줄 알았는데 점검해보니 아니었다.
CLAUDE.md가 뭐고 왜 여러 개일까?
CLAUDE.md는 Claude Code가 세션(session, 작업을 시작하고 끝내는 한 번의 대화 구간)을 시작할 때 자동으로 읽는 설정 파일이다. “나는 이렇게 일하는 사람이야, 이 규칙을 따라줘”라고 클로드에게 미리 알려두는 메모다.
문제는 이 파일이 한 군데만 있는 게 아니라는 점이다. Claude Code는 공식 문서에 나온 것처럼 여러 위치에서 CLAUDE.md를 찾는다. 홈 폴더(~/CLAUDE.md), 전역 설정 폴더(~/.claude/CLAUDE.md), 그리고 각 프로젝트 폴더 안의 CLAUDE.md까지.
내 세 파일은 ~/CLAUDE.md, ~/.claude/CLAUDE.md, 자동화 프로젝트 폴더의 CLAUDE.md였다. 그래서 클로드에게 직접 점검을 시켰다. 파일 내용을 실제 폴더와 대조해서 읽고, 수정하거나 지워도 되는 부분이 있으면 알려달라고 했다.
CLAUDE.md 정리 전 점검: 세 파일에서 나온 문제
세 파일 모두 문제가 있었다. 종류는 달랐다.
~/CLAUDE.md는 131줄짜리 파일이었다. 클로드가 읽고 나서 이상한 걸 발견했다. 1번 줄과 67번 줄에 똑같이 # CLAUDE.md라는 제목이 있었다. 1~65줄과 67~131줄을 비교했더니 완전히 같은 내용이었다. 같은 지침 블록이 두 번 들어가 있었다는 뜻이다.
위는 정리 전 131줄, 정리 후 65줄과 두 블록 비교 결과를 찍은 화면이다. 왜 두 번 들어갔는지 원인은 지금도 모른다.
자동화 프로젝트 CLAUDE.md에는 다른 문제가 있었다. workflows/ 폴더를 전제로 한 규칙이 세 곳에 흩어져 있었다. “Workflow는 내 허락 없이 새로 만들거나 삭제하지 마”, 에러 처리 절차의 ‘Workflow 업데이트’, 보안 절의 ‘Workflow’ 표현. 그런데 workflows/ 폴더가 실제로 없었다. 폴더는 사라졌는데 규칙은 그대로 남아 있었다.
CLAUDE.md 정리 중 만난 NotebookLM 지시 문제
~/.claude/CLAUDE.md는 또 다른 문제였다. 세션 시작 때 NotebookLM(구글의 AI 노트 정리 도구) 노트북을 먼저 검색하라고 되어 있었다. 그런데 NotebookLM 연결은 로그인 감지 버그와 구글 장애로 2026-09-01부터 막혀 있었다. 매 세션마다 실패할 게 뻔한 명령이 설정에 그냥 살아 있었던 거다.
위는 전역 CLAUDE.md의 NotebookLM 지시를 고친 변경 부분이다.
그 외에 자동화 프로젝트 CLAUDE.md에 ‘실제 사용 중인 블로그는 tistory 1개뿐’이라고 적혀 있었다. 지금 이 블로그, ujinify.com이 훨씬 더 활발히 쓰는 프로젝트인데도 설정에는 반영이 안 되어 있었다.
CLAUDE.md 정리 첫 단계: 중복 찾는 쉘 명령어
쉘(shell, 명령어를 입력해서 컴퓨터에게 일을 시키는 창)에서 두 가지 명령어로 확인할 수 있다.
먼저 파일이 몇 줄인지 센다.
wc -l ~/CLAUDE.md , 줄 수를 보여준다. wc는 ‘word count’의 줄임말이다.
grep -n '^# ' ~/CLAUDE.md , 파일 안에서 #으로 시작하는 제목 줄을 찾아서 몇 번째 줄인지 함께 보여준다. grep은 파일 안에서 특정 단어나 패턴을 찾는 명령어다.
내 경우에는 grep 결과에 # CLAUDE.md가 1번 줄과 67번 줄, 두 군데 나왔다. 같은 제목이 두 번 뜨면 중복을 의심해야 한다. 그다음엔 두 블록의 내용이 실제로 같은지 확인해야 한다.
앞 블록과 뒤 블록을 비교하는 짧은 스크립트(script, 명령어를 순서대로 묶어둔 파일)를 돌렸다. 완전히 같다는 결과가 나왔고, 그래서 뒤 블록을 지웠다.
자기 파일에서 확인하려면 이 순서로 해보면 된다. wc -l로 줄 수 확인 → grep -n '^# '로 제목 위치 확인 → 같은 제목이 두 군데 이상 있으면 두 블록 내용 비교. 간단하다.
CLAUDE.md 정리에서 없는 폴더 규칙 지우기
workflows/ 폴더가 실제로 없다는 걸 어떻게 확인했냐고 하면, ls 명령어로 봤다. ls는 폴더 안에 뭐가 있는지 목록으로 보여주는 명령어다. 없으면 없다고 나온다.
있어야 할 폴더가 없으면 그 폴더를 전제로 한 규칙은 전부 의미가 없다. 클로드가 “Workflow 삭제 전 허락을 받아야 한다”는 규칙을 읽어도, 지킬 대상이 없다. 그냥 노이즈다.
위는 workflows 폴더가 없다는 결과와 정리 전후 ‘Workflow’ 문구 검색 결과다.
수정 전에 파일을 /tmp에 백업했다. /tmp는 임시 파일을 저장하는 폴더다. 백업 없이 수정하지 마라. 잘못 지우면 돌아올 방법이 없다.
백업 뒤에 workflows/ 관련 문구를 세 곳 모두 지웠다. 113줄이던 파일이 106줄이 됐다.
파일 구조를 설명하는 절도 실제와 달랐다. tools/ 폴더에 파이썬(.py)과 타입스크립트(.ts) 파일이 섞여 있고, 새 코드는 타입스크립트로 작성된다는 실제 구조로 고쳤다. ujinify를 활성 블로그 목록에 올리고, 폐기된 프로젝트 목록은 4줄로 줄였다. 보관 방침은 그대로 뒀다.
실제 안 쓰는 도구 지시는 지우기로 했다
NotebookLM 지시는 지울지 남길지 갈렸다. 연결이 복구되면 다시 켜야 해서, 재개 규칙까지 통째로 지우면 나중에 처음부터 다시 써야 한다.
그래서 지우지 않고 ‘보류 중’으로 바꿨다. 지시 자체는 남겨두고, 현재 상태를 주석처럼 표시한 거다. 연결이 복구되면 ‘보류 중’ 표시만 지우면 된다. 재개 규칙은 그대로 살아 있다.
이건 판단의 문제다. 완전히 폐기된 도구라면 지우는 게 맞다. 일시 중단 상태라면 보류 표시를 남겨두는 쪽이 낫다. 어느 쪽이든 원칙은 하나다. 지금 작동하지 않는 도구에 대한 지시가 설정에 살아 있으면 클로드는 매 세션마다 실패할 명령을 실행하려 한다. 그 부분만큼은 반드시 정리해야 한다.
ujinify 전용 CLAUDE.md를 새로 만든 이유
점검하면서 ujinify 블로그 파이프라인 폴더에 전용 CLAUDE.md를 새로 만들기도 했다. 여기저기 흩어져 있던 규칙들, 글 내용 규칙, 이미지 캡처 규칙, 랭크매스 점수 규칙, 릴스·링크 처리 순서를 한 파일에 모았다.
알려진 문제도 적었다. 이미지 캡션과 사실을 지어내는 문제, 랭크매스 포커스 키워드가 REST로 저장되지 않는 문제. 고친 게 아니라 기록한 거다. 기록해두지 않으면 클로드도 나도 같은 실수를 반복한다.
정리 후 나한테 달라진 점, 너도 확인해보는 방법
솔직하게 말하겠다. CLAUDE.md 정리 후 확인한 건 줄 수뿐이다. ~/CLAUDE.md가 131줄에서 65줄이 됐다. 프로젝트 CLAUDE.md가 113줄에서 106줄이 됐다. 그게 다다.
응답이 빨라졌는지, 컨텍스트가 몇 토큰 줄었는지는 측정하지 않았다. 그래서 효과는 “읽는 분량이 줄었다”까지만 말할 수 있다. 더 좋아졌다고 단정하지 않겠다.
내 환경의 CLAUDE.md 정리 상태 확인하는 법
자기 환경에서 확인하고 싶다면 세 가지만 해보면 된다.
wc -l로 CLAUDE.md 줄 수를 세고, grep -n '^# '로 같은 제목이 반복되는지 확인한다.
CLAUDE.md 안에 언급된 폴더 이름을 찾아서 ls로 실제로 있는지 확인한다.
세션 시작 때 실행하라고 적어둔 도구가 지금도 작동하는지 직접 돌려본다.
나는 이 세 가지에서 각각 문제가 나왔다. 처음 점검해보는 사람이라면 하나쯤은 걸릴 거라고 본다. 오래된 설정일수록 더 그렇다.
