Kingfisher(0): 이미지 로딩/캐시/동시성 “필수 개념” 정리

Intro

Kingfisher 코드를 보기 전에, 먼저 머릿속 개념을 정리하려고 한다.

이미지 로딩은 겉으로는 단순하다.

• 내려받고(Network)
• 해석하고(Decode)
• 보여준다(Display)

그런데 앱이 느려지는 순간은 거의 항상 여기서 시작한다.

• 네트워크가 흔들리거나
• 디코딩이 누적되거나
• 표시 타이밍(UI)이 밀리거나

그래서 이미지 캐시는 “편의 기능”이 아니라, 실무에서 성능과 안정성을 지탱하는 설계가 된다.

---

1. 이미지 로딩의 비용 모델

이미지는 결국 이 순서로 돈을 쓴다.

• Network: 외부 환경에 따라 변동이 크다.
• Decode: 고정비에 가깝고, 생각보다 비싸다.
• Display: UI 타이밍(스크롤, 리스트)과 맞물리면 체감이 커진다.

결국 이미지 처리를 위해 네트워크만 줄인다고 끝이 아니다.
디코딩/표시 비용까지 같이 줄여야 “진짜 빠른 프로세스”가 된다.

1-1. 그래서 캐시(Cache)를 도입한다

비용이 큰 작업을 매번 반복하면, 앱은 느려질 수밖에 없다.
그래서 이미지 로딩에서는 자연스럽게 캐시(cache) 라는 개념이 등장한다.

- 캐시란 무엇인가?

캐시는 한 문장으로 정의할 수 있다.

비싼 작업의 결과를 저장해두고, 다음에 같은 요청이 오면 재사용하는 것.

 

이미지 로딩에서 “비싼 작업”은 보통 이 두 가지다.

• 네트워크 다운로드(지연/변동)
• 디코딩(고정비/누적)

캐시가 있으면, 한 번의 다운로드/디코딩 결과를 재사용하면서
“같은 이미지를 보여주기 위해 치르는 총 비용”을 줄일 수 있다.

 

하지만 캐시는 공짜가 아니다.

캐시는 공간(메모리/디스크) 을 써서 시간을 사는 구조다.

즉, 캐시를 도입하는 순간부터 정책과 동시성이 따라온다.

---

2. 2단 캐시: Memory → Disk → Network

이미지 요청이 들어오면, 캐싱 흐름은 거의 이렇게 흐른다.

요청
  → 메모리 캐시 확인 (hit면 즉시 반환)
  → miss면 디스크 캐시 확인 (hit면 메모리에 올리고 반환)
  → miss면 네트워크 다운로드
      → 디코딩
      → 메모리 + 디스크 저장
      → 반환

 

이 구조의 핵심은 “속도”만이 아니다.

• 메모리 캐시는 가장 빠르다
• 디스크 캐시는 가장 오래 산다
• 네트워크는 가장 불안정하다

즉, 2단 캐시는 속도 / 지속성 / 복구를 분리해서 가져가는 선택이다.

---

3. Memory vs Disk

둘 다 캐시지만, 저장 형태가 다르다.

- 메모리 캐시: 객체(인스턴스) 그대로

바로 꺼내서 쓰는 형태(예: UIImage)로 저장한다.
즉, 메모리 캐시 hit = 즉시 사용 가능에 가깝다.

- 디스크 캐시: 직렬화된 Data/bytes

파일로 저장하려면 UIImage → Data가 필요하고,
다시 읽으면 Data → UIImage가 필요하다.

let data = image.pngData()!
try data.write(to: fileURL)

let loaded = try Data(contentsOf: fileURL)
let image = UIImage(data: loaded)

여기서 중요한 포인트는

Disk hit은 Network miss일 뿐, “비용 0”이 아니다.
(읽기 I/O + Data → Image 변환 비용은 남는다)

 

---

4. Decoding vs Serialization

이 둘을 섞어 말하면 캐시 설계가 흐려진다.

• 직렬화(Serialization): UIImage → Data
  저장/전송 가능한 바이트 형태로 변환
• 디코딩(Decoding): Data → 렌더링 가능한 이미지 표현
  화면에 그릴 수 있도록 내부 표현(픽셀 준비 포함)으로 준비

디스크 캐시는 보통 Data를 저장한다.
그래서 디스크에서 꺼내는 순간에도, 다시 비용이 생길 수 있다.

