Apple과 해커의 미래

AI 요약

저자는 Claude와 Codex만 실행하던 상시 가동 Mac mini가 해킹당한 일을 계기로, AI 에이전트 시대에 Mac이 어떤 컴퓨터여야 하는지 묻습니다. 네덜란드 국가사이버보안센터(NCSC)는 인터넷에서 5900번 포트에 접근할 수 있던 여러 시스템이 공격받았다고 경고했습니다. 공격자는 macOS 화면 공유(Screen Sharing)의 CVE-2026-65400 취약점을 악용해 루트(root) 권한을 얻고 Monero 채굴기를 설치했습니다. 취약점 심각도는 10점 만점에 7.1점이며, Apple은 macOS Tahoe, Sequoia, Sonoma용 패치를 배포했습니다.

에이전트가 침입을 알아챘습니다

저자의 에이전트는 30분마다 정지하는 모니터링 도구를 주기적으로 다시 실행합니다. 이 과정에서 Claude가 시스템 이상을 감지해 긴급 알림을 보냈고, 명령 실행을 중단한 뒤 계정에서 비밀번호 없이 관리자 명령을 실행할 수 있다고 경고했습니다. 저자는 Claude를 더는 실행하지 말라는 권고는 따르지 않았습니다. 대신 Claude와 함께 악성코드를 찾고, 침입이 일어난 4초 구간을 확인하고, 재발 감시 도구를 만든 뒤 Mac mini를 초기화했습니다. 에이전트가 컴퓨터에 접근하면 위험하다는 우려가 있지만, 이 사례에서는 상시 실행하던 에이전트가 피해 파악에 도움을 줬다는 설명입니다.

TCC는 에이전트가 아닌 프로그램에 권한을 묻습니다

저자는 macOS의 개인정보 권한 체계인 TCC(Transparency, Consent, and Control)가 헤드리스(headless) Mac에서 에이전트를 운용하기 어렵게 만든다고 말합니다. 에이전트는 자주 새 프로그램을 만들고, 그 프로그램은 SMB 공유 폴더 같은 네트워크 자원에 접근할 때마다 권한을 요청할 수 있습니다. 저자가 원하는 것은 에이전트에 권한을 부여하는 방식이지만, TCC는 에이전트가 만든 각각의 프로그램을 대상으로 권한을 관리합니다.

문제는 권한 요청창이 보호된 화면에 떠서 같은 컴퓨터에서 실행 중인 프로그램이나 에이전트가 볼 수 없다는 점입니다. 작업은 조용히 실패하고, 저자는 화면 공유로 Mac에 접속해 직접 ‘허용’을 눌러야 합니다. 이 권한창을 소프트웨어가 읽고 처리하지 못하게 막는 데에는 악성코드가 보안 확인을 우회하지 못하게 하려는 이유가 있습니다. 하지만 저자는 자신의 사용 방식에서는 이 불편이 화면 공유를 계속 켜두게 만든 원인 중 하나였다고 설명합니다.

보안 업데이트 설정과 사용자의 기대

저자는 화면 공유 포트 5900을 인터넷에 노출한 일을 자신의 실수로 인정하고, 앞으로 VPN을 쓰겠다고 합니다. 다만 TCC 권한창을 처리하려고 화면 공유 기능을 자주 썼으며, ‘보안 업데이트 자동 설치’ 설정을 켜면 CVE 수정도 자동으로 설치되는 줄 알았다고 지적합니다. 실제로 취약점 수정은 대개 보안 업데이트가 아니라 macOS 포인트 릴리스에 포함됐습니다. 저자는 Apple이 해당 설정의 이름을 보안 업데이트와 시스템 업데이트의 관계를 분명히 드러내도록 정했어야 한다고 말합니다. 동시에 이 문제를 자신의 오해에서 비롯한 실수라고도 인정합니다.

