npm Cache와 node_modules가 Mac에서 공간을 차지한다면? 안전하게 정리하는 방법

npm cache와 오래된 node_modules 폴더가 Mac에서 공간을 차지하고 있다면, 먼저 공유 npm cache와 프로젝트 로컬 종속성을 구분하세요. 캐시를 지우기 전에 내용을 검토하고, 재설치할 준비가 되었거나 해당 프로젝트가 더 이상 필요하지 않을 때만 오래된 node_modules 폴더를 삭제하세요.

이 구분이 중요한 이유는 npm cache와 node_modules가 서로 다른 문제를 해결하기 때문입니다. 두 가지는 정리 시 서로 다른 결과를 초래합니다.

하나는 재사용 가능한 패키지 캐시이고, 다른 하나는 프로젝트가 실제로 실행되는 종속성 트리입니다. 이 둘을 하나의 일회용 덩어리처럼 취급하는 것이 개발자들이 공간을 빠르게 확보한 뒤 잘못된 환경을 복구하느라 시간을 낭비하는 흔한 원인입니다.

빠른 요약

npm cache와 node_modules가 Mac에서 빠르게 커지는 이유

JavaScript 개발자의 컴퓨터에서는 하나의 프로젝트만으로 스토리지가 늘어나는 경우가 드뭅니다. 실제 패턴은 누적입니다.

여러 앱, 브랜치, 프로토타입, 클라이언트 저장소에 걸쳐 패키지를 설치합니다. npm은 매번 모든 것을 처음부터 다운로드하지 않아도 되도록 재사용 가능한 캐시를 유지합니다. 각 프로젝트도 자체 로컬 종속성 트리를 node_modules에 보관합니다.

즉, 디스크 사용량은 두 방향에서 동시에 증가할 수 있습니다:

• 새로운 패키지와 버전을 설치할수록 계속 확장되는 공유 npm cache;
• 각각 자체 node_modules 트리를 가진 여러 프로젝트 폴더;
• 오래된 저장소에 걸쳐 중복되거나 거의 중복된 종속성;
• 기술적으로 일회용이더라도 재구축 비용을 추가하는 네이티브 모듈과 도구 체인 패키지;
• 제대로 보관되거나 삭제되거나 깔끔하게 재설치된 적이 없는 오래된 프로젝트.

결과는 익숙할 것입니다. 하나의 저장소는 성가신 수준이지만, 열 개의 저장소는 비용이 많이 들고, 1년간의 정상적인 작업은 조용한 스토리지 문제로 변합니다.

npm Cache vs node_modules: 차이점은 무엇인가요?

이것이 가장 중요한 구분입니다.

npm 공식 문서에 따르면, 캐시 파일은 Posix 시스템에서 기본적으로 ~/.npm에 저장되며, 로컬 설치는 현재 패키지 루트 아래 ./node_modules에 들어갑니다. npm은 먼저 패키지를 캐시에 로드한 다음, 이를 필요로 하는 프로젝트의 node_modules에 압축을 풉니다.

그래서 “npm이 공간을 차지한다”는 말은 대개 너무 모호하여 실행 가능한 정보가 되지 못합니다. 압박이 공유 캐시에서 오는지, 오래된 프로젝트 설치에서 오는지, 아니면 둘 다인지 알아야 합니다.

npm 공식 문서가 시사하는 것

npm cache는 프로젝트의 작업 종속성 트리가 아니라 캐시로 설계되었습니다. npm은 나중에 다시 채울 수 있는 캐시로 명시적으로 문서화하고 있습니다.

node_modules는 다릅니다. 이 폴더는 프로젝트의 패키지, 실행 파일, 로컬 종속성 그래프가 실제로 존재하는 곳입니다. 이를 제거하면 단순히 캐시를 지우는 것이 아니라 프로젝트가 현재 사용 중인 설치된 종속성을 제거하는 것입니다.

Mac에서 npm cache를 삭제해도 안전한가요?

대개 안전하지만, 이유가 중요합니다.

npm 공식 문서에서는 캐시가 무결성 검증되며, 캐시 삭제는 목적이 디스크 공간을 확보할 때만 필요하다고 명시합니다. 이것이 중요한 관점의 차이입니다. npm cache는 소중한 상태로 취급해서는 안 되지만, 존재한다고 해서 정기적으로 지워야 하는 것도 아닙니다.

안전한 사고방식은 다음과 같습니다:

• Mac의 공간이 부족하다면, 캐시 정리는 합리적인 타협이 될 수 있습니다;
• 설치가 정상적으로 작동하고 있다면, 캐시를 지우는 것은 불필요한 경우가 많습니다;
• 캐시를 지운다면, 이후 설치에서 패키지를 다시 다운로드해야 한다는 점을 예상하세요;
• 먼저 캐시 상태만 확인하고 싶다면 npm cache verify를 사용하세요.

