Worker와 공유 메모리

웹 Worker는 별도 전역 환경에서 실행되어 메인 스레드의 작업과 병렬로 진행할 수 있다. 보통 postMessage는 구조화 복제로 데이터를 전달하고, Transferable 객체는 소유권을 이전한다. SharedArrayBuffer는 여러 실행 에이전트가 같은 기본 메모리를 볼 수 있게 하지만, 이를 썼다는 이유만으로 앱 전체가 복사 없이 동작하거나 빨라지는 것은 아니다. 공유 버퍼의 인덱스와 데이터 레이아웃, 작업 분할, 종료 처리는 애플리케이션이 설계해야 한다.

Atomics와 동기화

일반 공유 메모리 읽기·쓰기는 실행 에이전트 사이의 순서를 보장하는 동기화 프로토콜이 아니다. Atomics 연산은 공유 정수형 TypedArray의 원자적 접근과 순서 조정을 제공하므로, 카운터·플래그·작업 큐의 상태 전이를 정의하는 데 쓸 수 있다. Atomics.wait()는 메인 브라우저 스레드에서 호출할 수 없고, Worker 등 허용된 실행 문맥에서만 블로킹 대기로 사용한다. 사용할 수 있는 배열 형식과 메모리 모델은 ECMAScript 규격을 따라야 하며, 교착 상태나 잘못된 프로토콜까지 자동으로 막아 주지는 않는다.

브라우저의 cross-origin isolation 조건

현대 브라우저에서 웹 페이지의 SharedArrayBuffer 사용은 cross-origin isolated 상태에 의존한다. 일반적인 서버 구성은 최상위 문서에 Cross-Origin-Opener-Policy: same-origin과 Cross-Origin-Embedder-Policy: require-corp 또는 지원되는 환경의 credentialless를 적용하고, self.crossOriginIsolated를 확인하는 것이다. COEP 환경에서는 교차 출처 하위 리소스가 CORS 또는 CORP 정책으로 적절히 허용되어야 한다. iframe 안에서는 권한 정책과 상위·하위 문서 전체의 격리 조건이 추가될 수 있다. 세부 지원은 브라우저와 임베딩 문맥에서 확인한다.

보안 헤더의 영향과 한계

COOP는 창의 browsing context 관계와 opener 통신에 영향을 주고, COEP는 허용되지 않은 임베드 리소스를 차단할 수 있다. 따라서 헤더를 켜면 OAuth 팝업, 결제 창, 광고·분석 스크립트, 외부 이미지가 달라질 수 있어 Report-Only로 먼저 관찰하는 편이 안전하다. 이 격리는 브라우저가 민감한 공유 기능을 노출하기 위한 조건이지, 운영체제 프로세스가 반드시 분리되거나 앱이 모든 사이드채널 공격에 면역이 되었다는 보증은 아니다.

전문가 엔지니어링 안내와 점검

Google Chrome Developers의 브라우저 보안 전문가가 작성한 web.dev 배포 가이드는 COOP·COEP를 적용할 때 하위 리소스의 CORS/CORP 응답, iframe의 전체 격리 체인, crossOriginIsolated 확인이 필요하다고 설명한다. 이는 헤더를 실제 사이트에 적용하는 엔지니어링 지침이며 브라우저 표준 자체를 대체하지 않는다. 배포 전 주요 브라우저 버전에서 기능 감지, Worker 통신, 외부 리소스, 팝업 흐름을 시험한다. 브라우저 지원은 바뀔 수 있으므로 특정 버전 숫자를 보편 조건으로 외우지 말고 현재 호환성 표와 실제 실행 환경을 확인한다.

참고 자료