macOS Tahoe에서 "앱이 손상되어 열 수 없음" 오류? Gatekeeper 및 격리 속성 완전 해결 가이드

방금 다운로드한 앱을 더블 클릭했는데 실행되는 대신 macOS가 문을 닫아버립니다: "'앱'이 손상되어 열 수 없습니다. 휴지통으로 이동해야 합니다." 이것은 macOS에서 가장 답답한 다이얼로그 중 하나입니다. 거의 항상 거짓말이기 때문입니다. 앱이 실제로 손상된 경우는 드뭅니다. 실제로 보고 있는 것은 Gatekeeper — Apple의 앱 검증 시스템 — 가 인증할 수 없는 무언가를 실행하기를 거부하는 것이며, Tahoe 26.5(2026년 5월 11일 출시)는 이 검문을 그 어느 때보다 엄격하게 만들었습니다. macOS Tahoe에서 "앱이 손상되어 열 수 없음" 오류가 발생했다면, 이 가이드에서 정확히 왜 발생하는지, 그리고 Mac의 보안을 훼손하지 않고 안전하게 해결하는 방법을 설명합니다.

이 글은 "그냥 이 명령어를 실행하세요" 식의 단순한 글이 아닙니다. 격리 플래그를 제거하는 것은 30초 안에 해결되는 작업이지만, 맹목적으로 실행하면 방금 전까지 완전히 안전했던 기기에 악성 소프트웨어를 설치하게 됩니다. 그러므로 제대로 접근합니다: 메커니즘을 이해하고, 볼 수 있는 세 가지 오류 다이얼로그를 해독하고, 정상적인 앱이 왜 플래그를 받는지 파악한 다음, 실제로 작동하는 가장 덜 공격적인 수정 방법을 적용합니다. 끝까지 읽으면 무엇을 입력해야 하는지뿐만 아니라 입력해야 하는지 여부도 알게 됩니다.

핵심 요점

• "앱이 손상됨"은 일반적으로 실제 손상이 아닌 격리 속성 + 서명 문제입니다. Tahoe는 다운로드된 파일에 com.apple.quarantine 확장 속성을 적용하고, 코드 서명이나 공증 티켓을 검증할 수 없는 앱의 실행을 거부합니다.
• 세 가지 다이얼로그는 세 가지 다른 상황을 의미합니다. "손상됨"(서명이 깨졌거나 없거나 App Translocation), "개발자를 확인할 수 없음"(서명 없음/공증 없음), "악성 소프트웨어 없음 확인 불가"(공증 확인을 완료할 수 없음)는 각각 원인과 해결 방법이 다릅니다.
• 먼저 안전한 방법을 시도하세요: 시스템 설정 > 개인 정보 보호 및 보안 > "어쨌든 열기". 이전의 오른쪽 클릭 → 열기 우회 방법은 macOS 15/26 세대에서 제거되었습니다. Apple은 이제 단일하고 의도적인 확인 절차를 통해 처리합니다.
• xattr -dr com.apple.quarantine 같은 Terminal 수정 방법은 효과가 있지만 보안을 낮춥니다. 신뢰하는 출처에서 얻은 신뢰하는 앱에만 격리 속성을 제거하세요. /Applications 전체에 대해 무작정 명령어를 실행하지 마세요.
• Gatekeeper를 전역적으로 비활성화하는 것을 첫 번째 조치로 삼지 마세요. spctl --master-disable은 오래된 튜토리얼에서 주장하는 방식으로 더 이상 작동하지 않으며, "어디서나" 옵션은 기본적으로 숨겨져 있고, Mac 전체에서 Gatekeeper를 끄는 것은 하나의 앱을 승인하는 것보다 훨씬 더 큰 위험입니다.

Gatekeeper, 격리 속성, 공증이란 무엇인가

오류를 지능적으로 해결하려면 오류를 생성하는 세 가지 겹치는 시스템을 이해해야 합니다. 사람들은 이 용어를 같은 의미로 사용하지만, 앱 실행 시간에 모두 작동하는 별개의 메커니즘입니다.

Gatekeeper: 문 앞의 경비원

Gatekeeper는 처음 열 때 애플리케이션을 실행할 수 있는지 여부를 결정하는 macOS 하위 시스템입니다. 바이러스 스캐너가 아니며 앱을 지속적으로 감시하지도 않습니다. 처음 한 번만 신분증을 확인하는 경비원처럼 생각하면 됩니다. 새로 다운로드한 앱을 실행할 때 Gatekeeper는 두 가지 질문을 합니다: 이 앱은 Apple이 인식하는 개발자가 코드 서명했습니까? 그리고 이 앱은 Apple이 공증했습니까? 두 질문 모두 예라면 앱이 문제없이 열립니다. 하나라도 아니오라면 Gatekeeper가 실행을 차단하고 아래에서 해독할 다이얼로그 중 하나를 표시합니다.

Gatekeeper의 정책은 데몬에 의해 시행되며 spctl(보안 정책 제어) 명령줄 도구를 통해 표면화됩니다. 그래서 모든 문제 해결 가이드가 결국 spctl에 도달하는 것입니다. 핵심은 Gatekeeper가 첫 번째 실행만 신경 쓴다는 것입니다. 앱을 성공적으로 한 번 열면 macOS가 승인을 기억하고 더 이상 귀찮게 하지 않습니다. 그래서 수정은 항상 초기 관문을 통과하는 것에 관한 것이지, 앱 동작 방식을 영구적으로 변경하는 것이 아닙니다.

