RN의 New Architecture & Nitro Modules

eeensu·2026년 5월 10일

React Native

목록 보기

37/41

개요

React Native의 새로운 아키텍처(New Architecture)와 최근 생태계에서 고성능 기술로 주목받는 Nitro Modules에 대해 알아보자. 2026년 현재, 이 두 기술은 React Native의 고질적인 성능 한계를 돌파하는 핵심적인 개념이다.

1. New Architecture (신형 아키텍처)

신형 아키텍처는 React Native 0.76 버전 이후로 기본값(Default)으로 활성화된, 프레임워크의 내부 구조를 완전히 교체한 결과물이다. 기존의 비동기 JSON 직렬화 통신 방식(The Bridge)을 폐기하고, C++ 기반의 메모리 공유 방식을 채택하였다. 핵심 구성 요소는 다음과 같다.

1. JSI (JavaScript Interface)

JS 엔진(Hermes)이 C++ 객체에 대한 참조(Reference)를 직접 가질 수 있게 해주는 계층이다.
데이터를 JSON으로 변환(Serialization)할 필요 없이, JS에서 네이티브 함수를 동기적(Synchronously)으로 즉시 호출할 수 있다.
JS 엔진에 종속되지 않는 추상화 계층이므로, Hermes뿐 아니라 다른 JS 엔진(JSC, V8 등)에서도 동일하게 동작한다.

구 Bridge와 JSJ의 차이

과거의 '브릿지'라는 별도의 통신 계층을 거치지 않고, JSI라는 얇은 C++ 인터페이스를 통해 JS 엔진과 네이티브가 직접 함수를 호출하는 구조로 바뀌었다. JSON 직렬화도, 비동기 메시지 큐도 사라졌다.

2. Fabric (신규 렌더링 시스템)

UI 렌더링을 담당하는 새로운 C++ 렌더러이다.
기존에는 JS가 UI 업데이트 명령을 브릿지를 통해 비동기로 보냈기 때문에 스크롤이나 애니메이션 렌더링이 밀리는 현상이 있었다.
Fabric은 UI 스레드와 JS 스레드 간의 레이아웃 계산과 렌더링을 동기적으로 처리할 수 있게 하여, React 18 이상의 동시성 기능(Concurrent Features, Suspense, Transitions, automatic batching 등)을 완벽하게 지원한다.

3. TurboModules (신규 네이티브 모듈)

앱이 켜질 때 모든 네이티브 라이브러리(카메라, 갤러리 등)를 한 번에 메모리에 올리던 기존 방식(Native Modules)을 대체한다.
JS 코드에서 해당 모듈이 실제로 호출될 때(Lazy Load) 메모리에 로드하므로 앱 초기 구동 속도가 대폭 향상된다.
빌드 타임에 Codegen(TS/Flow spec을 C++/Java/Obj-C 인터페이스로 자동 변환하는 RN 공식 도구)을 거쳐 타입 안정성을 보장한다.

4. Bridgeless Mode (브릿지리스 모드)

신형 아키텍처가 완성된 형태로, 구형 브릿지 코드를 메모리에서 완전히 제거하여 오버헤드를 0으로 만든다.
0.76부터는 Bridgeless가 기본 동작 모드이며, 구형 Bridge는 미마이그레이션 라이브러리를 위한 interop layer로만 잔존한다.

⚠️ 도입 시 유의사항

모든 서드파티 라이브러리가 즉시 호환되지는 않으며, interop layer로 임시 동작은 가능하나 Custom Shadow Node나 Concurrent Features는 미지원이다.
최소 SDK 요구사항이 상향되었다: iOS 13.4 → 15.1, Android SDK 23 → 24 (Android 7).
Concurrent Features를 온전히 쓰려면 앱 코드를 React 18 시맨틱(Rules of React)에 맞게 마이그레이션해야 한다.

2. Nitro Modules

공식 신형 아키텍처의 JSI 위에서 동작하면서, 개발 편의성과 실행 속도를 극한으로 끌어올린 서드파티 라이브러리(Margelo 사 개발)이다. 공식 TurboModules가 훌륭하지만, 개발자가 직접 구현하려면 복잡한 C++ 보일러플레이트와 Codegen이 만들어내는 빌드 타임 의존성을 다뤄야 하는 진입 장벽이 존재한다. Nitro Modules는 이 문제를 해결하기 위해 등장했다.

