앱 캐시 디렉토리 — 개념, 목적 및 모바일 개발에서 삭제 방법

앱 캐시 디렉토리란?

캐시 디렉토리는 임시 파일을 위해 설계된 애플리케이션의 내부(또는 외부) 메모리에 있는 특수 디렉토리입니다. Internal Storage와의 주요 차이점: 기기의 여유 공간이 부족할 경우 시스템은 통지 없이 캐시에서 파일을 삭제할 권리가 있습니다. 따라서 애플리케이션은 중요한 사용자 데이터의 유일한 복사본을 캐시에 절대 저장해서는 안 됩니다. 캐시는 다운로드한 이미지, 서버 응답, 사전 컴파일된 리소스 및 원격으로 복원하거나 프로그래밍 방식으로 다시 생성할 수 있는 기타 데이터에 최적입니다.

Android에서 캐시 디렉토리는 /data/data/<package>/cache/에 있으며 context.cacheDir을 통해 접근할 수 있습니다. 캐시 크기는 명시적으로 제한되지 않지만 Google Play는 100MB를 초과하지 않도록 권장합니다. 캐시가 큰 앱은 사용자로부터 부정적인 평가를 받기 때문입니다. iOS에서 캐시 디렉토리는 Sandbox 컨테이너 내부의 Library/Caches/에 있으며 NSCachesDirectory를 통해 접근할 수 있습니다. iOS는 기기를 백업에서 복원할 때나 저장 공간이 심각하게 부족할 때 Caches에서 파일을 삭제할 수 있습니다 — 이에 대해 앱 문서에서 사용자에게 알려야 합니다.

어떤 데이터를 안전하게 캐시에 저장할 수 있고 어떤 데이터를 Internal Storage나 Documents에 저장해야 하는지 이해하는 것은 개발자의 핵심 기술입니다. 잘못된 캐시 사용은 두 가지 상반된 문제를 초래합니다: 앱이 너무 많은 공간을 차지하거나(개발자가 Documents에 있어야 할 것을 캐시에 저장한 경우) 사용자가 데이터를 잃는 경우(개발자가 영구적으로 저장해야 할 것을 캐시에 저장한 경우)입니다. 간단한 규칙을 따르세요: 데이터를 복구할 수 있으면 캐시, 복구가 불가능하면 Internal Storage 또는 Documents를 사용하세요.

캐시 데이터의 목적과 유형

데이터 유형에 따라 재생성 속도와 저장 공간 요구 사항이 다릅니다. 이러한 특성을 이해하면 개발자가 어떤 파일을 캐시에 넣고 어떤 파일을 영구 저장소에 넣을지 올바르게 선택하는 데 도움이 됩니다.

이미지 및 미디어 파일 캐시

가장 일반적인 캐시 데이터 유형은 네트워크에서 다운로드한 이미지입니다. Glide, Picasso, Coil과 같은 라이브러리는 다운로드한 이미지를 자동으로 앱의 캐시 디렉토리에 저장합니다. 소셜 앱의 이미지 캐시 일반적인 크기는 50~200MB입니다. 캐시 크기는 기기의 화면 해상도와 조회한 콘텐츠 양에 따라 달라집니다. Glide는 2단계 캐싱을 사용합니다: 먼저 RAM의 L1 캐시(LRU 알고리즘)를 확인한 다음 디스크의 L2 캐시를 확인합니다. 이렇게 하면 추가 네트워크 요청 없이 반복적으로 보는 이미지를 빠르게 로드할 수 있습니다. DiskCacheStrategy를 통해 최대 디스크 캐시 크기를 구성하면 점유 공간을 제어할 수 있습니다: 제한을 초과하면 라이브러리가 자동으로 가장 사용되지 않은 파일을 삭제합니다.

val cacheDir = File(context.cacheDir, "image_cache")
val maxSize = 50 * 1024 * 1024 // 50 MB

val cache = DiskLruCache.open(cacheDir, 1, 1, maxSize)
cache.edit("key")?.let { editor ->
    editor.newOutputStream(0).use { stream ->
        // 캐시에 데이터 쓰기
    }
}

네트워크 요청 캐시

