macOS 27, 다른 팀의 컨테이너 접근을 묻지도 않고 차단합니다

macOS에서 containerURL(forSecurityApplicationGroupIdentifier:)는 권한(entitlement)이 전혀 없는 앱 그룹에 대해서도 멀쩡해 보이는 URL을 반환합니다. Apple은 이 점을 분명히 문서화해 두었습니다. iOS에서는 식별자가 유효하지 않으면 nil을 반환하지만, macOS에서는 “앱 그룹이 유효하지 않더라도 예상되는 형태의 URL이 항상 반환된다”는 것입니다.⁴ macOS 27에서는 이 동작이 새로운 제약과 정면으로 충돌합니다.

macOS 27부터는 다른 팀의 컨테이너 접근을 차단하기 전에 사용자에게 묻지 않습니다. 다른 개발자 팀의 앱 데이터 컨테이너나 앱 그룹 컨테이너에 있는 파일을 읽으면 예전에는 승인 요청 창이 떴습니다. 이제는 기본적으로 실패하며, 사용자가 개인정보 보호 및 보안 설정에서 해당 항목을 직접 찾아내야만 되돌릴 수 있습니다.¹

이 두 가지 사실이 겹치면, 정작 실패가 일어나는 지점에는 아무런 신호도 남지 않습니다. 대화 상자는 뜨지 않습니다. 메서드는 nil 대신 URL을 돌려줍니다. 경로도 예상했던 것과 똑같이 생겼습니다. 차단은 한참 뒤 파일 작업 단계에서야 드러나고, 그때는 파일이 없는 것처럼 보입니다.

요약

macOS 27은 다른 팀의 앱 데이터 컨테이너와 앱 그룹 컨테이너에 접근할 때 뜨던 사용자 승인 요청을 없애고, 그런 접근을 기본적으로 차단합니다. 사용자가 제어할 수 있는 위치는 개인정보 보호 및 보안 설정으로 옮겨졌습니다.¹ 이 변경은 버그 수정이 아니라 System Integrity Protection의 새 기능으로 분류되어 있습니다. 앱 그룹 컨테이너에 관한 Apple 자체 안내 문서는 여전히 macOS 27이 없애 버린 그 확인 창 동작을 설명하고 있습니다. macOS의 API는 접근할 수 없는 그룹에 대해서도 형식이 온전한 URL을 반환하므로, 차단은 API 호출 시점이 아니라 읽기 시점에 나타납니다. 같은 팀 안에서의 접근은 영향을 받지 않습니다. 경계선은 Team ID입니다.

무엇이 바뀌었나

macOS 27 릴리스 노트에는 System Integrity Protection 항목 아래 한 문장이 실려 있습니다.¹

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

Radar 161835690. 두 개의 절, 두 개의 별개 변경입니다.

앞 절은 확인 창을 없앱니다. 뒤 절은 차단을 기본값으로 못 박습니다. 이 변경을 다루는 기사들은 대개 차단 쪽을 앞세우는데, 사실 그쪽이 덜 흥미로운 절반입니다. 기본값을 조이는 일은 늘 있는 일입니다. 반면 사라진 확인 창은 사용자가 겪는 실패의 모양을, 그리고 개발자가 받아 보게 될 버그 리포트의 모양을 바꿔 놓습니다.

예전에는 사용자가 대화 상자를 보고 판단을 내렸습니다. 사용자가 거절했다면, 앱은 사람이 내린 선택이 있었다는 사실을 알 수 있었습니다. 이제는 아무에게도 묻지 않습니다. 접근은 그냥 일어나지 않고, 이를 다시 켜는 유일한 경로는 누가 알려 주지 않는 한 사용자가 들여다볼 이유가 없는 설정 창뿐입니다.

Apple 문서가 아직도 설명하고 있는 이전 동작

이 제약은 두 릴리스 앞서 도입된 보호 장치 위에 얹힌 것입니다. 앱 그룹 컨테이너에 관한 Apple 가이드는 이렇게 적고 있습니다.²

