Mac 앱 삭제 후 남은 파일 정리하기
같은 제거된 앱을 두 개의 잔여 스캐너에 넣으면 서로 다른 목록이 나옵니다. 이것은 버그가 아닙니다. 도구마다 소유권 판별 규칙, 거부 목록, 관리자 작업 한도가 다릅니다. 화면에 보이는 결과는 이 세 가지 선택에 따라 결정됩니다. 귀속을 이해하면 잔여 정리는 “누가 더 많은 찌꺼기를 찾느냐”가 아니라 “누구의 실수가 덜 치명적인가”로 바뀝니다.
이 가이드는 사후 상태를 다룹니다. 앱은 이미 사라졌거나 방금 휴지통에 들어갔고, 제거 도구가 마땅히 가져야 할 신중함으로 잔여물을 검토하려 합니다. 앱이 아직 실행 중일 때의 전체 순서는 완전 제거를 참고하세요. 제품 선택은 AppCleaner 너머를 참고하세요.
한 줄 요약: 앱을 휴지통으로 끌면 번들만 제거됩니다. 데이터는 ~/Library 아래 Application Support, Caches, Preferences, Containers에 남습니다. 잔여물은 크기나 이름이 아니라 번들 식별자로 귀속하고, 삭제 전에 후보를 모두 검토하세요. 또는 그 규칙을 강제하는 제거 도구를 쓰세요.
macOS에서 “제거”가 실제로 의미하는 것
macOS는 애플리케이션을 하나의 삭제 버튼으로 끝나는 하나의 객체로 다루지 않습니다. 적어도 세 층이 있습니다.
| 층 | 흔한 위치 | 누가 지워야 하는가 |
|---|---|---|
| App bundle | /Applications, ~/Applications, Setapp 등 |
사용자, 휴지통, 또는 패키지 관리자 |
| 사용자 지원 데이터 | ~/Library/… |
잔여 스캐너 또는 신중한 수작업 검토 |
| 시스템 / 권한 | /Library, helpers, receipts, extensions |
제조사 제거기를 먼저 |
휴지통으로 끄는 것은 첫 번째 층만 보장합니다. 중간 층은 일반 도구가 도움이 되는 영역입니다. 세 번째 층은 도구가 잘 처리하는 척하다가 자주 실패하는 영역입니다. 드라이버, 네트워크 확장, 권한 있는 헬퍼, 라이선스 데몬이 여기에 해당합니다. Apple이 여전히 이 이유로 제조사 Uninstall 앱을 우선하라고 안내하는 이유입니다 (Apple의 앱 삭제 안내).
사용자 잔여물이 실제로 있는 곳
대부분의 서드파티 잔여물은 홈 Library 아래에 모입니다.
| 영역 | 보통 무엇인지 |
|---|---|
Application Support/<Name or ID> |
데이터베이스, 오프라인 팩, 프로젝트 상태 |
Caches/<bundle id> |
재생성 가능한 캐시 |
Containers/ 및 Group Containers/ |
샌드박스 홈과 공유 그룹 |
Preferences/ (+ ByHost) |
설정 plist |
Logs/, DiagnosticReports |
진단 정보 |
Saved Application State/ |
창 복원 |
HTTPStorages/, WebKit, cookies |
해당 정체성의 네트워크 상태 |
LaunchAgents/ |
plist에 기반한 사용자 로그인 헬퍼 |
Application Scripts/ |
샌드박스 스크립트 패키지 |
/Library 아래 시스템 경로(LaunchDaemons, PrivilegedHelperTools, /private/var/db/receipts의
영수증)는 더 높은 위험 등급입니다. 제조사 제거기를 우선하고, 일반 스캐너는 여기서
검토 전용으로 다루세요.
샌드박스 앱은 겉보기에 깔끔해 보이는 경우가 많습니다. 기본 컨테이너는
~/Library/Containers/<bundle id>에 있습니다. 그래도 App Groups, Application Scripts,
공유 캐시, CloudKit, Keychain 항목을 쓸 수 있습니다. 샌드박스는 직접 파일 접근을
좁히지만, 한 디렉터리로 끝나는 발자국을 보장하지는 않습니다. 비샌드박스 앱은
Application Support, Caches, Preferences, Logs, Saved Application State, WebKit,
Cookies에 흩어질 수 있습니다. 흩어질수록 두 도구가 다르게 판단할 여지도 커집니다.
귀속이 전부입니다
안전한 잔여 발견은 마케팅 이름이 아니라 정체성에 묶입니다.
번들 식별자 대 표시 이름
com.example.widget은 이름 변경과 현지화를 거쳐도 안정적입니다. 표시 이름은 그렇지 않습니다.
두 제품이 회사 폴더(…/Application Support/Google)를 공유할 수 있는데, 그중 하나만
제거된 상태일 수 있습니다. “Google” 문자열 매칭은 스캐너가 수 기가바이트 규모
오탐을 만들어 내는 전형적인 경로입니다.
식별자 매칭은 정밀하고, 형제 앱 데이터를 거의 제안하지 않습니다. 대신 앱이 자기 이름으로 지은 폴더는 놓칠 수 있습니다.
이름 매칭은 그런 폴더를 찾고, 단지 단어를 공유하는 것까지 찾습니다. 더 많이 찾고, 더 자주 틀립니다.
삭제 전 실무 확인:
mdfind 'kMDItemCFBundleIdentifier == "com.example.widget"'
ls /Applications ~/Applications 2>/dev/null
해당 id를 가진 것이 아직 있으면, 공유 지원 경로는 살아 있는 것으로 다루세요.
헬퍼와 내장 정체성
현대 앱은 관련 id를 가진 헬퍼를 함께 배포합니다. com.example.widget.helper,
SMPrivilegedExecutables에 선언된 이름, Contents/Library/LoginItems의 로그인 항목입니다.
철저한 스캐너는 앱이 사라지기 전에 번들에서 그 id를 수집합니다. 번들이 사라진
뒤에는 기록해 둔 것, 또는 정확한 이름으로 디스크에 남은 것만 남습니다.
그룹 컨테이너
~/Library/Group Containers/는 의도적으로 공유 스위트 데이터를 둡니다.
group.<bundle id><TeamID>.<bundle id>같은 팀 범위 이름- 여러 앱이 쓰는 공유
group.*공간
자동 연관 후보가 될 수 있는 것은 정확한 소유 범위 경로뿐입니다. 공유 그룹 트리는 형제 앱이 남아 있으면 검토 전용이거나 건드리지 말아야 합니다. “더 많이 찾음” 도구가 실제 피해를 내는 대표적인 범주입니다.
이름 변형과 채널 빌드
Foo Beta는 Foo Beta, FooBeta, 그리고 때로 아직 설치된 정식 채널의 안정판 Foo
폴더를 남길 수 있습니다. 채널 접미를 뗀 기본 이름은 오탐 위험이 큽니다. 안정판 앱이
사라졌음을 증명하기 전에는 검토 전용으로 두세요.
안전한 진입점 세 가지
1. 제조사 제거기를 먼저
보안 에이전트, VPN 클라이언트, 오디오 드라이버, 엔드포인트 도구는 자신의 영수증과 확장 해제 순서를 압니다. Library 탐색 전에 그것들을 실행하세요. 파일 삭제는 시스템 또는 네트워크 확장의 신뢰할 수 있는 비활성화 절차가 아닙니다. macOS가 등록을 관리합니다.
2. 앱이 이미 사라진 뒤 검토
.app이 사라졌다면, 그 번들 id 또는 정확한 이름 변형으로 여전히 표시된 경로를 스캔하세요.
보수적인 기본값:
- 소유가 확인되면 보통 괜찮음: 캐시, 로그, 저장 상태, 충돌 보고서
- 신중히 검토: Application Support, Containers, Preferences(라이선스, 오프라인 메일, 프로젝트 DB)
- 보통 그대로 둠: 정확한 소유권이 없는 Group Containers, Library 밖 Documents, 다른 id가 아직 필요로 하는 모든 것
후보 크기 측정:
du -sh ~/Library/Application\ Support/<Name> \
~/Library/Caches/<bundle.id> \
~/Library/Containers/<bundle.id> 2>/dev/null
권한 오류는 보통 폴더가 비어 있다는 뜻이 아니라, Terminal에 Full Disk Access가 없다는 뜻입니다.
3. 앱이 휴지통에 들어간 그 순간
많은 사람이 먼저 휴지통에 넣고 나중에 생각합니다. ~/.Trash의 새 .app을 감지하고,
Info.plist 정체성을 읽고, 관련 지원 파일을 스캔한 뒤 검토 패널을 여는 감시기는
잔여물을 수색 없이 잡아 줍니다. 도움이 되는 설계와 해로운 설계를 가르는 제약:
- 휴지통에 넣은 앱 번들은 자동 삭제하지 않기(Put Back이 동작해야 함)
- 보호 / AV / MDM 클래스에 대해서는 팝업하지 않기
- 클리너 자신이 제거 과정에서 앱을 휴지통에 넣었을 때는 일회성 억제를 소모하기, 그렇지 않으면 패널이 제거 흐름과 경합함
- Full Disk Access에 걸기; 없으면 백그라운드에서 권한을 요청하기보다 조용히 실패하기
Mole 의 잔여물 스캔은 설치된 앱, bundle ID와 영수증이 여전히 소유한 경로를 먼저 빼고 확인할 수 없는 후보는 선택하지 않습니다. 신원과 크기를 보여 주고 복구 가능한 삭제는 휴지통으로 보냅니다. Library 안에서 크다는 사실만으로는 충분하지 않습니다.
앱이 남긴 파일은 크기만으로 찾을 수 없습니다
예전에 지운 앱의 잔여물을 찾으려면 아직 쓰이는 경로를 먼저 제외해야 합니다. 후보 폴더를 나열한 뒤 번들 ID, 실행 중인 앱, Launch Services 등록, 제조사 공용 폴더를 확인해 설치된 소프트웨어가 쓰는 경로를 빼냅니다. 시간 초과나 접근 오류로 확인이 끝나지 않았다면, 추측해서 지우지 말고 잔여 파일 후보를 내놓지 않아야 합니다. 깨끗한 Mac에서도 늘 수십 개의 “정크” 앱을 찾는다면 판단 근거를 확인하세요.
마지막 수정 시점도 중요합니다. 최근에 바뀐 설정은 앱 목록에 나타나지 않는 CLI 도구가 쓰는 파일일 수 있으므로, 최근 mtime을 가진 경로는 후보에서 제외해야 합니다.
실습 예: 두 도구, 한 제조사 스위트
같은 회사에서 Product B를 아직 설치한 채 Product A를 제거했다고 가정합니다.
- 도구 1(식별자 중심): 작은 목록, 대부분
com.vendor.productA.*경로. - 도구 2(이름 중심):
~/Library/Application Support/Vendor(4 GB)와 두 제품이 쓰는 그룹 컨테이너를 추가.
도구 2가 더 철저해 보입니다. 실제로 제안하는 삭제는 Product B를 망가뜨릴 수 있습니다. 화면 아래 합계는 품질 점수가 아닙니다. 그 위의 범주가 중요합니다.
앱을 지운 뒤 남은 Homebrew 설치 기록
앱이 Homebrew Cask에서 왔다면, .app만 지우면 Caskroom 기록이 남아 재설치를
막을 수 있습니다. 파일 잔여물 처리 후:
brew list --cask
토큰이 남아 있으면 brew uninstall --cask <token>으로 연관을 지웁니다(brew 자체의
더 넓은 정리가 필요할 때만 --zap을 허용). “Cask is not installed”라면 해당 토큰과
Homebrew 환경이 맞는지 확인하세요. 그 메시지만으로 오래된 기록이 있다고 단정하거나 임의의 Caskroom 경로를 rm -rf 하면 안 됩니다.
이름이 맞아도 거절할 것
- 아직 설치된 형제와 채널 쌍둥이
- 공유 그룹 컨테이너와 제조사 상위 폴더
- 검증된 제거기 없는 영수증과 권한 있는 헬퍼
- Library 밖의 사용자 문서
- 캐시 경로 근처에 있는 AI 채팅 저장소와 모델 디렉터리 (AI 정리)
흔한 실수
찾은 목록을 최대화하기. 후보가 많을수록 귀속이 더 나쁜 경우가 많습니다.
Group Containers를 기본 삭제하기. 의도적으로 공유됩니다.
VPN, AV, 오디오, 가상화에 제조사 제거기를 건너뛰기.
Full Disk Access 없이 측정한 뒤 “아무것도 안 남았다”고 결론 내리기.
대량 잔여 삭제 직후 휴지통 비우기. 중요한 것이 잘못 귀속됐을 수 있다면 하루 정도 평소처럼 써 보세요.
확인
- 제거한 경로를 다시 측정합니다.
- 해당 id의 로그인 항목이나 launch agent가 남지 않았는지 확인합니다 (시작 항목).
- 같은 제조사의 형제 앱을 실행합니다.
- 삭제를 수락한 뒤에만 휴지통을 비웁니다.
작업 순서
- 앱에 드라이버, 확장, 헬퍼가 있었다면 제조사 제거기를 찾습니다.
- 필요하다면 앱이 아직 실행 중일 때 내보내기 또는 인증 해제를 합니다.
- 앱과 보이는 헬퍼를 종료합니다.
- 번들을 제거합니다(또는 이미 휴지통에 있는지 확인합니다).
- 정체성으로 잔여물을 검토하고, 공유 컨테이너는 그대로 둡니다.
- 해당하면 Homebrew cask 영수증을 처리합니다.
- Mac을 평소처럼 쓰는 동안 항목을 휴지통에 둔 뒤 비웁니다.
제거 후 첫날
많은 사람이 앱이 사라진 순간 휴지통을 비웁니다. 조금 늦추는 일정은 잃는 것이 없고 돌아갈 길을 남깁니다.
- 첫날에는 앱 번들과, 다시 생성된다고 확인한 캐시만 휴지통에 넣습니다.
- Application Support와 Containers는 그대로 두고, 하루는 Mac을 평소처럼 씁니다.
- 형제 앱과 같은 제조사의 다른 제품이 여전히 깨끗하게 실행되면 두 번째 묶음을 지웁니다.
- 아직 판단이 서지 않는 경로는
du -sh로 크기를 적어 두고 일주일 뒤에 결정합니다.
휴지통은 같은 볼륨에 있으므로 비우기 전까지 용량은 돌아오지 않습니다. 기다려서 얻는 것은 되돌릴 수 있는 시간입니다. 디스크가 정말로 가득 찼다면 다시 생성되는 캐시부터 비워 여유를 만들고, 판단이 갈리는 경로는 나중으로 미룹니다.
권한과 가시성
Full Disk Access가 없으면 Terminal도 대부분의 스캐너도 Containers 안과 Library 일부를
보지 못합니다. du는 권한 오류를 내면서도 합계까지 마치는데, 그 합계에는 열지 못한 것이
통째로 빠져 있습니다. 이것은 “남은 것이 없다”가 아니라 “볼 자격이 없다”로 읽어야 합니다.
- Terminal이나 스캔을 실행하는 도구에 Full Disk Access를 준 뒤 다시 측정합니다.
- 전후 숫자를 비교합니다. 반쯤 눈을 가린 결과로 판단하는 것이 수 기가바이트짜리 컨테이너를 비었다고 부르게 만듭니다.
- 더 쓰지 않는 도구에서는 Full Disk Access를 회수합니다. Mac에서 가장 넓은 읽기 권한이고, 한 번 준 권한은 그것을 준 이유보다 오래 남습니다.
“완전 제거” 글과의 역할 분담
완전 제거는 앱이 아직 설치되어 있을 때의 순서를 다룹니다. 제조사 제거기 먼저, 필요하면 내보내기나 인증 해제, 종료, 번들 제거, 그다음 남은 것 검토입니다. 이 글은 번들이 이미 사라진 상태를 전제하며, 쉬운 증거가 없어진 나머지 절반에 분량을 씁니다. 어떤 파일이 그 앱의 것이었고 어떤 파일은 공유되었을 뿐인지 가리는 일입니다.
더 읽을 거리
- Apple: Mac에서 앱 삭제 또는 제거하기
- 관련: 완전 제거, AppCleaner 대안, 클리너가 절대 지우면 안 되는 것
잔여 정리는 정체성 유지입니다. 기술은 기가바이트를 최대화하는 것이 아니라 소유권을 증명하고, 공유 상태를 보호하며, 삭제를 복구 가능하게 유지하는 것입니다.
자주 묻는 질문
~/Library 아래 잔여 파일을 직접 삭제해도 안전한가요?
귀속이 있을 때만 가능합니다. 폴더를 크기나 비슷한 이름이 아니라 앱의 번들 식별자에 맞추고, 보내기 전에 각 항목을 검토하세요. 잘못된 추측 한 번이 다른 앱 데이터나 본인 문서를 날릴 수 있습니다.
앱이 파일을 남기는 이유는 무엇인가요?
macOS에는 제거 계약이 없습니다. 번들을 휴지통으로 끄는 것이 메커니즘의 전부이고, 앱이 런타임에 쓴 것은 쓰인 자리에 그대로 남습니다.
재설치하면 삭제한 것이 다시 만들어지나요?
재생성 가능한 상태는 그렇습니다. 캐시, 영수증, 기본 환경설정은 첫 실행에 돌아옵니다. 문서, 채팅 기록, 라이선스는 돌아오지 않습니다. 신중한 도구가 재설치로 다시 만들어질 것만 미리 선택하는 이유입니다.