🔄 Core Data + Firebase(Firestore) 동기화 구조 설계

🎯 목표

온라인 상태 → Firestore ↔ Core Data 양방향 동기화

오프라인 상태 → Core Data에만 임시 저장

다음 연결 시 → Core Data 변경분을 Firestore에 자동 업로드

Firestore 최신 데이터는 Core Data에 자동 반영

---

1️⃣ 왜 Core Data와 Firestore를 함께 써야 할까?

방식	설명	단점
🔹 Firebase(Firestore)만 사용	클라우드 중심, 실시간 데이터 공유 가능	인터넷이 없으면 저장 불가
🔹 Core Data만 사용	완전 오프라인 저장 가능	여러 기기 간 데이터 동기화 불가

 

👉 그래서 이 두 가지를 하이브리드 형태로 결합하면,
오프라인 안정성 + 온라인 동기화를 동시에 얻을 수 있습니다.

---

2️⃣ 전체 데이터 흐름 개요

아래는 Core Data와 Firestore를 함께 쓰는 전체 구조입니다.

┌──────────────┐
│   Firestore  │
│  (클라우드 DB) │
└──────┬───────┘
       │  ⬆⬇ (Sync)
       │
┌──────┴───────┐
│   Core Data  │
│   (로컬 데이터) │
└──────┬───────┘
       │  ⬆⬇
       │
┌──────┴───────┐
│     앱 UI     │
│ (EmotionDiary)│
└──────────────┘

 

 

앱은 항상 Core Data를 우선으로 읽고/쓰기 합니다.

Core Data에 저장된 변경사항은 이후 Firebase와 동기화(Sync) 됩니다.

---

3️⃣ Sync 구조 설계

Firestore와 Core Data를 동기화하기 위해
각 데이터에 다음 메타 필드를 추가하는 것이 중요합니다.

 

필드명	설명
id	고유 식별자 (UUID)
isSynced	동기화 여부 (Firestore 업로드 완료 여부)
updatedAt	마지막 수정 시각
deletedAt (선택)	삭제 예약 여부

 

이 필드들이 있으면 다음을 쉽게 구현할 수 있습니다 👇

 

1. 오프라인 상태에서 수정/삭제를 임시 보관

2. 온라인 전환 시 isSynced = false 인 데이터만 업로드

3. Firestore 최신 데이터를 받아 Core Data 갱신

struct EmotionDiary: Identifiable, Codable {
    var id: String
    var emotion: EmotionType
    var content: String
    var imageURL: String?
    var createdAt: Date
    var updatedAt: Date
    var isSynced: Bool = false
}

---

4️⃣ Conflict(충돌) 해결 전략

Firestore와 Core Data 간에 같은 데이터가 다르게 수정될 수 있습니다.
이때 가장 단순하고 효과적인 기준은 최종 수정 시각(updatedAt) 우선 원칙입니다.

상황	처리 방식
Core Data가 최신	Firestore 덮어쓰기
Firestore가 최신	Core Data 덮어쓰기
동일	무시 (변화 없음)