하루살이 개발일지

React-Native의 동작원리 및 새로운 아키텍쳐의 도입 / React-Native 새로운 아키텍쳐 특징 및 구버전과의 차이점 본문

앱개발/React-Native

React-Native의 동작원리 및 새로운 아키텍쳐의 도입 / React-Native 새로운 아키텍쳐 특징 및 구버전과의 차이점

harusari 2024. 3. 16. 15:10

 

 

📖 목차

1. React-Native란?
  1-1. 크로스 플랫폼이란?
  1-2. 네이티브 앱이란?
  1-3. React-Native의 장점
  1-4. React-Native의 단점
  1-5. React-Native의 전망

2. React-Native의 동작 원리 및 아키텍쳐
  2-1. 가상 DOM (Virtual DOM)과 Shadow Tree
  2-2. 옛날 버전 React-Native 동작 순서
  2-3. 이러한 방식의 문제점

3. React-Native의 새로운 아키텍쳐
  3-1. 구버전과의 차이점
  3-2. JSI
  3-3. 동시성 렌더러(Concurrent Renderer)
  3-4. TurboModule
  3-5. Fabric Renderer

4. 새로운 아키텍쳐의 도입 및 기능
  4-1. 새로운 아키텍쳐의  기능 및 개선 사항
  4-2. 새로운 아키텍쳐의 도입

 

 

1. React-Native란?

React-Native는 페이스북에서 개발한 크로스 플랫폼 개발 프레임워크로, JavaScript를 언어로 사용한다.

웹 프론트 개발에서의 대표적인 라이브러리인 React를 기반으로 개발된 프레임워크이기 때문에 React에 익숙한 개발자라면 React-Native를 통해 비교적 쉽게 모바일 앱을 만들 수 있다.

 

React-Native는 많은 기업에서 사용하고 있는데, 대표적으로 페이스북, 인스타그램, 에어비앤비 앱이 있다. 

 

 

1-1. 크로스 플랫폼이란?

출처: https://www.elancer.co.kr/blog/view?seq=195

 

크로스 플랫폼은 여러 플랫폼(iOS, Android, Web)에서 동일한 소스코드를 사용하여 앱을 개발하는 방법이다.

대표적인 예로 React-Native, Flutter 등이 있다.

 

크로스 플랫폼을 사용하면 네이티브 앱을 각 플랫폼마다 별도로 개발하는 것보다 효율적일 수 있다. 하나의 코드베이스로 여러 플랫폼의 앱을 개발할 수 있으므로 개발 비용을 절감하고 시간을 단축할 수 있다. 

 

그러나 크로스 플랫폼은 SDK(Software Development Kit)의 기능을 직접 사용하는 네이티브 앱에 비해 성능이 떨어진다는 단점이 있다. 크로스 플랫폼으로 개발된 앱은 네이티브 코드로 번역하고 상호작용하는 과정이 필요하기 때문에 네이티브 앱에 비해 추가적인 작업이 필요하다. (하지만 스마트폰의 성능 향상으로 사용자가 체감하는 성능 차이는 미비한 수준이다.)

또한, 특정 플랫폼에서 기존 기능의 업데이트나 새로운 기능이 나왔을 때 크로스 플랫폼에서 이를 사용하기 위해서는 관련된 라이브러리가 업데이트되길 기다리거나, Native 모듈을 직접 작성해야 한다.

 

따라서 크로스 플랫폼 방식은 사용자와 상호작용이 많아 UI 등의 빠른 업데이트가 필요한 경우, 페이지 수가 많은 경우 유리할 수 있다.

 

 

1-2. 네이티브 앱이란?

출처: https://www.elancer.co.kr/blog/view?seq=195

 

그렇다면, 네이티브 앱은 무엇일까?

대표적인 스마트폰 플랫폼인 Android와 iOS는 플랫폼 내에서 사용 가능한 앱을 만들기 위한 도구를 제공한다. 이 도구 모음을 SDK(Software Development Kit)라고 하는데, 이를 사용해 개발된 앱을 네이티브 앱이라고 한다.

SDK를 통해 스마트폰 기기를 동작하게 하며, 카메라, 알림 등의 기능을 구현할 수 있다.

