Mac 앱이 제거되지 않을 때 확인할 일곱 가지 원인

앱 삭제게시 수정 13분 읽기

macOS에서 제거가 실패하는 건 한 가지 문제가 아닙니다. Finder가 번들을 옮기길 거부할 수도 있고, 옮기기는 성공했는데 다음 로그인 때 앱이 다시 나타날 수도 있고, 번들은 사라졌는데 여러분을 괴롭히던 헬퍼는 계속 실행 중일 수도 있습니다. 각각 원리가 다르고 해결법도 다르니, 여러분의 Mac이 정확히 어떻게 했는지부터 시작하세요. 일반적인 순서는 완전히 제거하기를 보세요. 이 글은 그게 이미 실패했다고 전제합니다.

증상부터 시작하세요

제거 실패 증상 여섯 가지, 항목이 열려 있다는 알림, 삭제 후 다시 나타나는 앱, 아무 일도 일어나지 않음, 관리자 암호 요구, root로도 작업이 허용되지 않는다는 오류, 시스템 설정에서 회색으로 비활성화된 항목, 각각 서로 다른 원인으로 연결됨
거부되는 문구 자체가 진단입니다. 이 여섯 가지 중 두 가지는 아무 알림도 뜨지 않는데, 그래서 이 도구가 고장 났다고 오해받습니다.
  • "항목이 열려 있어서 휴지통으로 옮길 수 없습니다." 뭔가 실행 중입니다. 대개 여러분이 종료한 앱은 아닙니다.
  • 지웠는데 다시 돌아왔습니다. 앱이 다시 설치된 것인지, 남아 있던 헬퍼만 다시 실행된 것인지 먼저 구분하세요.
  • Finder가 관리자 암호를 요구합니다. .pkg 설치 프로그램이 번들을 root 소유로 남겨둔 겁니다. 정상입니다.
  • 아무 일도 일어나지 않습니다. 알림도, 오류도 없습니다. 앱 관리 권한 거부가 가능한 원인 중 하나입니다.
  • root로 rm을 실행해도 "작업이 허용되지 않음"이 뜹니다. 권한이나 보호 정책의 제한일 수 있지만, 이 문구만으로 SIP 때문이라고 단정할 수는 없습니다.
  • 회색으로 비활성화돼 있거나, 회사용 Mac에서 다시 나타납니다. 구성 프로필이나 MDM이 그걸 소유하고 있는 겁니다.

1. 앱이나 헬퍼 중 하나가 여전히 실행 중

Finder는 사용 중인 앱 번들을 옮기지 못할 수 있습니다. 앱 창을 닫아도 그 앱이 실행한 보조 프로세스까지 모두 종료되는 것은 아닙니다. 활성 상태 보기에서 모든 프로세스를 표시하고 제조사 이름으로 검색해 보세요. Foo라는 앱에 Foo Helper, FooUpdater, 이름이 다른 로그인 항목이 함께 설치되어 있을 수 있습니다. Apple 메뉴 > 강제 종료에는 창이 있는 앱만 표시되므로 보조 프로세스 확인을 대신할 수 없습니다.

pgrep -fl -i foo
lsof +D /Applications/Foo.app 2>/dev/null | awk '{print $1, $2}' | sort -u

pgrep -fl은 명령줄 전체를 매칭하기 때문에, 프로세스 이름에는 제조사 이름이 없어도 실행 파일 경로에 있다면 그 헬퍼를 잡아냅니다. lsof +D는 번들 안의 파일을 붙잡고 있는 모든 프로세스를 알려줍니다.

부모 프로세스를 강제 종료해도 헬퍼가 확실히 멈추지는 않습니다. 헬퍼는 자기만의 PID를 가진 독립된 프로세스라서, 부모가 종료할 때 스스로 정리하지 않는 한 부모를 죽여도 헬퍼는 고아가 될 뿐입니다. 그리고 launchd가 그 헬퍼를 관리하고 있다면, 둘 중 뭘 죽이든 launchd에게 다시 시작하라고 알려주는 셈밖에 안 됩니다. 그게 다음 섹션의 내용입니다.

Quick Look 미리보기나 Spotlight 색인 작업도 번들 안의 파일을 붙잡고 있을 수 있는데, 재시작하면 둘 다 풀립니다. 메시지가 다시 뜬다면, Apple의 앱 제거 안내는 안전 모드를 제안합니다.

2. launchd가 남아 있는 헬퍼를 다시 실행함

