Mac에서 AI 코딩 도구가 남긴 것 정리하기

개발게시 수정 15분 읽기

2년 동안 넉넉했던 디스크가 코딩 에이전트를 매일 쓰기 시작하면 몇 달 만에 꽉 찰 수 있습니다. 에이전트 자체는 작습니다. 바뀐 건 기기가 얼마나 자주 컴파일하는지, CLI가 디스크에서 얼마나 자주 스스로를 교체하는지, 그리고 여러분의 사고 과정 자체가 얼마나 많이 텍스트로 홈 디렉터리에 남는지입니다. 늘어난 용량은 거의 다 세 범주로 나뉘고, 각각 되찾는 데 드는 비용이 완전히 다르니 서로 다른 판단이 필요합니다.

모델 가중치는 뻔한 용의자지만, 이 문제에서는 대개 엉뚱한 범인입니다. Ollama, LM Studio, Hugging Face는 자체 도구만 안전하게 정리할 수 있는 콘텐츠 주소 기반 저장소를 씁니다. 이건 AI 도구 잔여물 제거하기에서 따로 다룹니다. 이 글은 작업하는 동안 AI 코딩 에이전트가 남기는 것에 대한 이야기입니다.

지우기 전에 먼저 측정하세요

명령어 두 개면 궁금증 대부분이 풀립니다. 첫 번째는 에이전트의 홈 디렉터리 합계를 냅니다.

du -sh ~/.codex ~/.claude ~/.local/share/claude ~/.grok ~/.cache 2>/dev/null | sort -h

두 번째는 지금까지 열어본 모든 프로젝트에 흩어진 빌드 산출물을 찾아줍니다. 루트 경로는 여러분이 코드를 보관하는 위치로 바꾸세요.

find ~/www ~/Projects -maxdepth 3 -type d \
  \( -name target -o -name node_modules -o -name .next -o -name dist -o -name build \) \
  -prune -exec du -sh {} + 2>/dev/null | sort -h | tail -20

-prune은 find가 이미 매칭된 디렉터리 안으로 더 들어가지 않게 막아줍니다. 여기서는 중요한 차이를 만드는데, 이게 없으면 find는 24GB짜리 target/ 안의 파일을 전부 훑고 나서야 다음으로 넘어갑니다. 이 글을 쓰면서 실측한 Mac에서는 상위 두 줄이 Rust target/의 24GB와 Tauri 프로젝트 target/의 9.8GB였고, node_modules 트리는 134MB부터 1.5GB까지였습니다. 여기서 중요한 건 비율입니다. 의존성 문제처럼 보이던 것이 실제 수치의 2퍼센트에 불과했습니다.

이걸 목록 대신 지도로 보고 싶다면, Mole의 Analyze 화면이 같은 볼륨을 트리맵으로 그려주고 가장 큰 사각형을 파고들 수 있게 해줍니다. find에 어떤 루트를 넘겨야 할지 추측하는 것보다 빠릅니다.

첫 번째 범주: 빌드 산출물, 증폭된 형태로

이 범주 자체는 새롭지 않습니다. 새로운 건 규모입니다. 손으로 작업하는 개발자는 하루에 몇 번 컴파일합니다. 작업을 처리하는 에이전트는 거의 편집할 때마다 컴파일하고, 테스트를 돌리고, 두 번째 접근을 시도하고, 다시 컴파일합니다. 예전엔 몇 달에 걸쳐 커지던 캐시가 이제 오후 한나절 만에 커지고, 점진적 빌드 디렉터리는 애초에 디스크를 속도와 맞바꾸도록 설계돼 있습니다.

Rust는 대개 압도적으로 가장 큽니다. target/ 디렉터리는 컴파일된 의존성, 점진적 컴파일 상태, 빌드 스크립트 출력을 담는데 프로필별로 따로 보관되니 debug와 release가 각각 완전한 복사본으로 존재합니다. 옵션 없이 실행한 cargo clean은 "target 디렉터리 전체를 삭제"합니다. 먼저 미리 확인하세요.

