Caches Directory: 캐시 관리 및 데이터 정리

iOS에서 Caches Directory란?

Caches Directory는 iOS 애플리케이션 샌드박스 내부의 디렉토리로, 필요시 복원할 수 있는 데이터를 저장하도록 최적화되어 있습니다. Documents Directory와 달리 Caches는 사용자 데이터를 위한 것이 아니며, 애플리케이션 성능을 향상시키기 위한 임시 저장소입니다.

iOS는 Caches Directory를 사용하여 캐시된 네트워크 응답, 사전 로드된 이미지, 직렬화된 객체 및 애플리케이션이 복원할 수 있는 데이터를 저장합니다. 개발자는 이 디렉토리의 장기 데이터 저장소에 의존해서는 안 됩니다.

Apple WWDC 2020에 따르면, 약 40%의 iOS 애플리케이션이 캐시된 이미지와 네트워크 데이터를 저장하는 데 Caches Directory를 사용하는 반면, 25%의 개발자는 이러한 디렉토리 간의 차이를 이해하지 못해 Documents나 Application Support에 있어야 할 데이터를 잘못 Caches에 배치하고 있습니다.

Caches의 중요한 특성: 시스템이 캐시 파일을 삭제한 상황을 애플리케이션이 적절히 처리해야 합니다. 캐시를 제거했을 때 애플리케이션 기능이 손상된다면 데이터가 잘못된 디렉토리에 저장된 것입니다.

Caches Directory 경로 얻는 방법

Swift에서는 .cachesDirectory와 함께 표준 FileManager 메서드를 사용하여 Caches Directory 경로를 얻습니다. 이는 네트워크 데이터로 작업하는 거의 모든 iOS 애플리케이션에서 사용되는 간단한 작업입니다.

import Foundation

let fileManager = FileManager.default
guard let cachesURL = fileManager.urls(
    for: .cachesDirectory,
    in: .userDomainMask
).first else { return }

// Save cached JSON
let cacheFile = cachesURL.appendingPathComponent("feed_cache.json")
let jsonData = try JSONSerialization.data(
    withJSONObject: response,
    options: [.prettyPrinted]
)
try jsonData.write(to: cacheFile)

Objective-C는 NSCachesDirectory와 함께 NSSearchPathForDirectoriesInDomains를 사용합니다. Apple이 Swift API를 권장하지만, Caches Directory를 사용하는 Objective-C 코드는 계속 작동하고 지원됩니다.

@import Foundation;

NSArray *paths = NSSearchPathForDirectoriesInDomains(
    NSCachesDirectory,
    NSUserDomainMask,
    YES
);
NSString *cachesPath = paths.firstObject;
NSString *cacheFile = [cachesPath stringByAppendingPathComponent:@"feed_cache.plist"];

Swift 프로젝트는 URL 기반 API를 선호해야 합니다. 이는 타입 안전하며 SwiftUI 및 Combine과 같은 현대적인 프레임워크와 더 잘 통합됩니다.

Caches에 저장할 데이터

Caches Directory는 애플리케이션이 성능을 향상시키기 위해 사용하는 여러 범주의 데이터에 최적이지만, 유일한 정보 소스는 아닙니다. 캐싱에 적합한 데이터를 선택하는 것은 UX와 애플리케이션 성능에 직접적인 영향을 미칩니다.

캐시된 네트워크 응답

API의 JSON 응답, 뉴스 피드 데이터, 객체 목록 등 애플리케이션이 서버에서 다시 다운로드할 수 있는 모든 것. HTTP 응답의 자동 캐싱에는 URLCache를 사용하거나 직렬화된 객체를 수동으로 저장하세요.

이미지 및 미디어 파일

네트워크에서 다운로드된 이미지는 Caches Directory의 가장 일반적인 사용 사례입니다. SDWebImage 및 Kingfisher와 같은 라이브러리는 기본적으로 캐시된 이미지를 Caches에 저장합니다.

