10 · 파일 시스템과 I/O

← 챕터 목록

파일 시스템과 I/O는 "저장은 그냥 되는 것"처럼 보이지만, 실제로는 어느 스레드에서·얼마나·어디에·어떻게 원자적으로 읽고 쓰느냐가 앱의 반응성과 데이터 무결성을 좌우합니다. 이 챕터는 그 네 축을 iOS 관점에서 정리합니다.

Q1. 동기 파일 I/O를 Main Thread에서 수행하면 왜 문제가 되는가?

CS 원리

blocking I/O는 syscall로 커널에 진입한 뒤, 원하는 데이터가 커널의 페이지 캐시에 있으면 즉시(마이크로초) 복사해 돌아오지만, 없으면 프로세스를 sleep 상태로 두고 저장장치 I/O가 끝날 때까지 그 스레드를 다른 일에 쓸 수 없게 만듭니다. UI 프레임워크는 본질적으로 이벤트 루프 모델이라, 이 루프를 도는 스레드가 한 번 블록되면 그 시간만큼 입력·타이머·화면 갱신 콜백이 통째로 밀립니다. 문제의 핵심은 "느리다"가 아니라 지연이 예측 불가능하고, 하필 프레임을 그려야 하는 스레드를 붙잡는다는 점입니다.

iOS에서는

Foundation의 Data(contentsOf:), String(contentsOf:), FileHandle.readData 등은 결국 Darwin/XNU의 BSD VFS 계층에서 read(2)/pread(2) 같은 blocking syscall로 내려갑니다. 메인 스레드에서는 CoreAnimation의 커밋(CATransaction)이 CFRunLoop 위에서 돌기 때문에, 런루프가 블록되면 그 프레임의 레이어 변경이 화면에 올라가지 못해 정지처럼 보입니다. 게다가 Data Protection으로 암호화된 파일은 기기가 잠겨 있으면(파일의 보호 클래스에 따라) 접근 자체가 지연·실패할 수 있어 메인 스레드 블로킹이 더 위험합니다. 앱 시작·재개 등 특정 국면에서 이 지연이 임계치(국면마다 다르며 앱 시작은 통상 20초 안팎으로 알려져 있으나 Apple이 공식 수치를 명시하지는 않습니다)를 넘으면 SpringBoard의 watchdog이 SIGKILL을 보내고, 크래시 로그에 exception code 0x8badf00d("ate bad food")가 찍힙니다(이 코드는 TN2151에 정리돼 있습니다).

실험 · 도구

재현은 간단합니다. 수십 MB 파일을 스크롤 콜백 안에서 동기로 읽게 만들고 스크롤하면, Instruments의 Time Profiler에서 메인 스레드 스택에 I/O 함수가 잡히고 Animation Hitches(os_signpost)로 프레임 드랍이 보입니다. Xcode 스킴의 Thread Performance Checker를 켜면 메인 스레드에서의 디스크 접근을 런타임 경고로 잡아 줍니다. 코드 레벨에서는 I/O 진입 직전에 스레드를 강제로 검증하는 게 가장 빠른 조기 발견 수단입니다.

// 파일 I/O 앞에 두면 메인에서 호출될 때 즉시 크래시로 잡힌다
dispatchPrecondition(condition: .notOnQueue(.main))

// ❌ 나쁨: 스크롤 콜백에서 동기 읽기 → 런루프 정지
func scrollViewDidScroll(_ sv: UIScrollView) {
    let data = try? Data(contentsOf: bigFileURL)   // 메인에서 블록
}

// ✅ 좋음: 전용 백그라운드에서 I/O, 결과만 메인으로 hop
Task.detached(priority: .utility) {
    let data = try Data(contentsOf: bigFileURL)
    await MainActor.run { self.apply(data) }
}

프로젝트 적용

• 모든 파일 I/O는 백그라운드(Task.detached/전용 큐/전용 actor)에서 하고, UI 갱신 값만 MainActor로 넘긴다.
• 큰 blob을 UserDefaults에 넣지 않는다 — 내부적으로 plist 파일을 동기로 다시 쓰기 때문에 메인 스레드 I/O가 숨어든다.
• viewDidLoad·cellForRowAt·스크롤 콜백 안에서의 동기 읽기는 금지. 필요하면 미리 로드해 캐시한다.

꼬리 질문