com.apple.quarantine 확장 속성

"격리 인식" 애플리케이션 — Safari, Chrome, Mail, Messages, AirDrop, 대부분의 브라우저 및 채팅 클라이언트 — 을 통해 파일을 다운로드하면 해당 앱이 com.apple.quarantine이라는 확장 속성으로 파일에 태그를 지정합니다. 확장 속성(xattr)은 파일의 실제 내용의 일부가 아니라 파일 시스템에서 파일에 매달리는 메타데이터 조각입니다. 격리 xattr은 파일이 Mac 외부에서 왔다는 것을 기록하는 짧은 문자열로, 플래그, 타임스탬프, 다운로드한 에이전트, 고유한 이벤트 ID와 함께 있습니다.

해당 이벤트 ID는 홈 폴더의 작은 SQLite 파일(역사적으로 ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2에 위치)인 LSQuarantine 데이터베이스로 연결되어 각 격리된 항목이 어디서 왔는지 기록합니다. 이것이 Gatekeeper 프롬프트의 "이 파일은 [날짜]에 [웹사이트]에서 다운로드되었습니다" 라인 뒤의 데이터입니다. 격리 xattr의 존재가 Gatekeeper에게 "이 파일은 외부 세계에서 온 것이니 실행 전에 검사하라"고 알리는 트리거입니다. 해당 속성을 제거하면 Gatekeeper는 앱이 항상 Mac에 있었던 것처럼 처리합니다 — 그래서 제거가 가장 빠른 수정이자 가장 많은 판단을 필요로 하는 이유입니다.

공증: Apple의 악성 소프트웨어 사전 검사

공증은 퍼즐의 가장 새로운 조각이자 현대의 "손상됨" 불만의 주요 원인입니다. macOS Catalina 이후 Apple은 App Store 외부에서 배포되는 소프트웨어가 공증되도록 요구합니다: 개발자가 서명된 앱을 Apple에 업로드하면, Apple의 자동화 서비스가 알려진 악성 소프트웨어를 검사하고 올바르게 서명되었는지 확인하며, 통과하면 Apple이 공증 티켓을 발급합니다. 해당 티켓은 앱에 "스테이플"되어 파일과 함께 이동하거나, 실행 시 Gatekeeper가 온라인으로 가져올 수 있습니다.

공증된 앱을 열 때 Gatekeeper는 티켓을 검증합니다 — 스테이플된 것이든 Apple 서버에서 가져온 것이든 — Apple이 이 정확한 빌드를 확인하고 승인했음을 확인합니다. 티켓이 없거나, 가져올 수 없거나(오프라인 상태), 또는 공증 후 앱이 수정된 경우(티켓이 보증하는 서명이 무효화됨) 검사가 실패하고 차단됩니다. 공증은 App Review가 아닙니다. Apple은 품질을 검토하거나 앱의 목적을 판단하지 않습니다. 악성 소프트웨어 사전 검사와 서명 무결성 보증입니다. 이 구분을 이해하는 것이 중요합니다. "악성 소프트웨어 없음을 확인할 수 없음" 메시지는 종종 "이것은 악성 소프트웨어입니다"가 아니라 "티켓을 확인하기 위해 Apple에 연결할 수 없었습니다"를 의미하기 때문입니다.

세 가지 다이얼로그 해독

이 글에서 가장 유용한 내용은 다이얼로그의 정확한 문구가 무엇이 잘못되었는지 알려준다는 것입니다. 원인에 따라 수정 방법이 다르므로 아무것도 하기 전에 다이얼로그를 주의 깊게 읽으세요.

다이얼로그 1: "'앱'이 손상되어 열 수 없습니다. 휴지통으로 이동해야 합니다."

이것이 가장 무섭게 들리고 가장 오해를 불러일으킵니다. 압도적인 대부분의 경우 앱은 손상되지 않았습니다. 이 다이얼로그는 일반적으로 다음 경우에 나타납니다:

• 앱에 com.apple.quarantine 속성이 있고 코드 서명 유효성 검사가 실패한 경우. 서명은 앱이 서명되지 않았거나, 취소된 인증서로 서명되었거나, 또는 가장 일반적으로 정상적인 앱의 경우 서명 후 앱이 수정된 경우 실패할 수 있습니다. 전형적인 원인은 확장 속성과 심볼릭 링크를 올바르게 보존하지 않는 타사 압축 해제 도구 또는 아카이브 유틸리티로, 앱 번들을 미묘하게 손상시켜 서명이 더 이상 일치하지 않게 합니다.
• App Translocation(Gatekeeper 경로 무작위화라고도 함)이 작동하여 그 위에 다른 문제가 발생한 경우.
• 앱이 아키텍처 불일치인 경우 — 예를 들어 Rosetta 2가 없거나 더 이상 사용할 수 없는 Apple Silicon Mac의 Intel 전용 바이너리, 또는 손상된 유니버설 바이너리.

