브라우저에서 AI 모델을 실행하는 흐름이 커질수록 병목은 추론 코드만이 아니다. 큰 모델 파일과 웹 폰트처럼 여러 사이트가 반복해서 내려받는 자산도 중요한 비용이 된다. 같은 파일을 사이트마다 다시 다운로드하고, 각 오리진 저장소에 따로 보관하면 네트워크와 저장 공간이 함께 낭비된다.
Cross-Origin Storage, 줄여서 COS는 이 문제를 겨냥한 제안이다. 해시로 식별되는 리소스를 브라우저에 저장해 두고, 허용된 여러 오리진이 다시 사용할 수 있게 하려는 브라우저 API이자 저장 메커니즘이다.1
COS는 CORS의 대체물이 아니다
이름은 비슷하지만 COS는 CORS를 대체하지 않는다. CORS는 브라우저가 다른 오리진의 응답을 읽어도 되는지 판단하는 HTTP 헤더 기반 규칙이다.2
COS의 초점은 “읽을 수 있는가”보다 “이미 받은 큰 파일을 다시 받을 필요가 있는가”에 있다. 즉, 동일 출처 정책을 바꾸는 보안 모델이라기보다, 해시로 동일한 리소스를 식별해 재사용 가능성을 높이려는 저장 모델에 가깝다.1
핵심 식별자는 URL이 아니라 암호화 해시다. 같은 AI 모델 파일이나 같은 웹 폰트라면 요청한 사이트가 달라도 파일의 해시는 같다. 브라우저는 이 해시를 기준으로 COS에 이미 저장된 리소스가 있는지 확인할 수 있다.
무엇이 달라지나
현재 웹 저장소와 캐시는 대체로 오리진 단위로 나뉜다. 그래서 사이트 A가 큰 모델 파일을 내려받았더라도, 사이트 B는 같은 파일을 다시 받을 가능성이 높다. COS가 제안하는 변화는 이 지점에 있다. 리소스를 오리진이 아니라 콘텐츠 해시 중심으로 바라보면, 같은 파일을 여러 오리진이 중복해서 보관하지 않아도 된다.
제안된 명령형 API는 navigator.crossOriginStorage.requestFileHandles() 형태로 언급된다.4 개발자는 해시로 식별되는 파일을 요청하고, 브라우저는 COS에 해당 파일이 있는지 확인하는 식의 흐름을 상정할 수 있다.
CSS에서의 선언형 사용 방식도 논의되고 있다. 예를 들어 url()에 cross-origin-storage() 요청 URL 수정자를 붙여, 특정 리소스를 COS 대상으로 지정하는 방식이다.4 이 수정자는 기존 integrity() 수정자에 의존하도록 제안되어 있으며, 무결성 해시가 리소스 식별의 기준이 된다.4
제안된 흐름은 단순하다.
브라우저가 요청한 리소스의 무결성 해시를 확인한다.
COS에 같은 해시의 리소스가 있고, 해당 오리진의 사용이 허용되어 있으면 네트워크 대신 COS에서 가져온다.
COS에 없으면 네트워크에서 다운로드한다.
오리진 제한 조건이 허용하면, 이후 재사용을 위해 COS에 저장한다.4
누가 가져갈 수 있는가
COS가 “한 번 받은 파일을 아무 사이트나 쓸 수 있게 한다”는 뜻은 아니다. 제안에는 리소스 제공자가 재사용 범위를 지정하는 방식이 포함되어 있다.
CSS 예시에서는 cross-origin-storage(*)처럼 모든 오리진의 COS 사용을 허용하는 구문이 제시된다.4 반대로 cross-origin-storage("https://...")처럼 특정 오리진 목록에만 사용을 허용하는 방식도 논의된다.4
따라서 COS를 이해할 때 중요한 점은 두 가지다. 하나는 파일의 동일성을 해시로 판단한다는 점이고, 다른 하나는 재사용 가능 범위를 리소스 제공자가 제한할 수 있다는 점이다.
왜 웹 AI와 맞물리나
COS의 대표적인 대상 중 하나는 대형 AI 모델이다.4 Transformers.js 같은 도구는 웹 앱에서 task-specific pipeline으로 트랜스포머 모델을 실행할 수 있게 한다. 예를 들어 ASR 파이프라인은 Xenova/whisper-tiny.en 모델과 webgpu 장치를 사용할 수 있고, 감정 분석 기본 모델로는 Xenova/distilbert-base-uncased-finetuned-sst-2-english가 쓰인다.
이런 흐름에서는 모델과 런타임 파일의 크기가 체감 성능에 직접 영향을 준다. 예를 들어 ort-wasm-simd-threaded.asyncify.wasm WebAssembly 런타임 파일은 4,733 kB다. 모델 파일까지 포함하면, 여러 사이트가 유사한 자산을 반복 다운로드하는 비용은 더 커진다.
COS가 해결하려는 문제는 바로 이 반복 비용이다. 사이트 A에서 받은 대형 모델을 사이트 B가 조건에 맞게 재사용할 수 있다면, 사용자는 다운로드 시간을 줄이고 브라우저는 저장 공간을 더 효율적으로 쓸 수 있다.
지금 개발자가 볼 판단 기준
COS는 아직 완성된 표준 기능으로 보기보다 제안 단계의 API로 봐야 한다. Chrome 팀은 COS를 새로운 브라우저 API와 저장 메커니즘으로 검토하고 있으며, CSS에서의 선언형 연동 방식도 논의 중이다.4
따라서 지금 당장 프로덕션 코드가 COS에 의존하기보다는, 다음 질문을 기준으로 관찰하는 편이 현실적이다.
우리 서비스가 여러 오리진에서 반복 다운로드되는 대형 자산을 다루는가?
그 자산을 해시 기반 무결성 검증으로 안정적으로 식별할 수 있는가?
리소스 제공자가 전체 오리진 허용과 특정 오리진 허용 중 어떤 정책을 선택해야 하는가?
CSS, JavaScript API, 빌드 파이프라인 중 어디에서 COS 연동이 가장 자연스러운가?
COS의 의미는 단순한 캐시 추가가 아니다. 웹 앱이 점점 더 큰 실행 자산을 클라이언트에서 다루는 방향으로 갈수록, 브라우저 저장소를 오리진 단위로만 나누는 방식이 충분한지 묻는 제안이다. 특히 웹 AI처럼 대형 모델을 반복해서 내려받는 환경에서는, COS가 향후 성능과 배포 전략을 함께 바꿀 수 있는 주제로 볼 만하다.
1GitHub - WICG/cross-origin-storage: Explainer for the Cross-Origin Storage (COS) API
2Cross-Origin Resource Sharing (CORS) explained
3Cross-Origin Storage · Issue #256 · WICG/proposals · GitHub
4[css-values-5] Proposal for a new <request-url-modifier> called <cross-origin-storage>
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.