파일, 다운로드, 전송
iPhone에서 파일을 다룰 때 제멋대로처럼 느껴지는 것들은 대부분 격리에 관한 규칙 하나에서 비롯되고, 다운로드를 안정적으로 만드는 것들은 대부분 HTTP의 기능 하나에서 비롯됩니다. 여기서는 이 둘과, 파일이 한 기기에서 다른 기기로 옮겨가는 방식들을 함께 정리했습니다.
-
샌드박스
-
각 앱이 오직 자기 자신의 저장 공간만 볼 수 있다는 규칙입니다. 한 앱이 다른 앱의 다운로드 파일을 열 수 없는 이유이자, "동영상 옆에 자막 파일이 있다"는 개념 자체가 iOS에는 존재하지 않는 이유입니다.
모든 앱은 자신만의 전용 디렉터리를 갖고, 다른 앱의 디렉터리는 전혀 들여다볼 수 없습니다. 파일은 공유 시트, 문서 선택기, 드래그 앤 드롭처럼 의도적인 행위를 통해서만 앱 사이를 이동하며, 이는 하나하나가 앱이 알아서 처리한 게 아니라 사람이 직접 내린 결정입니다.
그 대가는 자잘한 곳에서 나타납니다. 데스크톱 플레이어는
film.mkv옆에 있는film.srt를 알아서 찾아냅니다. iOS에는 애초에 "옆에"라는 개념이 없어서, 자막 파일은 일부러 건네줘야 하고 그 짝을 계속 기억하는 것도 앱의 몫이 됩니다.함께 보기: 앱 그룹보안 범위 지정 북마크
-
앱 그룹
-
같은 개발자가 만든 두 앱이 함께 열어볼 수 있는 공유 저장 공간으로, 샌드박스에 뚫린 유일하게 허용된 틈입니다. 공유 확장 프로그램이 자신이 속한 앱에게 파일을 건네주는 방법이 바로 이것입니다.
공유 확장 프로그램은 겉보기와 달리 원래 앱과는 별개의 프로그램으로, 자기만의 샌드박스를 갖고 있고 실행 시간도 아주 짧습니다. 원래 앱의 저장 공간에 직접 뭔가를 써넣을 수는 없습니다.
그래서 대신 둘 다 접근이 허용된 공유 공간에 파일을 써두고, 앱은 다음에 실행될 때 그 공간을 비워 갑니다. 개발자 경계를 넘는 일은 전혀 없고, 사용자의 명시적인 탭 없이는 아무것도 넘어가지 않습니다.
함께 보기: 샌드박스
-
보안 범위 지정 북마크
-
외장 드라이브나 iCloud의 폴더처럼 샌드박스 바깥에 있는 폴더에 대한 접근 권한을 기억해 두는 토큰으로, 덕분에 앱은 나중에 다시 물어보지 않고도 그 폴더를 다시 열 수 있습니다.
시스템 파일 선택기를 통해 위치를 고르면, 그 순간에만 유효한 접근 권한이 부여됩니다. 북마크는 이 권한을 앱을 재실행해도 유지되게 해주고, 앱은 그 권한을 사용할 때마다 명시적으로 시작하고 끝내야 합니다.
이 덕분에 아무것도 복사해 오지 않고도 외장 SSD를 탐색하는 게 가능해지며, 그 권한 범위는 정확히 사용자가 고른 그 대상에만 한정됩니다 — 어떤 폴더 하나에 대한 북마크는 그 옆 폴더에 대해서는 아무 권한도 부여하지 않습니다.
함께 보기: 샌드박스
-
범위 요청
-
파일 전체가 아니라 특정 구간 — 예를 들면 5,000,000번째 바이트부터 5,999,999번째 바이트까지 — 만 서버에 요청하는 것입니다. 이게 있어야 다운로드를 이어받을 수 있고, 여러 연결이 동시에 한 파일을 나눠 가져올 수 있습니다.
범위 요청을 지원하는 서버는 206 Partial Content 상태 코드와 함께 요청받은 구간만 돌려줍니다. 지원하지 않는 서버는 200을 응답하며 처음부터 전체를 다 보내는데, 이게 바로 다운로드를 이어받는 것과 처음부터 다시 시작하는 것의 차이입니다.
다운로드 엔진의 흥미로운 기능은 거의 전부 이 하나의 HTTP 기능에 기대고 있습니다. 이게 없다면 연결이 끊긴 뒤에도, 재부팅 후에도 이어받을 방법이 없고, 여러 연결을 동시에 쓸 방법도 없습니다.
함께 보기: 이어받기 가능한 다운로드병렬 연결
-
이어받기 가능한 다운로드
-
지금까지 확정된 바이트 수를 기록해 두고 나머지만 요청함으로써, 처음부터 다시 시작하는 대신 멈췄던 바로 그 지점부터 이어지는 전송입니다.
여기서 필요한 조건은 기록된 숫자가 절대 낙관적이면 안 된다는 것입니다. 기록상으로는 이미 써진 것으로 처리됐지만 실제로는 아직 버퍼에 남아 있는 바이트가 있다면, 앱이 강제 종료될 때 파일에 구멍이 생깁니다 — 그리고 동영상 중간에 생긴 구멍은 시청을 시작한 지 한 시간이 지나서야 발견되는 손상입니다.
그래서 이 숫자는 네트워크에서 읽어들인 양이 아니라 디스크에 실제로 기록된 양을 따라야 하고, 포그라운드 전송과 백그라운드 전송 사이를 넘나들 때마다 이 숫자가 서로 일치해야 합니다.
-
병렬 연결
다중 연결, 청크 다운로드 -
파일 하나를 여러 구간으로 나눠서 동시에 여러 개를 가져오는 방식입니다. 하나의 연결이 속도 제한에 걸려 있을 때는 도움이 되지만, 병목이 사용자 본인의 회선 자체에 있다면 아무 효과가 없습니다.
연결 하나당 속도를 제한하는 서버라면, 연결을 여러 개로 나눠서 걸었을 때 총합으로는 더 많은 데이터를 받아낼 수 있는 경우가 흔합니다. 다중 연결 다운로드가 좋은 평판을 얻는 지점이 바로 여기입니다.
다만 이건 마법이 아니고, 흔히 오해받는 부분이기도 합니다. 이미 회선 자체가 포화 상태라면 연결을 늘려봤자 같은 용량을 더 작은 조각으로 나누고 오버헤드만 더할 뿐입니다. 일부 서버는 한 주소에서 오는 다중 요청을 아예 거부하거나 속도를 제한하기도 합니다.
함께 보기: 범위 요청이어받기 가능한 다운로드
-
백그라운드 전송
-
다운로드를 운영체제에 넘겨서, 앱이 닫힌 뒤에도 계속 이어지게 하는 방식입니다. 이때 타이밍은 시스템이 결정하는데, 그게 바로 전송이 끝까지 이어지는 것에 대한 대가입니다.
iOS 앱은 화면에서 벗어나면 얼마 지나지 않아 실행이 멈춥니다. 시스템의 백그라운드 서비스에 넘겨진 전송은 이 상태에서도 살아남고, 앱이 강제 종료돼도 살아남으며, 재부팅 후에도 다시 이어집니다.
대신 포기하는 건 제어권입니다. 시스템은 자신이 판단한 전원 상태와 네트워크 상태에 따라 이런 전송들을 일괄 처리하기 때문에, 백그라운드 다운로드는 앱 안에서 진행되는 다운로드와는 다른 방식으로 멈췄다 다시 시작되곤 합니다 — 다만 결국에는 끝까지 완료됩니다.
함께 보기: 이어받기 가능한 다운로드샌드박스
-
WebDAV
-
웹 서버를 파일 서버로 바꿔주는 HTTP 확장 기능입니다 — 목록 보기, 읽기, 쓰기, 이동, 삭제까지 가능합니다. Nextcloud와 ownCloud가 쓰는 방식이고, 대부분의 NAS 장비가 제공하는 방식이기도 합니다.
WebDAV은 결국 HTTP 위에서 동작하기 때문에, 특별한 포트나 별도의 클라이언트 프로토콜 없이 웹의 다른 모든 것과 똑같은 인프라를 그대로 씁니다 — 이게 바로 더 정교했던 다른 파일 프로토콜들은 사라졌는데 WebDAV만 살아남은 이유입니다.
회사의 클라우드에 파일을 맡기고 싶지 않은 사람에게는 실질적인 대안이 됩니다 — 자기 소유의 서버, 자기 자신의 인증 정보, 그리고 평범한 표준 기술만 쓰면 되니까요.
함께 보기: 클라우드 스토리지
-
클라우드 스토리지
-
다른 누군가의 서버에 보관된 파일에, 그 회사의 API — Dropbox, OneDrive, Box, pCloud 등 — 를 통해 접근하는 방식입니다. 저마다 인터페이스가 다르기 때문에 앱들은 하나씩 따로 지원을 추가할 수밖에 없습니다.
모든 클라우드에 공통으로 쓰이는 표준 프로토콜 같은 건 없습니다. 각 제공업체가 자기만의 API와 자기만의 로그인 절차를 따로 설계해 두었기 때문에, 앱에 새 제공업체를 추가하는 건 설정 항목 하나 넣는 게 아니라 실제로 해야 할 개발 작업입니다.
로그인은 보통 OAuth 방식이라서, 앱은 사용자의 비밀번호를 절대 볼 수 없습니다 — 제공업체가 직접 사용자를 인증한 뒤 토큰만 돌려주고, 이 토큰은 언제든 그 제공업체의 설정 화면에서 취소할 수 있습니다.
함께 보기: WebDAV
-
WebRTC
-
일단 연결이 맺어지고 나면 그 사이에 서버를 두지 않고 두 기기를 직접 연결하는 표준입니다. 기기 간 전송 기능이 같은 방 안에서 파일을 옮길 때 쓰는 방식이 바로 이것입니다.
작은 신호 교환 서버가 두 기기를 서로에게 소개해 준 다음(6자리 코드가 하는 역할이 바로 이것입니다) 자기 역할을 끝내고 빠집니다. 그 이후 파일은 두 기기 사이를 직접 오가며, 중간 어디에도 저장되지 않습니다.
같은 네트워크 안에서는 그 네트워크가 허용하는 만큼 빠릅니다. 인터넷을 통한 경우라면 양쪽이 서로 직접 도달할 수 있는지에 따라 달라지는데, 이게 바로 어느 기기도 원인을 알 수 없는 상태로 연결이 가끔 실패하는 지점입니다.
함께 보기: 로컬 HTTP 서버
-
로컬 HTTP 서버
-
자신의 네트워크 안에서 웹 요청에 응답하는 앱으로, 덕분에 컴퓨터의 웹 브라우저가 휴대폰이 제공하는 페이지를 열어볼 수 있습니다. 케이블도, 계정도 필요 없이 Wi-Fi 전송이 작동하는 방식이 바로 이것입니다.
휴대폰이 주소 하나를 보여주고, 컴퓨터가 그 주소를 엽니다. 그렇게 열리는 페이지는 다름 아닌 휴대폰 자신이 제공하는 것입니다. 파일은 로컬 네트워크를 통해 직접 오가며, 그 네트워크를 벗어나지 않습니다.
같은 네트워크에 있는 사람이라면 누구든 그 주소에 접근할 수 있으므로 잠금장치가 필요합니다 — 입력해야 하는 코드, 작업별로 따로 부여되는 권한, 그리고 일부러 켜두지 않는 한 꺼져 있는 파괴적인 기능들이 그것입니다.
함께 보기: WebRTC