업로드 중 브라우저가 충돌? 안정적인 전송을 위한 해결책

업로드 중 브라우저가 충돌한다면 원인은 거의 항상 탭의 메모리 압력입니다. Chrome은 개인 메모리가 약 2~4GB를 초과하는 탭을 강제 종료하며, 10GB 파일을 단일 Blob 개체로 로드하는 전송 서비스는 그 한계를 훨씬 초과합니다. 해결책: File API의 slice() 메서드로 파일을 청크로 스트리밍하는 서비스를 사용하고(대부분의 현대 서비스가 그렇게 함), 업로드 전에 다른 모든 탭을 닫고, fetch/XHR에 개입하는 확장 프로그램을 비활성화하며, 배터리로 작동하는 노트북보다 데스크톱에서 업로드하세요. Firefox는 일반적으로 Chromium보다 메모리 오버헤드가 적게 대용량 File API 스트림을 처리합니다.

업로드 중 브라우저가 충돌하는 이유

두 가지 아키텍처 현실이 충돌합니다. 첫째, 모든 브라우저 탭은 자체 메모리 한계가 있는 별도의 프로세스입니다. Chrome은 OOM 킬러가 개입하기 전에 64비트 시스템에서 각 렌더러 프로세스를 약 4GB로 제한합니다. 둘째, JavaScript로 파일을 업로드하는 순진한 방법은 전체 File 개체를 fetch 본문에 전달하는 것으로, 브라우저는 전송 전에 메모리에 버퍼링하려 합니다.

잘 구축된 전송 서비스는 절대 이렇게 하지 않습니다. File.slice(start, end)로 파일을 읽어 각 5~20MB 청크에 대한 Blob을 생성하고, 그 청크를 업로드한 다음 해제합니다. 메모리는 파일 크기에 관계없이 대략 청크크기 × 동시성 바이트로 유지됩니다.

업로드가 500MB 진행 시 잘 시작되다가 2GB에서 탭이 회색이 된다면, 서비스가 전송 전에 전체를 로드하는 것입니다. 다른 서비스를 사용하거나 다른 접근 방식을 택하세요.

다른 탭을 과감하게 닫으세요

Chrome은 일부 그룹화된 탭에 대해 단일 렌더러 프로세스를 공유합니다(Site Isolation이 이를 변경하지만 메모리 압력은 여전히 시스템 수준에서 공유됩니다). 4K YouTube를 재생하는 두 번째 탭, Figma가 로드된 세 번째 탭, Notion이 각각 800MB의 RAM을 소비하는 네 번째 탭이 모두 쌓입니다. 8GB RAM의 노트북에 12개 탭을 열어놓고 10GB 업로드하는 것은 위험합니다.

큰 업로드를 시작하기 전에 Chrome을 완전히 종료하고 전송 서비스 탭만으로 다시 여세요. Activity Monitor(macOS) 또는 작업 관리자(Windows)가 해당 단일 탭에서 브라우저가 2GB 미만을 사용하고 있음을 표시해야 합니다.

확장 프로그램 비활성화

광고 차단기, 개인정보 보호 확장, 비밀번호 관리자, 네트워크 분석기(uBlock Origin, Privacy Badger, LastPass, HTTP Toolkit)는 모두 네트워크 요청에 개입합니다. 대부분은 문제를 일으키지 않습니다. 일부, 특히 오래된 코드의 것들은 요청 본문을 검사하기 위해 버퍼링하여 스트리밍 업로드를 무효화하고 메모리를 날립니다.

시크릿 창에서 테스트하세요(확장 프로그램은 기본적으로 비활성화됨). 시크릿에서 업로드가 깔끔하게 완료된다면 확장 프로그램이 문제입니다. 하나씩 활성화하여 원인을 찾으세요.

GPU가 약한 경우 하드웨어 가속 비활성화

