Apple과 해커의 미래 (번역)
원문: https://stratechery.com/2026/apple-and-a-hackers-future/
내 컴퓨터가 해킹당했다. 인정하기 민망한 일인데, 원인은 내 잘못이었다. 악용된 취약점은 Ars Technica 기사에 자세히 나와 있다.
네덜란드 당국은 공격자가 악성 코드를 실행할 수 있는 고심각도 macOS 취약점이 실제로 악용되고 있다고 경고했다. “NCSC는 인터넷에서 5900 포트가 접근 가능한 여러 시스템에서 이 취약점의 실제 악용이 관측됐다는 통보를 받았다”고 네덜란드 국가사이버보안센터는 이번 주 초 밝혔다. “모든 사례에서 해당 시스템의 root가 탈취됐고 모네로 암호화폐 채굴기가 심어졌다.”
CVE-2026-65400으로 추적되는 이 취약점은 지난주 macOS Tahoe, Sequoia, Sonoma용 패치를 받았다. 10점 만점에 7.1의 심각도를 기록하는 이 취약점은 macOS 화면 공유 기능의 버그에서 비롯됐다. 화면 공유 기능은 컴퓨터가 켜져 있는 동안 원격 당사자가 화면을 보고 키보드와 마우스를 제어할 수 있게 해준다. 근본 원인은 선행 이벤트, 사용자 상호작용, 변수, 기타 시스템 상태를 추적하는 “상태 관리”의 결함이다.
익스플로잇이 작동하는 모습은 여기서 영상으로 볼 수 있다. CVE-2026-65400의 세부 사항은 지난주 Black Hat 보안 컨퍼런스에서 공개됐다. Apple은 지난주 CVE-2026-65400이 자격 증명 없는 공격자가 맥에 접근하는 것을 “가능할 수 있다”고 말했다. Apple이 왜 그렇게 말을 조심스럽게 썼는지는 불명확하지만, 취약점 공개에서 표현을 완화하는 건 대부분 기술 개발자에게 흔한 일이다. Apple은 취약점을 보고한 보안 회사 Bynario에게 공로를 돌렸다.
해당 컴퓨터는 Claude와 Codex 외에는 아무것도 돌리지 않는 상시 켜짐 Mac Mini였다. 이 이야기를 흥미롭게 만드는 첫 번째 요소가 바로 그 점이었다. 그 사실이 나를 구했으니까.
에이전트에 의한 보호
Writing Things Down과 Sharp Tech의 여러 에피소드에서 언급한 Gecko는 내가 함께 일하는 사람들을 위해 만든 에이전트다. 훌륭하지만, 기능과 접근 범위를 일부러 제한해 뒀다. 내 진짜 에이전트는 전용 Claude Code 스레드다. 내 모든 아이디어를 기록하고, 최근 몇 달 동안 돌린 수많은 프로젝트의 상태를 추적한다.
Claude-speak는 그다지 좋아하지 않지만 이 기능에 Claude를 쓰는 데에는 몇 가지 이유가 있다. Code 하네스 안의 Claude가 Codex보다 폭넓은 논의를 더 잘 처리하는 것 같고, 기록하라는 내 지시를 원하는 방식으로 더 부드럽게 따른다. Code에는 영구 모니터링 도구도 있다. 내가 기록해 둔 모든 것을 시각적으로 추적하는 상태 보드와 텔레그램 봇과의 상호작용을 잡아내는 인박스로 쓰고 있다(OpenAI의 새 Dots가 이 기능의 일부를 해낸다. ChatGPT/Codex에서 그동안 몹시 필요했던 부분이다).
그 모니터링 도구는 30분마다 멈추기 때문에 내 에이전트가 일정에 따라 재시작한다. 바로 그 작업이 Claude의 긴급 알림을 촉발했다.
Claude는 추가 진단 정보를 확보했고, 스스로 모든 명령 실행을 중단했으며, 내 계정이 이제 비밀번호 없이 관리자 명령을 실행할 수 있다는 사실을 알려줬다. 파일이 그렇게 기록된 경로일 거라고 보았다. 이어서 문제를 다루기 위한 다음 단계를 여럿 제안했다. 내가 무시한 것은 더는 Claude를 호출하지 말라는 권고였다. 실제로 나는 Claude를 써서 악성코드를 뿌리 뽑았다. 결국 침입에 성공한 정확히 4초짜리 구간을 찾아냈고, 앞으로를 감시할 도구를 만들었고, Mac Mini를 밀었다.
이 모든 일은 취약점을 자세히 설명하는 Ars Technica 기사를 찾기 전에 일어났다. 꽤 놀라운 일이었다. 이런 에이전트에 컴퓨터 접근을 주는 게 겁나는 사람들이 많다는 걸 안다. 앞서 말했듯 문제의 Mac Mini에는 Codex와 Claude 외에 아무것도 없다. 그래도 이 사례에서는, 에이전트를 상시로 돌리지 않았다면 훨씬 더 큰 곤란에 빠졌을 거라고 말할 수 있다.
애플에 의한 보호
Apple은 에이전트에 대해 그다지 마음에 들어 하지 않는 듯하다. 지난주 회사 개발자 사이트에 Updates to Full Disk Access in macOS라는 제목의 노트가 올라왔다. 전문을 인용한다.
우리는 개발자에게 Apple 제품용 앱에 놀라운 기능을 담을 수 있는 강력한 API를 제공하며, 사용자의 개인 데이터를 보호하도록 설계된 통제 체계가 그 뒤를 받친다. Full Disk Access는 백업 앱이 맥에서 제대로 동작할 수 있도록 하려는 목적으로 이 통제를 대체로 우회한다. 일부 개발자는 사용자를 위험에 빠뜨릴 수 있는 방식으로 Full Disk Access를 사용하고 있다. 파일, 메일, 메시지, 심지어 브라우징 기록까지 시스템의 모든 것을 노출하면서, 사용자가 충분히 알거나 이해하지 못한 상태로 말이다. 커뮤니케이션 앱의 경우 사용자가 소통하는 상대방의 프라이버시도 침해될 수 있다.
앞으로 우리는 추가 통제를 도입해, 정말로 이런 특별한 수준의 접근을 앱에 부여하고 싶은 사용자가 아주 명시적인 사용자 행동으로만 그렇게 할 수 있도록 한다. 이 문제를 다루는 것은 중요하다. AI 에이전트가 점점 유능해지고 자율적으로 변하면서, 이 수준의 접근과 관련된 위험은 상당히 커질 것이다. 사용자가 이런 접근을 부여하기 전에 위험을 명확히 이해하도록 보장하고, 자기 데이터와 프라이버시에 대해 정보에 기반한 결정을 내릴 수 있게 하겠다.
Apple의 해법이 무엇이 될지 걱정된다는 말은 심한 과장이다. 맥이 완벽한 에이전트 호스트인 측면이 하나 있다. Apple은 수십 년 동안 스크립트 가능성, 자동화, 접근성 API(이 셋은 아주 자주 같은 것)의 조합에 투자해 왔고, 덕분에 맥은 컴퓨터 사용에 놀랍도록 적합하다. macOS는 공식 인증된 Unix 시스템이기도 하다. 명령줄에 완벽히 맞는 에이전트에게 이는 Unix 세계에서 만들어진 도구 전체에 접근할 수 있다는 뜻이다. 그리고 물론, 맥 하드웨어는 훌륭하다.
문제는 내 사용 사례에서 macOS가 놀랍도록 적대적이라는 것이다. 내 경우는 다른 컴퓨터와 휴대폰에서 ChatGPT와 Claude 앱으로 주로 접근하는, 헤드리스 상시 켜짐 Mac Mini다. 가장 큰 문제는 GUI 전용 권한 프롬프트다. 그 컴퓨터에서 돌아가는 소프트웨어에는 보이지 않는다. 에이전트도 마찬가지다.
이 권한 프롬프트는 Transparency, Consent, and Control(TCC)이라 불리는 macOS 하위 시스템의 일부다. Apple은 요즘 이 이름을 잘 쓰지 않는 것 같다. 맥에서 TCC가 다루는 항목은 많다. OS 릴리스마다 목록은 길어진다. 접근하려는 앱마다 해당 항목에 대한 접근을 명시적으로 승인해야 한다. 카메라 권한을, 아니 더 짜증스러운 Desktop이나 Downloads 접근 권한을 요구받은 적이 있다면 TCC를 만난 것이다.
이 시스템은 주로 쓰는 맥에서는 짜증스럽지만 다룰 만하다. 에이전트를 돌리는 헤드리스 맥에서는 재앙이다. 이유는 둘이다. 첫째, 에이전트는 끊임없이 새 프로그램을 작성하는데, 내 경우 그 프로그램들이 네트워크에 있는 기기에 접근할 필요가 있다(예컨대 SMB 공유는 TCC 경고를 촉발한다). 내게 필요한 건 에이전트를 위한 권한 계층이지, 에이전트가 만드는 프로그램을 위한 게 아니다. TCC는 잘못된 추상화 수준에서 작동하고 있다.
둘째, TCC 하위 시스템은 프롬프트를 어떤 프로그램도 볼 수 없는 보호된 공간에 노출한다. 프로그램들은 이유도 알리지 않고 조용히 실패하고, 에이전트는 그 이유를 모른다. 내가 할 수 있는 일은 화면에 권한 프롬프트가 떠 있을 거라고 기억해 두는 것뿐이다. 화면 공유 소프트웨어로 Mac Mini에 접속해서 확인을 누른다.
여기엔 그럴듯한 이유가 있다. TCC 하위 시스템의 목표는 악성코드가 몰래 컴퓨터에 접근하는 걸 막는 것이다. 프롬프트를 유저랜드의 소프트웨어가 접근할 수 있으면 악성코드가 우회할 수 있다. 하지만 나는 에이전트 전용으로 배치한 컴퓨터를 돌리고 있다. 내 사용 사례에서 TCC는 골치 아픈 존재 그 이상도 이하도 아니며, 간접적으로는 내가 해킹당는 데 한몫했다.
애플에 대한 불만
다시 Ars Technica에서.
NCSC가 언급했듯 이 취약점은 5900 포트가 인터넷에 노출됐을 때 악용된다. 화면 공유를 켜면 macOS 방화벽이 해당 포트를 연다. 라우터와 전용 방화벽은 별도 설정을 하지 않는 한 대개 이 포트를 막는다. 보안 실무자들은 화면 공유를 쓰더라도 포트를 닫아 두고 대신 VPN이나 SSH 터널링으로 접속하라고 권한다. 이 대안들은 대부분 사용자가 할 수 있는 조치가 아니다.
가장 안전한 방법은 화면 공유를 차단하고, 필요할 때만 켜고, 세션이 끝나면 끄는 것이다. 화면 공유는 시스템 설정 > 일반 > 공유에서 화면 공유 스위치로 켜고 끌 수 있다. 물론 지난주 보안 업데이트를 설치하는 것도 필수다.
당연히 앞으로는 VPN을 쓸 것이다(내 보안 접근의 근간은 Tailscale이다). 그래도 짚고 싶은 건, 내가 원하는 방식으로 Mac Mini를 실제로 쓰려면 TCC 때문에 화면 공유를 켜 둘 수밖에 없다는 점이다. 나는 화면 공유를 끊임없이 쓴다. 휴대폰에서도. 그리고 거의 매번 그 목적은 오래전부터 진지하게 받아들이지 않는 어리석은 프롬프트에서 “확인”을 누르는 것이다. 처음부터 Tailscale에만 의존하지 않은 건 Mac Mini에 닿는 보조 경로를 갖고 싶었기 때문이다(SSH 터널링이었어야 했다. 이것도 좀 민망하고 내 잘못이다).
이 사건에서 나를 정말 얄밉게 만드는 건 Apple이 수정 사항을 배포한 방식이다. 보안을 위해 컴퓨터를 항상 최신 상태로 유지해야 한다는 건 안다. 내 모든 컴퓨터에 보안 업데이트 자동 설치를 설정해 뒀으니까.
내가 몰랐던 건 이 설정이 실제로는 대부분의 보안 업데이트에 적용되지 않는다는 사실이다. CVE 수정은 거의 언제나 포인트 릴리스로 도착한다. 실제로 가장 최근 포인트 릴리스가 이 버그 수정이 내용이었다. 문득 깨달았다. 수년 동안 나는 실제로 필요한 것보다 더 많이 노출돼 있었다. “보안… 업데이트 자동 설치”에 체크하면 보안 업데이트가 자동으로 설치될 거라고 잘못 믿은 탓이다.
물론 여기서 내가 지나치게 따지는 걸 수 있다. 결국 내가 포인트 릴리스를 제때 설치하지 않은 것이다. 그래도 신경이 쓰이는 건, 내 Desktop에 접근하는 데는 예민한 회사가 꽤 중요한 설정이 꽤 세련된 사용자에게 어떻게 읽히는지에는 별로 관심이 없었다는 점이다. 이번에도 내 실수지만, 그 실수는 Apple이 보안 업데이트를 보안 업데이트라고 부르고 자동 설치 옵션까지 준다면 믿어도 된다고 여긴 사람의 정직한 실수였다.
Apple이 대체로 벌어 온 신뢰다. 점점 답답한 건, 그 신뢰를 점점 더 요구하고 요구의 범위도 계속 넓어진다는 것이다. 업데이트 표기를 두고 불평하는 게 하찮아 보일 수 있다. 그런데 네트워크 공유 접근에 허가를 요구하려면, 내가 명시적으로 허용한 보안 업데이트는 적어도 내 컴퓨터에 적용해 주면 안 되나?
이것이 Full Disk Access 노트가 불길하게 느껴지는 이유이기도 하다. 어떤 에이전트에게 Full Disk Access를 주면 그 에이전트가 iMessage를 읽을 수 있다는 걸 사용자가 이해하지 못할 수 있다는 건 이해한다(당장은. 2000년대 iTunes처럼 iMessage 저장소도 머지않아 암호화될 거라고 보지만). 다른 사용자는 오히려 그게 필요할 수 있다. 아니면 나처럼 맥을 Apple이 관리하는 기기라기보다 자기 개인 컴퓨터로 실제로 쓰고 싶어할 수도 있다. 이번 사건이 내가 그런 위험을 감당하기엔 너무 무능하다는 걸 보여준 것인지, 아니면 수년을 함께한 Apple과 내가 서로 엇갈려 말하고 있는 것인지 모르겠다.
홈 비전
지난주 Mark Gurman이 Bloomberg에 Apple Is Finally Ready to Enter Its Next Big Category: the Smart Home이라는 기사를 냈다.
Apple은 10월 13일, 오랫동안 미뤄진 스마트 홈 시장 진출을 본격화할 계획이다. 새 CEO John Ternus 체제에서 회사에 중요한 제품 확장이다. 관계자들에 따르면 전략의 중심에는 J490이라는 코드명의 스마트 홈 허브가 있다. Apple은 2020년 출시 이후 첫 HomePod mini 업데이트와 2022년 이후 첫 새 TV 셋톱박스도 발표할 예정이다…
이 제품들은 Apple이 수년간 개발한 새 Siri AI 어시스턴트를 보여주는 무대이기도 하다. 탈모습을 바꾼 Siri는 수차례 지연을 겪었고, 스마트 홈 기기들은 Apple이 마침내 인공지능에서 따라잡으려는 노력을 조명하는 데 도움이 될 것이다. 홈 허브는 대략 6인치 정사각형 디스플레이 형태로, 벽에 달거나 카운터에 놓을 수 있는 버전이 나온다고 관계자들이 밝혔다. 제품이 공개되지 않았다는 이유로 익명을 요구했다…
Apple은 고객이 이런 디스플레이를 집 여러 곳에 두는 상상을 한다. 온도조절기, 도어락, 기타 연결 제품을 제어하고, 영상 통화, 인터콤 식 소통, 음악 재생, Apple iCloud에 저장된 사진 슬라이드쇼 감상에 쓸 수 있다.
홈 오토메이션 관련 발표가 그것만이 아니었다. Muse 제작자 Nat Friedman이 X에 올렸다.
내가 일반 대중을 대표하지 않는다는 건 아주 뼈저리게 안다. 우선 나는 에이전트를 실제로 쓰는 사람이다. 게다가 나는 Muse의 목표 고객이 아니다. Meta의 에이전트를 쓰는 것보다 내 에이전트를 직접 만드는 데 더 관심이 있다. 지금 진행 중인 프로젝트 중 하나는 에이전트가 제어할 만한 소형 가젯들을 만들어 볼 작은 홈 일렉트로닉스 랩이다.
그렇다 쳐도, Gurman의 기사에서 나를 놀라게 한 건 Apple 스마트홈 제품에 느끼는 열의의 수준이 얼마나 낮은가였다. 십 년간의 Siri 실망이 쌓인 피로도 있고, 음성 중심 제품을 회사가 해낼 수 있을지에 대한 회의도 있다. 그보다 더 큰 이유는, Apple의 제약을 내 삶의 더 많은 부분에 들이는 생각 자체가 거슬린다는 것이다.
그 제약이 Full Disk Access 같은 것에만 국한되지 않는다. Apple이 온도조절기나 도어락 같은 것과의 통합을 해내는 만큼, 그건 서드파티 기기 제조사와 협력해야 가능하다. 문제는 서드파티 기기 제조사들이 대개 형편없다는 것, 특히 소프트웨어 측면에서다. Siri가 완벽하다 해도, Apple은 최소공배수가 정하는 경험이 되지 않도록 하는 난관에 부딪힌다.
내가 훨씬 더 관심을 갖는 건 소프트웨어 계층을 내가 직접 제어하는 것이다. 사실 AI가 있으면 기존 소프트웨어 거의 전부를 디컴파일할 수 있다. 최근 몇 주 동안 게임 쪽에서 혁명이 일어나고 있다. 게임들이 차례로 소스로 디컴파일돼 어느 플랫폼으로든 포팅되고 있다. 그리고 직접 쓸 수도 있다. 그렇다는 건, 모든 것에 대해 내 에이전트가 내가 원하는 방식으로 상호작용하는 내 소프트웨어가 가능하다는 뜻이다. Apple이 알맞은 API를 내놓고 서드파티 개발자들이 형편없지 않기를 빌어 바라는 것보다 훨씬 흥미롭다.
앱의 한계
이건 참고로 Siri에게 닥친 문제이기도 하다. 최근 iPhone 이벤트와 Ternus의 “Intelligent Personal Hub” 비전에 대해 내가 쓴 글에서:
가장 흥미로운 건, Apple이 전통적으로 갖고 있던 가장 큰 강점이 어떻게 발목을 잡는 요소가 될 수 있는가다. Apple이 30만 개 앱이 Siri와 작동한다고 주장한다는 건 극도로 인상적이다. 하지만 “개발자가 새 기능을 도입하기 쉽다”는 말의 함축은 개발자가 실제로 그 일을 해야 한다는 것이다. Duo용 UI를 업데이트하는 작업에 추가되는 작업이다.
모두가 개발자를 설득해 통합을 만들어야 하는 세계에서는 이게 문제가 되지 않는다. 그런데 여기서 브라우저 사용이 크게 부각된다. 에이전트가 그냥 웹을 쓸 수 있는 만큼, 사실상 모든 것과의 통합을 공짜로 얻는다. 개발자가 API에 붙기를 기다리는 Apple이 불리한 위치에 놓인다…
Apple의 비전에서 Intelligence의 유용성은 기존 워크플로우를 보강하는 능력으로 정의된다. 그래서 캘린더와 리마인더 업데이트 언급이 나온다. 하지만 더 나은 워크플로우는 앱에서 이뤄지던 일 많은 부분을 에이전트에게 직접 맡기는 것일 수 있다. 확인해야 하는 구조화된 리마인더 앱이 나은가, 아니면 에이전트가 직접 상기시켜 주는 것이 나은가? 실제 답은 사람마다 다르겠지만, Apple이 앱 패러다임에 너무 결혼해 있어서 대안을 고려해 본 적조차 없을 거라는 점은 짚어둘 만하다.
앱은 놀라웠고, 그 이전보다 나은 경험이었다. 그렇다고 앱이 최선의 경험이라는 뜻은 아니다. 에이전트를 진지하게 써 본 사람이라면 내가 무슨 말을 하는지 정확히 안다. 앱은 방해가 된다. 앱과 통합한다는 건 에이전트를 더 나쁘게 만드는 것이다. 진짜 UI, 즉 모든 디지털 것을 위한 범용 인터페이스를 손에 쥔 상태에서 앱마다 다른 UI를 원하는 사람은 없다.
바로 이 지점에서 Muse Gadgets 프로그램은 천재적인 수법이다. Meta는 잠재적으로 실제 제품이 될 수도 있는 기기들로 가득한 생태계 전체를 시딩하고 있고, 완전 오픈소스다. 보상은 기기를 파는 데 있지 않다. Muse가 모든 것의 인터페이스가 되는 데 있다.
해커의 미래
21년 전 Paul Graham이 Return of the Mac을 썼다.
내가 아는 최고의 해커들이 점차 맥으로 갈아타고 있다. 이유는 물론 OS X다. Powerbook은 아름답게 설계됐고 FreeBSD를 돌린다. 이것보다 더 알아야 할 게 뭐가 있는가?…
OS X와 함께 해커들이 돌아왔다. 케임브리지의 Apple 스토어에 들어섰을 때 집에 온 것 같았다. 많은 게 변했지만 Apple 특유의 멋은 여전히 공기 중에 있었다. 쇼를 운영하는 사람이 마음같아 하는 사람들이라는 느낌, 대충대충 기업 딜러들의 느낌이 아니라.
그래서 어때서, 상업 세계는 말할지 모른다. 해커가 Apple을 다시 좋아하면 무슨 상관인가? 해커 시장이 도대체 얼마나 큰가?
아주 작지만, 크기에 비해 중요하다. 컴퓨터에 관해서, 해커들이 지금 하는 일을 10년 후에는 모두가 하게 된다. Unix부터 비트맵 디스플레이, 웹까지 거의 모든 기술은 CS 학과와 연구소에서 먼저 인기를 얻고 점차 세상에 퍼졌다.
Graham이 그 글을 쓴 해보다 1년 앞선 2004년에 맥으로 갈아탄 사람으로서, 이 문장은 나를 기분 좋게 했다. “나 맥으로 갈아탔는데, 나 이제 멋진 해커인가 보다.” 사실 Unix 부분은 나에게 크게 중요하지 않았다. 나는 디자인과 UI가 좋았고, GarageBand를 써 보고 싶었을 뿐이다. 그리고 이후 수년 동안 나는 맥이 그냥 되는 경험을 높이 평했다. 처음에는 대안들보다 느렸고, 그다음에는 대등했고, Apple Silicon 이후로는 그 어떤 것보다 나았다.
그런데 AI, 특히 에이전트에 관한 것은, 누구나 해커를 만든다. 의지와 아이디어만 있으면 정말 지금 뭐든 할 수 있다. 그걸 받아들이기 시작하면 폐쇄된 정원은 보호가 아니라 감옥처럼 느껴진다.
분명히 해두자면, 나는 Apple의 몰락을 예측하는 게 아니다. 컴퓨터나 휴대폰을 바꿀 생각도 없다. 그럼에도 나를 놀라게 하는 건, 회사의 홈 기기에 관심이 없을 뿐 아니라, 처음으로 Apple을 기본 선택으로 사지 않는 미래를 상상할 수 있게 됐다는 것이다. 실제로 그 일은 이미 일어났다. 이 사건 전에 이미 새 서버를 샀고, Linux가 돌아갈 것이다. 다시는 랙에 맥을 넣지 않을 것이다.
Apple에게는 상관없는 일이다. 그들의 컴퓨터는 애초에 그런 용도로 설계된 게 아니다. 질문은, 그렇게 설계된 것이 내가 향해 달려 가는 미래인가 하는 것이다. 에이전틱 추상화가 전통적 인터페이스를 유물로 만드는 동시에 컴퓨팅을 그 어느 때보다 모두에게 접근 가능하게 만들고, 한계가 규모를 위해 만드는 개발자가 아니라 나 자신을 위해 만드는 내 상상력이 되는, 바로 그 미래 말이다.