"손상됨" 문구는 "이 앱이 보안 또는 무결성 검사에 실패했으며 소프트한 '어쨌든 열기' 버튼을 제공하지 않겠다"는 Apple의 포괄적 표현입니다. 그래서 이 경우 종종 친절한 개인 정보 보호 및 보안 재정의를 표시하지 않고 Terminal로 안내합니다.

다이얼로그 2: "'앱'은 개발자를 확인할 수 없어서 열 수 없습니다."

이것은 더 부드럽고 더 정직한 형제입니다. 앱이 서명되지 않았거나 공증되지 않은 것을 의미합니다 — Apple은 앱을 만든 사람이 누구인지, 악성 소프트웨어 검사를 받았는지 기록이 없습니다. 중요한 점은 이 다이얼로그에 "휴지통으로 이동" 및 "취소" 버튼이 함께 제공되며, 실제 탈출구는 다이얼로그 자체가 아니라 시스템 설정에 있습니다. 이것이 Apple 개발자 계정 비용을 지불하지 않은 오픈 소스 도구, 틈새 유틸리티, 또는 소규모 개발자의 소프트웨어에서 가장 자주 보이는 다이얼로그입니다. 공식 "어쨌든 열기" 흐름을 통해 안전하게 처리하기 가장 쉬운 경우로, 다음에서 다룹니다.

다이얼로그 3: "Apple에서 '앱'에 악성 소프트웨어가 없는지 확인할 수 없습니다."

이 문구는 macOS 15/26 세대에 등장했으며 가장 흔히 오해되는 것입니다. Apple이 악성 소프트웨어를 발견했다는 의미가 아닙니다. Gatekeeper가 앱의 공증 상태를 확인하려 했지만 확인을 완료할 수 없었음을 의미합니다. 일반적인 이유는:

• Mac이 오프라인이거나 제한적인 방화벽/프록시 뒤에 있어 Gatekeeper가 티켓을 검증하기 위해 Apple의 공증 서버에 접근할 수 없는 경우.
• 앱이 공증되었지만 티켓이 스테이플되지 않았고 온라인 조회 시간이 초과된 경우.
• 시스템 클록이 잘못 설정된 경우(아래에서 자세히 설명), 인증서 및 티켓 시간 유효성 검사가 실패합니다.

이 다이얼로그도 일반적으로 개인 정보 보호 및 보안의 "어쨌든 열기"로 안내합니다. 온라인 상태임에도 이 메시지가 보이면 재정의하기 전에 검사가 왜 실패하는지 조사하는 것이 현명합니다 — 공증된 앱은 깨끗하게 통과해야 합니다.

정상적인 앱이 "손상됨"으로 표시되는 이유

원인을 알면 어떤 수정 방법을 사용할지 알 수 있으므로, 완전히 정상적인 앱이 경보를 울리는 구체적인 이유를 살펴보겠습니다.

격리 플래그 자체

이것이 첫 번째 이유입니다. 완전히 합법적인 앱을 다운로드하면 브라우저가 com.apple.quarantine으로 태그를 지정하고, 앱의 서명이 조금이라도 잘못되면 Gatekeeper가 "개발자를 확인할 수 없음"에서 "손상됨"으로 에스컬레이션합니다. 플래그를 직접 볼 수 있습니다:

xattr -l /Applications/ExampleApp.app

격리된 앱의 예시 출력:

com.apple.quarantine: 0083;6612a3b0;Safari;5F1B2C3D-7A8E-4F90-B1C2-D3E4F5061728
com.apple.macl: [binary data, 72 bytes]

첫 번째 필드(0083)는 격리 플래그 값이며, 16진수 타임스탬프, 속성을 적용한 에이전트(Safari), LSQuarantine 데이터베이스에 매핑되는 이벤트 UUID가 이어집니다. xattr -l을 실행했는데 com.apple.quarantine 라인이 전혀 없으면 격리는 문제가 아니며 서명이나 아키텍처 문제를 살펴봐야 합니다.

App Translocation (Gatekeeper 경로 무작위화)

이것이 미묘한 것입니다. 악의적인 앱이 옆에 있는 독이 든 파일을 로드하는 공격 유형을 방지하기 위해, macOS는 격리된 앱을 전위합니다: 먼저 /Applications로 드래그하지 않고 다운로드 위치(다운로드 폴더 또는 마운트된 디스크 이미지)에서 실행하면 macOS가 실제 위치 대신 무작위화된 읽기 전용 임시 마운트 지점에서 실행합니다. 앱은 실제로 있는 위치와 다른 경로를 봅니다.

대부분의 앱에서는 보이지 않습니다. 하지만 자체 위치에 상대적으로 리소스를 찾거나 제자리에서 자동 업데이트를 시도하는 앱은 혼란스러운 방식으로 중단됩니다 — 때로는 "손상됨" 오류나 실행 시 충돌로 나타납니다. App Translocation에 대한 해결책은 당혹스러울 정도로 간단합니다: 다운로드/DMG에서 앱을 꺼내 /Applications 폴더로 드래그한 다음 거기서 실행합니다. 앱 번들을 이동하면 해당 복사본에 대한 전위가 해제됩니다. 이 단순한 단계가 디스크 이미지에서 직접 앱을 실행하는 사람들의 "손상됨" 보고 중 놀라운 비율을 해결합니다.

