신뢰할 수 없는 웹사이트가 방문자의 컴퓨터를 재시작해야 할 정도로 마비시킬 수 있다면, 이것은 '보안 문제'일까 아닐까. 최근 auberon.xyz 블로그에 공개된 'Deathray'라는 데모는 이 질문을 정면으로 제기한다. 작성자는 WebGPU 셰이더를 담은 작은 파일 하나만으로 맥의 그래픽 처리를 멈추게 만들 수 있으며, 피해자가 해야 할 일은 링크를 클릭하는 것뿐이라고 설명한다. 이 현상은 크롬, 파이어폭스, 사파리 등 브라우저를 가리지 않고 재현되지만, macOS에서만 발생하고 다른 운영체제에서는 탭을 닫으면 정상으로 돌아온다는 점이 핵심이다.
무슨 일이 일어나는가
Deathray는 WebGL을 대체하기 위해 등장한 비교적 새로운 웹 표준인 WebGPU를 사용한다. WebGPU는 웹사이트가 브라우저 API를 통해 셰이더를 기기의 GPU에서 직접 실행할 수 있게 해주며, 현재 대부분의 주요 브라우저가 지원한다. Deathray의 원리는 단순하다. 컴퓨트 셰이더 안에서 동일한 벡터를 버퍼에 무한히 복사하는 busy loop를 돌리고, 버텍스 셰이더가 같은 버퍼에 의존하도록 만든다. 컴퓨트 셰이더가 무한 루프에 갇혀 있으니 버텍스 셰이더는 앞으로 나아갈 수 없고, 이 정체가 GPU를 사용하려는 다른 프로세스로 번진다.
문제는 그 '다른 프로세스' 중에 macOS의 화면 표시를 담당하는 WindowServer가 포함된다는 점이다. WindowServer가 응답하지 않게 되면 데스크톱 UI 전체가 먹통이 된다. 작성자에 따르면 증상은 일정하지 않아서, 마우스는 움직이지만 다른 조작이 안 되기도 하고, 무지개색 비치볼이 뜨거나 화면 일부에 마젠타색 깨진 그래픽이 나타나기도 한다. 흥미롭게도 컴퓨터 자체는 살아 있어서 SSH 접속은 정상적으로 된다. 다만 WindowServer를 감시하는 워치독이 일정 시간 무응답을 감지하면 커널 패닉을 일으켜 기기를 재시작시킨다.
이미 한 번 겪었던 문제
Apple에게 이런 유형의 공격은 처음이 아니다. 2023년 Imperva의 Ron Masas는 WebGL을 이용한 유사한 악성 셰이더 'ShadyShader'를 만들었다. ShadyShader 역시 폭주하는 루프로 GPU를 점유하되, 기술적으로는 무한이 아닌 거대한 중첩 루프를 사용했다. Apple은 이에 대해 CVSS 6.5(중간) 등급의 CVE-2023-40441을 발급하고, 폭주 루프를 더 잘 탐지하도록 입력 검증을 강화하는 방식으로 대응했다.
그런데 WebGPU에서는 그 입력 검증이 더 약해 보인다. Deathray는 누가 봐도 명백한 무한 루프인데도 걸러지지 않기 때문이다. 작성자는 결국 무한 루프를 탐지하려는 시도 자체가 정지 문제(halting problem)라는 이론적 한계에 부딪히는, 이길 수 없는 싸움이라고 지적한다. 특히 신뢰할 수 없는 코드를 실행할 때는 응답 없는 셰이더를 탐지하는 것이 아니라 선점(pre-emption)해서 강제로 중단시키는 메커니즘이 필요하며, 작성자가 테스트한 다른 모든 운영체제는 이 부분을 제대로 처리했다.
Apple이 유독 취약한 이유로 작성자는 M 시리즈 칩의 아키텍처를 조심스럽게 지목한다. M 시리즈에서는 OS 커널이 GPU를 직접 선점할 수 없고, 대신 ASC라는 코프로세서가 GPU를 관리한다. GPU 선점 로직이 모두 이 ASC 펌웨어 안에 들어 있기 때문에, 커널 차원에서 폭주하는 셰이더를 끊어내기가 구조적으로 까다로울 수 있다는 것이다. 참고로 작성자는 M 시리즈 맥북(Tahoe 환경)에서만 테스트했으며, 다른 맥에서도 재현되는지는 확인하지 못했다고 밝혔다.
이것은 보안 문제인가
대응 과정도 논쟁거리다. 작성자는 이 이슈를 2026년 7월 27일 Apple 보안팀에 제보했고, Apple은 신속히 재현한 뒤 수정하겠다는 의사와 함께 (기밀로 표시된) 수정 일정까지 제시했다. 그러나 8월 26일 Apple은 입장을 바꿔 이 제보에서 '보안적 함의를 찾지 못했다', 제품 변경으로 이어지지 않는다고 통보했고, 대신 '개선 검토'를 위해 다른 팀으로 전달하겠다고 했다. 작성자는 이것이 사실상 매우 낮은 우선순위를 의미한다고 해석하며, ShadyShader가 6.5 중간 등급을 받았던 것과 비교하면 의아하다고 덧붙인다.
여기서 흥미로운 지점은 '무엇이 보안 문제인가'라는 정의의 간극이다. Apple의 논리는 결과가 크래시, 행(hang), 또는 복구 가능한 데이터 손실에 그치므로 보안 문제로 보지 않는다는 것이고, 작성자가 이야기해 본 보안 연구자들도 대체로 여기에 동의한다고 한다. 기술적으로는 틀린 말이 아니다. Deathray는 샌드박스 탈출이나 원격 코드 실행, 데이터 유출 같은 심각한 취약점과는 거리가 멀다. 반면 보안 비전문가들은 대부분 이 특성 규정과 Apple의 낮은 우선순위에 놀란다. 링크를 클릭하는 것만으로 탭이 아니라 컴퓨터 전체가 강제 재시작될 수 있다는 사실은, 브라우저가 시스템을 안전하게 격리해 줄 것이라는 사용자들의 (어쩌면 잘못된) 신뢰를 눈에 보이는 방식으로 깨뜨리기 때문이다.
실무적으로 보면 Deathray의 위험도는 진입 장벽이 극단적으로 낮다는 데서 온다. 누군가에게 링크를 클릭하게 만드는 것만으로 성립하므로, 악용될 경우 '더 악질적인 릭롤(Rickroll)' 수준의 성가신 장난이 될 수 있다. 웹 서비스나 콘텐츠를 다루는 실무자라면 신뢰할 수 없는 사용자 제공 링크·임베드가 macOS 사용자에게 이런 형태의 서비스 거부로 이어질 수 있음을 염두에 둘 필요가 있다. 작성자는 Recurse Center에서 WebGPU를 배우다 실수로 무한 루프를 만들며 이 현상을 우연히 발견했다고 밝히며, WebGPU 자체는 애정하는 기술이라 Apple이 WebGPU를 기본 비활성화하는 식으로 '수정'하지는 않기를 바란다고 당부한다. 요컨대 이 사례는 새로운 웹 표준이 기기 하드웨어에 더 가까이 접근할수록, 무엇을 보안 결함으로 볼 것인가에 대한 기존의 선이 함께 흔들린다는 점을 보여준다.