들어가며..

최근 회사에서 내 리소스는 Blai 개발에 120% 쓰이고 있었고, ANTTIME은 솔직히 방치되어 있었다. 토큰스왑 페이지만 간간히 개선하고 본 앱은 업데이트 거리가 별로 없었기 때문이다. 그러다가 지지난주에 본 앱에 유지보수성 업데이트로 React Native 버전업을 진행하게 되었고, 이 업데이트로 RN New Architecture와 새로운 렌더엔진인 Fabric, 새로운 JS엔진인 Hermes 등을 모두 지원하게 되었다. (눈물겨운 빌드 설정의 시간이었다ㅠㅠ)

사실 버전업을 강행하게 된 계기는 최근 플레이스토어에서 ANTTIME을 16kb 메모리 페이지를 지원하는 버전으로 업데이트하라고 강제했기 때문이다. (관련링크) 그런데 16kb 메모리 페이지를 지원하는 안드로이드 API 타겟은 15부터고, API 15를 지원하는 리액트네이티브 버전은 0.76.4이상이기 때문에(우리앱은 0.74.6이었음) 이를 근소하게 더 충족하는 0.77로 버전업을 진행한 것이다.

하여튼 이래저래 급하게 진행했던 0.77 업데이트는 지난 RN 버전업보다 훨씬 더 고통스러웠다. 근본적인 아키텍처 변화가 있었기 때문에 네이티브 코드들의 수정 사항들이 많았기 때문이다. 그렇게 눈물 흘리며 버전업을 하면서 든 의문. 'RN팀은 왜 굳이 New Architecture로 전환해서 나를 힘들게 하는가?' 뭐 더 좋아지긴 하겠지. 근데 왜 좋은지를 알고나 업데이트 해야될 것 같아서 공부하게 되었다.

지금부터 New Architecture를 통해 뭐가 달라졌는지, 왜 변화했는지 등을 설명하겠다.

1. 통신 방식의 본질적인 변화

기존 React Native는 브릿지를 통해 JavaScript와 네이티브 단이 통신하는 구조였다.

기존 통신 방식 (브릿지): JS 객체를 JSON 문자열로 직렬화(Serialization)하고, 브릿지를 통해 비동기적으로 전송한 후, 네이티브 단에서 다시 객체로 역직렬화(Deserialization)하여 사용하는 방식이었다. 이 과정은 통신 오버헤드를 발생시키는 주요 원인이었으며, 특히 대량의 데이터나 빈번한 호출이 발생하는 복잡한 상황에서 성능 병목을 유발했다.

이를 비유하자면, 마치 서로 다른 언어를 사용하는 두 사람이편지를 쓰고(직렬화), 우체국(브릿지)을 통해 비동기로 전달하고, 받는 쪽이 편지를 번역해서 읽는(역직렬화) 방식과 같았다. 비동기적인 전달과 번역 과정에서 시간이 소요되는 것은 당연한 일이다.

새로운 통신 방식 (JSI): 브릿지는JSI(JavaScript Interface)로 대체되었다. JSI는 C++ 기반의 경량 계층으로, JS 엔진인 Hermes가 네이티브 C++ 객체에 대한직접적인 참조(Reference, 혹은 심볼)를 보유하게 한다. 이를 통해 직렬화/역직렬화 과정 없이 동기적 함수 호출이 가능해졌으며, 통신 비용을 거의 0에 가깝게 줄였다.

새로운 방식은 뭐랄까... 마치 암구호나 수화(JSI)처럼 서로 심볼을 정해놓고 그걸로 멀리 떨어져 있는 사람에게 직접적으로 명령을 내리는(Native 객체 직접 호출) 방식과 유사하다. 중간 과정 없이 즉각적이고 동기적인 소통이 가능해진 것이다.

즉, 통신 방식이 데이터를 복사해서 전달하고 번역하는 방식에서 심볼을 통해 객체를 직접 호출하는 방식으로 혁신적으로 변화된 것이다. 이런 방식을 통해 RN 비호가들에게 맨날 지적당했던 성능문제가 대폭 감소하게 되었다.

2. 성능 혁신의 또 다른 핵심 요소: Hermes와 Fabric

