터미널에 켠 전체 디스크 접근을 코딩 에이전트가 쓴다, Apple이 조이겠다는 이유

AI 요약

• Apple이 AI 에이전트를 이유로 맥 전체 디스크 접근 권한을 조이겠다고 예고했습니다.
• 이 권한은 실행 파일이 아니라 터미널에 붙어서, 거기서 돌린 코딩 에이전트가 그대로 씁니다.
• 시행 시점과 대상 macOS 버전은 공개되지 않았습니다.

Apple이 2026년 10월 2일 Apple Developer News에 「Updates to Full Disk Access in macOS」라는 짧은 공지를 올렸습니다. 맥의 전체 디스크 접근(Full Disk Access) 권한을 켜는 과정에 추가 통제를 넣겠다는 예고이고, 그 이유로 AI 에이전트를 직접 지목했습니다.

전체 디스크 접근은 켜 준 앱이 그 맥의 파일을 전부 읽게 해주는 설정입니다. Apple 사용 설명서가 적은 범위는 다른 앱의 데이터(메일, 메시지, Safari, 홈), Time Machine 백업 데이터, 그리고 이 맥의 모든 사용자에 대한 일부 관리 설정입니다. macOS 내부에서는 kTCCServiceSystemPolicyAllFiles라는 단일 권한으로 다룹니다. 원래는 백업 앱을 위한 통로였습니다.

공지 본문에서 Apple이 쓴 문장은 이렇습니다. 2026년 10월 2일 자 Apple Developer News 공지 전문의 일부입니다.

일부 개발자가 사용자를 위험에 빠뜨릴 수 있는 방식으로 전체 디스크 접근을 쓰고 있습니다. 사용자가 충분히 알지 못한 채 파일, 메일, 메시지, 심지어 브라우징 기록까지 시스템의 모든 것이 노출됩니다. (중략) AI 에이전트가 점점 더 유능해지고 자율적으로 움직이면서, 이 수준의 접근이 가진 위험은 크게 늘어날 것입니다.

Apple이 특정 소프트웨어 범주를 이름으로 지목하면서 권한 설계를 바꾸겠다고 공개한 것은 흔한 일이 아닙니다. 다만 공지 전문 177단어 안에 언제부터, 어떤 macOS 버전에서, 어떤 방식으로 조일지는 한 줄도 없습니다.

권한은 앱이 아니라 "책임 코드"에 붙습니다

이 공지가 독자에게 닿는 지점은 Apple이 지목한 "AI 에이전트"가 남의 앱이 아니라 지금 터미널에서 돌리는 코딩 에이전트라는 데 있습니다. claude, codex, gemini처럼 터미널에서 실행하는 도구가 전부 여기 해당합니다.

macOS의 권한 시스템 TCC는 권한을 실행 중인 바이너리에 붙이지 않습니다. 그 실행에 대한 책임 코드(responsible code)를 따로 판정해서 거기에 붙입니다. Apple 개발자 지원(DTS)이 개발자 포럼 답변에서 직접 설명한 규칙입니다.

TCC에는 책임 코드를 찾아내는 개념이 있습니다. 정확한 알고리즘은 문서화되어 있지 않고, 과거에 바뀐 적이 있으며, 앞으로도 바뀔 수 있습니다.

같은 답변에서 DTS가 정리한 세 경우가 실무에서 그대로 작동합니다.

결과를 한 문장으로 옮기면 이렇습니다. 터미널에 전체 디스크 접근을 켜둔 사람은 그 터미널에서 실행한 모든 코딩 에이전트에 같은 권한을 준 것과 같습니다. 에이전트에 따로 권한을 허용한 적이 없어도 그렇습니다. 시스템 설정의 전체 디스크 접근 목록에 그 에이전트 이름은 나타나지 않습니다. 목록에 있는 것은 터미널입니다.

백업 도구나 동기화 도구를 쓰려고 몇 년 전에 터미널에 이 권한을 켜 둔 사람이 많습니다. 그때는 터미널에서 돌리는 것이 rsync와 셸 스크립트였습니다. 지금 같은 창에서 도는 것은 파일을 읽고 명령을 실행하고 네트워크로 나가는 에이전트입니다. 켜 둔 권한은 그대로인데 그 권한을 쓰는 쪽이 바뀌었습니다.

권한이 안 넘어가서 깨지는 반대편

