React-Native 에서는 2018년부터 Old architecture 에서 New architecture 로 넘어가는 대규모 업데이트를 진행해왔고, 최근 릴리즈에서 이를 드디어 옵트아웃(기본 활성화) 으로 만들었습니다.
New Architecture 는 대표적으로 아래의 세가지를 뜻합니다.
- Native Module (Legacy native module -> Turbo module)
- Renderer (Legacy renderer -> Fabric renderer)
- Communication layer (Bridge -> JSI, Bridgeless)
- 그리고 이를 도와주는 도구로 추가된 Codegen 이 있습니다.
(Turbo module 과 Fabric 은 Bridge 를 사용하지 않지만, Bridgeless 모드라는것은 무엇인가 의아하실 수 있습니다. Bridgeless 라는것은 React-Native 의 코어 일부분에서 사용하던 브릿지까지 모두 제거하는것을 뜻합니다.)
React-Native 는 초창기에는 메타의 주도로 코어에서 주요한 네이티브 모듈들을 관리했지만
이를 코어에서 제거한 뒤 모두 커뮤니티가 관리하도록 돌리고 커뮤니티 기반으로 성장해왔습니다.
이때문에 동일한 목적과 기능을 갖춘 라이브러리여도, 만든이는 다른 다양한 커뮤니티 모듈들을 가지고 있습니다.
이 모든 커뮤니티 모듈들이 New architecture 로 전환하는것은 상당히 많은 시간과 노력이 필요합니다.
React-Native 팀은, 이 문제를 해결하기 위해서 두가지 전략을 세웠습니다.
https://github.com/reactwg/react-native-new-architecture/discussions/167
커뮤니티 모듈의 마이그레이션 지원
EAS(Expo CI) 에서 가장 많이 설치가 되는 상위 라이브러리들에 대해서 직접 수정/테스트, 그리고 원활하게 마이그레이션을 할 수 있도록 기술적인 지원을 했습니다.
그리고 이 과정을 스프레드 시트 로 커뮤니티에 공유 및 관리하였고, 현재는 react-native-directory 로 이전하여 New architecture 가 지원되는 라이브러리들에 뱃지로 표기하는 방식으로 관리하고 있습니다.
상호 운용 계층 (Interop layer)
현실적으로 인기가 많은 라이브러리들에 대해서 마이그레이션 지원을 한다고 해도, react-native-fast-image 와 같이 사실상 메인테이너가 관리를 포기하여 연락조차 되지 않는 라이브러리의 경우에는, fork 해서 새로운 배포를 만드는 것 이외에는 New architecture 를 적용할 방법이 없습니다.
이러한 커뮤니티 생태계로 인한 문제로 인하여, Old architecture 기반으로 만들어진 모듈들이 New architecture 앱에서도 잘 동작할 수 있도록 v0.72 부터 상호 운용 계층을 도입하였습니다. 현재는 여러가지 안정화 단계를 거쳐 대부분의 단순한 라이브러리에서는 잘 동작하고 있습니다.
처음 도입 당시에는 react-native.config.js 에서 unstable_reactLegacyComponentNames 필드에 직접 라이브러리를 지정한 라이브러리들만 interop layer 위에서 동작했지만, v0.74 부터 New architecture 가 지원되지 않는 라이브러리들에 대해서는 자동으로 Interop layer 가 적용되도록 개선이 되었습니다.
현재 React-Native 에서 라이브러리들이 어떤 아키텍쳐인지 판별되는 방식은 대략적으로 다음과 같습니다.
만약 라이브러리 관리자이고 New architecture 지원 이전에 Interop layer 에서 지원을 하고싶지만, 동작이 잘 안된다면 아래의 내용들을 확인해보시면 좋을 것 같습니다.
-
앱을 빌드를 하는 과정에서 react-native-cli 의 아래 두가지 패키지의 스크립트를 통해, 설치되어 있는 라이브러리들의 config 를 추출하고, 이 config 를 기반으로 빌드와 auto linking 등이 이루어집니다.
-
레거시 뷰 매니저를 통해 등록된 네이티브 모듈에 작성된 모듈 이름과 클래스 네임등을 기반으로 interop layer 적용을 합니다.
두가지 방식 모두 정규식 혹은 텍스트 비교등을 기반으로 동작을 하는 방식이라서, 정확하지 않다는 단점이 있습니다.
예를 들어 아래와 같은 문제들이 발생할 수 있습니다.
- old architecture 이지만, 주석으로 처리해놓은 new architecture 관련 설정들이 있다면 new architecture 의 auto linking 파이프라인을 타고 빌드 에러로 이어질 수 있거나
- 클래스 네임에 prefix 가 붙어있어서 Interop layer 에서 동작하지 않는다거나
때문에 관리하는 라이브러리에서 아직 New architecture 를 지원하지 않는다면, Interop layer 에서 잘 동작하게 만들기 위해서는 New architecture 와 관련된 설정들은 주석으로라도 미리 추가하시지 않는것이 좋습니다.