“macOS 15 이상에서 앱 그룹 컨테이너는 앱에 앱 샌드박스 기능이 없더라도 앱의 로컬 파일에 [System Integrity Protection]을 제공합니다. 이러한 앱 그룹 컨테이너는 앱 그룹에 속하지 않은 앱의 접근을 제한합니다. 앱 그룹에 속하지 않은 앱이 앱 그룹이나 앱 데이터 컨테이너 내부 위치에 접근을 시도하면 사용자에게 승인을 요청하는 창이 표시됩니다.”

이 페이지는 확인 창을 현재 시제로 설명합니다. 이 글을 쓰는 시점까지 Apple은 macOS 27에 맞춰 문서를 갱신하지 않았습니다.

현실적인 결과는 이렇습니다. 이 문제에 부딪힌 개발자가 문서를 검색해 공식 페이지를 찾아내면, 승인 대화 상자가 뜰 것이라는 설명을 읽게 됩니다. 대화 상자는 뜨지 않습니다. 그러면 그 개발자는 확인 창이 고장 났거나 자기 앱의 권한 설정이 잘못됐다고 결론 내릴 것입니다. 충분히 합리적인 추론이지만, 결국 엉뚱한 곳에서 시간을 쓰게 됩니다.

이 글의 작성 시점을 믿기보다는, 해당 페이지가 지금 어떤 상태인지 직접 확인해 보시기 바랍니다. 문서는 언젠가 따라잡습니다.

실패가 뒤늦게 드러나는 이유

정책 변경을 디버깅 문제로 바꿔 놓는 것은 바로 API의 동작 방식입니다.

containerURL(forSecurityApplicationGroupIdentifier:)에 대한 Apple의 레퍼런스는 플랫폼별 차이를 명확히 밝히고 있습니다.⁴

“파일 시스템에서 해당 그룹의 공유 디렉터리 위치를 가리키는 URL입니다. iOS에서는 그룹 식별자가 유효하지 않을 경우 값이 nil입니다. macOS에서는 앱 그룹이 유효하지 않더라도 예상되는 형태의 URL이 항상 반환되므로, 사용하기 전에 해당 디렉터리에 실제로 접근할 수 있는지 반드시 확인하십시오.”

논의(Discussion) 섹션은 같은 경고를 반복합니다. 권한이 없는 그룹 식별자로 이 메서드를 호출해도 예상되는 형태의 URL이 그대로 반환되지만, 그 디렉터리는 존재하지 않으며 샌드박스가 적용된 앱은 그것을 만들 수도 없습니다.⁴

그래서 흔히 쓰는 방어 패턴은 여기서 아무 역할도 하지 못합니다.

// This guard passes on macOS regardless of entitlement.
guard let url = FileManager.default.containerURL(
    forSecurityApplicationGroupIdentifier: "ABCDE12345.com.example.shared"
) else {
    return  // never taken on macOS
}

URL은 형식상 온전합니다. ~/Library/Group Containers/<team>.<group>을 가리키는데, 그 컨테이너가 실제로 있다면 바로 그 자리입니다. 파일 작업을 실행하기 전까지는 모든 것이 성공처럼 읽힙니다.

해법은 성공할지 여부를 미리 묻는 대신, 일단 읽기를 시도하고 실패를 처리하는 것입니다.

let fm = FileManager.default
guard let url = fm.containerURL(
    forSecurityApplicationGroupIdentifier: groupID
) else { return }  // macOS never takes this branch

do {
    _ = try fm.contentsOfDirectory(atPath: url.path)
    // Reached the container.
} catch {
    // On macOS 27 a cross-team denial lands here.
    // No prompt fired. The user was never asked.
    presentContainerUnavailable(error)
}

사전 검사 용도로 isReadableFile(atPath:)에 손을 뻗고 싶은 유혹은 참으시기 바랍니다. Apple은 그런 부류의 검사 전반을 권하지 않습니다.³