Android 앱을 개발하기 위해서는 Android SDK를 직접 사용하는 Kotlin이나 Java등을 사용할 수 있고, iOS 앱을 개발하기 위해서는 iOS SDK를 직접 사용하는 Objective-C Swift를 사용할 수 있다.

 

네이티브 앱을 사용하면 플랫폼 사에서 제공한 SDK를 직접 사용하기 때문에 해당 플랫폼에 최적화되어 있어 높은 성능을 제공한다. 그래픽 처리, 애니메이션 및 하드웨어의 기능을 최대한 활용할 수 있다. 또한 SDK가 업데이트되면 새로운 기능을 즉각 적용할 수 있다는 장점이 있다.

 

그러나 네이티브 앱은 각 플랫폼마다 별도의 개발이 필요하므로 개발 및 유지 비용 보수가 높을 수 있다는 단점이 있다. 동일 기능, 동일 디자인이더라도 각 플랫폼 별로 개발해야하기 때문에 각 플랫폼 별 개발자를 따로 둠으로써 비용이 높아질 수 있다. 또한 작성된 코드는 해당 플랫폼에서만 실행되기 때문에 재사용이 어렵다. 이를 통해 개발 및 관리 효율 측면에서 단점이 될 수 있다.

 

따라서 네이티브 앱은 최적화 및 성능 이슈가 큰 서비스의 앱을 개발할 때 적합할 수 있다.

고성능 게임, 하드웨어의 센서를 사용하는 경우, 민감한 데이터를 다루는 경우, 높은 보안 수준이 필요한 금융 관련 앱이 적합할 수 있다.

 

 

 

 1-3. React-Native의 장점

React-Native를 사용함에 있어 다음과 같은 장점이 있다.

 

효율적인 개발 및 관리

앞서 설명한 것처럼 React-Native는 크로스 플랫폼 앱으로, iOS와 Android 앱을 동시에 개발할 수 있어 효율적인 개발 및 관리가 가능하다. 또한, 리액트 컴포넌트 기반의 개발 방식을 사용하기 때문에 코드 재사용이 용이하다.

 

성능

React-Native로 개발된 앱은 (복잡한 계산이나 고도의 인터렉티브 애니메이션이 많지 않은 경우) 네이티브 앱과 유사한 성능을 제공한다. React-Native는 자바스크립트 코드를 통해 네이티브 컴포넌트를 제어하는데, 이는 앱이 네이티브 UI 요소를 사용해 렌더링된다는 의미이고, 결과적으로 사용자에게 네이티브 앱과 유사한 사용자 경험을 제공할 수 있다. 즉 UI 렌더링이 중요한 앱에서 성능적 이점을 제공할 수 있다.

 

Hot Reloading

React-Native는 개발 과정을 효율적으로 만들어주는 Hot Reloading 기능을 제공한다. 이는 개발자가 코드를 수정하면 즉시 결과에 반영되어 전체적인 프로세스를 빠르게 해준다.

 

 

커뮤니티와 생태계

React-Native는 방대한 커뮤니티가 있어 다양한 서드 파티 라이브러리, 플러그인, 도구를 통해 앱의 기능과 성능을 쉽게 확장할 수 있게 해준다. 개발자는 이를 통해 다양한 리소스와 지원을 받을 수 있다.

 

 

1-4. React-Native의 단점

React-Native를 사용함에 있어 다음과 같은 단점이 있다.

 

네이티브 코드 필요성

복잡한 애플리케이션의 경우 React-Native만으로 충분하지 않을 수 있다. 특정 기능들을 네이티브 코드로 개발할 필요성이 발생할 수 있는데 이는 개발 과정을 복잡하게 만들 수 있다.

 

 

성능 제한

React-Native의 경우 대부분 네이티브 앱에 가까운 성능을 제공하지만, 고도 그래픽 처리나 복잡한 계산에서는 순수 네이티브 앱에 비해 성능이 떨어질 수 있다.

 

 

라이브러리 호환성 및 업데이트

