macOS 27, 다른 앱의 데이터 접근을 차단하다: 무엇이 깨지고 어떻게 고치나

macOS Sonoma부터 한 앱이 다른 앱의 비공개 데이터를 읽으려 하면 프롬프트가 표시되었습니다: "App"이(가) 다른 앱의 데이터에 접근하려고 합니다. 허용하거나 거부할 수 있었고, 무엇이 깨지든 그 이유를 알 수 있었습니다. macOS 27 Golden Gate는 이 프롬프트를 제거합니다. 이제 접근은 묻지 않고 기본적으로 거부됩니다. 데이터를 원하던 앱은 그저 빈 결과나 "Operation not permitted" 오류를 받을 뿐입니다. 기능이 조용히 작동을 멈췄을 때에야 비로소 알게 됩니다.

동일한 릴리스에서 서로 연관된 세 가지 변경 사항이 같은 방향을 가리킵니다: XProtect가 이제 멀웨어가 흔히 훔치는 데이터에 대한 접근을 차단할 수 있고, 앱은 더 이상 프라이버시 데이터베이스를 직접 읽을 수 없으며, launchd는 격리(quarantine) 플래그가 붙은 property list 로드를 거부합니다. 이 가이드는 Apple의 릴리스 노트 표현을 그대로 사용해 각 변경 사항을 설명하고, 내 Mac에서 무엇이 영향을 받는지 확인하는 방법을 보여주며, 필요할 때 신중하게 접근 권한을 부여하는 방법과 부여하지 말아야 할 때를 설명합니다.

핵심 요약

• 더 이상 프롬프트가 없습니다. macOS 27에서는 다른 개발자의 앱 데이터 컨테이너와 앱 그룹 컨테이너에 대한 접근이 "기본적으로 거부"되며 개인정보 보호 및 보안(Privacy & Security) 설정에서 관리됩니다. Apple의 릴리스 노트는 이를 시스템 무결성 보호(System Integrity Protection) 항목에 포함시켰습니다.
• 명령줄 도구가 애매한 경우입니다. Apple은 알려진 문제로 다음을 명시합니다: 번들 ID가 없는 프로세스는 특정 앱의 데이터에 대한 접근 권한을 부여받을 수 없습니다. 문서화된 해결 방법은 "요구 사항이 지속되는 동안"의 전체 디스크 접근 권한(Full Disk Access)입니다.
• XProtect가 이제 "흔히 표적이 되는" 데이터를 보호합니다. Apple은 해당 목록을 공개하지 않으므로, 도구가 문제없이 읽던 앱 데이터라도 일부는 접근이 거부될 것으로 예상해야 합니다.
• 앱은 더 이상 TCC 프라이버시 데이터베이스를 직접 읽을 수 없습니다. TCC.db를 검사해 권한을 보고하던 스크립트와 도구는 다른 접근 방식이 필요합니다.
• 격리된 LaunchAgent는 로드되지 않습니다. 확인해본 Mac에서는 ~/Library/LaunchAgents의 20개 에이전트 중 9개가 격리 속성을 가지고 있었으며, 모두 세 개의 서드파티 브라우저가 작성한 업데이터 에이전트였습니다.

변경 사항: 프롬프트에서 기본 거부로

Apple은 이 영역을 단계적으로 강화해 왔습니다:

릴리스	다른 개발자의 앱 데이터에 대한 접근
macOS 13 Ventura 이하	내 계정으로 실행되는 거의 모든 프로세스에 열려 있음
macOS 14 Sonoma	보호됨; "다른 앱의 데이터"에 대한 접근 허용 여부를 묻는 프롬프트가 표시됨
macOS 15 Sequoia	보호 범위가 앱 그룹 컨테이너까지 확장됨
macOS 27 Golden Gate	프롬프트 없이 기본적으로 거부됨; 개인정보 보호 및 보안 설정에서 관리

macOS 27의 문구는 릴리스 노트의 시스템 무결성 보호 섹션에서 다음과 같습니다:

