36 lines
5.2 KiB
Markdown
36 lines
5.2 KiB
Markdown
---
|
|
category: Frontend
|
|
tags: [auto-wikified, technical-documentation, frontend]
|
|
title: React Native
|
|
description: "React Native는 2015년 메타(Meta, 구 Facebook)에서 개발한 오픈 소스 크로스 플랫폼 모바일 애플리케이션 개발 프레임워크이다 [1, 2]."
|
|
last_updated: 2026-05-04
|
|
---
|
|
|
|
# React Native
|
|
|
|
## 📌 Brief Summary
|
|
React Native는 2015년 메타(Meta, 구 Facebook)에서 개발한 오픈 소스 크로스 플랫폼 모바일 애플리케이션 개발 프레임워크이다 [1, 2]. 자바스크립트(JavaScript)와 타입스크립트(TypeScript)를 기반으로 하여 단일 코드베이스로 iOS, Android, 웹 및 데스크톱 애플리케이션을 구축할 수 있다 [1, 3]. 고유한 렌더링 엔진 대신 호스트 운영체제의 기본(Native) UI 컴포넌트를 사용하여 사용자에게 100% 네이티브와 같은 외관과 동작을 제공하는 것이 가장 큰 특징이다 [3, 4].
|
|
|
|
## 📖 Core Content
|
|
|
|
* **자바스크립트 생태계 및 React 패러다임 활용**
|
|
React Native는 세계에서 가장 널리 사용되는 자바스크립트와 React 패러다임을 그대로 모바일 환경에 적용한다 [5, 6]. 이는 웹 개발자가 상대적으로 낮은 학습 곡선으로 모바일 개발에 진입할 수 있게 하여 '인재 이동성(Talent Portability)'을 제공하며, 단일 팀이 웹과 모바일 코드베이스 전반에 기여할 수 있는 전략적 이점을 창출한다 [7, 8]. npm 저장소의 방대한 라이브러리는 물론, Zustand, TanStack Query(React Query)와 같은 웹 생태계의 상태 관리 도구들을 그대로 활용할 수 있다 [9, 10].
|
|
* **네이티브 UI 렌더링 (Native Components)**
|
|
React Native는 자바스크립트 코드를 실제 플랫폼의 네이티브 UI 컴포넌트(iOS의 `UIView`, Android의 `View`)로 변환하여 렌더링한다 [4, 11]. 이러한 렌더링 방식 덕분에 플랫폼 고유의 스크롤 물리 효과, 텍스트 선택 동작, 자동 수정, 동적 타입, 접근성 기능(VoiceOver, TalkBack) 등을 추가적인 노력 없이 자연스럽게 상속받아 온전한 네이티브 사용자 경험(UX)을 제공한다 [4, 12].
|
|
* **새로운 아키텍처 (New Architecture)의 도입**
|
|
기존 React Native의 가장 큰 성능 병목으로 지적되던 비동기 자바스크립트 브릿지(Bridge)를 제거하고, 성능을 극대화하기 위해 아키텍처를 대대적으로 개편하였다 [13, 14].
|
|
* **JSI (JavaScript Interface):** 브릿지를 대체하는 기초 레이어로, 자바스크립트 코드가 C++를 통해 네이티브 객체를 직접적이고 동기적으로 호출할 수 있게 하여 직렬화(Serialization) 오버헤드를 완전히 제거한다 [15, 16].
|
|
* **Fabric:** JSI를 기반으로 구축된 새로운 UI 렌더링 시스템으로, 메인 스레드에서 동기적인 레이아웃 계산과 렌더링을 가능하게 하여 UI 반응성을 크게 향상시킨다 [16, 17].
|
|
* **TurboModules:** 앱 시작 시 모든 네이티브 모듈을 로드하던 기존 방식 대신, 필요할 때만 지연 로딩(Lazy-loading)하는 모듈 시스템으로 초기 시작 시간과 메모리 사용량을 대폭 줄여준다 [16, 18].
|
|
* **Expo 에코시스템을 통한 개발 표준화**
|
|
최근 React Native 개발에서는 Expo가 프로덕션 앱 구축의 실질적인 표준(De Facto Standard)으로 자리 잡았다 [19, 20]. EAS(Expo Application Services)를 이용한 클라우드 빌드 및 배포 자동화, Expo Router를 통한 파일 기반 네비게이션, 그리고 네이티브 코드를 직접 건드리지 않고도 외부 라이브러리를 통합할 수 있는 Config Plugins 기능 등을 제공하여 개발 생명주기를 획기적으로 간소화한다 [19, 20].
|
|
|
|
## ⚖️ Trade-offs & Caveats
|
|
|
|
* **플랫폼 파편화 및 유지보수 비용:** iOS와 Android의 네이티브 모듈은 독립적으로 진화하기 때문에, OS 업데이트나 네이티브 플랫폼의 변경 사항에 따라 플랫폼 종속적인 수정이 필요할 수 있다 [21]. 이로 인해 브릿지 및 서드파티 라이브러리 관련 버그를 해결하기 위한 장기적인 유지보수 오버헤드가 발생한다 [22-24].
|
|
* **버전 업그레이드의 복잡성:** 주요 버전 업데이트 시 광범위한 테스트가 요구되며, 서드파티 라이브러리가 새로운 OS 버전을 즉각적으로 지원하지 않을 경우 호환성 문제가 발생할 수 있다 [22].
|
|
* **디버깅 난이도:** 자바스크립트 로직과 네이티브 코드가 결합된 하이브리드 환경의 특성상, 에러가 네이티브 영역(혹은 서드파티 라이브러리의 네이티브 코드)에서 발생할 경우 원인을 추적하고 디버깅하는 과정이 순수 네이티브 개발보다 훨씬 복잡해진다 [25, 26].
|
|
* **커스텀 UI 및 복잡한 애니메이션 한계:** 네이티브 컴포넌트를 사용하기 때문에 플랫폼 표준 인터페이스 구현에는 유리하지만, 렌더링 파이프라인을 완전히 통제하는 Flutter와 비교했을 때 플랫폼 종속성을 벗어나는 극도로 복잡한 맞춤형 애니메이션이나 고사양 그래픽 처리를 구현하는 데에는 구조적 한계가 존재한다 [27-29].
|
|
|
|
---
|
|
*Last updated: 2026-05-03* |