비록 방대한 생태계를 자랑하지만, React-Native는 일부 네이티브 기능에 대한 지원이 부족하거나 특정 서드파티 라이브러리와의 호환성 문제를 겪을 수 있다. 또한 React-Native 자체적으로 빠르게 발전하고 있어 업데이트가 잦은데, 이로 인해 기존 프로젝트의 최신 버전과 호환되지 않는 문제가 발생할 수 있다. 이는 유지 보수에 있어 추가적인 작업이 필요해진다.

 

 

1-5. React-Native의 전망

모바일 앱 개발 시장은 효율성과 비용 절감을 중시하기 때문에, 이러한 측면에서 React-Native는 크로스 플랫폼 개발의 강력한 선택지로 자리잡고 있다. 개발자는 단일 코드베이스를 통해 iOS와 안드로이드 두 플랫폼에서 작동하는 앱을 한 번에 개발할 수 있다는 점에서 큰 장점이 있다. 또한, Fackbook과 수많은 개발자의 기여를 통해 프레임워크가 지속적으로 발전하고 있어 긍정적인 전망을 가지고 있다.

현재에도 점점 더 많은 개발자들이 React-Native를 채택하고 있는 추세이며, React와 JavaScript에 익숙한 개발자라면 React-Native를 선택하는 것이 더 효율적일 수 있다.

 

 

 

 


 

 

2. React-Native의 동작 원리 및 아키텍쳐

 

2-1. 가상 DOM (Virtual DOM)과 Shadow Tree

React-Native는 React의 가상 DOM개념을 활용한다.

 

💡 React의 가상 DOM이란?


React의 가상 DOM(Virtual DOM) 개념은 성능 최적화를 위해 도입되었다. DOM은 HTML과 XML 문서의 구조화된 표현으로, 웹 페이지의 요소들을 트리 구조로 나타낸다. 웹 애플리케이션에서 DOM을 변경하면, 이는 페이지의 렌더링을 다시 일으키며, 이 과정은 비용이 많이 들고 시간이 오래 걸리게 된다.

React는 이 문제를 해결하기 위해 가상 DOM을 도입했는데, 가상 DOM은 실제 DOM의 경량화된 복사본으로, 메모리 상에 존재한다. 개발자가 UI를 변경하고자 할 때, React는 먼저 이 변경사항을 새로운 가상 DOM에 적용하고, 변경 전과 후의 가상 DOM을 비교 실제로 변경되어야 하는 부분만을 실제 DOM에 적용한다. 이 과정을 '재조정(Reconciliation)'이라고 하며, 이를 통해 필요한 최소한의 DOM 업데이트만을 수행하여 성능을 향상시킬 수 있다.

 

 

 

React-Native에서는 이 가상 DOM 개념을 모바일 앱 개발에 활용한다. 하지만 React-Native의 경우 DOM은 존재하지 않으며, 대신 네이티브 UI 컴포넌트가 존재한다. 

 

출처: https://dzone.com/articles/whats-the-difference-between-react-native-and-reac

 

 

React-Native에서는 React와 유사하게 컴포넌트 기반의 접근 방식으로 애플리케이션의 UI를 구축한다. 이러한 컴포넌트는 JavaScript로 작성되며, React Native의 빌드 시스템을 통해 적절히 처리된다. 작성된 JavaScript 코드는 브릿지(Bridge)를 통해 네이티브 코드와 통신하게 되며, 이 과정을 통해 네이티브 UI 컴포넌트를 조작할 수 있다.

 

 

컴포넌트의 구조와 속성은 브릿지를 통해 내부적으로 'Shadow Tree'라고 불리는 추상적인 구조로 표현된다. Shadow Tree는 React의 가상 DOM과 유사한 역할을 수행하며, UI의 변경 사항을 효율적으로 관리하고 실제 네이티브 컴포넌트에 반영되는 업데이트를 최소화한다. 변경 사항이 발생하면, 이는 먼저 Shadow Tree에 적용되고, 이후 React Native는 변경 전후의 Shadow Tree를 비교하여 실제로 업데이트가 필요한 부분만을 실제 네이티브 뷰에 반영하여 전체 UI를 재구성하는 대신 최소한의 변경으로 처리된다. 이를 통해 React-Native는 UI의 변경 사항을 효율적으로 관리하고 실제 네이티브 UI 업데이트를 최소화해 애플리케이션의 성능을 최적화하고 사용자 경험을 개선한다.

 

