Mac 앱 삭제 후 남은 파일 정리하기

같은 제거된 앱을 두 개의 잔여 스캐너에 넣으면 서로 다른 목록이 나옵니다. 이것은 버그가 아닙니다. 도구마다 소유권 판별 규칙, 거부 목록, 관리자 작업 한도가 다릅니다. 화면에 보이는 결과는 이 세 가지 선택에 따라 결정됩니다. 귀속을 이해하면 잔여 정리는 “누가 더 많은 찌꺼기를 찾느냐”가 아니라 “누구의 실수가 덜 치명적인가”로 바뀝니다.

이 가이드는 사후 상태를 다룹니다. 앱은 이미 사라졌거나 방금 휴지통에 들어갔고, 제거 도구가 마땅히 가져야 할 신중함으로 잔여물을 검토하려 합니다. 앱이 아직 실행 중일 때의 전체 순서는 완전 제거를 참고하세요. 제품 선택은 AppCleaner 너머를 참고하세요.

한 줄 요약: 앱을 휴지통으로 끌면 번들만 제거됩니다. 데이터는 ~/Library 아래 Application Support, Caches, Preferences, Containers에 남습니다. 잔여물은 크기나 이름이 아니라 번들 식별자로 귀속하고, 삭제 전에 후보를 모두 검토하세요. 또는 그 규칙을 강제하는 제거 도구를 쓰세요.

macOS에서 “제거”가 실제로 의미하는 것

macOS는 애플리케이션을 하나의 삭제 버튼으로 끝나는 하나의 객체로 다루지 않습니다. 적어도 세 층이 있습니다.

휴지통으로 끄는 것은 첫 번째 층만 보장합니다. 중간 층은 일반 도구가 도움이 되는 영역입니다. 세 번째 층은 도구가 잘 처리하는 척하다가 자주 실패하는 영역입니다. 드라이버, 네트워크 확장, 권한 있는 헬퍼, 라이선스 데몬이 여기에 해당합니다. Apple이 여전히 이 이유로 제조사 Uninstall 앱을 우선하라고 안내하는 이유입니다 (Delete or uninstall apps).

사용자 잔여물이 실제로 있는 곳

대부분의 서드파티 잔여물은 홈 Library 아래에 모입니다.

/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은 디스크 분석, 앱 유지보수, 검토 우선 정리를 네이티브 Mac 앱으로 묶습니다. 시스템 데이터는 여전히 macOS와 소유 앱이 관리합니다.

고아는 “Library 안의 큰 것”이 아닙니다

잊은 앱의 잔여물을 찾으려면 청구 차감이 필요합니다. 후보 지원 폴더를 나열한 뒤, 설치된 소프트웨어가 여전히 청구하는 것(번들 id, 실행 중 앱, Launch Services 등록, 제조사 루트)을 빼 냅니다. 청구 스캔이 부분적이면(시간 초과, 읽을 수 없는 디렉터리) 안전한 결과는 추측 목록이 아니라 고아 0개입니다. 깨끗한 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”는 오래된 연관이지, 임의의 Caskroom 경로를 rm -rf 할 이유가 아닙니다.

이름이 맞아도 거절할 것

• 아직 설치된 형제와 채널 쌍둥이
• 공유 그룹 컨테이너와 제조사 상위 폴더
• 검증된 제거기 없는 영수증과 권한 있는 헬퍼
• Library 밖의 사용자 문서
• 캐시 경로 근처에 있는 AI 채팅 저장소와 모델 디렉터리 (AI 정리)

흔한 실수

찾은 목록을 최대화하기. 후보가 많을수록 귀속이 더 나쁜 경우가 많습니다.

Group Containers를 기본 삭제하기. 의도적으로 공유됩니다.

VPN, AV, 오디오, 가상화에 제조사 제거기를 건너뛰기.

Full Disk Access 없이 측정한 뒤 “아무것도 안 남았다”고 결론 내리기.

대량 잔여 삭제 직후 휴지통 비우기. 중요한 것이 잘못 귀속됐을 수 있다면 하루 정도 평소처럼 써 보세요.

확인

1. 제거한 경로를 다시 측정합니다.
2. 해당 id의 로그인 항목이나 launch agent가 남지 않았는지 확인합니다 (시작 항목).
3. 같은 제조사의 형제 앱을 실행합니다.
4. 삭제를 수락한 뒤에만 휴지통을 비웁니다.

작업 순서

1. 앱에 드라이버, 확장, 헬퍼가 있었다면 제조사 제거기를 찾습니다.
2. 필요하다면 앱이 아직 실행 중일 때 내보내기 또는 인증 해제를 합니다.
3. 앱과 보이는 헬퍼를 종료합니다.
4. 번들을 제거합니다(또는 이미 휴지통에 있는지 확인합니다).
5. 정체성으로 잔여물을 검토하고, 공유 컨테이너는 그대로 둡니다.
6. 해당하면 Homebrew cask 영수증을 처리합니다.
7. Mac을 평소처럼 쓰는 동안 항목을 휴지통에 둔 뒤 비웁니다.

더 읽을 거리

• Apple: Delete or uninstall apps on Mac
• 관련: 완전 제거, AppCleaner 대안, 클리너가 절대 지우면 안 되는 것

잔여 정리는 정체성 유지입니다. 기술은 기가바이트를 최대화하는 것이 아니라 소유권을 증명하고, 공유 상태를 보호하며, 삭제를 복구 가능하게 유지하는 것입니다.

자주 묻는 질문

~/Library 아래 잔여 파일을 직접 삭제해도 안전한가요?

귀속이 있을 때만 가능합니다. 폴더를 크기나 비슷한 이름이 아니라 앱의 번들 식별자에 맞추고, 보내기 전에 각 항목을 검토하세요. 잘못된 추측 한 번이 다른 앱 데이터나 본인 문서를 날릴 수 있습니다.

앱이 파일을 남기는 이유는 무엇인가요?

macOS에는 제거 계약이 없습니다. 번들을 휴지통으로 끄는 것이 메커니즘의 전부이고, 앱이 런타임에 쓴 것은 쓰인 자리에 그대로 남습니다.

재설치하면 삭제한 것이 다시 만들어지나요?

재생성 가능한 상태는 그렇습니다. 캐시, 영수증, 기본 환경설정은 첫 실행에 돌아옵니다. 문서, 채팅 기록, 라이선스는 돌아오지 않습니다. 신중한 도구가 재설치로 다시 만들어질 것만 미리 선택하는 이유입니다.