“파일 시스템의 현재 상태나 특정 파일의 상태를 근거로 동작을 예단하는 방식은 권장하지 않습니다. 그렇게 하면 이상한 동작이나 경쟁 조건이 발생할 수 있습니다. 작업이 성공할지 미리 알아내려 애쓰기보다, 일단 작업(파일 로딩이나 디렉터리 생성 같은)을 시도하고 오류를 확인한 뒤 그 오류를 적절히 처리하는 편이 훨씬 낫습니다.”

이번 변경에만 해당하는 두 번째 이유도 있습니다. 같은 페이지는 isReadableFile(atPath:) 메서드가 읽기 가능 여부를 판단할 때 “실제 사용자 ID와 그룹 ID를 사용한다”고 밝히고 있습니다.³ 이는 POSIX 권한 평가입니다. 다른 팀 컨테이너에 대한 차단은 POSIX 위에 얹힌 정책 판단이므로, 권한 비트 검사가 그것을 반영한다는 보장이 없습니다. 결국 실패할 읽기 앞에서 true를 반환하는 사전 검사는 아예 없느니만 못합니다. 예기치 못한 실패를 원인에서 더 멀리 떨어진 곳으로 밀어내기 때문입니다.

iOS 27에서 canOpenURL이 지원 중단되었습니다 글을 읽으신 분이라면 같은 모양을 알아보실 것입니다. Apple은 미리 물어보는 능력을 계속 걷어내고, 시도해 보는 능력만 남깁니다. 시도하고 처리하기는 특정 API 하나를 위한 우회책이 아니라 점점 일반적인 답이 되어 가고 있습니다.

플랫폼 간 비대칭도 눈여겨볼 만합니다. iOS는 nil을 반환해 호출 지점에서 정직하게 실패합니다. macOS는 URL을 반환하고 실패를 뒤로 미룹니다. macOS 27의 변경은 원래도 둘 중 더 조용한 쪽이었던 플랫폼에서, 마지막 남은 신호였던 확인 창마저 없앤 셈입니다.

또 하나의 함정이 있습니다. Apple은 컨테이너 위치가 이후 릴리스에서 바뀔 수 있으니 ~/Library/Group Containers/...를 손으로 조립하지 말고 이 메서드가 반환하는 URL을 항상 쓰라고 안내합니다.⁴ 그 경로를 하드코딩해 둔 쪽은 확인할 메서드 호출 자체가 없고, 읽기 가능 여부 검사를 넣을 자리도 없습니다.

SDK 버전으로 갈리는 변경은 아닐 것입니다

자연스럽게 나오는 질문은 예전 SDK를 계속 쓰면 이 변경을 미룰 수 있느냐입니다. 릴리스 노트는 여기에 답하지 않습니다.

대신 릴리스 노트가 보여 주는 것은 하나의 패턴입니다. macOS 27 노트는 별개의 11개 항목에서 SDK 기준을 명시하는 표현을 씁니다. “macOS 27.0 SDK로 빌드한 앱에서는”, “27.0 SDK로 빌드한 앱에서는”, “프로젝트의 최소 배포 타깃이 27.0보다 낮은 경우”처럼 말입니다.¹ Apple은 그런 단서가 필요할 때 분명히 붙입니다.

그런데 컨테이너 항목에는 그런 단서가 전혀 없습니다. 그 부재가 의도적이라고 보는 합리적인 해석을 따르면, 이 제약은 어떤 SDK로 빌드했든 macOS 27에서 실행되는 모든 바이너리에 적용되는 OS 차원의 정책입니다.

다만 Apple이 직접 그렇게 말한 적은 없으므로, 이것은 사실 진술이 아니라 근거 있는 추론으로 다루시기 바랍니다. 어느 쪽이든 실무적 결론은 같습니다. 예전 SDK를 완화책으로 삼을 계획은 세우지 마십시오. 접근이 실패한다는 전제로 계획하십시오.

실제로 타격을 입는 쪽