요약하자면, React Native는 JavaScript로 작성된 컴포넌트를 네이티브 플랫폼의 UI 컴포넌트로 변환하는 고유한 메커니즘을 사용한다. 이 과정은 Shadow Tree를 포함한 여러 추상화된 중간 단계를 통해 UI의 업데이트를 최적화하며, 이는 개발자가 효율적으로 네이티브 애플리케이션을 구축할 수 있게 해준다.

 

 

 

2-2. React-Native 동작 순서

 

 

 

이 그림은 React-Native에서 JavaScript와 네이티브 플랫폼 사이의 통신 과정을 보여준다. 각 단계를 간단하게 살펴보자.

 

1. Event(이벤트)

사용자의 인터렉션 시스템에서 발생한 이벤트가 네이티브 레벨에서 감지된다. (ex. 사용자가 버튼을 누르는 동작)

 

2. Collect data and notify(데이터 수집 및 알림)

이벤트와 관련된 데이터가 수집되고, 이 정보가 브릿지를 통해 자바스크립트 측으로 전송되기 위해 준비된다.

 

3. Serialized payload(직렬화된 데이터)

네이티브 레벨에서 수집된 데이터가 직렬화된 형태(= 단방향)로 변환된다. 이는 네트워크를 통해 또는 프로세스 간 통신을 통해 전송되기 적합한 형태이다.

 

4. Process event(이벤트 처리)

자바스크립트 측에서 이벤트를 받아서 처리한다. 이는 상태 변화를 포함할 수도 있고, 다른 액션을 트리거할 수도 있다.

 

5. Call navite methods or update UI(네이티브 메소드 호출 또는 UI 업데이트)

처리된 결과에 따라 자바스크립트 측에서 UI를 업데이트하거나, 네이티브 메소드를 호출하는 명령을 생성한다.

 

6. Serialized batched response (직렬화된 일괄 처리된 응답)

명령들이 직렬화되어 네이티브 레벨로 전송된다. 이는 여러 명령이 하나의 큰 패킷으로 묶여 효율적으로 전송된다.

 

7. Process commands (명령 처리)

네이티브 레벨에서 직렬화된 명령을 받아 역직렬화하고, 해당 명령을 실행한다. 이 명령은 UI 업데이트 또는 다른 네이티브 작업을 포함할 수 있다.

 

8. Update UI (UI 업데이트)

최종적으로 네이티브 UI가 업데이트된다. 이는 새로운 컴포넌트를 렌더링하거나 기존 컴포넌트의 속성을 변경하는 등의 작업을 포함할 수 있다.

 

 

 

2-3. 이러한 방식의 문제점

 

 

React Native의 아키텍처는 자바스크립트 스레드와 네이티브 스레드 간의 통신에 브릿지를 사용한다. 브릿지는 데이터를 JSON 형식으로 직렬화하여 이 두 스레드 간에 전달하는 역할을 한다. 이러한 통신 방식은 비동기적이며, 모든 자바스크립트 작업은 단일 스레드에서 처리된다.

이 구조는 여러 가지 문제를 낳는다. 비동기적 통신은 때때로 불필요한 대기 시간을 발생시켜, UI와의 상호작용이나 애니메이션 처리 시 부드러움이 결여되는 원인이 된다. 또한, 자바스크립트의 단일 스레드 작업은 계산이 많은 작업이 이 스레드를 독점할 경우 애플리케이션의 다른 부분이 정체되는 현상을 초래한다. 

더욱이, 브릿지를 통한 데이터의 직렬화 및 역직렬화 과정은 추가적인 성능 오버헤드를 발생시킨다. 특히 상호작용이 빈번하게 일어나는 애플리케이션에서는 이 오버헤드가 프레임 드랍을 유발해 애니메이션이 버벅거리는 문제로 이어진다.

* 프레임 드랍은 화면의 렌더링 속도가 저하되어 사용자에게 끊김이나 지연 현상으로 인식되는 것이다.


결론적으로, 이러한 방식의 React Native는 브릿지 기반 아키텍처로 인해 성능상의 한계와 개발 효율성의 저하라는 문제에 직면했다. 이는 애플리케이션의 반응성과 사용자 경험에 부정적인 영향을 주어, 개발자들 사이에서 지속적인 개선 요구로 이어졌다.

 

