로컬 편집의 병목은 네트워크가 아니라 메모리와 디코딩입니다
수십 GB 파일을 서버에 올리지 않는 것은 큰 장점이지만 브라우저가 파일 전체를 RAM에 복사해도 된다는 뜻은 아닙니다. File 객체, 스트림, 디코더를 이용해 필요한 구간을 읽고, 무거운 원본은 Proxy로 Preview 부담을 줄이는 구조가 중요합니다. 특히 고해상도 H.265, 긴 GOP, 여러 동시 트랙은 같은 4K 파일이라도 기기마다 체감 성능이 크게 다릅니다.
Proxy와 Original은 같은 미디어의 두 표현으로 관리합니다
Timeline clip이 Proxy 파일 자체를 원본으로 기억하면 나중에 최종 출력에서 저해상도 파일을 잘못 사용할 수 있습니다. 프로젝트는 하나의 MediaAsset을 가리키고 Preview 때 Proxy, 최종 Export 때 Original을 선택하는 방식이 안전합니다. 원본이 잠시 offline이어도 Proxy가 있으면 편집을 계속할 수 있지만 최종 출력 전에는 원본 재연결이 필요합니다.
브라우저 로컬 저장은 백업과 다릅니다
IndexedDB와 OPFS는 자동 저장과 캐시에 유용하지만 사용자가 사이트 데이터를 삭제하거나 브라우저가 저장공간을 회수하면 사라질 수 있습니다. 중요한 프로젝트는 .nolimit 편집 파일과 원본 폴더를 별도로 보관하세요. 프로젝트 파일만 다른 기기로 옮기면 원본 미디어를 다시 연결해야 할 수 있습니다.
| 자원 | 부족할 때 증상 | 대응 |
|---|---|---|
| RAM | 탭 종료·디코더 실패 | Proxy, 동시 Preview 감소 |
| 저장공간 | Proxy/자동저장 실패 | 불필요 캐시 정리, 원본 외부 보관 |
| GPU | Preview·AI 느림 | 경량 모델/해상도, software fallback |
| 코덱 지원 | 재생·Export 불가 | Encoder로 호환 포맷 변환 |
대용량 Export는 완료 메시지보다 결과 파일 검증이 중요합니다
오프라인 렌더가 오래 걸려도 영상의 presentation timestamp와 오디오 시간축이 정확하면 결과는 정상일 수 있습니다. 반대로 실시간 화면 녹화 방식은 기기 렌더가 늦어질 때 영상이 오디오를 못 따라갈 수 있습니다. 최종 파일은 duration, A/V 종료 시점, 마지막 구간 프레임이 실제로 decode되는지 확인해야 합니다.
- 원본을 열고 Preview가 버거우면 Proxy를 만듭니다.
- 자동 저장 상태와 기기 저장공간을 확인합니다.
- 긴 작업 중간에 .nolimit 프로젝트를 별도 저장합니다.
- 최종 Export 전 원본 미디어 연결 상태를 확인합니다.
- 내보낸 파일의 90% 이후와 마지막 프레임을 반드시 재생합니다.