모바일 기기 파일 시스템: 정의, 디렉터리 구조 및 작동 방식

모바일 기기 파일 시스템이란?

파일 시스템은 물리적 미디어에 데이터가 쓰기, 읽기 및 구성되는 방식을 관리하는 운영 체제의 소프트웨어 구성 요소입니다. 모바일 기기에서 파일 시스템은 중요한 기능을 수행합니다: 플래시 메모리 공간 관리, 권한 기반 파일 액세스 제어, 충돌 후 복구를 위한 변경 사항 저널링, NAND 플래시 메모리의 특성을 고려한 쓰기 최적화입니다.

데스크톱 OS와 달리, 모바일 파일 시스템은 플래시 메모리의 제한된 다시 쓰기 주기를 고려하여 설계됩니다. NAND 셀은 제한된 횟수의 지우기 작업을 견딜 수 있습니다 — TLC 및 MLC 메모리의 경우 각각 3,000~10,000 주기입니다. 저장소의 수명을 연장하기 위해 파일 시스템은 웨어 레벨링 메커니즘과 TRIM 명령을 사용합니다. Samsung이 플래시 메모리 전용으로 개발한 F2FS는 NAND 어레이 지오메트리를 고려하고 단편화와 블록 지우기 작업 수를 최소화하도록 데이터를 배치합니다.

최신 모바일 기기는 여러 파일 시스템의 조합을 사용합니다. 내부 메모리(/data 파티션)는 Android에서 EXT4 또는 F2FS, iOS에서 APFS로 포맷됩니다. SD 카드는 전통적으로 4GB를 초과하는 파일의 경우 exFAT, 최대 호환성을 위해 FAT32를 사용합니다. Android의 /system 파티션은 종종 읽기 전용으로 마운트되며 EXT4 또는 EROFS(Enhanced Read-Only File System) — Huawei가 시스템 파티션 크기를 줄이기 위해 개발한 압축 파일 시스템을 사용합니다.

Android의 디렉터리 구조

Android의 디렉터리 계층 구조는 /를 루트로 하는 Linux 구조를 기반으로 합니다. 각 파티션에는 고유한 파일 시스템, 액세스 권한 및 목적이 있습니다. 애플리케이션은 제한된 디렉터리 집합에만 액세스할 수 있으며 나머지는 루트 권한으로 보호됩니다.

/data 파티션 및 앱 샌드박스

/data 파티션은 사용자 데이터, 설치된 애플리케이션 및 해당 설정을 저장하기 위한 기본 파티션입니다. 각 애플리케이션은 /data/data/<package_name>/ 경로에 자체 디렉터리를 받습니다. 이 디렉터리 내에서 시스템은 자동으로 하위 디렉터리를 생성합니다: 애플리케이션 파일용 files/, 임시 파일용 cache/, SQLite 데이터베이스용 databases/, SharedPreferences용 shared_prefs/입니다. 이 디렉터리에 대한 액세스 권한은 애플리케이션 설치 시 설정되며 루트 액세스 없이 변경할 수 없습니다. 최신 기기의 대부분에서 /data 파티션은 F2FS로 포맷되어 EXT4 대비 최대 40% 더 높은 임의 쓰기 속도를 제공합니다.

/system 파티션 및 시스템 구성 요소

/system 파티션에는 운영 체제, 시스템 애플리케이션 및 라이브러리가 포함됩니다. 이 파티션은 시스템 파일의 우발적 또는 악의적인 수정을 방지하기 위해 읽기 전용으로 마운트됩니다. Android 10+ 및 Project Treble을 지원하는 기기에서 /system 파티션은 동적이며 전체 재플래시 없이 OTA 패키지를 통해 업데이트할 수 있습니다. 애플리케이션의 경우 /system 파티션에 액세스할 수 없습니다 — 쓰기를 시도하면 SecurityException이 발생합니다. 그러나 애플리케이션은 적절한 권한이 있는 경우 시스템 글꼴 및 구성 파일과 같은 /system의 일부 파일을 읽을 수 있습니다.