• 객체 생성 비용
• 디코딩 비용(또는 그에 준하는 준비 비용)

즉,

• Disk hit = “네트워크 비용을 피했다”
• Disk hit ≠ “디코딩 비용이 사라졌다”

---

5. 캐시는 정책이다

캐시는 무한하지 않다.
그래서 저장을 시작하면 곧바로 정책이 필요해진다.

• Eviction(교체): 공간이 부족할 때 무엇을 버릴지
• Expiration(만료): 언제까지 유효한지
• Cleanup(정리): 언제 실제로 삭제할지

여기서 트레이드오프가 생긴다.

• 정확하게 관리할수록 → 메타데이터/연산/동기화 비용이 오른다
• 단순하게 할수록 → 예측 가능성/정합성이 떨어질 수 있다

---

6.  iOS에서 캐시가 ‘저장소’가 아닌 이유

여기까지 오면 이런 생각이 든다.

“캐시는 그냥 메모리에 저장하면 되는 거 아냐?”

하지만 iOS에서는 메모리가 한정되어 있고, OS가 강하게 개입한다.

즉, 캐시는 “내가 잡고 있으면 유지되는 저장소” 가 아니다.

캐시의 전제는 보통 아래와 같다.

있으면 빠르다. 하지만 없어져도 안전해야 한다. (best-effort)

 

그래서 Apple은 캐시를 “정확한 저장소”로 만들기보다는,
캐시에 맞는 컨테이너를 제공한다. 그 대표가 NSCache다.

---

7.  NSCache

NSCache는 이름 그대로 캐시 용도로 설계된 컨테이너다.

 

여기서 관점은 하나만 기억하면 된다.

NSCache는 ‘정확한 저장소’가 아니라, ‘버려져도 안전한 캐시’에 가깝다.

즉, 캐시 miss를 기본 전제로 설계해야 한다.

그리고 NSCache가 “캐시 컨테이너”로 자주 쓰이는 이유는 보통 아래 성질 때문이다.

• 메모리 상황에 따라 캐시가 자동으로 비워질 수 있는(eviction) 방향으로 설계되어 있고
• 기본적인 set/get/remove는 각 메서드 호출 단위에서 멀티 스레드 접근을 허용하도록 설계되어 있다. (Thread Safe)
• 키를 copy하지 않는다

이제 이 “키를 copy하지 않는다”가 왜 중요한지 보자.

7-1. (Deep) NSCache는 key를 copy하지 않고 retain 한다

NSCache는 NSMutableDictionary와 다르게, 키를 copy하지 않는다.

즉, 넣은 키 객체를 그대로 retain(참조 유지) 한다.

이게 왜 중요할까?

• 키가 mutable(변할 수 있는) 참조 타입이고
• 키의 동등성/해시에 영향을 주는 값이 바뀌면
• 캐시 hit/miss가 꼬일 수 있다

그래서 실제 NSCache를 사용할 때는 보통 키로 불변(immutable) 객체를 쓴다.
(대표적으로 NSString)

---

8. 키는 왜 보통 NSString인가

여기서 Swift 사용자들이 항상 마주치는 제약이 하나 나온다.

NSCache<KeyType, ObjectType>의 KeyType/ObjectType은 클래스 타입(AnyObject) 이어야 한다.

 

Swift의 String은 값 타입(struct) 이다.
그래서 String을 NSCache의 key 타입으로 직접 쓸 수 없고 보통 이렇게 많이 쓴다.

let cache = NSCache<NSString, UIImage>()
cache.setObject(image, forKey: key as NSString)

 

정리하면,

• NSCache는 키를 copy하지 않고 retain 한다
  → 키는 “불변”이 안전하다
• NSCache는 키 타입이 AnyObject(클래스) 여야 한다
  → Swift String은 직접 못 쓰고 NSString으로 브리징한다

다시 말해, NSCache는 제네릭 제약이 AnyObject라서 Swift 값 타입은 그대로 Key/Object로 사용할 수 없다.
그래서 Key는 NSString처럼 클래스 타입으로 브리징/구성해서 쓰는 경우가 많다.

---

9. Thread-safe ≠ Atomic

NSCache는 기본 API가 멀티 스레드에서도 쓸 수 있게 설계되어 있다.

그럼 동시성 문제는 끝일까?

