macOS 전체 디스크 접근 권한 변경 사항

개발자에게 강력한 API를 준다면서 전체 디스크 접근이 보호 장치를 대부분 우회한다면, 실제로는 충분한 수단을 제공하지 않는 셈임. 사용자에게도 세밀한 제어권을 주지 않으니 이런 투박한 권한에 의존하게 됨.
메일·메시지·방문 기록이 걱정된다면, 이를 제외한 전체 디스크 접근 권한은 왜 없는지 궁금함. 바이브 코딩으로 만든 디스크 시각화 앱에는 파일 크기만 읽는 권한을 주면 데이터나 사생활을 훼손하지 않고도 제 역할을 할 수 있음. 명시적인 사용자 동작을 한 번 더 요구하는 것도 대체로 번거로운 장애물에 불과함.

무엇보다 애플리케이션 수준의 권한 분리 API가 필요함. 공급망 공격을 막으려고 코드 편집기를 격리하는 데 왜 Mac 위의 Linux 가상 머신까지 써야 하는지 의문임.
데스크톱의 민감한 정보는 기본적으로 사용자 계정에서 접근 가능하므로, 단순한 root/사용자 분리만으로는 이미 보안이 충분하지 않음. 데이터 유출이 목적이라면 root 권한으로 얻는 추가 이점도 크지 않음.

더 세밀한 제어 기능을 추가하는 건 좋다고 봄. 글을 읽고 전체 디스크 접근 권한 목록을 확인했는데, Ghostty는 터미널이고 Alfred는 전체 검색에 쓰므로 허용해 둠.
Spotify와 Gemini는 꺼 둠. Spotify에 왜 이 권한이 필요한지 모르겠고, Gemini가 내 컴퓨터의 모든 것을 알 필요도 없음.

터미널에 전체 디스크 접근을 허용하면 임의의 스크립트에도 같은 권한이 생기므로 상당한 위험임. macOS가 파일 시스템 접근 API를 개선했으면 함. ACL과 권한 체계로 할 수 있는 일은 많지만 설정 UI에는 반영되지 않음.
문서·다운로드·데스크톱·외장 디스크 단위의 허용도 너무 광범위함. 특히 외장 디스크는 앱별로 허용할 경로를 직접 선택할 수 있어야 함.

Spotify에는 컴퓨터가 켜져 있고 인터넷에 연결되어 있으면 로컬 미디어를 어디서나 라이브러리로 이용하는 기능이 있었음. 지금은 쓰지 않아 여전히 있는지는 모르지만, 해당 샌드박스·권한 모델에서는 디스크 접근이 필요할 것 같음.
정확히는 폴더를 선택하면 그 안의 모든 미디어를 복제하는 기존 설계에서 그런 권한이 필요하다는 뜻이며, 다른 설계도 가능함.

터미널 자체에는 파일 접근 권한이 필요하지 않음. /bin/zsh 같은 셸을 실행하면 되고, 파일 접근이 필요한 건 셸이지 그 셸을 담는 터미널이 아님.
더 나아가 OpenBSD는 /bin/ksh도 부분적으로 샌드박스 처리함. 파일 시스템 대부분은 볼 수 있지만, pledge("stdio rpath wpath cpath fattr flock getpw proc exec tty id", NULL)로 가능한 동작을 제한함.

터미널에 전체 디스크 접근을 허용하지 않겠음. 상당한 공격 경로가 될 수 있음.