새로운 아키텍처를 구현하고 성능을 끌어올린 핵심 동력은 Hermes와 Fabric이다. React Native 0.76 버전부터는 새로운 아키텍처가 기본으로 활성화되지만, 기존 프로젝트를 마이그레이션하거나 설정을 명확히 확인하려면 다음 네이티브 설정을 검토해야 한다.

A. Hermes (자바스크립트 엔진)

Hermes는 React Native의 모바일 환경 최적화를 위해 개발된 JS 엔진으로, 기존에 사용되던 JavaScriptCore(JSC) 엔진 대비 다음과 같은 이점을 제공한다.

빠른 앱 시작 속도: JS 코드를 실행 전에 미리 **바이트코드(Bytecode)**로 컴파일하여 배포한다. 앱 실행 시 파싱 및 컴파일 단계를 생략하고 바이트코드만 로드하여 실행하므로 앱 구동 시간이 크게 단축된다.

낮은 메모리 사용량: 모바일 환경에 최적화되어 엔진 자체의 메모리 사용량이 적어 리소스 효율성이 높다.

JSI 기본 지원: 새로운 아키텍처의 기반인 JSI를 처음부터 통합 지원하도록 설계되었다.

[Hermes 활성화 설정]

Hermes는 새로운 아키텍처 활성화 시 자동으로 사용되지만, 명시적인 확인이 필요하다. expo를 쓰는 프로젝트가 아니라 우리회사 플젝처럼 bare RN 프로젝트면 아래 파일들에 직접 추가해줘야한다. (각각 코틀린과 스위프트 문법으로 되어있음)

Android(android/gradle.properties):

hermesEnabled=true

iOS(ios/Podfile):

# Podfile 내 'use_react_native!' 블록 안에서 확인
use_react_native!(
:path => config[:react_native_path],
# ... 기타 설정 ...
:hermes_enabled => true # 이 부분이 Hermes를 활성화한다.
)

B. Fabric (새로운 렌더링 시스템)

Fabric은 기존의 UI Manager(Paper)를 대체하는 C++ 기반의 렌더링 시스템이다.

동시성 렌더링 (Concurrent Rendering): React 18의 핵심 기능인 동시성 모드를 지원한다. 이는 긴급한 사용자 이벤트(클릭 등)에 우선순위를 부여하여, 복잡한 렌더링 작업 중에도 UI가 멈추지 않고부드러운 사용자 경험을 제공한다.

C++ 코어 통합: Fabric은 JSI를 통해 JS와 동기적으로 통신하며, 레이아웃 계산을 담당하는 Shadow Tree가 C++ 코어 내로 통합되어 UI 업데이트의 효율성과 정확성을 높인다.

타입 안정성: Codegen 도구를 통해 JS와 Native 컴포넌트 간의 속성 전달 규약이 자동으로 생성되므로, 타입 안정성이 보장되어 런타임 오류가 줄어든다.

[Fabric 및 New Architecture 활성화 설정]

Fabric은 Turbo Modules와 함께 새로운 아키텍처 플래그를 통해 활성화된다.

Android(android/gradle.properties):

newArchEnabled=true

iOS(ios/Podfile):

# Podfile의 시작 부분 (Configuration Block 내)
ENV['RCT_NEW_ARCH_ENABLED'] = '1' # '1' 또는 'true'로 설정하여 새로운 아키텍처를 활성화한다.

3. React Native의 미래는 과연?

(사진은 New Architecture 기본 사용 버전인 0.76을 발표하던 ReactConf 이미지)

한 3년 전에 RN 사용하는 대표 회사였던 air-bnb가 RN 사용을 대폭 포기하면서 RN의 미래에 비관적인 얘기들이 많았다고 한다. 또한 욕나오는 버전관리로 인해 어디서나 RN의 개발자 경험에 대한 저주들을 되게 많이 들을 수 있었는데...

요새 아키텍처 개선과 새로운 프레임워크 Expo의 등장으로 React Native는 여론 반등 분위기를 누리고 있다고 한다. 새로운 아키텍처 덕분에 Flutter 대비 성능 격차는 거의 해소되었다고 하고, Expo는 욕나오는 CI/CD 및 빌드를 클라우드 기반으로 처리해준다. 다음 프로젝트는 꼭 Expo를 해봐야겠다.