여기서부터 ‘원자성(atomicity)’ 문제가 시작된다.

여기서 핵심은 이거다.

• NSCache가 보장하는 건 보통 단일 메서드 호출 단위의 안전성
• 실무에서 깨지는 건 복합 로직 단위(원자성)

9-1. check-then-act가 깨지는 이유 (중복 work)

if cache.object(forKey: k) == nil {          // check
    cache.setObject(makeValue(), forKey: k)  // act
}

만약 서로 다른 스레드에서 동시에 check를 진행해서 둘 다 “nil”이라고 판단하면,

• Thread A도 makeValue()를 실행하고
• Thread B도 makeValue()를 실행한다.

즉, “한 번만 만들고 싶었던 값 생성 작업”이 중복으로 수행될 수 있다.

그리고 둘 다 setObject를 호출하면,
캐시 입장에서는 같은 key에 대해 마지막에 set된 값으로 덮어써질 뿐이지만,

이미 비싼 작업(다운로드/디코딩/가공)은 두 번 수행된 뒤다.

 

즉, 중간에 다른 스레드가 끼면 “한 번만 만들기” 같은 의도(원자성) 가 깨지고,
결과보다 더 큰 문제로 중복 비용이 발생한다.

9-2. NSCache + 메타데이터를 붙이는 순간, 원자성이 필요해진다

실전 캐시는 NSCache만 쓰지 않는다.

• 만료 시간
• lastAccessed
• keys 목록
• cost/size 추적

이런 상태 정보를 갖는 순간 캐시는
“캐시 + 상태(메타데이터)” 를 동시에 고려해야 하는 상태가 된다.

그때부터는 단순히 thread-safe가 아니라,
NSCache 업데이트와 메타데이터 업데이트를 한 덩어리로 묶는 설계(원자성) 가 필요해진다.

---

10. 만료(Expiration)와 정리(Cleanup)

만료는 보통 두 가지 기준으로 잡는다.

• TTL(Time To Live): 생성 시점 기준
• lastAccessed: 마지막 접근 시점 기준

그리고 삭제(정리) 타이밍은 보통 3가지로 나뉜다.

• 접근 시 정리: 읽을 때 만료면 삭제
• 주기적 정리: 백그라운드/타이머 기반
• 혼합: 둘을 섞어서 운영

여기서도 트레이드오프가 있다.

• 접근 시 정리: 단순하지만 “접근 순간”이 무거워질 수 있음
• 주기적 정리: 부하를 분산하지만 스케줄링/동기화가 필요함

---

11. Jetsam: 캐시 miss가 기본인 이유

iOS에서 메모리는 “내가 잡는다고 유지되는 자원”이 아니다.

메모리 압박이 오면,

• 캐시는 비워질 수 있고
• 심하면 앱이 종료될 수 있다 (Jetsam)

그래서 메모리 캐시의 전제는 이렇게 바뀐다.

“캐시 hit을 기대하되, miss를 기본으로 설계한다.”

 

그리고 디스크 캐시의 의미는 여기서 커진다.

• 메모리가 날아가도
• 앱이 재시작해도
• 복구 비용을 낮출 수 있기 때문

---

마무리

이미지 캐시는 단순히 “저장해두고 재사용”에서 끝나지 않는다.

네트워크/디코딩/표시라는 비용 모델 위에서,

2단 구조(Memory/Disk) 와 정책(Eviction/Expiration/Cleanup) 을 설계해야 하고,

그 과정에서 동시성(원자성)과 iOS의 메모리 압박(Jetsam) 이라는 현실을 같이 끌어안게 된다.

 

이번 정리의 결론은 하나다.

캐시는 ‘정확한 저장소’가 아니라, ‘깨져도 안전해야 하는 최적화 레이어’다.

그래서 캐시를 쓸 때는 항상 이렇게 질문해야 한다.

• 지금 줄이려는 비용은 무엇인가? (Network / Decode / Display)
• 이 최적화는 어떤 비용을 새로 만들었는가? (공간 / 정책 / 동기화)
• 그리고 OS가 개입했을 때도 안전한가? (eviction / Jetsam)

이제 다음 글에서는 Kingfisher가 어떻게 이런 개념, 문제 상황 등을 고려하고 어떤 식으로 해결했는지에 대해서 학습하면 된다.
이 질문들이 실제 구현에서 어떤 형태로 드러나는지 확인해보려고 한다.