React Native New Architecture: 무엇이 하나가 아니라 네 영역인가

30초 요약

New Architecture는 하나의 Bridge 교체 기능이 아니다. 네 영역을 나눠 본다.

React Native 0.86에서는 New Architecture가 유일한 런타임이다. 라이브러리 문제가 생겼을 때 newArchEnabled=false로 돌아가는 해결책은 없다. 함수 호출, 네이티브 화면, 사건 순서 중 어디가 실패했는지 먼저 나눈다.

이 글을 관통하는 상황: 함수는 되는데 카메라 미리보기만 비어 있다

가상의 react-native-receipt-kit이 두 기능을 제공한다고 하자.

const result = await ReceiptScanner.scanReceipt()
 
return <CameraPreview onDetected={handleDetected} />

• scanReceipt()는 화면 없이 카메라·문서 인식 기능을 호출하는 네이티브 모듈 경계다.
• CameraPreview는 플랫폼 카메라 화면을 React 컴포넌트로 제공하는 네이티브 컴포넌트 경계다.

0.86으로 올린 뒤 scanReceipt()는 결과를 주지만 CameraPreview만 빈 화면이라면 “New Architecture 통신이 전부 깨졌다”는 진단은 너무 넓다. 같은 패키지 안에서도 함수 호출과 실제 플랫폼 화면은 다른 하위 체계를 지난다.

이 사례는 특정 실제 패키지의 동작을 재현하는 코드가 아니다. 공개 문서가 설명하는 실패 표면을 한 패키지 안에 모은 진단 예시다. 실제 조사에서는 사용하는 라이브러리의 현재 공식 지원 버전, 빌드 로그와 양쪽 플랫폼 실행 결과를 증거로 사용한다.

이 글에서는 다음을 미리 준비한 가상 증거 묶음인 fixture가 이미 수집한 결정적인 입력으로 사용한다. 실제 React Native가 자동으로 출력하는 고정 로그 형식이 아니라, fixture가 관찰 결과를 같은 형식으로 정리한 기록이다.

Android 함수 결과     scanReceipt → { pageCount: 1 }
iOS 함수 결과         scanReceipt → { pageCount: 1 }
Android 등록 기록     네이티브 화면 제공자 → 미등록
iOS 등록 기록         네이티브 화면 제공자 → 등록됨
Android 호스트 뷰     카메라 미리보기 뷰 없음
iOS 호스트 뷰         카메라 미리보기 뷰 있음

아래 분류를 읽기 전에 먼저 예측한다. 함수 결과는 양쪽에서 성공하고 Android의 네이티브 화면 제공자만 등록되지 않았다. 새 네이티브 모듈 체계, 새 렌더러·컴포넌트, Event Loop, Bridge 제거 기반 중 어디부터 조사해야 하는가?

새 아키텍처는 네 책임 영역의 묶음이다

가상의 영수증 패키지를 이 지도에 놓으면 다음과 같다.

이 표는 원인을 확정하지 않는다. 첫 조사 범위를 정한다. 예를 들어 빈 미리보기는 카메라 권한이나 플랫폼 화면의 생성·활성·해제 시점을 뜻하는 생명주기 문제일 수도 있으므로 실제 로그와 네이티브 화면을 본 뒤 범위를 더 좁힌다.

위 증거의 첫 답은 Android의 새 렌더러·네이티브 컴포넌트 등록 경계다. 함수 결과가 양쪽에서 성공했으므로 네이티브 모듈 전체 실패를 첫 원인으로 고르지 않는다. 사건 순서 증거도 없으므로 Event Loop부터 조사하지 않는다. Android 제공자 등록과 실제 호스트 뷰가 함께 실패한 좁은 경계부터 확인한다.

현재 0.86에서는 구 아키텍처로 돌아갈 수 없다

현재 앱 디렉터리에서 설치 버전과 남아 있는 설정 흔적은 다음처럼 읽기 전용으로 확인할 수 있다.

node -p "require('react-native/package.json').version"
rg -n "newArchEnabled|RCT_NEW_ARCH_ENABLED" android ios

첫 명령이 0.86.x를 출력하고 두 번째 검색에서 newArchEnabled=false가 보여도 구 런타임 사용 증거가 아니다.