같은 규칙은 반대 방향으로도 작동합니다. 권한이 넘어가야 할 때 안 넘어가서 기능이 깨지는 사례가 공개 저장소에 남아 있습니다.

anthropics/claude-code 이슈 #24162가 보고한 증상입니다. Claude.app에 전체 디스크 접근을 켜 줘도, 그 앱이 띄우는 내장 CLI는 보호 경로를 못 읽습니다. 이유는 서명 신원이 다르다는 것입니다. 데스크톱 앱은 com.anthropic.claudefordesktop이고 내장 CLI는 com.anthropic.claude-code이며, 실행 파일이 .app 번들 바깥의 ~/Library/Application Support/Claude/ 아래에 있습니다. TCC는 둘을 무관한 프로그램으로 취급합니다.

보고된 동작은 권한 요청 창조차 뜨지 않고 TCC가 auth_value=5(거부)로 자동 거부하는 것이었습니다. 보호된 파일에 닿으면 sqlite3.OperationalError: unable to open database file이 납니다. 이슈는 2026년 2월 8일에 올라왔고 중복으로 닫혔습니다. 같은 증상을 node 바이너리에서 겪은 이슈 #21737도 걸려 있습니다.

두 사례를 같이 놓으면 지금 권한 모델의 모양이 보입니다. 터미널로 돌리면 의도보다 넓게 열리고, 앱 안에서 돌리면 의도보다 좁게 닫힙니다. 둘 다 사용자가 고른 결과가 아니라 서명 신원과 실행 경로가 만든 결과입니다. Apple이 "매우 명시적인 사용자 행동"을 요구하겠다고 적은 자리가 여기입니다.

에이전트가 로컬에서 어디까지 손을 뻗는지는 Apple만의 문제가 아닙니다. Claude Code 모드가 프로세스 안에서 실행되는데 샌드박스가 없다는 점을 다룬 적이 있고, GET 요청만 허용한 에이전트가 코드를 실행한 사례도 정리했습니다. OS 권한은 그 모든 것의 마지막 울타리입니다.

Apple이 밝힌 것과 밝히지 않은 것

지금 시점에 바뀐 것은 없습니다. 공지는 예고이고, 시행 시점과 대상 버전이 공개되지 않았습니다.

항목	내용
대상	맥 사용자 전원, 맥용 앱 개발자 전원. 요금제·제품 등급 구분 없음
비용	없음. macOS 시스템 권한 설정 변경이라 과금 대상이 아님
한국 사용 가능	지역 구분 없음. 한국을 포함한 전 지역에 같은 권한 모델이 적용됩니다
필요 조건	없음. 신청·대기자 명단·승인 절차 없음
시행 시점	미공개. Apple이 날짜도 macOS 버전도 적지 않았습니다
통제 방식	미공개. "매우 명시적인 사용자 행동"이라고만 적혀 있습니다

공지가 나온 자리의 맥락은 두 건입니다.

Meta 쪽 반박은 구체적입니다. 커뮤니케이션 담당 부사장 Andy Stone은 Messages 연동이 전적으로 선택 사항이고, 전체 디스크 접근과 Messages 커넥터를 둘 다 켜야만 읽을 수 있다고 밝혔습니다. Meta Superintelligence Labs 임원은 앱 수준과 macOS 시스템 수준에 걸친 권한 단계 3개를 거쳐야 하며 버그로도 우회되지 않는다고 설명했습니다. 양측 주장은 정면으로 어긋난 채이고, 기술적 설명은 공개적으로 정리되지 않았습니다. 그래서 이 공방 자체보다, Apple이 이 시점에 권한 설계를 손보겠다고 나섰다는 사실이 더 확정적인 정보입니다.

맥을 쓴다면 오늘 시스템 설정의 개인정보 보호 및 보안에서 전체 디스크 접근 목록을 열어 터미널, iTerm, 에디터가 켜져 있는지 한 번 보면 됩니다. 켜져 있다면 그 창에서 실행하는 코딩 에이전트가 메일과 메시지와 Safari 기록까지 읽을 수 있는 상태입니다. 백업이나 동기화 때문에 켜 둔 것이면 그 백업 앱에만 남기고 터미널에서는 끄는 쪽이 지금 상태와 의도를 맞추는 방법입니다. Apple이 통제를 조일 때 가장 번거로워질 쪽은, 켜 둔 이유를 기억하지 못한 채 목록에 오래 남아 있던 항목들입니다.