• 백그라운드로 옮겼는데도 hitch가 남는다면 어디를 의심해야 하나?
• watchdog 타임아웃이 앱 시작·재개·종료 국면마다 다른 이유는?
• Swift Concurrency에는 진짜 async 파일 API가 있나? 없다면 blocking I/O를 어떻게 감싸야 하나?

Q2. Data(contentsOf:)가 대용량 파일에서 위험한 이유는 무엇인가?

CS 원리

파일을 메모리로 가져오는 방식은 크게 둘입니다. (1) 복사 로드: read syscall로 사용자 버퍼에 내용을 복사 — 파일 크기만큼 상주 메모리를 차지하고 시간도 O(파일 크기). (2) 메모리 매핑(mmap): 파일을 프로세스의 가상 주소 공간에 매핑만 해 두고, 실제 물리 페이지는 해당 주소를 접근할 때(page fault) lazy하게 올립니다. 매핑된 페이지 중 수정하지 않은(clean) 것은 원본이 디스크에 그대로 있으므로, 메모리 압박 시 커널이 그냥 버렸다가 다시 필요할 때 fault로 재로딩할 수 있습니다. 즉 mmap은 "가상 공간은 크게, 물리 메모리는 접근한 만큼만"이 핵심입니다.

iOS에서는

Data(contentsOf:options:)의 ReadingOptions에서 .mappedIfSafe(안전할 때 매핑)·.alwaysMapped(강제 매핑)를 줄 수 있습니다. iOS 메모리 관리는 앱 메모리를 디스크로 스왑하지 않고 메모리 압축만 사용하며, 메모리 압박이 오면 jetsam이 우선순위(포그라운드/백그라운드)에 따라 프로세스를 강제 종료합니다. 포그라운드 앱도 기기별 하드 리밋을 넘으면 EXC_RESOURCE/jetsam으로 죽습니다. 매핑된 clean 페이지는 재확보 가능해 footprint 계산에 유리하지만, 쓰기로 dirty가 되거나 무작위로 전부 touch하면 결국 물리 메모리에 올라옵니다. 남은 메모리 예산은 os_proc_available_memory()로 확인할 수 있습니다.

실험 · 도구

100MB 이상 파일을 옵션 없이 vs .mappedIfSafe로 읽고, Instruments의 Allocations와 VM Tracker에서 resident/footprint를 비교하면 차이가 바로 드러납니다. Xcode Memory Report의 그래프로도 급증이 관찰됩니다. 스트리밍 처리는 상수 메모리로 큰 파일을 소화하는 정석입니다.

// ❌ 파일 크기만큼 힙에 상주
let all = try Data(contentsOf: url)

// ✅ 안전하면 메모리 매핑 — 접근한 페이지만 올라옴
let mapped = try Data(contentsOf: url, options: .mappedIfSafe)

// ✅ 청크 스트리밍 — 상수 메모리로 처리
let handle = try FileHandle(forReadingFrom: url)
defer { try? handle.close() }
while let chunk = try handle.read(upToCount: 1 << 20), !chunk.isEmpty {
    process(chunk)                 // 1MB씩만 메모리에
}

// 남은 메모리 예산(바이트) 확인
let budget = os_proc_available_memory()

프로젝트 적용

• 비디오·대형 DB·로그처럼 큰 파일은 절대 전체 로드하지 말고 스트리밍하거나 매핑한다.
• 대용량 JSON은 JSONDecoder(전체 Data 요구)가 위험 — 라인/스트리밍 파서를 쓰거나 애초에 포맷을 나눈다.
• mmap한 파일은 도중에 다른 주체가 truncate/변경하면 접근 시 SIGBUS로 죽는다. 네트워크 볼륨 등 신뢰할 수 없는 위치는 매핑하지 않는다.

꼬리 질문

• 매핑한 파일을 다른 프로세스가 truncate하면 무슨 일이 일어나나?
• 100MB JSON을 파싱해야 한다면 어떤 전략을 택하겠나?
• jetsam 리밋은 기기·포그라운드 여부에 따라 어떻게 달라지나?

Q3. Documents, Library, Caches, tmp 디렉터리는 어떻게 구분하는가?

CS 원리

여러 OS가 공유하는 관례입니다. "사용자 문서 / 애플리케이션 상태 / 캐시 / 임시"를 폴더로 구분하고, 그 폴더가 곧 백업 정책과 purge 정책을 결정합니다(리눅스의 XDG Base Directory와 같은 발상). 개발자가 데이터의 성격을 올바른 폴더로 표현하면, 백업·정리·복원 같은 시스템 동작이 자동으로 맞게 흘러갑니다.

