오프라인 및 기기 기능을 위한 Jetpack Compose vs React Native

정말 비교하고 있는 것은 무엇인가요

사람들이 “기기 기능”이라고 말할 때 보통 카메라 캡처, GPS, 블루투스 스캔, 푸시 알림, 파일 접근(다운로드, PDF, 첨부파일), 걸음 수나 네트워크 상태 같은 백그라운드 작업처럼 폰 자체와 연동되는 부분을 뜻합니다. 핵심 질문은 “할 수 있나?”가 아니라 “하드웨어로 가는 경로가 얼마나 직접적인가, 그리고 기기와 OS 버전 전반에서 얼마나 예측 가능한가”입니다.

오프라인 모드는 문제를 완전히 다르게 만듭니다. 단순히 “인터넷 없이 동작”이라는 스위치가 아닙니다. 로컬 저장, 어떤 데이터가 오래되어도 괜찮한지에 대한 명확한 판단, 그리고 변경 충돌이 일어났을 때의 규칙(예: 사용자가 오프라인 상태에서 주문을 수정했는데 서버에서 같은 주문이 업데이트된 경우)을 설계해야 합니다. 동기화를 추가하면 단순한 화면 설계가 아니라 작은 시스템을 설계하는 것입니다.

Compose vs React Native는 종종 네이티브 대 크로스 플랫폼으로 프레이밍되지만, 오프라인과 기기 관련 작업에서는 경계(흠집)에서 차이가 드러납니다: 당신이 의존하는 브리지, 플러그인, 꼼수의 수와, 특정 모델의 폰에서 문제가 발생했을 때 디버그가 얼마나 쉬운가입니다.

“성능”도 사용자 관점에서 정의되어야 합니다: 시작 시간, 스크롤과 타이핑(특히 긴 리스트와 폼에서), 배터리와 발열(백그라운드에서 조용히 전력을 소모하는 작업), 안정성(크래시, 정지, UI 글리치). 두 쪽 모두 훌륭한 앱을 낼 수 있습니다. 트레이드오프는 당신이 어디에 확실성을 원하느냐입니다: OS 수준의 더 촘촘한 제어, 아니면 가장자리에서 더 많은 움직이는 부품이 있는 하나의 코드베이스.

기기 접근: 내부 구조의 차이

여기서 큰 차이는 UI 위젯이 아니라 앱이 카메라, 블루투스, 위치, 파일, 백그라운드 서비스에 어떻게 닿느냐입니다.

안드로이드에서 Jetpack Compose는 UI 레이어일 뿐입니다. 코드는 여전히 일반 Android SDK와 기존의 네이티브 라이브러리를 사용합니다. 기기 기능 접근은 직접적입니다: Android API를 호출하고 권한을 처리하며 SDK를 번역 계층 없이 통합합니다. 스캐너나 MDM 도구 같은 벤더가 Android용 라이브러리를 제공하면 보통 바로 추가해 사용할 수 있습니다.

React Native는 대부분의 앱 로직을 JavaScript로 실행하므로 기기 접근은 네이티브 모듈을 통해 이루어집니다. 모듈은 기기 기능을 JavaScript에 노출하는 Android(Kotlin/Java)와 iOS(Swift/Obj-C) 쪽의 작은 코드 조각입니다. 많은 일반 기능은 기존 모듈로 커버되지만 네이티브와 JavaScript 사이에서 데이터를 전달하기 위해 브리지(또는 최신 JSI/TurboModules 접근)를 의존합니다.

커버되지 않은 기능을 만날 때 경로는 갈라집니다. Compose에서는 네이티브 코드를 더 많이 씁니다. React Native에서는 커스텀 네이티브 모듈을 만들어 두 플랫폼을 유지보수해야 합니다. 그래서 ‘크로스플랫폼을 선택했다’가 조용히 ‘이제 세 개의 코드베이스가 생겼다: JS, Android 네이티브, iOS 네이티브’가 되는 경우가 있습니다.

요구사항이 커질 때 팀 적합도를 실용적으로 생각하는 방법:

