AI Mac 정리 도구: 모델이 결정해도 되는 것과 안 되는 것

"AI Mac 정리 도구"는 사실 서로 다른 두 가지 제품을 가리킵니다. 하나는 내부 어딘가에 모델이 들어 있고, 추천의 지능을 내세워 파는 정리 앱입니다. 다른 하나는 Claude Code, Cursor, Ollama와 그 캐시가 지난 1년 동안 조용히 차지해버린 디스크를 되찾는 도구입니다. 2026년에 이 문구를 검색하는 사람 대부분이 원하는 건 후자입니다. 그래도 전자부터 먼저 답할 가치가 있는데, 그 답이 후자 그룹의 어떤 도구를 얼마나 신뢰할지를 결정하기 때문입니다.

1부: 모델이 실제로 결정하는 것

AI를 내세우는 정리 도구는 최소 네 단계로 이루어진 파이프라인 중 한 단계에 대해 주장을 하고 있는 겁니다.

1. 나열. 디스크를 훑고 크기를 잽니다. du 형태의 작업이고, 판단은 들어가지 않습니다.
2. 귀속. 각 경로를 어떤 앱이나 도구 체인이 소유하는지 결정합니다.
3. 순위와 설명. 4천 개 후보 중 어떤 12개가 살펴볼 가치가 있는지 정하고, 각각이 뭔지 한 문장으로 설명합니다.
4. 결정과 삭제. 무엇을 지워도 안전한지 정하고, 실제로 지웁니다.

2단계와 3단계는 정말로 애매하고, 모델이 정말로 도움이 됩니다. 4단계는 성격이 다른 문제고, 모델은 거기에 맞는 도구가 아닙니다. AI 정리 도구를 둘러싼 논쟁은 사실 거의 다 제조사가 어느 단계를 말하고 있는지에 대한 논쟁입니다.

모델이 제 몫을 하는 지점

귀속은 정직하게 말해서 진짜 어려운 사례입니다. ~/Library/Application Support/Foo Labs가 3GB를 차지하고 있는데 디스크에 Foo Labs라는 앱이 없다고 해봅시다. 증거는 약하고 흩어져 있습니다. 폴더 자체의 plist 안에 있는 번들 식별자 조각, ~/Library/HTTPStorages의 일치하는 접두사, ~/Library/Saved Application State 아래의 .savedState 번들, /var/db/receipts의 설치 영수증. 이름을 그대로 비교하는 방법은 바로 실패합니다. 제조사가 한 곳에는 Foo Labs라고 쓰고 다른 곳에는 com.foolabs.editor라고 쓰기 때문이고, 손으로 만든 카탈로그는 상위 몇백 개 앱까지만 다루다가 그 이후로는 뚝 끊깁니다. 바로 이런 모양이 규칙보다 모델이 이기는 지점입니다. 약한 신호는 많고, 결정적인 신호는 하나도 없고, 아무도 끝까지 정리하지 못할 긴 꼬리가 있는 상황이죠.

순위 매기기도 같은 모양입니다. 스캔 결과로 경로 4천 개와 60GB가 나왔다면, 그건 결과가 아니라 또 다른 문제입니다. 설명은 그보다 더 쉽습니다. ~/Library/Caches/com.apple.nsurlsessiond를 평범한 문장으로 바꾸는 건 그냥 번역이니까요. 이 세 가지 작업에 모델을 쓰고 그렇다고 밝히는 도구라면, 진짜 기능을 내세우고 있는 겁니다.

마지막 관문이 결정적이어야 하는 이유

삭제 결정에는 모델이 줄 수 없는 세 가지 속성이 필요합니다.

결정성. 같은 디스크, 같은 버전이면 매번 같은 답이 나와야 합니다. temperature를 0으로 둬도 이건 얻어지지 않습니다. 프롬프트 자체가 여러분 기기의 내용물을 그대로 담고 있기 때문입니다. 앱을 하나 더 설치하면 파일 목록이 바뀌고, 그 결정이 매달려 있던 토큰도 함께 바뀝니다. 내 Mac에서는 통하지만 동료의 Mac에서는 통하지 않는 안전 규칙은 안전 규칙이 아닙니다.

