CoreData에 대한 사실과 오해

서정원·2025년 8월 30일
0

백엔드가 있는데, 굳이 코어데이터를 사용할 필요가 있나? 오히려 앱 용량만 늘어나고 안좋은거 아닌가?

라고 저의 건방진 생각이었습니다.. 이번 CoreData를 공부하면서 꼭 넣어야 하는 내용들을 정리할 생각입니다!!

코어데이터는 애플이 코코아 개발 환경을 통해 제공하는 인메모리 방식의 데이터 관리 프레임워크 입니다.
ORM 매핑 프레임워크가 맞는 표현입니다.

인메모리 방식 ?
데이터를 하드디스크가 아닌 컴퓨터의 주기억장치인 RAM에 저장하고 처리하는 기술을 의미합니다. 이 방식은 데이터에 접근하는 속도를 획기적으로 높여 실시간 분석 및 빠른 의사결정을 가능하게 하며, 캐싱, 실시간 데이터 처리, 사용자 세션 관리 등 다양한 분야에서 활용됩니다.

그래서 코어 데이터에서의 데이터를 다루는 모든 작업은 메모리를 기반으로 동작합니다. 코어 데이터를 통해 읽고 쓰는 모든 데이터는 원칙적으로 메모리에 로드된 다음에 처리되기 때문에, 대량의 읽기와 쓰기 작업이 발생하더라도 성능에 크게 영향을 끼치지 않습니다. 대부분의 작업이 영구 저장소에서 직접 처리되고, 효율성을 위해 읽기 목적의 데이터 일부만 메모리에 올려 놓고 사용하는 데이터베이스와는 구분되는 효율적 특성입니다.

그리고 내부적으로 파일이나 SQLite 같은 영구 저장소에 보조적으로 데이터를 저장할 수 있기 때문에, 앱이 종료되도 데이터는 삭제되지 않습니다!

여기까지만 보면 그럼 코어 데이터가 데이터베이스 아닌가? 라고 생각할 수 있지만, 이는 잘못된 생각입니다!


데이터를 영구적으로 보존할 수 있고, 데이터베이스의 데이터 구조를 거의 그대로 사용하고, 검색이나 정렬같은 핵심 쿼리 기능을 모두 지원하기 때문에, 데이터베이스로 오해하는 경우가 많은 것 같습니다.

코어 데이터는 인메모리 방식으로 동작하는 프레임워크 입니다. 사용하려는 모든 데이터는 우선 메모리에 로딩되는 과정을 거친 다음에야 비로소 사용할 수 있고, 데이터를 읽거나 쓰고 수정하며 삭제하는 모든 작업은 메모리에 로딩된 데이터를 대상으로 이루어집니다. 이 방식의 장점으로는 빠른 처리 속도와 성능의 향상을 꼽을 수 있습니다.
온디스크처럼 매번 디스크에 직접 작성하거나 읽어오지 않아도 되기 때문에 상대적으로 I/O가 적게 발생하며, 또한 비즈니스 로직 수행 과정에서 발생하는 데이터의 변경 내역을 모두 메모리 수준에서 처리한 후 최종 결과만 영구 저장소에 반영하면 되기 때문에 여러번 반복해서 읽거나 쓰더라도 성능에 문제는 거의 생기지 않습니다. (물론 인메모리 방식이라 할지라도 코드를 작성하는 방식에 따라 성능 저하는 생길 수 있겠죠?)


코어 데이터의 한계

크게 불편함을 느끼기는 어렵지만, 데이터베이스에 비해 코어 데이터가 마냥 좋은 것만은 아닙니다.

데이터를 메모리에 로딩하는 과정 없이는 작업이 불가능합니다.

데이터베이스에서 일반적으로 데이터를 삭제하거나 업데이트할 때는 특정 조건을 명시한 SQL문이 사용됩니다. 이에 따라 해당 조건에 부합하는 최소한의 데이터만 메모리에 로드한 다음에 필요한 작업을 처리하는데, 이 같은 온 디스크 방식의 특성은 전체 데이터 양이 많더라도 효율적으로 업데이트할 수 있다는 것입니다.
하지만 코어 데이터는 인메모리 방식을 기반으로 동작하는 프레임워크 입니다. 메모리에 로드된 객체에 대해서만 수정이 가능하기 때문에, 먼저 객체를 메모리에 로딩해둬야 합니다. 데이터를 삭제하는 과정 역시 마찬가지입니다.
영구 저장소로 부터 데이터를 잃어 객체로 만들고 이를 메모리에 로딩해 놓은 다음, 이를 삭제하고 다시 컨텍스트를 저장소에 커밋하는 과정을 거쳐야 합니다. 삭제도 마찬가지입니다. 이 같은 과정을 반복되면 메모리 사용량이 늘어나고 이는 성능하락으로 이어질 수 있습니다.

데이터 로직을 다루는 데에 한계가 있습니다.

관계형 데이터베이스에서 데이터의 저장과 관련해 제공하는 기능 중에서 코어 데이터가 지원하지 못하는 것이 있습니다. 동일 테이블에 중복된 값의 입력을 방지하는 Unique 키 입니다. 동일 테이블에 중복된 값의 입력을 방지하는 Unique 키는 주로 주민등록번호 같은 칼럼에 사용되는데, 똑같은 값이 재입력되는 것을 방지하는데 도움을 줍니다. 하지만 Unique키에 해당하는 기능이 제공되지 않기 때문에 중복 값의 입력을 방지하려면 비즈니스 로직 부분에서 처리를 해줘야 합니다.

멀티 쓰레드, 멀티 유저를 지원하지 않습니다.

코어 데이터는 원칙적으로 싱글 쓰레드만 지원합니다. 한 번에 하나의 작업만 처리할 수 있습니다. 하지만 데이터베이스들은 일반적으로 멀티 쓰레드를 지원할 뿐만 아니라 멀티 유저까지 지원합니다.
코어 데이터가 싱글 쓰레드만 지원하는 것은 단일 작업에서 처리 성능을 향상시키기 위함입니다. 멀티 쓰레딩 방식으로 동작할 때는 한쪽에서 작업하고 있는 동안 해당 영역을 다른 쓰레드가 침범하지 못하도록 락을 걸어야 하는데, 이 락은 데이터베이스 성능 저하의 원인이 되기도 합니다.
반대로 말하면 락을 걸지 않음으로 훨씬 빠르게 데이터를 처리할 수 있습니다.

다중 플랫폼 환경에서 어울리지 않는다. (부족한 내용 피드백 받았습니다!)

iOS 앱만 서비스하는 경우 해당되지 않는 케이스지만, 만약 iOS, Android, Web 모두 지원하는 상황이라면, 다른 써드파티 라이브러리를 사용하는 방법이 더 나을 것 같습니다. 데이터 모델과 동작을 통일할 수 있습니다. (기존엔 Realm을 왜써야 되는지 몰랐는데, 이번 케이스를 통해 조금이나마 접근하게 됐습니다.)


그래서 코어 데이터에는 어떤걸 저장해야 되는걸까? 네트워크가 유실되더라도 보여줘야 하는 데이터? 서버에는 보내지 않아도 되는 로컬 데이터? 등등 서비스의 성격에 따라 다르겠지만 이를 유연하게 잘 선택하는 것이 중요할 것 같습니다!

여기까지 코어 데이터에 대해 공부하면서 개인적으로 기록하고 싶은 내용들을 위주로 작성했습니다! 읽어주셔서 감사합니다! 오타 및 잘못된 내용은 언제든 댓글 달아주시면 최대한 빠르게 수정하겠습니다!

profile
개념의 배경에 집중합니다🔥

0개의 댓글