• 이미 강한 Android 역량이 있거나 깊은 Android 통합이 예상되면 Compose가 더 적합한 경향이 있습니다.
• 팀이 JavaScript에 강하고 기기 요구가 일반적이면 React Native가 더 적합합니다.
• 어느 쪽이든 백그라운드 서비스, 특수 하드웨어, 엄격한 오프라인 규칙이 필요하다면 네이티브 작업을 계획하세요.

실전 성능: 사용자가 체감하는 부분

체감 차이는 앱이 열릴 때, 화면을 이동할 때, 사용자가 계속 탭하는 동안 UI가 작업을 수행할 때 주로 드러납니다.

시작 시간과 화면 전환은 Compose가 전체적으로 네이티브이고 앱의 나머지 런타임과 같은 환경에서 실행되기 때문에 보통 더 빠르게 유지하기가 쉽습니다. React Native도 매우 빠를 수 있지만 콜드 스타트는 JS 엔진과 번들 로딩 같은 추가 설정을 포함하는 경우가 많습니다. 앱이 무겁거나 빌드가 최적화되지 않으면 작은 지연이 더 잘 발생합니다.

부하가 걸렸을 때의 응답성도 중요합니다. 큰 JSON을 파싱하거나 긴 리스트를 필터링하거나 폼 합계를 계산할 때 Compose 앱은 대개 Kotlin 코루틴으로 작업을 분산시켜 메인 스레드를 비워 둡니다. React Native에서는 JS 스레드를 막는 작업은 탭과 애니메이션을 ‘끈적거리게’ 만들 수 있으므로, 무거운 작업을 네이티브 코드로 옮기거나 작업을 신중히 예약해야 합니다.

스크롤은 사용자가 가장 먼저 불평하는 곳입니다. Compose는 LazyColumn 같은 네이티브 리스트 도구를 제공해 항목을 가상화하고 메모리를 잘 재사용합니다(올바르게 작성된 경우). React Native는 FlatList 같은 컴포넌트를 사용하며, 이미지 크기, 항목 키, 재렌더링을 주의해 스터터를 피해야 합니다.

배터리와 백그라운드 작업은 보통 동기화 방식에 따라 달라집니다. 안드로이드에서는 Compose 앱이 WorkManager 같은 플랫폼 도구를 활용해 예측 가능한 스케줄링을 할 수 있습니다. React Native에서는 백그라운드 동기화가 네이티브 모듈과 OS 제한에 의존하기 때문에 기기와 설정에 따라 신뢰성이 더 다양합니다. 공격적인 폴링은 양쪽에서 배터리를 소모합니다.

성능이 가장 큰 위험이라면 먼저 ‘문제 화면’ 하나를 만들어 보세요: 가장 무거운 리스트와 실제 데이터 볼륨을 가진 오프라인 폼 하나. 플래그십이 아니라 중급 기기에서 측정하세요.

오프라인 모드 기초: 데이터 저장과 상태

오프라인 모드는 주로 데이터의 문제이지 UI의 문제는 아닙니다. 어떤 UI 스택을 선택하든 핵심은 기기에 무엇을 저장할지, 오프라인일 때 UI가 무엇을 보여줄지, 그리고 나중에 변경을 어떻게 조정할지 결정하는 것입니다.

로컬 저장: 적절한 도구를 선택하세요

간단한 규칙: 중요한 사용자가 만든 데이터는 임시 키-값 필드가 아니라 실제 데이터베이스에 저장하세요.

주문, 품목, 고객, 드래프트처럼 쿼리하고 정렬해야 하는 구조화된 데이터는 데이터베이스에 넣고, 튜토리얼을 본 여부 같은 작은 설정은 키-값 저장소를 사용하며, 사진, PDF, 캐시된 내보내기, 큰 첨부파일은 파일로 관리하세요.

Compose 환경의 안드로이드에서는 팀들이 보통 Room이나 다른 SQLite 기반 옵션과 작은 키-값 저장소를 사용합니다. React Native에서는 보통 SQLite/Realm 스타일 저장소 라이브러리를 추가하고 설정용으로는 AsyncStorage/MMKV 유사한 별도 키-값 저장소를 둡니다.

오프라인 우선 흐름: 로컬을 소스 오브 트루스로 다루기

