React Native 0.82부터 레거시 아키텍처를 못 쓰는 이유

😀 개요

안녕하세요 😀

오늘은 React Native 0.82부터 달라진 아키텍처 흐름에 대해서 얘기해 보려고 합니다.

이전에 리액트 네이티브의 새로운 아키텍처는 뭘까?라는 글을 작성한 적이 있습니다. 그때는 Bridge, JSI, Yoga 같은 개념을 중심으로 "왜 기존 구조가 한계에 부딪혔는가?"를 정리했는데요.

이번에는 그 다음 단계입니다.

React Native 0.76부터 New Architecture가 기본값이 되었고, React Native 0.82부터는 레거시 아키텍처를 끄고 예전 방식으로 돌아가는 선택지가 사실상 사라졌습니다.

처음 이 내용을 보면 이런 생각이 들 수 있습니다.

"기존 Bridge 구조도 잘 돌아가던 거 아닌가?"

"왜 굳이 New Architecture만 쓰게 만든 걸까?"

"그럼 기존 프로젝트는 바로 문제가 생기는 걸까?"

저도 처음에는 단순히 "성능 개선을 위해 구조를 바꾼 것" 정도로만 이해했습니다. 그런데 공식 문서를 읽어보니, 이 변화는 단순한 성능 개선이라기보다는 React Native가 앞으로 어떤 방향으로 가려는지 보여주는 기준점에 가깝다고 느꼈습니다.

그래서 이번 글에서는 React Native 0.82의 New Architecture Only가 정확히 어떤 의미인지, 그리고 왜 Bridge 기반 구조를 계속 유지하기 어려웠는지 정리해 보겠습니다.

🔍 기존 React Native 구조는 어떤 문제가 있었을까?

React Native의 가장 큰 장점은 하나의 코드로 iOS와 Android 앱을 만들 수 있다는 점입니다.

하지만 내부적으로는 JavaScript 세계와 Native 세계가 완전히 다릅니다. JavaScript는 우리가 작성하는 React 코드가 실행되는 영역이고, Native는 실제 iOS와 Android UI가 그려지고 기기 기능이 동작하는 영역입니다.

기존 React Native는 이 두 영역을 Bridge라는 개념으로 연결했습니다.

Bridge는 쉽게 말하면 "통역사" 같은 역할입니다.

JavaScript 쪽에서 "이 버튼을 그려줘", "이 네이티브 기능을 실행해줘"라고 요청하면, 이 요청을 JSON 형태로 바꿔서 Native 쪽으로 넘깁니다. Native 쪽은 그 메시지를 다시 해석해서 실제 UI를 그리거나 네이티브 기능을 실행합니다.

흐름을 단순하게 보면 아래와 같습니다.

JavaScript 코드 작성
→ Bridge를 통해 메시지 전달
→ JSON 직렬화
→ Native 영역에서 역직렬화
→ 실제 UI 렌더링 또는 네이티브 기능 실행

여기까지만 보면 크게 문제가 없어 보입니다.

그런데 앱이 복잡해지고, 리스트가 길어지고, 애니메이션이 많아지고, 사용자의 터치에 바로 반응해야 하는 화면이 늘어나면서 Bridge 구조의 한계가 점점 커졌습니다.

가장 큰 문제는 "항상 중간 통역 과정을 거쳐야 한다"는 점입니다.

JavaScript와 Native가 직접 대화하는 것이 아니라, 메시지를 만들고, JSON으로 바꾸고, 큐에 쌓고, 다시 해석하는 과정을 반복합니다. 이런 과정이 많아지면 사용자는 앱이 살짝 늦게 반응하거나, 스크롤 중 화면이 비거나, UI가 한 박자 늦게 움직이는 느낌을 받을 수 있습니다.

📌 왜 New Architecture가 필요했을까?

공식 문서에서는 기존 구조의 한계를 크게 몇 가지로 설명합니다.

첫 번째는 Bridge를 통한 직렬화 비용입니다.

직렬화는 데이터를 다른 영역으로 보내기 위해 특정 형식으로 바꾸는 과정입니다. 쉽게 말하면 JavaScript가 Native에게 바로 말하지 못하고, 중간에서 전달용 문서로 바꿔 보내는 느낌입니다.

