Room의 기술적 정의

1. Executive Summary (핵심 요약)

Room: 안드로이드 표준 로컬 DB 솔루션(Jetpack). SQLite의 추상화 계층(ORM)으로, 2025년 현재 **Kotlin Multiplatform(KMP)**까지 공식 지원하며 iOS/Desktop까지 커버리지가 확장되었습니다.
SQLite: 안드로이드 OS에 내장된 로컬 DB 엔진. Room이 내부적으로 사용하는 기술이지만, 직접(Raw) 사용하는 것은 생산성과 안정성 면에서 비권장됩니다.
Realm (MongoDB): [중요] 도입 금지 권고. 2024년 9월, MongoDB가 **Realm SDK 및 Atlas Device Sync의 서비스 종료(EOL)**를 발표했습니다. 2025년 9월부로 지원이 완전히 종료되므로 신규 프로젝트에는 절대 사용해서는 안 됩니다.

Room은 구글이 제공하는 Jetpack 라이브러리의 일부로, SQLite 위에서 동작하는 ORM(Object Relational Mapping) 기술입니다.

역할: 개발자가 복잡한 SQL 쿼리와 커서(Cursor) 관리를 직접 하지 않도록 돕는 **추상화 레이어(Abstraction Layer)**입니다.
특징:
- 컴파일 타임 검증: SQL 쿼리 문법이 틀리면 컴파일 단계에서 에러를 잡아줍니다(런타임 크래시 방지).
- 비동기 통합: Kotlin Coroutines(Flow, Suspend function) 및 RxJava와 완벽하게 통합됩니다.
- 최신 트렌드 (KMP): Room 2.7/2.8 버전부터 Kotlin Multiplatform을 지원하여, 안드로이드와 iOS가 동일한 DB 로직을 공유할 수 있게 되었습니다.kmpship

Room은 SQLite를 대체하는 새로운 엔진이 아니라, **SQLite를 더 쓰기 쉽게 만든 래퍼(Wrapper)**입니다.

비교 항목	SQLite (Raw)	Room (Jetpack)
추상화 수준	Low-level API (`SQLiteOpenHelper`)	High-level ORM (`@Dao`, `@Entity`)
쿼리 검증	런타임에 확인 (오타 나면 앱 실행 중 죽음)	컴파일 타임에 확인 (빌드 시 에러 발생)
데이터 매핑	`Cursor` 객체를 순회하며 수동으로 매핑	DTO/Entity 객체로 자동 매핑 반환
Boilerplate	매우 많음 (DB 버전 관리, 매핑 코드 등)	매우 적음 (Annotation 기반)
비동기 처리	직접 스레드 관리 필요 (Handler, Executor)	Coroutines/Flow 리턴 타입 지원으로 자동 처리
마이그레이션	`onUpgrade`에서 쿼리 직접 작성	`Migration` 클래스로 체계적 관리 및 테스트 지원

코드 비교 (생산성 차이):

SQLite: cursor.getColumnIndex("id") 등을 사용해 컬럼 하나하나 타입을 맞춰 꺼내야 함.
Room: interface UserDao { @Query("SELECT * FROM user") fun getAll(): Flow<List<User>> } 한 줄로 끝.

질문하신 **”Realm 지금은 MongoDB?”**에 대한 대답은 **”MongoDB가 인수했으나, 이제 제품을 죽이고 있다”**입니다. 이 부분이 기술 선정 시 가장 리스크가 큰 부분입니다.

과거: Realm은 빠르고 사용하기 쉬운 모바일 NoSQL DB로 인기를 끌었습니다.
인수: MongoDB가 Realm을 인수하여 “MongoDB Realm” -> “Atlas Device SDKs”로 리브랜딩했습니다.
현재 (Critical): 2024년 9월, MongoDB는 Atlas Device Sync와 Realm SDK(Device SDKs)의 개발 중단(Deprecation)을 공식 발표했습니다.loopcafe.substack+1

종료 일정: 2025년 9월 30일부로 클라우드 싱크(Atlas Device Sync) 및 공식 SDK 지원이 종료(End of Life)됩니다.
영향:
- 클라우드 동기화: 완전히 사라집니다. 대체제가 필요합니다.
- 로컬 DB: 오픈소스(Community Edition)로 남을 수는 있으나, MongoDB 측의 메인 엔지니어링 지원이 끊긴 상태입니다. 기업용 프로덕트에 “유지보수 주체가 사라진 DB”를 쓰는 것은 보안 및 OS 업데이트 대응 측면에서 치명적입니다.
결론: 기존에 Realm을 사용 중이라면 **마이그레이션(Room 또는 ObjectBox 등)**을 계획해야 하며, 신규 프로젝트에는 도입하지 말아야 합니다.

CTO/엔지니어링 매니저 관점에서 기술 스택을 결정하신다면 다음과 같이 권장해 드립니다.

표준 (Standard): 무조건 Room을 사용하십시오. 구글의 퍼스트 파티 지원, 안정성, KMP 확장을 고려할 때 가장 안전한 선택입니다.
생산성 (Migration): 만약 기존 프로젝트가 순수 SQLite Cursor를 쓰고 있다면 Room으로 점진적 리팩토링(Migration)을 하십시오. 유지보수 비용이 급격히 줄어듭니다.
위험 관리 (Avoid): **Realm(MongoDB SDK)**은 선택지에서 지우셔야 합니다. 이미 EOL 카운트다운이 시작되었습니다.
대안 (Alternatives): 만약 Room(SQL)이 아닌 NoSQL 방식이나 빠른 속도가 반드시 필요하다면 ObjectBox 같은 대안이 있으나, 생태계 크기를 고려할 때 Room이 압도적으로 유리합니다.

한 줄 결론:

“안드로이드 로컬 DB는 Room이 사실상의 표준이며, Realm은 서비스 종료 예정이므로 사용해서는 안 됩니다.”