아이콘이나 헬퍼가 다시 나타났다면 지운 앱 번들 밖에 실행 파일이 남아 있는지 확인하세요. launchd는 남아 있는 프로그램을 다시 실행할 수 있지만 삭제된 앱 번들을 스스로 복원하지는 못합니다. 활성 상태 보기에 잠깐 보이지 않았다는 것만으로 필요할 때 실행되는 작업을 배제할 수 없습니다.

launchd는 백그라운드 작업을 감독합니다. 작업은 Label, 프로그램, 실행 조건을 담은 property list입니다. RunAtLoad는 작업이 로드될 때 시작하고, KeepAlive는 종료될 때 다시 시작합니다. 둘 다 없는 작업도 다시 돌아옵니다. MachServices, Sockets, WatchPaths, QueueDirectories, StartInterval은 전부 뭔가가 요청하는 순간 launchd가 프로세스를 시작하게 만들기 때문에, 10초 만에 유휴 상태가 됐다가 자기 Mach 서비스로 다시 시작하는 헬퍼는 확인할 때마다 없는 것처럼 보입니다.

정의는 세 위치에 있습니다. ~/Library/LaunchAgents는 현재 사용자의 로그인 세션용이고, /Library/LaunchAgents는 각 사용자의 로그인 세션에서 쓰입니다. /Library/LaunchDaemons는 로그인 없이도 실행되는 시스템 작업용입니다. 기본 실행 사용자는 root지만 다른 사용자를 지정할 수 있습니다. 에이전트와 데몬 모두 번들 밖에 설치됐다면 앱을 지운 뒤에도 남을 수 있습니다. /System/Library/Launch*는 Apple 소유이며 보호됩니다.

