주요 콘텐츠로 건너뛰기
Mole
개요 기능 사용 후기 가격 FAQ 블로그
EnglishEN 简体中文中 繁體中文繁 日本語日 한국어한 FrançaisFR DeutschDE ItalianoIT EspañolES
바로 구매구매 다운로드

    도움말, 문서, 릴리스, 아티클

    홈/블로그

    Mac 앱이 제거되지 않을 때: 일곱 가지 원인과 각각의 증상

    앱 삭제게시 2026년 8월 18일수정 2026년 8월 22일14분 읽기

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

    증상부터 시작하세요

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

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

    Finder는 파일이 열려 있는 번들을 옮기길 거부하고, 눈에 보이는 프로세스를 종료한다고 앱이 시작한 모든 걸 멈추는 건 아닙니다. Activity Monitor는 창이 있는 것만이 아니라 모든 프로세스를 나열합니다. 제조사 이름으로 검색하고 결과 전체를 읽어보세요. Foo라는 앱은 흔히 Foo Helper, FooUpdater, 그리고 전혀 다른 표시 이름을 가진 로그인 항목 번들까지 함께 설치합니다. Apple 메뉴 > 강제 종료 창은 대체재가 되지 못합니다. UI가 있는 애플리케이션만 나열하기 때문입니다.

    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 에이전트나 데몬이 도로 되돌려놓음

    이건 "지웠는데 다시 돌아왔다"는 사례이고, 가장 자주 오진되는 경우입니다. 사람들은 Activity Monitor를 확인하고 아무것도 안 보이면 앱이 실행 중이 아니었다고 결론짓습니다. 필요할 때만 실행하는 방식에서는 그게 증거가 되지 않습니다.

    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 자체가 없을 수도 있습니다. 이런 경우는 백그라운드 작업 관리에 속하고 시스템 설정 > 일반 > 로그인 항목 및 확장 프로그램(시작 항목 안내)에서 제어합니다.

    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은 관리 대상이 아니고 이게 원인이 아닙니다.

    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 이상에서는 대개 앱 관리 때문입니다. Apple은 이걸 "다른 앱을 업데이트하거나 삭제하도록 앱 허용"으로 설명합니다. 알아보는 방법은 경로는 POSIX 기준으로 쓸 수 있는데도 실제 쓰기가 계속 실패하는 것입니다.

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

    이게 출력되는데도 제거가 여전히 안 된다면, 문제는 권한 자체가 아닙니다. 시스템 설정 > 개인정보 보호 및 보안 > 앱 관리로 가서 제거를 수행하는 앱을 켜고 다시 실행하세요. 많은 앱이 시작할 때만 이 권한을 확인하기 때문입니다.

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

    POSIX 권한이 첫 번째 관문입니다. 번들이 root 소유이고 여러분은 root가 아니라면, sudo가 해결해줍니다. 이 검사는 오직 여러분이 어떤 사용자인지만 따지기 때문입니다. 시스템 설정 뒤에 있는 개인정보 보호 계층인 TCC는 POSIX를 통과한 뒤에 판단합니다. 앱 관리는 다른 앱의 번들을 수정하거나 삭제하는 한 가지 작업에 대한 TCC 관문입니다. 관리자라고 해서 이걸 통과하는 건 아니고 sudo도 마찬가지입니다. 이건 사용자가 아니라 요청하는 프로그램에 매여 있기 때문이고, 그래서 거부됐을 때 알림도 없이 그냥 일반적인 오류로만 나타날 수 있는 겁니다.

    SIP는 이 둘보다 더 아래에 있고 root조차 그대로 거부합니다. POSIX 거부는 EACCES를 설정하고 Permission denied를 출력하고, SIP 거부는 EPERM을 설정하고 Operation not permitted를 출력합니다. 전자는 권한을 갖고 다시 시도하라는 뜻이고, 후자는 다시 시도할 권한 자체가 없다는 뜻입니다.

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

    보안 소프트웨어, VPN 클라이언트, 가상화 제품은 시스템 확장 기능을 설치합니다. 앱 번들은 그 확장 기능을 등록할 뿐이지, 그 자체가 확장 기능은 아닙니다. 확장 기능이 활성화된 상태에서 컨테이너를 지우면 소유자를 잃은 등록 정보만 남는데, Mac이 여러분이 이미 제거했다고 믿는 소프트웨어를 통해 계속 트래픽을 필터링하는 이유가 바로 이겁니다.

    systemextensionsctl list
    

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

    7. App Store나 Homebrew에서 온 경우

    Mac App Store 앱. 번들을 지운다고 구매 기록까지 사라지지는 않습니다. 사람들이 흔히 걸리는 함정은 Apple이 "다른 Mac 컴퓨터와 기기에서 구매한 App Store 앱 자동 다운로드"라고 표현한 설정입니다. 같은 계정의 다른 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로 이 진단하기

    이 글을 수동으로 따라가려면 화면 다섯 개를 오가야 합니다. Activity Monitor, launchd 폴더 세 곳, 로그인 항목 및 확장 프로그램, 개인정보 보호 및 보안, Finder. Mole은 하나의 앱에 속한 부분들을 탭 하나에 모아두고, 스캔은 항상 무료이니 구매 여부와 상관없이 읽기 전용 진단 도구로 쓸 수 있습니다.

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

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

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

    확인을 누르면 이 글이 권장한 순서가 그대로 실행되는데, 여러분이 기억해야 하는 게 아니라 강제됩니다. Mole은 앱과 그 번들 안에 있는 헬퍼를 종료하고, 로그인 항목 헬퍼를 부팅아웃하고, plist를 지우기 전에 승인된 launch 항목을 launchctl로 언로드하고, 삭제 시점에 모든 경로를 다시 검증합니다. 삭제는 휴지통으로 가니 실수해도 그냥 도로 꺼내면 됩니다.

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

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

    자주 묻는 질문

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

    대략 빈도순으로 네 가지 원인이 있습니다. launchd 에이전트나 데몬이 여전히 그걸 가리키는 작업 정의를 갖고 있어서, Activity Monitor에서는 보이지 않는 트리거로 다시 시작시킵니다. brew uninstall --cask 대신 앱을 휴지통으로 보내서 Homebrew cask 기록이 살아남은 경우입니다. 관리 대상 Mac이라면 MDM이 다시 밀어 넣은 겁니다. 아니면 다른 기기에서 구매한 앱을 자동으로 다운로드하는 App Store 설정이 다른 Mac에서 그걸 끌어온 겁니다.

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

    기술적으로는 됩니다만 나쁜 거래입니다. 복구 모드에서 기기 전체의 보안 수준을 낮추는 대가로, 봉인된 시스템 볼륨이 교체되는 다음 macOS 업데이트 때 그 번들이 다시 돌아올 뿐입니다. 대신 Dock과 로그인 항목에서 제거하세요.

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

    아닙니다. .pkg 설치 프로그램이 root로 그 번들을 거기 놓았기 때문에, 옮기려면 인증이 필요합니다. 정말 걱정할 만한 실패는 그 반대입니다. 알림도, 오류도, 아무 일도 일어나지 않는 경우요. 이건 대개 시스템 설정 > 개인정보 보호 및 보안 아래에서 앱 관리가 거부된 것이고, sudo로는 고쳐지지 않습니다. 이 관문은 사용자가 아니라 요청하는 프로그램에 매여 있기 때문입니다.

    관련 글

    • Mac에서 앱 완전히 제거하기: 일반적인 순서와 거기서 검토하는 Library 계층.
    • Mac에서 백신 제거하기: 시스템 확장 기능이 있는 소프트웨어, 해체 순서 자체가 일의 전부인 경우.
    • Mac에서 시작 프로그램 비활성화하기: 더 이상 아무것도 방해하지 않을 때의 launchd와 로그인 항목 쪽.

    Mole은 네이티브 Mac 앱입니다. 공간 정리, 앱 관리, 시스템 유지보수, 디스크 분석, 상태 확인까지. 평생 사용하고 구독은 없습니다.

    Mole 둘러보기

    이어서 읽기

    • 앱 삭제데이터 손실 없이 Mac 앱을 완전히 제거하는 방법8분 읽기
    • 앱 삭제네트워크를 망가뜨리지 않고 Mac에서 백신 제거하기15분 읽기
    • 앱 삭제도구 체인을 유지한 채 Mac에서 Java 제거하기4분 읽기

    Mole · 鼴

    Mac 정리, 앱 관리, 상태 확인을 하나로.

    v1.13.0 (166) · 릴리스

    지원

    도움말 문서 릴리스

    약관

    이용약관 개인정보 처리방침 환불 정책

    리소스

    블로그 CLI 도구 파트너 프로그램

    소셜

    Twitter hi@mole.fit

    유일한 공식 사이트 mole.fit · 가짜 사이트의 위험한 다운로드에 주의

    터미널 사용자를 위한 CLI는 계속 무료입니다.