모바일 암호화 파일 전송: 이동 중 안전한 공유

모바일 파일 암호화는 iOS의 Safari와 Android의 Chrome/Firefox에서 Web Crypto API를 통해 실행됩니다. 데스크톱에서 작동하는 것과 동일한 crypto.subtle.encrypt 호출입니다. Photos 라이브러리나 Files 앱에서 선택한 파일은 바이트가 기기를 떠나기 전에 AES-256-GCM으로 암호화됩니다. 가장 무거운 작업은 PBKDF2 키 파생입니다. iPhone 14 Pro에서 600,000회 반복이 약 350ms에 완료됩니다. 최근 휴가에서 찍은 500MB .mov 파일의 실제 병목은 암호화가 아니라 업로드 대역폭입니다. 모바일 우선 전송 서비스는 네이티브 앱이 필요하지 않습니다. 브라우저에 필요한 모든 것이 갖춰져 있습니다.

브라우저 기반이 모바일 네이티브 앱보다 나은 이유

파일 전송용 네이티브 iOS 및 Android 앱(Dropbox, WeTransfer의 2023년 이전 앱)은 광범위한 권한을 요청하고, 사용 후에도 메모리에 남아 있으며, 광고를 표시합니다. 브라우저 기반 워크플로는 설치가 필요 없고, 한 번만 실행되며, 탭을 닫으면 종료됩니다. 더 중요한 것은, Apple의 App Store가 진정한 영지식 앱을 거부했다는 점입니다(Cryptee의 2021년 사례가 문서화되어 있습니다). 이로 인해 브라우저 배포가 암호화 로직이 앱스토어 업데이트로 조용히 교체되지 않음을 보장하는 유일한 방법입니다. 동일한 JavaScript 번들이 어디서나 실행되며 SHA-384 해시로 검증 가능합니다.

iOS와 Android의 Web Crypto API

iOS 17+의 Safari 17은 crypto.subtle을 완전히 지원합니다. deriveKey, encrypt, decrypt, sign, verify 모두 가능합니다. Android의 Chrome은 버전 37(2014년)부터 지원했습니다. 두 구현 모두 네이티브 OS 프리미티브에 위임합니다. iOS의 CommonCrypto, Android의 BoringSSL입니다. 따라서 암호화는 ARM의 AES 명령어로 하드웨어 가속됩니다. Pixel 8에서 5MB 청크 암호화는 약 15ms가 걸립니다. API는 JavaScript에 원시 키 재료를 노출하지 않습니다(CryptoKey 객체는 불투명 핸들). 모바일 브라우저는 악성 확장이 훨씬 적으므로 이것은 도움이 됩니다.

메모리 폭발 없이 대용량 파일 처리하기

모바일 Safari는 6GB RAM이 있는 iPhone에서 JavaScript 힙을 약 2GB로 제한하며, 구형 기기에서는 더 적습니다. 단순히 "파일을 ArrayBuffer로 읽고, 암호화하고, 업로드"하는 방식은 1GB 이상에서 충돌합니다. 스트리밍이 필수입니다. File.slice()를 사용해 5MB 청크를 읽고, 각각을 HKDF로 파생된 서브키로 암호화하며, ReadableStream 본문이 있는 fetch()를 통해 업로드합니다. 점진적 업로드는 10GB 동영상도 최대 메모리를 50MB 이하로 유지합니다. Android의 Chrome은 버전 105부터 스트리밍 fetch 요청을 지원합니다. Safari는 17.4에서 완전 지원을 추가했습니다.

배터리와 발열 고려사항

AES-256-GCM은 하드웨어에서 저렴합니다. ARMv8의 Cryptography Extensions는 거의 DRAM 속도로 실행합니다. iPhone 14 Pro에서 1GB 암호화는 배터리의 약 2%를 소비하며, 대부분은 업로드를 위한 라디오가 사용하지 CPU가 아닙니다. 사용자가 발열을 느끼는 곳은 높은 반복 횟수의 PBKDF2입니다. 1,200,000회 반복(OWASP 2024 권장)은 700ms가 걸리며 A17를 잠깐 90°C로 스파이크합니다. 600,000회 반복은 보안과 발열의 균형을 맞춥니다. m=32MB의 Argon2id는 메모리 경도가 더 느리지만 전력 밀도가 낮아 지속적인 워크로드에서 더 순합니다.