launchctl list | grep -i foo
launchctl print-disabled gui/$(id -u) | grep -i foo
grep -l -i foo ~/Library/LaunchAgents/*.plist /Library/LaunchAgents/*.plist \
  /Library/LaunchDaemons/*.plist 2>/dev/null

launchctl list에서 PID가 붙은 label은 지금 실행 중이고, 대시(-)만 있는 label은 로드된 채 트리거를 기다리는 중입니다. print-disabled는 영구 비활성화 상태 데이터베이스를 읽는데, plist가 존재하는지와는 별개의 사실입니다. 후보는 plutil -p <path>로 읽어보고 Program이나 ProgramArguments가 제거하려는 앱을 가리키는지 확인하세요. 제조사가 항상 파일 이름을 그 안의 label과 똑같이 짓지는 않습니다.

순서가 중요합니다

작업을 먼저 멈추고 비활성화한 다음, plist를 지우고, 마지막에 앱을 지우세요.

launchctl bootout gui/$(id -u)/com.vendor.foo.helper
sudo launchctl bootout system/com.vendor.foo.daemon
launchctl disable gui/$(id -u)/com.vendor.foo.helper

작업이 로드된 상태에서 plist를 지우면, launchd는 디스크에는 더 이상 존재하지 않는 정의를 가진 서비스를 계속 유지합니다. 다음 재부팅까지 계속 실행되고, 비활성화 상태 데이터베이스에 오래된 항목을 남길 수도 있습니다. 앱을 먼저 지우는 건 더 나쁩니다. 작업이 없는 실행 파일을 향해 다시 생성되며 루프를 그리면서 실패하는데, "지웠는데 여전히 로그인 항목에 보인다"는 게 여기서 나옵니다.

macOS 13 이상에서는 앱이 SMAppService를 사용할 수 있습니다. 헬퍼 실행 파일과 서비스 파일을 앱 번들 안에 두므로 위 디렉터리에는 별도 plist가 없을 수 있습니다. 등록 정보 자체는 macOS가 관리하며 시스템 설정 > 일반 > 로그인 항목 및 확장 프로그램(시작 항목 안내)에서 확인합니다.

3. SIP가 보호하는 시스템 앱

시스템 무결성 보호는 권한 비트가 아니라 커널 수준의 정책입니다. Apple은 이걸 커널 권한을 이용해 중요한 시스템 파일의 쓰기 가능 여부를 제한하는 것으로 설명하며, "샌드박스 안에서 실행되든 관리자 권한으로 실행되든 상관없이 시스템에서 실행되는 모든 프로세스"에 적용된다고 밝힙니다(Apple 플랫폼 보안). Big Sur부터는 시스템 콘텐츠가 암호학적으로 봉인된 별도의 볼륨에 놓입니다. csrutil status는 보호가 켜져 있는지 알려주고, Apple은 "Mac에 필요한 앱은 제거할 수 없습니다"라고 명확히 밝히는데, 여기엔 Mail, Music, Books, Notes, Podcasts, Maps, News, Stocks가 포함됩니다.

번들 하나를 지우자고 SIP를 끄는 건 나쁜 거래입니다. 복구 모드로 부팅해서 기기 전체의 보안 정책을 바꿔야 한다는 뜻이고, Intel Mac에서는 이걸 끄면 물리적 저장 장치의 모든 파티션에 대한 보호가 사라진다고 Apple이 밝히고 있으며, Apple Silicon에서는 Mac이 Full Security 상태에서 벗어납니다. 얻는 것도 오래가지 않습니다. 다음 macOS 업데이트 때 시스템 볼륨이 통째로 교체되고, 쓸 수 있는 공간도 회수되지 않습니다.

더 나은 방법: Dock에서 아이콘을 끌어내고, 시스템 설정 > 일반 > 로그인 항목 및 확장 프로그램에서 제거하고, 계속 여러분의 파일을 여는 기본 앱이라면 정보 가져오기 > 다음으로 열기 > 모두 변경으로 핸들러를 바꾸세요.

4. MDM이나 구성 프로필이 설치한 경우

관리 대상 Mac에서는 관리 서버의 일정에 따라 앱이 다시 설치될 수 있고, 프로필을 제거하지 못하게 설정했을 수도 있습니다. 제거 후 몇 시간 뒤 앱이 돌아오거나, 컨트롤이 비활성화되거나, 원격 재설치여서 launchd 검색으로 원인을 찾지 못할 수 있습니다. 시스템 설정 > 일반 > 기기 관리를 확인하세요. 해당 항목이 없다는 것만으로 관리 대상이 아니라고 단정하지 말고, 등록 상태를 확인하고 회사 소유 Mac이라면 IT 담당자에게 문의하세요.

profiles status -type enrollment
sudo profiles list

첫 번째는 자동 기기 등록을 통한 등록 여부와 사용자 승인 여부를 알려주고, 두 번째는 설치된 프로필을 나열하는데 root 권한이 필요합니다. 그런 다음 IT 팀에 물어보세요. Apple의 안내는 제거할 수 없는 프로필이라면 그걸 제공한 쪽에 물어보라는 것이고, 프로필을 제거하면 그 프로필이 설정한 모든 것이 함께 사라진다고 경고합니다. 메일 계정을 담은 프로필이라면 그것도 함께 사라진다는 뜻입니다.

5. 소유권과 조용히 실패하는 권한

Finder가 관리자 암호를 요구합니다. 정상입니다. .pkg 설치 프로그램은 root로 실행되고 번들을 root 소유로 남기기 때문에, 옮기려면 인증이 필요합니다. ls -ld /Applications/Foo.app으로 확인하세요. 여기까지 왔으니 영수증도 알아둘 가치가 있습니다. pkgutil --files <id>는 패키지가 놓은 경로를 나열하고, sudo pkgutil --forget <id>는 파일은 하나도 지우지 않고 /private/var/db/receipts에서 영수증만 지웁니다.

아무 일도 일어나지 않습니다. 알림도 오류도 없이 앱이 /Applications에 그대로 있다면, macOS 14 이상에서는 앱 관리 권한도 확인할 대상입니다. 다른 앱을 업데이트하거나 삭제할 수 있는지 정하는 권한입니다. 다음 읽기 전용 명령은 번들 경로에 쓰기 권한이 있는지 확인합니다.

test -w /Applications/Foo.app && echo "posix says yes"

출력됐다고 권한 문제를 배제할 수는 없습니다. 삭제에는 부모 디렉터리의 쓰기·탐색 권한, ACL, 다른 보호 정책도 영향을 줍니다. 앱 관리가 거부돼 있다면 시스템 설정 > 개인정보 보호 및 보안 > 앱 관리에서 제거를 수행하는 신뢰할 수 있는 앱을 허용하고 다시 실행해 보세요.

핵심 원리: 똑같아 보이는 세 가지 거부

파일 권한에는 소유권뿐 아니라 부모 디렉터리 접근 권한과 ACL도 영향을 줍니다. 관리자 인증으로 해결되는 제한도 있지만 전부는 아닙니다. 시스템 설정의 개인정보 보호 계층인 TCC는 별도로 판단합니다. 앱 관리는 다른 앱의 번들을 수정하거나 삭제하는 작업에 대한 권한입니다. 사용자뿐 아니라 요청한 앱을 기준으로 하므로 관리자이거나 sudo를 써도 자동으로 허용되지 않으며, 거부가 일반 오류로만 표시될 수 있습니다.

SIP는 root의 작업도 거부할 수 있지만 오류 문구만으로 어떤 보호 정책인지 알 수는 없습니다. EACCES와 Permission denied는 부모 디렉터리의 쓰기·탐색 권한 부족에서도 발생합니다. EPERM과 Operation not permitted도 SIP 외의 원인이 있습니다. 정확한 경로, 소유권, 부모 디렉터리 권한, 요청한 앱을 확인하세요. 어느 오류도 시스템 보호를 끄라는 뜻은 아닙니다.

6. 시스템 확장 기능이나 네트워크 필터가 여전히 활성

보안 소프트웨어, VPN 클라이언트, 가상화 제품은 시스템 확장 기능을 설치할 수 있습니다. 개별 파일을 지우는 것은 확장을 비활성화하는 올바른 절차가 아닙니다. 확장을 포함한 앱을 정상적으로 휴지통으로 옮기면 macOS가 시스템 확장을 제거할 수 있지만, 제품이 다른 구성 요소도 따로 설치했을 수 있습니다. 제조사의 제거 절차를 따르고 실제 상태를 확인하세요.

systemextensionsctl list

출력은 팀 식별자, 번들 식별자, [activated enabled] 같은 상태를 보여줍니다. 비활성화는 그걸 담고 있는 앱의 몫이고 대개 재시작이 필요하니, 먼저 제조사 제거 도구를 실행하세요. Mac에서 백신 제거하기에서 이 종류의 해체 순서를 다룹니다.

7. App Store나 Homebrew에서 온 경우

Mac App Store 앱. 번들을 지워도 구매 기록은 남습니다. 다른 기기에서 구매한 앱을 자동 다운로드하는 설정이 켜져 있다면 새 구매가 이 Mac에도 내려올 수 있습니다. 다른 Mac에 앱이 설치돼 있다는 사실만으로 재설치 원인이 되지는 않습니다. App Store > 설정에서 해당 옵션을 확인하세요.

Homebrew cask. brew install --cask foo로 설치했다면, 앱을 휴지통으로 보내도 Homebrew는 여전히 설치돼 있다고 믿습니다. brew list --cask는 여전히 그 토큰을 보여주고, 다음번 brew upgrade가 방금 지운 앱을 다시 설치해버릴 수 있습니다. launchd 작업이 전혀 관여하지 않는, 진짜 "다시 돌아왔다" 원인입니다. 대신 brew uninstall --cask foo를 실행하세요. Homebrew의 매뉴얼 페이지는 --zap을 "cask와 관련된 모든 파일"을 제거하는 것으로 설명하면서 "애플리케이션 사이에 공유되는 파일까지 제거할 수 있다"고 경고하니, 이건 신중하게 판단하고 쓰세요.

삭제에 성공한 뒤: 뭐가 남는가

로그인 항목 및 확장 프로그램에 여전히 남아 있습니다. 존재하지 않는 경로를 가리키는 "로그인 시 열기" 항목이거나, 프로그램이 사라진 서비스에 대한 백그라운드 작업 관리 기록입니다. 시스템 설정 > 일반 > 로그인 항목 및 확장 프로그램에서 빼기 버튼으로 제거하세요. macOS가 재시작 후 스스로 정리하는 경우도 많습니다.

부팅할 때 메뉴 막대 아이콘이 나타납니다. 여전히 뭔가가 바이너리를 로드하고 있는 겁니다. 대개 지우지 않고 남겨둔 launch agent이거나, 설치 프로그램이 ~/Library/Application Support/<vendor>에 복사해둔 헬퍼입니다.

권한 있는 헬퍼가 살아남습니다. root가 필요했던 소프트웨어는 /Library/PrivilegedHelperTools/<label>에 설치되고 짝을 이루는 /Library/LaunchDaemons/<label>.plist도 함께 있습니다. 둘 다 root 소유이고 번들 밖에 있으니, 앱을 휴지통으로 보내도 어느 쪽도 건드리지 못합니다.

ls -la ~/Library/LaunchAgents /Library/LaunchAgents /Library/LaunchDaemons \
  /Library/PrivilegedHelperTools 2>/dev/null

데이터 쪽은 제거 후 남은 파일을 보세요.

Mole로 이 진단하기

수동으로 확인하려면 활성 상태 보기, launchd 폴더, 로그인 항목 및 확장 프로그램, 개인정보 보호 및 보안, Finder를 오가게 됩니다. Mole은 한 앱과 관련된 항목을 한 탭에 모아 보여 줍니다. 스캔은 무료이므로 구매 전에 읽기 전용으로 목록을 확인할 수 있습니다.

제거 검토 화면에서 앱 하나를 펼쳐 번들과 ~/Library/Application Support, ~/Library/HTTPStorages의 잔여 항목을 보여주고, 각 항목마다 크기와 체크박스가 있으며 아래에 제거 버튼이 있는 모습
제거가 건드릴 모든 항목을 정확한 경로와 크기와 함께, 아무것도 움직이기 전에 보여줍니다.

Mole의 Software 탭을 여세요. 세 구역으로 나뉘어 있습니다. 설치된 앱 목록, 사용 가능한 업데이트, 시작 항목. 마지막 구역이 바로 이 글이 손으로 모으라고 했던 launchd와 로그인 항목 목록이니, "다시 돌아온다"는 원인이 지운 뒤가 아니라 지우기 전에 보입니다.

앱을 선택하면 Mole이 번들 식별자를 확인한 뒤, 그 식별자가 소유한 것을 찾아냅니다. Application Support, Caches, Preferences, Containers, HTTPStorages, 그리고 이름에 같은 단어가 들어 있을 뿐이 아니라 plist가 실제로 그 앱을 참조하는 launch agent나 daemon까지요. 각 후보는 경로, 크기, 그걸 연결시킨 근거를 함께 담고 있고, 확신이 낮은 항목은 선택 해제 상태로 나타납니다.

확인하면 Mole은 앱과 번들 안의 헬퍼를 종료하고 로그인 항목 헬퍼를 해제합니다. 승인된 launch 항목은 plist를 지우기 전에 launchctl로 내리고, 삭제 시점에 모든 경로를 다시 검증합니다. 일반 파일은 휴지통으로 이동하며, 아직 남아 있다면 보통 복원할 수 있습니다. 다만 파일을 복원하는 것이 제거 작업 전체를 되돌리는 것은 아닙니다.

그런 다음 Mole은 성공 합계 대신 건너뛴 항목과 실패한 항목을 경로와 함께 보고합니다. 그러니 앱 관리가 거부돼서 실패한 행이나, 경로가 root 소유라 가드가 거부한 행을 보면 위에서 나온 원인 중 어떤 걸 만난 건지 알 수 있습니다. 거부된 쓰기 위에 체크 표시를 찍는 도구가, 사람들이 저녁 시간 내내 메뉴 막대 아이콘을 궁금해하게 만드는 원인입니다. Mole이 하는 모든 작업은 로컬에서만 이뤄지고, 파일 작업은 ~/Library/Logs/mole/operations.log에 기록됩니다. 터미널에서는 무료 오픈소스인 Mole CLI가 있고, mo uninstall에 --dry-run이 있어서 먼저 경로 목록을 읽을 수 있습니다.

Mole은 이길 수 없는 세 가지 원인과는 맞서 싸우지 않습니다. SIP를 끄거나 봉인된 볼륨에서 Apple 기본 앱을 제거하지 않고, 관리 대상 Mac에서 소프트웨어를 재설치하는 구성 프로필을 우회하지 않으며, 보안 에이전트, VPN 클라이언트, 가상화 제품에 대해서는 해체 순서를 아는 제조사 제거 도구를 대체하지 않습니다. 앱 관리가 거부되면 Mole은 권한을 우회해서 밀어붙이는 대신 실패를 그대로 보고합니다.

자주 묻는 질문

앱을 지웠는데 왜 다시 나타나나요?

앱 번들이 다시 설치됐는지, 남아 있던 헬퍼만 실행됐는지 먼저 구분하세요. launchd는 기존 실행 파일을 다시 실행할 수 있지만 지운 번들을 복원하지는 못합니다. brew uninstall --cask 대신 휴지통으로 옮겨 Homebrew 기록이 남았거나, 관리 대상 Mac에서 MDM이 재설치했거나, App Store가 다른 기기의 새 구매를 자동 다운로드했을 수 있습니다.

SIP를 끄면 Apple 기본 앱을 지울 수 있나요?

SIP만 꺼도 봉인된 시스템 볼륨에 쓸 수 있게 되는 것은 아닙니다. 필수 시스템 앱을 제거하려면 다른 보호 기능까지 약화해야 할 수 있으며, 지원되는 정리 방법이 아닙니다. 불필요한 아이콘은 Dock이나 로그인 항목에서 제거하세요.

Finder가 앱을 지우는데 암호를 요구해요. 뭔가 잘못됐나요?

관리자 소유로 설치된 앱을 옮길 때는 인증이 필요할 수 있으며, 그 자체는 오류가 아닙니다. 아무 반응 없이 실패한다면 일반 파일 권한과 앱 관리 권한을 함께 확인하세요. 시스템 설정 > 개인정보 보호 및 보안에서 앱 관리가 거부된 경우에는 sudo로 우회할 수 없습니다. 사용자뿐 아니라 요청하는 앱을 기준으로 판단하는 권한이기 때문입니다.

관련 글