Mole CLI 또는 Mole for Mac

Mole 소개게시 2026년 7월 25일수정 2026년 8월 8일7분 읽기

Mole는 두 가지 프로그램으로 제공됩니다. mo는 Homebrew로 설치하는 무료 오픈소스 커맨드라인 도구이며 GPL-3.0 라이선스입니다. Mole for Mac은 유료 네이티브 앱으로, 다섯 개의 탭과 메뉴 바 표시를 갖습니다. 이 둘은 체험판과 프로 버전의 관계가 아닙니다. 겹치는 일을 하면서도 디스크상의 작은 공유 계층을 둔 별도 구현이므로, 하나를 선택해도 다른 하나를 쓸 수 없게 되지 않습니다. 이 글은 이미 쓰는 방식에 맞는 쪽을 고르는 안내이며, 둘 다 쓸 때 어떤 일이 일어나는지도 설명합니다.

둘이 공유하는 것

CLI 명령 다섯 개는 앱의 다섯 탭과 직접 대응합니다. mo clean, mo uninstall, mo optimize, mo analyze, mo status가 각각 Clean, Software, Optimize, Analyze, Status에 해당합니다. 카테고리도 양쪽에서 알아볼 수 있습니다. 사용자·개발자·브라우저·시스템 캐시 계열, 앱 인벤토리와 잔여 항목 탐색, 디스크 분석, 상태 지표가 겹칩니다. 구현과 정확한 후보 집합은 동일하지 않습니다.

스캔은 양쪽 모두 무료입니다. 앱은 삭제 쪽에만 요금을 받으며, 각 삭제 도구는 라이선스 없이 두 번 사용할 수 있어 같은 Mac에서 앱 스캔과 CLI 스캔을 비용 없이 비교할 수 있습니다.

더 흥미로운 겹침은 디스크에 있습니다. 둘 다 ~/.config/mole/whitelist와 ~/.config/mole/whitelist_optimize에 쓰고, ~/Library/Logs/mole/operations.log에 이어 붙입니다. 한쪽에서 보호한 캐시는 다른 쪽에서도 보호되고, 어느 쪽에서 삭제하든 같은 파일에 기록이 남습니다. 두 프로그램은 런타임에 서로를 알지 못하지만, 완전히 독립적이지도 않습니다.

터미널에서만 할 수 있는 것

앱에 대응 기능이 없는 CLI 워크플로는 크게 세 가지입니다. mo history, mo update, mo completion, mo remove 같은 보조 명령은 추가 유지 관리 화면이 아니라 터미널 관리용입니다.

`mo purge`

프로젝트 디렉터리를 스캔해 무거운 빌드 산출물 삭제를 제안합니다. 대상 목록이 넓습니다. target, build, dist, .next, DerivedData, __pycache__, coverage와 대략 서른 개 더 포함하며, 패키지 매니저가 다시 받아야 하는 의존성 디렉터리도 들어갑니다. Purge는 휴지통으로 옮기지 않고 영구 삭제하며, 최근 7일 안에 손댄 프로젝트는 최근 항목으로 표시하고 기본 선택에서 빼둡니다. 개발 머신에서 수십 기가바이트를 바로 회수하는 방법인 동시에, 가장 먼저 --dry-run을 써 볼 만한 명령이기도 합니다.

`mo installer`

Downloads, Desktop, Homebrew 캐시, iCloud, Mail에 남은 DMG, PKG, 아카이브 설치 파일을 쓸어 모으며, 각각 출처를 표시합니다.

`mo touchid`

sudo에 Touch ID를 설정합니다. 정리 작업이 아니라 셸 설정 작업입니다.

명령 외에도 터미널은 창으로는 하기 어려운 세 가지를 줍니다. 모든 삭제 명령은 --dry-run을 받으며, 실제로 지울 목록만 출력하고 아무것도 지우지 않습니다. mo analyze, mo status, mo history는 --json을 받고, mo status는 출력이 파이프되면 스스로 JSON으로 바뀌어 상태 검사를 스크립트에 넘길 수 있습니다. 읽기 전용·구조화 출력 경로는 ssh, 헤드리스 Mac, 스크립트 안에서도 동작합니다. 예약 삭제는 여전히 비대화형 정책을 명시해야 합니다. cron이 띄웠다고 해서 대화형 확인 화면이 안전해지지는 않습니다.

앱에서만 할 수 있는 것

앱의 추가는 터미널이 약한 두 축에 모입니다. 지속 표시와 권한이 필요한 시스템 제어입니다.

표시 측면에서 Analyze는 드릴다운 가능한 트리맵을 그리고, Status는 스파크라인과 고정 가능한 프로세스가 있는 실시간 bento 대시보드를 렌더하며, 메뉴 바 HUD는 다른 작업을 하는 동안 CPU·메모리·네트워크를 보여 줍니다. Uninstall은 이동 전에 경로·소유자·크기가 있는 검토 계획을 보여 주고, 삭제는 바로 지우지 않고 휴지통으로 보냅니다.

시스템 제어 측면에서 앱은 팬과 지원되는 배터리 쓰기를 위해 SMJobBless로 범위를 좁힌 루트 헬퍼를 설치합니다. 시작 항목 관리는 별도 경계를 따릅니다. 검증된 launchd 작업과 지원되는 Service Management 항목은 토글할 수 있고, 매칭되지 않는 백그라운드 항목은 추측하지 않고 System Settings를 엽니다. 상주 앱으로서만 의미 있는 화면도 있습니다. 카메라·마이크 사용을 실시간으로 알려 주는 Privacy Check, 지원 Mac에서 충전을 약 75~80% 근처로 유지하는 Battery Care, Keep Screen On, 키보드를 닦을 때 쓰는 Clean Screen, 이슈에 붙여 넣을 진단 리포트를 모으는 읽기 전용 Doctor입니다.