압축 해제 및 전송 도구의 서명 손상

코드 서명은 디렉토리 구조, 심볼릭 링크, 확장 속성을 포함한 앱 번들 내용의 암호화 해시입니다. 서명 후 번들에서 무언가가 변경되면 서명이 더 이상 일치하지 않고 유효성 검사가 실패합니다. 여러 일상적인 작업이 번들을 조용히 손상시킬 수 있습니다:

• 심볼릭 링크를 보존하지 않거나 압축 해제 시 번들 구조를 평탄화하는 타사 아카이브 유틸리티.
• 확장 속성을 제거하거나 심볼릭 링크를 손상시키는 도구 또는 파일 시스템을 통한 파일 전송(일부 네트워크 공유, 특정 클라우드 동기화 클라이언트, FAT/exFAT USB 드라이브).
• 파일 이름 변경을 포함하여 .app 번들 내부를 수동으로 편집하는 것.

이런 경우 원래 다운로드는 정상이었지만 "손상됨"이 발생합니다. 여기서의 수정 방법은 단순히 격리 속성을 제거하는 것이 아닙니다 — Safari를 사용하여(번들을 올바르게 처리하는) 공식 소스에서 앱을 다시 다운로드하거나, 개발자 자체 빌드의 경우 로컬에서 다시 서명하는 것입니다(나중에 주의 사항과 함께 다룸).

Apple Silicon vs Intel 바이너리

Apple Silicon Mac(M1부터 최신 M 시리즈까지)을 사용 중이고 Intel 전용 앱을 실행하려고 하면 macOS는 Rosetta 2가 필요합니다. 새 시스템에서는 Rosetta가 설치되지 않을 수 있으며, Apple은 Rosetta 2가 점진적으로 지원 종료될 것임을 시사했습니다 — macOS 27 시점에서 가용성이 크게 변경됩니다. 번역될 수 없는 Intel 바이너리나 arm64 슬라이스가 없는 손상된 유니버설 바이너리는 손상처럼 보이는 실행 실패로 나타날 수 있습니다. 바이너리가 포함하는 아키텍처를 검사할 수 있습니다:

lipo -archs /Applications/ExampleApp.app/Contents/MacOS/ExampleApp

유니버설 앱의 출력:

x86_64 arm64

Apple Silicon Mac에서 x86_64만 보이면 Rosetta 2(또는 네이티브 빌드)가 필요합니다. Intel Mac에서 arm64만 보이면 해당 빌드는 단순히 실행될 수 없습니다. Rosetta 지원 종료에 대한 더 자세한 내용은 Rosetta 2 지원 종료 가이드를 참조하세요.

잘못된 클록이 공증을 망가뜨림

이것은 사람들을 놀라게 합니다. 인증서 유효성 검사와 공증 티켓 검사는 시간에 민감합니다 — 서명 인증서가 특정 시점에 유효했음을 확인하고 티켓이 만료되지 않았음을 확인합니다. Mac의 날짜와 시간이 크게 잘못된 경우(오래된 하드웨어의 방전된 시계 배터리, 수동으로 잘못 설정된 날짜, 또는 잘못된 시간대 설정), 이 검사가 실패하여 "악성 소프트웨어 없음 확인 불가" 또는 심지어 "손상됨"이 발생할 수 있습니다. 항상 시계를 확인하세요:

date

날짜가 잘못되어 있으면 시스템 설정 > 일반 > 날짜 및 시간에서 수정하고 "자동으로 날짜 및 시간 설정"을 활성화한 다음 앱을 다시 시도하세요. 사소하게 들리지만 실제로 반복 가능한 원인입니다.

안전한 수정 흐름: 먼저 개인 정보 보호 및 보안

황금률: Terminal을 건드리기 전에 공식적으로 가장 덜 공격적인 방법을 시도하세요. Tahoe에서는 시스템 설정의 "어쨌든 열기" 흐름을 의미합니다. 정확히 하나의 앱을 승인하고, 다른 모든 것에 대해 Gatekeeper를 완전히 켜둔 채로, 소프트웨어를 신뢰한다고 확인하는 의도적인 순간을 만듭니다.

1단계: 앱을 /Applications로 이동

앱이 다운로드에 있거나 마운트된 DMG에서 실행 중이면 먼저 .app을 /Applications 폴더로 드래그하세요. 이것만으로도 App Translocation이 해제되고 다른 작업 없이 많은 "손상됨" 경우가 해결됩니다. 그 후 디스크 이미지를 꺼냅니다.

2단계: 열기를 시도한 다음 개인 정보 보호 및 보안 열기

앱을 더블 클릭합니다. 차단 다이얼로그가 나타나면 취소를 클릭합니다("휴지통으로 이동"을 클릭하지 마세요). 그런 다음:

시스템 설정 > 개인 정보 보호 및 보안으로 이동하여 보안 섹션까지 스크롤합니다. macOS가 최근 앱을 차단했으면 "'ExampleApp'이 Mac을 보호하기 위해 차단되었습니다" 라인과 "어쨌든 열기" 버튼이 표시됩니다.

3단계: "어쨌든 열기"를 클릭하고 인증