더보기

💡 용어 정리

 

스레드(Thread) : 컴퓨터 프로그램에서 작업을 실행하는 데 사용되는 경량 프로세스이다. 기본적으로 프로그램 내에서 독립적으로 실행되는 명령어의 흐름으로, 멀티스레딩을 통해 동시에 여러 작업을 수행할 수 있게 해준다.

예를 들어, 하나의 애플리케이션이 동시에 여러 파일을 다운로드할 때, 각각의 파일 다운로드는 개별 스레드에서 처리될 수 있고 이를 통해 다운로드가 서로 방해받지 않고 동시에 진행될 수 있다.

각 스레드는 자체 호출 스택을 가지고 있으며, 동일한 프로세스 내의 스레드끼리는 메모리와 리소스를 공유할 수 있다. 이는 데이터를 공유하거나 통신하는 데 유리하지만, 동기화와 같은 문제를 야기할 수도 있다.

 

JavaScript Thread : JavaScript Thread는 JavaScript 엔진에 의해 처리되며, JavaScript 코드의 실행, 가상 DOM 업데이트, 비즈니스 로직 처리 등을 담당한다. JavaScript Thread는 싱글 스레드로 동작하기 때문에 비동기 작업이 중요하다. UI 업데이트 등의 작업은 브릿지(Bridge)를 통해 네이티브 UI Thread로 전달된다.

 

Bridge: Bridge는 JavaScript Thread와 Native UI Thread 사이의 통신 역할을 담당한다. JavaScript Thread에서 발생한 UI 업데이트 요청이나 이벤트 처리 등은 Bridge를 통해 네이티브 모듈로 전달된다. Bridge는 이를 처리하고 필요한 UI 업데이트를 네이티브 UI Thread에 전달한다. 반대로, 네이티브 UI Thread에서 발생한 이벤트나 데이터는 Bridge를 통해 JavaScript Thread로 전달된다. Bridge는 이를 효율적으로 처리하기 위해 비동기 통신 방식을 사용한다.

 

Native UI Thread: Native UI Thread는 UI 업데이트 요청 및 사용자 인터렉션에 대한 처리를 담당한다. Bridge를 통해 전달받은 UI 업데이트 요청이나 이벤트를 처리하여 실제 네이티브 UI를 업데이트한다. 이는 플랫폼별 UI 컴포넌트와 상호 작용하여 최종적으로 화면에 렌더링된다.

 

 


 

3. React-Native의 새로운 아키텍쳐

3-1. 구버전과의 차이점

즉, 구버전 React-Native의 한계점을 요약하면 다음과 같다.

  1. 비동기성 : 자바스크립트 측에서 데이터를 브릿지에 제출하고, 네이티브 측에서 데이터 처리를 기다린다는 것
  2. 단일 스레드 : 자바스크립트 스레드를 과부화시키지 않고 UI 스레드에서 애니메이션을 실행하도록 하는 것이 중요
  3. 데이터 직렬화에 따른 추가적 오버헤드 : JSON 객체에서 데이터를 직렬화할 때 추가적 부담이 발생

 

브릿지는 대부분의 사용 사례에서 잘 작동하지만, 많은 데이터를 브릿지를 통해 전송하기 시작하면 앱의 병목 현상이 발생할 수 있다.

만약 사용자가 빠르게 스크롤할 때, 자바스크립트와 네이티브 사이의 비동기 통신으로 인해 이러한 현상이 발생할 수 있다. 즉, 브릿지에서 직렬화를 기다리고 있는 객체들로 인해 '교통 체증'과 같은 것을 겪을 수 있다는 것이다.

 

이러한 병목 현상과 자바스크립트와 네이티브 간에 안전한 통신 방법을 제공하는 것이 신버전 아키텍쳐의 주요한 요점이다. 그러나 신버전 아키텍쳐가 무조건 100% 좋은 것만은 아닐 수도 있다.

 

 


 