중요: Nitro는 TurboModules의 대체재가 아니라 그 위에 얹히는 레이어다. Nitro 자체가 RN에 등록되는 하나의 Turbo Module이며, install() 훅을 통해 JSI 위에 자체 바인딩 시스템을 부트스트랩한다.

초고속 JSI 바인딩
- C++/Swift/Kotlin 중 원하는 언어로 네이티브 코드를 작성할 수 있으며, JS↔네이티브를 가장 빠른 경로로 직접 연결한다.
- 특히 iOS에서는 Swift 5.9의 Swift ↔ C++ interop을 활용해 Objective-C 메시지 send 단계를 건너뛰고 직접 브리징한다. 이것이 기존 TurboModules 대비 iOS 성능 우위의 핵심 원인이다.
- Android는 fbjni를 통해 Kotlin/Java로 직접 바인딩한다.
Hybrid Object (Nitro의 핵심 개념)
- TurboModules는 모든 모듈이 싱글톤이고 메서드는 정적 메서드처럼 동작한다. 따라서 Image 같은 네이티브 객체 인스턴스를 JS로 직접 넘길 수 없고, 파일 경로/base64/Blob 등으로 우회해야 했다.
- Nitro의 Hybrid Object는 네이티브 객체 인스턴스 자체를 JS의 first-class citizen으로 다룰 수 있게 한다. 생성·전달·소멸이 모두 자연스럽게 이뤄진다.
```
interface ImageEditor extends HybridObject<{ ios: 'swift', android: 'kotlin' }> {
  loadImage(path: string): Promise<Image>
  crop(image: Image, size: Size): Image  // Image 인스턴스를 직접 주고받음
}
```
- 이 특성 덕분에 vision-camera, mmkv 등 고성능 라이브러리들이 Nitro로 전환하고 있다.
강력한 타입/Null 안정성
- TypeScript spec이 single source of truth가 되어, 네이티브 구현이 spec과 다르면 앱이 컴파일조차 되지 않는다.
- 예: TS에서 number로 선언했는데 Swift에서 String을 반환하면 빌드 실패. 런타임 타입 오류가 원천 차단된다.
오버헤드 최소화된 데이터 변환
- JS↔C++ 타입 컨버터가 빌드 타임에 정적으로 생성되어 런타임 동적 lookup이 없다.
- 대용량 ArrayBuffer, 배열, 객체 전달 시 메모리 복사 비용이 최소화되도록 C++ 템플릿 최적화가 적용되어 있다.
- Margelo 자체 벤치마크 기준으로는 단순 호출에서도 TurboModules보다 빠른 수치를 보고하지만, 실제 체감 차이는 워크로드(특히 객체 전달 빈도와 크기)에 크게 의존한다.
Codegen 방식의 차별화 (Nitrogen)
- Nitro도 Nitrogen이라는 자체 코드 생성기를 사용한다. "Codegen이 없다"가 아니라 언제, 어떻게 돌리는가가 다르다.
- 공식 Codegen: 앱 빌드 시점에 매번 spec을 재생성 → 빌드 시간 증가, import resolve 한계.
- Nitrogen: 라이브러리 개발자가 publish 시점에 1회 실행 → 생성된 인터페이스를 npm 패키지에 포함해 배포. 빌드는 가벼워지고, 다른 파일의 import도 정상적으로 resolve된다.

요약

New Architecture: React Native 프레임워크 자체가 성능을 올리기 위해 내부 통신망을 브릿지에서 JSI(C++ 직접 참조)로 교체한 '공식 시스템 구조 변경'이다. (JSI + Fabric + TurboModules + Bridgeless)
Nitro Modules: 이 새로운 JSI 통신망 위에서, 개발자가 Swift/Kotlin/C++ 코드를 JS와 연결할 때 가장 빠르고 편하게 작성할 수 있도록 돕는 '초고성능 서드파티 엔진'이다. 핵심 차별점은 Hybrid Object, Swift↔C++ 직접 인터롭, 정적 타입 안정성.
둘의 관계: 대체 관계가 아니라 계층 관계다. Nitro는 Turbo Module로 자기 자신을 등록한 뒤 JSI 위에 별도 바인딩 레이어를 올린다.