다른 개발자 팀의 앱 데이터 컨테이너 및 앱 그룹 컨테이너에 있는 파일에 접근할 때 더 이상 사용자에게 승인을 요청하는 프롬프트가 표시되지 않습니다. 이러한 접근은 기본적으로 거부되며 사용자가 개인정보 보호 및 보안 설정에서 관리할 수 있습니다.

이 문장에서 두 단어가 영향을 받는지 여부를 결정합니다. 개발자 팀(Developer teams): 이 규칙은 서로 다른 개발자의 앱에 관한 것입니다. 같은 개발자가 만든 여러 앱은 같은 팀이 서명했기 때문에 여전히 그룹 컨테이너를 공유할 수 있습니다. 컨테이너(Containers): 이 규칙은 앱이 Library에 보관하는 샌드박스 데이터 폴더를 다룹니다. Documents 폴더나 Desktop, 직접 저장한 파일은 포함하지 않습니다 — 이들은 별도의 파일 및 폴더 권한을 가지며, 이번 변경으로 달라지지 않았습니다.

"다른 앱의 데이터"란 무엇인가

샌드박스 앱은 홈 폴더 내 두 곳에 비공개 파일을 보관합니다:

• ~/Library/Containers/ — 샌드박스 앱마다 번들 ID로 이름 붙은 폴더 하나씩, 실제 데이터는 Data/ 아래에 있음
• ~/Library/Group Containers/ — 같은 개발자의 여러 앱이 공유하는 폴더로, group.… 형식이거나 앞에 개발자 팀 ID가 붙은 이름

폴더 이름만 나열하는 것은 무해하며 규모를 보여줍니다. 사용했던 Mac(아직 Tahoe 26.5.2 실행 중)에서:

ls ~/Library/Containers | wc -l                    # 956
ls ~/Library/Group\ Containers | wc -l             # 187
ls ~/Library/Group\ Containers | grep -vc '^group\.'   # 70 named with a team ID

956개의 앱 컨테이너와 187개의 그룹 컨테이너가 있으며, 이제 이들 각각은 기본적으로 다른 개발자의 모든 앱에 대해 접근이 차단됩니다. 대부분은 문제없습니다. 제대로 동작하는 앱이라면 다른 앱의 데이터베이스를 읽을 이유가 없기 때문입니다. 문제는 정당하게 그 데이터를 읽어주던 도구들입니다.

문제가 발생했을 때의 모습

이 실패에는 대화 상자가 없으므로 증상으로 나타납니다. 가장 흔한 증상들:

증상	가능성 있는 원인
~/Library/Containers/…/Data 또는 ~/Library/Group Containers/ 아래 경로에서 터미널에 ls: … : Operation not permitted 표시	셸을 실행하는 책임 앱(Terminal, iTerm, IDE 등)이 해당 앱 데이터에 접근 권한이 없음
백업, 동기화 또는 내보내기 도구가 앱 데이터를 건너뛰거나 "permission denied"를 보고함	도구가 해당 컨테이너를 읽을 권한이 없음
가져오기 도구가 다른 앱에서 가져올 것을 찾지 못함	조용히 거부됨; 가져오기 도구에는 빈 폴더나 없는 폴더로 보임
런처, 클립보드 또는 자동화 도구가 다른 앱의 데이터를 읽던 기능을 잃음	동일한 거부가 결과 누락으로 나타남
cron이나 launchd로 실행되는 스크립트가 어제 읽었던 경로에서 실패함	번들 ID가 없는 명령줄 프로세스 — 아래의 알려진 문제 참고

"Operation not permitted"(EPERM)은 macOS 프라이버시 제어가 파일 접근을 차단할 때 발생하는 표준 오류입니다. 파일이 없다는 뜻도 아니고, sudo가 도움이 된다는 뜻도 아닙니다 — 프라이버시 보호는 root에도 적용됩니다.

올바르게 접근 권한 부여하기