/sdcard 마운트 지점

/sdcard 마운트 지점은 에뮬레이트되거나 물리적 외부 저장소 파티션에 대한 심볼릭 링크입니다. SD 카드가 없는 기기에서 /sdcard는 공유 액세스를 위해 지정된 /data 내의 하위 파티션을 가리킵니다. 이 파티션은 기기가 MTP 프로토콜을 통해 컴퓨터에 연결될 때 사용자에게 표시됩니다. 애플리케이션은 READ_EXTERNAL_STORAGE 및 WRITE_EXTERNAL_STORAGE 권한을 통해 /sdcard에 액세스하며 Android 10부터는 MediaStore API를 사용하는 Scoped Storage를 통해 액세스합니다. /sdcard의 크기는 일반적으로 전체 플래시 메모리의 60~80%이며 나머지는 /data 파티션용으로 예약됩니다.

iOS의 디렉터리 구조

iOS에서 파일 시스템은 애플리케이션의 샌드박스 컨테이너를 통해 구성됩니다. 각 애플리케이션은 XNU 커널 수준에서 액세스가 제한된 격리된 디렉터리를 받습니다. 사용자 파티션은 iOS 10.3에서 도입된 APFS(Apple File System)를 사용합니다. APFS는 스냅샷, 파일 복제 및 파일 수준 암호화를 지원하여 모바일 기기에 최적입니다.

표준 샌드박스 컨테이너 디렉터리

iOS 샌드박스 컨테이너에는 Documents, Library, tmp, SystemData의 네 가지 주요 디렉터리가 포함됩니다. 각 디렉터리에는 고유한 백업 정책, 데이터 보존 기간 및 액세스 수준이 있습니다. Documents는 자동으로 iCloud 및 iTunes 백업에 포함됩니다. Library에는 하위 디렉터리 Caches(백업되지 않음), Preferences(백업됨) 및 Application Support(백업됨)가 포함됩니다. tmp 디렉터리는 저장 공간이 부족할 때 iOS가 삭제할 수 있는 임시 파일용이며 백업에 포함되지 않습니다. SystemData는 시스템 자체에서 사용하며 표준 API를 통해 애플리케이션이 액세스할 수 없습니다.

let fm = FileManager.default

let documents = fm.urls(
    for: .documentDirectory,
    in: .userDomainMask
).first!

let caches = fm.urls(
    for: .cachesDirectory,
    in: .userDomainMask
).first!

let appSupport = fm.urls(
    for: .applicationSupportDirectory,
    in: .userDomainMask
).first!

각 샌드박스 컨테이너 디렉터리에는 고유한 보호 클래스가 있습니다. iOS는 네 가지 클래스를 지원합니다: 완전 보호(기기 잠금 시 파일에 액세스할 수 없음), 열려 있지 않으면 보호(이미 열린 파일은 잠금 상태에서 액세스 가능), 첫 사용자 인증까지 보호(첫 잠금 해제 후 파일에 액세스 가능), 보호 없음(기기 부팅 후 항상 파일에 액세스 가능). 기본적으로 Documents 및 Library의 모든 파일은 완전 보호 클래스를 받아 사용자 데이터의 최대 보호를 보장합니다. 파일 생성 시 백그라운드 애플리케이션이 기기 잠금 중에 데이터에 액세스해야 하는 경우 다른 보호 클래스를 명시적으로 지정할 수 있습니다.

파일 시스템 액세스 권한 및 보안

모바일 기기에서 파일에 대한 액세스 제어는 Android와 iOS의 주요 차이점입니다. Android는 애플리케이션 격리를 위한 확장 기능과 함께 클래식 Linux 권한 모델(읽기, 쓰기, 실행)을 사용합니다. iOS는 더 엄격한 샌드박스 모델을 사용하며 각 애플리케이션은 격리된 컨테이너에서 실행되고 특별한 메커니즘 없이 다른 애플리케이션의 파일에 액세스할 수 없습니다.