사전 감사 가능성. 보호 목록은 경로 접두사의 집합이라, 1분이면 전체를 읽을 수 있고 두 릴리스 사이의 차이도 비교할 수 있습니다. 가중치와 프롬프트는 무엇이 거부될지 목록으로 읽어낼 수가 없으니, 경계를 넘기 전에 그 경계가 어디인지 아무것도 보여주지 않습니다.

사후 감사 가능성. 결정적 규칙이 잘못된 것을 지우면 재현 가능한 버그가 남습니다. 여기 경로가 있고, 이걸 허용한 줄이 있고, 지금 실패하는 테스트가 있습니다. 모델이 그랬다면 남는 건 대화 기록이고, 고치는 방법은 프롬프트를 수정하는 것뿐이며, 그 수정이 다른 모든 경우에 어떤 영향을 미치는지는 측정되지 않습니다.

실패의 무게도 비대칭입니다. 순위를 잘못 매기면 스크롤 한 번 더 하면 그만이지만, ~/.claude/projects를 잘못 지우면 갖고 있던 대화 기록 전부를 잃습니다. 그러니 이건 "AI가 좋다 나쁘다"의 문제가 아니라, 파이프라인 한가운데를 가르는 문제입니다. 틀렸을 때 주의력만 소모되는 쪽은 확률적이어도 되고, 틀렸을 때 데이터를 잃는 쪽은 결정적이어야 합니다.

Mole은 어느 쪽에 서 있는가

Mole은 모델을 탑재하지도, 추론을 실행하지도 않습니다. 어떤 경로가 삭제 후보가 될 수 있는지는 앱에 고정으로 컴파일된 차단 상대 경로 접두사 배열이 결정합니다. .ollama/models, .lmstudio/models, .cache/huggingface, .cache/torch, .claude/projects, .codex/sessions, .grok/sessions, Library/Caches/com.apple.e5rt.e5bundlecache 같은 항목들이 들어 있습니다. 사용자가 편집할 수 있는 나머지 절반은 cat ~/.config/mole/whitelist로 읽을 수 있는 평범한 텍스트 파일입니다. 무료 Mole CLI는 GPL-3.0 오픈소스로 같은 목록을 적용하니, 이걸 강제하는 코드 자체가 공개돼 있습니다.

마지막 항목이 이 주장을 압축해서 보여줍니다. com.apple.e5rt.e5bundlecache는 ~/Library/Caches 안에 있고 이름에 "cache"라는 단어가 들어 있어서, 세상의 모든 휴리스틱이 이걸 지워도 되는 것으로 분류합니다. 하지만 실제로는 Apple Neural Engine 컴파일 모델이 들어 있어서, 앱이 모델을 로드한 상태에서 이걸 비우면 기기를 재시작할 때까지 인식 관련 호출이 깨집니다. 이게 보호되는 이유는 누군가 실제로 그 실패를 겪고 이 줄을 써넣었기 때문입니다.

그러니 여기 나온 어떤 도구든 실질적인 시험은 질문 하나로 충분합니다. 모델이 네 단계 중 어느 것을 수행하는가? 나열, 귀속, 순위, 설명이라면 믿을 만한 답입니다. "무엇을 지워도 안전한지 결정한다"는 답이 나오면 그다음엔 목록을 보여달라고 물어야 하고, 목록이 없다면 검토할 것도 없는 셈입니다.

2부: AI 도구가 남긴 것을 정리하는 도구들

대부분이 검색할 때 실제로 원하는 건 바로 이겁니다. 남는 흔적은 규칙이 저마다 다른 네 종류로 나뉘고, 이걸 뒤섞는 순간 사고가 납니다.