공식 Architecture 소개 페이지의 일부 마이그레이션 문구가 기능을 비활성화해 이전 방식으로 돌아가는 선택인 opt-out의 과거 절차를 보여 줄 수 있다. 현재 실행 선택은 더 최신이고 버전이 명시된 0.82·0.84·0.86 릴리스 자료를 우선한다.

상호 운용 계층은 호환성이지 구 런타임이 아니다

따라서 다음 두 문장은 다르다.

이전 방식의 라이브러리가 상호 운용 계층을 통해 실행된다.
앱 전체가 Legacy Architecture로 실행된다.

첫 문장은 가능하지만 0.86에서 두 번째 문장은 아니다. 패키지가 실행된다는 사실만으로 새 네이티브 모듈·컴포넌트 API로 직접 전환됐다고 기록하지 않는다.

Bridge 제거는 모든 경계를 동기로 만든다는 뜻이 아니다

Legacy Architecture의 Bridge는 JavaScript와 네이티브 호출 값을 전달 가능한 데이터로 바꿔 비동기 큐로 보냈다. New Architecture는 이 통로를 직접 상호작용 기반으로 교체한다.

하지만 “Bridge가 없다”에서 다음 결론은 나오지 않는다.

• 모든 네이티브 함수가 동기 값을 반환한다.
• 모든 데이터 전달 비용이 사라진다.
• 모든 네이티브 작업이 JavaScript 스레드에서 실행된다.
• 라이브러리 호환성이 자동으로 보장된다.

동기·비동기, 입력 크기, 스레드와 취소 규칙은 2편에서 본 것처럼 각 API 계약에 남는다. 직접 상호작용을 가능하게 하는 JavaScript Interface(JSI)의 역할은 다음 4편에서 하나의 질문으로 분리한다.

한 패키지에서도 실패 표면을 나눈다

영수증 사례에서는 다음 순서가 된다.

1. scanReceipt() 결과와 CameraPreview 화면 실패를 별도 항목으로 재현한다.
2. Android와 iOS가 모두 실패하는지 플랫폼별로 나눈다.
3. 라이브러리의 React Native 0.86·New Architecture 공식 지원 범위를 확인한다.
4. 네이티브 모듈 등록 오류와 네이티브 컴포넌트 생성 오류를 빌드·실행 로그에서 분리한다.
5. 상호 운용 계층으로 실행되는지 새 API로 직접 구현됐는지를 지원 문서와 소스에서 구분한다.

새 아키텍처는 자동 성능 결과가 아니다

“0.86이므로 빨라졌다”는 검증 문장이 아니다. 변경 전후의 같은 사용자 흐름을 같은 조건에서 측정하고, JavaScript 응답·UI 응답·네이티브 호출 중 실제 병목을 나눈다. 구체적인 측정은 29편에 남긴다.

같은 상황을 다시 진단한다

문제       영수증 함수는 성공하지만 카메라 미리보기만 비어 있음
잘못된 판단 New Architecture 전체 통신이 깨졌으니 구 아키텍처로 끔
관찰       네이티브 모듈 함수와 네이티브 UI 컴포넌트의 결과가 다름
원인 후보  카메라 컴포넌트 등록·렌더·권한·생명주기 경계
행동       실패 표면과 플랫폼을 나누고 패키지 지원·빌드·실행 증거를 확인
검증       함수 결과, 실제 호스트 뷰와 카메라 입력을 Android·iOS에서 각각 확인

풀 리퀘스트에서는 다음을 확인한다.

• 현재 React Native 버전에서 실제 선택 가능한 아키텍처를 릴리스 자료로 확인했는가?
• 패키지 호환 문제를 모듈 함수, 네이티브 컴포넌트와 사건 순서로 나눴는가?
• 상호 운용 계층의 실행 성공을 새 API 전환 완료로 과장하지 않았는가?
• Bridge 제거를 모든 호출의 동기화·무비용 보장으로 오해하지 않았는가?
• New Architecture라는 이름을 성능 측정 결과 대신 사용하지 않았는가?

기억할 문장은 짧다.

New Architecture는 하나의 스위치가 아니라 책임이 나뉜 실행 지도다.

다음 글에서는 이 지도에서 JavaScript와 C++ 객체가 직접 상호작용할 기반을 제공하는 JSI의 역할만 분리해 살펴본다.