더 나은 첫 번째 단계: 정리 전에 먼저 확인

npm은 기존 캐시 내용에 대한 오프라인 검증 단계로 npm cache verify를 문서화하고 있습니다. 공간을 확보하기 전에 더 낮은 위험의 확인을 원할 때 더 나은 첫 번째 명령어입니다.

npm cache verify

목적이 특히 디스크 공간을 확보하는 것이라면, npm이 문서화한 정리 명령어는 다음과 같습니다:

npm cache clean --force

--force 플래그는 의도적으로 설계된 것입니다. npm은 캐시 삭제를 일상적인 유지 관리 습관이 아닌 의도적인 디스크 공간 결정으로 취급합니다.

Mac에서 node_modules를 삭제해도 안전한가요?

때로는 안전하지만, 여기서는 상황이 훨씬 더 중요합니다.

node_modules를 삭제하면 해당 프로젝트의 로컬 종속성 트리가 제거됩니다. 프로젝트가 활성 상태라면 즉각적인 결과는 대개 명확합니다. 스크립트가 패키지를 찾지 못하고, node_modules/.bin의 로컬 바이너리가 사라지며, 다음 설치나 빌드가 예상보다 오래 걸릴 수 있습니다.

그렇다고 절대 제거하지 말라는 뜻은 아닙니다. 의도적으로 제거하라는 뜻입니다.

node_modules 삭제에 좋은 후보:

• 더 이상 활발하게 실행하지 않는 오래된 프로젝트;
• 나중에 다시 빌드할 수 있는 오래된 데모나 프로토타입;
• 어차피 깔끔하게 재설치하려고 하는 저장소;
• 재설치가 예상되고 수용 가능한 신뢰할 수 있는 lockfile이 있는 프로젝트.

위험이 더 높은 상황:

• 마감일, 데모 또는 릴리스 빌드 직전의 활성 작업 저장소;
• 재구축에 시간이 걸리는 네이티브 모듈이 있는 프로젝트;
• 몇 달 동안 건드리지 않아 빠르게 복원하는 방법을 기억하지 못할 수 있는 작업 공간;
• 깔끔한 종속성 체계나 예상되는 lockfile이 없는 저장소.

오래된 node_modules 폴더가 그렇게 큰 피해를 주는 이유

하나의 프로젝트는 관리 가능할 수 있습니다. 실제 낭비는 여러 개를 가지고 있을 때 발생합니다.

모든 오래된 저장소는 전체 종속성 트리, 패키지 매니저 메타데이터, 선택적 네이티브 패키지, 프레임워크 도구 체인, 버전별 아티팩트를 보관할 수 있습니다. 그래서 개발자들은 종종 npm이 문제라고 생각하지만, 실제로 더 큰 원인은 사용하지 않는 저장소에 흩어진 잊혀진 node_modules 폴더 더미인 경우가 많습니다.

수동으로 npm cache를 정리하는 방법

수동 방법을 원한다면, 범위를 좁고 명확하게 유지하세요.

1. 활성 캐시 디렉토리 확인

어느 시점에서 npm 설정을 변경했다면, 캐시가 기본 위치에 없을 수 있습니다. 먼저 npm에 물어보세요:

npm config get cache

2. 삭제하기 전에 캐시 확인

먼저 문서화된 검증 단계를 사용하세요:

npm cache verify

3. 실제로 공간이 필요할 때만 캐시 정리

디스크 공간을 확보하는 것이 이후 재다운로드 비용을 감당할 만하다면:

npm cache clean --force

4. 필요하면 크기 다시 확인

캐시 경로를 알면 크기를 직접 확인할 수 있습니다:

du -sh "$(npm config get cache)"

이것이 더 안전한 순서입니다. 위치, 검증, 정리를 별도의 결정으로 분리하기 때문입니다.

삭제 전에 오래된 node_modules 폴더를 찾는 방법

이것이 대개 더 가치 있는 정리 작업입니다.

더 이상 활발하게 빌드하지 않는 프로젝트부터 시작하세요. 이것이 Finder에서 맥락 없이 가장 큰 폴더 하나를 쫓는 것보다 중요합니다.

다음과 같은 검토 순서를 사용하세요:

1. 메인 프로젝트 디렉토리에서 node_modules 폴더를 검색합니다.
2. 어떤 저장소가 오래되었거나, 보관되었거나, 재설치하기 쉬운지 확인합니다.
3. 프로젝트가 이번 주에도 로컬에서 실행할 필요가 있는지 확인합니다.
4. 재구축 비용을 이해하는 node_modules 폴더만 삭제합니다.