cargo clean --dry-run
cargo clean --release

cargo clean -p <package>는 지정한 패키지만 정리합니다. 워크스페이스 구성원 하나가 문제일 때 쓰기 적합한 도구입니다.

JavaScript는 산출물을 더 넓고 얇게 퍼뜨립니다. node_modules 자체 말고도 node_modules/.cache(번들러와 트랜스파일러가 씀), Next.js 빌드용 .next, 그리고 도구 체인이 쓰는 dist나 build가 있습니다. 캐시만 콕 집어 찾으세요.

find ~/www -maxdepth 4 -type d -path '*/node_modules/.cache' -prune -exec du -sh {} + \
  2>/dev/null | sort -h | tail

Python은 임포트하는 패키지마다 옆에 __pycache__를 남깁니다. 하나하나는 작지만 수천 개씩 쌓입니다. 지우기 전에 개수부터 세어보세요. 같은 명령어 형태 끝에 rm -rf를 붙이면 루트 경로가 잘못됐을 때 되돌릴 수 없으니까요.

find ~/www -type d -name __pycache__ -prune -print | wc -l

바이트코드 캐시는 다음 임포트 때 네트워크 접속 없이도 다시 만들어지니, 이 글 전체에서 가장 안전하게 지울 수 있는 대상입니다.

Go는 프로젝트별 디렉터리 대신 전역 빌드 캐시 하나를 씁니다. go env GOCACHE가 그 위치를 출력하고, go clean -cache는 "go 빌드 캐시 전체를 삭제"합니다. go clean -testcache는 컴파일된 패키지는 남긴 채 캐시된 테스트 결과만 만료시킵니다. 제 기기에서는 빌드 캐시가 183MB, 모듈 캐시가 38MB였습니다. 다운로드한 모듈이 작아도 빌드 쪽은 확인할 가치가 있습니다.

Xcode는 따로 다뤄야 합니다. DerivedData, 아카이브, 기기 지원, 시뮬레이터 런타임은 네 가지 서로 다른 종류이고 복구 비용도 제각각이기 때문입니다. 이 Mac에서 DerivedData 폴더는 9.3GB였습니다. Xcode 저장 공간 정리하기에서 어떤 걸 지워도 되고 어떤 걸 심볼화를 위해 남겨야 하는지 다룹니다. Gradle과 Maven도 프로젝트별 build/ 디렉터리와 ~/.gradle이나 ~/.m2 아래의 전역 저장소로 똑같이 나뉘고, 전역 쪽은 개발자 캐시 정리하기에 나오는 다른 레지스트리들과 함께 다룹니다.

두 번째 범주: 더 이상 쓰지 않는 CLI 버전

이건 거의 아무도 찾아볼 생각을 하지 않는 범주인데, 에이전트를 여러 개 돌리는 기기에서는 흔히 모든 캐시를 합친 것보다 더 큽니다.

에이전트 CLI는 버전이 붙은 완전한 새 릴리스를 통째로 다운로드하고 런처가 그걸 가리키게 만드는 방식으로 스스로를 업데이트합니다. 릴리스마다 독립적이라 이전 릴리스와 파일을 하나도 공유하지 않습니다. 포인터는 옮겨가지만, 오래된 릴리스는 그대로 남습니다. 아무것도 그걸 쓸어가지 않으니, 업데이트할 때마다 개수가 하나씩 늘어나고, 이게 영원히 계속됩니다.

