BlueByte
app is damagedWorkaround

macOS: "앱이 손상되어 열 수 없습니다"

작성 Haneul Seo2026년 8월 17일 업데이트5 min

안녕하세요, BlueByte입니다. 그 앱을 휴지통에 넣기 전에 — 거의 확실히 손상된 게 아닙니다. macOS가 웹에서 온 미공증 앱을 실행하기를 거부하며 그걸 "손상됨"이라 표현하는 것입니다. 오늘은 그게 지금 벌어지는 일인지 확인하고, 출처를 신뢰할 때만 막고 있는 플래그를 지우는 순서로 가보겠습니다.

이 메시지가 정말 뜻하는 것

받은 앱을 열 때 실패합니다:

"App" is damaged and can't be opened. You should move it to the Trash.

앱이 손상된 경우는 대개 아닙니다. macOS Gatekeeper가 인터넷에서 왔고 공증되지 않은 앱을 실행하기를 거부하며, 최근 macOS는 그 거부를 예전의 "확인되지 않은 개발자" 대신 "손상됨"으로 표현합니다. 문구가 놀라워 멀쩡한 소프트웨어를 버리기도 하는데 — 실제 문제는 손상이 아니라 보안 플래그입니다.

Gatekeeper가 막는 이유

파일이 다운로드되면 macOS가 com.apple.quarantine 확장 속성을 붙입니다. Gatekeeper가 첫 실행 때 그 태그를 확인하고, 앱이 미서명·미공증이면 차단합니다. 배제할 두 번째 실제 가능성이 있습니다: 다운로드가 정말 불완전·손상된 경우 — 이땐 태그 제거로 해결 안 됩니다 — 그리고 Apple 실리콘에서 Rosetta가 필요한 Intel 전용 앱은 비슷하지만 다른 안내를 냅니다.

손상이 아니라 격리인지 확인

추측하지 말고 격리 속성이 실제로 있는지 확인:

xattr -p com.apple.quarantine /Applications/App.app

값을 출력하면 격리가 원인입니다. 그다음 다운로드가 온전한지 확인 — 배포처가 제공하면 크기·체크섬을 대조하세요. 크기 불일치는 Gatekeeper 우회가 아니라 재다운로드입니다.

플래그 지우기 — 신뢰하는 소프트웨어에만

  1. 출처를 신뢰하는지 확인. 이 단계는 보안 검사를 없애므로 신뢰하는 사이트의 소프트웨어에만 하세요.

  2. 앱에서 격리 속성을 제거:

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

-r은 번들 안 전체에서 제거합니다. 경로를 실제 위치로 바꾸세요.

  1. 앱을 정상적으로 엽니다. macOS가 여전히 물으면 앱 우클릭 → 열기 후 확인하면 그 앱에 대한 승인이 기록됩니다.

실제 사례: GitHub 릴리즈

오픈소스 도구를 공식 GitHub 릴리즈 페이지에서 받아 Applications에 끌어놓았더니 macOS가 "손상됨"이라고 합니다. xattr -p com.apple.quarantine /Applications/Tool.app이 격리 값을 출력해 손상이 아니라 Gatekeeper임을 확인합니다. GitHub 릴리즈를 신뢰하고(릴리즈 페이지의 체크섬이 다운로드와 일치) xattr -dr com.apple.quarantine /Applications/Tool.app을 실행합니다. 다음 실행에서 앱이 열리고 xattr -p는 이제 아무것도 반환하지 않습니다.

플래그가 사라졌는지 확인

앱을 실행하면 경고 없이 열려야 합니다. xattr -p를 다시 실행해 아무것도 안 나오면 — 앱이 한 번 우연히 열린 게 아니라 — 격리 플래그가 제거된 것입니다.

다시 겪지 않으려면

가능하면 공증된 빌드와 Mac App Store를 선호하고, 웹에서 설치할 땐 검증 가능한 배포처를 고수하세요. 직접 배포하는 소프트웨어는 Apple 공증을 받으면 사용자에게 이 안내가 아예 안 나옵니다.

Rosetta·공증 안내와의 구분

이건 Gatekeeper이지 아키텍처 문제가 아닙니다. Apple 실리콘에서 Intel 전용 앱은 대신 Rosetta 설치를 안내 — 다른 메시지입니다. "Apple이 악성 소프트웨어를 확인할 수 없어 열 수 없음"은 공증 대기 중의 더 순한 변형으로, 같은 우클릭 → 열기로 풀립니다. "손상됨"이라 하면 먼저 격리 속성을 확인하세요.

관련 질문

앱이 실제로 손상된 건가요?

대개 아닙니다. 이 메시지는 인터넷에서 온 미서명·미공증 앱에 대한 Gatekeeper의 반응입니다. 다시 받아 체크섬이 맞으면 파일은 정상입니다.

격리 속성을 제거해도 안전한가요?

macOS 보안 검사를 우회하는 것이니, 신뢰하는 출처의 소프트웨어에만 하세요. 알 수 없는 것은 보호를 그대로 두세요.

우클릭 → 열기가 아무것도 안 합니다.

더 엄격한 macOS 버전에선 '손상됨' 변형이 열기 우회를 제공하지 않습니다. 대신 xattr 명령으로 격리 속성을 제거하세요.

격리를 제거했는데도 안 열립니다.

다운로드가 정말 불완전하거나, Apple 실리콘에서 Rosetta가 필요할 수 있습니다. 다시 받아 체크섬을 확인하고 별도 Rosetta 안내를 살피세요.