같은 팀 안에서의 접근은 그대로입니다. Apple의 규칙은 Team ID 경계를 우연이 아니라 구조적인 것으로 못 박습니다. “서로 다른 개발자 팀은 같은 앱 그룹을 사용할 수 없습니다.” 반면 한 팀은 자기 앱들과 보조 프로세스 전반에서 하나의 그룹을 공유할 수 있습니다.²

깨지는 앱은 그 선을 넘어가는 쪽입니다.

마이그레이션 및 가져오기 도구. 경쟁 제품이나 이전 제품의 컨테이너를 읽어 사용자 데이터를 가져오는 모든 것이 해당됩니다. 가장 명확한 사례이고, 원래도 확인 창 뒤에 놓여 있었지만 사용자들이 종종 승인해 주던 경로입니다.

백업 및 동기화 유틸리티. 앱 컨테이너를 열거해 백업하는 도구는 이제 자기 팀 밖에 있는 것을 조용히 건너뜁니다.

주인이 바뀐 컴패니언 앱. 코드는 하나도 바뀌지 않기 때문에 가장 날카로운 사례입니다. 두 앱이 하나의 Team ID로 출시되어 그룹을 문제없이 공유하고 있었습니다. 인수, 팀 분리, 또는 별도 개발자 계정으로의 이전이 두 앱을 서로 다른 Team ID 아래로 갈라놓습니다. 앱 그룹 식별자는 여전히 멀쩡해 보이고, URL도 여전히 잘 풀리는데, 데이터만 도착하지 않습니다.

마지막 사례는 좀 더 곱씹어 볼 만합니다. 시점 자체가 불리하게 작용하기 때문입니다. Team ID 변경은 서명과 배포를 관리하는 사람이 처리하는데, 그 자리에서는 공유 컨테이너 의존성이 대개 보이지 않습니다. 코드는 컴파일됩니다. 두 앱 모두 출시됩니다. 어느 쪽 테스트도 이를 잡지 못합니다. 단위 테스트는 팀이 다른 실제 컨테이너를 건드리지 않고, CI는 빌드 머신이 가진 신원으로 두 타깃을 모두 돌리기 때문입니다. 실패는 프로덕션의 사용자 기기에서, 사용자가 당연히 같은 제품이라고 여기는 두 앱 사이에 동기화가 끊긴 데이터의 모습으로 드러납니다.

Team ID 마이그레이션을 계획하고 있다면, 점검은 기계적으로 하면 됩니다. 타깃들이 선언한 앱 그룹 식별자를 전부 grep한 뒤, 각각에 대해 어떤 번들이 그것을 읽는지 목록으로 만드십시오. 앞으로 서로 다른 Team ID 아래로 흩어질 번들들이 함께 읽는 식별자가 있다면, 그것이 깨지는 지점입니다. 이전 전이라면 10분짜리 확인이고, 이전 후라면 지원 요청 건입니다.

Apple은 앱 그룹에 참여할 수 있는 대상을 나열해 두었습니다. 번들 구조의 메인 실행 파일, 앱 익스텐션, App Clips, XPC Services입니다.² 각각이 이 문제가 드러날 수 있는 자리입니다.

진단하는 법

코드 버그라고 단정하기 전에 확인해 볼 만한 것이 두 가지 있습니다.

먼저 시스템이 애초에 권한을 검증하기는 했는지 확인하십시오. Apple은 실행 중인 프로세스에 대해 권한 검증 완료 플래그를 확인하는 런타임 점검 방법을 문서화해 두었습니다.²

sudo launchctl procinfo <pid>

앱 그룹 승인 개념이 생기기 전에 만들어진 프로비저닝 프로파일에는 그 정보가 없을 수 있고, 그러면 macOS 27의 차단과 겉보기가 똑같으면서 원인은 다른 접근 실패가 생깁니다. “Automatically manage signing”이 켜져 있고 REGISTER_APP_GROUPS 빌드 설정이 Yes이면 Xcode가 프로파일을 갱신해 줍니다.²