2022년에 발표된 React Native의 새로운 아키텍처는 큰 변화와 개선을 약속했으며, 이러한 전환은 단순히 소프트웨어 업데이트를 넘어서는 광범위한 작업을 포함한다. 그러나 아직 React Native 팀에서 새로운 아키텍처의 안정성과 호환성을 확실히 보장하기 위해 광범위한 테스트와 점진적인 개선을 진행하고 있어 아직 이러한 아키텍쳐가 널리 사용되지는 않고 있다. 따라서 현재는(2024.03) 공식적이고 안정적인 릴리즈 단계에 있는 것은 아니다.

 

 

그렇다면 신버전 React-Native의 주요 아키텍쳐의 구성 요소들을 살펴보자.

 

3-2. JSI

 

React-Native의 새로운 아키텍쳐는 브릿지의 개념을 버리고 JavaScript Interface (JSI)라는 새로운 통신 매커니즘이 도입되었다.

JSI는 비동기적으로 동작했던 브릿지와 달리 자바스크립트와 네이티브 코드 사이의 직접적이고 동기적인 통신을 가능하게 하는 C++ 기반의 API이다. 이를 통해 자바스크립트 엔진과 네이티브 사이드 간에 더 빠른 통신이 가능해졌다.

 

- React: 애플리케이션의 비즈니스 로직이나 상태 관리 로직이 포함된 React 컴포넌트들이 있다.

- React Types: 이는 개발자가 정적 타입을 사용하여 안전하고 예측 가능한 코드를 작성할 수 있게 하는 TypeScript 또는 Flow 같은 정적 타입 시스템이다.

- Codegen: 자바스크립트와 네이티브 코드 사이의 인터페이스를 자동으로 생성해주는 도구로, 타입스크립트나 Flow를 사용하여 정의된 API를 바탕으로 필요한 코드를 생성하고 타입 안정성을 제공한다.

- JS Bundle: 이는 Metro 번들러에 의해 컴파일된 애플리케이션의 자바스크립트 코드 모음이다.

- Renderer (Fabric): 새로운 렌더러인 Fabric은 UI를 실제로 그리는 방법을 개선하여 더 빠르고 효율적인 렌더링을 가능하게 한다.

- Native Modules (TurboModules): TurboModules는 네이티브 기능들(예: 카메라, 위치 서비스 등)을 자바스크립트 코드 내에서 사용할 수 있게 해준다. 이를 통해 네이티브 기능을 자바스크립트에서 직접 호출할 수 있다.

- Yoga: 레이아웃 계산을 담당하는 엔진으로, Flexbox를 기반으로 동작하여 다양한 디바이스 화면에 맞는 UI를 구성할 수 있게 해준다.

- Native UI : 실제 디바이스에서 사용자에게 보여지는 UI 요소들이다.

 

 

 

3-3. 동시성 렌더러(Concurrent Renderer)

새로운 아키텍처는 React 18에서 도입된 동시성 렌더러(Concurrent Renderer) 및 기능을 지원한다. 동시성 렌더러(Concurrent Renderer)는 React 애플리케이션이 렌더링 작업을 비동기적으로 수행할 수 있는 능력을 의미한다. 이는 애플리케이션의 렌더링 성능을 향상시킬 수 있으며, 특히 대규모 업데이트가 발생할 때 사용자 인터랙션의 반응성을 유지하는 데 도움을 준다.

 

이를 통해 Suspense for Data-Fetching, Transitions 같은 React의 새로운 API를 React Native 코드에서 사용할 수 있다.

Suspense for Data-Fetching은 데이터 로딩 중에 대체 컴포넌트를 표시하여 로딩 상태를 더 세련되게 처리할 수 있도록 해주는 기능이며, Transitions는 UI 업데이트의 우선순위를 정하여 긴급하지 않은 업데이트는 사용자의 중요한 인터랙션에 방해가 되지 않도록 배경에서 조용히 처리되는 기능이다.

 

또한, 자동 배치 기능을 통해 React에서의 불필요한 렌더링을 줄일 수 있는데, 이는 여러 상태 업데이트가 하나의 작업으로 묶여 처리되도록 함으로써 불필요한 렌더링을 줄이는 기술이다.

 

 

 

3-4. TurboModule