iOS에서는

FileManager로 각 위치를 얻습니다. iCloud/Finder 백업은 Documents와 Library(단, Caches 제외)를 포함하고, Caches와 tmp는 제외합니다. Documents 안이라도 재생성 가능한 큰 파일은 QA1719가 안내하듯 isExcludedFromBackup으로 개별 제외해야 합니다 — 안 하면 백업이 비대해져 리뷰 리젝 사유가 됩니다. UIFileSharingEnabled를 켜면 Documents가 Files 앱/Finder에 노출됩니다. Application Support 폴더는 기본 생성되어 있지 않아 create: true로 만들어 써야 합니다.

실험 · 도구

시뮬레이터에서 각 URL을 찍어 실제 컨테이너 경로를 열어 보면 구조가 손에 잡힙니다. 백업 제외 플래그는 URLResourceValues로 파일 단위로 설정합니다.

let fm = FileManager.default

let docs   = try fm.url(for: .documentDirectory,          in: .userDomainMask, appropriateFor: nil, create: false)
let appSup = try fm.url(for: .applicationSupportDirectory, in: .userDomainMask, appropriateFor: nil, create: true)
let caches = try fm.url(for: .cachesDirectory,            in: .userDomainMask, appropriateFor: nil, create: false)
let tmp    = fm.temporaryDirectory

// Documents 안에 재생성 가능한 큰 파일을 둘 때: 백업에서 제외 (미설정 시 리젝 사유)
var url = docs.appendingPathComponent("cache.bin")
var values = URLResourceValues()
values.isExcludedFromBackup = true
try url.setResourceValues(values)

프로젝트 적용

• SQLite/Core Data 스토어 같은 영구 앱 상태 → Application Support.
• 네트워크에서 다시 받을 수 있는 이미지·응답 캐시 → Caches(또는 Documents + isExcludedFromBackup).
• 유일본인 사용자 데이터를 tmp·Caches에 두지 않는다 — 어느 순간 사라져 복구 불가가 된다.

꼬리 질문

• App Group 공유 컨테이너는 이 네 폴더와 무엇이 다른가?
• iCloud Documents(ubiquity container)에 두면 백업/동기화가 어떻게 달라지나?
• 앱을 삭제 후 재설치하면 이 폴더들 중 무엇이 남아 있나?

Q4. 파일 쓰기 중 앱이 종료되어도 데이터가 깨지지 않게 하려면 어떻게 하는가?

CS 원리

여기서 지켜야 할 성질은 두 가지로 나뉩니다. 원자성(atomicity)은 "부분 상태가 관찰되지 않음"이고, 지속성(durability)은 "커밋했다고 본 데이터가 전원 손실 후에도 남아 있음"입니다. temp에 쓰고 rename(tmp, dest)하면, 디렉터리 엔트리 교체가 원자적이라 원자성이 확보됩니다. 다만 rename만으로는 데이터가 아직 페이지 캐시에만 있을 수 있어, 전원이 꺼지면 사라질 수 있습니다. 그래서 순서가 중요합니다 — 데이터 fsync → rename → 디렉터리 fsync. 또한 원인을 구분해야 합니다. 앱 프로세스만 죽는 crash면 커널 페이지 캐시가 살아 있어 rename만으로 충분하지만, 커널 패닉·전원 손실이면 fsync가 필요합니다. 저널링/WAL을 쓰는 DB는 이 로그 선기록으로 원자성과 지속성을 함께 보장합니다.

실험 · 도구

쓰기 도중 프로세스를 강제로 죽여(kill -9 또는 디버거에서 중단) 목적지 파일의 무결성을 확인하면 두 방식의 차이가 명확합니다. fs_usage로 syscall을 추적하면 .atomic 경로가 실제로 aux 파일 생성 후 rename을 부르는 것을 볼 수 있습니다. 진짜 durability가 필요하면 아래처럼 F_FULLFSYNC를 직접 부릅니다.

func atomicWriteDurable(_ data: Data, to dest: URL) throws {
    let dir = dest.deletingLastPathComponent()
    let tmp = dir.appendingPathComponent(".tmp-" + UUID().uuidString)  // 반드시 같은 볼륨

    // 1) tmp 파일에 전부 write
    FileManager.default.createFile(atPath: tmp.path, contents: nil)
    let fh = try FileHandle(forWritingTo: tmp)
    try fh.write(contentsOf: data)

    // 2) 디스크 매체까지 강제 flush — 전원 손실 대비 (fsync보다 강한 F_FULLFSYNC)
    if fcntl(fh.fileDescriptor, F_FULLFSYNC) == -1 { throw POSIXError(.EIO) }
    try fh.close()

    // 3) 원자적 교체: 이 지점 전에 죽으면 dest = 구버전 전체, 후면 신버전 전체
    //    (교체 자체의 지속성까지 필요하면 상위 디렉터리 fd도 fsync)
    _ = try FileManager.default.replaceItemAt(dest, withItemAt: tmp)
}

