네트워크 요청을 네 종류로 나눕니다
| 종류 | 네트워크 가능 | 원본 미디어 포함 |
|---|---|---|
| 사이트 HTML/CSS/JS | 예 | 아니오 |
| HEIC/PDF/미디어 런타임 | 필요 시 다운로드 | 아니오 |
| Whisper 모델 weight | 필요 시 다운로드 | 아니오 |
| 사용자가 선택한 영상·이미지·PDF | 로컬 처리 경로에서는 처리 서버 업로드 없음 | 기기 내부에서 읽음 |
| AdSense | 예 | No Limit 파일 처리 원본을 전달하도록 구현하지 않음 |
코드에서 먼저 보는 것
현재 Easy와 Studio의 핵심 미디어 처리 경로는 사용자가 선택한 File/Blob을 로컬 URL, WebCodecs, WebAssembly, Worker, IndexedDB/OPFS로 넘깁니다. 빌드 QA에서는 애플리케이션 asset에서 원본 파일을 FormData, XMLHttpRequest, sendBeacon으로 처리 서버에 전송하는 경로가 새로 생기지 않았는지 검사합니다.
반대로 동적 import와 모델/런타임 다운로드는 숨기지 않습니다. “네트워크 요청이 하나도 없다”는 표현은 실제 동작과 맞지 않으므로 사용하지 않습니다.
브라우저 저장소도 서버가 아닙니다
Studio 프로젝트는 지원 환경에서 IndexedDB나 OPFS 같은 사이트 전용 로컬 저장소를 사용할 수 있습니다. 이 데이터는 브라우저 프로필 안에 있으므로 일반적인 원격 업로드와 다르지만, 사용자가 사이트 데이터를 삭제하거나 브라우저가 저장공간을 회수하면 없어질 수 있습니다. 중요한 작업을 .nolimit 프로젝트와 원본 파일로 별도 백업하라고 안내하는 이유입니다.
광고 코드와 파일 처리 코드를 분리합니다
AdSense는 광고 제공을 위해 자체 네트워크 요청을 만들 수 있습니다. 그래서 Privacy에서는 “광고 SDK가 없다”고 쓰지 않고, 광고 네트워크와 로컬 미디어 처리 경계를 따로 설명합니다. 또한 Studio, Encoder, QC, 실제 변환 화면에는 Auto Ads 스크립트를 로드하지 않아 재생·다운로드·Export 같은 조작 UI 주변에 자동 광고가 끼어들 위험을 줄입니다.
검증의 한계
정적 코드 검사만으로 브라우저, CDN, 확장 프로그램, 운영체제의 모든 네트워크 동작을 통제할 수는 없습니다. 배포 후에는 DevTools Network와 실제 브라우저 환경에서 원본 파일 처리 시 request payload에 사용자 파일이 들어가지 않는지 별도로 확인하는 것이 가장 강한 검증입니다. No Limit의 공개 문구는 이 범위를 넘겨 단정하지 않습니다.