Android의 권한

Android에서 각 애플리케이션은 별도의 UID(사용자 ID)로 실행됩니다. 애플리케이션이 샌드박스에서 생성한 모든 파일은 이 UID에 속하며 다른 애플리케이션에 보이지 않습니다. 공유 디렉터리(외부 저장소)에 액세스하려면 애플리케이션이 READ_EXTERNAL_STORAGE 및 WRITE_EXTERNAL_STORAGE 권한을 요청해야 합니다. Android 11부터 권한은 런타임에 요청해야 하며 targetSdkVersion 30+인 애플리케이션은 다른 애플리케이션의 파일에 액세스하기 위해 SAF를 사용해야 합니다. 권한 모델을 위반하면 SecurityException이 발생하며 표준 try-catch 블록으로 처리됩니다. Google Play는 게시 전에 애플리케이션의 권한 정책 준수를 자동으로 확인합니다.

if (ContextCompat.checkSelfPermission(
    context,
    Manifest.permission.READ_EXTERNAL_STORAGE
) != PackageManager.PERMISSION_GRANTED) {
    ActivityCompat.requestPermissions(
        activity,
        arrayOf(Manifest.permission.READ_EXTERNAL_STORAGE),
        REQUEST_CODE
    )
}

iOS 샌드박스 및 키체인

iOS 샌드박스는 XNU 커널 수준에서 구현되며 애플리케이션이 컨테이너를 벗어나는 것을 허용하지 않습니다. 애플리케이션이 Document Picker를 통해 외부 파일 URI에 액세스할 수 있더라도 운영 체제는 원본에 대한 직접 액세스를 제공하는 대신 애플리케이션 컨테이너에 임시 복사본을 생성합니다. 애플리케이션 간 파일 공유를 위해 iOS는 Share Sheet 및 UIActivityViewController 메커니즘을 사용하여 한 애플리케이션의 컨테이너에서 다른 애플리케이션의 컨테이너로 파일을 복사합니다. 자격 증명(토큰, 비밀번호, 키)의 안전한 저장을 위해 iOS는 키체인을 제공합니다 — 커널 수준에서 시스템이 액세스할 수 있는 암호화된 저장소입니다. 키체인은 샌드박스 컨테이너의 일부가 아니며 별도의 securityd 데몬에 의해 관리되어 애플리케이션이 손상된 경우에도 추가 보호 계층을 제공합니다.

파일 시스템 특징: EXT4, APFS, F2FS

파일 시스템의 선택은 저장소 성능과 안정성에 직접적인 영향을 미칩니다. 각 파일 시스템에는 고유한 아키텍처, 최적화 및 제한 사항이 있습니다. 개발자가 이러한 차이점을 이해하면 다양한 기기에서 애플리케이션의 동작을 예측하는 데 도움이 됩니다.

• EXT4 — 저널링이 있는 표준 Linux 파일 시스템으로 최대 16TB 파일과 1EB 볼륨을 지원합니다. F2FS 도입 전 Android의 기본 파일 시스템으로 사용되었습니다. 저널링을 통해 안정성을 제공하지만 각 작업에서 inode 및 블록 비트맵을 업데이트해야 하므로 임의 쓰기 속도에서 F2FS보다 떨어집니다
• F2FS — Samsung이 2012년 NAND 플래시 메모리 전용으로 개발한 파일 시스템입니다. 플래시 어레이 지오메트리를 고려하고 로그 구조화 아키텍처를 사용하여 EXT4 대비 25~40% 더 높은 임의 쓰기 성능을 제공합니다. Android 11부터 Google은 /data 파티션의 기본 파일 시스템으로 F2FS를 권장합니다
• APFS — Apple이 2017년에 도입한 파일 시스템입니다. 스냅샷, 파일 복제(복사-on-쓰기), 파일 수준 암호화 및 체크섬을 통한 엄격한 데이터 무결성 제어를 지원합니다. APFS는 SSD에 최적화되어 있으며 저장소 수명 전반에 걸쳐 성능을 유지하기 위해 TRIM 명령을 사용합니다
• exFAT — SD 카드 및 USB 드라이브에서 사용되는 Microsoft의 파일 시스템입니다. 4GB를 초과하는 파일과 최대 128PB 볼륨을 지원합니다. 저널링이 없으므로 갑작스러운 전원 손실로 인해 데이터가 손상될 수 있습니다. 이동식 미디어에는 권장되지만 시스템 파티션에는 권장되지 않습니다