어떤 식별자 방식을 쓰고 있는지도 파악해 두십시오. group. 접두사가 붙은 그룹은 앱의 프로비저닝 프로파일에 포함되어야 합니다. <TeamID>.<group name> 형태를 쓰는 그룹은 시스템이 서명 신원과 팀 식별자 접두사를 대조하므로 프로파일이 필요 없지만, 이 형태는 macOS 전용이며 Keychain Access Groups에서는 지원되지 않습니다.²

그다음 개인정보 보호 및 보안 설정을 확인하십시오. 릴리스 노트가 사용자 제어권이 이제 그곳에 있다고 밝힌 자리입니다.¹

물어볼 수 없는 차단을 전제로 설계하기

확인 창은 보안 일만 한 게 아니라 제품 일도 하고 있었습니다. 사용자에게는 결정할 사안이 있다는 것을 알려 주었고, 앱에는 결정이 내려졌다는 것을 알려 주었습니다. 이제 두 가지 일 모두 개발자 몫입니다.

경계에서 한 번만 확인하십시오. 동기화 루프 중간에서 차단을 발견하는 대신, 컨테이너를 처음 확보하는 시점에 가벼운 읽기를 한 번 시도하십시오. 큐 깊은 곳에서 터진 실패는 부분적인 결과와, 하필 다음 차례였던 파일 탓으로 돌려진 오류를 남깁니다. 확보 시점의 시도 한 번이면 분기할 지점이 한 곳으로 모이고, 권한 사전 검사와 달리 실제 읽기가 지나갈 바로 그 경로를 그대로 지나가 봅니다.

사용자의 언어로 무슨 일이 일어났는지 말하십시오. “데이터를 읽을 수 없습니다”는 데이터 손실 문의를 불러옵니다. 정확한 메시지는 경계와 해결책을 함께 짚습니다. 그 데이터는 다른 개발자의 앱에 속해 있고, macOS는 그런 접근을 기본적으로 차단하며, 스위치는 개인정보 보호 및 보안 설정에 있다는 것을 알려 주십시오. 사용자는 어디 있는지 모르는 실패에는 손을 쓸 수 없습니다.

재시도하지 마십시오. 차단은 일시적인 오류가 아니라 정책 상태입니다. 막힌 컨테이너를 상대로 도는 백오프 루프는 배터리를 태우고 로그를 채울 뿐 아무것도 바꾸지 못합니다. 한 번 실패하고, 그 상태를 드러내고, 사용자가 설정을 바꾼 뒤 직접 누를 수 있는 재확인 버튼을 제공하십시오.

주기적으로 찔러 보는 대신 활성화 시점에 다시 확인하십시오. 사용자가 설정을 바꾸러 나갔다가 돌아온 순간이 접근을 다시 시험할 때입니다. 타이머로 막힌 경로를 계속 두드려 봐야, 정해 둔 주기마다 똑같은 차단이 돌아올 뿐입니다.

애초에 다른 팀의 컨테이너를 읽는 일이 정말 필요한지 물으십시오. 불편한 질문이지만, 대개는 이쪽이 옳은 답입니다. 경쟁 제품의 컨테이너를 읽는 마이그레이션 도구는 플랫폼이 세 릴리스에 걸쳐 좁혀 온 일을 하고 있습니다. macOS 15에서 샌드박스로 감쌌고, 확인 창을 붙였고, 이제 차단합니다. 상대 앱이 직접 제공하는 내보내기 경로, 사용자가 직접 조작하는 파일 선택기를 통한 문서 기반 가져오기, 문서화된 교환 형식은 모두 이번 변경에서 살아남습니다. Team ID 경계를 넘는 컨테이너 읽기에는 뚜렷한 궤적이 있고, 그 궤적은 한 방향을 가리킵니다.

파일 선택기는 따로 짚어 둘 만합니다. 플랫폼이 의도한 탈출구이기 때문입니다. 사용자가 파일을 고르는 행위는 보안 범위가 지정된(security-scoped) 메커니즘을 통해 접근 권한을 명시적으로 부여하는데, 이는 방금 사라진 확인 창보다 훨씬 단단한 권한 근거이며, 설정을 하나도 바꾸지 않고 오늘 당장 동작합니다.