API 요청 응답은 오프라인 액세스 및 서버 부하 감소를 위해 캐시할 수 있습니다. OkHttp는 Cache 클래스를 통해 내장 캐싱 지원을 제공합니다. Cache-Control 및 ETag 응답 헤더는 캐싱 정책을 관리합니다: 서버가 응답의 유효 기간을 지정합니다. 올바른 구성으로 네트워크 요청 캐시는 반복 방문 시 데이터 로딩 시간을 60~80% 줄이고 인터넷 연결 없이 기본 앱 기능을 제공할 수 있습니다. 네트워크 요청 캐시 크기는 10~20MB를 초과하는 경우가 거의 없지만, 많은 사용 시 50MB에 도달할 수 있습니다. OkHttpClient.Builder 생성자를 통해 최대 캐시 크기를 구성하고 앱 시작 시마다 캐시된 데이터의 유효성을 확인하세요.

데이터베이스 및 사전 컴파일된 데이터 캐시

SQLite 데이터베이스는 작동 중에 WAL 파일(Write-Ahead Log), 롤백 저널, 인덱스 페이지 등의 임시 파일을 생성할 수 있습니다. 이러한 파일은 주 데이터베이스와 함께 저장되지만, 임시 데이터베이스(예: 전체 텍스트 검색 또는 분석)의 경우 캐시 디렉토리에 위치를 지정할 수 있습니다. 사전 컴파일된 OpenGL 및 Vulkan 셰이더 프로그램도 이 디렉토리에 캐시되어 그래픽 장면의 첫 로딩을 가속화합니다. iOS에서는 NSCachesDirectory가 사전 컴파일된 Core Data 및 임시 이미지 처리 파일 저장에 권장됩니다.

Android 및 iOS에서 캐시 삭제 작동 방식

캐시 삭제는 자동(시스템에 의해) 또는 수동(사용자 또는 앱에 의해)으로 이루어질 수 있습니다. 다양한 시나리오에서 시스템 동작을 이해하는 것은 데이터 손실을 방지하는 데 필요합니다.

시스템에 의한 자동 캐시 삭제

Android에서 시스템은 /data 파티션의 여유 공간이 임계값(보통 500MB) 아래로 떨어질 때 캐시 삭제 프로세스를 시작합니다. cacheflush 프로세스는 설치된 모든 앱의 캐시 크기를 분석하고 가장 오래된 파일부터 가장 사용되지 않은 파일을 삭제합니다. 사용자는 시스템 설정을 통해 모든 앱의 캐시를 수동으로 삭제할 수도 있습니다: “설정 → 저장소 → 캐시 → 캐시 삭제.” iOS에서 자동 Caches 삭제는 기기를 백업에서 복원할 때 발생합니다 — iOS는 Library/Caches/의 내용을 복원하지 않습니다. 또한 iOS는 여유 공간이 부족할 때 격리된 데이터에 대해 삭제 가능 저장소 메커니즘을 사용하여 Caches에서 파일을 선택적으로 삭제할 수 있습니다.

let fm = FileManager.default
let cachesURL = fm.urls(
    for: .cachesDirectory,
    in: .userDomainMask
).first!

let contents = try fm.contentsOfDirectory(
    at: cachesURL,
    includingPropertiesForKeys: nil
)
for fileURL in contents {
    try fm.removeItem(at: fileURL)
}

앱에 의한 프로그래밍 방식 캐시 삭제

개발자는 사용자 요청이나 일정에 따라 프로그래밍 방식 캐시 삭제를 구현할 수 있습니다. Android에서 자체 캐시를 삭제하려면 context.cacheDir 및 context.externalCacheDir의 모든 파일을 삭제하면 됩니다. iOS에서는 Library/Caches/의 내용을 삭제하되 디렉토리 자체는 삭제하지 마세요 — 내용만 삭제합니다. 앱 설정에서 현재 캐시 크기와 확인 버튼이 있는 “캐시 삭제” 버튼을 사용자에게 표시하는 것이 좋습니다. Google Play Console에 따르면 캐시 삭제 버튼이 있는 앱은 이 기능이 없는 앱보다 저장 공간 부족에 대한 불만이 22% 적습니다. 캐시 삭제는 안전해야 합니다: 앱은 캐시된 파일이 삭제된 상황을 올바르게 처리하고 다음 액세스 시 투명하게 다시 로드해야 합니다.

Android와 iOS의 cacheDir 차이점