TurboModule JSI 통신 방식을 사용해 구축된 개선된 네이티브 *모듈 시스템이다. TurboModule은 기존의 브릿지가 가진 비동기적인 통신 방식을 개선한다. TurboModule은 자바스크립트와 플랫폼 네이티브 모듈(예: Bluetooth, Biometrics 등)사이의 통신 레이어를 재작성한 것이다.

* 모듈 시스템 : 프로그래밍에서 코드를 재사용 가능하고 관리하기 쉬운 작은 단위로 분리하는 방식. 이 시스템은 코드의 각 부분이 모듈이라고 불리는 독립적인 파일 또는 패키지로 구성되도록 하여, 각 모듈이 특정 기능을 수행하게 함.

 

 

TurboModule을 통해 자바스크립트 코드는 JSI(JavaScript Interface)를 이용하여 네이티브 모듈과 직접적으로 동기적으로 통신할 수 있게 되는데, 이는 기존 브릿지의 역할을 대체하며 브릿지를 통한 JSON 직렬화 과정 없이도 네이티브 모듈과 자바스크립트 간에 데이터를 빠르게 주고받을 수 있게 해준다.

 

따라서 TurboModule은 브릿지를 통한 통신의 개선된 버전으로 볼 수 있으며, 개발자가 C++을 사용하여 더 빠르고 효율적인 네이티브 모듈을 작성할 수 있게 해준다.

 

 

 

 

3-5. Fabric Renderer

Fabric은 React-Native의 새로운 렌더링 엔진이다. Fabric Renderer는 이러한 Fabric을 사용하는 새로운 UI 렌더링 시스템이다. Fabric은 기존의 렌더링 방식을 개선하여 UI를 더 효율적으로 렌더링하고, React 18에서 소개된 기능들을 활용하여 UI 업데이트의 우선순위를 정하고 관리할 수 있게 해준다. 예를 들어, 사용자 인터랙션이 필요하지 않은 부분의 렌더링은 지연시키고 사용자의 행동에 따른 우선순위가 높은 업데이트를 먼저 처리하여 전체적인 애플리케이션의 반응성을 높일 수 있다.

 

 

 

3-6. Codegen

Codegen은 한마디로 코드 자동 생성 도구이며, 크게 두 가지 작업을 수행하며 이 작업은 밀접하게 연관되어 있다.

 

첫 번째로, 네이티브 모듈에서 필요로 하는 기능과 API들을 자바스크립트나 TypeScript와 같은 정적 타입을 가진 코드로 번역해준다. 이렇게 번역된 코드를 'JS Spec'이라고 부른다. 'JS Spec'은 네이티브 모듈의 사용법을 정적 타입 언어로 기록한 것으로, 이를 통해 네이티브 모듈의 API를 명확하게 이해하고 사용할 수 있다.

두 번째로, 이 'JS Spec'을 기반으로 실제 네이티브 코드와 자바스크립트 코드 사이에서 데이터를 주고받을 때 필요한 인터페이스 파일들을 자동으로 생성해준다. 이 인터페이스 파일들은 네이티브 코드와 자바스크립트 코드 간의 소통 방법을 정의한다. 예를 들어, 자바스크립트 함수가 네이티브 함수를 호출할 때 필요한 인자, 예상되는 반환 타입 등을 명시한다.

이 과정을 통해 개발자는 네이티브 모듈과의 통신을 위해 복잡하게 코드를 직접 작성하는 수고를 덜 수 있다. 또한, 'JS Spec'에 정의된 타입 정보를 바탕으로 타입 체크가 가능해져, 개발 과정에서 발생할 수 있는 타입 관련 오류를 사전에 방지할 수 있다. 결과적으로, 개발자는 보다 안정적이고 효율적으로 애플리케이션을 개발할 수 있게 된다. 

요약하자면, Codegen은 개발자가 네이티브 모듈을 더 쉽게, 더 안전하게 사용할 수 있도록 도와주는 도구이다.

 

 

 


 

 

4. 새로운 아키텍쳐의 도입 및 기능

 

4-1. 새로운 아키텍쳐의  기능 및 개선 사항

새로운 아키텍처를 활성화하면 다음과 같은 기능과 개선 사항을 기대할 수 있다.

 

1. 이벤트 루프 모델 업데이트