핵심 정리

macOS 앱 개발자라면: - macOS에서 containerURL(forSecurityApplicationGroupIdentifier:)가 nil이 아닌 값을 돌려줬다고 해서 접근이 가능하다는 증거로 삼지 마십시오. 이 메서드는 언제나 URL을 반환합니다. 읽기를 시도하고 오류를 처리하십시오. - 사전 검사로 isReadableFile(atPath:)를 쓰지 마십시오. Apple은 파일 시스템의 결과를 미리 단정하는 방식을 권하지 않으며, 이 메서드는 POSIX 권한을 평가하는데, 정책 계층의 차단은 그 권한을 건드리지 않을 수 있습니다. - 다른 Team ID에 속한 컨테이너를 읽는 코드 경로를 모두 점검하십시오. macOS 27에서는 아무에게도 묻지 않고 실패합니다. - ~/Library/Group Containers/...를 하드코딩해 두었다면 방어할 메서드 호출 자체가 없습니다. 검사를 넣을 자리를 만들려면 API로 옮기십시오.

마이그레이션이나 백업 도구를 출시하는 팀이라면: - 다른 팀의 컨테이너를 읽는 일은 더 이상 확인 창 하나만 넘으면 되는 일이 아닙니다. 차단을 기본 상태로 두고 설계하고, 설정이 어디 있는지 사용자에게 알려 주십시오. - 실패는 오류가 아니라 데이터 없음의 모습으로 나타납니다. 명시적인 안내 문구를 넣으십시오. 그러지 않으면 사용자는 이를 데이터 손실로 신고할 것입니다.

Team ID를 바꾸려는 모든 이에게: - 인수나 계정 분리는 이전에 Team ID 접두사를 공유하던 앱들 사이의 앱 그룹 공유를 조용히 끊어 놓습니다. 소스 코드에는 그 신호가 전혀 나타나지 않습니다.

자주 묻는 질문

하나의 개발자 계정 안에서 컨테이너를 공유하는 앱에도 영향이 있나요?

없습니다. 경계선은 Team ID입니다. Apple의 규칙은 이미 서로 다른 팀이 같은 앱 그룹을 쓰지 못하게 막고 있으며, 한 팀은 자기 앱, 익스텐션, App Clips, XPC Services 전반에서 하나의 그룹을 공유할 수 있습니다.²

사용자가 승인할 수 있는 확인 창이 뜨나요?

macOS 27에서는 뜨지 않습니다. 릴리스 노트는 이러한 접근이 더 이상 승인을 요청하지 않고 기본적으로 차단되며, 관리 지점이 개인정보 보호 및 보안 설정으로 옮겨졌다고 명시합니다.¹

예전 SDK로 빌드하면 피할 수 있나요?

아마 안 될 것입니다. 릴리스 노트는 다른 11개 변경에는 SDK 기준을 명시하는 표현을 쓰면서 이 항목에는 쓰지 않았는데, 이는 모든 바이너리에 적용되는 OS 차원의 정책임을 시사합니다.¹ Apple이 대놓고 밝힌 적은 없으므로 근거 있는 추론으로 받아들이시고, 접근이 실패한다는 전제로 준비하십시오.

프로비저닝 문제와 어떻게 구분하나요?

sudo launchctl procinfo <pid>를 실행해 시스템이 해당 프로세스에 권한 검증 완료 플래그를 설정했는지 확인하십시오. 오래된 프로비저닝 프로파일은 앱 그룹 승인 개념보다 앞선 것일 수 있고, 원인은 다르면서 겉보기는 비슷한 실패를 만들어 냅니다.²

문서는 왜 아직도 확인 창을 설명하고 있나요?

Apple의 앱 그룹 컨테이너 가이드는 macOS 15 동작을 설명하고 있으며, 이 글을 쓰는 시점까지 macOS 27 변경 사항이 반영되지 않았습니다.² 이 글의 날짜에 기대지 말고 해당 페이지의 현재 상태를 직접 확인하십시오.

출처