어쨌든 열기를 클릭합니다. macOS가 Touch ID 또는 암호로 인증을 요청한 다음 최종 확인을 표시합니다. 확인하면 앱이 실행됩니다. 이후로 해당 앱은 승인 목록에 있으며 정상적으로 열립니다.

이것이 이전의 오른쪽 클릭 → 열기 트릭을 대체하는 흐름입니다. macOS 14 Sonoma 및 이전 버전에서는 앱을 오른쪽 클릭하고 열기를 선택하면 일회성 우회 다이얼로그를 받을 수 있었습니다. Apple은 생각 없이 Gatekeeper를 우회하는 사용자를 막기 위해 macOS 15/26 세대부터 이 단축키를 제거했습니다. 개인 정보 보호 및 보안 경로는 의도적으로 더 느립니다 — 그 마찰은 기능입니다. 이번 릴리스의 보안 설정 변경에 대한 자세한 내용은 macOS Tahoe 보안 및 개인 정보 보호 완전 가이드에서 재설계된 패널을 자세히 설명합니다.

중요: 앱이 가혹한 "손상됨" 다이얼로그를 표시하고 개인 정보 보호 및 보안에서 "어쨌든 열기" 버튼이 표시되지 않으면, 서명이 단순히 공증되지 않은 것이 아니라 실제로 손상된 것을 의미합니다. 이 경우 먼저 공식 사이트에서 앱을 다시 다운로드하세요. 여전히 실패하면 아래 Terminal 섹션이 다음 단계입니다.

Terminal 수정 방법 (및 실제 비용)

GUI 경로에서 "어쨌든 열기" 버튼이 나타나지 않을 때 Terminal이 다음 도구입니다. 아래의 모든 것은 신뢰하는 출처에서 얻은 신뢰하는 특정 앱에 적용될 때만 안전합니다. 이 명령어들은 가리키는 대상의 보안을 낮춥니다 — 그것이 전체 목적이자 전체 위험입니다.

행동 전 검사

항상 확인 후 행동하세요. 확장 속성 나열:

xattr -l /Applications/ExampleApp.app

com.apple.quarantine이 있으면 격리가 차단에 기여하고 있습니다. 없으면 제거해도 도움이 되지 않으며 서명이나 아키텍처에 문제가 있습니다.

격리 속성 제거

단일 앱에서 격리 속성을 제거하려면, 전체 번들에서 재귀적으로(-r) 속성을 삭제(-d)합니다:

xattr -dr com.apple.quarantine /Applications/ExampleApp.app

성공해도 출력이 없습니다. 이제 앱을 다시 실행합니다. 많은 경우 Gatekeeper가 더 이상 외부 세계에서 온 것으로 처리하지 않기 때문에 즉시 열립니다. 속성이 제거되었는지 확인할 수 있습니다:

xattr -l /Applications/ExampleApp.app

com.apple.quarantine 라인이 없어야 합니다.

실제로 하는 일과 위험한 이유: 격리 xattr을 제거하면 Gatekeeper에게 이 앱을 외부 세계에서 다운로드된 것으로 검사하지 말라고 알립니다. 직접 다운로드한 정당한 앱의 경우 이미 내린 신뢰 결정을 단순히 확인하는 것으로 괜찮습니다. 하지만 의심스러운 사이트, 포럼 링크, 또는 "크랙된" 앱에서 얻은 것에 맹목적으로 실행하면 악성 소프트웨어를 잡을 수 있었던 유일한 검사를 해제한 것입니다. xattr -dr com.apple.quarantine을 /Applications 전체나 보증할 수 없는 앱에 대해 실행하지 마세요. 선의의 Mac 사용자가 감염되는 가장 일반적인 방법은 Gatekeeper를 해제하려는 다운로드 페이지에서 격리 제거 명령어를 복사 붙여넣기하는 것입니다.

손상된 번들 다시 서명 (고급, 주의 사항 있음)

문제가 격리가 아닌 손상된 서명이면 속성을 제거해도 도움이 되지 않습니다 — Gatekeeper는 여전히 잘못된 서명을 봅니다. 일부 가이드에서는 임시 서명으로 앱을 강제로 다시 서명할 것을 제안합니다:

codesign --force --deep --sign - /Applications/ExampleApp.app

--sign -는 임시 서명(실제 신원 없음), --force는 기존 서명을 덮어씁니다, --deep는 중첩된 코드로 재귀합니다.

여기서 매우 주의하세요. 이것은 진정으로 고급이며 종종 잘못된 답입니다:

• --deep는 서명을 위해 Apple에 의해 더 이상 사용되지 않으며 복잡한 앱에서 미묘하게 잘못된 결과를 생성할 수 있습니다. 올바른 서명 전략이 아닌 검증 편의성을 위해 설계되었습니다.
• 임시 다시 서명은 개발자의 실제 서명과 공증을 완전히 버립니다. Apple의 신뢰가 아닌 자신의 기기 신뢰로 앱을 보증하는 것입니다.
• 번들이 손상된 경우(실제 "손상됨" 시나리오), 손상 부분을 다시 서명해도 수리되지 않습니다. 올바른 수정은 공식 소스에서 깨끗한 복사본을 다시 다운로드하는 것입니다.

실제로 다시 서명은 자신의 빌드를 디버깅하는 개발자를 위한 도구이지 최종 사용자를 위한 해결책이 아닙니다. 직접 빌드하지 않은 앱에 codesign --force --deep --sign -를 사용하려고 한다면 멈추고 대신 다시 다운로드하세요.