터미널을 이용한 검토를 원한다면, 삭제하기 전에 폴더의 실제 위치를 보여주는 명령어를 사용하세요:

find ~/Projects -type d -name node_modules -prune -print
find ~/Projects -type d -name node_modules -prune -exec du -sh {} +

여전히 수동적이지만, 거대한 작업 폴더 하나에 감정적으로 반응하는 것보다 낫습니다.

프로젝트의 node_modules를 삭제하기 전에 검토할 것

• 저장소가 여전히 활성 상태인가요?
• 예상되는 lockfile이 있나요?
• 재설치를 느리게 만드는 네이티브 모듈이나 코드 생성 단계가 있나요?
• 프로젝트가 가볍게 건드리고 싶지 않은 모노레포나 워크스페이스 설정의 일부인가요?
• node_modules만 제거하는 것보다 전체 사용하지 않는 프로젝트를 보관하거나 삭제하는 것이 더 나은 정리 방법이 아닌가요?

대개 가장 강력한 정리 행동은 “모든 곳의 종속성을 지우는 것”이 아닙니다. “더 이상 필요 없는 오래된 프로젝트를 삭제하는 것”입니다.

yarn, pnpm, Bun cache는 어떤가요?

이 부분은 npm과 분리해서 생각하세요.

프로젝트가 다른 패키지 매니저를 사용한다면, npm 명령어가 그대로 적용된다고 가정하지 말고 해당 패키지 매니저의 자체 정리 모델을 사용하세요.

Yarn

최신 Yarn은 yarn cache clean을 공유 캐시 파일을 제거하는 명령어로 문서화합니다. 또한 더 넓은 정리 범위를 위해 --mirror와 --all 옵션도 제공합니다.

yarn cache clean

pnpm

pnpm은 npm의 정확한 캐시 패턴 대신 스토어 모델을 사용합니다. pnpm 공식 문서는 pnpm store prune을 스토어에서 참조되지 않는 패키지를 제거하는 것으로 설명하며, 향후 설치 시 필요하면 제거된 패키지를 다시 다운로드할 수 있다고 명시합니다.

pnpm store prune

Bun

Bun은 기본적으로 ~/.bun/install/cache에 글로벌 패키지 캐시를 문서화합니다. 또한 패키지가 다운로드 후 node_modules에 복사되므로, 폴더 크기만 보면 Bun도 “캐시 + 프로젝트 설치” 혼란을 만들 수 있다고 명시합니다.

중요한 것은 모든 명령어를 외우는 것이 아닙니다. 스토리지 모델을 혼동하지 않는 것입니다. npm cache, Yarn cache, pnpm store, Bun cache는 관련된 문제이지 동일한 문제가 아닙니다.

생태계별로 검토할 때 개발자 정리가 더 안전한 이유

node_modules가 Mac에서 유일한 개발자 스토리지 문제인 경우는 거의 없습니다. 대개 Xcode 데이터, 시뮬레이터 스토리지, Docker 이미지, 빌드 캐시, 로그, 기타 도구 체인별 경로 옆에 자리 잡고 있습니다.

일반 파일 브라우저는 폴더가 크다는 것을 보여줍니다. 하지만 다음 중 어느 것인지는 알려주지 않습니다:

• 재구축 가능한 npm cache;
• 활성 작업 공간의 종속성 트리;
• pnpm store;
• Docker cache;
• 또는 프로젝트 근처에 있을 뿐인 다른 생태계.

그래서 워크플로우가 생태계를 인식하는 상태로 유지될 때 개발자 정리가 더 잘 작동합니다.

실제 상황이 “npm + Docker + 오래된 Xcode 데이터 + 너무 많은 유휴 저장소”라면, 폴더를 하나씩 쫓는 것보다 더 넓은 검토 우선 모델이 더 유용합니다.

핵심 요약

npm cache와 node_modules가 Mac에서 공간을 차지하고 있다면, 동일한 정리 대상으로 취급하지 마세요.

공유 캐시에는 npm cache verify를 사용하고, 실제 목적이 공간 확보일 때 npm cache clean --force를 사용하세요. 오래된 node_modules 폴더는 프로젝트별로 검토하고, 재설치 비용을 이해할 때만 삭제하세요.

이것이 더 안전한 방법입니다. 캐시와 작업 공간 상태를 분리하고, 활성 프로젝트보다 오래된 프로젝트를 먼저 검토하고, 맹목적인 폴더 삭제 대신 생태계 맥락에 연결된 개발자 정리를 유지하세요.