셀룰러, Wi-Fi, 업로드 안정성

모바일 업로드는 실패합니다. 지하철 터널, 엘리베이터, Wi-Fi에서 LTE로의 전환 — 이 중 어느 것도 단순한 fetch()를 끊어버릴 수 있습니다. 견고한 모바일 전송은 청크 수준 확인이 있는 재개 가능한 업로드를 사용합니다. tus.io 프로토콜(tus 1.0 스펙, 광범위하게 지원)이나 S3 멀티파트 업로드 같은 방식입니다. 각 5MB 청크가 독립적으로 업로드됩니다. 실패 시 해당 청크만 재전송합니다. 클라이언트는 IndexedDB에 청크 상태를 저장하므로 브라우저 탭 리로드나 iOS 탭 제거로 전체 작업이 다시 시작되지 않습니다. SwissTransfer와 HexaTransfer는 재개 가능한 업로드를 구현합니다. WeTransfer의 모바일 웹 플로우는 그렇지 않아, LTE로 2GB 업로드가 종종 실패합니다.

키보드 입력과 비밀번호 UX 문제

16자 강한 비밀번호를 휴대폰 키보드로 입력하는 것은 불편합니다. 대안을 제공하세요. 발신자 화면의 QR 코드를 스캔해 비밀번호를 받거나, 네이티브 비밀번호 관리자에서 붙여넣거나(iOS는 Keychain에서 자동 입력), 이전 전송 중 등록된 패스키를 사용하는 방법입니다. 일회성 경우에는 Web Share Target API를 사용해 Signal 같은 동반 앱이 사용자가 다시 입력하지 않고 비밀번호를 주입하도록 합니다.

접근성과 소형 화면

4.7인치 iPhone SE는 데스크톱 스타일의 드래그 앤 드롭 업로더에 맞지 않습니다. 모바일 암호화 UI는 뷰포트를 존중해야 합니다. 전체 화면 파일 선택기, 소프트 키보드 위에서도 보이는 진행 바, 모든 버튼에 VoiceOver 레이블(접근성을 위해 aria-valuenow가 있는 role="progressbar"), Apple HIG에 따른 최소 44x44px 탭 타겟이 필요합니다. 호버 상태 뒤에 컨트롤을 숨기지 마세요 — 터치에는 호버가 없습니다. iOS 저전력 모드로 테스트하세요. 저전력 모드는 백그라운드 타이머를 제한해 폴링 기반 진행 업데이트를 중단시킵니다.

iOS Safari의 업로드를 방해하는 함정

Safari on iOS에는 몇 가지 함정이 있습니다. iOS 16.4 이전에는 Fetch API의 업로드 진행 이벤트가 안정적으로 발생하지 않습니다. File System Access API는 지원되지 않으므로 Chrome처럼 로컬 스토리지에서 대용량 파일을 스트리밍할 수 없습니다. Safari는 메모리 압박 시 비활성 탭을 적극적으로 제거해 진행 중인 업로드를 중단시킵니다. 완화 방법: 폴백으로 진행 이벤트가 있는 XMLHttpRequest 사용(여전히 잘 작동), 업로드 중 탭을 포그라운드로 유지, 대용량 파일의 경우 화면을 잠그지 말라고 사용자에게 경고합니다. 화면 켜짐은 배터리를 소모하지만 탭 제거를 방지합니다.

Android의 광범위한 기기 분열

Android는 Pixel 8 Pro부터 Android Go를 실행하는 80달러 Moto e14 기기까지 다양합니다. Web Crypto는 모든 기기에서 작동하지만 성능이 크게 다릅니다. 2GHz MT6762는 600,000회 PBKDF2 반복에 1.8초가 걸리는 반면, Apple M3급 휴대폰은 200ms입니다. Device Memory API와 Hardware Concurrency를 통해 기기를 감지하고, 그에 따라 반복 횟수를 조정하세요(Go 기기는 300,000까지 낮춤). 셀룰러 전용 연결에서 1GB 이상의 업로드가 불안정할 수 있다고 사용자에게 경고하세요. 보상: 암호화된 전송이 플래그십 없이도 세계 대부분의 휴대폰에서 작동합니다.

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