내장 DB(CoreData)와 외부 DB(FireStore) 모두 프로젝트에 적용한 이유와 마주했던 문제점들

이번 프로젝트 '메모라이징'에서는 데이터를 저장하고 관리하기 위해 내장 DB(CoreData)와 외부 DB(FireStore)를 모두 사용하였습니다. 이는 다음과 같은 이유로 결정되었습니다.

내장 DB(CoreData) 사용 이유

• 오프라인 상태에서도 데이터를 사용할 수 있습니다.
• 앱 자체에서 데이터를 관리하므로, 서버와의 통신이 필요하지 않습니다.
• 데이터를 빠르게 로딩할 수 있습니다.

외부 DB(FireStore) 사용 이유

• 추후 다양한 플랫폼에서 데이터를 공유할 수 있습니다.
• 서버에서 데이터를 관리하므로, 다른 기기에서도 동일한 데이터를 사용할 수 있습니다.

무엇보다 Firebase라는 Cloud 플랫폼을 사용하면서 무분별하게 사용량을 늘렸던 경험이 있었고, 이는 실제로 낭비에 가까운 비용 발생의 주원인이었습니다. 그렇기에 이번 프로젝트에서는 ‘어떻게 하면 네트워크 메서드를 한번이라도 덜 사용할 수 있을까?’ ‘어떻게하면 현재 갖고 있는 데이터만으로 또 다른 Fetch 없이 재활용할 수 있을까?’라는 고민을 많이 했습니다. 그렇게 다양한 해결책을 생각해본 결과 ios의 내장 DB인 CoreData까지 생각하게 되었습니다. 이는 실제로 앱 내부에 존재하던 상당히 많은 Network Fetch 함수들을 없애는 효과를 만들었습니다. 하지만 두 DB를 동시에 사용하면서 발생했던 문제점들 역시 존재했습니다. 

마주한 문제점

동기화 문제

• 내장 DB에서 수정한 데이터를 서버와 동기화하는 과정에서, 불일치 문제가 발생했습니다. 

생각했던 해결 방안들

• 처음으로 생각했던 해결 방안은 Profile Tab에 동기화 버튼을 만들어 주는 것이었습니다. 하지만 이런 수동적인 동기화 방식은 UX가 좋지 않다고 판단하였고, 사용자가 무분별한 서버 사용을 가능하게 하는 수단이기에 조심스러웠습니다. 
• 두 번째 방안은 앱이 재실행될 때 서버와 동기화 하는 것이었습니다. 하지만 이 방식 역시 저희가 원하는 수준의 효과가 없다고 판단하였고, 이러면 굳이 내장 DB를 사용하여 앱의 볼륨을 키우는 것이 맞는가? 하는 고민을 만들었습니다. 
• 마지막으로, 사용자가 로그인할 때 동기화 하는 방안으로 결정했습니다. 비록 이 방식으로 간다면 다중 기기 유저를 제한해야 하는 단점이 있었지만 평소 앱을 사용하며 로그아웃을 자주 하는 사용자가 없을 것이라 판단하여 선택하였습니다. 

느낀점

여전히 해결하지 못 한 문제들이 존재하기에 대단히 만족스럽지는 않지만, 앱을 출시하고 지인분들이 앱을 사용할 때 사용량이 기하 급수적으로 올라가지 않는 것을 보면서 저희의 시도와 고민들이 의미있었구나라는 만족은 있었습니다.