🧩 Core Data에서 여러 이미지를 저장하는 두 가지 방법 비교

“Transformable로 배열을 통째로 저장할까?”
“아니면 별도의 Entity를 만들어 관계로 관리할까?”

이 두 접근 방식은 목적은 같지만, 동작 원리와 확장성은 전혀 다릅니다.

---

🔹 1️⃣ 두 가지 접근 방식

Core Data로 “여러 이미지를 저장”하려고 할 때 가장 먼저 마주치는 선택지가 바로 이 두 가지입니다.

 

1. Transformable 타입으로 [String] 배열을 통째로 저장하는 방법

2. 별도의 DiaryImageEntity를 만들어 1:N 관계로 연결하는 방법

 

두 방식 모두 “여러 장의 이미지 경로를 관리한다”는 점에서는 같지만,
데이터 구조, 관리 방식, 그리고 확장성 측면에서는 완전히 다르게 동작합니다.

---

🔹 2️⃣ 방식 ① Transformable로 [String] 배열 저장

class EmotionDiaryEntity: NSManagedObject {
    @NSManaged var id: UUID
    @NSManaged var emotion: String
    @NSManaged var content: String
    @NSManaged var createdAt: Date
    @NSManaged var imagePaths: [String]?   // Transformable 타입
}

 

이 방식은 단순히 이미지 경로들을 배열 형태로 묶어서
한 칸짜리 컬럼(Blob 데이터) 으로 Core Data에 저장하는 형태입니다.

Core Data 내부에서는 이 [String] 배열을 직렬화(encode)하여
하나의 바이너리 덩어리로 보관합니다.

 

✅ 장점

1. 구현이 매우 간단합니다.
2. Entity 하나에 [String] 속성만 추가하면 끝.

3. 작은 앱이나 간단한 데이터에서는 빠르게 적용할 수 있습니다.

 

⚠️ 단점

1. 데이터 수정 시 전체 배열을 다시 저장해야 합니다.
[String] 중 하나만 바꿔도 전체 배열이 재직렬화됩니다.

2. 각 이미지에 대한 개별 관리가 불가능합니다.
Core Data는 배열 요소를 “객체”로 인식하지 않기 때문에
특정 이미지를 삭제하거나, 순서를 바꾸거나, 메타데이터를 추가하기 어렵습니다.

3. 확장성 부족.
나중에 이미지에 추가 속성(썸네일, 위치, 태그 등)을 붙이고 싶어도 불가능합니다.

---

✅ 정리하자면, Transformable 방식은 “단순하고 빠르게 저장할 때만” 적합합니다.
데이터 구조가 커지거나 장기적으로 관리가 필요한 경우에는 유지보수가 어렵습니다.

---

🔹 3️⃣ 방식 ② DiaryImageEntity를 만들어 1:N 관계로 연결

class EmotionDiaryEntity: NSManagedObject {
    @NSManaged var id: UUID
    @NSManaged var emotion: String
    @NSManaged var content: String
    @NSManaged var createdAt: Date
    @NSManaged var images: NSSet?    // To-Many 관계 (DiaryImageEntity)
}

class DiaryImageEntity: NSManagedObject {
    @NSManaged var id: UUID
    @NSManaged var imagePath: String
    @NSManaged var diary: EmotionDiaryEntity?   // To-One 관계
}

 

이 방식은 Core Data의 진짜 강점을 살리는 구조입니다.

이미지를 하나의 “별도 엔티티”로 관리하고,
일기(EmotionDiaryEntity)와 이미지를 “1:N 관계”로 연결하는 것입니다.

 

✅ 장점

1. 관계형 관리가 가능합니다.
일기를 삭제하면 연결된 이미지들도 자동으로 삭제(Cascade)됩니다.

2. 이미지별 개별 관리가 쉬움.
특정 이미지만 수정하거나, 추가 정보를 부여하기도 쉽습니다.

3. 확장성 높음.
나중에 DiaryImageEntity에 날짜, 위치, 태그, 썸네일 등 다양한 속성을 붙일 수 있습니다.

4. 성능적으로도 효율적.
Core Data는 관계를 통해 필요한 데이터만 메모리에 로드하므로,
데이터가 많아져도 안정적으로 동작합니다.

 

⚠️ 단점

1. 초기 설계가 다소 복잡합니다.
2. 관계 설정, FetchRequest, Delete Rule 설정 등 추가 작업이 필요합니다.

3. 아주 단순한 앱에서는 구조가 약간 과할 수 있습니다.

---

✅ 정리하자면, 1:N 관계 구조는 “확장성과 관리가 필요한 앱”에 적합합니다.
일기처럼 데이터가 누적되고, 이미지가 많아지는 구조에는 훨씬 안전하고 유연합니다.

---

🔹 4️⃣ 두 방식을 비교해보면

항목	Transformable [String]	관계형 DiaryImageEntity
저장 방식	배열 전체를 직렬화하여 하나로 저장	각 이미지를 별도 엔티티로 저장
구조	단순	관계형, 체계적
수정 시	배열 전체 재저장	개별 이미지 수정 가능
삭제 시	수동 관리 필요	Cascade 자동 처리 가능
확장성	낮음	매우 높음
추천 상황	간단한 앱, 임시 데이터	✅ 장기 저장, 이미지 다수, 유지보수 필요한 앱

---

🔹 5️⃣ 어떤 방식을 써야 할까?

간단한 테스트 앱
→ Transformable [String]으로 충분합니다.

 

감정일기, 앨범, 포토 다이어리처럼 이미지가 누적되는 앱
→ ✅ 별도의 DiaryImageEntity를 두고 1:N 관계로 관리하는 것이 정석입니다.