Apple은 이 제어 기능을 시스템 설정 → 개인정보 보호 및 보안에 배치했으며, 아래의 알려진 문제는 구체적으로 파일 및 폴더(Files & Folders) 패널을 가리킵니다. 이제 다른 앱의 데이터에 대한 접근은 일회성 프롬프트 대신 앱별로 이곳에서 부여됩니다.

일반 앱의 경우

1. 시스템 설정 → 개인정보 보호 및 보안 → 파일 및 폴더를 엽니다.
2. 접근 권한이 필요한 앱을 찾아 펼칩니다.
3. 더 넓은 권한 대신 필요한 특정 데이터만 허용합니다.

macOS 27에서 이 패널의 정확한 구성은 Tahoe와 다를 수 있습니다. Apple의 노트는 접근이 어디서 관리되는지를 설명할 뿐, 클릭 단위의 경로를 설명하지는 않습니다. 원칙은 어느 쪽이든 같습니다: 기능이 동작하는 데 필요한 가장 좁은 범위의 접근을 부여하십시오.

앱의 문서에서 대신 **전체 디스크 접근 권한(Full Disk Access)**을 부여하라고 안내한다면 그것도 유효합니다 — 전체 디스크 접근 권한은 앱 데이터 컨테이너를 포함합니다. 하지만 Mail, Messages, Safari 데이터를 포함해 홈 폴더의 다른 모든 것도 포함하므로, 디스크를 읽는 것이 본업인 도구, 즉 백업 소프트웨어나 디스크 분석기 같은 것에만 사용하십시오.

스크립트, cron 작업, 명령줄 도구의 경우

여기서 Apple은 알려진 문제를 다음과 같이 명시합니다:

파일 및 폴더 패널에서, 번들 ID가 없는 프로세스는 다른 개발자 팀이 소유한 특정 앱 데이터 컨테이너나 앱 그룹 컨테이너에 대한 접근 권한을 부여받을 수 없습니다.

해결 방법: 해당 접근이 실제로 필요한지 검토하십시오. 필요한 경우, 요구 사항이 지속되는 동안 해당 프로세스에 전체 디스크 접근 권한을 부여하십시오.

"번들 ID가 없는 프로세스"란 일반 실행 파일을 말합니다: Python 인터프리터, launchd가 실행하는 셸 스크립트, Homebrew로 설치된 바이너리, cron이 시작하는 데몬. 중요한 것은 그것이 어떻게 실행되는가입니다:

• Terminal에서 실행하면, 프라이버시 결정은 번들 ID를 가지고 있는 Terminal(또는 iTerm, IDE)에 귀속됩니다. 그 앱에 접근 권한을 부여하면 보통 그 안에서 실행하는 명령까지 함께 처리됩니다.
• launchd나 cron이 실행하면, 귀속시킬 앱이 없습니다. 프로세스 자체가 권한을 필요로 하며, 알려진 문제에 따르면 이는 해당 바이너리에 전체 디스크 접근 권한을 부여해야 함을 의미합니다.

명령줄 바이너리를 전체 디스크 접근 권한에 추가하려면, 전체 디스크 접근 권한 목록에서 **+**를 클릭하고 ⌘⇧G를 누른 다음 경로(예: /opt/homebrew/bin/python3 또는 /usr/sbin/cron)를 붙여넣어 추가합니다. Apple의 표현인 "요구 사항이 지속되는 동안"은 문자 그대로 받아들일 가치가 있습니다. 작업을 위해 부여하고, 끝나면 제거하십시오. 전체 디스크 접근 권한을 가진 인터프리터는 그것이 실행하는 모든 스크립트에 그 접근 권한을 넘겨줍니다.

XProtect 계층

같은 섹션의 두 번째 노트는 요청자가 누구인지에 좌우되지 않는 보호 계층을 추가합니다:

XProtect는 이제 악성 소프트웨어가 흔히 표적으로 삼는 앱 데이터에 대한 접근을 제한할 수 있습니다. 다른 개발자 팀의 앱이 생성한 파일에 접근하는 것은 기본적으로 거부될 수 있지만 사용자가 개인정보 보호 및 보안 설정에서 관리할 수 있습니다.

