Mac이 화면 기록 권한을 계속 물어볼 때: 실제로 통하는 해결책
Mac이 화면 기록 권한을 계속 요청하거나, 이미 허용한 권한이 작동하지 않는다면? macOS TCC의 실제 작동 방식과 두 문제의 올바른 해결법을 정리했습니다.
Zoom을 열고 화면 공유를 누르면, macOS가 지난달에 띄웠던 것과 똑같은 대화상자를 다시 띄웁니다. Zoom이 화면을 기록해도 되는지 묻는 그 창 말입니다. 이미 허용했는데도요. 시스템 설정으로 가 보면 Zoom은 분명히 화면 및 시스템 오디오 기록 목록에 있고, 스위치도 켜져 있습니다. 고장 난 곳은 없습니다. 그런데도 또 물어봅니다.
일주일 뒤에는 전혀 다른 일이 벌어집니다. 백업 도구가 Mail 폴더를 읽지 못합니다. 전체 디스크 접근 권한을 확인해 보니 앱은 목록에 있고, 스위치도 켜져 있고, 있어야 할 모습 그대로입니다. 그런데 앱은 권한이 전혀 없는 것처럼 동작합니다. 느낌은 비슷하지만 이건 앞의 문제와 같은 문제가 아닙니다.
인터넷에서 찾을 수 있는 조언 대부분은 이 두 상황을 하나로 뭉뚱그려 다루고, 그래서 그 조언들이 그렇게 자주 실패합니다. 첫 번째는 의도된 동작입니다. Apple은 화면 캡처 권한에 주기적 재확인을 설계로 넣었고, 이를 끄는 스위치는 존재하지 않습니다. 두 번째는 원인이 분명하고 찾아낼 수 있는 진짜 결함이며, 거의 항상 한 가지로 귀결됩니다. macOS가 디스크에 있는 앱을 당신이 권한을 부여했던 그 앱과 같은 앱이라고 더 이상 믿지 않는다는 것입니다.
이 글은 그 둘을 분리하고, 두 문제의 밑바탕에 있는 서브시스템을 설명하며, 각각에 맞는 올바른 해결책을 제시합니다. 또한 이 주제에서 가장 흔하게 등장하는 조언 — chmod로 파일 권한을 바꾸라거나 일종의 권한 복구를 실행하라는 조언 — 이 실제 관련 시스템과 아무 상관이 없는 이유도 설명합니다. 아래에 나오는 모든 시연은 System Integrity Protection이 활성화된 macOS 26.5.2, 빌드 25F84를 실행하는 Mac에서 테스트했습니다.
핵심 요약
- 서로 다른 두 문제가 같은 얼굴을 하고 있습니다 — 화면 캡처의 예정된 재확인 요청은 설계된 동작이라 끌 수 없고, 허용했는데도 작동하지 않는 권한은 원인이 있는 실제 결함입니다.
- TCC는 권한을 앱의 경로가 아니라 코드 서명 신원에 묶습니다 — 업데이트 후, 앱을 옮긴 뒤, 또는 같은 앱의 사본이 디스크에 두 개 존재할 때 권한이 소리 없이 작동을 멈추는 이유가 바로 이것입니다.
tccutil reset이 Apple이 제공하는 유일한 명령입니다 — Terminal에서 권한을 부여하는 방법은 없으며, 번들 식별자 없이reset을 실행하면 Mac의 모든 앱에서 해당 권한이 지워집니다.- 개인정보 데이터베이스는
ls조차 허용하지 않습니다 — SIP가 켜진 테스트용 Mac에서 두 TCC 디렉터리 중 어느 쪽을 나열해도Operation not permitted가 반환되며, 이것이 이 문제가 일반적인 파일 권한과 무관하다는 가장 명확한 증거입니다. - Apple은 서비스 이름 목록을 공개하지 않습니다 —
ScreenCapture나SystemPolicyAllFiles같은 이름은 커뮤니티 지식이며, 이를 공식 문서인 양 제시하는 가이드는 추측하고 있는 것입니다.
TCC란 무엇이고 무엇이 아닌가
앱이 화면을 기록해도 되는지, Mail 폴더를 읽어도 되는지, 마이크를 써도 되는지, 다른 앱을 제어해도 되는지를 결정하는 서브시스템의 이름은 TCC입니다. 이 약자는 Transparency, Consent and Control(투명성, 동의, 제어)을 뜻합니다. 지금까지 당신이 클릭해 넘겼던 모든 "앱이 …에 접근하려고 합니다" 대화상자를 만들어내는 주체이고, 시스템 설정의 개인정보 보호 및 보안 아래 모든 목록을 채우는 주체이기도 합니다.
이 영역의 유일한 명령줄 도구에 대한 Apple의 man 페이지는 그것을 한 문장으로 설명합니다. NAME 항목에는 "tccutil – manage the privacy database"라고 적혀 있고, DESCRIPTION은 이렇게 확장합니다. "The tccutil command manages the privacy database, which stores decisions the user has made about whether apps may access personal data."
이 문장을 주의 깊게 읽어야 합니다. 표현이 정확하고, 시스템 전체의 형태를 알려주기 때문입니다. TCC는 결정을 저장합니다. 그것은 동의의 기록입니다. 파일에 대한 서술이 아니라, 애플리케이션과 보호 대상 데이터 범주 사이의 관계에 대한 서술입니다.
개인정보 데이터베이스는 파일 시스템이 아닙니다
이것이 다른 무엇보다 많은 시간을 낭비시키는 오해이므로, 먼저 정리하고 넘어갈 가치가 있습니다.
전통적인 Unix 파일 권한은 파일 자체에 저장된 속성입니다. 소유자, 그룹, 읽기/쓰기/실행 비트가 있고 chmod와 chown으로 변경합니다. 이들은 "어떤 사용자 계정이 이 파일을 건드릴 수 있는가?"라는 질문에 답합니다.
TCC는 완전히 다른 질문에 답합니다. "사용자가 어떤 애플리케이션에게 이 범주의 데이터를 읽도록 동의했는가?" 주체는 사용자 계정이 아니라 애플리케이션입니다. The Eclectic Light Company의 Howard Oakley는 2025년 11월 권한과 개인정보에 관한 해설에서 이 차이를 잘 정리했습니다. "privacy protection operates outside of file attributes, using a rule-based system applied to each app."
실질적 결과는 절대적입니다. 당신의 사용자 계정은 이미 ~/Library/Mail을 소유하고 있고, POSIX 비트도 이미 읽어도 된다고 말합니다. 당신 계정으로 실행한 터미널 명령은 읽을 수 있는데 GUI 앱은 읽지 못하는 이유가 바로 그것입니다. 파일 권한은 애초에 장애물이 아니었습니다. TCC가 장애물이었습니다.
그러므로 chmod를 아무리 써도 TCC 문제는 해결되지 않습니다. 어떤 "권한 복구" 루틴도 마찬가지입니다. 그 개념은 APFS 이전 시대에 리시트 데이터베이스를 대상으로 하던 것이며, Apple은 몇 년 전에 Disk Utility에서 제거했습니다. 화면 기록 요청을 없애겠다고 홈 폴더 전체에 sudo chmod -R 755를 실행하는 것은 도움이 되지 않고, Library 폴더를 망가뜨릴 수 있습니다. 하지 마십시오.
나열조차 할 수 없는 데이터베이스
TCC 데이터베이스는 두 개입니다. 사용자별 데이터베이스는 ~/Library/Application Support/com.apple.TCC/ 아래에 있으며 당신 계정에 적용되는 결정을 담습니다. 시스템 전역 데이터베이스는 /Library/Application Support/com.apple.TCC/에 있으며, 관리자나 MDM 프로파일이 설정할 수 있는 것들을 포함해 머신 전체에 적용되는 결정을 담습니다.
논쟁을 끝내는 시연은 이렇습니다. SIP가 켜진 테스트용 Mac에서 다음 두 명령을 시도했습니다.
ls ~/Library/Application\ Support/com.apple.TCC/
ls /Library/Application\ Support/com.apple.TCC/둘 다 Operation not permitted를 반환했습니다. POSIX 실패에서 보이는 "permission denied"가 아니라, System Integrity Protection이 접근 자체를 차단할 때 커널이 내놓는 응답입니다. SIP가 활성 상태임도 확인했습니다. csrutil status는 System Integrity Protection status: enabled.를 반환했습니다.
이 디렉터리를 나열할 수도, 안에 있는 데이터베이스를 읽을 수도, 편집할 수도 없습니다. 어떤 가이드가 SQLite 브라우저로 TCC.db를 열어 행을 삽입하라고 한다면, 그것은 SIP가 꺼진 머신을 설명하고 있는 것이며, 대화상자 하나를 우회하려고 SIP를 끄는 것은 Mac 방어 구조의 상당 부분을 내주는 거래입니다. 이 글은 그 방법을 알려주지 않습니다.
당신이 할 수 있는 일은 시스템 설정 인터페이스로 권한을 부여하거나, tccutil로 결정을 재설정하거나, MDM 프로파일이 대신 결정을 기록하게 하는 것입니다. 문은 이 세 개입니다. 네 번째는 없습니다.
왜 이런 설계인가
TCC 결정이 평범한 편집 가능한 파일에 들어 있다면, 홈 폴더에 쓰기 권한이 있는 어떤 앱이든 자기 자신에게 화면 기록, 카메라 접근, Mail 폴더 사용 권한을 조용히 부여할 수 있을 것입니다. 그러면 보호는 무의미해집니다. 그래서 Apple은 결정을 SIP 뒤에 두고, 지원되는 유일한 쓰기 경로를 시스템이 그리는 대화상자와의 사용자 상호작용으로 만들고, 명령줄 도구에는 정확히 한 개의 동사만 주었습니다. reset입니다.
이는 일관성 있는 설계이지만, 밤 11시에 망가진 권한을 고치려는 사람 입장에서는 매우 작은 연장통입니다. 이 글의 대부분은 그 연장통을 잘 쓰는 방법에 관한 것입니다. macOS가 Gatekeeper, 공증, SIP, TCC를 어떻게 층층이 쌓는지에 대한 더 넓은 맥락은 macOS Tahoe 보안 및 개인정보 보호 완전 가이드에서 주변 아키텍처를 다룹니다.
서로 다른 두 문제
이제 이 글의 나머지가 의존하는 구분으로 넘어갑니다.
문제 1: 의도된 재확인 요청
2024년 macOS 15 Sequoia 베타 주기 동안 Apple은 화면 및 오디오 캡처에 대한 주기적 재확인을 도입했습니다. 화면을 캡처하는 모든 앱은 일정 주기로 재확인을 요구받게 되었고, 여기서 빠져나갈 방법은 없습니다.
초기 베타 동작은 매주였고, 재시동할 때마다도 다시 물었습니다. 이는 상당한 대중적 비판을 불렀습니다. MacRumors는 2024년 8월에 "popups for screen recording app permissions have been showing weekly up throughout the beta testing process, but Apple has tweaked the frequency in response to user feedback"라고 보도하며 베타가 월 단위 재승인으로 옮겨갔다고 전했습니다. 9to5Mac과 iDownloadBlog도 같은 베타에서 같은 변경을 보도했습니다. 재시동마다 뜨던 요청도 같은 시점에 없어졌습니다. 대화상자는 "Allow For One Month" 버튼과 시스템 설정을 여는 옵션을 제공하며, 당시 MacRumors는 "it does not appear that there is a way for users to permanently give screen recording access to recording functionality, but a monthly popup is at least more convenient than a weekly popup"이라고 언급했습니다.
이제 솔직해질 부분입니다. macOS 26 세대의 현재 주기는 어떤 권위 있는 출처로도 확인할 수 없었습니다. 이 패널에 대한 Apple 자체 지원 문서인 macOS Tahoe 26 Mac 사용 설명서의 "Allow apps to use screen and audio recording"은 패널을 여는 방법과 대화상자에 답하는 방법을 설명할 뿐, 주기적 재승인에 대해서는 아무 말도 하지 않습니다. macOS 26을 다루는 2차 출처들은 서로 모순되어 어떤 곳은 매주, 어떤 곳은 매월이라 하고, 어느 쪽도 근거를 제시하지 않습니다.
그래서 자신 있게 말할 수 있는 것과 없는 것은 이렇습니다. 확인됨: 주기적 재확인은 Sequoia 주기에 도입되었고, 화면 및 시스템 오디오 캡처에 적용되며, 한 달짜리 허용을 제공하고, 사용자가 끌 수 있는 스위치는 없습니다. 확인됨: 이 패널에 대한 Apple의 현재 지원 문서는 이를 전혀 언급하지 않습니다. 확인되지 않음: macOS 26 세대에서의 정확한 간격. Mac이 대략 한 달에 한 번 다시 묻는다면, 그것은 Apple이 Sequoia에서 출시한 동작과 일치합니다. 훨씬 더 자주 묻는다면 아래의 결함 진단을 읽으십시오. 잦은 재요청은 다른 문제입니다.
문제 1에 대해 알아야 할 가장 유용한 사실은 이것이 결함이 아니며 고칠 것이 없다는 점입니다. 허용을 클릭하는 데는 1초가 걸리고, 대화상자 자체가 재확인이므로 시스템 설정에서 무언가를 다시 켤 필요가 없습니다. 매달 뜨는 요청에 대응해 재설정하거나, 재설치하거나, 뭔가를 편집하라고 말하는 모든 가이드는 건강한 환자에게 치료제를 파는 셈입니다.
개발자 측의 예외가 하나 있습니다. Apple에는 반복되는 요청을 억제하는 com.apple.developer.persistent-content-capture라는 엔타이틀먼트가 있고, Michael Tsai의 블로그가 2024년 8월에 이를 둘러싼 개발자 논의를 모아 두었습니다. 이는 원격 제어 및 VNC 계열 애플리케이션을 겨냥한 관리형 기능으로, 개발자가 Apple에 신청해 승인을 받아야 합니다. 사용자가 켤 수는 없습니다. 소수의 원격 접속 앱이 결코 당신을 귀찮게 하지 않는 이유를 설명해 줄 뿐입니다.
문제 2: 붙지 않는 권한 부여
이쪽은 진짜 결함입니다. 패널에 등록되어 있고 스위치도 켜져 있는데 권한이 없는 것처럼 동작하는 앱, 업데이트 후 패널에서 사라진 앱, 종료 후 다시 실행하기 전까지만 작동하는 권한, 같은 앱 이름의 항목 두 개, +로 추가해도 패널에 절대 나타나지 않는 도구, 한 달에 한 번이 아니라 실행할 때마다 뜨는 요청 등의 모습으로 나타납니다.
이 모두에는 원인이 있고, 대부분은 하나의 원인을 공유합니다. 그것이 다음 주요 섹션의 내용입니다.
여기 속할 것처럼 보이지만 속하지 않는 것이 하나 있습니다. 로그인 키체인 암호를 반복해서 묻는 Mac입니다. 그것은 TCC가 아니라 키체인 서브시스템이며, 이 글의 어떤 내용도 그 문제를 해결하지 못합니다. 그 증상이라면 로그인 키체인 암호 요청 해결법이 올바른 영역을 다룹니다.
당신의 문제는 어느 쪽인가
| 증상 | 어느 문제 | 할 일 |
|---|---|---|
| 대략 한 달에 한 번 화면 캡처 요청, 허용 후 앱은 정상 작동 | 설계된 동작 | 허용을 클릭하십시오. 잘못된 것은 없습니다. |
| 실행할 때마다 요청 | 결함 | 서명 신원 또는 사본 중복 문제. 아래 참조. |
| 패널에서 켜져 있는데 앱이 여전히 못 함 | 결함 | 옛 신원에 묶인 낡은 항목. 깨끗한 재부여. |
| 업데이트 후 앱이 패널에서 사라짐 | 결함 | 서명이 바뀜. 다시 부여. |
| 패널에 같은 이름 항목이 두 개 | 결함 | 디스크에 사본이 둘. 찾아서 하나 제거. |
| CLI 도구는 작동하는데 패널에 안 보임 | 알려진 macOS 26.1 버그 | 명령줄 섹션 참조. |
| 요청이 뜨고 허용을 눌러도 아무 일 없음 | 결함 | 앱이 완전히 종료되지 않은 경우가 많음. 깨끗한 재부여. |
| 프로파일 안내와 함께 스위치가 회색 처리됨 | 관리되는 Mac | 기기를 관리하는 담당자에게 문의. |
| 캡처가 아닌 권한이 매달 다시 물음 | 결함 | 예정된 재확인이 있는 것은 화면 캡처뿐입니다. |
macOS 26 세대에서 각 권한이 있는 위치
이 패널들은 모두 같은 뿌리 아래에 있습니다. 시스템 설정을 열고 사이드바에서 개인정보 보호 및 보안을 클릭한 뒤 범주를 선택하십시오. 이 글과 관련된 범주는 다음과 같습니다.
- 화면 및 시스템 오디오 기록. macOS 26 세대에서 이름이 바뀌었습니다. 이전에는 화면 기록이었습니다. Apple의 설명은 한 줄입니다. "Allow apps to record your screen and audio, or just your audio. The listed apps have access."
- 전체 디스크 접근 권한. 시스템 전반의 보호된 사용자 데이터입니다. Mail, Messages, Safari 데이터, Time Machine 백업, 그리고 다른 앱들의 컨테이너 폴더가 포함됩니다.
- 손쉬운 사용. Mac을 제어할 수 있는 능력입니다. 포인터 이동, 클릭, 윈도우 내용 읽기, 다른 애플리케이션 인터페이스 조작이 여기에 해당합니다.
- 자동화. 특정 앱이 다른 특정 앱에 Apple 이벤트를 보낼 권리입니다. 평면 목록이 아니라 쌍으로 구성된 유일한 패널입니다.
- 파일 및 폴더. 세분화된 폴더 접근입니다. 데스크탑, 서류, 다운로드, 이동식 및 네트워크 볼륨이 대상입니다. 전체 디스크 접근 권한이 있는 앱은 여기에 항목이 필요 없습니다.
- 입력 모니터링. 앱이 최상위가 아닐 때도 키 입력을 볼 수 있게 합니다.
- 카메라와 마이크. 이름 그대로입니다. 특히 마이크가 말썽이라면 입력 권한 체인에는 나름의 특이점이 있고, macOS Tahoe 26.5에서 Mac 마이크가 작동하지 않을 때 해결법 가이드에서 다룹니다.
- 로컬 네트워크. 비교적 새로운 항목이며, 차단된 로컬 네트워크 권한이 개인정보 문제처럼 전혀 보이지 않는 증상을 만들어내기 때문에 혼란의 흔한 원인입니다. 응답하지 않게 된 프린터가 대표적인 예이며, AirPrint와 로컬 네트워크 개인정보 문제 해결법에서 단계별로 다룹니다.
나중에 중요해지는 구조적 사실 두 가지가 있습니다. 당신이 보는 목록은 데이터베이스의 렌더링이며, 아래에서 설명할 macOS 26.1 버그는 데이터베이스가 맞는데도 렌더링이 틀릴 수 있음을 증명했습니다. 그리고 - 버튼으로 항목을 제거하는 것은 앱을 거부하는 것이 아니라 결정을 삭제하는 것이므로, 다음에 앱이 요청할 때 새 요청 대화상자를 받게 됩니다. 이 구분이 깨끗한 재부여 절차의 근거입니다.
부여된 권한이 작동을 멈추는 이유
메커니즘은 이렇습니다. 이 한 가지를 이해하면 이 영역의 혼란스러운 동작 대부분이 예측 가능해집니다.
TCC는 경로나 이름이 아니라 코드 서명 신원에 묶입니다
앱에 권한을 부여할 때 macOS는 "/Applications/Foo.app에 있는 파일이 화면을 기록해도 된다"고 기록하지 않습니다. 앱의 코드 서명 신원, 즉 식별자와 누가 서명했는지를 기술하는 암호학적 요구사항에 묶인 결정을 기록합니다. Apple의 기술 노트 TN3127, "Inside Code Signing: Requirements"가 그 요구사항이 어떻게 구성되는지에 대한 레퍼런스입니다.
그 결과는 아무도 말해 주지 않는 것입니다. 서명 신원이 바뀌면 macOS는 그 앱을 아무것도 부여받은 적 없는 다른 애플리케이션으로 취급합니다. 옛 항목은 패널에 남아 부여된 것처럼 보이지만, 데이터베이스가 기억하는 형태로는 더 이상 존재하지 않는 앱을 가리키고 있습니다. 당신 눈에는 켜진 스위치가 보입니다. 시스템 눈에는 낯선 자가 보입니다.
앱의 신원은 직접 확인할 수 있습니다. 테스트용 Mac에서는 이렇게 했습니다.
codesign -dv --verbose=2 /System/Applications/Utilities/Terminal.app출력에는 시스템이 사용하는 번들 식별자인 Identifier 줄(Terminal의 경우 com.apple.Terminal), 서명한 인증서들을 나열하는 일련의 Authority 줄, 그리고 TeamIdentifier 줄이 포함됩니다. Apple이 기본 제공하는 앱의 경우 TeamIdentifier는 not set으로 나옵니다. Apple은 서드파티 개발자와 다른 인증 체인으로 시스템 소프트웨어에 서명하기 때문입니다. 서드파티 앱이라면 10자리 팀 식별자와 Developer ID 인증서를 포함한 인증 체인이 보여야 합니다.
그 팀 식별자가 안정적인 기준점입니다. 팀 식별자 없이 애드혹으로 서명된 앱은 코드 해시만으로 식별되는데, 코드 해시는 빌드할 때마다 바뀝니다. Developer ID로 서명된 앱은 업데이트를 거쳐도 유지되는 안정적인 팀 신원을 갖습니다. 일부 앱이 업데이트할 때마다 다시 묻고 대부분은 그러지 않는 이유가 이것입니다.
이제 구체적인 사례들입니다.
사례 1: 앱이 업데이트되면서 다르게 서명됨
앱이 새 버전을 출시했습니다. 새 빌드가 다른 인증서로 서명되었거나, 개발자가 애드혹 서명에서 Developer ID로 옮겼거나, 그 반대이거나, 인증서가 만료되어 새 인증서로 다시 서명했습니다.
알아보는 법: 시점이 업데이트와 정확히 맞아떨어지고, 앱이 패널에서 사라졌거나 두 번째 항목이 생겼습니다.
해결: 낡은 항목을 제거하고 다시 부여하십시오. 그 외에 할 일은 없습니다. TCC 입장에서 그 앱은 진짜로 새로운 앱입니다.
사례 2: 디스크에 같은 앱의 사본이 두 개
이것이 "켜져 있는데 작동하지 않는" 증상의 가장 흔한 원인이며, 가장 놓치기 쉬운 원인이기도 합니다.
앱을 내려받아 ~/Downloads에서 한 번 실행하고 권한을 부여한 다음, 나중에 /Applications로 끌어다 놓았을 수 있습니다. 혹은 이미 사본이 있는 상태에서 Homebrew Cask가 또 하나를 설치했거나, /Applications에 릴리스 빌드를, ~/Applications에 베타를 두고 쓰고 있을 수도 있습니다. 패널에는 앱 이름과 아이콘이 있는 한 줄만 보이고, 그 줄이 어느 사본을 가리키는지는 알려주지 않습니다. 당신은 /Applications의 사본을 실행하면서 ~/Downloads 사본에 대한 권한 부여를 보고 있는 것입니다.
알아보는 법: 디스크의 모든 사본을 검색하십시오.
mdfind "kMDItemKind == 'Application'" -name "AppName"또는 Spotlight가 색인하지 못했을 수 있는 사본까지 훑으려면 이렇게 합니다.
find /Applications ~/Applications ~/Downloads ~/Desktop -maxdepth 3 -name "AppName.app" 2>/dev/null경로가 하나보다 많이 돌아온다면 그것이 답입니다.
해결: 원하지 않는 사본을 삭제하고 정확히 하나만 남긴 다음, 남은 것에 대해 깨끗한 재부여를 수행하십시오. 삭제를 건너뛰지 마십시오. 두 번째 사본을 디스크에 남겨두면 한 달 뒤 다시 이 자리로 돌아오게 됩니다.
사례 3: 권한 부여 후 앱이 이동됨
사례 2와 관련되지만 별개입니다. 사본은 하나뿐인데 위치가 바뀌었습니다. 어떤 앱은 이를 무리 없이 견디고 어떤 앱은 그러지 못하는데, 서명 요구사항이 어떻게 쓰였는지, 그리고 내장 헬퍼의 경로가 부모 구조에 박혀 있는지에 따라 달라집니다.
알아보는 법: 잘 쓰던 앱인데, 응용 프로그램 폴더를 정리했거나 마이그레이션에서 복원한 뒤 망가졌습니다.
해결: 새 위치에서 깨끗한 재부여를 하십시오. /Applications 안의 하위 폴더로 옮겼다면 먼저 최상위로 되돌려 보십시오. 자체 업데이트 기능이 있는 일부 앱은 하위 폴더에서 제대로 동작하지 않습니다.
사례 4: 불완전한 업데이트가 서명을 무효화함
업데이트가 중단되었거나, 동기화 도구가 번들을 건드렸거나, 백신 제품이 내부 파일을 격리했다가 복원했거나, 백업 복원이 번들을 불완전하게 재구성했습니다. 서명이 더 이상 검증되지 않습니다.
알아보는 법:
codesign --verify --deep --strict --verbose=2 /Applications/AppName.app정상 번들이라면 앱이 디스크상에서 유효하며 지정된 요구사항을 만족한다는 짧은 보고로 끝납니다. 손상된 번들은 실패하는 특정 파일을 짚어 줍니다. 여기서 실패가 보인다면 권한을 아무리 만져도 소용없습니다. macOS가 번들 자체를 전혀 신뢰하지 않기 때문입니다.
해결: 개발자의 원본 다운로드로 재설치하십시오. "앱을 다시 설치하세요"가 어깨를 으쓱하는 대신 진짜로 정답인 몇 안 되는 경우 중 하나입니다. 같은 근본 손상이 더 눈에 띄게 드러나는 형태가 "앱이 손상되었기 때문에 열 수 없습니다" 대화상자이며, Gatekeeper와 격리 속성 해결 가이드에서 자세히 다룹니다.
사례 5: 자기 번들을 교체하는 Sparkle 계열 자체 업데이터
App Store 밖에서 배포되는 많은 Mac 앱은 Sparkle 프레임워크나 유사한 방식으로 스스로 업데이트합니다. 새 버전을 내려받아 실행 중인 상태에서 자기 번들을 제자리에서 교체하는 방식입니다.
이 과정이 제대로 작동하면 새 번들은 동일한 팀 식별자를 유지하고 TCC는 계속 그것을 인식합니다. 그렇지 못한 경우 — 업데이트가 다르게 서명되었거나, 교체 과정에서 번들이 일부만 기록되었거나, 앱이 살짝 다른 경로에 자신을 대체한 경우 — 다음에 보호된 기능을 사용할 때 재요청이 뜨거나 조용한 실패가 발생합니다.
알아보는 법: 앱이 App Store 밖에서 스스로 업데이트하고, 권한 문제가 업데이트 시점을 중심으로 몰려 있습니다.
해결: 업데이트가 끝난 뒤 깨끗한 재부여를 하십시오. 업데이트할 때마다 이런 일이 생긴다면 개발자의 서명 설정이 문제이며, 그쪽에서 고칠 수 있는 문제이므로 알려줄 가치가 있습니다.
일반적인 진단 절차
"부여했는데 작동하지 않는" 어떤 경우든 세 가지 질문을 순서대로 던지십시오. 이 앱의 사본이 디스크에 몇 개 있는가(mdfind), 번들이 검증되는가(codesign --verify), 업데이트 직후에 망가졌는가. 이 세 답이 거의 매번 위 다섯 사례 중 하나를 가리킵니다.
Terminal 도구: tccutil이 할 수 있는 일과 할 수 없는 일
이 서브시스템을 위한 명령줄 도구는 정확히 하나뿐이며, 그 능력은 대부분의 가이드가 암시하는 것보다 훨씬 좁습니다.
reset이 유일한 명령입니다
macOS 26.5.2에서 인자 없이 tccutil을 실행하면 사용법 문자열이 출력됩니다.
tccutil: Usage: tccutil reset SERVICE [BUNDLE_ID]이것이 인터페이스 전부입니다. Apple의 man 페이지는 "one command is currently supported"라고 명시하며 이렇게 설명합니다.
reset Reset all decisions for the specified service, causing apps to prompt again the next time they access the service. If a bundle identifier is specified, the service will be reset for that bundle only.
man 페이지에 나오는 Apple 자체 예시는 tccutil reset AddressBook과 tccutil reset All com.apple.Terminal입니다.
대부분의 가이드가 건너뛰는 결론을 끌어내십시오. 부여 명령은 존재하지 않습니다. Terminal에서 권한을 승인할 수 없습니다. reset은 앱이 다시 묻도록 결정을 잊게 할 뿐, 당신을 대신해 예라고 말하지 않습니다. 예라고 말하는 유일한 방법은 시스템 설정 인터페이스와 MDM 구성 프로파일뿐입니다. 전체 디스크 접근 권한을 부여하는 tccutil 주문을 소개하는 가이드를 본다면, 그건 틀렸습니다.
가장 중요한 번들 ID 경고
이것이 Terminal 섹션 전체의 실질적 핵심이므로 따로 지면을 할애합니다.
# DANGEROUS - resets screen recording for EVERY app on the Mac
tccutil reset ScreenCapture
# Correct - resets it for one app only
tccutil reset ScreenCapture com.example.appname번들 식별자는 문법상 선택 사항이지만 실무에서는 필수입니다. 생략하면 macOS에게 이 머신의 모든 화면 기록 결정을 잊으라고 지시한 것입니다. Zoom, Slack, Discord, Teams, 스크린샷 도구, 녹화 소프트웨어, 원격 지원 클라이언트 — 전부 다음에 사용할 때 다시 물어봅니다. 영구적으로 망가지는 것은 없지만, 앱 하나를 고치겠다고 오후 내내 대화상자를 클릭할 일을 스스로 만든 셈입니다.
번들 식별자 없는 tccutil reset All은 더 심합니다. 모든 앱의 모든 서비스에 대한 모든 결정을 잊습니다. 어떤 가이드가 이것을 첫 단계로 실행하라고 한다면, 그 가이드를 닫으십시오.
항상 번들 식별자를 덧붙이십시오. 매번, 예외 없이.
인자 검증 순서, 그리고 그것이 오타를 감추는 이유
이 부분은 직접 테스트했으며, 그 동작은 오류 메시지를 읽는 방식에 영향을 줍니다. tccutil은 서비스 이름보다 번들 식별자를 먼저 검증합니다. 엉터리 서비스와 엉터리 번들 ID를 함께 주면 이렇습니다.
tccutil reset ZZZNotAService com.example.nonexistent.zzz이렇게 반환합니다.
tccutil: No such bundle identifier "com.example.nonexistent.zzz": The operation couldn't be completed. (OSStatus error -10814.)명백히 잘못된 서비스 이름이 아니라 번들에 대해 불평합니다. 번들 ID 없이 엉터리 서비스만 주면 이렇습니다.
tccutil reset ZZZNotAService이렇게 반환합니다.
tccutil: Failed to reset ZZZNotAService실질적 결과는 이렇습니다. 번들 식별자의 오타는 항상 명확하고 구체적인 오류를 주므로 좋습니다. 하지만 서비스 이름의 오타는 번들 식별자도 틀린 경우 가려질 수 있습니다. 도구가 그것을 문제 삼을 만큼 진행되지 않기 때문입니다. -10814 오류가 나오면 번들 식별자를 먼저 고치고, 명령을 다시 실행해 서비스 이름도 틀렸는지 확인하십시오.
따라서 결론은 이것입니다. 명령을 만들기 전에 번들 식별자를 검증하십시오.
앱의 번들 식별자를 찾는 방법
믿을 만한 방법이 두 가지 있습니다. 첫 번째는 테스트용 Mac에서 확인했으며, osascript -e 'id of app "Terminal"'은 com.apple.Terminal을, osascript -e 'id of app "Safari"'는 com.apple.Safari를 반환했습니다.
osascript -e 'id of app "AppName"'Finder에 표시되는 그대로 앱 이름을 넣으십시오. 가장 빠른 방법이며, Howard Oakley의 개인정보 보호 개요 글 댓글에서 독자들이 알려주고 그가 인정한 방법이기도 합니다.
두 번째 방법은 번들을 직접 읽는 것으로, 앱이 표준 위치에 없거나 AppleScript가 이름을 해석하지 못할 때 유용합니다.
defaults read /Applications/AppName.app/Contents/Info.plist CFBundleIdentifier또는 서명 기관까지 함께 보여주는 코드 서명 뷰를 사용해 Identifier= 줄을 읽으십시오.
codesign -dv --verbose=2 /Applications/AppName.app어느 쪽을 쓰든 좋지만, 반드시 둘 중 하나를 쓰십시오. 앱 이름으로 식별자를 추측하지 마십시오. 역방향 DNS 명명은 관례이지 규칙이 아니며, 당신이 짐작할 만한 것과 전혀 닮지 않은 식별자를 가진 앱이 많습니다.
서비스 이름은 Apple 문서가 아니라 커뮤니티 지식입니다
여기서는 완결성보다 정직함이 중요합니다.
Apple은 tccutil reset이 받아들이는 서비스 이름 목록을 공개하지 않습니다. man 페이지가 예시로 주는 것은 정확히 두 개, AddressBook과 All뿐입니다. 이 주제에 대한 Apple 문서는 그것이 전부입니다.
유통되는 이름들은 커뮤니티에서 나왔습니다. Howard Oakley는 2025년 3월 개인정보 보호 개요 글에서 다음을 포함한 목록을 공개했습니다.
Accessibility, AddressBook, All, AppleEvents, AudioCapture, BluetoothAlways, Calendar, Camera, ContactsFull, ContactsLimited, DeveloperTool, FocusStatus, MediaLibrary, Microphone, Motion, Photos, PostEvent, Reminders, RemoteDesktop, ScreenCapture, SpeechRecognition, SystemPolicyAllFiles, SystemPolicyDesktopFolder, SystemPolicyDocumentsFolder, SystemPolicyDownloadsFolder, SystemPolicyNetworkVolumes, SystemPolicyRemovableVolumes.
그중 두 개가 이 글이 가장 관심을 두는 패널에 대응합니다. 화면 및 시스템 오디오 기록에는 ScreenCapture, 전체 디스크 접근 권한에는 SystemPolicyAllFiles입니다.
테스트용 Mac에서 이 이름들을 무차별로 시험해 보지는 않았습니다. 의도적으로 그랬습니다. 성공하는 tccutil reset은 그 머신의 실제 권한을 지워버리므로, 어떤 이름이 통하는지 확인하는 유일한 방법은 보존하려던 것을 파괴하는 것이고, 실패하는 이름을 시험해 봐야 아무것도 알 수 없습니다. 위 목록은 출처가 분명한 커뮤니티 지식이며 현장 실무자들이 사용하는 것과 일치합니다. 그것은 Apple 문서가 아니고, 저는 그것을 권위 있는 것처럼 제시하기보다 사실대로 말하겠습니다.
두 가지가 따라옵니다. tccutil reset이 아무 일도 하지 않는 것처럼 보이면, 시스템이 고장 났다고 결론짓기 전에 서비스 이름이 틀렸을 가능성을 고려하십시오. 그리고 가능하면 시스템 설정 경로를 선호하십시오. 패널에는 철자 문제가 없기 때문입니다.
명령줄 바이너리와 헬퍼 도구
이 영역은 "앱 하나, 목록 항목 하나"라는 모델이 가장 심하게 무너지는 곳이며, 잘 문서화된 macOS 26 버그가 한동안 상황을 훨씬 나쁘게 만든 곳이기도 합니다.
평범한 실행 파일에는 번들 식별자가 없습니다
.app은 번들입니다. 정해진 구조를 가진 디렉터리이며, 그 안에 CFBundleIdentifier 등을 선언하는 Info.plist가 들어 있습니다. /usr/local/bin에 놓인 컴파일된 바이너리에는 그런 것이 전혀 없습니다. 그냥 Mach-O 실행 파일일 뿐입니다.
TCC의 모델은 번들을 중심으로 만들어졌습니다. 평범한 실행 파일도 권한을 부여받을 수는 있지만 키로 삼을 번들 식별자가 없고, 그래서 앱처럼 패널에 나타나지 않을 수 있으며, tccutil reset Service bundle.id가 겨냥할 대상도 없습니다.
macOS 26.1 표시 버그, 그리고 그것이 알려준 것
2025년 말, Apple 개발자 포럼의 여러 스레드가 서로 다른 권한에서 동일한 현상을 보고했습니다. Apple 자체 엔지니어들이 진단을 확인해 주었고, 그 결말은 패널과 데이터베이스의 관계에 대해 오래 유효한 사실을 알려주므로 짚고 넘어갈 가치가 있습니다.
스레드 807898, "Issue: Plain Executables Do Not Appear Under 'Screen & System Audio Recording' on macOS 26.1 (Tahoe)"는 화면 기록을 요청한 평범한 실행 파일이 정상적으로 요청 대화상자를 받았고, 부여 후 화면도 제대로 캡처했지만 시스템 설정 목록에는 결코 나타나지 않았다고 보고했습니다. 게시자의 요약은 이렇습니다. "macOS 26.1 (Tahoe) appears to require app bundles for an item to be shown in the Screen Recording privacy UI. Plain executables: still request and receive permission, still function correctly after permission is granted, but do not appear in the System Settings list." 동일한 코드를 .app 번들로 포장하니 정상적으로 나타났습니다. Apple의 DTS 엔지니어인 Quinn "The Eskimo!"가 답글로 이를 확인했습니다. "IMO this is a bug and I encourage you to file it as such."
스레드 807323, "Background Unix executable not appearing in Screen Recording permissions UI (macOS Tahoe 26.1)"는 같은 증상을 다른 각도에서 보고했습니다. CGRequestScreenCaptureAccess()를 호출하는 백그라운드 Unix 실행 파일이 26.0.1에서는 동작했는데 26.1에서 UI에 나타나지 않게 되었습니다. 게시자는 + 버튼으로 실행 파일을 수동 추가하면 "grants permission internally, but the executable still doesn't show in the UI"라서 사용자가 "cannot verify or revoke permissions"라고 지적했습니다. 그 스레드에는 Apple의 답변이 없었고 다른 개발자의 확인만 있었습니다. 스레드 809549는 전체 디스크 접근 권한에서 같은 문제를 제기하며 명령줄 바이너리가 "fail to appear under the FDA settings, even after selection"이라고 보고했고, Quinn이 기존 통합 스레드로 안내한 뒤 관리자가 스레드를 잠갔습니다.
그 통합 스레드인 806187에 결말이 있습니다. 핵심 발견은 이것입니다. 권한은 그동안 내내 올바르게 기록되고 있었습니다. 데이터베이스는 맞았고, 목록이 틀렸습니다. 한 참여자의 표현대로 "CLI apps can have full disk access or other permissions, but you cannot see it in the list." 26.1에 추가된 "Background Security Improvements" 기능이 설정 인터페이스를 번들 애플리케이션만 표시하도록 바꿔 놓은 것이었습니다.
임시 우회책은 "drag the binary from Finder to the full disk access list in System Settings window. The permission will be given, but it won't show in the list."였습니다. 오래 유효한 권고는 또 다른 DTS 엔지니어인 Kevin Elliott에게서 나왔습니다. "The better solution is to embed that tool inside an app bundle. I don't mean 'make your command-line tool act like an app', I mean 'take your command-line tool and stick it inside an app bundle, then use it exactly the way you were using it before'."
여러 참여자가 이 표시 버그가 macOS 26.3 베타에서 수정되었음을 확인했고, 스레드 807898의 누군가는 26.1과 26.2 베타에 있던 손쉬운 사용 쪽의 같은 문제도 26.3에서 해결되었다고 보고했습니다.
26.1을 지나온 사람에게도 이것이 중요한 이유: 패널은 데이터베이스의 뷰이고, 뷰는 거짓말을 할 수 있습니다. 어떤 앱이나 도구가 분명히 권한을 갖고 있는데 목록에 나타나지 않는다면, 권한이 없다고 단정하지 마십시오. 무언가를 재설정하기 전에 동작을 먼저 시험해 보십시오.
Terminal에서 실행한 앱이 Terminal의 권한을 상속하는 이유
이 부분은 개발자들을 끊임없이 걸려 넘어지게 하지만, 규칙을 알고 나면 더 이상 신비롭지 않습니다.
TCC는 단순히 "어느 바이너리가 이 요청을 하고 있는가?"를 묻지 않습니다. Howard Oakley가 "an attribution chain that traces up through the call chain to an app that is responsible for the privacy settings to be applied"라고 설명한 것을 따라 올라갑니다. 시스템은 책임 있는 프로세스를 찾는데, 그것은 보통 체인의 가장 깊은 프로세스가 아니라 사용자가 실행한 앱입니다.
그래서 Terminal에서 프로그램을 실행하면 대개 Terminal이 책임 프로세스가 됩니다. 당신 프로그램의 화면 캡처 요청은 Terminal의 화면 캡처 요청이 됩니다. Terminal에 권한이 있으면 프로그램이 동작하고, 없으면 요청 대화상자에 당신 프로그램이 아니라 Terminal의 이름이 표시됩니다. 이는 스레드 807898의 게시자가 관찰한 그대로입니다. VS Code나 Terminal 같은 다른 앱에서 실행하면 "the parent app appears in the list instead, not the executable itself."
일상적 사용에서 세 가지 결과가 따릅니다. 터미널 에뮬레이터에 권한을 부여한다는 것은 그 안에서 실행하는 모든 도구가 그 권한을 물려받는다는 뜻이며, 편리한 동시에 가볍게 결정하기 전에 생각해 볼 만한 실질적인 권한 확장입니다. 같은 스크립트라도 Terminal에서 실행할 때, LaunchAgent에서 실행할 때, 더블클릭한 앱 래퍼에서 실행할 때 동작이 달라집니다. 각 경우 책임 프로세스가 다르기 때문입니다. 그리고 터미널 에뮬레이터를 바꾸면 처음부터 다시 시작해야 합니다. iTerm2, Ghostty, Warp, Kitty, Terminal.app은 각각 별개의 신원이기 때문입니다.
헬퍼 도구, XPC 서비스, 로그인 항목
현대적인 Mac 앱은 흔히 여러 실행 파일로 구성됩니다. 본체 앱, 경우에 따라 /Library/PrivilegedHelperTools 아래의 권한 있는 헬퍼, 번들에 내장된 XPC 서비스, 로그인 시 실행되는 런치 에이전트 등입니다.
제대로 서명된 번들 안에 내장된 XPC 서비스는 보통 부모 앱의 귀속 아래에서 동작합니다. 체인이 앱으로 해석되기 때문입니다. 별도로 설치되는 헬퍼와 런치 데몬은 그렇지 않은 경우가 많습니다. 이들은 앱의 프로세스 트리 밖에서 자기 신원으로 실행되므로 자체 권한 부여가 필요합니다. 일부 앱이 권한을 두 번 — 앱용 한 번, 헬퍼용 한 번 — 승인하라고 요구하는 이유가 이것이고, root로 설치된 헬퍼가 사용자별 데이터베이스가 아니라 시스템 데이터베이스에 항목을 필요로 할 수 있는 이유이기도 합니다.
앱이 절반만 동작한다면, 즉 인터페이스는 반응하는데 백그라운드 기능이 조용히 실패한다면, 권한 없는 헬퍼가 유력한 용의자입니다. 패널만 봐서는 알아낼 수 없으므로, 어떤 헬퍼에 무엇이 필요한지 알아내는 가장 빠른 길은 그 앱의 지원 문서입니다.
화면 기록에 국한된 이야기
패널 위치는 시스템 설정 → 개인정보 보호 및 보안 → 화면 및 시스템 오디오 기록입니다. Apple의 설명은 그대로 옮기면 이렇습니다. "Allow apps to record your screen and audio, or just your audio. The listed apps have access."
이 권한에만 해당하는 사항들입니다.
예정된 재확인 요청이 있는 유일한 권한입니다. 다른 어떤 TCC 범주도 타이머에 따라 다시 묻지 않습니다. 카메라 권한이나 전체 디스크 접근 권한이 매달 당신에게 묻는다면, 그것은 설계된 동작이 아니며 결함이 있는 것입니다.
스위치를 켠 뒤에는 대개 앱을 재시작해야 합니다. 많은 앱이 실행 시점에 캡처 가능 여부를 한 번만 읽습니다. 앱이 실행 중일 때 스위치를 켜면 다시 실행하기 전까지 눈치채지 못할 수 있습니다. "켰는데 아무 일도 안 일어났다"는 보고의 상당수가 이것만으로 설명됩니다.
시스템 오디오와 화면은 묶여 있지만 동일하지는 않습니다. 패널은 둘 다 다룹니다. 어떤 앱은 오디오만 요청합니다. 앱이 화면은 잘 캡처하는데 소리가 없이 녹화된다면, 애초에 시스템 오디오 캡처를 요청했는지 확인하고 앱 자체의 오디오 기기 설정도 확인하십시오. 가상 오디오 기기가 없는 것은 TCC 문제와 완전히 별개의 문제입니다. Mac 화면 녹화 완전 가이드가 오디오 쪽을 상세히 짚어 줍니다.
정직하게 보고하는 현실의 난제. Microsoft Q&A 스레드에는 macOS Tahoe 26.4, 빌드 25E246에서 Teams for Mac이 화면 공유 권한 요청을 무한 반복하는 사례가 기록되어 있습니다. 보고한 관리자는 사람이 확인할 수 있는 모든 것을 확인했습니다. 올바른 코드 요구사항으로 com.microsoft.teams2를 겨냥해 MDM으로 배포한 PPPC 프로파일, kTCCServiceScreenCapture에 대해 auth_value=2를 보여주는 시스템 수준 TCC 레코드, 동일하게 나타나는 사용자 수준 레코드, 그리고 설정이 프로파일로 구성되었다는 안내와 함께 Teams가 켜져 있음을 보여주는 시스템 설정까지요. 캐시를 지우고, 구형 com.microsoft.teams 식별자를 제거하고, MDM으로 재설치하고, 프로세스를 죽였다 다시 띄우고, 재시동까지 했습니다.
제시된 답변은 표준적인 조치였습니다. "fully quit Teams, remove and re-add or re-toggle the Teams entry in Screen Recording, then restart Teams and re-attempt sharing so macOS can re-prompt and re-bind the permission", 그래도 안 되면 클라이언트 로그와 함께 Microsoft 지원으로 에스컬레이션하라는 것이었습니다. 3주 뒤 보고자는 동작하는 해결책을 받지 못했으며 대신 웹 앱을 쓰고 있다고 밝혔습니다. 때로는 모든 계층에서 권한이 정말로 부여되어 있는데도 애플리케이션 쪽 버그가 원인일 수 있습니다. 언제 멈춰야 하는지 아는 것도 실력의 일부입니다.
전체 디스크 접근 권한에 국한된 이야기
전체 디스크 접근 권한은 시스템에서 가장 광범위한 권한입니다. 백업 도구, 마이그레이션 유틸리티, 보안 소프트웨어, 그리고 관리 목적으로 쓰는 터미널 에뮬레이터가 필요로 하는 권한입니다.
파일 및 폴더 항목과 같지 않습니다. 파일 및 폴더는 특정 폴더를 허용합니다. 전체 디스크 접근 권한은 머신 전반의 보호된 데이터를 허용합니다. Mail, Messages, Safari 탐색 데이터, Time Machine 백업, 그리고 다른 애플리케이션의 컨테이너 디렉터리가 여기 포함됩니다. 전체 디스크 접근 권한이 있는 앱은 파일 및 폴더에 아무 항목도 필요 없습니다.
거의 항상 앱 재시작이 필요합니다. 다른 어떤 권한보다도 전체 디스크 접근 권한은 프로세스 시작 시점에 평가되는 경향이 있습니다. 부여한 다음 앱을 종료하고 다시 실행하십시오. 많은 앱이 바로 그렇게 하라는 대화상자를 띄웁니다. 그 말을 믿으십시오.
요청 대화상자로는 받을 수 없습니다. 앱은 승인하면 전체 디스크 접근 권한이 부여되는 대화상자를 띄울 수 없습니다. 당신을 패널로 안내할 수 있을 뿐입니다. 이 권한이 필요한 앱들이 시스템 대화상자 대신 안내문을 보여주는 이유이고, "허용을 눌렀는데도 안 된다"는 보고가 흔한 이유이기도 합니다. 애초에 누를 허용 버튼이 없었던 것입니다.
터미널 에뮬레이터에 부여하면 그 범위는 넓습니다. Terminal이나 iTerm2에 전체 디스크 접근 권한을 준다는 것은, 앞서 설명한 귀속 체인을 통해 그 안에서 실행하는 모든 명령이 그 범위를 갖게 된다는 뜻입니다. 관리자가 원하는 것이 정확히 그것인 경우도 많습니다. 다만 자신이 무엇을 하고 있는지는 이해하고 하십시오.
명령줄 도구는 위에서 설명한 26.1 표시 버그의 영향을 받았고, 수정은 26.3 베타에 들어갔습니다. 26.1이나 26.2를 쓰고 있고 CLI 도구를 추가해도 목록에 나타나지 않는다면, 그것이 그 알려진 버그이며 도구는 권한을 실제로 갖고 있을 가능성이 큽니다. 목록을 믿지 말고 동작을 시험하십시오.
손쉬운 사용과 자동화에 국한된 이야기
이 둘은 비슷한 유형의 혼란을 만들어내기 때문에 함께 묶었습니다.
손쉬운 사용은 앱에게 Mac을 제어할 능력을 부여합니다. 윈도우 매니저, 텍스트 확장 도구, 클립보드 관리자, 키보드 리매퍼, 자동화 도구, 원격 지원 소프트웨어가 모두 이를 필요로 하며, macOS는 이를 강력한 권한으로 취급합니다.
이 권한의 특징적 동작은 이렇습니다. 많은 앱이 변경 사항을 인식하려면 완전 종료 후 재실행이 필요하고, 일부는 스위치를 껐다 다시 켜야 합니다. 손쉬운 사용에 의존하는 앱이 업데이트 후 작동을 멈췄다면, 앞서 다룬 코드 서명 신원 사례들을 먼저 확인하십시오. 손쉬운 사용도 macOS 26.1 표시 버그의 영향을 받은 패널 중 하나였으며, 스레드 807898의 한 보고는 손쉬운 사용 쪽 문제가 "has now been fixed in 26.3 Beta."라고 전했습니다.
자동화는 다른 모든 패널과 구조적으로 다릅니다. 앱의 목록이 아니라 쌍의 목록입니다. "앱 A가 앱 B를 제어하려고 합니다"에서 각 쌍이 별개의 결정입니다. 스크립트가 세 개의 애플리케이션을 제어한다면 결정도 세 개, 항목도 세 개입니다.
두 가지가 따라옵니다. 자동화 권한이 망가졌다는 것은 흔히 여러 쌍 중 하나가 빠졌다는 뜻이고, 어느 것이 빠졌는지 볼 수 있는 곳은 패널뿐입니다. 그리고 tccutil reset AppleEvents com.example.controller로 자동화를 재설정하면 그 제어자의 모든 쌍이 한 번에 지워지므로, 스크립트가 각 대상을 건드릴 때마다 다시 승인해야 합니다. 막힌 자동화 상태에서 빠져나오는 가장 빠른 방법인 경우가 많지만, 연달아 뜨는 요청들을 각오하십시오.
짚어 둘 함정이 하나 있습니다. Terminal에서 AppleScript를 실행하면 기록되는 권한은 당신의 스크립트가 대상 앱을 제어하는 것이 아니라 Terminal이 대상 앱을 제어하는 것입니다. 스크립트를 다른 터미널 에뮬레이터로 옮기거나 앱으로 감싸면 다시 승인해야 합니다. 이는 귀속 체인이 설계대로 작동하는 것이지만, 처음 겪을 때 놀랍지 않은 것은 아닙니다.
깨끗한 재부여 절차
진짜 결함을 확인했다면 다음 절차를 따르십시오. 순서대로 따라야 합니다. 각 단계에는 이유가 있으며, 하나를 건너뛰는 것이 사람들이 이 방법이 통하지 않는다고 결론짓는 이유입니다.
1. 앱을 완전히 종료하십시오.
윈도우를 닫는 것으로는 부족합니다. Cmd-Q로 종료한 다음 남은 것이 없는지 확인하십시오.
pgrep -fl "AppName"프로세스가 남아 있다면 그것들이 옛 권한 상태를 붙들고 있으며, 이후에 하는 모든 작업이 낡은 메모리 내 결정을 기준으로 평가됩니다.
이유: 실행 중인 프로세스는 자신의 권한 상태를 캐시합니다. 살아 있는 프로세스 아래에서 데이터베이스를 재설정하면 일관성 없는 동작이 나타나 유령을 쫓게 됩니다.
2. 디스크에 앱 사본이 정확히 하나인지 확인하십시오.
mdfind "kMDItemKind == 'Application'" -name "AppName"사용하지 않는 사본은 삭제하십시오.
이유: 사본이 둘이면 엉뚱한 쪽에 권한을 다시 부여해 정확히 출발점으로 되돌아갈 수 있습니다. 사람들이 건너뛰는 단계이자, 그들에게서 이 절차가 실패하는 이유입니다.
3. 번들 식별자를 확인하십시오.
osascript -e 'id of app "AppName"'이유: 잘못된 식별자는 잘해야 -10814 오류를 주고, 최악의 경우 재설정 명령에서 식별자를 아예 빼고 싶게 만드는데 그것이 파괴적인 경로입니다.
4. 패널에서 앱 항목을 제거하십시오.
시스템 설정 → 개인정보 보호 및 보안 → 해당 패널을 열고 앱을 선택한 뒤 -를 클릭하십시오. 관리자 인증을 요구하면 입력하십시오.
이유: 이렇게 하면 지원되는 인터페이스를 통해 낡은 결정이 삭제됩니다. 스위치를 끄는 것과는 다릅니다. 스위치를 끄면 결정을 제거하는 것이 아니라 거부를 기록합니다. 거부되면 앱은 다시 당신에게 물어볼 기회조차 얻지 못합니다.
5. 해당 번들 식별자에 대해 서비스를 재설정하십시오.
tccutil reset ScreenCapture com.example.appname올바른 서비스 이름과 식별자로 바꾸십시오. 전체 디스크 접근 권한은 SystemPolicyAllFiles, 손쉬운 사용은 Accessibility, 자동화는 AppleEvents입니다.
이유: 26.1 버그가 결정적으로 보여주었듯 패널과 데이터베이스는 서로 어긋날 수 있습니다. 인터페이스에서의 제거와 재설정을 모두 수행하면 시스템이 실제로 어느 쪽을 참조하든 문제가 없습니다. 여기서 번들 식별자는 선택 사항이 아닙니다.
6. 앱을 다시 실행하십시오.
이유: 캐시된 결정도 없고 이전 실행의 잔재도 없는 새 프로세스가 필요합니다.
7. 권한이 필요한 동작을 실행하십시오.
화면 공유를 시작하거나, 폴더를 열거나, Apple 이벤트를 보내십시오. 시스템 설정으로 돌아가 미리 스위치를 켜지 마십시오.
이유: 요청 대화상자가 현재의 서명 신원을 결정에 묶어주는 메커니즘입니다. 그 묶음이 이 작업 전체의 목적입니다. 패널에서 미리 스위치를 켜면 때때로 제대로 묶이지 않은 결정이 기록되는데, 사람들이 스위치는 켜져 있는데 앱은 작동하지 않는다고 보고하는 이유가 그것입니다.
8. 요청 대화상자에서 승인하십시오.
허용을 클릭하거나, 전체 디스크 접근 권한처럼 직접 요청할 수 없는 범주라면 시스템 설정을 열어 거기서 켜십시오.
9. 앱을 한 번 더 종료했다가 다시 실행하십시오.
이유: 많은 앱이 실행 시점에만 자신의 권한 집합을 읽습니다. 이 단계가 "부여됨"을 "실제로 사용 가능함"으로 바꿔주며, 이 절차 전체에서 가장 흔한 거짓 실패를 없애줍니다.
9단계 후에도 앱이 여전히 실패한다면 문제는 권한이 아닙니다. 다음 섹션으로 넘어가십시오.
아무것도 통하지 않을 때
새 사용자 계정으로 테스트하기
시스템 설정 → 사용자 및 그룹에서 새 관리자 계정을 만들고, 로그인한 뒤 앱을 설치하거나 실행하고 거기서 권한을 부여하십시오.
이 한 번의 테스트가 문제 영역을 깔끔하게 가릅니다.
- 새 계정에서 작동함: 결함은 당신 사용자 계정의 상태에 있으며, 사용자별 TCC 데이터베이스, 낡은 환경설정, 또는 간섭하는 로그인 항목일 가능성이 높습니다. 앱과 시스템은 멀쩡합니다.
- 새 계정에서도 실패함: 결함은 시스템 전역이거나 앱 자체에 있습니다. 당신 계정은 문제가 아니며, 막 시도하려던 "환경설정을 지우세요" 류의 조언들은 저녁 시간을 낭비하게 했을 것입니다.
5분이면 되고, 한 시간의 추측보다 가치 있습니다.
전체 재설치가 진짜 정답인 경우
재설치는 모든 문제에 대한 반사적 대답이고 대개는 틀렸습니다. 다음 세 상황에서는 진짜로 옳습니다.
codesign --verify가 번들이 손상되었다고 보고할 때. 서명이 검증되지 않으면 그 아래 무엇도 고칠 수 없습니다. 백업이 아니라 개발자의 원본 다운로드로 재설치하십시오. 백업이 손상의 출처일 수 있기 때문입니다.- 앱을 수정한 출처에서 설치했을 때. 재포장된 설치 프로그램, 앱 번들을 패치하는 도구, 일부 기업 배포 메커니즘은 개발자 서명과 더 이상 일치하지 않는 번들을 남깁니다. 개발자에게서 깨끗한 사본을 받으십시오.
- 당신이 겪는 특정 증상에 대해 앱 자체의 지원 문서가 그렇게 하라고 할 때. 어떤 앱들은 알려진 권한 상태 문제와 함께, 자체 상태 디렉터리를 지우는 단계까지 포함한 재설치 절차를 문서화해 두고 있습니다.
이 셋 밖에서는 재설치를 해도 대개 이미 갖고 있던 것과 같은 번들이 다시 생길 뿐이고, 서명 신원이 그대로라면 권한 상황도 그대로입니다.
재시동은 하되, 올바른 이유로
재시동은 프로세스 상태를 지우고, 런치 데몬을 다시 로드하고, 메모리 내 캐시를 초기화합니다. 특히 깔끔하게 재로드되지 않는 백그라운드 헬퍼가 얽힌 경우처럼, 일부 유형의 막힌 권한 상태를 실제로 해결합니다. 하지만 코드 서명 불일치, 디스크의 중복 사본, 손상된 번들, 애플리케이션 버그는 고치지 못합니다. 초기에 한 번 재시동하고, 그다음에는 진단으로 돌아가십시오.
하지 말아야 할 것
검색 결과에 끊임없이 등장하므로 명시적으로 말합니다. SIP를 끄지 마십시오. 대화상자 하나를 우회하려고 시스템 전체의 보호를 제거하는 일입니다. TCC.db를 편집하거나 삭제하지 마십시오. SIP가 켜져 있으면 할 수 없고, 꺼져 있더라도 하고 싶어 해서는 안 됩니다. 홈 폴더에 chmod -R을 쓰지 마십시오. 이 서브시스템에는 아무 영향도 주지 않으면서 Library 폴더를 망가뜨릴 수 있습니다. 그리고 하루 종일 허용을 클릭하며 보내고 싶은 것이 아니라면 번들 식별자 없이 tccutil reset All을 실행하지 마십시오.
관리되는 Mac
Mac이 회사나 학교에서 관리하는 기기라면 규칙이 달라집니다. 애초에 이길 수 없는 스위치와 한 시간을 싸우기 전에, 자신이 그런 경우인지 아는 것이 좋습니다.
내 Mac이 관리되는지 확인하는 법
세 가지 확인 방법이 있습니다. 첫째, 시스템 설정 → 일반 → 기기 관리를 보십시오. 프로파일이 설치되어 있다면 거기에 나열됩니다. 둘째, 개인정보 패널 자체의 안내를 찾아보십시오. 관리되는 항목에는 해당 설정이 프로파일로 구성되었다는 문구가 표시되고 스위치는 보통 회색 처리됩니다. 셋째, Terminal에서 확인합니다.
profiles status -type enrollment관리되지 않는 테스트용 Mac에서는 다음이 반환되었습니다.
Enrolled via DEP: No
MDM enrollment: No관리되는 Mac은 여기서 등록 상태를 보고합니다.
프로파일이 할 수 있는 일과 할 수 없는 일
MDM은 보통 PPPC 프로파일이라 부르는 Privacy Preferences Policy Control 페이로드를 통해 권한을 부여합니다. 결정을 시스템 전역 TCC 데이터베이스에 직접 기록하며, 그래서 관리되는 Mac에서는 아무도 클릭하지 않았는데 권한이 생겨 있을 수 있습니다.
여기에는 한계가 있고, 화면 캡처가 그중 하나입니다. Mac 관리자들 사이에서 널리 인용되는 PPPC 변경 관련 글을 쓴 MDM 벤더 Kandji는 그 메커니즘을 이렇게 설명합니다. 화면 캡처와 입력 모니터링의 경우 "IT can use MDM to pre-allow certain apps to be approved even by standard users to enable screen capture or input monitoring." 이는 조용히 권한을 부여하는 것이 아니라 승인 권한을 사용자에게 위임하는 인증 값을 사용합니다. 따라서 프로파일은 화면 캡처를 완전히 거부할 수 있고 표준 사용자가 승인하도록 허용할 수도 있지만, 문서화된 동작에 따르면 전체 디스크 접근 권한이나 손쉬운 사용처럼 조용히 부여하지는 못합니다.
이 미묘한 부분은 조심스럽게 받아들이십시오. 위의 Microsoft Q&A 사례에서 관리자는 kTCCServiceScreenCapture에 대해 MDM 정책을 나타내는 인증 사유가 붙은 시스템 수준 TCC 레코드를 보고했기 때문입니다. 두 설명은 깔끔하게 들어맞지 않으며, 저는 더 정돈된 쪽을 고르는 대신 둘 다 보고하고 있습니다.
관리되는 Mac을 사용한다면
회색 처리된 스위치를 우회하려 하지 마십시오. 성공하지 못할 것이고, 많은 배포 환경에서는 그 시도가 기록됩니다. 프로파일로 관리되는 항목에 tccutil reset을 실행하면 실패하거나, 다음 관리 체크인 때 다시 적용됩니다. 기기를 운영하는 담당자에게 연락하십시오. 해결은 그쪽에서 프로파일을 바꾸는 것이고 1분이면 됩니다.
관리되는 Mac을 운영한다면
PPPC 페이로드의 코드 요구사항을 배포된 앱 버전에 대해 codesign이 실제로 보고하는 값과 일치시키십시오. 위의 Teams 사례가 시사적인 이유는 바로 그 관리자가 이를 검증했는데도 벽에 부딪혔다는 점입니다. 올바른 프로파일은 필요조건이지만 항상 충분조건은 아닙니다. Teams가 그랬듯 앱이 버전에 따라 번들 식별자를 바꾼다면, 둘 다 남겨두지 말고 구형 식별자를 프로파일에서 제거하십시오.
흔한 문제 해결
앱이 목록에 있고 켜져 있는데도 기록하지 못함
문제: 패널에는 앱이 활성화된 것으로 표시됩니다. 그런데 앱은 권한이 없는 것처럼 동작합니다.
해결: 그 항목은 디스크의 앱과 더 이상 일치하지 않는 서명 신원에 묶여 있습니다. 가장 흔한 원인인 두 번째 사본을 확인하기 위해 먼저 mdfind "kMDItemKind == 'Application'" -name "AppName"을 실행하고 여분을 삭제하십시오. 그런 다음 패널에서의 제거와 번들 식별자를 붙인 tccutil reset을 모두 포함해 전체 깨끗한 재부여 절차를 수행하십시오. 스위치를 단순히 껐다 켜지 마십시오. 그것은 거부를 기록한 뒤 묶이지 않은 승인을 기록하는 것이며, 애초에 이 상황을 만든 원인입니다.
업데이트 후 앱이 목록에서 사라짐
문제: 어제까지 패널에 있던 앱이 오늘은 없고, 바뀐 것은 업데이트뿐입니다.
해결: 새 빌드가 다르게 서명되어 macOS가 이력 없는 새 애플리케이션으로 인식한 것입니다. 복구할 것은 없습니다. 앱을 실행하고, 보호된 동작을 유발하고, 새로 뜨는 요청을 승인하십시오. 요청 대화상자를 띄울 수 없는 전체 디스크 접근 권한을 사용하는 앱이라면 + 버튼으로 추가하십시오. 업데이트할 때마다 반복된다면 개발자의 서명 설정이 불안정한 것이니 알려줄 가치가 있습니다.
한 달에 한 번이 아니라 실행할 때마다 요청이 뜸
문제: 화면 캡처 대화상자가 예상 주기가 아니라 앱을 열 때마다 나타납니다.
해결: 이는 설계된 재확인이 아니라 결함입니다. 유력한 원인은 빌드할 때마다 코드 해시가 바뀌는 애드혹 서명 앱, 번들을 반복해서 교체하는 자체 업데이터, 또는 매번 달라지는 실행 경로입니다. 앱에 codesign -dv --verbose=2를 실행해 TeamIdentifier 줄을 확인하십시오. 서드파티 앱인데 not set으로 나온다면 그 앱은 Developer ID로 서명되지 않은 것이며, 개발자가 서명을 고치기 전까지 안정적인 권한은 불가능합니다.
같은 앱 이름의 항목 두 개
문제: 패널에 같은 앱이 두 번, 때로는 동일한 아이콘으로 나타납니다.
해결: 서명 신원이나 경로가 다른 사본이 디스크에 두 개 있는 것입니다. find /Applications ~/Applications ~/Downloads ~/Desktop -maxdepth 3 -name "AppName.app" 2>/dev/null로 전부 찾으십시오. 하나만 남기고 나머지는 삭제한 다음, 두 패널 항목을 모두 제거하고 남은 것에 다시 권한을 부여하십시오. 릴리스 빌드와 베타 채널을 의도적으로 함께 유지한다면, 항목이 두 개인 것을 예상하고 받아들이십시오.
명령줄 도구가 목록에 나타나지 않음
문제: + 버튼으로 바이너리를 추가했는데 표시되지 않습니다.
해결: macOS 26.1과 26.2에서는 위에서 논의한 확인된 표시 버그이며, Apple의 DTS 엔지니어들이 인정했고 26.3 베타에서 수정된 것으로 보고되었습니다. 목록에 보이지 않아도 권한은 기록되고 있을 가능성이 매우 높으므로, 더 파고들기 전에 실제 동작을 시험하십시오. 어떤 버전에서든 평범한 실행 파일에는 번들 식별자가 없고 이 인터페이스에서 일급 시민이었던 적도 없습니다. 스레드 806187에서 Kevin Elliott가 말한 대로, 오래 유효한 답은 도구를 앱 번들 안에 넣고 이전과 똑같이 계속 사용하는 것입니다.
요청 대화상자가 엉뚱한 애플리케이션 이름을 표시함
문제: 스크립트를 실행했는데 권한 대화상자에 당신의 스크립트가 아니라 Terminal, VS Code, 또는 Script Editor의 이름이 나옵니다.
해결: 이는 귀속 체인이 올바르게 작동하는 것입니다. 책임 프로세스는 당신이 실행한 앱이고, 권한은 거기에 붙습니다. 그 호스트 애플리케이션에 권한을 부여하고 그 안에서 실행하는 모든 것이 권한을 물려받는다는 사실을 받아들이거나, 도구를 자체 앱 번들로 포장해 그것이 책임 프로세스가 되게 하십시오. 터미널 에뮬레이터를 바꾸면 다시 부여해야 한다는 점을 유념하십시오. 각각이 별개의 신원이기 때문입니다.
스위치가 회색 처리됨
문제: 스위치를 바꿀 수 없고, 프로파일에 관한 안내가 있을 수 있습니다.
해결: 결정이 구성 프로파일로 설정된 것입니다. profiles status -type enrollment로 확인하고 시스템 설정 → 일반 → 기기 관리를 살펴보십시오. 관리되는 Mac이라면 관리자에게 연락하십시오. 변경은 프로파일에서 이루어져야 합니다. 개인용 Mac인데 예상치 못한 프로파일이 보인다면 무엇이 설치되어 있는지 검토하십시오. 자신이 알고 설치하지 않은 프로파일은 따져볼 가치가 있습니다.
권한이 잘 되다가 절전 모드나 긴 세션 후 멈춤
문제: 하루를 시작할 때는 화면 공유가 되는데, Mac이 잠들었다 깨어난 뒤에는 실패합니다.
해결: 먼저 지금 보고 있는 것이 다른 윈도우 뒤에 가려진 주기적 재확인 대화상자가 아닌지 확인하십시오. 보지 못한 요청 대화상자는 조용한 실패와 똑같아 보입니다. 모든 윈도우를 앞으로 불러내 확인하십시오. 요청이 없다면 앱을 완전히 종료하고 pgrep -fl "AppName"으로 확인한 뒤 다시 실행하십시오. 깨어난 뒤 재로드에 실패한 헬퍼 프로세스가 보통 원인입니다. 계속된다면 Mac을 한 번 재시동하십시오. 매일 반복된다면 그 앱에 절전 복귀 처리 버그가 있는 것이므로 개발자에게 보고할 사안입니다.
자주 묻는 질문
주기적인 화면 기록 요청을 끌 수 있나요?
아니요. Apple은 이를 비활성화하는 사용자용 설정을 제공하지 않으며, 이를 억제하는 지원되는 명령도 없습니다. 이를 없애는 유일한 메커니즘은 com.apple.developer.persistent-content-capture 엔타이틀먼트인데, 이는 개발자가 Apple에 신청해야 하는 관리형 기능이며 원격 제어 애플리케이션을 겨냥한 것입니다. 사용자가 켤 수 있는 것이 아닙니다.
macOS는 얼마나 자주 화면 기록 권한을 다시 묻나요?
Apple은 간격을 문서화한 적이 없습니다. 이 동작은 Sequoia 주기에 매주로 시작되었고, MacRumors와 9to5Mac이 2024년 8월에 보도했듯 비판 이후 Apple이 해당 베타에서 매월로 바꿨습니다. Apple의 현재 지원 문서는 재확인 요청을 전혀 언급하지 않으며, macOS 26의 주기는 어떤 권위 있는 출처로도 확인할 수 없었습니다.
권한을 재설정하면 데이터가 삭제되나요?
아니요. tccutil reset은 기록된 동의 결정을 삭제할 뿐 그 외에는 아무것도 건드리지 않습니다. 파일, 설정, 앱 데이터는 그대로입니다. 대가는 번거로움입니다. 영향을 받은 모든 앱이 다음에 권한이 필요할 때 다시 물어봅니다. 그 대가는 재설정 범위가 넓을수록 커지며, 항상 번들 식별자를 포함해야 하는 이유가 바로 그것입니다.
왜 제 앱은 Terminal에서는 되는데 단독으로는 안 되나요?
TCC가 요청을 책임 프로세스에 귀속시키기 때문이며, Terminal에서 실행한 프로그램의 경우 그것은 보통 Terminal 자신입니다. 당신의 프로그램은 Terminal의 권한을 빌려 쓰고 있는 것입니다. 단독으로는 권한이 없고, 앱 번들이 아니라 평범한 실행 파일이라면 권한을 부여받기 위해 패널에 나타나지조차 않을 수 있습니다.
전체 디스크 접근 권한을 부여하는 것은 위험한가요?
macOS가 제공하는 가장 광범위한 권한으로 Mail, Messages, Safari 데이터, Time Machine 백업, 다른 앱들의 컨테이너를 포괄합니다. 그 모든 것을 맡길 수 있다고 신뢰하는 소프트웨어에만 부여하십시오. 그리고 터미널 에뮬레이터에 부여하면 그 범위가 거기서 실행하는 모든 명령으로 확장된다는 점을 유념하십시오.
권한을 바꾼 뒤 Mac을 재시동해야 하나요?
보통은 아닙니다. 해당 앱을 종료했다가 다시 실행하는 것으로 거의 항상 충분하며, 많은 앱이 실행 시점에만 자신의 권한을 읽으므로 이는 필수 단계입니다. 전체 재시동은 깔끔하게 재로드되지 않는 백그라운드 헬퍼나 런치 데몬이라는 좁은 경우에 도움이 됩니다. 한 번 재시동한 뒤에는 진단으로 돌아가십시오.
결론
이 영역에서 겪는 좌절의 대부분은 "권한"이라는 하나의 이름표를 하나의 대상으로 취급하는 데서 옵니다. 그것은 최소한 세 가지입니다. chmod가 다루며 여기 논의와는 아무 상관도 없는 POSIX 파일 권한, 앱의 코드 서명 신원에 묶인 채 읽을 수 없는 데이터베이스에 저장되는 TCC 개인정보 결정, 그리고 관리되는 Mac에서 로컬에서 바꿀 수 있는 것을 덮어쓰는 프로파일 기반 정책입니다.
일단 구분하고 나면 판단 흐름은 짧습니다. 일정에 따라 도착하는 화면 캡처 요청은 의도된 것이고, 끄는 스위치는 없으며, 올바른 대응은 허용을 클릭하고 하던 일을 계속하는 것입니다. 나머지는 전부 결함이며, 결함에는 원인이 있습니다. 디스크의 두 번째 사본, 업데이트로 바뀐 서명, 더 이상 검증되지 않는 번들, 자체 권한이 필요한 헬퍼, 또는 당신 스크립트가 아니라 터미널 에뮬레이터를 가리키는 귀속 체인 말입니다.
도구는 정말로 빈약합니다. tccutil에는 동사가 하나뿐이고, Apple은 그것이 받아들이는 서비스 이름을 공개하지 않으며, 패널은 데이터베이스의 뷰인데 macOS 26.1 표시 버그가 보여주었듯 실제로 틀린 적이 있습니다. 그때 Apple 자체 엔지니어들이 목록은 보여주기를 거부하는 동안에도 권한은 올바르게 기록되고 있었음을 확인해 주었습니다. 그 조건 안에서 일하십시오. 명령을 만들기 전에 번들 식별자를 검증하고, reset에는 항상 그것을 덧붙이고, 깨끗한 재부여 절차를 순서대로 따르고, 막히면 새 사용자 계정으로 테스트하십시오. 그리고 언제 멈춰야 하는지 아십시오. 권한을 확인했고, 서명을 확인했고, 중복을 제거했고, 깨끗한 계정에서 테스트까지 했다면 — macOS Tahoe 26.4의 Teams 보고자가 그랬듯 — 남은 문제는 당신이 고칠 몫이 아닙니다. 보고하고, 기다리는 동안 우회책을 쓰십시오.
관련 읽을거리: macOS Tahoe 26.5에서 Mac 마이크가 작동하지 않을 때 · macOS Tahoe 보안 및 개인정보 보호 완전 가이드