본문 바로가기
감정일기(가칭)

🧩 Core Data 매니저 네이밍, 어떻게 하는 게 좋을까?

by 밤새는 탐험가89 2025. 10. 18.
728x90
SMALL

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 구조로 추상화하는 게 좋아요.

728x90
LIST