iOS 개발을 하다 보면 거의 필수적으로 사용하는 게 바로 Core Data죠.
그런데 막상 Core Data를 다루는 클래스를 만들다 보면 이런 이름을 많이 짓습니다 👇
final class CoreDataManager { ... }
겉보기엔 아무 문제 없어 보이지만,
앱이 점점 커지기 시작하면 이 이름이 너무 포괄적이라는 문제가 생깁니다.
😵💫 왜 CoreDataManager는 모호할까?
처음엔 단 하나의 엔티티만 다루니까 괜찮습니다.
하지만 앱 규모가 커지고, Core Data를 여러 도메인에서 사용하기 시작하면…
“이 매니저가 감정일기를 관리하는 건지,카테고리를 관리하는 건지,아니면 사용자 프로필을 저장하는 건지…”
구분이 안 되기 시작합니다.
결국 나중에는 “CoreDataManager.swift” 파일 하나가
모든 엔티티의 CRUD를 한데 모은 괴물 파일이 되어버리죠 😅
✨ 그래서 중요한 건 “도메인 중심 네이밍”
즉, 무엇을 관리하는 Core Data 매니저인지
이름만 봐도 알 수 있게 만드는 게 핵심이에요.
🧭 실제 프로젝트에서 자주 쓰는 네이밍 패턴
| 패턴 예시 | 이름 | 설명 |
| 🧱 도메인 + CoreDataManager | DiaryCoreDataManager | 감정일기 전용 Core Data 매니저 (가장 깔끔하고 직관적) |
| 📘 도메인 + DataManager | EmotionDiaryDataManager | 기술 의존성(Core Data)을 숨기고 싶을 때 |
| 🗃️ 도메인 + Repository | DiaryRepository | ViewModel에서 데이터 레이어 추상화할 때 (Clean Architecture 용) |
| 🧩 도메인 + Persistence | EmotionDiaryPersistence | 데이터 지속성(Persistence Layer)을 표현하고 싶을 때 |
🧠 네이밍 선택 기준
✅ 1️⃣ Manager로 끝나는 경우
Core Data의 직접 제어 및 관리 로직이 들어갈 때
- 예: saveDiary(), updateDiary(), deleteDiary() 같은 CRUD 함수
- Core Data의 context를 직접 다룸
- FileManager나 LogManager처럼 “작업을 수행하는 역할”일 때 적합
👉 추천:
final class DiaryCoreDataManager { ... }
✅ 2️⃣ Repository로 끝나는 경우
ViewModel이나 UseCase에서 “데이터 소스”로 추상화할 때
- Core Data 외에 Firebase, API, CloudKit 같은 저장소와도 연동 가능
- 나중에 DiaryRepository → RemoteDiaryRepository 로 교체하기 쉬움
👉 예시:
protocol DiaryRepository {
func fetchDiaries() -> [EmotionDiaryModel]
func saveDiary(_ model: EmotionDiaryModel)
}
final class CoreDataDiaryRepository: DiaryRepository {
private let manager = DiaryCoreDataManager.shared
func fetchDiaries() -> [EmotionDiaryModel] { ... }
}
⚖️ 어떤 게 더 좋은가?
| 비교 | 항목 | Manager Repository |
| 설명력 | 단일 기능(저장/불러오기) 명확 | 추상화된 데이터 레이어 표현 |
| 의존성 | Core Data 직접 의존 | Core Data 숨김 (유연함 ↑) |
| 확장성 | 단일 앱 내부용에 적합 | 여러 데이터 소스 연동 시 적합 |
| 난이도 | 구현 간단 | 설계는 복잡하지만 유지보수 유리 |
👉 정리하자면:
지금처럼 Core Data만 사용하는 개인 앱 / 단일 도메인 앱이라면
➜ DiaryCoreDataManager 로 충분합니다 ✅
나중에 Firebase나 API 연동 계획이 있다면
➜ DiaryRepository 구조로 추상화하는 게 좋아요.
'감정일기(가칭)' 카테고리의 다른 글
| 📚 DiaryCoreDataManager 내부 구조 완전 정리 (0) | 2025.10.18 |
|---|---|
| ☁️ Core Data에서 Firebase로 확장하는 iOS 데이터 구조 설계 (0) | 2025.10.18 |
| 📒 감정일기 앱의 데이터 로딩 전략 설계 — 동기 로딩 vs 점진적 로딩(Pagination) (0) | 2025.10.17 |
| 🚀 현실적인 iOS 데이터 로딩 전략 — Core Data와 Pagination(페이징) 이야기 (0) | 2025.10.17 |
| 🪵 개발/배포 환경을 구분한 로깅 설계 (0) | 2025.10.17 |