프로젝트 적용

• 단순 단일 파일 갱신은 Data.write(to:options:.atomic)로 충분하다. 금융·과금처럼 손실이 치명적이면 F_FULLFSYNC까지 건다.
• 여러 파일이 함께 일관돼야 하면 개별 원자적 쓰기로는 부족하다 — SQLite 트랜잭션(또는 Core Data)으로 묶는다.
• 매우 큰 파일에 무조건 .atomic을 쓰지 않는다 — 임시본 복사로 순간 디스크 사용량이 두 배가 되고, 원본의 권한·확장속성을 잃을 수 있다(replaceItemAt은 이를 보존).

꼬리 질문

• fsync와 F_FULLFSYNC는 무엇이 다른가? 왜 Apple은 후자를 권하나?
• 두 개의 파일을 동시에 일관되게 바꿔야 한다면 어떻게 설계하나?
• rename이 서로 다른 볼륨을 넘으면(cross-device) 왜 더 이상 원자적이지 않나?

Q5. Atomic write란 무엇인가?

CS 원리

원자성은 "all-or-nothing, 부분 관찰 불가"라는 성질입니다. 제자리 write는 여러 블록·여러 syscall로 나뉘어 진행되므로, 중간에 죽거나 그 순간 다른 쪽이 읽으면 반쪽 상태가 관찰됩니다. 반면 rename(2)은 같은 파일시스템 안에서 원자적이라, 이걸 이용해 "완성된 새 파일"을 한 번에 목적지 이름에 붙입니다. 여기서 데이터베이스 ACID 용어를 빌려 구분하면 명확합니다 — 원자성(찢어짐 방지), 지속성(전원 손실 후 유지), 격리(동시 접근 일관성)는 서로 독립입니다. rename은 원자적이지만 fsync가 없으면 지속적이지 않고, 파일 하나에 대한 원자성일 뿐 여러 파일 묶음의 원자성은 트랜잭션이 있어야 합니다.

iOS에서는

Data.write(to:options:.atomic), String.write(to:atomically:encoding:) 등이 내부적으로 원본과 같은 디렉터리에 보조(aux) 파일을 만들어 쓰고 rename으로 교체합니다. 같은 디렉터리를 쓰는 이유는 rename이 같은 볼륨에서만 원자적이기 때문입니다. 다른 프로세스·App Extension·Files 앱과 함께 접근한다면 NSFileCoordinator로 조율해 원자적 관찰을 보장해야 합니다. APFS는 copy-on-write 파일시스템으로 메타데이터 갱신을 crash-safe하게 처리하지만, 파일 교체의 원자성은 여전히 rename 기반이라는 점은 동일합니다.

// 내부적으로 aux 파일에 write 후 rename — 반쪽 파일이 관찰되지 않는다
try data.write(to: url, options: .atomic)

// 문자열/레거시 컬렉션도 동일한 원자적 옵션 제공
try text.write(to: url, atomically: true, encoding: .utf8)

// 주의: .atomic 은 '원자성'만 보장.
// 전원 손실 후 유지(지속성)는 별개 → Q4의 F_FULLFSYNC가 필요.

프로젝트 적용

• 설정·문서·직렬화 결과 저장은 .atomic을 기본으로 둔다.
• 이미 mmap/열린 fd로 참조 중인 파일을 원자적으로 교체하면, 그 참조는 옛 inode를 계속 가리킨다는 점을 알아 둔다.
• 같은 큰 파일을 아주 자주 원자적으로 쓰면 매번 전체 복사가 일어나 write amplification과 플래시 수명에 불리하다.

꼬리 질문

• 원자적 쓰기를 했는데도 데이터가 사라질 수 있는 시나리오는 무엇인가?
• 열린 fd나 mmap이 걸려 있는 파일을 원자적으로 교체하면 그 핸들은 무엇을 보나?
• 디렉터리(여러 파일)를 통째로 원자적으로 교체하려면 어떤 방법이 있나?

출처 · 참고자료