Apple은 Full Disk Access(전체 디스크 접근 권한)에 추가 통제를 도입하겠다고 밝혔습니다. 이 권한은 파일, 메일, 메시지, 검색 기록까지 앱이 읽게 할 수 있으며, AI 에이전트가 자율적으로 행동할수록 그 위험이 커진다는 설명입니다. 저자는 일반 사용자가 이 권한의 결과를 잘 모를 수 있다는 점에는 동의하지만, 원하는 사용자가 충분히 이해한 뒤 권한을 줄 수 있어야 한다고 우려합니다. 특히 Mac을 Apple이 관리하는 기기가 아니라 자신의 방식대로 쓰는 범용 컴퓨터로 여기고 있습니다.

앱의 시대에서 에이전트의 시대로

저자는 Mac이 스크립트 실행과 자동화, 접근성 API, Unix 명령행 도구를 갖춰 에이전트 실행에 잘 맞는다고 봅니다. 반면 Apple은 앱 개발자가 API와 통합 기능을 제공해야 에이전트가 서비스와 연결되는 구조를 고수합니다. 웹을 직접 사용하는 에이전트는 별도 통합 없이도 많은 서비스에 접근할 수 있으며, 기존 앱 화면 대신 에이전트가 작업을 대신하는 편이 나을 수 있다고 주장합니다. Meta의 공개형 Muse Gadgets 프로그램에도 관심을 보입니다. 기기 판매보다 에이전트가 다양한 기기를 제어하는 인터페이스가 되는 데 의미가 있다는 해석입니다.

마지막으로 저자는 Paul Graham의 2005년 글 「Return of the Mac」을 떠올립니다. 당시에는 해커들이 먼저 쓰는 기술이 10년 뒤 대중에게 퍼진다는 관점에서 Mac의 Unix 기반을 높이 평가했습니다. 이제는 AI 에이전트가 누구나 직접 도구를 만들고 컴퓨터를 바꾸게 하므로, 사용자가 원하는 일을 가로막는 ‘벽으로 둘러싸인 정원’이 보호보다 감옥처럼 느껴질 수 있다고 말합니다. Apple 제품을 당장 떠나겠다고 선언하지는 않지만, 이미 새 서버는 Linux로 정했고 랙에 Mac을 다시 넣지 않겠다고 합니다. 에이전트가 전통적인 인터페이스의 역할을 줄이는 미래에 Apple의 통제 방식이 사용자의 상상력과 맞을지 질문합니다.

Hacker News 반응

• @hombre_fatal — Apple이 전체 디스크 접근 권한을 더 분명하게 알리려는 일을 에이전트를 싫어하는 태도로 해석하는 이유를 모르겠습니다. 보통 사용자를 잠깐이라도 생각하면 소셜 미디어가 화를 내는 것 같습니다. Apple이 제시한 이유는 합리적으로 보입니다.
  • @askonomm — 감정 문제는 아니라고 봅니다. 프롬프트 인젝션에 취약한 비결정적 도구에서 전체 시스템 접근 권한을 거두는 일은 당연한 선택입니다. 그래서 저는 요즘 모든 프로젝트를 루트리스 격리 컨테이너에서 실행합니다. 소프트웨어를 신뢰한 적은 없지만, 요즘은 불신할 이유가 훨씬 선명해졌습니다.
• @soltanov — 감정이 아니라 플랫폼 통제 문제입니다. Apple은 보안이라는 이름으로 백그라운드 자율성을 제한하면서 자사 시스템 프레임워크에는 제한 없는 상시 접근을 허용합니다. 늘 하던 방식입니다.
  • @simonh — 전체 디스크 접근은 Mac의 소프트웨어에 사용자가 허용하는 권한이지, Apple 전용 권한이 아닙니다. Apple의 발표에도 그 권한 자체를 없애겠다는 내용은 없습니다. 권한을 줄 때 사용자가 결과를 충분히 알게 하겠다는 말입니다.
• @jeremyjh — 에이전트가 화면 공유 소프트웨어에 접근해 TCC 권한창을 보게 하면 안 되나요?
  • @wpm — TCC 권한창에는 가짜 클릭을 어느 정도 감지하는 기능이 있습니다. osascript로 ‘허용’을 누르려 해본 지 오래돼서 지금도 되는지는 모르겠습니다.