작은 데이터라면 큰 문제가 되지 않을 수 있습니다.

하지만 리스트 스크롤, 제스처, 애니메이션처럼 자주 발생하는 작업에서는 이 비용이 반복해서 쌓입니다. 특히 UI가 60FPS 이상으로 부드럽게 움직여야 하는 상황에서는 작은 지연도 사용자가 바로 느끼게 됩니다.

두 번째는 비동기 구조의 한계입니다.

기존 Bridge는 기본적으로 비동기 방식으로 동작했습니다. 비동기 자체가 나쁜 것은 아닙니다. 오히려 메인 스레드를 막지 않는다는 장점도 있습니다.

하지만 어떤 UI 작업은 사용자의 입력에 맞춰 즉시 반응해야 합니다.

예를 들어 툴팁 위치를 현재 레이아웃 기준으로 바로 잡아야 하거나, 터치 이벤트에 맞춰 화면을 즉시 갱신해야 하는 경우가 있습니다. 이런 상황에서 모든 작업이 비동기 큐를 거치면 중간 상태가 화면에 보이거나, UI가 어색하게 튀는 문제가 생길 수 있습니다.

세 번째는 React의 최신 기능을 제대로 활용하기 어렵다는 점입니다.

React는 Concurrent Rendering, Suspense, Transition 같은 기능을 통해 UI 업데이트의 우선순위를 더 유연하게 다루는 방향으로 발전하고 있습니다.

그런데 React Native의 내부 구조가 과거 Bridge 중심으로 묶여 있으면, 이런 최신 React 기능을 모바일 환경에서 자연스럽게 활용하기 어렵습니다.

결국 New Architecture는 단순히 "Bridge가 느리니까 바꾸자"가 아니라, React Native가 앞으로의 React와 같이 가기 위해 필요한 구조적 변화라고 볼 수 있습니다.

🧩 React Native 0.82에서 달라진 핵심

React Native 0.76에서는 New Architecture가 기본값이 되었습니다.

그리고 React Native 0.82부터는 New Architecture가 유일한 아키텍처가 되었습니다.

즉, 예전처럼 Android에서 newArchEnabled=false를 설정하거나, iOS에서 RCT_NEW_ARCH_ENABLED=0으로 레거시 아키텍처를 강제로 끄는 방식이 더 이상 의미가 없어졌습니다.

이 변화가 의미하는 것은 분명합니다.

React Native 팀은 이제 레거시 Bridge 구조를 유지하면서 새 기능을 얹는 방식이 아니라, New Architecture를 기준으로 앞으로의 기능을 발전시키겠다는 방향을 확정한 것입니다.

New Architecture의 큰 축은 아래와 같습니다.

1. New Native Module System
2. New Renderer
3. Event Loop
4. Removing the Bridge
5. Hermes 개선

이름만 보면 어렵지만, 하나씩 보면 기존 문제를 해결하기 위한 구조입니다.

🚀 JSI는 왜 중요한 걸까?

New Architecture에서 자주 등장하는 개념이 JSI입니다.

JSI는 JavaScript Interface의 약자입니다.

쉽게 말하면 JavaScript와 Native가 Bridge를 거치지 않고 더 직접적으로 대화할 수 있게 해주는 인터페이스입니다.

기존 구조에서는 Native 함수를 호출하려면 메시지를 만들고, Bridge를 거치고, JSON으로 직렬화하는 과정이 필요했습니다. 반면 JSI 기반 구조에서는 JavaScript가 Native 함수를 더 직접적으로 호출할 수 있습니다.

예전 방식은 이런 느낌입니다.

nativeModule.getValue(value => {
  nativeModule.doSomething(value);
});

콜백을 통해 값을 받고, 그 값을 다시 다른 함수에 넘기는 구조입니다.

반면 New Architecture에서는 아래처럼 더 직접적인 호출이 가능해집니다.

const value = nativeModule.getValue();
nativeModule.doSomething(value);

물론 실제 내부 구현은 훨씬 복잡합니다.

하지만 앱 개발자 관점에서는 "JavaScript와 Native 사이의 대화 비용이 줄어들고, 동기적으로 필요한 값을 가져올 수 있는 길이 생겼다" 정도로 이해하면 좋을 것 같습니다.