애플리케이션 개발 시 다른 파일 시스템에는 서로 다른 파일 이름 길이 제한(EXT4 및 F2FS의 경우 255바이트, APFS의 경우 255 Unicode 문자), 최대 파일 크기 및 특수 문자 지원이 있습니다. 예를 들어 APFS는 이모지를 포함한 Unicode 문자를 파일 이름에 허용하지만 EXT4는 ASCII로 제한됩니다. 애플리케이션이 다른 언어의 이름으로 파일을 생성하는 경우 모든 대상 기기에서 테스트하세요 — APFS에서 올바르게 생성된 파일 이름이 EXT4에서 잘릴 수 있습니다.

파일 시스템 작업 권장 사항

모바일 기기 파일 시스템으로 안정적인 작업을 위해서는 몇 가지 주요 규칙을 따라야 합니다. 이는 개발자의 일반적인 실수와 공식 문서의 권장 사항 분석을 기반으로 합니다.

• 디렉터리에 하드코딩된 경로를 사용하지 마세요. 항상 시스템 API를 통해 경로를 얻으세요: Android의 경우 context.filesDir, iOS의 경우 NSSearchPathForDirectoriesInDomains. 하드코딩된 경로는 OS 버전과 기기 간에 변경됩니다
• 파일 작업의 예외를 처리하세요: IOException, FileNotFoundException, SecurityException. iOS에서 모든 FileManager 작업은 오류를 발생시킬 수 있으므로 do-catch로 감싸세요. Android에서 외부 저장소 작업은 미디어 부재로 인해 실패할 수 있습니다
• 쓰기 전에 사용 가능한 공간을 확인하세요. Android에서는 File.getUsableSpace(), iOS에서는 URLResourceValues.volumeAvailableCapacityKey를 사용하세요. 사용 가능한 공간이 부족한 경우 사용자에게 경고하세요
• 백업에 포함되는 디렉터리에 큰 파일을 저장하지 마세요. iOS에서는 isExcludedFromBackup을 사용하여 캐시를 백업에서 제외하세요. Android에서는 임시 파일에 cacheDir을 선호하세요
• 저장소 오버플로 및 갑작스러운 전원 손실 시 동작을 테스트하세요. 트랜잭션 쓰기를 사용하세요: 임시 파일에 쓴 다음 원자적으로 이름을 변경합니다

플랫폼 간 차이점에 특히 주의하세요. Android의 파일 경로는 슬래시(/data/data/.../files/)를 사용하고 iOS는 URL 스키마(file:///var/mobile/.../Documents/)를 사용합니다. 애플리케이션이 플랫폼 간 프레임워크(Flutter, React Native, Kotlin Multiplatform)를 사용하는 경우 플랫폼 어댑터를 통해 파일 작업을 통일하세요. 예를 들어 Flutter는 path_provider 패키지를 제공하여 플랫폼별 코드를 작성하지 않고 두 플랫폼 모두에서 Documents 또는 filesDir에 대한 올바른 경로를 반환합니다. 문자열 작업으로 경로를 연결하지 마세요 — 다른 플랫폼에서 구분 기호를 올바르게 처리하는 File.join() 또는 URL.appendingPathComponent()를 사용하세요.