Apple은 무엇이 "흔히 표적이 되는" 데이터로 간주되는지 밝히지 않습니다. Mac 정보 탈취 멀웨어(infostealer)가 무엇을 찾는지는 보안 연구자들에 의해 잘 문서화되어 있습니다: 저장된 비밀번호와 쿠키가 있는 브라우저 프로필, 암호화폐 지갑 데이터, 메시징 앱 세션 파일. XProtect의 목록이 이들과 크게 겹칠 것이라는 추측은 합리적이지만, 어디까지나 추측입니다.

실질적인 영향은 이렇습니다: 예를 들어 다른 앱의 세션이나 프로필 데이터를 정당하게 읽는 도구가, 올바른 것처럼 보이는 권한을 부여한 뒤에도 macOS 27에서 거부될 수 있습니다. 그런 일이 발생하면 먼저 개인정보 보호 및 보안에서 대기 중인 항목이 있는지 확인하십시오. 없다면 해당 도구의 개발자에게 macOS 27에서 테스트했는지 물어볼 가치가 있습니다 — 수정은 그쪽에서 이루어져야 할 수도 있습니다.

앱은 더 이상 프라이버시 데이터베이스를 읽을 수 없습니다

TCC(Transparency, Consent and Control) 데이터베이스는 카메라, 마이크, 화면 기록, 파일 등을 사용하도록 허용한 앱을 기록합니다. 사용자별 사본은 ~/Library/Application Support/com.apple.TCC/TCC.db에 있습니다. 수년간 전체 디스크 접근 권한을 가진 도구는 이를 직접 읽어 권한을 보고할 수 있었습니다.

macOS 27 릴리스 노트는 TCC 지원 중단 항목에서 다음과 같이 밝힙니다:

앱은 더 이상 로컬 TCC 데이터베이스에 직접 접근할 수 없습니다.

Tahoe에서도 이를 읽으려면 전체 디스크 접근 권한이 필요합니다. 테스트 Mac에서 그 권한이 없는 셸로 실행하면:

sqlite3 ~/Library/Application\ Support/com.apple.TCC/TCC.db "select service from access limit 1"
# Error: unable to open database ".../com.apple.TCC/TCC.db": authorization denied

macOS 27에서는 앱 전반에 걸쳐 이 직접 경로가 막힙니다. 영향을 받는 대상:

• Mac 관리자: 규정 준수 스크립트나 인벤토리 확장 프로그램이 권한을 보고하기 위해 TCC.db를 조회하던 경우. 지원되는 경로는 데이터베이스가 아니라 기기 관리 도구의 개인정보 보호 환경설정 정책 제어(PPPC) 보고 기능입니다.
• 유틸리티: 파일을 읽어 "어떤 앱이 어떤 권한을 가지고 있는지" 보여주던 도구.
• 멀웨어: 이미 접근할 수 있는 것이 무엇인지 알아내기 위해 데이터베이스를 읽던 경우. 이것이 이번 변경의 이유입니다.

내 Mac의 경우, 시스템 설정 → 개인정보 보호 및 보안은 여전히 권한을 검토하고 철회할 수 있는 곳입니다. 각 카테고리는 해당 권한을 가진 앱을 나열합니다.

또 다른 조용한 변경: 격리된 LaunchAgent

이 변경은 앱 데이터에 관한 것은 아니지만 같은 방식으로 조용히 실패하며, 테스트 Mac에서는 이 글의 다른 어떤 내용보다 더 큰 영향을 미친 것으로 드러났습니다. 릴리스 노트는 Launch Daemons and Agents 항목에서 다음과 같이 밝힙니다:

launchd는 더 이상 격리(quarantine) 확장 속성이 붙은 launchd property list 파일 로드를 지원하지 않습니다.

LaunchAgent는 ~/Library/LaunchAgents에 있는 작은 .plist 파일로, 로그인 시나 예약된 일정에 따라 프로그램을 시작하도록 launchd에 지시합니다: 업데이터, 동기화 도우미, 메뉴 막대 도구 등입니다. 격리 속성(com.apple.quarantine)은 인터넷에서 받은 파일, 그리고 자체적으로 격리 규칙의 적용을 받는 앱이 생성한 파일에 macOS가 붙이는 플래그입니다.