• 도구 캐시와 로그. ~/Library/Caches/claude-cli-nodejs, Cursor의 Electron 캐시, ~/.claude 아래의 원격 측정과 디버그 디렉터리. 다시 만들 수 있고 특별할 것 없습니다.
• 대화 기록과 프로젝트 상태. ~/.claude/projects, ~/.codex/sessions, ~/.grok/sessions. 스캔했을 때 가장 놀라운 크기로 나타나는 경우가 많고, 대체할 수 없습니다.
• 오래된 CLI 버전. 스스로 업데이트하는 에이전트 CLI는 이전 릴리스를 그대로 남겨둡니다. Codex 기준으로 릴리스 하나당 대략 300MB이니, 다섯 개가 쌓이면 실제로 쓰는 건 하나뿐인데 1.2GB에 이릅니다.
• 모델 가중치. ~/.ollama/models, ~/.cache/huggingface/hub, LM Studio의 모델 디렉터리. 단연 가장 크고, 다운로드한 도구가 소유합니다.

도구를 고르기 전에 먼저 측정하세요.

du -sh ~/.claude ~/.codex ~/.ollama/models ~/.cache/huggingface 2>/dev/null | sort -h

이 경로들을 이미 알고 있는 검토형 정리, Mole

Clean 도구는 먼저 스캔부터 하고, 아무것도 움직이기 전에 검토할 결과를 보여줍니다. 후보 행 하나하나가 정확한 경로, 소유자, 크기를 담고 있고, 스캐너가 확신하지 못하는 항목은 선택 해제 상태로 나타나니 기본 클릭은 항상 더 작은 쪽입니다. 삭제는 unlink가 아니라 휴지통으로 가고, 작업 하나하나가 ~/Library/Logs/mole/operations.log에 기록되는데, 여기서 TRASHED와 DELETED는 서로 다른 단어입니다.

AI 도구에 특히 중요한 동작이 두 가지 있습니다. 오래된 에이전트 CLI 버전 디렉터리는 후보로 내밀지만, 지금 쓰고 있는 릴리스는 절대 후보가 되지 않습니다. 런처가 가리키는 대상을 먼저 확인해서 고정해두기 때문에, 지금 실행 중인 버전은 버전 번호를 추측해서가 아니라 구조적으로 제외됩니다. 그리고 제거 작업은 이름 매칭이 아니라 소유권을 따지기 때문에, 한 제조사의 앱 하나를 제거해도 아직 설치된 형제 앱이 소유한 공유 Application Support 상위 폴더는 후보로 내밀지 않습니다.

작업을 실행하려면 Clean을 열고 스캔이 끝나길 기다린 뒤, 커 보이는 그룹을 펼쳐서 남기고 싶은 항목은 선택 해제하고, 정리한 다음 회수된 공간을 확인하면 됩니다. 스캔은 무료고 유료 도구는 결제 전에 두 번 무료로 써볼 수 있으니, $19를 낼 가치가 있는지 결정하기 전에 검토 과정 전체를 직접 확인할 수 있습니다.

터미널을 벗어나고 싶지 않다면, Mole CLI

별도의 무료 제품으로, GPL-3.0 오픈소스이며 brew install mole로 설치합니다. 언제나 먼저 미리보기부터 하세요.

mo clean --dry-run
mo purge --dry-run

mo clean은 캐시와 로그를 다루고, mo purge는 오래된 프로젝트 빌드 산출물을 대상으로 합니다. 파괴적인 명령어에는 모두 --dry-run이 있어서 먼저 정확한 경로 목록을 읽을 수 있습니다. Mac 앱과 같은 보호 목록과 작업 로그를 공유합니다. 플래그를 빼기 전에 알아둘 차이 하나. CLI의 캐시 정리는 파일을 영구히 삭제하지만, 제거와 잔여물 삭제는 여전히 휴지통으로 갑니다.

이 문제를 위해 만들어진 오픈소스 터미널 도구, cc-cleaner