이것이 AI 에이전트에 나쁘다는 불평은 잘 이해되지 않음. Local Code(https://releases.drawthings.ai/p/public-beta-of-local-code-b...)는 전체 디스크 접근 없이도 동작함.
접근 권한이 없는 파일을 처리해 달라고 하면 내장 permit 도구가 운영체제의 폴더 권한 승인 창을 띄움. 승인 내역은 Apple과 앱 양쪽에 기록되므로 나중에 철회할 수 있고, 전체 디스크를 내주지 않아도 유용하게 쓸 수 있음.

에이전트를 쓰는 시대라면 TCC 대화상자에 한 번만 허용을 추가하면 됨. iOS 위치 서비스나 여러 에이전트 실행 도구처럼, Claude Desktop의 데스크톱 파일·폴더 접근에 대해 한 번 허용·항상 허용·거부를 선택하게 하면 됨.
진짜 골칫거리는 터미널 에뮬레이터와 명령줄 에이전트 실행 도구임. TCC 권한은 책임 프로세스에서 상속되므로 Terminal.app이나 ghostty.app에 전체 디스크 접근을 주면 zsh, bash, python 등 셸에서 실행하는 모든 것에도 같은 권한을 주게 됨.

앱별로 접근을 허용한 폴더 목록을 확인하고 수정하고 싶음. 한 번 승인한 개별 폴더의 접근 권한을 어떻게 철회하는지 명확하지 않음.

수년째 원하던 기능임. 샌드박스 앱은 파일이나 폴더 접근을 요청하고 보안 범위 북마크(security-scoped bookmark) 로 그 권한을 유지할 수 있음.
하지만 앱이 북마크를 저장하는지는 사용자에게 보이지 않으므로, 자신이 일회성 접근과 지속적인 접근 중 무엇을 승인하는지 알 수 없음.

업데이트 한 번이면 가능하다는 논리는 어떤 운영체제에도 적용할 수 있음. Windows는 로그인할 때 사용자를 모욕하도록, macOS는 Apple을 위해 암호화폐를 채굴하도록, Android는 모든 연락처에 스팸을 보내도록 바뀔 수 있음.

차라리 그렇게 해주길 바람. 너무 많은 앱에 과도한 접근 권한이 있음. 웹사이트에 방문해 거기서 발견한 명령을 실행하는, 말 그대로 트로이 목마를 설치했다는 사실을 왜 깨닫지 못하는지 의문임. 바로 프롬프트 인젝션이 그런 위험임.

요즘 Mac을 쓰는 건 정말 이 광고 속 Windows Vista를 쓰는 것 같음.

내가 나이 든 건지 궁금함. 전체 디스크 접근은 자신이 컴퓨터 주인이라면 당연한 것이었는데 말임.

내 컴퓨터의 소유권은 제3자 개발자가 무엇을 할 수 있는지 엄격하고 세밀하게 통제하는 데 달려 있음. 네이티브 앱 대부분이 분석·마케팅 SDK를 넣거나 바이브 코딩으로 만들어지는 시대에는 나와 개발자의 이해관계가 충돌할 수 있음. macOS에 이런 제어 기능이 없다면 모든 앱을 브라우저 샌드박스에서 실행하겠음.
이번 변경은 기술 기자가 의도치 않게 자신의 문자 메시지를 모두 Meta에 넘긴 사건에 대한 대응임. 비전문 사용자에게 동의와 투명성이 충분히 보장되지 않는다는 뜻이며, 업계 누구도 제대로 된 해법을 찾았다고 보지 않음. 비전문가와 전혀 교류하지 않는 게 아니라면 내 사생활에도 간접적인 영향이 생김. 기술 사용자로서는 더 세밀한 제어와 감사 기능을 바람.

나도 암호화 없는 HTTP로 개인정보를 보내고, 바이러스와 악성코드를 없애려고 Windows 98/XP를 주기적으로 밀어야 했던 시절을 기억할 만큼 나이가 들었음.
앱이 디스크 전체를 뒤져 세금 신고서까지 가져갈 수 있는 건 원래부터 무모한 보안 모델이었음. 한동안은 개발자의 양심에 맡기는 방식이 그럭저럭 통했을 뿐임. 도덕 개념이 없는 AI에 전체 디스크 접근을 주면서 선의에만 의존할 수는 없음.

이제 1980년이 아님. 인터넷은 적대적인 환경이고 모두 데이터를 빼내려 함. 모든 앱에 전체 접근을 허용할 자유는 여전히 있지만 나는 그러지 않겠음. 휴대전화와 Mac에 설치된 수백 개 앱이 허락 없이 사진과 카메라에 접근하지 못한다는 점이 무척 좋음.

어떻게 받아들여야 할지 모르겠음. 1990년대 Linux를 쓰기 시작할 때는 피해가 계정 하나에 한정된다는 보안상의 장점을 내세웠음. root 권한 상승 위험은 제쳐뒀고, 당시 Linux가 생소한 운영체제라 신경 쓰는 사용자도 드물었음. 반면 Macintosh와 비 NT 계열 Windows에는 보안이 사실상 없었음.
요즘 늘어나는 보안 조치는 번거롭고 제약도 많지만 필요하기도 함. 무명의 개발자는커녕 평판 좋은 소프트웨어 업체도 믿을 수 있던 시대는 이미 지났음.

50세인 나로서는 실행하는 모든 앱에 모든 파일 접근을 기본 허용해도 괜찮다고 여겼던 것 자체가 황당함.

이 권한을 이례적인 수준의 접근이라고 부르는 건 재미있는 표현임. 개인용 컴퓨터 역사 대부분의 기간에는 일반 사용자 계정으로 실행한 앱이 그 계정의 모든 파일을 보는 게 지극히 평범했음.
그렇다고 이번 조치가 나쁘다는 뜻은 아님. 충분히 이해한 사용자가 계속 원하는 대로 할 수 있게 해준다면 찬성함.

이번 주에 iMac Pro 한 대와 MacBook 네 대를 모두 포맷했고, 이제 두 AI 에이전트 모두 호스트에서 직접 실행하지 않음. LIMA(https://lima-vm.io)로 격리하고 저장소 하나만 노출함. 일부 연동 기능을 잃지만 마음 놓고 쓸 수 있다는 이점이 더 큼.

명령줄까지 포함하는 진정한 애플리케이션 격리가 필요함. Terminal은 아무 앱이나 명령을 내릴 수 있는 대상이 아니라 특권 접근 수단으로 취급해야 함. App Store 밖에서 설치한 앱도 샌드박스 처리해야 함.

Claude에 macOS 네이티브 앱을 바이브 코딩해 달라고 할 때마다 샌드박스 적용을 요청함. 에이전트도 방법을 알고 있으니 요청하면 되며, 코드를 읽지 않고도 적용 여부를 확인할 수 있음.