데이터를 복원할 수 없다면 Caches에 속하지 않습니다. 이것이 가장 간단한 기준입니다: 내일 시스템이 Caches에서 모든 파일을 삭제한다고 상상해보세요. 애플리케이션이 계속 올바르게 작동한다면 데이터가 적절히 저장된 것입니다.

시스템이 캐시 정리를 관리하는 방법

iOS는 자동으로 Caches Directory 정리를 관리하지만, 정확한 트리거와 알고리즘은 Apple에 의해 문서화되지 않았습니다. 디스크 공간이 부족할 때와 Offload Unused Apps 기능이 활성화될 때 시스템이 Caches에서 파일을 삭제할 수 있는 것으로 알려져 있습니다.

정리 프로세스는 애플리케이션에 투명합니다. 시스템은 알림 없이 파일을 삭제합니다. 애플리케이션은 읽기 전에 파일 존재 여부를 확인하고 없으면 다시 생성해야 합니다. 장기 저장소에 의존하지 않는 것이 Caches 작업 시 핵심 요구 사항입니다.

Apple의 문서 “File System Basics”(2024)에 따르면, 애플리케이션은 Caches Directory의 파일이 세션 간에 사용 가능할 것으로 기대해서는 안 됩니다. 개발자는 폴백 메커니즘을 구현하는 것이 좋습니다: 캐시된 파일이 없으면 네트워크에서 데이터를 다운로드하여 Caches에 다시 저장합니다.

별도의 시나리오는 앱 오프로드입니다. 이 기능이 활성화되면 iOS는 애플리케이션을 제거하지만 Documents Directory는 유지합니다. 이 과정에서 Caches Directory는 삭제됩니다. 애플리케이션을 복원한 사용자는 캐시된 데이터를 얻을 수 없으며, 애플리케이션이 다시 다운로드해야 합니다.

Caches Directory와 Temporary Directory 비교

Caches와 Temporary (tmp) 디렉토리의 차이점은 개발자들 사이에서 종종 혼란을 야기합니다. 두 디렉토리 모두 임시 데이터를 저장하지만, 수명 보장과 목적이 다릅니다.

앱 실행 간 데이터를 유지하는 것이 유용하지만 복원 가능한 경우 Caches를 선택하세요. 데이터가 현재 세션에서만 필요하고 앱 종료 후 가치가 없는 경우 tmp를 사용하세요.

Caches 작업 모범 사례

Caches Directory로 작업하려면 데이터 손실, 예기치 않은 애플리케이션 동작 및 성능 문제를 방지하는 몇 가지 규칙을 따라야 합니다.

읽기 전에 항상 파일 존재 여부 확인

FileManager.fileExists(atPath:)는 Caches에서 읽을 때마다 호출해야 합니다. 파일이 없으면 원본 소스에서 데이터를 로드하여 캐시에 저장하세요. Caches에 파일이 존재한다고 가정하지 마십시오.

캐시 크기 제한

앱에서 Caches Directory의 최대 크기를 설정하세요. 예를 들어, 이미지는 50MB, JSON 응답은 10MB로 제한합니다. 제한을 초과하면 수정 날짜를 기준으로 가장 오래된 파일을 삭제합니다.

import Foundation

func trimCache(to maxSizeBytes: Int) {
    let cachesURL = FileManager.default
        .urls(for: .cachesDirectory, in: .userDomainMask)
        .first!

    guard let enumerator = FileManager.default
        .enumerator(
            at: cachesURL,
            includingPropertiesForKeys: [.fileSizeKey, .contentModificationDateKey]
        )
    else { return }

    // Enumerate and remove old files
    // when exceeding size limit
}

이러한 방법을 따르면 시스템 캐시 정리 작업에 관계없이 애플리케이션이 올바르게 작동하며 사용자가 예기치 않은 데이터 손실을 겪지 않습니다.