cc-cleaner는 MIT 라이선스이고, Python 3.10 이상이 필요하며, pipx install cc-cleaner로 설치합니다. Claude Code, npm, uv, cargo, Docker, Playwright, 브라우저 캐시, 그리고 Hugging Face, PyTorch, Whisper, Ollama를 아우르는 AI/ML 모델 그룹까지 22개의 정리 도구를 담고 있습니다. cc-cleaner status는 크기 표를 출력하고, cc-cleaner clean은 인터랙티브 선택 화면을 열며, -n은 dry run입니다.

위험 등급은 명확합니다. Safe 항목은 기본으로 정리되고, Moderate와 Dangerous 항목은 --force가 있어야 합니다. README는 "대화 기록, 공유 저장소"를 Moderate 등급에 놓습니다. 나머지는 소스 코드가 말해줍니다. Ollama 정리 도구는 ~/.ollama/models 전체를 디렉터리 하나로 통째로 지우고, Hugging Face 정리 도구는 ~/.cache/huggingface/hub와 datasets에 똑같이 하며, Claude 정리 도구는 ~/.claude/projects 아래의 *.jsonl 대화 기록을 후보로 내밉니다. 삭제는 shutil.rmtree와 Path.unlink로 이뤄지니 휴지통에는 아무것도 남지 않습니다. 안전장치는 금지된 시스템 경로의 고정 집합과, 모든 대상이 홈 디렉터리 아래에 있어야 한다는 조건입니다. 사람이 작성한 결정적 목록이라는 점에서는 정확히 옳은 방식입니다. 다른 건 엄밀함이 아니라 선을 어디에 긋느냐입니다. cc-cleaner는 모델 저장소와 대화 기록을 플래그 뒤에 두고, Mole은 아예 거부합니다.

같은 영역을 메뉴 막대 앱으로 다루고 싶다면, DevCleaner

DevCleaner는 macOS 14 이상용 메뉴 막대 유틸리티로 현재 1.9.0 버전이며, Xcode DerivedData와 Gradle부터 npm과 Docker까지 23개 생태계를 다루고 Claude, ChatGPT, Cursor, Ollama, LM Studio 전용 스캐너를 갖추고 있습니다. Safe 항목은 기본으로 삭제되고, Warning 항목은 "직접 판단"이며, Danger 항목은 절대 미리 선택돼 있지 않습니다. 자격 증명과 세션 파일에는 확고한 거부 목록이 있고, 실행 중인 앱의 캐시를 건드리기 전에는 경고를 띄웁니다. 핵심 정리 기능은 무료이고 Pro는 일회성 구매나 연간 구독으로 판매되니, 현재 가격은 제조사 페이지에서 확인하세요. 삭제가 휴지통으로 가는지는 사이트에 나와 있지 않은데, 처음 실행하기 전에 물어볼 가치가 있는 부분입니다.

MacPaw도 Homebrew cask를 통해 CleanMyMac CLI를 퍼블릭 베타로 내놓고 있고, 같은 대상을 겨냥합니다. 독점 소프트웨어이고, 저장소는 소스가 아니라 이슈 트래커일 뿐이며, 동작이 여전히 바뀌는 중이라고 명시하고 있으니, 공개된 설명보다는 확인 단계에서 실제로 보여주는 내용을 읽으세요.

에이전트에게 내 디스크를 맡긴다면

마지막 방법은 정리 도구를 건너뛰고 Claude Code나 비슷한 에이전트에게 디스크를 직접 정리해달라고 하는 겁니다. 공개된 정리용 skill 중 하나를 거칠 수도 있습니다. 이 방법의 장점은 진짜고, 여기 나온 다른 어떤 도구도 갖고 있지 않습니다. 에이전트는 아무도 정리해둔 적 없는 구조에 대해서도 추론할 수 있습니다. 지난달 나온 프레임워크든, 개인용 도구 체인이든, 오직 여러분만 정리한 방식대로 배열된 홈 디렉터리든 상관없이요.