확인은 반복문 한 번이면 됩니다:

for f in ~/Library/LaunchAgents/*.plist /Library/LaunchAgents/*.plist /Library/LaunchDaemons/*.plist; do
  xattr "$f" 2>/dev/null | grep -q com.apple.quarantine && echo "QUARANTINED  $f"
done

테스트 Mac에서:

폴더	Property list 수	격리됨
~/Library/LaunchAgents	20	9
/Library/LaunchAgents	8	0
/Library/LaunchDaemons	27	0

격리된 9개 파일 모두 업데이터 에이전트였으며, 세 개의 서드파티 Chromium 기반 브라우저가 각각 세 개씩 생성한 것이었습니다. 격리 값의 세 번째 필드는 해당 파일을 생성한 앱의 이름을 나타냅니다:

xattr -p com.apple.quarantine ~/Library/LaunchAgents/some.agent.plist
# 0081;<timestamp>;<name of the app that wrote it>;<id>

이 중 적어도 하나는 오늘날 Tahoe에서 로드되어 실행 중입니다. Apple의 노트에 따르면 macOS 27에서는 이러한 에이전트가 로드되지 않으므로, 해당 브라우저들의 백그라운드 업데이터는 조용히 멈출 것입니다. Golden Gate 자체에서는 이를 확인하지 못했으며, 벤더들이 이미 에이전트 작성 방식을 바꿨을 수도 있습니다. 하지만 이것이야말로 몇 달 동안 눈에 띄지 않고 지나가는 유형의 문제입니다: 눈에 보이게 실패하는 것은 아무것도 없고, 브라우저는 그저 스스로 업데이트를 멈출 뿐입니다.

격리된 에이전트 고치기

1. 먼저 앱을 업데이트하십시오. 벤더가 이미 수정했다면 새 버전이 해당 속성 없이 에이전트를 다시 작성할 것입니다.
2. 직접 고쳐야 한다면, 신뢰하기 전에 먼저 검사하십시오. 무엇을 실행하는지 확인합니다:

plutil -p ~/Library/LaunchAgents/some.agent.plist          # look at Program / ProgramArguments
codesign -dv --verbose=2 "/path/to/the/program" 2>&1 | grep -E "Authority|TeamIdentifier"

3. 프로그램이 예상한 것과 일치할 때만, 속성을 제거하고 에이전트를 다시 로드합니다:

xattr -d com.apple.quarantine ~/Library/LaunchAgents/some.agent.plist
launchctl bootout gui/$(id -u) ~/Library/LaunchAgents/some.agent.plist 2>/dev/null
launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/some.agent.plist

알아보지 못하는 에이전트에서 격리 속성을 제거하지 마십시오. LaunchAgent를 통한 지속성(persistence)은 전형적인 멀웨어 기법이며, 이번 변경은 다운로드한 .plist가 조용히 스스로를 설치하는 것을 막기 위해 설계되었습니다. 알아보지 못하는 격리된 에이전트는 다시 로드할 이유가 아니라 조사할 이유입니다. 로그인 항목 및 백그라운드 앱 가이드에서 에이전트를 설치한 앱까지 거슬러 올라가 추적하는 방법을 설명합니다.

업그레이드 전후 5분 점검

업그레이드에 따라 무엇이 바뀔지 확인하려면 Tahoe에서, 이미 바뀐 것을 확인하려면 macOS 27에서 다음을 실행하십시오:

# 1. How much app data is now guarded by default
ls ~/Library/Containers | wc -l
ls ~/Library/Group\ Containers | wc -l

# 2. Scheduled jobs that may read other apps' data
crontab -l 2>/dev/null
ls ~/Library/LaunchAgents

# 3. Quarantined launch items that will stop loading
for f in ~/Library/LaunchAgents/*.plist /Library/LaunchAgents/*.plist /Library/LaunchDaemons/*.plist; do
  xattr "$f" 2>/dev/null | grep -q com.apple.quarantine && echo "QUARANTINED  $f"
done

# 4. Scripts that read the privacy database directly
grep -rl "TCC.db" ~/bin ~/scripts ~/.local/bin 2>/dev/null

4단계의 폴더는 스크립트를 보관하는 위치에 맞게 조정하십시오. 각 항목에 대해 Apple의 해결 방법과 같은 질문을 스스로에게 던지십시오: 이 접근이 실제로 필요한가?

접근 권한을 부여하지 말아야 할 때

이 변경이 존재하는 이유는 "내 계정으로 실행되는 모든 프로세스가 어떤 앱의 데이터든 읽을 수 있다"는 것이 Mac 정보 탈취 멀웨어가 의존하던 주된 수단이었기 때문입니다. 기능을 되찾기 위해 접근 권한을 내주기 전에, 몇 가지 원칙이 도움이 됩니다:

• 좁은 범위의 권한을 선호하십시오. 전체 디스크 접근 권한보다는 파일 및 폴더의 앱별 접근 권한을, 터미널 앱 전체에 대한 전체 디스크 접근 권한보다는 바이너리 하나에 대한 전체 디스크 접근 권한을 선택하십시오.
• 명령줄에 대한 권한 부여는 임시로 하십시오. Apple 자신의 표현대로 "요구 사항이 지속되는 동안"입니다. 제거할 시점을 캘린더에 남겨두십시오.
• 새로운 요청은 의심하십시오. 지난달까지 다른 앱의 데이터를 읽을 이유가 없었던 앱이 이번 달에 전체 디스크 접근 권한을 요청한다면 다시 살펴볼 가치가 있습니다.
• 신뢰하지 않는 웹페이지에서 권한을 부여하는 명령을 절대 붙여넣지 마십시오. 사용자를 유도해 Terminal 명령을 실행하게 만드는 사회공학 캠페인이야말로 이러한 보호 장치가 우회되는 정확한 방식입니다. 이는 터미널 붙여넣기 멀웨어 경고에 관한 글에서 설명합니다.

일반적인 문제 해결

sudo를 사용해도 "Operation not permitted"가 발생하는 경우

문제: sudo ls ~/Library/Containers/…/Data가 여전히 실패합니다.

해결 방법: 프라이버시 보호는 Unix 권한 문제가 아니며, root도 그 적용을 받습니다. 개인정보 보호 및 보안에서 책임 앱(Terminal 또는 명령을 실행한 앱)에 접근 권한을 부여하십시오.

launchd 작업은 실패하지만 같은 명령이 Terminal에서는 동작하는 경우

문제: 예약된 스크립트가 직접 실행하면 다른 앱의 데이터를 정상적으로 읽지만, 예약된 시간에는 실패합니다.

해결 방법: Terminal에서는 접근이 Terminal에 귀속됩니다. launchd 아래에서는 귀속시킬 앱이 없고, Apple의 알려진 문제에 따르면 번들 ID가 없는 프로세스는 앱별 접근 권한을 받을 수 없습니다. 작업이 실행하는 정확한 바이너리에 전체 디스크 접근 권한을 부여하고, 작업이 더 이상 필요 없어지면 제거하십시오.

백업 도구가 일부 앱 데이터를 조용히 건너뛴 경우

문제: 백업은 완료되었지만, 백업 안에서 어떤 앱의 컨테이너가 없거나 비어 있습니다.

해결 방법: 백업 앱에 전체 디스크 접근 권한을 부여하고 — 이는 정당한 사용 사례 중 하나입니다 — 다시 실행하십시오. 도구의 로그에서 권한 오류를 확인하십시오. 대부분의 도구는 백업이 "성공"하더라도 이를 보고합니다.

업그레이드 후 오류 없이 기능을 잃은 앱

문제: 가져오기, 동기화 또는 검색 기능이 아무것도 반환하지 않습니다.

해결 방법: 개인정보 보호 및 보안에서 허용할 수 있는 항목이 있는지 확인하고, 벤더의 릴리스 노트에서 macOS 27 호환성을 확인하십시오. 원하는 데이터가 XProtect가 보호하는 종류라면 수정은 개발자 쪽에서 이루어져야 할 수 있습니다.

백그라운드 업데이터가 업데이트를 멈춘 경우

문제: 업그레이드 이후 앱의 자동 업데이트가 조용히 멈췄습니다.

해결 방법: 위의 반복문으로 해당 앱의 LaunchAgent에 격리 속성이 있는지 확인하십시오. 먼저 앱을 수동으로 업데이트하십시오. 그것이 가장 확실하게 유지되는 해결책입니다.

자주 묻는 질문

macOS 27은 "다른 앱의 데이터에 접근" 프롬프트를 제거했나요?

예. Apple의 릴리스 노트는 이러한 접근이 "더 이상 사용자에게 승인을 요청하지 않는다"고, "기본적으로 거부된다"고 밝힙니다. 이제는 발생 시점에 프롬프트에 응답하는 대신 개인정보 보호 및 보안 설정에서 관리합니다.

같은 개발자의 앱에도 영향을 미치나요?

아니요. 이 규칙은 "다른 개발자 팀"에 적용됩니다. 같은 개발자 팀이 서명한 앱은 여전히 그룹 컨테이너를 통해 데이터를 공유할 수 있으며, 이것이 관련 앱 모음이 계속 동작하는 방식입니다.

전체 디스크 접근 권한만으로 여전히 충분한가요?

명령줄 관련 알려진 문제에 대한 Apple 자체 해결 방법에 따르면 그렇습니다 — 전체 디스크 접근 권한은 앱 데이터 컨테이너에 대한 접근을 부여합니다. XProtect의 새로운 제한은 흔히 표적이 되는 데이터에 관한 것으로 Apple이 별개라고 설명하는 부분이며, 일부 데이터에는 여전히 적용될 수 있습니다.

왜 내 스크립트는 더 이상 TCC.db를 읽을 수 없나요?

Apple의 macOS 27 노트는 앱이 더 이상 로컬 TCC 데이터베이스에 직접 접근할 수 없다고 명시합니다. 권한을 검토하려면 시스템 설정을 사용하고, 관리자라면 기기 관리 도구의 보고 기능을 사용하십시오.

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

그것이 무엇을 실행하는지, 그리고 프로그램이 예상하는 개발자에 의해 서명되었는지 확인한 경우에만 안전합니다. 격리를 제거하는 것은 정확히 멀웨어가 원하는 행동이며, 이것이 애초에 macOS 27이 격리된 에이전트 로드를 중단한 이유입니다.

결론

이번 macOS 27 변경 사항들의 주제는 일관됩니다: 한 앱에 속한 데이터는 단지 같은 계정으로 실행된다는 이유만으로 더 이상 다른 앱에서 사용할 수 없으며, 인터넷에서 다운로드한 파일은 단지 올바른 폴더에 놓였다는 이유만으로 더 이상 백그라운드 프로세스가 되지 않습니다. 대부분의 사람들에게 이는 분명한 이득입니다. 바로 그 접근 방식이 Mac 정보 탈취 멀웨어가 의존하던 것이었기 때문입니다.

대가는 눈에 띄지 않게 발생하는 문제입니다. 스크립트, 백업 도구, 가져오기 도구, 심지어 브라우저 업데이터까지 조용히 작동을 멈출 수 있습니다. 5분 점검을 실행하고, 도구가 정말로 필요로 할 때는 좁고 임시적으로 접근 권한을 부여하며, 업그레이드 후 무언가 조용해지면 다른 무엇보다 먼저 개인정보 보호 및 보안을 확인하십시오.

관련 글: macOS 27이 "Open using Rosetta"를 무시함: 누락된 Intel 플러그인 해결하기 · 화면 기록 및 전체 디스크 접근 권한이 계속 요청되는 문제 · "앱이 손상되었습니다"와 격리 속성 · macOS 27 Golden Gate 출시일 업데이트 가이드