SharedArrayBuffer가 브라우저에서 다시 작동하기 시작했지만, 페이지가 교차 출처 격리(cross-origin isolated) 상태일 때만 가능합니다. 이 상태를 만들려면 두 개의 응답 헤더가 필요합니다. 이 헤더들을 추가하면서 사이트의 모든 서드파티 스크립트를 제거해야 했고, 이는 프론트엔드 구축 방식과 데이터 유출 방식을 완전히 바꾸어 놓았습니다.

헤더가 중요한 이유

SharedArrayBuffer는 자바스크립트에서 진정한 멀티스레딩을 가능하게 하며, 이는 탭 내에서 ffmpeg를 실행하기 위한 필수 조건입니다. 최신 브라우저들은 Spectre 방식의 보안 완화 조치 이후 이 기능을 다시 활성화했지만, 이를 **교차 출처 격리(cross-origin isolation)**와 연결했습니다. 격리를 달성하려면 서버에서 다음을 전송해야 합니다:

  • Cross-Origin-Opener-Policy: same-origin
  • Cross-Origin-Embedder-Policy: require-corp

두 번째 헤더인 require-corp는 외부 리소스가 Cross-Origin-Resource-Policy 헤더를 가지고 있거나 CORS(Cross-Origin Resource Sharing)로 가져와야 함을 브라우저에 알립니다. 대부분의 서드파티 서비스는 이러한 헤더를 설정하지 않으므로, 해당 서비스의 스크립트, 폰트, iframe은 즉시 차단됩니다.

격리 기능을 켰을 때 사라진 것들

헤더를 적용하자마자 연쇄적인 오류가 발생했습니다:

  • 분석(Analytics) – 대부분의 제공업체는 단순한 <script> 태그를 사용하여 no-CORS 요청으로 추적 코드를 로드합니다. CORP 헤더가 없으면 요청이 거부되어 트래커가 실행되지 않습니다.
  • Google Fonts – 스타일시트가 CORS 없이 fonts.googleapis.com에서 가져와집니다. 브라우저가 이를 폐기하므로 페이지에 커스텀 타이포그래피가 적용되지 않습니다.
  • 임베디드 미디어 – YouTube iframe과 위젯 스크립트에 CORP가 없어 렌더링이 중단됩니다.
  • OAuth 팝업 – 엄격한 same-origin 정책으로 인해 window.opener 관계가 깨져, 일반적인 팝업 기반 로그인 흐름이 작동하지 않습니다.

요약하자면, 해당 도메인이 새로운 헤더 체계를 수용하지 않는 한, 제3자 도메인에 의존하는 모든 에셋이 사라졌습니다.

중간 매개체 없이 재구축하기

사이트가 망가진 상황에서, 저는 셀프 호스팅 에셋을 중심으로 프론트엔드 스택을 다시 작성했습니다:

  • 폰트와 이미지는 이제 제 자체 오리진(origin)에서 제공되므로 외부 스타일시트가 필요 없습니다.
  • 데이터 API는 제가 제어하는 프라이빗 백엔드를 기반으로 구축되어 모든 요청이 제 도메인 내부에서 유지됩니다.
  • **분석(Analytics)**은 POST 이벤트를 수락하고 프라이빗 버킷에 저장하는 아주 작은 Cloudflare Worker로 대체되었습니다. 클라이언트 측 코드는 단 몇 줄의 fetch 코드로 구성됩니다.
  • Sentry와 같은 에러 보고 및 세션 리플레이 도구는 완전히 제거되었습니다. 이제 모든 크래시는 제 자체 엔드포인트에 기록됩니다.

외부 리소스가 여전히 필요한 경우, 유일한 실행 가능한 방법은 소유하고 있는 서버를 통해 프록시(proxy)를 거치게 하여 브라우저가 확인하기 전에 필요한 CORP 헤더를 추가하는 것입니다.

개인정보 보호의 이점 vs 운영 비용

즉각적인 이점은 명확합니다. 사이트가 더 이상 광고 네트워크, 폰트 제공업체 또는 비디오 플랫폼으로 사용 데이터를 유출하지 않습니다. 모든 텔레메트리(telemetry)는 제 통제하에 있으며, 원할 때 언제든 삭제할 수 있습니다. 이러한 수준의 개인정보 보호는 일반적인 서드파티 스택으로는 달성하기 어렵습니다.

트레이드오프는 추가적인 유지 관리 부담입니다. 폰트를 호스팅하고, 분석 데이터를 저장하며, 프록시를 최신 상태로 유지하는 작업은 대부분의 개발자가 전문 서비스에 외주를 주는 작업들입니다. 또한 이러한 접근 방식은 해당 서비스들이 제공하는 기능(예: 실시간 에러 집계 또는 상세한 퍼널 시각화)을 포기해야 함을 의미합니다.

반론: 생태계가 적응할 것인가?

어떤 이들은 서드파티 업체들이 결국 필요한 헤더를 추가하여 교차 출처 격리 도입을 수월하게 만들 것이라고 주장합니다. 이미 일부는 그렇게 하고 있지만, 널리 사용되는 서비스의 대다수는 여전히 그렇지 않습니다. 생태계가 따라올 때까지 개발자는 개인정보 보호의 이점이 셀프 호스팅에 필요한 엔지니어링 노력보다 큰지 결정해야 합니다.

제대로 격리되었는지 확인하는 방법

다시 작성하기 전에 브라우저가 페이지를 격리된 상태로 인식하는지 확인하십시오:

crossOriginIsolated   // should be true
typeof SharedArrayBuffer   // should be "function"

두 확인 사항 중 하나라도 실패하면 헤더가 올바르게 적용되지 않은 것이며, SharedArrayBuffer를 사용할 수 없습니다.

개발자들에게 남겨진 과제는?

더 많은 웹 앱이 멀티스레드 자바스크립트의 성능 향상을 추구함에 따라, 서드파티 제공업체들이 CORP를 채택해야 한다는 압박이 커질 것입니다. 그동안 SharedArrayBuffer가 필요한 프로젝트는 셀프 호스팅 에셋 전략이나 가벼운 프록시 계층을 계획해야 합니다. 격리 요구 사항의 변경 사항을 확인하기 위해 브라우저 릴리스 노트를 주시하는 것도 필수적입니다.

핵심 요약: SharedArrayBuffer를 사용하기 위해 교차 출처 격리(cross-origin isolation)를 활성화하는 것은 어려운 선택을 강요합니다. 서드파티 스크립트의 편의성을 유지할 것인지, 아니면 더 엄격하고 자체적으로 제어 가능한 개인정보 보호 모델로 전환할 것인지 결정해야 합니다. 이 결정은 현대 웹사이트의 기술적 아키텍처와 데이터 흐름의 양상을 모두 재편합니다.