Gemini가 Mac의 키를 원한다? 우리는 이 영화를 전에 본 적이 있다

Google이 macOS용 Gemini Desktop 모드를 테스트하고 있다는 보도에 따르면, 이 모드는 확인 대화 상자(confirmation dialog)를 완전히 건너뛰는 기능을 제공합니다. 사용자는 모든 파일을 읽고, 쓰고, 수정하고, 삭제할 수 있습니다. Mail과 Messages에서도 자유롭게 탐색할 수 있으며, 어떤 행동마다 승인을 받을 필요가 없습니다. 이것은 더 이상 AI 비서가 아니라, 판단이나 책임감이 없는 사용자 계정 그 자체입니다.

이 현상이 위치하는 곳

이것은 새로운 영역이 아닙니다. 30년 동안 우리가 걸어온 지반 위에서 새로운 세입자가 들어오는 것과 같습니다. 소프트웨어가 "더 도움이 되기 위해" 더 광범위한 시스템 접근 권한을 요구할 때마다, 그 주장은 생산성이고 대가는 공격 표면(attack surface)입니다. 우리는 브라우저 플러그인, 모바일 앱 권한, 시간이 지남에 따라 조용히 확장된 OAuth 스코프를 통해 이 과정을 겪어왔습니다. 에이전트형 AI(agentic AI) 물결은 단지 가장 최신 수단일 뿐입니다. 이 특정 사례가 주목할 만한 이유는 그 범위 때문입니다: 전체 파일 시스템 접근 권한에 앱 상호작용, 그리고 확인 단계 생략까지 결합된 하나의 기능으로 묶여 있다는 점입니다. 이는 역사적으로 제3자 소프트웨어에게 개인 장치에서 부여되었던 대부분의 권한 모델보다 훨씬 넓은 파급 범위(blast radius)이며, 실제로는 신뢰도 상승(trust escalation)임에도 불구하고 편의성 업그레이드로 포장되고 있습니다.

과대광고 검토 (Hype check)

숨 막히는 헤드라인들은 이것을 "AI가 당신의 개인 파일을 읽을 수 있다"는 식으로 프레임을 씌우는데, 마치 그것이 무서운 부분인 것처럼 말입니다. 사실 그렇지 않습니다. 더 무섭고, 더 구조적인 문제는 다음과 같습니다: 에이전트가 행동할 때 개별 행동에 대한 확인 절차 없이 작동하게 되면, 실수를 잡아주는 유일한 안전장치(circuit breaker)를 제거하는 것입니다. 프롬프트 인젝션(Prompt injection), 잘못 구성된 지침, 오해석된 요청 등 이 중 어느 것이든 인간의 개입이 전혀 없는 상태에서 파일 삭제나 외부 메시지 전송을 촉발할 수 있습니다. 이것은 기밀성 문제일 뿐만 아니라 가용성 및 무결성(availability and integrity) 문제이기도 합니다.

과소평가되고 있는 것은 감사 추적(audit trail) 문제입니다. 사람이 파일을 삭제하면 '왜 그렇게 했는지' 물어볼 사람이 있습니다. 하지만 에이전트가 전체 접근 권한(full-access grant) 하에 작업을 수행할 경우, 로그를 통해 의도를 재구성해야 하며, 그 로그가 모델이 어떤 추론 경로(reasoning path)를 따랐는지 알려줄 만큼 충분히 세밀한지조차 가정해야 합니다. 사고 조사에서 이게 얼마나 쉬울까요?

과대평가되고 있는 것은 새로움입니다. '광범위한 권한을 가진 AI 에이전트'라는 문구는 헤드라인에서는 불안하게 들리지만, 기능적으로는 사용자가 읽지 않고 '허용(allow)'을 클릭했던 시스템 레벨 헬퍼 데몬(system-level helper daemon)을 가진 어떤 자동 업데이트 앱과 크게 다르지 않습니다. 차이점은 규모와 의도입니다. 우리는 이런 종류의 접근 권한을 행동이 완전히 결정론적(deterministic)이지 않은 범용 모델에 넘겨주는 것에 대해 이야기하고 있으며, 이는 한 가지 작업을 수행하는 좁은 목적의 데몬과는 의미 있게 다른 위험 프로필입니다.

'그냥 유용한 AI'라는 틀에서 이익을 얻는 사람은 누구일까요? 명백히 에이전트 기능을 출시하기 위해 경쟁하는 공급업체들입니다. 편리함이 판매를 촉진합니다. 확인 대화 상자(Confirmation dialogs)는 마찰(friction)이며, 마찰은 채택 지표(adoption metrics)의 적입니다. '우리가 AI가 더 자주 권한을 요청하도록 만들었다'는 구조로 아무도 보상을 받지 못합니다.

시사점 (Implications)

개발자 및 보안 팀에게 있어 이것은 AI 기능으로 위장된 접근 권한 모델 문제입니다. 만약 에이전트 데스크톱 도구(agentic desktop tools)와 상호 작용하는 무언가를 구축하고 있다면, 그것을 높은 권한으로 실행되는 모든 프로세스를 생각하듯이 생각해야 합니다. 만약 오작동하면 폭발 반경(blast radius)은 무엇인지, 무엇이 기록되고(logged), 무엇이 되돌릴 수 있는지(reversible)를 말입니다. '전체 접근' 모드는 온보딩 과정 없이 첫날부터 신입 직원에게 root 권한을 부여하는 것과 동일한 수준의 심사를 거쳐야 합니다.

최종 사용자에게 실질적인 조언은 화려하지 않지만 사실입니다. 최소 권한 원칙(least privilege)은 AI 에이전트에도 적용되며, 어쩌면 인간에게 적용되는 것보다 더 엄격하게 적용되어야 합니다. 왜냐하면 에이전트는 당신이 이 문장을 읽는 시간 동안 수천 가지의 행동을 실행할 수 있기 때문입니다. 만약 어떤 기능에 '매번 물어보기(ask me every time)' 토글과 '그냥 실행하기(just do it)' 토글이 함께 제공된다면, 두 번째 옵션에서 사고가 발생한다고 가정해야 합니다.

업계 차원에서는 이것이 다음 권한 피로 주기(permission-fatigue cycle)가 될 것이라고 예상합니다. 사용자는 부분적인 접근에 짜증을 느끼기 때문에 전체 접근 권한 부여를 요청받게 되고, 지원 티켓에는 예기치 않은 파일 변경에 대한 내용이 올라올 것이며, 결국 공개적인 사고가 발생하여 제품에 범위 지정된 권한 모델(scoped-permission model)을 다시 강제하게 될 것입니다. 이것은 기본적으로 2010년 이후 모든 플랫폼 권한 시스템의 플롯과 같습니다.

열린 질문 (Open question)

전체 파일시스템 접근 권한을 가진 자율 에이전트가 파괴적이거나 의도치 않은 행동을 할 경우, 실제로 책임은 누구에게 있는가? 토글을 바꾼 사용자인가, 모드를 배포한 벤더(vendor)인가, 아니면 '모델이 결정을 내렸기 때문에' 아무도 없는가?

— Cor, Skyblue Soft

출처 (Sources)

• Google Gemini가 곧 Mac의 파일, 앱 및 웹에 대한 전체 접근 권한을 얻을 수 있다

AI 지원 초안 또는 이미징, 인간이 큐레이션하고 검토 및 편집함.