• @GeekyBear — 전체 디스크 접근 권한은 백업 소프트웨어에 주는 권한입니다. Meta 소프트웨어에 그 권한을 주면 Meta가 사생활을 존중하지 않을 것입니다.
  • @danaris — 반론을 하나 들자면, 전체 디스크 접근 권한은 백업 외에도 쓰입니다. 이 권한을 백업 앱에만 주는 방향으로 제한한다면 걱정스럽습니다. AI 에이전트 문제가 심각하다는 점에는 동의하지만, 아기와 목욕물을 함께 버리면 안 됩니다.
• @drdexebtjl — 문제는 Apple이 TCC 권한을 프로세스 트리의 최상위에서만 적용한다는 점입니다. 백업 도구가 명령행 프로그램이면 Terminal에 전체 디스크 접근 권한을 줘야 합니다. 그러면 Terminal에서 실행하는 다른 모든 프로그램도 같은 권한을 받습니다. TCC의 보안 모델은 근본적으로 잘못됐습니다. Unix가 수십 년 전에 해결했듯 에이전트는 별도 사용자 계정으로 실행해야 합니다.
  • @noncoml — 에이전트를 별도 사용자로 실행하면 그 사용자는 원래 사용자만 읽을 수 있는 파일에 접근할 수 없습니다. 그게 어떻게 도움이 되나요?
  • @drdexebtjl — 사용자가 파일 접근 권한을 ACL로 에이전트 계정에 명시적으로 부여하면 됩니다. 같은 권한을 여러 에이전트에 줘야 한다면 그룹을 만들고 그 그룹에 권한을 주면 됩니다.
• @Vvector — 취약점을 악용하려면 “5900번 포트가 인터넷에서 접근 가능”해야 했습니다. 왜 누가 임의의 포트나 모든 포트를 인터넷에 열어두나요?
  • @DuncanCoffee — 화면 공유를 켜면 Mac 쪽 방화벽은 포트를 엽니다. 라우터나 별도 방화벽은 대개 설정을 바꾸지 않는 한 차단합니다. 글을 읽어보면 작성자가 직접 라우터에서 포트를 열어둔 것 같습니다.
• @fg137 — 작성자가 자기 책임을 인정하면서 Apple을 탓하는 3,000단어짜리 글을 쓰는 이유를 모르겠습니다. 기본적인 보안 수칙만 지켰어도 생기지 않았을 일입니다.
  • @user43928 — 동의하지 않습니다. Apple의 원격 접근 기능에 치명적인 인증 취약점이 있었고, Apple은 이미 수정본을 배포했는데도 작성자의 설정에서는 자동 설치되지 않았습니다. VPN으로 한 겹 더 막았으면 예방할 수 있었다고 해서 Apple의 실수가 사라지지는 않습니다.
• @runjake — 작성자는 TCC가 자신의 Mac 해킹에 간접 책임이 있다고 왜 말하나요?
  • @krackers — TCC는 여기저기 불편한 권한창을 띄웁니다. 작성자는 그 창을 직접 닫으려고 원격 데스크톱을 열었고, 그 원격 접근 기능에 사전 인증 취약점이 있었습니다. TCC 권한창을 다른 방식으로 처리할 수 있었다면 그런 선택을 하지 않았을 수 있다는 말입니다.
• @parasubvert — AI 에이전트를 많이 쓰는 사람은 생산성에 비해 계정 도용, 사생활 침해, 데이터 손실 위험을 지나치게 감수하는 것 같습니다. 보안, 설계 제약, 자동 테스트, 결정론적 작업과 비결정론적 작업의 분리에 규율이 없으면 한동안 생산적일 수 있지만, 어느 날 갑자기 큰 피해를 볼 수 있습니다. 에이전트에는 규율 있는 샌드박스 모델이 필요합니다.

원문: Stratechery / 번역·요약: Trawling