레이아웃은 겉모습만 다를 뿐 하나의 패턴을 따릅니다.

  • Codex는 ~/.codex/packages/standalone/releases/<version>-<arch>/에 보관하고, 한 단계 위에 있는 current 심볼릭 링크가 현재 쓰는 버전을 가리킵니다.
  • Claude Code는 ~/.local/share/claude/versions/<version>에 보관하는데, 각 항목은 디렉터리가 아니라 실행 파일 하나이고, ~/.local/bin/claude가 현재 버전을 가리키는 심볼릭 링크입니다.
  • Grok은 ~/.grok/downloads/grok-<version>-macos-<arch>를 파일로 보관하고, ~/.grok/bin/grok과 ~/.grok/bin/agent가 현재 빌드를 가리킵니다.
  • Cursor Agent는 ~/.local/share/cursor-agent/versions/<date>-<sha>/에 보관하고, ~/.local/bin/cursor-agent가 런처입니다.
  • GitHub Copilot CLI는 npm으로 설치하면 제자리에서 스스로를 교체하지만, 설치 스크립트는 root가 아닌 사용자라면 기본값 $HOME/.local 아래 접두사에 버전이 붙은 패키지를 씁니다. Mole은 같은 형태로 ~/.copilot/pkg/universal을 확인합니다.

한 번에 전부 측정하세요.

