AI 에이전트가 macOS의 전체 디스크 접근(Full Disk Access) 재고를 강제하는 이유

AI 에이전트는 이제 대부분의 앱보다 우리의 사적 데이터에 더 가까이 자리 잡았습니다. Inc. 칼럼니스트 Jason Aten은 Meta의 Muse 앱이 자신의 사적인 메시지 내용을 알고 있다는 기사를 보도하며 우려가 커졌습니다. 하지만 Meta는 9월 30일 이 주장을 부인했습니다.

한편, Wired 역시 ChatGPT의 Mac 앱에 해커들이 민감한 데이터에 접근할 수 있게 했을 수 있는 결함이 있었다고 보도했습니다. 이러한 배경 속에서 Apple은 10월 2일 macOS 전체 디스크 접근(Full Disk Access)에 대한 새로운 제어 기능을 발표했습니다. 또한 개발자 블로그 게시물을 통해 우려 사항을 설명했습니다. 본 기사에서는 애플이 무엇을 말했는지, 왜 이 권한이 그렇게 강력하며, 개발자들이 무엇을 변경해야 하고 리더들이 무엇을 우선순위로 두어야 하는지 설명합니다.

Apple은 증가하는 AI 에이전트 위험에 어떻게 대응하고 있나요?

Apple이 설명하기를 전체 디스크 접근(Full Disk Access)은 백업이 제대로 작동하도록 구축되었습니다. 하지만 AI 에이전트는 그 접근의 위험을 높였습니다. 따라서 이 권한을 진정으로 부여하려는 사용자도 가능하지만, 매우 명시적인 행동을 통해서만 가능합니다.

AI 에이전트 개발자는 다음에 무엇을 해야 하나요?

애플의 방향이 명시적 동의를 가리키기 때문에, AI 에이전트 개발자들은 오늘부터 준비할 수 있습니다. 다음 단계들은 그 원칙에 기반합니다.

제한된 접근 요청하기

먼저, 여러분의 AI 에이전트가 전체 디스크 접근(Full Disk Access)이 필요한지 여부를 질문하는 것부터 시작하세요. 많은 경우, 단지 몇 개의 폴더만 필요하며, 범위 지정 권한(scoped permissions)이나 사용자 선택 폴더가 실제 작업을 충분히 처리할 수 있습니다. 따라서 광범위한 접근은 기본값으로 배포할 것이 아니라 정당화할 수 있는 예외여야 합니다.

범위를 좁힌 후에는 타이밍에도 최소 권한 원칙(least privilege)을 적용하세요. 이는 사용자가 한 가지 작업에 대한 접근만 허용하는 경우 그 대가를 이해한다는 것을 의미하기 때문에 중요합니다. 반면, 온보딩 과정을 단순히 클릭하고 지나가는 사용자들은 그렇지 않은 경우가 많습니다. 자율 에이전트의 보안 가이드라인은 OWASP의 '과도한 주체성(Excessive Agency)' 위험에 맞춰 이 접근 방식을 지지하며, 최소 권한 원칙과 민감한 작업에 대한 인간 검토를 권장합니다.

모든 접근을 설명하고 보여주기(Explain and Show Every Access)

다음으로 사용자에게 에이전트가 무엇을 읽고 왜 읽는지 간단한 언어로 알려주세요. 권한 요청 시점에 해당 메시지를 표시해야 하며, 숨겨진 정책 페이지에 넣어서는 안 됩니다. 그렇지 않으면 모호한 프롬프트는 현재 Muse AI Agent를 둘러싸고 벌어지는 논쟁과 같은 분쟁을 야기합니다.

설명만으로는 충분하지 않으므로, 나중에 접근 기록도 눈에 보이게 만드세요. 로그나 활동 보기(activity view) 기능을 통해 사용자가 에이전트가 어떤 파일, 메일 또는 메시지를 건드렸는지 볼 수 있게 합니다. 이는 **'우리 제품을 믿어달라'**는 요청을 사용자가 검증할 수 있는 무언가로 바꿉니다. 또한 누군가가 귀사 제품의 동작에 이의를 제기할 경우 팀에게 증거 자료도 제공합니다.

주입 공격 및 유출 방지 강화(Harden Against Injection and Leaks)