spctl로 Gatekeeper 판정 확인

Gatekeeper가 불만을 갖는 이유를 이해하려면 직접 물어보세요. 특정 앱을 상세하게 평가합니다:

spctl -a -vvv /Applications/ExampleApp.app

정상적인 공증 앱은 다음과 같이 반환됩니다:

/Applications/ExampleApp.app: accepted
source=Notarized Developer ID
origin=Developer ID Application: Example Developer (AB12CD34EF)

차단된 앱은 다음을 반환할 수 있습니다:

/Applications/ExampleApp.app: rejected
source=no usable signature

해당 source= 라인이 핵심입니다 — source=Notarized Developer ID는 모든 것이 정상임을 의미하고, source=no usable signature는 서명이 손상되었거나 없음을 의미하며, "공증되지 않음" 이유로 거부되면 격리가 아닌 공증을 가리킵니다. 전체 Gatekeeper 상태 확인:

spctl --status

일반적으로 다음이 출력됩니다:

assessments enabled

App Store 외부 앱 처리

"손상됨" 보고의 대부분은 Mac App Store 외부에 설치된 앱에서 발생하므로 별도로 설명할 가치가 있습니다. App Store 앱은 검토를 거치고 처음부터 끝까지 서명 및 공증되므로 이 다이얼로그를 거의 트리거하지 않습니다. 공개 웹의 앱이 Gatekeeper가 역할을 하는 곳입니다.

신뢰 순서대로 가장 안전한 출처는: Mac App Store, 공증된 다운로드가 있는 개발자의 공식 웹사이트, 그리고 공식 소스에서 일반적으로 가져오는 Homebrew Cask 같은 평판 좋은 패키지 관리자입니다. 무작위 다운로드 미러, 유료 앱의 "무료" 버전, 포럼이나 채팅에서 공유된 링크는 훨씬 더 주의해야 합니다. 격리 속성을 제거하여 앱을 실행할 수 있다는 사실이 실행하는 것이 안전하다는 것을 의미하지 않습니다.

공증이 검사이지 보증이 아닌 것에 대한 경고: 공증된 악성 소프트웨어가 가끔 Apple의 자동화된 검사를 통과합니다. 유효한 Apple 공증으로 배포된 MacSync 스틸러에 대한 분석에서 Gatekeeper를 깨끗하게 통과하는 앱도 악성일 수 있음을 보여줍니다. 교훈은 "모든 것을 불신하라"가 아니라 "소스가 다이얼로그보다 중요하다"입니다. 웹사이트를 신뢰하지 않는다면 아무리 깨끗하게 실행되더라도 다운로드를 신뢰하지 마세요. 더 광범위한 보안 강화 체크리스트는 Mac 보안 및 개인 정보 보호 가이드에서 Gatekeeper와 함께 실행할 가치 있는 도구를 다룹니다.

Tahoe와 이전 macOS의 변경 사항

몇 년 전에 이 문제를 해결했다면 방법이 바뀌었습니다. 차이점을 알면 오래된 튜토리얼을 따르는 것을 피할 수 있습니다.

오른쪽 클릭 → 열기가 없어졌습니다. macOS 14 Sonoma까지 앱을 오른쪽 클릭하고 열기를 선택하면 일회성 우회 다이얼로그를 받을 수 있었습니다. Apple은 macOS 15/26 세대에서 이를 제거했으며 Tahoe 26.5에서도 계속됩니다. 차단된 앱의 유일한 공인 재정의는 시스템 설정 > 개인 정보 보호 및 보안의 "어쨌든 열기" 버튼입니다. 오른쪽 클릭하고 열기를 알려주는 튜토리얼은 구식입니다.

"어디서나" 옵션이 숨겨져 있습니다. 이전 macOS에서는 보안 및 개인 정보 보호 창에서 Gatekeeper를 "어디서나"에서 앱을 허용하도록 설정할 수 있었습니다. 해당 라디오 버튼은 몇 년 전에 UI에서 제거되었으며 Tahoe에서도 숨겨져 있습니다. 명령줄을 통해 유사한 상태를 표면화할 수 있지만 Apple은 "모든 것을 신뢰"하는 태도가 위험하기 때문에 의도적으로 도달하기 어렵게 만들었습니다.

spctl --master-disable이 광고된 대로 작동하지 않습니다. 많은 오래된 가이드에서 Gatekeeper를 완전히 끄고 "어디서나" 옵션을 다시 표시하기 위해 sudo spctl --master-disable을 실행하라고 합니다. 최신 macOS에서 이 명령어의 효과는 제한됩니다: 성공을 보고할 수 있지만 Gatekeeper 보호(특히 공증 및 전위 동작)는 예를 들어 macOS 10.14에서처럼 완전히 비활성화되지 않습니다. 시스템 무결성 보호와 재설계된 보안 아키텍처는 단일 명령어가 전체 하위 시스템을 깨끗하게 끌 수 없음을 의미합니다. spctl --master-disable을 중심으로 구축된 가이드는 구식으로 취급하세요.