평가도 그만큼 솔직해야 합니다. 셸 명령어는 여러분의 실제 파일 시스템을 놓고 추론 시점에 생성되니, 실행되는 명령을 누군가 미리 검토한 적이 없습니다. 직접 요구하지 않으면 dry run도 없습니다. 파급 범위는 여러분의 홈 디렉터리 전체이고, 알고 보니 비어 있던 변수로 조합된 rm -rf는 오래된 실패 사례입니다. 안전망이 빠진 채로 1부의 이야기가 그대로 적용됩니다. 결정은 확률적인데 그게 곧바로 마지막 관문에 연결돼 있는 셈입니다.

거의 공짜인 안전장치가 네 가지 있습니다.

• 삭제를 직접 조합하게 하지 말고 미리보기 플래그가 있는 도구를 운전하게 하세요. 공개된 Claude Code skill 중 하나는 mo CLI를 감싸서 mo clean 전에 mo clean --dry-run을 반드시 거치게 하고, dry run 결과 전체를 출력하며, 직접 타이핑한 확인을 요구합니다. 에이전트는 대상을 고르고, 삭제는 결정적인 도구가 수행합니다.
• 권한 설정에서 rm을 미리 허용해두지 마세요. 삭제 명령은 하나씩 승인하고, 요약이 아니라 경로 자체를 읽으세요.
• 휴지통을 기본값으로 만드세요. Homebrew의 trash나 ~/.Trash로의 mv는 모든 실수를 복구 가능한 것으로 바꿔줍니다.
• 작업 범위를 한정하세요. 디렉터리 하나만 가리키게 하고, 작업 전에는 du -sh, 작업 후에는 df -h를 요구해서 회수했다는 용량이 추정이 아니라 실측이 되게 하세요.

모델 저장소는 다운로드한 도구의 몫

이 부분에서는 위에 나온 것을 포함해 범용 정리 도구를 도구로 쓰면 안 됩니다. Ollama와 Hugging Face 둘 다 모델끼리 blob을 공유하는 콘텐츠 주소 기반 저장소를 씁니다. 어떤 blob이 아직 참조되고 있는지는 그걸 소유한 도구만 압니다. ollama ls와 ollama rm <model>을 쓰거나, hf cache ls와 hf cache rm model/<repo> --dry-run을 쓰세요. blob 파일을 손으로 지우면 왜 모델이 고아가 되는지는 AI 도구 잔여물 제거하기에서 다룹니다.

도구별 비교

경계를 분명히 밝히면

Mole은 악성코드 대응 도구도, 백업 도구도 아니고, 드라이버나 VPN 구성 요소, 시스템 확장 기능을 함께 설치하는 소프트웨어에는 제조사 제거 도구를 대체할 수 없습니다. 모델 가중치나 AI 채팅 기록도 지우지 않습니다. 그러니 200GB 문제가 전부 모델 라이브러리 때문이라면, Analyze에서 그 라이브러리의 규모를 보여주고 작업은 Ollama나 LM Studio에 맡깁니다. 이건 나중에 메울 빈틈이 아니라 의도적으로 그어둔 경계입니다.

하나를 고른다면

빌드 산출물 200GB에 도구 체인이 열 개 넘게 얽혀 있는 경우. 용량은 AI와 무관한 캐시, 오래된 node_modules, DerivedData, Docker에 있습니다. 검토형 정리나 mo clean --dry-run으로 시작한 뒤, 자체 정리 명령이 필요한 저장소는 개발자 캐시 정리하기를 따라가세요. 위험 등급을 먼저 읽었다면 cc-cleaner로 두 번째 정리를 해보는 것도 좋습니다.

로컬 모델 라이브러리가 큰 경우. 가중치는 범용 정리 도구를 아예 건너뛰세요. ollama ls, hf cache ls, LM Studio의 My Models 화면만이 공유 blob을 안전하게 비울 수 있는 도구입니다. 디스크 지도로 저장소 위치를 찾고, 실제로 바꾸는 건 그걸 소유한 도구에게 맡기세요.