Intel UHD 620이나 유사한 통합 GPU가 있는 구형 노트북은 진행률 표시줄 업데이트와 파일 읽기 버퍼를 동시에 렌더링하다 충돌하는 경우가 있습니다. Chrome의 설정 > 시스템 > "가능한 경우 하드웨어 가속 사용"을 비활성화할 수 있습니다. 이렇게 하면 다른 모든 것의 부드러움이 줄어들지만 메모리가 제한된 시스템에서 대용량 업로드를 안정화합니다.

마찬가지로 업로드 탭에 대해 Chrome의 "Memory Saver" 모드를 비활성화하세요. 이 모드는 업로드 도중 메모리 압박 시 탭을 축출하는 것으로 알려져 있습니다. 탭을 고정하거나 명시적으로 제외하세요.

매우 큰 파일에는 Firefox 전환

Firefox는 역사적으로 Chromium보다 더 타이트한 메모리 예산으로 File API를 처리합니다. Chrome에서 반복적으로 충돌하는 10GB 업로드가 Firefox에서는 문제없이 완료되는 경우가 많습니다. 잘 구축된 서비스에서는 차이가 크지 않지만(두 브라우저 모두 청크 스트리밍을 잘 처리함), 덜 이상적인 구현의 서비스에서는 Firefox의 보수적인 메모리 모델이 더 관대합니다.

macOS의 Safari도 대용량 업로드에 신뢰할 수 있지만, iOS Safari는 백그라운드 탭을 공격적으로 종료한다는 주의사항이 있습니다.

탭을 고정하고 전경에 유지하세요

백그라운드 탭은 메모리 압박 시 가장 먼저 축출됩니다. 업로드 탭을 전경에 유지하세요. 30분 동안 다른 창으로 전환하고 돌아와서 탭이 새로 고침된 것을 발견하지 마세요. Chrome의 "폐기된" 탭은 돌아오면 회색 자리 표시자를 표시하며, 진행 중인 업로드는 죽은 것입니다.

macOS에서 caffeinate -s 또는 업로드 중 Windows의 절전 모드를 비활성화하세요. 절전 중인 노트북은 WebSocket과 XHR 연결을 닫으며, 모든 서비스가 이후에 깔끔하게 재개할 수 있는 것은 아닙니다.

배터리가 아닌 데스크톱에서 업로드하세요

배터리로 작동하는 노트북은 CPU와 RAM을 공격적으로 제한합니다. macOS의 "저전력 모드"와 Windows의 "배터리 절약기"는 모두 백그라운드 작업 우선순위를 낮추며, AES 암호화와 네트워크 쓰기를 수행하는 브라우저 탭에는 지연을 의미합니다.

플러그인하세요. 배터리 절약 모드를 비활성화하세요. 노트북에 CPU 성능 프로필 선택 옵션이 있다면(Dell Power Manager, Lenovo Vantage), 업로드 동안 "성능"으로 설정하세요.

업로드 중 Activity Monitor로 RAM 확인

업로드 중 브라우저 프로세스의 메모리를 확인하세요. macOS Activity Monitor: Memory 탭, 브라우저 이름으로 필터. Windows 작업 관리자: 세부 정보 탭, "메모리(전용 작업 세트)" 정렬.

건강한 청크 업로드는 진행 상황에 관계없이 수백 MB의 브라우저 메모리를 안정적으로 유지합니다. 메모리가 업로드 진행에 따라 선형으로 증가한다면(10GB 파일의 50%에서 5GB에 도달), 서비스가 모든 것을 버퍼링하고 있는 것입니다. 그것이 버그입니다. 다른 서비스를 찾으세요.

대용량 브라우저 업로드에 맞게 구축된 서비스 사용

잘 설계된 전송 서비스는 암호화를 위한 Web Worker 풀, 제한된 메모리, 실패한 청크에 대한 명시적 재시도가 있는 청크 업로드를 사용합니다. HexaTransfer는 Web Workers에서 File.slice()로 파일을 읽고, 청크별로 AES-256-GCM으로 암호화하며, 50MB를 보내든 전송당 10GB 한도를 보내든 수백 MB의 브라우저 메모리를 절대 초과하지 않습니다.

hexatransfer.com에서 사용해 보세요 — 무료, 계정 불필요, 최대 10GB.