전반적으로 더 의도적인 마찰. Tahoe 접근 방식의 일관된 주제는 의도적인 마찰입니다. Apple은 확인되지 않은 앱을 승인하는 것이 반사적인 오른쪽 클릭이 아닌 시스템 설정에서 내린 의식적이고 인증된 결정이길 원합니다. 이 특정 릴리스의 전체 보안 및 CVE 그림은 macOS Tahoe 26.5 릴리스 업데이트 가이드를 참조하세요.

기업 및 MDM 참고 사항

조직에서 Mac을 관리한다면 일반 사용자에게 없는 옵션이 있으며, 사용자에게 xattr 명령어를 실행하도록 가르치지 않아야 합니다. 모바일 기기 관리(MDM)를 사용하면 기기별이 아닌 규모에 맞게 신뢰를 배포할 수 있습니다. 개인 정보 보호 기본 설정 정책 제어(PPPC) 프로필과 Gatekeeper 관련 구성 프로필을 배포하여 특정 개발자 신원을 사전 승인하면 내부적으로 배포되고 승인된 타사 앱이 Gatekeeper 프롬프트 없이 실행됩니다. 내부 도구에 대해서도 올바르게 서명 및 공증된 내부 빌드가 올바른 장기적 답입니다. Developer ID 비용을 지불하고, 서명하고, 내부 앱을 공증하면 직원들에게 해제하도록 요청하는 대신 Gatekeeper를 기본적으로 통과합니다.

플릿 전체 Gatekeeper 비활성화 유혹을 피하세요. 조직의 모든 Mac을 소프트 타겟으로 만들고 공격자가 찾기를 바라는 정확한 태도입니다. 플릿에서 로그인 시 실행되는 항목도 관리한다면 Tahoe 로그인 항목 및 백그라운드 앱 관리 가이드가 실행되는 항목과 시기를 제어하는 Gatekeeper 정책과 잘 어울립니다.

일반적인 문제 해결

문제: 개인 정보 보호 및 보안에서 "어쨌든 열기" 버튼이 표시되지 않음

해결 방법: 이것은 거의 항상 받은 다이얼로그가 부드러운 "개발자를 확인할 수 없음"이 아닌 가혹한 "손상됨" 변형(서명 손상/없음)이라는 것을 의미합니다 — Apple은 실제로 잘못된 서명에 대해 GUI 재정의를 제공하지 않습니다. 먼저 App Translocation을 배제하기 위해 앱을 다운로드/DMG에서 /Applications로 이동한 다음 다시 실행하여 macOS가 새 차단을 등록하도록 합니다. 버튼이 여전히 표시되지 않으면 Safari를 사용하여 공식 사이트에서 앱을 다시 다운로드하세요. 일관되게 손상된 상태로 다운로드되면 개발자의 빌드 자체가 문제일 수 있습니다. 신뢰하는 앱에 대한 최후 수단으로 xattr -dr com.apple.quarantine을 사용하세요.

문제: xattr을 실행할 때 Terminal이 "Operation not permitted" 표시

해결 방법: 이것은 구문이 아닌 권한 문제입니다. macOS는 특정 위치를 보호하며 터미널 앱에 전체 디스크 접근 권한이 없을 수 있습니다. 시스템 설정 > 개인 정보 보호 및 보안 > 전체 디스크 접근으로 이동하여 터미널(Terminal.app, iTerm 등)을 활성화한 다음 완전히 종료하고 다시 실행합니다. 또한 올바른 경로를 입력했는지 확인하세요 — 앱을 Terminal 창으로 드래그하면 정확한 경로가 삽입됩니다. 앱이 보호된 위치에 있는 경우 먼저 /Applications로 복사하고 거기서 작업하면 제한을 우회할 수 있습니다.

문제: 앱이 한 번 열리지만 업데이트 후 다시 손상되거나 "손상됨"이 됨

해결 방법: 이것은 App Translocation 또는 업데이터의 손상된 서명과 싸우는 자체 업데이트 앱을 가리킵니다. 앱이 전위될 때 제자리 자체 업데이터가 오작동하므로 앱이 /Applications에 있는지(다운로드 아님) 확인하세요. 앱이 각 업데이트 후 스스로를 다시 격리하면 업데이터가 격리 인식 메커니즘을 통해 다시 다운로드할 수 있습니다. 가장 깨끗한 수정은 앱을 삭제하고, 공식 소스에서 새 복사본을 다운로드하고, /Applications로 드래그하고, "어쨋든 열기"를 통해 한 번 승인한 다음 거기서 향후 업데이트가 실행되도록 하는 것입니다.

문제: 온라인 상태임에도 "악성 소프트웨어 없음을 확인할 수 없음"

해결 방법: 먼저 date로 시스템 클록을 확인하세요 — 잘못된 날짜는 티켓 검증을 깨뜨립니다. 그런 다음 Apple의 공증 서버를 차단하는 프록시, VPN, 또는 방화벽 뒤에 있지 않은지 확인하세요. 제한적인 VPN을 일시적으로 비활성화하고 다시 시도하면 해결되는 경우가 많습니다. spctl -a -vvv /path/to/App.app을 실행하여 정확한 판정을 확인하세요. 연결이 복원된 후 spctl이 앱을 허용됨/공증됨으로 보고하면 원래 실패는 순전히 네트워크/클록 문제였지 앱이 아닙니다.