Cursor나 Claude Code가 디스크를 잡아먹고 있다는 걸 방금 알아챈 경우. 가장 다루기 쉬운 경우입니다. 캐시와 로그는 다시 만들어지고, 오래된 CLI 버전은 순수한 낭비이며, 대화 기록만은 건드리면 안 됩니다. 여기 나온 검토형 도구라면 어느 것이든 처리할 수 있고, 단계별 안내는 AI 코딩 도구 정리하기에 있습니다.

자주 묻는 질문

AI가 들어간 Mac 정리 도구는 일반 도구보다 더 안전하게 삭제하나요?

지금까지의 증거로는 아닙니다. 고아 폴더를 어떤 앱이 소유하는지 판단하고, 뭐가 주목할 가치가 있는지 순위를 매기는 데는 모델이 규칙을 이길 수 있습니다. 약한 신호가 많은 애매한 문제이기 때문입니다. 하지만 경로 하나를 지워도 안전한지 판단하는 데는 결정성과 감사 가능한 목록이 필요한데, 모델은 둘 다 제공하지 못합니다. 제조사에게 모델이 파이프라인의 어느 단계를 수행하는지 물어보세요. "무엇을 지워도 안전한지 결정한다"는 답이 나오면 목록을 보여달라고 요청하는 신호로 받아들이면 됩니다.

Claude Code에게 Mac 정리를 맡겨도 안전한가요?

가장 유연한 방법이면서 동시에 가장 제약이 적은 방법이기도 합니다. 명령어는 추론 시점에 생성되어 여러분의 홈 디렉터리에 대해 실행되고, 직접 요청하지 않는 한 미리보기도 없습니다. 그래도 쓰겠다면, 에이전트가 rm -rf를 직접 조합하게 하지 말고 dry-run 플래그가 있는 도구를 운전하게 하세요. 권한 설정에서 rm을 미리 허용해두지 말고, 삭제는 휴지통으로 보내고, 한 번에 디렉터리 하나로만 범위를 한정하세요.

Mac 정리 도구가 제 Ollama 모델이나 Claude Code 기록을 지울까요?

전적으로 도구에 달려 있고, 바로 그래서 가장 먼저 물어봐야 할 질문입니다. Mole은 ~/.ollama/models, ~/.lmstudio/models, ~/.cache/huggingface, ~/.claude/projects, ~/.codex/sessions, ~/.grok/sessions를 삭제 관문에서 아무리 오래됐어도 차단하니 절대 후보가 되지 않습니다. cc-cleaner는 모델 디렉터리와 Claude Code 대화 기록을 Moderate 위험으로 분류하고 --force를 넘기면 지웁니다. 도구의 위험 등급은 처음 실행한 뒤가 아니라 그 전에 읽으세요.

AI 코딩 도구를 1년 쓰고 나면 실제로 공간을 차지하는 건 뭔가요?

보통 사람들이 예상하는 캐시가 아니라 오래된 CLI 버전과 대화 기록입니다. 스스로 업데이트하는 에이전트 CLI는 릴리스 하나당 몇백 메가바이트씩 남길 수 있고, Codex 기준으로 다섯 개가 쌓이면 실제로 쓰는 건 하나뿐인데도 대략 1.2GB에 이릅니다. ~/.claude/projects 아래의 대화 기록은 조용히 쌓여서 스캔했을 때 가장 놀라게 만드는 항목이고, 바로 그래서 정리 대상에 포함시키는 게 아니라 제외해야 합니다.

관련 글

• Mac에서 Ollama와 LM Studio 모델 정리하기: 콘텐츠 주소 기반 모델 저장소의 작동 원리.
• 빌드를 망가뜨리지 않고 개발자 캐시 정리하기: 패키지 매니저 저장소와 흩어진 node_modules.
• AI 코딩 도구 정리하기: 경로별로 짚어보는 단계별 안내.