AI 에이전트가 점점 더 유능하고 자율적으로 변함에 따라, 이러한 수준의 접근과 관련된 위험도 크게 증가할 것입니다.
이 문장은 2026년 10월 2일에 게시된 짧은 Apple 개발자 노트인 "macOS의 Full Disk Access 업데이트"를 마무리하는 내용입니다. 이 노트는 대략 200단어 분량이며 아직 아무것도 변경하지 않습니다. 하지만 이것은 툴 빌더들에게 그들이 의존해 온 스위치만으로는 곧 더 많은 것이 필요할 수 있다는 경고를 보내는 것입니다.
여기에는 무엇이 쓰여 있고, 무엇이 빠져 있으며, 만약 자신의 컨테이너 외부의 내용을 읽는 어떤 것을 배포한다면 그것이 의미하는 바가 담겨 있습니다.
Full Disk Access가 존재하는 이유
macOS는 앱을 격리(sandboxes)하고 민감한 위치를 TCC(Transparency, Consent and Control system)라는 시스템 뒤에 가둡니다. 일반적인 앱은 사용자의 Messages 데이터베이스나 Safari 기록을 읽으려면 요청해야 하며, 대부분의 경우 아예 요청할 수도 없습니다.
백업 도구는 이 모델을 깨뜨립니다. 백업 앱은 사용자가 어떤 폴더를 중요하게 생각하는지 미리 알 수 없으며, 한 번에 하나의 디렉터리에 대해 권한을 요청할 수도 없습니다. 그래서 Apple은 하나의 무딘 탈출구인 Full Disk Access를 만들었습니다. 이를 허용하면 해당 앱은 개별 리소스 제어(per-resource controls)를 완전히 우회합니다.
Apple 자체 노트는 이것을 명확하게 말하고 있습니다: Full Disk Access는 "백업 앱이 Mac에서 제대로 작동할 수 있도록 이러한 제어를 크게 우회합니다." 디자인 자체는 변하지 않았습니다. Apple이 신호하는 것은 그것이 무엇을 하는지가 아니라, 그 권한을 어떻게 얻게 되는지에 대한 변화입니다.
발표가 실제로 말하는 것
세 가지 요점, 그리고 더 이상 없습니다:
- Apple은 기존 스위치 위에 "추가적인 제어 장치"를 도입할 것입니다.
- 앱에 이 비범한 수준의 접근 권한을 '진정으로' 부여하기를 원하는 사용자는 매우 명시적인 사용자 행동을 통해서만 그렇게 할 수 있습니다.
- 동기는 위험입니다: 일부 개발자들은 사용자가 이해하지 못하는 방식으로 "파일, 메일, 메시지 및 심지어 브라우징 기록을 포함하여 시스템의 모든 것"에 노출시키는 방식으로 이 권한을 사용합니다.
"추가 제어(additional controls)"에 대한 내용이며 대체하는 것이 아닙니다. Apple은 Full Disk Access를 제거하지 않으며 백업 사용 사례는 명시적으로 보존합니다. 변경 사항은 동의 시점(consent moment)에 관한 것입니다.
언급되지 않은 것들
두 번 읽을 가치가 있습니다.
- 효력 발생일 없음. 해당 내용은 "향후(Going forward)"라고만 언급되어 있을 뿐입니다. 날짜, 릴리스 번호, 베타 버전에 대한 언급이 전혀 없습니다.
- OS 버전 미언급. 이 기능이 macOS 27.x 또는 26.4에서 시작된다거나, "내년에" 시작된다고 주장하는 모든 기사는 추론에 기반한 것입니다. 해당 내용은 그렇게 말하지 않습니다.
- API 목록 없음. 단 하나의 API도 이름 붙여지지 않았습니다. 영향을 받는 디렉토리 목록은 없으며, 어떤 TCC 서비스가 범위 내에 있는지 언급되지 않았고, 기존의
kTCCServiceSystemPolicyAllFiles 식별자가 제한 대상인지에 대한 진술도 없습니다.
- 기존 승인 건에 대한 답변 없음. 해당 내용은 이미 Full Disk Access를 부여받은 앱들이 재요청(re-prompted)될지, 예외 처리(grandfathered)될지, 아니면 그대로 둘지에 대해 언급하지 않습니다. 이는 소프트웨어를 출시하는 데 있어 가장 중요한 미해결 질문이며, 이에 대한 답변이 없습니다.
Apple은 효력 발생일이나 영향을 받는 API 목록을 발표하지 않았습니다. 이것이 발표되기 전까지는 일정을 가정하지 않고 더 엄격한 동의 흐름에 대비하는 것이 유일하게 방어 가능한 엔지니어링 입장입니다.
우리는 이번 주 macOS 27 기계에서 ~/Library/Messages/chat.db를 읽는 백그라운드 작업을 만들면서 이 문제의 실질적인 버전을 접했습니다. 해당 파일은 -rw-r--r-- 권한을 가지고 있었고, 동일 사용자 소유였으며, 같은 셸에서 읽기가 가능했습니다. 하지만 읽기 시도 결과 EPERM, 즉 errno 1 오류가 반환되었습니다.
이 오류는 파일 시스템 문제가 아니라 TCC(Transparency, Consent, and Control) 문제입니다. 제품이 광범위한 읽기에 의존한다면 이 세부 사항들이 중요합니다.
이 변경 사항이 적용되기 전에 해야 할 다섯 가지
권한(grant)은 경로가 아닌 코드 요구사항에 바인딩됩니다. 새로운 서명으로 재구축된 후에도 저희 앱은 체크박스가 켜진 상태로 목록에 남아 있었지만, 여전히 접근이 거부되었습니다. 시스템 로그에는 Failed to match existing code requirement라고 표시되어 있었습니다. TCC는 서명된 바이너리의 지정된 요구사항을 참조합니다. Ad-hoc signing이나 새로운 개발 인증서를 사용하면 CDHash가 변경되고, 기존 항목은 더 이상 일치하지 않습니다. 오래된 항목을 삭제하고, 다시 시작한 다음, 프롬프트를 재트리거하는 것이 유일한 해결책입니다. "허용"을 다시 클릭해도 아무 효과가 없습니다. 왜냐하면 해당 항목이 절대 재구축되지 않기 때문입니다.
백그라운드 프로세스는 부모의 권한으로 커버되지 않습니다. 동일한 스크립트는 터미널에서는 ~/Documents를 문제없이 읽었지만, LaunchAgent에 의해 실행될 때는 EPERM 오류가 발생했습니다. 터미널의 권한은 터미널 자체 실행 파일에 속하며, 그것이 생성하는 모든 프로세스에 속하지 않습니다. 만약 헬퍼(helper)가 읽기를 수행한다면, 사용자가 승인해야 하는 것은 그 헬퍼입니다.
일부 서비스에서 프롬프트 기능이 사라지고 있습니다. macOS 27에서는 화면 녹화 권한 요청 시 아예 거부되었다는 응답을 받았으며, 로그에는 does not allow prompting; returning denied라고 기록되었습니다. API가 더 이상 다이얼로그를 표시할 수 없으므로, 앱은 사용자를 시스템 설정(System Settings)으로 안내하여 어떤 항목을 활성화해야 하는지 설명해야 합니다.
권한 상태가 여러분의 자체 점검에서 보는 위치와 다를 수 있습니다. 저희 환경에서는 사용자 수준 TCC 데이터베이스가 더 이상 ~/Library/Application Support/com.apple.TCC/TCC.db에 있지 않았고, /private/var/containers/Data/ProtectedSystem/<UUID>/... 아래에서 해결되었습니다. 오래된 경로에 대한 건강 검진은 비어 있는 결과를 반환하며, 승인된 앱임에도 불구하고 "권한 없음"이라고 보고합니다. 데이터베이스를 읽지 말고 로그를 읽으십시오.
이 변경 사항이 적용되기 전에 해야 할 다섯 가지
애플의 로드맵을 알 필요는 없습니다. 모두 더 엄격한 동의 흐름(stricter consent flow)을 흡수하기 위해 비용 효율적으로 만드는 방법들입니다.
- 필요할 때가 되기 전에 최소 권한 원칙을 적용하라. 도구가 읽는 정확한 경로를 나열하고 작동하는 가장 좁은 API를 사용하라: 캘린더에는 EventKit, 주소록에는 Contacts, 파일 시스템 감시에는
FSEvents, 문서에는 사용자 지정 폴더를 사용한다. 만약 특정 코드 경로에서 메시지(Messages) 접근이 필요하다면, 나머지 제품 기능이 권한 부여 없이 실행될 수 있도록 이를 기능 플래그 뒤에 배치하라.
- 시스템이 표시할 위치에 목적을 선언하라. 사용자가 동의하는 순간 읽게 될 문장을 작성하라: 무엇을 읽는지, 왜 읽는지, 기기를 벗어나는 데이터가 무엇인지 명시해야 한다. 이 진술은 개인정보 보호 정책과 앱 내 설정에서도 동일하게 유지해야 한다. 이유가 이미 화면에 표시되어 있다면 '명시적 사용자 행동'을 만족시키기가 더 쉽다.
- Full Disk Access에 강하게 의존하는 것을 중단하라. 권한 부여 뒤에 있는 모든 기능은 정의된 '거부(denied)' 상태를 가져야 한다: 빈 상태, 좁은 모드 대체재, 또는 설명이 포함된 비활성화된 컨트롤이다. 앱이 충돌하거나 권한 누락 시 작동을 멈춘다면, 더 엄격한 흐름은 이를 지원 티켓으로 변질시킨다.
- 권한 실패를 명시적으로 감지하고, 서명 변경 후 매번 재검증하라.
EPERM을 파일 시스템 버그가 아닌 가능한 TCC(Transparency, Consent, and Control) 거부로 취급하라. tccd 결정을 기록하고, 새로운 ID로 빌드될 때마다 실행되는 자동화된 검사를 추가하라: 제한적 읽기 시도를 수행하고 성공을 단언하며, 실패할 경우 크게 경고를 발생시켜야 한다. 재서명(Re-signing)은 우리가 본 가장 흔한 침묵의 회귀 현상이다.
- OS 버전에 따라 사용자에게 무엇을 해야 할지 알려라. 정확한 설정 패널로 깊이 연결(Deep-link)하고, 해당 항목 이름을 명시하며, 앱 업데이트 시 재승인(re-authorizing)이 필요할 수 있음을 경고하라. 지침은 버전별로 유지해야 한다. 해당 패널의 위치는 이전에 변경된 적이 있기 때문이다.
날짜 대신 주시해야 할 것들
두 가지 신호가 이것이 실제 변화임을 알려줄 것이다. 첫째, 시스템 설정(System Settings)에 있는 Full Disk Access 패널이다: 만약 새로운 확인 단계가 나타난다면, 변경 사항이 출시된 것이다. 둘째, macOS 베타 릴리스 노트다: TCC 또는 개인정보 보호 항목에 새 컨트롤을 명시하는 내용이 일반 사용 가능 버전보다 먼저 올라올 것이다.
이 중 하나가 나타날 때까지는 이 발표를 마감일(deadline)이 아닌 설계 제약 조건(design constraint)으로 간주하세요. 이는 여러분의 코드에 어떤 가정이 이제는 책임(liabilities)이 되었는지 알려줍니다. 그것만으로도 시작하기 충분합니다.
macOS 권한(permissions), 서명(signing), 자동화(automation)에 대한 더 긴 현장 기록(field notes)을 원한다면, 여기에서 확인할 수 있습니다: https://hhfa008.github.io/personal/cases.html