오프라인 우선은 생성/편집/삭제가 먼저 로컬에서 일어나고 나중에 동기화되는 패턴입니다. 실무적인 패턴은: 로컬 DB에 쓰고, UI는 로컬 DB에서 업데이트하며, 가능한 경우 백그라운드에서 서버로 푸시하는 것입니다. 예를 들어 영업 사원이 비행기에서 주문을 수정하면 목록에서 즉시 보고, 앱은 동기화 작업을 큐에 넣어 나중에 실행합니다.

충돌은 같은 레코드가 두 기기에서 변경되었을 때 발생합니다. 흔한 전략은 last-write-wins(간단하지만 데이터 손실 가능), 병합(메모 같은 추가 필드에 좋음), 또는 사용자 검토(가격이나 수량처럼 정확도가 중요할 때 최선)입니다.

혼란스러운 버그를 피하려면 “진실”을 명확히 정의하세요:

• UI 상태는 임시입니다(사용자가 지금 입력 중인 것).
• 저장된 상태는 내구성이 있습니다(충돌 후나 크래시 후 다시 로드할 수 있는 것).
• 서버 상태는 공유된 것입니다(다른 기기가 결국 보게 될 것).

이 경계를 유지하면 폼과 리스트가 커져도 오프라인 동작은 예측 가능하게 유지됩니다.

백그라운드 동기화 신뢰성: 무엇이 깨지고 왜인가

백그라운드 동기화는 코드보다 폰 때문에 더 자주 실패합니다. Android와 iOS는 배터리, 데이터, 성능을 보호하기 위해 앱의 백그라운드 활동을 제한합니다. 사용자가 배터리 세이버를 켜거나 백그라운드 데이터를 끄거나 앱을 강제 종료하면 “5분마다 동기화” 약속이 OS가 허용하는 시점에만 실행되는 상황으로 바뀔 수 있습니다.

안드로이드에서는 작업을 어떻게 스케줄링하느냐와 제조사의 전원 관리 규칙에 따라 신뢰성이 달라집니다. 더 안전한 경로는 OS 승인 스케줄러(예: WorkManager와 제약 조건)를 사용하는 것입니다. 그래도 브랜드별로 화면이 꺼지거나 기기가 유휴 상태일 때 작업을 공격적으로 지연시키기도 합니다. 거의 실시간 업데이트가 필요하다면 항상 켜진 동기화 대신 결국 동기화되는 모델로 재설계해야 하는 경우가 많습니다.

Compose와 React Native의 차이는 백그라운드 작업이 어디에서 실행되느냐입니다. Compose 앱은 보통 네이티브 코드에서 백그라운드 작업을 실행하므로 스케줄링과 재시도 로직이 OS에 가깝게 유지됩니다. React Native도 견고하게 만들 수 있지만 백그라운드 작업은 추가 네이티브 설정과 서드파티 모듈에 의존하는 경우가 많습니다. 흔한 함정은 작업이 제대로 등록되지 않거나, 헤드리스 작업이 OS에 의해 죽거나, JS 런타임이 예상대로 깨어나지 않는 경우입니다.

동기화가 작동하는지 증명하려면 이를 실제 기능처럼 다루고 측정하세요. “실행됐는가?”와 “완료됐는가?”에 답하는 사실을 로깅하세요. 동기화 작업이 언제 스케줄됐고 시작·종료됐는지, 네트워크와 배터리 세이버 상태, 업로드 큐에 있는 항목·성공·실패·재시도(에러 코드 포함), 사용자/기기별 마지막 성공 동기화 시간, 충돌 결과를 추적하세요.

간단한 테스트: 폰을 주머니에 넣어 밤새 두세요. 아침까지 기기들 간 동기화가 성공하면 제대로 가고 있는 것입니다.

복잡한 폼: 검증, 드래프트, UX 세부사항

조건부 필드, 다단계 화면, 많은 검증이 있는 복잡한 폼에서는 작은 지연이나 포커스 글리치가 곧바로 이탈로 이어집니다.