동일한 목적에도 불구하고 Android와 iOS의 캐시 디렉토리 구현에는 중요한 차이점이 있습니다. 개발자는 두 플랫폼에서 올바른 앱 작동을 위해 이를 고려해야 합니다.

Android는 context.externalCacheDir을 통해 별도의 외부 캐시 디렉토리를 제공합니다 — SD 카드에 있으며(설치된 경우) 앱을 제거해도 삭제되지 않습니다. 이것은 대용량 미디어 파일에 편리하지만 메모리 카드에 정크를 남길 위험이 있습니다. iOS에는 외부 캐시 개념이 없으며 모든 임시 파일은 Sandbox 컨테이너 내에 저장되고 제거 시 확실히 삭제됩니다. Android에서는 캐시가 앱 설정에서 사용자에게 표시되며 사용자가 수동으로 삭제할 수 있습니다. iOS에서는 시스템 설정이 개별 앱의 캐시 크기를 표시하지 않습니다 — 개발자가 인터페이스에 삭제 버튼을 추가하지 않는 한 사용자는 앱을 삭제하고 다시 설치해야만 캐시를 삭제할 수 있습니다.

중요한 차이점은 복원 시 동작입니다. iOS에서는 iTunes 또는 iCloud 백업에서 복원할 때 Caches 디렉토리가 복원되지 않습니다. iOS는 캐시된 데이터가 첫 번째 실행 시 다시 생성될 것으로 가정하기 때문입니다. Android에서는 Google Drive에서 복원할 때 Internal Storage만 백업됩니다 — 복원 후 캐시는 비어 있습니다. 두 경우 모두 앱은 빈 캐시로 올바르게 작동해야 하며, 사용자에게 오류를 표시하거나 기능을 잃지 않아야 합니다.

캐시 관리 권장 사항

적절한 캐시 관리는 사용자 경험과 앱 평점에 영향을 미치는 요소 중 하나입니다. 다음 권장 사항은 일반적인 문제를 방지하고 사용자 만족도를 높이는 데 도움이 됩니다.

• 캐시 크기 제한을 설정하세요. 최대 용량을 메가바이트 단위로 지정하여 DiskLruCache 또는 유사한 라이브러리를 사용하세요. 제한을 초과하면 라이브러리가 자동으로 가장 사용되지 않은 파일을 삭제합니다
• 앱 설정에 캐시 삭제 버튼을 구현하세요. 현재 캐시 크기(“12.5MB” 형식)를 표시하고 삭제 전에 확인을 요청하세요. 삭제 후 표시된 크기를 업데이트하세요
• 복구할 수 없는 파일은 캐시에 저장하지 마세요. 데이터가 앱 작동에 중요한 경우 Internal Storage(Android) 또는 Documents(iOS)에 저장하고 빠른 액세스를 위한 복사본만 캐시에 두세요
• 쓰기 전에 외부 캐시 가용성을 확인하세요. Android에서는 SD 카드가 설치되지 않았거나 사용할 수 없는 경우 context.externalCacheDir이 null을 반환할 수 있습니다. 항상 내부 캐시로의 폴백을 제공하세요
• 캐시 데이터에 TTL 정책을 사용하세요. 필요한 것보다 오래 파일을 저장하지 마세요: 이미지의 경우 24~48시간, API 응답의 경우 데이터 업데이트 빈도에 따라 5분~1시간

앱 분석에서 캐시 크기를 정기적으로 모니터링하세요. Firebase Analytics 또는 유사한 시스템에 캐시 크기 메트릭 보고를 통합하세요. 평균 캐시 크기가 100MB를 초과하면 캐싱 전략을 최적화하세요: 드물게 사용되는 데이터의 TTL을 줄이고, 캐싱 전 이미지 압축을 구현하고(PNG 대신 WebP, JPEG 품질을 85%로 낮춤), 서버에서 콘텐츠를 로드할 때 페이지네이션을 사용하세요. 16~32GB 기기를 사용하는 사용자는 앱 크기에 특히 민감하다는 점을 기억하세요: 캐시가 200MB에 도달하면 많은 사용자가 삭제 방법을 찾거나 단순히 앱을 삭제합니다. Google 설문 조사에 따르면 38%의 사용자가 통제할 수 없는 캐시 증가와 저장 공간 소비로 인해 하나 이상의 앱을 삭제한 적이 있습니다.