파일을 선택하는 것과 업로드하는 것은 다릅니다
브라우저의 파일 선택기는 사용자가 고른 파일에 대한 로컬 접근 권한을 페이지에 제공합니다. 이 시점에 파일 내용이 자동으로 서버로 전송되는 것은 아닙니다. 실제 업로드는 애플리케이션이 네트워크 요청을 만들어 파일 데이터를 보내야 발생합니다. No Limit의 로컬 도구는 가능한 작업에서 이 중간 업로드 단계를 만들지 않는 방향으로 설계합니다.
영상은 압축된 채로 편집할 수 없습니다
MP4나 MOV 안의 H.264/H.265 같은 영상은 압축돼 있습니다. Preview를 만들려면 필요한 프레임을 디코딩해야 합니다. 브라우저가 제공하는 네이티브 미디어 기능이나 WebCodecs를 사용할 수 있으면 효율적이고, 특정 포맷은 WebAssembly 기반 런타임이 보조할 수 있습니다.
CPU, GPU, Worker의 역할이 다릅니다
| 구성 | 잘 맞는 작업 | 주의점 |
|---|---|---|
| WebCodecs / native media | 지원 코덱 디코딩·인코딩 | 브라우저·OS 코덱 지원 차이 |
| WebAssembly | 포맷 파싱, 일부 코덱, 파일 처리 | CPU·메모리 사용량 |
| WebGPU | 일부 AI 추론·병렬 계산 | 지원 기기와 GPU 메모리 |
| Worker | UI와 무거운 계산 분리 | 데이터 복사 비용 관리 |
| IndexedDB / OPFS | 프로젝트·캐시·로컬 파일 데이터 | 브라우저 저장공간 정책 |
긴 영상은 Proxy가 중요한 이유
4K 원본을 매 프레임 그대로 디코딩하면 모바일이나 저전력 노트북에서 Preview가 끊길 수 있습니다. 편집 중에는 더 가벼운 proxy나 낮은 품질 preview를 사용하고, 최종 Export에서 원본을 다시 참조하면 편집 반응성과 결과 품질을 분리할 수 있습니다. 데이터 모델에서 Timeline clip이 proxy 파일 자체가 아니라 원본 MediaAsset을 가리키는 이유도 여기에 있습니다.
브라우저 편집의 현실적인 한계
“무제한”이라는 말이 기기 자원을 무시한다는 뜻은 아닙니다. 실제 한계는 RAM, GPU 메모리, 저장공간, 브라우저 탭 메모리 정책, 코덱 지원, 파일 손상 여부에 따라 달라집니다. 대형 프로젝트는 원본 백업과 프로젝트 파일을 별도로 보관하고, 긴 작업에서는 브라우저의 절전·백그라운드 정책도 고려해야 합니다.
언제 로컬 방식이 잘 맞나
- 파일이 커서 업로드 시간이 부담스러운 작업
- 민감한 원본을 외부 처리 서버에 보내고 싶지 않은 작업
- 반복적인 변환·트림·자막 수정처럼 기기에서 충분히 처리 가능한 작업
- 오프라인에 가까운 환경에서도 편집 상태를 유지하고 싶은 작업