macOS가 다운로드를 격리하는 걸 아예 끌 수 없나요?

spctl로 Gatekeeper를 낮출 수 있지만 시스템 전체 보호가 약해집니다. 신뢰하는 앱마다 속성을 제거하는 게 검사를 끄는 것보다 훨씬 안전합니다.

참고 자료

Haneul Seo

Infrastructure engineer · 10+ years running Linux fleets

같은 카테고리 다른 글

Start request repeated too quicklyFixed

systemd: Start request repeated too quickly

systemd는 StartLimitIntervalSec(기본 10초) 안에 StartLimitBurst(기본 5회)보다 많이 시작된 유닛의 시작을 거부하며, Restart=도 이 제한에 포함됩니다. 기본 RestartSec 100ms로는 크래시하는 서비스가 1초도 안 되어 다섯 번을 소진합니다. 저널에서 진짜 크래시를 찾아 고치고, reset-failed를 실행한 뒤, RestartSec로 재시작에 여유를 주세요.

systemd
Too many authentication failuresFixed

SSH: Received disconnect ... Too many authentication failures

agent가 서버가 허용하는 것보다 많은 키를 내밀고 있습니다. sshd가 들여다보는 공개키 하나하나가 MaxAuthTries 시도를 한 번씩 소모하고 — 기본 6회, 하드닝된 호스트에서는 3회인 경우가 많습니다 — 정작 맞는 키는 차례가 오기 전에 연결이 끊깁니다. IdentitiesOnly=yes와 명시적 IdentityFile로 키 하나를 고정하면 시도 횟수가 1로 떨어집니다.

OpenSSH
1722Fixed

Active Directory: 복제가 error 1722(The RPC server is unavailable)로 실패

RPC는 하위 계층이 연결에 실패했을 때 1722(0x6ba, RPC_S_SERVER_UNAVAILABLE)를 보고합니다. 따라서 진짜 원인은 RPC 자신이 아니라 DNS, 차단된 포트, 두 도메인 컨트롤러 중 한쪽의 호스트 설정입니다. repadmin이 어느 파트너가 실패하는지 알려주고, dcdiag /test:dns가 이름 해석을 배제하며, Test-NetConnection과 동적 포트 범위가 방화벽 문제를 가릅니다. 가장 흔한 실수는 TCP 135만 허용하고 49152–65535는 막아 둔 규칙입니다.

Windows Server Active Directory
Windows Server RDSFixed

Windows Server RDS: The remote session was disconnected because there are no Remote Desktop License Servers available to provide a license

120일 RD Licensing 유예 기간이 끝났는데 세션 호스트가 쓸 수 있는 라이선스 서버가 없어 세션을 거부하는 상황입니다. GetGracePeriodDays 의 DaysLeft 가 0 이고 SpecifiedLSList 가 비어 있으면 몇 초 만에 확인됩니다. 해결은 활성화된 라이선스 서버와, 호스트 버전을 감당할 만큼 새 CAL 입니다. 2019 CAL 은 2022 세션 호스트를 서비스하지 못합니다. 여기에 배포 또는 Licensing 정책 설정과 두 서버 사이의 RPC 포트 개방이 따라옵니다.

Windows Server RDS
0x80070035 / Event ID 31017Workaround

Windows 11: NAS 공유 폴더를 열 때 "조직의 보안 정책이 인증되지 않은 게스트 액세스를 차단" (0x80070035)

Windows 10 Enterprise/Education/Pro for Workstations, Windows 11 Pro, Windows Server 2019 이후의 SMB 클라이언트는 기본적으로 게스트 로그온을 거부하고, Windows 11 24H2 Enterprise/Pro/Education 은 게스트 세션이 할 수 없는 SMB 서명까지 요구합니다. 그래서 게스트 접근만 제공하는 NAS 공유는 'block unauthenticated guest access' 대화상자, Error code 0x80070035, 또는 System error 3227320323 으로 실패하고, SmbClient/Security 로그에 Event ID 31017 'Rejected an insecure guest logon' 이 남습니다. Microsoft 가 권하는 해결은 NAS 에 실제 계정을 만들고 펌웨어에서 서명을 지원하게 하는 것입니다. Set-SmbClientConfiguration -EnableInsecureGuestLogons $true(24H2 는 -RequireSecuritySignature $false 까지)는 비상구이며, 그 클라이언트의 서명과 암호화를 포기하는 대가가 있습니다.

Windows (SMB client)
E: Could not get lock /var/lib/dpkg/lock-frontendFixed

Ubuntu/Debian: E: Could not get lock /var/lib/dpkg/lock-frontend — 누가 쥐고 있고 어떻게 기다리는지

다른 패키지 관리자, 대개 부팅 때 persistent systemd 타이머로 발화한 Ubuntu 의 unattended-upgrades 가 여러분의 apt-get 이 도는 동안 dpkg 프런트엔드 락을 쥐고 있는 것입니다. Ubuntu 는 apt 바이너리에만 binary::apt::DPkg::Lock::Timeout "120" 을 실어 두어서 apt-get 은 즉시 포기하고 apt 는 기다립니다. 메시지의 PID 를 읽고, 실행이 끝나게 두거나 apt-get 에 -o DPkg::Lock::Timeout=<초> 를 주고, dpkg --configure -a 는 실제로 중단된 실행 뒤에만 쓰고, 락 파일은 절대 지우지 마세요. 보유자가 종료하면 커널이 푸는 fcntl 락입니다.

APT (Ubuntu/Debian)