웹 브라우저는 못 하지만 다운로드 관리자는 하는 일

iOS는 앱이 원한다고 해서 계속 동작하도록 내버려 두지 않습니다. 앱을 벗어나면 몇 초 안에 일시 중단되고, 일시 중단된 앱은 CPU 시간도, 네트워크 소켓도, 자신이 멈췄다는 사실을 알아챌 방법도 갖지 못합니다. 메모리에 있던 내용은 여전히 그대로지만 얼어붙은 상태이며, 시스템에 메모리가 더 필요해지면 앱은 아무런 통보 없이 그대로 종료됩니다.

그래서 앱 내부의 일반적인 연결로 진행되던 다운로드는 홈 제스처를 하는 순간 끝나 버립니다. 일부 앱은 몇 초의 추가 백그라운드 시간을 요청해서 이를 감추기도 하는데, 다운로드가 백그라운드에서 살아남는 시간이 딱 사용자가 눈치채지 못할 정도까지만인 이유가 여기 있습니다.

제대로 된 해법은 종류 자체가 다릅니다. iOS는 백그라운드 전송 서비스를 제공합니다 — URL과 저장 위치 목록을 시스템에 넘기면, 시스템이 자신의 프로세스 안에서 자신의 일정에 따라 직접 다운로드를 수행합니다. 앱은 일시 중단되어도, 종료되어도, 아예 실행되고 있지 않아도 상관없습니다. 전송은 계속되고, 보고할 내용이 생기면 그때 앱이 백그라운드에서 다시 실행됩니다. 잠금 화면에서도 살아남는 모든 다운로드의 뒤에는 이 메커니즘이 있으며, 이를 쓸지 말지는 사용자가 켜고 끄는 설정이 아니라 앱이 처음부터 내려야 하는 설계상의 결정입니다.

웹상의 동영상 중 상당수는 파일로 전달되지 않습니다. HLS로 전달됩니다 — .m3u8 플레이리스트가 각각 몇 초 분량인 수백 개의 작은 세그먼트를 나열하며, 흔히 여러 화질 단계로 준비되어 연결 상태가 바뀌면 플레이어가 그 사이를 오갈 수 있게 합니다. 그 영화 전체를 담은 URL은 하나도 존재하지 않습니다. 애초에 영화는 하나의 연속된 시퀀스로만 존재하기 때문입니다.

이런 것을 저장한다는 건 모든 세그먼트를 받아온 뒤 재다중화한다는 뜻입니다 — 영상과 음성 스트림을 그대로 일반 MP4 컨테이너에 써넣는 것입니다. 재인코딩이 전혀 일어나지 않으므로 손실도 없고, 영화 길이가 아니라 몇 초밖에 걸리지 않습니다. 결과물은 어디서나 재생되는 평범한 파일입니다.

이것이 바로 "이 스트림을 다운로드"가 일반 파일을 받는 것보다 시작이 눈에 띄게 늦은 이유이기도 합니다. 플레이리스트를 가져와 해석하고 화질 단계를 선택한 뒤에야 세그먼트가 들어오기 시작하니까요. 그리고 어떤 스트림은 아예 저장할 수 없는 이유도 여기에 있습니다. 세그먼트가 DRM 방식으로 암호화되어 있다면, 그 키는 애초에 얻을 수 없도록 설계되어 있고, 법을 지키는 어떤 도구도 그것을 뚫을 수 없습니다.