앱 전용 면 중 가장 큰 것은 다른 앱 업데이트입니다. 여러 업데이트 채널을 감지하고 Sparkle, Homebrew cask·formula, Mac App Store, Electron 피드에 대한 인앱 경로를 둡니다. GitHub Releases와 웹사이트 메타데이터로 추가 버전을 찾을 수 있으며, 번들을 안전하게 검증·교체할 수 없으면 다른 설치기를 만들지 않고 해당 앱이나 벤더 페이지를 엽니다. 라이선스는 두 대 Mac을 커버하는 일회 구매이며 평생 업데이트, 14일 환불, macOS 14 이상을 전제로 합니다. 두 프로그램 모두 텔레메트리를 보내지 않습니다.

내부: 하나의 안전 모델이 두 프론트엔드를 섬기는 방식

앱은 mo를 셸로 호출하는 래퍼가 아닙니다. Swift로 다시 구현한 것이며, 두 코드베이스는 프로세스보다 경로와 안전 결정을 공유합니다. Analyze는 CLI의 경로 분류와 병렬 사이징 교훈을 쓰지만, 자체 스캐너·타임아웃·부분 결과 상태·캐시·폴백 동작을 가집니다. 따라서 한쪽의 합계는 교차 확인에 유용할 뿐, 바이트 단위 동일성을 약속하지 않습니다.

저장소에 기록된 동기화 원칙은 CLI 패리티가 동일한 삭제 범위가 아니라 같거나 더 안전함이라는 뜻입니다. 앱이 보여 주는 모든 후보는 사용자에게 도달하기 전에 분류됩니다. 기본 선택, 기본 미선택 검토 전용, 또는 요청이 와도 거부되는 차단입니다. CLI 동작과 이 분류가 어긋나면 앱은 더 좁은 쪽을 택합니다.

mo purge가 가장 분명한 예입니다. 그 스윕의 Mac 이식판은 CLI가 지우는 다운로드 의존성 디렉터리를 의도적으로 모두 제외합니다. node_modules, Pods, venv, vendor를 포함합니다. 이유는 복구 가능성입니다. 컴파일된 target 디렉터리는 로컬 빌드로 돌아오지만, 의존성 트리는 네트워크가 필요하고 설치 당시와 다르게 해석될 수 있습니다. 앱은 순수 로컬 컴파일로 다시 만들 수 있는 것만 제안하며, 기본 선택이 아닌 검토 전용 행으로 보여 줍니다. 같은 비대칭은 다른 곳에도 있습니다. 앱은 앱 데이터 스캔을 Full Disk Access 뒤에 두고, 스캔 시점이 아니라 삭제 순간에 모든 경로를 다시 검증하며, 일반 삭제는 휴지통으로 보냅니다.

그래서 둘의 공격성은 같지 않으며, 차이는 한 방향으로 일관됩니다. CLI는 목록을 읽는 사용자를 가정해 더 많이 회수합니다. 앱은 목록이 이미 안전하기를 원하는 사용자를 가정해 더 적게 회수합니다.

터미널 도구와 Mac 앱이라는 두 프론트엔드가 같은 다섯 작업을 각각 실행하되, 디스크의 같은 허용 목록 파일과 같은 작업 로그를 읽고 씁니다 — 두 프로그램은 실행 중 서로 통신하지 않지만 보호 목록과 로그를 공유하므로, 한쪽에서 보호한 캐시는 양쪽 모두에서 보호됩니다.

둘 다 쓰기

둘 다 설치해도 깨지지 않으며, 공유 파일 덕분에 조합이 일관됩니다. 앱 Settings에서 캐시를 보호하면 mo clean도 건너뜁니다. mo clean --whitelist로 경로를 추가하면 앱도 따릅니다. 둘 다 삭제를 같은 로그에 남깁니다.

알아 둘 주의점 두 가지입니다. 프로그램은 실행 중 조율하지 않으므로 동시에 양쪽에서 정리를 시작하지 마세요. 그리고 앱이 의도적으로 더 좁기 때문에 mo clean에만 있는 카테고리가 앱에 없는 것은 빠진 기능이 아니라 예상된 동작입니다.

CLI가 제거할 집합이 Mac 앱이 제거할 더 작은 집합을 감싸고, 그 차이는 node_modules, Pods, venv, vendor 같은 다운로드된 의존성 디렉터리입니다 — 같거나 더 안전하며, 더 넓지 않습니다. CLI만 쓰는 디렉터리는 다시 받으려면 네트워크가 필요한 것들입니다.

선택하기

터미널에서 주로 일하고, --dry-run으로 미리 보고 싶고, 스크립트에 --json이 필요하고, 프로젝트 산출물·설치 파일 스윕이 필요하거나, 단순히 돈을 쓰지 않으려면 CLI를 설치하세요. 개발 머신에서는 그것으로 충분한 경우가 많고, 무료인 이유도 바로 그 때문입니다.

디스크 맵과 실시간 대시보드가 필요하고, 팬 제어·시작 항목 관리·서드파티 앱 업데이트가 진짜 목적인 경우, 또는 Terminal을 열 일이 없는 사람을 위해 설치하는 경우에는 앱을 구매하세요. 마지막 경우가 앱이 생긴 원래 이유이며, 그 이야기는 Mole의 이야기에 있습니다.

아직 판단이 서지 않으면 먼저 CLI를 설치하고 mo clean --dry-run을 실행하세요. 비용도 없고 아무것도 지우지 않으며, 출력을 읽는 것이 Mac에 도구가 필요할 만큼의 문제가 있는지 가장 가장 방법입니다. 그 질문은 클리너를 설치하기 전에 물어볼 가치가 있습니다.