Experimenting with the proposed Cross-Origin Storage API in Transformers.js
Quick Summary
교차 출처 저장소 API는 브라우저 AI 앱이 모델과 웹어셈블리 파일을 암호학적 해시로 식별해 출처가 달라도 하나의 검증된 사본을 공유하도록 제안함으로써, 캐시 격리로 인한 중복 다운로드와 저장 공간 낭비를 줄이려는 초기 단계의 웹 API다.
🖼️ 인포그래픽
🖼️ 4컷 인포그래픽
💡 한 줄 요약
교차 출처 저장소 API는 브라우저 AI 앱이 모델과 웹어셈블리 파일을 암호학적 해시로 식별해 출처가 달라도 하나의 검증된 사본을 공유하도록 제안함으로써, 캐시 격리로 인한 중복 다운로드와 저장 공간 낭비를 줄이려는 초기 단계의 웹 API다.
📌 핵심 요약
- Transformers.js는 브라우저에서 음성 인식이나 감정 분석 파이프라인을 실행할 때 필요한 AI 모델과 웹어셈블리 런타임을 자동으로 내려받아 캐시하지만, 같은 출처 안에서만 재사용할 수 있다.
- 서로 다른 출처의 앱이 동일한 모델과 동일한 자원 주소를 사용해도 브라우저의 캐시 분할 정책 때문에 캐시가 적중하지 않으며, 예시에서는 동일한 음성 인식 모델만으로 177MB의 중복 다운로드와 저장이 발생한다.
- 이러한 캐시 격리는 과거 자원 접근 여부가 응답 시간으로 노출되는 보안·개인정보 침해를 방지하기 위한 것으로, 크롬은 최상위 사이트와 현재 프레임 사이트를 포함한 네트워크 격리 키를 자원 주소와 함께 사용한다.
- 제안된 교차 출처 저장소 API는 자원 주소나 출처 대신 SHA-256 같은 암호학적 해시로 파일을 식별하며, 저장된 파일이 없으면 네트워크에서 내려받아 기록하고 있으면 파일 핸들을 통해 즉시 읽게 한다.
- 개발자는 파일을 모든 출처, 지정한 출처 목록 또는 같은 사이트에만 공개할 수 있으며, 브라우저는 기록 시 실제 데이터와 선언된 해시가 일치하는지 검증해 저장 자원의 무결성을 보장한다.
🧩 주요 포인트
- Transformers.js는 브라우저에서 음성 인식이나 감정 분석 파이프라인을 실행할 때 필요한 AI 모델과 웹어셈블리 런타임을 자동으로 내려받아 캐시하지만, 같은 출처 안에서만 재사용할 수 있다.
- 서로 다른 출처의 앱이 동일한 모델과 동일한 자원 주소를 사용해도 브라우저의 캐시 분할 정책 때문에 캐시가 적중하지 않으며, 예시에서는 동일한 음성 인식 모델만으로 177MB의 중복 다운로드와 저장이 발생한다.
- 이러한 캐시 격리는 과거 자원 접근 여부가 응답 시간으로 노출되는 보안·개인정보 침해를 방지하기 위한 것으로, 크롬은 최상위 사이트와 현재 프레임 사이트를 포함한 네트워크 격리 키를 자원 주소와 함께 사용한다.
- 제안된 교차 출처 저장소 API는 자원 주소나 출처 대신 SHA-256 같은 암호학적 해시로 파일을 식별하며, 저장된 파일이 없으면 네트워크에서 내려받아 기록하고 있으면 파일 핸들을 통해 즉시 읽게 한다.
- 개발자는 파일을 모든 출처, 지정한 출처 목록 또는 같은 사이트에만 공개할 수 있으며, 브라우저는 기록 시 실제 데이터와 선언된 해시가 일치하는지 검증해 저장 자원의 무결성을 보장한다.
🧠 상세 정리
1. 브라우저에서 실행하는 Transformers.js 파이프라인
Transformers.js는 웹 개발자가 작업별 파이프라인을 만들어 브라우저에서 트랜스포머 모델 추론을 실행할 수 있게 한다. 원문은 자동 음성 인식 작업과 Xenova/whisper-tiny.en 모델을 지정하고, 웹 그래픽 처리 장치를 사용해 jfk.wav 파일을 처리하는 예시로 출발한다. 이 모델은 일반적인 영어 음성 인식에 적합할 뿐 아니라 Transformers.js의 기본 모델 해석 규칙에서도 자동 음성 인식용 기본값으로 선택된다. 파이프라인을 처음 실행하면 라이브러리가 필요한 모델 자원과 웹어셈블리 파일을 자동으로 내려받고 캐시하며, 같은 페이지를 다시 불러오면 캐시 API에서 자원을 제공하므로 결과가 거의 즉시 반환된다.
2. 출처가 달라지면 반복되는 모델 다운로드
문제는 동일한 모델을 사용하는 앱이 서로 다른 출처에서 제공될 때 드러난다. 한 출처에서 Xenova/whisper-tiny.en의 모든 자원을 이미 내려받아 캐시했더라도, 같은 예제 앱을 다른 출처에서 열면 브라우저는 바이트 단위로 완전히 동일한 파일을 다시 내려받고 별도로 저장한다. 원문의 작은 실험에서도 이러한 중복 다운로드와 저장 용량이 177MB에 이르며, 여러 웹 앱이 인기 모델을 반복해서 사용하면 낭비가 빠르게 누적될 수 있다. 따라서 개별 앱의 캐시는 정상적으로 작동하지만, 출처 경계를 넘어 동일한 대용량 AI 자원을 재사용하지 못한다는 점이 핵심 과제로 제시된다.
3. 서로 다른 모델도 공유하는 웹어셈블리 런타임
중복 문제는 같은 AI 모델을 사용하는 경우에만 한정되지 않는다. 원문은 음성 인식 결과에 감정 분석 파이프라인을 추가하고, 모델을 명시하지 않아 Transformers.js가 Xenova/distilbert-base-uncased-finetuned-sst-2-english를 기본값으로 선택하는 사례를 보여준다. 두 파이프라인은 서로 완전히 다른 AI 모델을 사용하지만, 기반이 되는 ONNX Runtime의 4,733kB짜리 ort-wasm-simd-threaded.asyncify.wasm 파일에는 함께 의존한다. 다른 출처에서 확장된 예제를 열면 이 공통 웹어셈블리 런타임도 다시 내려받아 캐시되므로, 모델이 겹치지 않는 앱 사이에서도 동일한 런타임에 대한 중복 네트워크 요청과 디스크 사용이 발생한다.
4. 캐시 분할이 필요한 보안상의 이유
AI 모델 자원은 기본적으로 허깅 페이스 허브를 거쳐 최종 CDN 주소에서 제공되고, 웹어셈블리 런타임은 기본적으로 jsDelivr CDN에서 제공된다. 겉으로는 여러 앱이 최종적으로 동일한 CDN 주소를 요청하므로 하나의 캐시를 공유할 수 있을 것처럼 보이지만, 현대 브라우저의 캐시는 오랫동안 출처 또는 사이트 문맥에 따라 분할돼 왔다. 이는 어떤 사이트의 HTTP 요청 응답 시간을 관찰해 사용자가 이전에 동일한 자원에 접근했는지 알아내는 시간 측정 공격을 막기 위한 보안·개인정보 보호 장치다. 따라서 중복 저장은 단순한 구현 실수가 아니라, 사이트 간 방문 이력이나 자원 접근 여부가 간접적으로 노출되지 않도록 만든 캐시 격리 정책의 결과다.
5. 크롬의 네트워크 격리 키와 캐시 불일치
크롬은 자원 주소만으로 캐시 항목을 찾지 않고 네트워크 격리 키를 추가로 사용하며, 이 키는 최상위 사이트와 현재 프레임 사이트로 구성된다. 원문의 두 예제 출처인 googlechrome.github.io와 rawcdn.rawgit.net이 똑같은 jsDelivr 웹어셈블리 주소를 요청해도 각각의 최상위 사이트와 현재 프레임 사이트 값이 다르다. 그 결과 자원 주소가 문자 단위로 완전히 같아도 전체 캐시 키는 일치하지 않으며, 기존 사본은 캐시 적중으로 처리되지 않는다. 브라우저는 동일한 파일을 다시 내려받고 별도로 저장하게 되고, 교차 출처 저장소 제안은 바로 이 보안 경계를 유지하면서 대용량 공통 파일의 중복을 줄이는 문제를 다룬다.
6. 암호학적 해시로 파일을 찾는 교차 출처 저장소
제안된 교차 출처 저장소 API는 navigator.crossOriginStorage라는 전용 인터페이스를 통해 출처가 다른 웹 앱들이 대용량 파일을 저장하고 검색하도록 설계됐다. 파일은 내려받은 주소나 저장한 출처가 아니라 SHA-256 같은 암호학적 해시로 식별되므로, 서로 다른 앱이 다른 위치에서 확보한 파일도 실제 바이트가 같다면 같은 자원으로 인식할 수 있다. 앱은 먼저 해시로 파일 핸들을 요청하고, 파일이 있으면 반환된 FileSystemFileHandle의 getFile()을 통해 블롭으로 읽는다. 파일이 없으면 네트워크에서 내려받은 뒤 생성 옵션과 공개 범위를 지정해 저장하고, 이후에는 같은 앱뿐 아니라 조건을 충족하는 완전히 다른 출처의 앱도 같은 해시로 이를 찾을 수 있다.
7. 기존 파일 시스템 API와 닮은 사용 방식
이 API의 형태는 출처 전용 파일 시스템에서 사용하는 FileSystemDirectoryHandle.getFileHandle()과 의도적으로 비슷하게 설계됐다. 출처 전용 파일 시스템에서 이름이 자원을 고유하게 식별한다면, 교차 출처 저장소에서는 해시가 같은 역할을 담당한다. create 옵션을 생략하거나 거짓으로 설정하면 기존 파일에 대한 읽기만 요청하고, 참으로 설정하면 새로운 파일을 기록하겠다는 뜻이 된다. 다만 이 기능은 아직 확정되지 않은 초기 단계의 제안이며 어느 브라우저에도 기본 구현돼 있지 않으므로, 원문은 별도의 교차 출처 저장소 확장 프로그램으로 navigator.crossOriginStorage 폴리필을 모든 페이지에 주입해 전체 흐름을 시험하는 방법을 안내한다.
8. 출처별 공개 범위와 단방향 권한 확대
저장 시 origins를 별표로 지정하면 파일은 해시를 아는 모든 출처에서 찾을 수 있으며, 공통 AI 모델이나 웹어셈블리 런타임처럼 웹 전체가 하나의 사본을 공유해야 하는 자원에 적합하다. 특정 출처 목록을 지정하면 회사의 여러 서비스가 함께 쓰는 독점 교정 모델처럼 허용된 사이트에만 접근을 제한할 수 있고, origins를 생략하면 같은 사이트에 속한 출처들만 사용할 수 있다. 공개 범위는 더 넓게 확대할 수 있지만 다시 좁힐 수는 없으므로, 이미 전역 공개된 파일을 다른 사이트가 제한된 목록으로 재저장해 접근성을 떨어뜨리는 일은 허용되지 않는다. 제한된 파일을 더 넓게 공개하려는 사이트는 전체 파일을 다시 기록해야 하며, 이는 기존 저장 여부를 알아내는 부채널로 권한 확대 절차가 악용되는 것을 막기 위한 요구사항이다.
9. 기록 단계의 무결성 검증과 남은 개인정보 문제
교차 출처 저장소에 파일을 기록할 때 브라우저는 실제 데이터가 선언된 해시와 일치하는지 확인하며, 값이 다르면 기록을 오류로 처리한다. 따라서 저장소에서 파일을 읽는 앱은 네트워크 다운로드 후 직접 해시를 계산했을 때와 같은 수준으로 예상한 바이트를 받았다고 신뢰할 수 있다. 이는 현재 많은 앱이 CDN에서 받은 모델 가중치가 올바른지 실용적으로 검증하기 어려운 문제도 함께 완화하며, 공식 허깅 페이스 CDN과 자체 호스팅 미러 중 어느 곳에서 받은 파일이든 동일한 검증을 적용한다. 원문은 마지막으로 공유 캐시가 사전 저장된 파일의 존재 여부를 사이트가 탐색하는 개인정보 문제를 다시 제기하지만, 제공된 source_body는 그 질문을 제시하는 문장 도중에 끝나므로 이후의 구체적인 보호 방식이나 결론은 확인할 수 없다.
🧾 핵심 주장 / 시사점
- 이 제안의 핵심은 기존 HTTP 캐시의 출처 격리를 없애는 것이 아니라, 주소와 출처가 아닌 검증 가능한 콘텐츠 해시를 기준으로 대용량 공통 자원을 별도 저장소에서 재사용하는 데 있다.
- 효과는 동일한 AI 모델의 재사용에 그치지 않으며, 서로 다른 모델과 작업이 공통으로 의존하는 ONNX Runtime 웹어셈블리 파일의 중복 다운로드와 저장도 줄이는 방향으로 확장된다.
- 해시 기반 식별, 기록 시 무결성 확인, 공개 범위의 단방향 확대, 권한 확대 시 전체 파일 재기록 요구는 자원 공유의 효율성과 보안·개인정보 보호를 함께 다루기 위한 설계 요소다.
✅ 액션 아이템
- 동일 모델·자원 주소를 쓰는 서로 다른 출처의 브라우저 AI 앱군에서 177MB 중복 다운로드를 줄이기 위해 적용 대상을 선별·우선순위를 정한다.
- 제안된 교차 출처 저장소의 SHA-256 기반 식별과 파일 핸들 즉시 읽기 절차를 도입해 캐시 재다운로드를 제거한다.
- 최상위 사이트·현재 프레임 사이트를 포함한 격리키 제약과 공개 범위(전체/허용 목록/동일 사이트) 설정을 충돌 없이 정합되게 정한다.
❓ 열린 질문
- 해시 식별 방식 적용 시 동일 파일 재사용 효과를 어떤 지표로 측정해 중복 제거 성과를 판단할 것인가?
- 최상위 사이트와 프레임 사이트 분리 규칙을 유지할 때, 공개 범위를 어디까지 열어야 개인정보 노출을 가장 낮출 수 있는가?
- 자원 해시 검증이 실패하면 브라우저는 어떤 복구 흐름으로 데이터 무결성 문제를 판정하고 재가져오기를 재시도할 것인가?