🧱 New Renderer는 어떤 역할을 할까?

New Architecture에서 또 중요한 개념은 New Renderer입니다.

기존 렌더러는 UI 트리를 다루는 방식에서 여러 제약이 있었습니다. UI 업데이트가 많아지거나, 사용자 입력처럼 우선순위가 높은 작업이 들어오면 더 유연하게 처리하기 어려웠습니다.

New Renderer는 이 부분을 개선하기 위해 등장했습니다.

공식 문서에서는 새로운 렌더러가 여러 스레드와 여러 우선순위의 업데이트를 다룰 수 있다고 설명합니다. 쉽게 말하면, 모든 UI 작업을 같은 줄에 세워두고 순서대로 처리하는 것이 아니라, 급한 작업과 덜 급한 작업을 더 똑똑하게 나눠 처리할 수 있게 된 것입니다.

예를 들어 사용자가 화면을 터치하는 작업은 즉시 반응해야 합니다.

반면 화면 아래쪽에 천천히 나타나는 리스트 업데이트는 조금 늦어도 사용자가 크게 불편하지 않을 수 있습니다.

New Renderer는 이런 우선순위를 React의 최신 기능과 함께 더 자연스럽게 처리하기 위한 기반입니다.

또 하나 중요한 점은 C++ 기반의 공유 코어입니다.

렌더러의 핵심 로직을 여러 플랫폼에서 공유하면 iOS와 Android 사이의 동작 차이를 줄일 수 있습니다. 크로스 플랫폼 개발에서 가장 피곤한 부분 중 하나가 "iOS에서는 되는데 Android에서는 다르게 보이는 문제"인데, 이런 차이를 줄이는 방향으로 아키텍처가 바뀌고 있다고 볼 수 있습니다.

⚡ Hermes는 여기서 어떤 역할을 할까?

Hermes는 React Native에 최적화된 JavaScript 엔진입니다.

공식 문서 기준으로 Hermes는 React Native에서 기본으로 사용되며, 많은 앱에서 JavaScriptCore와 비교했을 때 시작 시간, 메모리 사용량, 앱 크기 측면에서 이점을 기대할 수 있다고 설명합니다.

Hermes의 핵심은 앱 실행 전에 JavaScript를 Hermes Bytecode로 미리 컴파일한다는 점입니다.

쉽게 말하면 앱이 켜질 때 모든 JavaScript를 처음부터 해석하는 것이 아니라, 실행하기 좋은 형태로 미리 준비해 두는 방식입니다. 그래서 앱 시작 속도에 영향을 줄 수 있습니다.

React Native 0.82에서는 Hermes V1도 실험적으로 선택할 수 있게 되었습니다.

다만 여기서 중요한 점은 "Hermes V1을 당장 모든 프로젝트에 적용하자"가 아닙니다.

공식 블로그에서도 Hermes V1은 아직 실험적인 단계이고, 직접 사용하려면 React Native를 소스에서 빌드해야 한다고 설명합니다. 따라서 일반적인 서비스 앱이라면 당장 Hermes V1을 적용하기보다는, 현재 프로젝트가 Hermes를 제대로 사용하고 있는지 먼저 확인하는 편이 현실적입니다.

확인 코드는 간단합니다.

const isHermes = () => !!global.HermesInternal;

console.log('Hermes 사용 여부:', isHermes());

단, 이 값이 있다고 해서 항상 최적화된 Hermes Bytecode를 제대로 쓰고 있다는 뜻은 아닐 수 있습니다. 공식 문서에서도 release build에서 실제 전후 성능을 비교하는 것을 권장합니다.

🧪 기존 프로젝트는 어떻게 접근해야 할까?

React Native 0.82부터 New Architecture만 쓴다고 해서 모든 기존 프로젝트가 바로 망가지는 것은 아닙니다.

공식 블로그에서는 아직 New Architecture로 마이그레이션하지 않은 프로젝트라면 먼저 React Native 0.81 또는 Expo SDK 54에서 New Architecture를 활성화하고 확인한 뒤 0.82로 올리는 흐름을 권장합니다.