검증은 예측 가능할 때 사용하기 편합니다. 필드를 건드린 뒤에만 오류를 보여주고, 메시지는 간결하게 유지하며, 규칙은 실제 워크플로와 일치하게 하세요. 조건부 필드(예: “배송 필요 시 주소 입력”)는 페이지가 갑자기 튀지 않도록 자연스럽게 나타나야 합니다. 다단계 폼은 각 단계의 목표가 명확하고 뒤로 가기가 명확하며 입력을 잃지 않도록 해야 좋습니다.

키보드와 포커스 동작은 눈에 띄지 않게 치명적일 수 있습니다. 사용자는 Next 버튼이 합리적인 순서로 이동하기를 기대하고, 활성 필드가 보이도록 화면이 스크롤되며, 오류 메시지가 스크린 리더에서 접근 가능하기를 기대합니다. 작은 폰에서 한 손으로 테스트해 보세요. 그곳에서 엉성한 포커스 순서와 숨겨진 버튼이 드러납니다.

오프라인 드래프트는 긴 폼에서는 선택이 아닙니다. 실무적인 접근은 의미 있는 변경이 있을 때(모든 키 입력마다가 아니라) 저장하고 사용자가 나중에 다시 이어서 할 수 있게 하는 것입니다. “마지막 저장” 힌트를 보여주고, 부분 데이터 허용 및 첨부파일은 별도로 처리해 큰 이미지가 드래프트를 느리게 하지 않게 하세요.

예: 조건부 섹션이 있는 40개 항목 검사 폼. 각 키 입력마다 모든 규칙을 검증하면 타이핑이 끈적거립니다. 반대로 끝에서만 드래프트를 저장하면 배터리 방전으로 작업이 날아갈 수 있습니다. 부드러운 경험은 빠른 로컬 저장, 제출 근처에서 검증을 강화, 그리고 키보드가 동작 버튼을 가리지 않도록 안정된 포커스입니다.

긴 리스트: 부드러운 스크롤과 메모리 사용

긴 리스트는 사용자가 가장 먼저 문제를 느끼는 곳입니다: 스크롤, 탭, 빠른 필터링. 둘 다 빠르게 만들 수 있지만 느려지는 원인은 다릅니다.

Compose에서는 보통 LazyColumn(또는 LazyRow)로 긴 리스트를 구성합니다. 화면에 보이는 것만 렌더링하므로 메모리 사용에 유리합니다. 그래도 각 행을 가볍게 유지해야 합니다. 아이템 컴포저블 내부에서 무거운 작업을 하거나 상태 변화가 넓은 재구성을 유발하면 스터터가 발생할 수 있습니다.

React Native에서는 FlatList와 SectionList가 가상화를 위해 설계되었지만, props가 바뀔 때 많은 행을 재렌더링하거나 이미지, 동적 높이, 잦은 필터 업데이트가 JS 스레드에 부담을 주면 프레임 드랍으로 이어집니다.

대부분의 리스트 잔설을 막는 몇 가지 습관: 안정적인 키 유지, 매 렌더마다 새 객체나 콜백을 생성하지 않기, 행 높이를 예측 가능하게 유지, 페이징을 사용해 로딩 중 스크롤이 블로킹되지 않게 하기.

앱에 맞는 기술을 선택하는 단계별 방법

요구사항을 프레임워크 용어가 아니라 평범한 언어로 먼저 작성하세요. “어두운 곳에서 바코드 스캔”, “주문당 사진 10장 첨부”, “신호 없이 2일간 작업”, “기기 잠금 상태에서 조용히 동기화” 같은 문장은 트레이드오프를 분명히 합니다.

다음으로 화면을 다듬기 전에 데이터와 동기화 규칙을 확정하세요. 로컬에 무엇이 남고, 무엇을 캐시하며, 무엇을 암호화해야 하고, 두 번 편집되었을 때 무엇을 할지 결정하세요. UI가 먼저 예쁘게 만들어진 뒤에 이 작업을 하면 보통 앱 절반을 다시 고쳐야 합니다.

그다음 두 옵션에서 같은 작은 슬라이스를 만들어 점수 매기세요: 드래프트와 첨부파일이 있는 복잡한 폼 하나, 검색과 업데이트가 있는 긴 리스트 하나, 비행기 모드에서의 기본 오프라인 흐름 하나, 앱이 죽었다가 다시 열렸을 때 재개되는 동기화 실행 하나. 마지막으로 실제 기기에서 백그라운드 동작을 테스트하세요: 배터리 세이버 켬, 백그라운드 데이터 제한, 한 시간 이상 유휴 상태 등. 많은 “내 폰에서는 동작함” 동기화 문제는 여기서만 드러납니다.