자주 묻는 질문

xattr을 사용하여 격리 속성을 제거하는 것이 안전합니까?

신뢰하는 출처의 신뢰하는 특정 앱에 적용될 때만 안전합니다. 명령어 자체는 시스템에 해를 끼치지 않습니다. 위험은 전적으로 무엇을 가리키느냐에 있습니다. 격리를 제거하면 해당 앱에 대한 Gatekeeper의 검사가 해제되므로 의심스러운 소프트웨어에 실행하면 깨끗한 Mac이 감염되는 방법이 됩니다. 개발자 사이트의 신뢰할 수 있는 앱: 괜찮습니다. 무작위 "크랙된" 다운로드: 절대 하지 마세요.

Gatekeeper를 비활성화하면 악성 소프트웨어가 감염됩니까?

시스템 전체에서 Gatekeeper를 비활성화하면 노출이 크게 증가합니다. Gatekeeper는 공격자가 사용하는 가장 쉬운 경로 — 서명되지 않고 공증되지 않은 코드를 실행하도록 유도하는 것 — 를 차단합니다. 끄면 모든 다운로드가 검사 없이 실행됩니다. 개별 사용자가 전역적으로 비활성화할 좋은 이유는 거의 없습니다. "어쨌든 열기"를 통해 하나의 앱을 승인하면 다른 모든 것에 대해 문을 열어두지 않고 목표를 달성합니다. Gatekeeper를 계속 켜두세요.

Terminal에서 xattr을 실행할 때 "operation not permitted"가 표시되는 이유는 무엇입니까?

터미널 앱에 전체 디스크 접근 권한이 없거나 시스템 보호 위치를 대상으로 하고 있습니다. 시스템 설정 > 개인 정보 보호 및 보안 > 전체 디스크 접근에서 접근 권한을 부여하고, 터미널을 활성화한 다음 종료하고 다시 실행합니다. 앱을 Terminal 창으로 드래그하여 경로가 올바른지 확인하세요. 이것은 macOS 개인 정보 보호 보호 기능이 작동하는 것이지 명령어의 버그가 아닙니다.

Tahoe에서 오른쪽 클릭 "열기" 트릭이 여전히 작동합니까?

아닙니다. Apple은 macOS 15/26 세대에서 오른쪽 클릭 → 열기 일회성 우회를 제거했으며 Tahoe 26.5에서도 계속됩니다. 차단된 앱을 여는 유일한 공인 방법은 시스템 설정 > 개인 정보 보호 및 보안의 "어쨋든 열기" 버튼이며 인증이 필요합니다. 오른쪽 클릭 → 열기를 여전히 권장하는 가이드는 구식입니다.

앱이 어제는 작동했는데 지금은 손상됐다고 합니다. 왜 그렇습니까?

이 패턴에 맞는 몇 가지 원인이 있습니다: 개발자의 서명 인증서가 취소되었거나, 앱 내 업데이트가 손상되었거나 공증되지 않은 빌드를 도입했거나, 앱이 업데이트 중 스스로를 다시 격리했거나, 또는 시스템 클록이 드리프트되어 티켓 검증이 깨졌습니다. 먼저 date를 확인한 다음 공식 소스에서 새 복사본을 다시 다운로드하고 한 번 승인하세요. 계속 반복된다면 개발자에게 보고하세요.

"App Translocation"이 격리 속성과 같습니까?

아닙니다, 관련이 있지만 다릅니다. 격리는 파일이 다운로드되었음을 표시하는 속성입니다. App Translocation은 앱이 격리되어 다운로드 위치에서 실행될 때문에 macOS가 트리거하는 방어적 동작입니다 — 사이드 로드된 파일 공격을 저지하기 위해 무작위화된 읽기 전용 경로에서 앱을 실행합니다. 앱을 /Applications로 이동하면 전위가 중지되고, 격리 속성을 제거하면 플래그 지정이 중지됩니다. 다른 메커니즘, 다른 수정 방법입니다.

결론

macOS Tahoe의 "앱이 손상되어 열 수 없음" 오류는 대부분 손상 문제가 아닌 신뢰 문제입니다. Gatekeeper, com.apple.quarantine 속성, 공증은 Mac이 확인할 수 없는 코드를 실행하지 못하도록 함께 작동합니다 — 대부분의 경우 정상적인 앱은 격리 플래그, App Translocation, 부주의한 압축 해제로 인한 손상된 서명, 아키텍처 불일치, 또는 잘못된 클록 때문에 이를 트리거합니다. 다이얼로그를 읽어 세 가지 문제 중 어느 것인지 파악하고, 먼저 개인 정보 보호 및 보안의 공식 "어쨌든 열기" 경로를 시도하고, 무엇을 교환하는지 이해할 때만 xattr, spctl, codesign에 손을 뻗으세요. 무엇보다 기억해야 할 한 가지 규칙: 앱의 안전성은 얼마나 깨끗하게 강제로 실행할 수 있느냐가 아니라 출처에서 옵니다.

Mac을 올바르게 보호하는 방법에 대한 자세한 내용은 2026년 Mac 보안 및 개인 정보 보호 가이드와 macOS Tahoe 보안 및 개인 정보 보호 완전 가이드로 계속하세요.