du -sh ~/.codex/packages/standalone/releases/* \
       ~/.local/share/claude/versions/* \
       ~/.grok/downloads/* \
       ~/.local/share/cursor-agent/versions/* 2>/dev/null

이 글을 쓰면서 쓴 Mac에서는 262MB에서 310MB 사이의 Codex 릴리스 다섯 개, 293MB에서 306MB 사이의 Claude Code 바이너리 다섯 개, Grok 빌드 두 개, Cursor Agent 버전 두 개가 나왔습니다. 합쳐서 대략 3.5GB였고, 그중 실제로 쓰는 건 약 920MB뿐이었습니다. 나머지는 전부 이미 교체된 바이너리였습니다. Codex 자체 이슈 트래커에도 이걸 다루는 미해결 요청이 있는데, 제보자는 업데이트당 대략 250MB씩 늘어난다고 측정했습니다(openai/codex#22293).

디렉터리를 하나라도 지우기 전에 먼저 런처부터 확인하세요

날짜순으로 정렬해서 가장 최근 것만 남기고 싶은 유혹이 들 수 있습니다. 그러지 마세요. 흔히 있는 두 가지 상황이 이 방식을 무너뜨립니다. 회귀가 생긴 뒤 일부러 오래된 버전을 고정해뒀거나, 업데이트가 포인터를 옮기기 전에 새 디렉터리부터 미리 만들어둔 경우입니다. 현재 쓰고 있는 릴리스를 지우면 런처가 아무것도 가리키지 않게 됩니다.

대신 런처에게 물어보세요. 심볼릭 링크이니 실제 경로를 확인하면 됩니다.

readlink -f "$(command -v codex)"
readlink -f "$(command -v claude)"
readlink -f "$(command -v grok)"

이렇게 하면 실제 대상, 예를 들면 ~/.codex/packages/standalone/releases/0.147.0-aarch64-apple-darwin/bin/codex 같은 경로가 나오고, ls -l "$(command -v codex)"는 최종 답 대신 거쳐가는 단계를 하나씩 보여줍니다. 여기서 나온 결과가 바로 현재 쓰는 버전입니다. 그 경로에 없는 나머지 형제 디렉터리는 전부 더 이상 쓰지 않는 것이고, 휴지통으로 보내도 안전합니다. 휴지통을 비우기 전에 CLI를 한 번 실행해서 런처가 여전히 제대로 해석되는지 확인하세요.

PATH 위의 런처 심볼릭 링크가 current 포인터를 거쳐 릴리스 디렉터리 하나로 이어지는 모습, 옆에 있는 형제 릴리스 디렉터리들은 참조되지 않아 삭제해도 안전함
타임스탬프가 아니라 런처가 현재 쓰는 릴리스를 알려줍니다. 고정해둔 다운그레이드와 절반만 끝난 업데이트 둘 다 가장 최근 디렉터리를 오답으로 만듭니다.

세 번째 범주: 에이전트 작업 상태, 정크가 아닌 것

세 번째 범주는 정리 도구가 실제로 피해를 줄 수 있는 곳입니다. 앞의 두 범주와 겉모습이 똑같기 때문입니다.

세션 대화 기록, 메모리, 계획, 생성된 첨부 파일은 ~/.codex/sessions, ~/.codex/archived_sessions, ~/.codex/memories, ~/.claude/projects, ~/.grok/sessions 아래에 있습니다. 세션 id로 이름 붙은 JSONL 파일이고, 타임스탬프가 찍혀 있고, 추가만 되며, 계속 커집니다. 범용 정리 도구의 모든 휴리스틱은 이걸 로그 파일이라고 말합니다. 실측한 Mac에서 ~/.codex/sessions는 9.8GB, ~/.claude/projects는 대화 기록 파일 2,362개에 걸쳐 2.7GB, ~/.grok/sessions는 1.3GB였습니다. 지워도 될 것처럼 보이는 파일들에 붙은, 크고 유혹적인 숫자입니다.

이건 로그가 아닙니다. 대화 기록은 어떤 변경이 어떻게 도출됐는지에 대한 기록입니다. 시도했다가 버려진 접근법, 하나를 탈락시킨 제약, 최종 형태가 그렇게 된 이유. 그 추론은 다른 어디에도 존재하지 않습니다. 커밋 메시지는 뭐가 바뀌었는지만 기록하고, 코드는 살아남은 선택지만 남길 뿐 버려진 네 가지는 기록하지 않습니다. 몇 달치가 조용히 쌓이다가, 왜 그렇게 만들었는지 되짚어 물어보러 돌아가는 그 순간 처음으로 이 가치를 발견하게 됩니다.

더 큰 위험은 서드파티 정리 도구가 아닙니다. Claude Code 자체에 보관 기간 정리 기능이 있습니다. cleanupPeriodDays의 기본값은 30일이고, 시작할 때 projects/ 아래의 대화 기록, 계획 파일, file-history/의 편집 전 스냅샷, 세션별 작업 목록 중 그보다 오래된 것을 지웁니다. .claude 디렉터리 참조 문서에 어떤 경로가 정리되고 어떤 경로는 무기한 보관되는지 정확히 나와 있습니다. 1년치 대화 기록을 원한다면, 나중에 기본값을 알게 되기 전에 지금 그 숫자부터 늘려두세요. 같은 페이지에는 반대의 경우, 즉 특정 프로젝트의 상태를 의도적으로 지우고 싶을 때 쓰는 claude project purge도 나와 있습니다.

Mole은 이 중 무엇도 절대 건드리지 않습니다. 앞의 다섯 경로에 ~/.claude/file-history, ~/.claude/plans, ~/.claude/tasks, ~/.codex/attachments, ~/.codex/generated_images까지 더한 목록이 나이와 상관없이 보호 목록에 올라가 있습니다. 나이 기준도, "90일 이상"이라는 예외도, 그걸 켜는 설정도 없습니다. 이 경로들에 나이 기준 예외를 넣은 적이 한 번 있었는데 그날 바로 되돌렸습니다. 오래된 대화 기록이 낡은 대화 기록인 건 아니니까요.

핵심 원리: 크기가 아니라 복구 비용으로 정렬하기

이게 세 범주 전부를 판단 가능하게 만드는 규칙이고, 이 글에서 외워둘 가치가 있는 유일한 내용입니다. 후보를 몇 기가바이트인지가 아니라 되찾는 데 얼마가 드는지로 순위를 매기세요.

로컬에서 다시 만들 수 있음. 빌드 산출물, 점진적 컴파일 상태, 바이트코드 캐시, DerivedData. 이런 걸 지우는 대가는 지금 앉아 있는 바로 그 기기에서 몇 분의 CPU 시간이 드는 것뿐이고, 네트워크는 필요 없습니다. 마음껏 지우세요, 가장 큰 것부터 별생각 없이 지워도 됩니다.

다시 만드는 비용이 큼. 패키지 레지스트리, node_modules, CocoaPods, Python 가상 환경, vendor 디렉터리, 모델 가중치, iOS DeviceSupport. 이런 것들은 모두 네트워크가 필요하고, lockfile이 명시한 정확한 버전을 여전히 제공하는 레지스트리가 필요하고, 때로는 네이티브 도구 체인까지 필요합니다. 진짜 비용은 좋은 연결 상태에서 몇 분 걸리느냐가 아니라, 기차 안에서 아예 작업할 수 있느냐 없느냐입니다. 이런 건 하나씩 검토하세요.

대체 불가능. 채팅 대화 기록, 에이전트 메모리, 계획 파일, 프로젝트 상태, 로컬 파인튜닝. CPU나 대역폭을 아무리 들여도 이런 건 되찾을 수 없습니다. 일괄 삭제에 절대 포함되면 안 되고, 실수로 선택될 수 있는 종류의 항목이어서도 안 됩니다.

함정은 1단계와 2단계가 똑같아 보인다는 겁니다. target/과 node_modules/는 둘 다 프로젝트 루트에 있는 큰 디렉터리고, 둘 다 의존성 산출물로 가득하고, 둘 다 .gitignore에 올라가 있고, 둘 다 명령어 하나로 다시 만들어집니다. 크기순으로 정렬하면 나란히 붙어 있습니다. 하지만 cargo build는 이미 디스크에 있는 소스로 target/을 재구성하는 반면, npm ci는 레지스트리가 여전히 살아 있고 lockfile이 여전히 해석돼야 합니다. 하나는 커피 한 잔 마실 시간이면 끝나고, 다른 하나는 오후가 통째로 막히거나 다시 설치할 수 없게 회수된 패키지를 만날 수도 있는 일입니다. 이 둘을 뒤섞는 게 이 범주에서 가장 흔한 실수이고, 그래서 "가장 큰 폴더부터 지워라"가 가장 많은 공간을 확보해줄 때조차 나쁜 조언인 이유입니다.

복구 비용으로 순위를 매긴 세 단계, target과 node_modules는 프로젝트 디렉터리로서 겉모습은 똑같아 보이지만 하나는 로컬 소스에서 재구성되고 다른 하나는 레지스트리가 필요해서 서로 다른 단계에 놓임
크기는 후보의 순위를 엉뚱하게 매깁니다. 프로젝트 루트에서 똑같아 보이는 두 디렉터리도 복구 비용에서는 하루 작업 전체만큼 차이가 날 수 있습니다.

Mole로 이 작업 하기

수동으로 하는 방법은 잘 통하고 비용도 들지 않습니다. Mole이 더해주는 건 세 범주 전부가 이미 단계 구분이 적용된 하나의 검토 목록으로 나타난다는 점입니다. 어떤 점 디렉터리에 대화 기록이 들어 있는지 여러분이 직접 외우고 있을 필요가 없습니다.

Clean 도구를 열고 스캔을 실행하세요. 스캔은 무료고 라이선스도 필요 없습니다. 모든 후보는 정확한 경로, 소유자, 실측 크기와 함께 나타나고, 여러분이 목록을 승인하기 전까지는 아무것도 움직이지 않습니다. 확신이 낮은 항목은 선택 해제 상태로 나타나니 기본 동작은 항상 더 작은 쪽입니다. 삭제는 unlink가 아니라 휴지통으로 가서, 실수했을 때 백업 복원 대신 그냥 도로 꺼내면 되고, 일괄 작업은 지운 것만이 아니라 건너뛴 것과 실패한 것도 보고합니다.

더 이상 쓰지 않는 CLI 버전에 대해서는 Mole이 앞서 설명한 런처 확인 작업을 대신 해줍니다. 각 에이전트 CLI의 런처 심볼릭 링크를 읽어서 현재 쓰는 릴리스로 해석하고, 그 릴리스는 후보 목록에서 제외합니다. 그러니 의도적인 다운그레이드는 오래된 버전으로 취급되지 않고 그대로 유지됩니다. 이 동작 뒤에는 Codex에서 측정한 실제 사례가 있습니다. 릴리스 다섯 개가 1.2GB인데 실제로 쓰는 건 하나뿐이었습니다.

Mole CLI는 무료 오픈소스이고, 셸에서 mo clean으로 같은 작업을 다룹니다. 파괴적인 명령어마다 --dry-run이 있어서 무엇이 움직이기 전에 전체 경로 목록을 읽을 수 있습니다. 둘 다 ~/.config/mole/whitelist의 보호 목록 하나와 ~/Library/Logs/mole/operations.log의 작업 로그 하나를 공유하고, 모든 작업은 업로드도 원격 측정도 없이 로컬에서만 이뤄집니다.

Mole의 Clean 화면이 검토형 정리를 보여주며 각 후보를 경로와 크기로 나열하고, 작업 후 실제로 회수한 공간을 보고하는 모습
탐색과 삭제는 서로 다른 두 단계입니다. 완료 화면은 스캔 전에 추정한 값이 아니라 실제로 회수한 값을 보고합니다.

분명히 밝혀둘 것: Mole은 백업 도구도, 악성코드 대응 도구도 아니고, 드라이버나 시스템 확장 기능을 함께 설치하는 소프트웨어에는 제조사 제거 도구를 대체할 수 없습니다. 모델 가중치나 AI 채팅 기록도 지우지 않고, 지우겠다고 제안하지도 않습니다. 이런 건 그걸 소유한 도구에게 맡겨둡니다.

다시 쌓이지 않게 하려면

설정 세 가지만 바꾸면 다시 쌓이는 걸 대부분 막을 수 있습니다.

Rust가 빌드 디렉터리 하나만 쓰게 하세요. CARGO_TARGET_DIR은 "생성된 모든 산출물을 놓을 위치"를 정합니다. 그러면 모든 프로젝트가 한 곳의 트리에 쓰게 되니 측정도 정리도 한 곳에서 할 수 있습니다. 대가는 실재합니다. Cargo는 빌드 디렉터리를 잠그니, target 디렉터리 하나를 공유하는 프로젝트 두 개는 병렬이 아니라 하나씩 빌드됩니다. 동시 빌드를 자주 돌린다면 따로 두고 대신 정리 일정을 잡으세요.

전역 저장소는 손으로 정리하지 말고 정책에 맡기세요. 최신 Cargo는 일반적인 build와 fetch 명령을 실행하는 동안 이미 전역 캐시에서 쓰지 않는 항목을 지웁니다. npm도 자체 캐시를 자가 복구된다고 설명하며 npm cache verify를 유지보수 명령으로 제공합니다. 홈 디렉터리의 점 폴더를 통째로 지우는 대신 이런 정책이 알아서 돌아가게 두세요. 도구별 명령어는 개발자 캐시 정리하기에 있습니다.

에이전트 CLI가 자체 릴리스를 정리하는지 확인하고, 안 그런다고 가정하세요. 이 글을 쓰는 시점 기준으로 Codex나 Claude Code 어느 쪽에서도 더 이상 쓰지 않는 릴리스 바이너리를 정리하는 문서화된 플래그나 설정 키를 찾지 못했고, Codex 쪽 요청은 여전히 미해결 상태입니다. Claude Code의 cleanupPeriodDays는 세션 데이터를 정리할 뿐 버전 바이너리는 다루지 않으니 여기서는 도움이 되지 않습니다. 바뀌기 전까지는 계속 반복되는 작업이고, 이 목록에서 가장 가치가 큰 항목이기도 합니다. 에이전트가 업데이트를 내놓는 속도만큼 계속 다시 생기니까요.

자주 묻는 질문

AI 코딩 도구는 실제로 디스크를 얼마나 쓰나요?

바이너리 하나하나는 몇백 메가바이트지만, 중요한 건 그게 쌓인다는 겁니다. 이 글을 위해 측정한 기기에서는 에이전트 CLI 네 개가 버전 디렉터리에 걸쳐 약 3.5GB를 차지했는데 그중 실제로 쓰는 건 920MB뿐이었고, 세션 대화 기록은 약 14GB, Rust target/ 디렉터리 하나만 24GB였습니다. 여러분의 수치는 에이전트보다 사용 언어에 따라 더 크게 달라지니, 이 글의 숫자를 포함해 누구의 수치도 믿지 말고 이 글 맨 위에 있는 du 명령어 두 개를 직접 돌려보세요.

오래된 Claude Code나 Codex 버전을 지워도 안전한가요?

네, 먼저 런처부터 확인한다면요. readlink -f "$(command -v claude)"나 여러분이 쓰는 CLI에 맞는 명령을 실행해서 출력된 경로는 남겨두고 나머지 형제는 휴지통으로 보내세요. 날짜순으로 정렬해서 가장 최근 것만 남기지는 마세요. 고정해둔 다운그레이드나 절반만 끝난 업데이트 둘 다 가장 최근 디렉터리를 오답으로 만듭니다. 지운 뒤 휴지통을 비우기 전에 CLI를 한 번 실행해 보세요.

Mac 정리 도구가 제 에이전트 대화 기록을 지울까요?

일부는 그럴 겁니다. 이 파일들이 로그와 똑같이 생겼기 때문입니다. 바로 이게 이 범주의 구체적인 위험입니다. Mole은 ~/.codex/sessions, ~/.codex/archived_sessions, ~/.codex/memories, ~/.claude/projects, ~/.grok/sessions를 나이와 상관없이 절대 건드리지 않습니다. 어떤 정리 도구든 실행하기 전에 이런 경로가 후보 목록에 나타나는지 확인하세요. 실행하기 전에 목록을 보여주지 않는 도구라면, 그게 곧 답입니다.

빌드 캐시를 지우면 뭔가 느려지나요?

다음 빌드 딱 한 번만, 그 뒤로는 아닙니다. 점진적 컴파일 상태는 두 번째 빌드를 첫 번째보다 빠르게 만들려고 존재하는 것이니, 지우면 프로젝트당 정확히 한 번의 콜드 빌드라는 대가만 치르면 됩니다. 그게 단점의 전부이고, 그래서 빌드 산출물은 마음껏 지워도 되는 단계에 속하지만 레지스트리를 다시 오가야 하는 node_modules 트리는 그렇지 않은 겁니다.

Ollama 모델이나 Hugging Face 캐시는 어떻게 하나요?

이 글의 범위 밖이고, 의도적으로 그렇습니다. 이 도구들은 모델 두 개가 같은 blob을 공유할 수 있는 콘텐츠 주소 기반 저장소를 쓰기 때문에, 파일을 손으로 지우면 여전히 그걸 참조하는 모델이 고아가 될 수 있습니다. 각 도구 자체의 제거 명령을 쓰세요. AI 도구 잔여물 제거하기에서 다룹니다.

다음으로 볼 것

복구 비용으로 정렬하고, 릴리스를 지우기 전에 런처부터 확인하고, 대화 기록은 그대로 두세요. 측정 결과 가장 큰 줄이 패키지 저장소였다면, 개발자 캐시 정리하기에 도구별 정리 명령어가 있습니다. Xcode였다면, Xcode 저장 공간 정리하기가 다시 만들 수 있는 폴더와 남겨야 할 아카이브를 구분해줍니다. 모델 저장소였다면, AI 도구 잔여물 제거하기에서 왜 그걸 소유한 도구가 직접 지워야 하는지 설명합니다.