사용자가 실제로 느끼는 것을 측정하세요: 콜드 스타트 시간, 스크롤 부드러움, 크래시 없는 세션. 완벽한 벤치마크를 쫓지 마세요. 반복할 수 있는 단순한 기준선이 더 좋습니다.

흔한 실수와 함정

많은 팀이 화면과 애니메이션에 먼저 집중합니다. 고통스러운 부분은 보통 나중에 드러납니다: 오프라인 동작, 백그라운드 작업 제한, 사용자가 기대하는 상태와 일치하지 않는 상태 관리.

흔한 함정은 백그라운드 동기화가 요청할 때마다 실행될 것이라고 가정하는 것입니다. Android와 iOS는 배터리와 데이터를 절약하기 위해 작업을 지연하거나 중단합니다. 즉시 업로드를 전제로 설계하면 실제로는 ‘누락된 업데이트’ 리포트를 받게 됩니다(이는 OS 스케줄링 때문입니다).

또 다른 함정은 UI를 먼저 만들고 데이터 모델은 나중에 맞추는 것입니다. 오프라인 충돌은 출시 후 고치기 더 어렵습니다. 같은 레코드를 두 번 편집했을 때 무엇을 할지, 서버에 한 번도 업로드되지 않은 것을 사용자가 삭제하면 어떻게 할지 일찍 결정하세요.

폼은 상태를 이름 짓고 분리하지 않으면 조용히 엉망이 됩니다. 사용자는 자신이 드래프트를 편집하는지, 로컬에 저장된 기록을 편집하는지, 이미 동기화된 것을 편집하는지 알아야 합니다. 이게 없으면 중복 제출, 잃어버린 메모, 잘못된 시점에 차단하는 검증이 생깁니다.

주의할 패턴들:

• OS 규칙 대신 타이머로 백그라운드 작업이 항상 실행될 것이라고 가정하기.
• 오프라인을 단순 토글로 처리하고 데이터/충돌 모델의 핵심으로 다루지 않기.
• 하나의 폼이 드래프트·저장·동기화된 것 세 가지를 명확한 규칙 없이 대표하게 하기.
• 빠른 폰과 안정된 와이파이에서만 테스트하고 느린 리스트와 멈춘 업로드에 놀라기.
• 서드파티 플러그인을 많이 추가하다가 하나가 유지보수되지 않거나 엣지 케이스에서 실패하는 것을 발견하기.

현실 점검 예: 영업 사원이 신호 없는 지하실에서 주문을 만들고 두 번 편집한 뒤 밖으로 나오면 앱이 어느 버전을 동기화할지 설명하지 못하거나 배터리 제한 때문에 동기화가 차단되면 사용자는 네트워크가 아닌 앱을 탓합니다.

커밋 전에 확인할 체크리스트

스택을 선택하기 전에 앱의 작은 ‘실제’ 슬라이스를 만들어 점수 매기세요. 하나라도 실패하면 나중에 몇 주의 수정 작업으로 이어지는 경우가 많습니다.

먼저 오프라인 완료도를 확인하세요: 네트워크 없이도 상위 3개 작업을 끝까지 수행할 수 있는가? 빈 상태나 중복 항목으로 사용자가 혼란스러워하지 않는가? 다음으로 동기화를 스트레스 테스트하세요: 끊기는 Wi-Fi에서의 재시도와 백오프, 업로드 중 앱 강제 종료, 그리고 “기기에 저장됨” vs “전송됨” 같은 명확한 사용자 가시 상태. 긴 조건부 흐름의 폼 검증: 드래프트가 충돌이나 강제 종료 후에도 사용자가 떠난 지점에서 정확히 열려야 합니다. 목록은 수천 행과 필터, 인플레이스 업데이트로 밀어붙여서 프레임 드랍과 메모리 스파이크를 관찰하세요. 마지막으로 권한이 “사용 중일 때만”, 배터리 세이버 켬, 백그라운드 데이터 제한 같은 상황에서 기기 기능을 테스트해 우아한 대체 동작을 확인하세요.

