LPMetadataProvider로 웹페이지 썸네일 가져오기

Note

본 문서는 LPMetadataProvider로 웹페이지의 imageURL을 가져오지 못하여 이미지를 가져온 후 캐시를 적용하여 발생한 문제의 해결 방법을 작성한 문서입니다.

1. 배경

웹페이지 메타데이터에는 title, url, displayURL, imageURL이 포함된다.
이미지의 경우 LPMetadataProvider로부터 얻은 이미지를 로컬 캐시 디렉토리에 저장하고, 그 로컬 파일 URL(file://) 을 imageURL로 저장하는 구조다.

• 캐시 저장 위치: ~/Library/Caches/webPageImages/<encoded-url>.jpeg
• 저장 로직: WebPageMetadataService.cacheFileURL(for:)

2. 문제 상황

캐시 디렉토리는 iOS가 필요 시 정리할 수 있는 영역이라, 특정 시점 이후 이미지 파일이 없어지는 상황이 발생했다.
이때 Firestore에 저장된 imageURL은 여전히 로컬 file URL을 가리키기 때문에, 뷰에서 이미지가 표시되지 않는 문제가 발생했다.

문제 현상 요약:

• imageURL이 유효한 file URL이지만 URL을 따라가면 이미지 파일이 없음
• UI에서 이미지가 표시되지 않음

3. 원인 분석

현재 구조에서 imageURL은 로컬 캐시 파일의 URL을 그대로 저장한다. 캐시가 삭제되면:

• imageURL은 그대로 남아 있음
• 실제 파일은 존재하지 않음
• UI에서 이미지 로딩 실패

즉, 캐시 무효화에 대한 복구 흐름이 없음이 핵심 원인이었다.

4. 해결 방향

"이미지 복구 후 뷰에 즉시 반영"을 위해 과도한 알림/상태 업데이트를 도입하는 대신, fetch 시점에서 캐시 유무를 확인하고, 없으면 즉시 복구하는 방식으로 정리했다.

핵심 원칙:

• fetch 결과가 반환될 때는 이미 복구된 imageURL을 포함
• 불필요한 Notification/State 갱신 로직 사용 금지

5. 현재 해결 구현

Step 1) fetch 시점에서 캐시 상태 확인

WebPageRepositoryImpl.fetch(_:)에서 가져온 WebPageResponse를 순회하며 다음을 검사:

• imageURL이 비어 있지 않음
• imageURL이 file URL
• 해당 파일이 실제로 존재하지 않음

Step 2) 캐시 복구 및 저장 갱신

캐시가 없으면 아래 과정을 수행:

1. WebPageMetadataService.fetchMetadata(from:)로 메타데이터 재수집
2. 이미지 파일을 캐시에 다시 저장
3. 새 imageURL로 Firestore에 upsert
4. 복구된 메타데이터로 WebPage 생성

Step 3) fetch 결과로 즉시 반환

복구가 성공하면 복구된 WebPage를 바로 반환하고, 실패하면 기존 데이터로 fallback한다.

이로써 뷰는 추가 갱신 없이 복구된 imageURL을 받게 되고, 이미지가 정상 표시된다.

6. 트레이드오프

• 장점: UI 반영 로직을 단순화하고 일관된 fetch 결과를 제공
• 단점: fetch 호출 시 캐시 복구가 포함되어 UI가 느리게 뜸

7. 결론

현재 구조는 로컬 캐시 기반 이미지 저장을 유지하면서도, 캐시 누락 문제를 fetch 단계에서 해결하는 방식으로 정리되었다.
불필요한 알림/상태 업데이트 없이도 안정적으로 이미지가 다시 표시된다.