제가 정리한 기준은 아래와 같습니다.

1. 현재 React Native 버전 확인
2. 사용 중인 주요 네이티브 라이브러리 확인
3. React Native 0.81 또는 Expo SDK 54에서 New Architecture 활성화
4. Android/iOS 모두 빌드 확인
5. 자주 쓰는 화면 중심으로 QA
6. 문제가 없으면 0.82 이상으로 업그레이드 검토

특히 네이티브 모듈을 많이 사용하는 앱이라면 라이브러리 호환성을 먼저 확인하는 것이 중요합니다.

카메라, 지도, 결제, 푸시, 생체 인증, 파일 시스템처럼 Native와 강하게 연결된 라이브러리는 New Architecture 대응 여부에 따라 이슈가 생길 수 있습니다.

이때 무작정 버전을 올리기보다, 프로젝트에서 실제로 쓰는 라이브러리 목록을 먼저 뽑고 하나씩 확인하는 편이 안전합니다.

🤔 그럼 개발자는 무엇을 알아야 할까?

앱 개발자가 React Native 내부 구조를 전부 외울 필요는 없다고 생각합니다.

하지만 왜 이런 변화가 생겼는지는 알고 있어야 합니다.

React Native는 더 이상 "웹 개발자가 모바일 앱도 만들 수 있게 해주는 도구" 정도에 머물지 않고 있습니다. React의 최신 기능을 모바일 환경에서도 제대로 쓰게 하고, iOS와 Android뿐 아니라 더 많은 플랫폼을 같은 구조로 다루려는 방향으로 가고 있습니다.

그래서 앞으로 React Native를 공부한다면 단순히 컴포넌트 사용법만 보는 것보다 아래 개념은 한 번쯤 정리해 두는 게 좋습니다.

Bridge: 기존 JS와 Native 사이의 비동기 통신 구조
JSI: JS와 Native가 더 직접적으로 소통하게 해주는 인터페이스
Fabric: React Native의 새로운 렌더링 시스템
TurboModule: 새로운 Native Module 시스템
Hermes: React Native에 최적화된 JavaScript 엔진
Codegen: JS와 Native 사이 타입 계약을 생성해주는 도구

처음에는 어렵게 느껴질 수 있습니다.

저도 처음에는 JSI, Fabric, TurboModule이 전부 따로 노는 개념처럼 보였습니다. 그런데 Bridge의 한계를 먼저 이해하고 나니, 이 개념들이 결국 같은 방향을 보고 있다는 게 조금씩 보였습니다.

결국 핵심은 하나입니다.

JavaScript와 Native 사이의 거리를 줄이고, React의 최신 렌더링 모델을 모바일에서도 제대로 쓰기 위한 변화입니다.

🫡 마무리

이번 글을 정리하면서 느낀 점은 React Native의 변화가 생각보다 빠르게 현실로 들어왔다는 것입니다.

예전에는 New Architecture가 "언젠가 적용될 새로운 구조"처럼 느껴졌습니다. 그런데 이제는 React Native 0.82부터 그 구조가 기본이 아니라 유일한 선택지가 됐습니다.

개발자 입장에서는 부담스럽게 느껴질 수도 있습니다.

하지만 반대로 생각하면 React Native가 더 이상 과거 Bridge 구조의 한계를 안고 가는 것이 아니라, 앞으로의 React 생태계와 더 잘 맞는 방향으로 정리되고 있다는 뜻이기도 합니다.

리액트 네이티브를 단순히 사용법만 익히는 것도 중요하지만, 왜 이런 구조 변화가 생겼는지 이해하면 버전 업그레이드나 라이브러리 선택을 할 때 훨씬 덜 흔들리게 됩니다.

다음 글에서는 실제 프로젝트에서 React Native New Architecture로 넘어갈 때 어떤 라이브러리를 먼저 확인해야 하는지, 그리고 마이그레이션 체크리스트를 어떻게 잡으면 좋을지 정리해 보겠습니다.

---

참고 자료

• React Native 공식 블로그: New Architecture is here
• React Native 공식 블로그: React Native 0.82 - A New Era
• React Native 공식 문서: Using Hermes
• React Native 공식 문서: Fabric