모바일 브라우저에서 대용량 파일 처리가 실패하는 가장 흔한 이유는 인터넷 속도가 아니라 기기 메모리와 한 번에 수행하는 계산량입니다. 300MB 파일을 선택했다고 메모리도 300MB만 쓰는 것이 아니라, 원본을 읽은 데이터·디코딩 결과·중간 캔버스·출력 파일이 한동안 함께 존재할 수 있습니다.
진행률이 잠시 멈추는 현상, 화면 터치가 늦어지는 현상, 오류 없이 탭이 새로 열리거나 닫히는 현상은 서로 원인이 다를 수 있습니다. 파일을 반복해서 다시 실행하기보다 실패 지점을 구분하고 작업 단위를 줄이는 것이 먼저입니다.
파일 크기보다 동시에 존재하는 데이터가 중요합니다
화면에 펼친 픽셀, 중간 결과와 완성될 결과 파일이 겹치면 원본보다 훨씬 많은 메모리를 사용할 수 있습니다.
긴 계산이 화면 표시와 터치 입력도 담당하는 작업 흐름을 막으면 진행 표시와 반응이 늦어집니다.
페이지 수·사진 수·출력 해상도와 동시 결과 수를 줄이면 성공 가능성이 크게 높아집니다.
실패 원인을 좁히는 순서
- 1
같은 형식의 더 작은 파일이나 적은 페이지로 먼저 실행합니다. 작은 작업은 성공한다면 형식 미지원보다 메모리·처리량 문제일 가능성이 높습니다.
- 2
다른 탭과 메모리를 많이 쓰는 앱을 닫고 브라우저를 새로 연 뒤 다시 시도합니다. 실패 직후 같은 탭에서 반복 실행하지 않습니다.
- 3
이미지·PDF는 출력 해상도와 품질을 낮추고, 일괄 작업은 파일 또는 페이지 수를 절반으로 나눕니다.
- 4
모바일에서 계속 실패하면 같은 파일을 메모리가 더 넉넉한 PC 브라우저에서 처리해 파일 손상과 기기 한계를 구분합니다.
- 5
오류 문구, 멈춘 단계, 파일 형식과 크기, 페이지·사진 수를 기록합니다. 단순히 ‘안 됨’보다 어느 단계에서 실패했는지가 해결에 도움이 됩니다.
왜 300MB 파일이 300MB보다 많은 메모리를 쓸까
브라우저가 파일을 읽으면 먼저 작업에 사용할 연속된 데이터 묶음(ArrayBuffer)을 만듭니다. WebAssembly 엔진(브라우저에서 변환 프로그램을 실행하는 기술)이나 압축 라이브러리가 이 데이터를 자체 작업 공간으로 다시 복사할 수 있고, 처리 중에는 원본과 결과가 동시에 남을 수 있습니다.
이미지는 압축된 파일 크기보다 디코딩된 픽셀 수가 중요합니다. 예를 들어 4,000×3,000 이미지는 1,200만 픽셀이며 RGBA 픽셀 버퍼 하나만 단순 계산해도 약 48MB입니다. 캔버스와 크기 조절용 중간 이미지, 출력 Blob이 겹치면 작은 JPG 한 장도 훨씬 많은 메모리를 사용할 수 있습니다.
작업 종류마다 메모리가 늘어나는 지점이 다릅니다
파일 크기 제한 하나만 보고 안전성을 판단하기 어려운 이유입니다. 같은 100MB라도 처리 방식과 결과 개수에 따라 부담이 달라집니다.
| 작업 | 추가로 생길 수 있는 데이터 | 부담을 줄이는 방법 |
|---|---|---|
| 이미지 압축·변환 | 디코딩 픽셀·Canvas·출력 Blob | 긴 쪽 크기와 동시 사진 수 줄이기 |
| PDF를 이미지로 | 렌더링 Canvas·페이지별 이미지·ZIP | 페이지 범위와 출력 배율 나누기 |
| 이미지를 PDF로 | 여러 디코딩 이미지·PDF 데이터 | 사진 수를 나누고 품질 낮추기 |
| 오디오·영상 | 입력 복사·WASM 메모리·디코딩·출력 | 파일을 나누고 PC에서 처리하기 |
| ZIP 일괄 저장 | 개별 결과·압축 데이터·최종 ZIP | 결과를 여러 묶음으로 내려받기 |
진행률이 멈춘 것과 탭이 종료되는 것은 다릅니다
JavaScript의 많은 작업은 화면 갱신과 터치 입력도 함께 담당하는 메인 스레드(브라우저의 주 작업 흐름)에서 실행됩니다. 긴 계산이 계속되면 실제 처리는 진행 중이어도 진행률 숫자와 버튼 반응이 잠시 갱신되지 않을 수 있습니다. web.dev는 50ms를 넘는 작업을 긴 작업으로 설명하며, 작업을 나누어 브라우저가 화면과 입력을 처리할 기회를 주는 방식을 권장합니다.
반면 탭이 갑자기 새로 열리거나 브라우저가 페이지를 종료했다면 메모리 압박이나 운영체제의 자원 회수 가능성을 먼저 의심할 수 있습니다. 웹페이지는 모든 모바일 기기의 사용 가능한 메모리를 정확히 알 수 없으므로, 서비스의 최대 허용량이 해당 휴대전화에서 안정적으로 처리된다는 보증은 아닙니다.
파일을 어떻게 나누는 것이 효과적인가
PDF는 전체 파일 크기보다 페이지 수와 출력 배율을 먼저 줄여 봅니다. 2배 해상도 PNG로 100페이지를 한꺼번에 만드는 작업은 페이지별 결과를 모두 모아 ZIP으로 만들 때 부담이 커집니다. 10~20페이지 범위로 나누거나 JPG·1배 해상도로 먼저 성공 여부를 확인하는 편이 좋습니다.
사진 일괄 작업은 장수와 해상도를 함께 봅니다. 고해상도 PNG 여러 장은 원본 HEIC나 JPG 총용량이 작아도 디코딩 후 메모리가 크게 늘 수 있습니다. 오디오·영상은 재생 시간이 길고 코덱 변환이 필요한 경우 모바일 CPU와 메모리를 오래 점유하므로, 긴 원본은 구간을 나누거나 PC 환경을 선택하는 것이 현실적입니다.
- 같은 작업을 반복 실행하기 전에 페이지를 새로 열어 이전 임시 데이터를 정리합니다.
- PNG 대신 JPG 또는 WEBP, 2배 대신 1배처럼 결과 크기를 줄이는 설정부터 시험합니다.
- 파일 수를 절반으로 줄였을 때 성공하면 한 번에 처리할 묶음을 더 작게 유지합니다.
- 배터리 절약 모드와 발열 상태도 장시간 처리 성능에 영향을 줄 수 있으므로 기기를 식힌 뒤 다시 시도합니다.
판단에 참고한 공식 문서
최대 허용량보다 안정적인 작업 단위를 기준으로 삼으세요
브라우저 로컬 처리는 파일을 서버로 보내지 않는 대신 사용자의 기기가 계산과 메모리를 부담합니다. 따라서 ‘최대 150페이지’ 같은 숫자는 입력을 허용하는 상한이지 모든 모바일 기기에서 안정적으로 끝난다는 약속이 아닙니다.
작은 샘플로 형식 지원을 확인하고, 페이지·파일 수와 출력 해상도를 단계적으로 늘리는 방식이 가장 안전합니다. 동일 파일이 PC에서는 되고 모바일에서만 실패한다면 파일 자체보다 기기 자원 차이를 먼저 고려해야 합니다.