가시성은 사후적으로 도움이 되지만, 애초에 피해를 막는 것도 필수적입니다. 따라서 AI 에이전트가 읽는 모든 것을 신뢰할 수 없는 입력(untrusted input)으로 취급해야 합니다. 파일, 이메일, 웹 페이지 모두 숨겨진 지침을 담고 있을 수 있기 때문입니다. 실제로 OWASP는 프롬프트 주입 공격(prompt injection)을 2025년 LLM 애플리케이션 위험 목록에서 첫 번째로 순위를 매겼습니다.

Mac의 Full Disk Access 사건은 이러한 위험성을 급격히 높입니다. 왜냐하면 주입된 지침이 메시지, 메일 및 브라우징 기록에 도달할 수 있기 때문입니다. 노출을 줄이기 위해 가능한 한 민감한 데이터는 로컬(local)에 보관하세요. 장치 외부로 전송해야 하는 것은 작업에 필요한 것만 보내고, 무엇이 언제 나가는지 명확히 밝혀야 합니다. 마지막으로, 에이전트가 민감한 정보를 공유하기 전에 확인을 요청하세요.

마찰과 감시(Friction and Scrutiny) 대비

강력한 보호 장치가 있음에도 불구하고, 더 엄격한 권한 요청을 예상하고 지금 온보딩 과정을 테스트해 보세요. 만약 이 과정이 마찰(friction)을 추가한다면, 일부 사용자는 이탈할 것입니다. 따라서 AI 에이전트가 적은 접근성으로도 잘 작동하도록 설계하는 것이 먼저입니다. 그런 다음 사용자들에게 더 많이, 의도적이고 인지적으로 옵트인(opt-in)하게 하세요.

마지막으로, 데이터 처리 방식을 공개적으로 문서화하고, 무엇을 읽고 저장하며 전송할지, 그리고 얼마나 오래 보관할지를 설명하세요. 이런 방식으로 분쟁이 발생했을 때, 명확한 페이지를 통해 몇 주가 아닌 몇 시간 안에 대응할 수 있습니다. 참고로 이 단계들은 Apple의 요구사항이라기보다는 모범 사례(best practice)입니다.

진짜 문제는 접근성이 아닙니다. 권한(Authority) 문제입니다

더 깊은 교훈은 하나의 macOS 권한에 관한 것이 아닙니다. 대신, AI 에이전트는 소프트웨어가 접근성을 받는 방식과 소프트웨어가 권한을 행사하는 방식 사이의 더 광범위한 불일치를 노출했습니다. 전통적으로 운영 체제는 애플리케이션이 특정 리소스에 접근할 수 있는지 여부를 묻습니다. 그러나 AI 에이전트는 이제 더 어려운 질문을 던집니다. 그 에이전트가 그 접근성을 가지고 무엇을 결정하여 할 수 있을까?

이러한 자율적인 에이전트는 지침을 해석하고, 행동을 조정하며, 도구를 호출하고, 자체적으로 지침을 포함하는 콘텐츠에 응답할 수 있기 때문에, 이들의 권한 경계는 정의하기가 더욱 어려워집니다. 이러한 이유로 AI 에이전트가 점점 더 자율적이 될수록 동의(consent)가 중요해지고 있습니다. 그러나 사용자가 부여하는 권한을 이해할 때만 동의가 의미 있는 보호를 제공합니다.

하지만 그 이해는 사용자만의 책임일 수 없습니다. AI 에이전트 개발자들은 에이전트의 권한 범위를 더 좁고, 투명하며, 목적에 한정되도록 만들어야 하며, 조직들은 배포 전에 이러한 경계를 검증해야 합니다. 동시에 운영 체제 역시 단순한 접근 제어(access control)를 넘어 진화해야 합니다. 그들은 단순히 에이전트가 무엇에 접근할 수 있는지뿐만 아니라, 그 접근성을 가지고 무엇을 할 수 있는지를 구별해야 합니다. 마찬가지로, 이해도를 보안 통제(security control)로 취급하는 조직은 어떤 에이전트가 접근할 자격이 있고 얼마나 많은 권한을 받아야 하는지에 대해 더 나은 결정을 내릴 수 있습니다.