Cloudflare 블로그가 2026년 8월 19일, Workers 인프라에서 원격 Spectre 공격을 다시 점검한 결과를 공개했다. 제목은 A revisit of remote Spectre attacks on Cloudflare Workers다. 원문을 보면 2024년과 2025년에 걸쳐 재평가를 했고, 공격 원리와 방어를 상세히 공유했다고 한다. 새롭게 다룬 공격 요소는 Spectre gadgets와 remote timers, co-location 달성 같은 것들이다. Spectre gadgets는 추측 실행 중에 정보를 새는 코드 조각을 말한다. remote timers는 원격에서 실행 시간을 재는 수단이고, co-location은 공격자 코드를 피해자와 같은 물리 머신에 겹치게 만드는 과정이다. Cloudflare는 이런 공격에 대응하는 새 방어로 Workers를 더 단단하게 만들었다고 설명한다. 같은 머신에서 도는 코드 사이에 정보가 새는 문제를 막는 일이 얼마나 까다로운지 짐작하게 하는 대목이다.
다만 이 글이 중앙 클라우드 보안 이야기라는 점은 분명히 해 둔다. 우리가 관심을 갖는 건 그 세부 원리보다, 한 번 막았다고 생각한 공격이 시간이 지나 다시 고개를 든다는 사실이다. Cloudflare가 공유한 것처럼 공격 경로와 방어가 함께 발전한다면, 같은 문제를 안고 있는 분산 시스템도 주기적으로 점검해야 한다.
Workers는 중앙 클라우드의 멀티테넌트 실행 환경이라 P2P와 직접 비교하기 어렵다. 하지만 우리가 만드는 분산 시스템도 결국 낯선 사람이 보낸 코드를 내 컴퓨터에서 돌리는 순간이 온다. DePIN이나 그리드 컴퓨팅처럼 다른 사람의 노드를 빌려 쓰는 구조라면, 어떤 코드가 실행되는지 통제하는 일이 곧 보안의 전부가 된다. 원격 Spectre는 실제로 같은 머신에 올라탄 뒤에 의미를 갖는 공격이다. 중앙 데이터센터에서는 공격자와 피해자를 같은 물리 머신에 겹치게 만드는 co-location이 첫 관문인데, P2P 네트워크에서는 노드가 이미 전 세계에 흩어져 있어 이 관문이 구조적으로 존재한다. 그렇기에 Cloudflare가 공유한 Spectre gadgets나 remote timers 같은 요소는 P2P 런타임을 설계할 때도 그대로 체크리스트가 된다. 특히 누구나 코드를 올릴 수 있는 분산 컴퓨팅을 꿈꾼다면, 이번 글에서 다룬 원격 공격 경로를 처음부터 가정해야 한다.
사실 WebRTC 기반 연결에서는 데이터 채널로 받은 입력을 파싱하는 일이 있지만, 대부분 코드 실행까지 이어지지는 않는다. 그런데도 피어가 보낸 데이터를 신뢰하지 않는 원칙은 같다. P2P는 중앙 서버가 없어서 관리 주체가 흐릿하기 때문에, 보안 기준을 어디에 둘지 스스로 정해야 한다. Cloudflare는 중앙에서 통제할 수 있는 환경이지만, 우리는 그 통제권조차 없는 경우가 많다. 그래서 더 엄격한 격리와 모니터링이 필요하다.
이번 글이 주는 교훈은 단순하다. 보안 위협 평가는 한 번으로 끝나지 않는다. Cloudflare는 2024년과 2025년에 걸쳐 다시 들여다봤고, 공격 원리가 더 촘촘해졌을 때 방어도 함께 갱신했다. P2P 프로젝트는 예산도, 인력도 부족하기 때문에 이런 반복 평가를 미루기 쉽지만, 실행 코드를 외부에 노출하는 구조라면 처음부터 격리 비용을 설계에 넣어야 한다. PonsLink와 PonsWarp 같은 초기 MVP는 피어 간 연결과 미디어 전송이 중심이라 당장은 원격 코드 실행과 거리가 멀다. 하지만 분산 컴퓨팅 쪽으로 확장한다면, 지금 Cloudflare가 정리한 방어 항목이 우리의 요구사항 문장이 될 수 있다. 중앙 클라우드의 보안 고민을 P2P가 그대로 가져오라는 게 아니라, 멀티테넌트 실행을 허용하기 전에 Spectre 같은 사이드 채널을 이미 검증된 방식으로 막아야 한다는 점을 기억하자는 것이다.
개인적인 판단으로는, P2P 프로젝트가 보안 논의를 뒤로 미루는 가장 큰 이유는 ‘아직 아무도 우리 노드를 공격하지 않는다’는 착각 때문이다. 공격자는 인기가 많아진 뒤에 오는 게 아니라, 실행 구조의 허점을 발견하는 순간 온다. Cloudflare처럼 규모가 큰 회사도 주기적으로 재평가해야 하는 주제라면, 초기 프로젝트는 더 자주 점검해야 한다. 이번 글을 계기로 우리 제품도 실행 경계를 만들 때 Spectre를 비롯한 사이드 채널 문제를 체크리스트에 넣겠다. 앞부분에 링크를 걸어 두었으니, 세부 공격 원리나 방어 구조는 원문에서 직접 확인하면 더 정확하다.
댓글