실용적인 팁: 이 테스트는 접근 방식당 2~3일로 시간박스를 잡으세요. 그 기간 안에 “오프라인 + 동기화 + 긴 리스트 + 복잡한 폼” 슬라이스를 안정적으로 만들지 못하면 지속적인 고통을 예상하세요.

예시 시나리오: 오프라인 주문이 있는 현장 영업 앱

현장 영업팀이 소형 매장에 판매하는 상황을 상상해 보세요. 앱은 오프라인 주문, 매대와 영수증 사진 캡처, 큰 제품 카탈로그, 본사로의 일일 동기화가 필요합니다.

아침: 담당자가 가끔 신호가 약한 주차장에서 앱을 엽니다. 10,000개 상품 카탈로그를 검색하고 빠르게 항목을 추가하며 고객 상세와 긴 주문 폼을 왔다 갔다 합니다. 여기서 UI 마찰이 드러납니다. 상품 리스트가 과도하게 재렌더링되면 스크롤이 끊깁니다. 폼이 포커스를 잃거나 드롭다운이 리셋되거나 사진 촬영을 위해 앱이 백그라운드로 가면 드래프트를 잃으면 사용자는 즉시 불편함을 느낍니다.

오후: 연결이 몇 시간 끊깁니다. 담당자는 할인, 메모, 사진이 포함된 다섯 건의 주문을 만듭니다. 오프라인 모드는 단순히 로컬에 데이터 저장만이 아닙니다. 가격표가 바뀌었을 때의 충돌 규칙, 명확한 상태(저장됨, 동기화 대기, 동기화됨), 안전한 드래프트(통화나 카메라 사용, 앱 재시작을 견디는)가 필요합니다.

저녁: 담당자가 다시 커버리지에 들어옵니다. 이 팀에게 ‘충분히 신뢰할 만한’ 백그라운드 동기화는 네트워크가 복구되면 몇 분 내에 주문이 자동 업로드되고, 실패한 업로드는 중복 없이 재시도되며, 사진은 큐에 들어가 압축되어 동기화가 멈추지 않고, 담당자가 “지금 동기화”를 눌러 결과를 볼 수 있는 것을 의미합니다.

대개 여기서 결정이 분명해집니다: 장기간 스트레스(긴 리스트, 카메라+백그라운딩, OS 관리 백그라운드 작업) 하에서 얼마나 많은 네이티브 동작이 필요한지. 위험한 부분을 먼저 프로토타입하세요: 큰 제품 리스트 하나, 드래프트가 있는 복잡한 주문 폼 하나, 네트워크 중단 후 업로드를 재시도하는 오프라인 큐 하나.

다음 단계: 작은 빌드로 선택을 검증하세요

결정을 못 내리겠다면 짧고 집중된 스파이크를 실행하세요. 목표는 앱을 완성하는 것이 아니라 첫 번째 진짜 제약을 찾는 것입니다.

간단한 계획을 사용하세요: 타협할 수 없는 하나의 기기 기능(예: 바코드 스캔 + 사진)과 하나의 오프라인 워크플로(생성, 편집, 드래프트 저장, 폰 재부팅, 재개, 제출), 그리고 하나의 동기화 작업(오프라인 작업 큐, 불안정한 네트워크에서 재시도, 서버 거부 처리, 명확한 오류 상태 표시)을 선택합니다.

출시 전 실제 실패를 잡아내는 방법을 결정하세요. 동기화 시도에 이유 코드(네트워크 없음, 인증 만료, 충돌, 서버 오류)를 로깅하고, 지원팀이 추정 없이 문제를 진단할 수 있도록 작은 “동기화 상태” 화면을 추가하세요.

백엔드와 관리자 UI도 모바일 앱과 함께 빨리 구축해야 한다면, AppMaster(appmaster.io)은 비즈니스 앱의 기준으로 유용할 수 있습니다: 생산 준비가 된 백엔드, 웹, 네이티브 모바일 코드를 생성해 데이터 모델과 워크플로를 빠르게 검증할 수 있게 해줍니다.