이벤트 루프는 비동기 이벤트 처리에 있어 핵심적인 역할을 하는데, React Native의 새로운 아키텍처에서의 이벤트 루프 모델 업데이트는 자바스크립트와 네이티브 사이의 상호작용을 더욱 효율적으로 만들어 성능을 향상시키는 것을 목표로 둔다. 이를 통해 이벤트 처리 속도가 빨라지고, 앱의 반응성이 개선될 수 있다. 이러한 업데이트는 특히 애니메이션, 사용자 입력 처리, 네트워크 요청과 같이 비동기적으로 많은 작업을 처리할 때 유용하다.

 

2. 노드 및 레이아웃 API

새로운 아키텍처는 더욱 직관적이고 효율적인 방식으로 UI를 구성하고 관리할 수 있는 새로운 노드 및 레이아웃 API를 도입한다. 이 API는 컴포넌트의 레이아웃과 스타일을 정의하고 조정하는 과정을 개선하여, 개발자가 더 빠르고 쉽게 UI를 설계하고 변경할 수 있게 도와준다. 이를 통해 레이아웃 계산의 성능이 향상되고, 더 복잡하고 동적인 UI를 효과적으로 구현할 수 있다.

 

3. 스타일링 및 레이아웃 준수

새로운 아키텍처는 스타일링 및 레이아웃에 대한 새로운 규칙과 기준을 제시하여, 앱의 외관과 레이아웃이 다양한 화면 크기와 해상도에서도 일관되고 예측 가능하게 동작하도록 한다. 이는 개발자가 앱을 디자인할 때 더 많은 일관성과 호환성을 가지고 작업할 수 있도록 지원한다. 또한, 이를 통해 최종 사용자에게 더욱 안정적이고 직관적인 사용자 경험을 제공할 수 있다.

 

 

그러나 앱이나 라이브러리에 새로운 아키텍처를 적용한다고 해서 바로 성능이나 사용자 경험이 개선되는 것은 아니다. 예를 들어, 동기적 레이아웃 효과나 동시성 기능과 같은 새로운 기능을 활용하기 위해 코드를 리팩토링해야 할 수 있다. JSI는 자바스크립트와 네이티브 메모리 간의 오버헤드를 최소화하지만, 데이터 직렬화가 앱의 성능에 병목 현상을 일으키지 않았을 수도 있다.

 

 

4-2. 새로운 아키텍쳐의 도입

아직까지는(2024.3) 새로운 아키텍처가 완전히 공식 릴리즈되지 않았으며, 현재까지는 실험적인 단계에 있다고 볼 수 있다. React-Native팀에서는 2024년 말까지 다가오는 릴리스에서 새로운 아키텍처를 기본값으로 활성화할 계획이 있다고 한다. 이로 인해 현재 대부분의 React Native 애플리케이션과 라이브러리는 여전히 예전 아키텍처를 기반으로 작동하고 있다. 따라서, 현재는 새로운 아키텍처에 대한 실험, 테스트, 그리고 준비 단계에 있으며, 개발자들은 새로운 기능을 탐색하고 테스트해볼 수 있는 기회를 가질 수 있다.

 

공식적으로 새로운 아키텍처가 기본으로 설정되고 널리 사용되기 전까지, 개발자와 기업은 자신의 프로젝트와 요구 사항에 가장 잘 맞는 방식으로 React Native를 사용해야 한다. 새로운 아키텍처에 대해 실험하고 싶거나, 라이브러리를 미리 준비하고 싶은 경우 공식 가이드와 커뮤니티 지원이 제공된다. 그러나 현재까지는 대규모 프로덕션 앱을 운영하는 경우, 공식 릴리스와 더 안정적인 지원을 기다리는 것이 권장된다.

 

 

 


Reference

 

https://reactnative.dev/docs/the-new-architecture/landing-page

https://www.callstack.com/blog/experiment-with-new-architecture-of-react-native

https://semaphoreci.com/blog/react-native

https://www.elancer.co.kr/blog/view?seq=193

https://www.elancer.co.kr/blog/view?seq=195

https://velog.io/@ajm0718/React-Native-%EC%9E%91%EB%8F%99-%EC%9B%90%EB%A6%AC

https://litslink.com/blog/new-react-native-architecture