React Native 0.85: 새로운 아키텍처 기반의 '다듬기' 업그레이드

React Native 0.85이 출시되었을 때, 공식 측에서는 '혁명적인' 슬로건을 내걸지 않았습니다. 이번 업데이트는 본질적으로 새 아키텍처가 이미 자리 잡은 상황에서 애니메이션, 디버깅, 테스트 등 인프라를 체계적으로 다듬는 작업이었기 때문입니다.

현재 기술 스택 선정 단계에 있거나, 구 버전에서 업그레이드를 고려 중이라면 이번 버전이 주는 신호는 다음과 같습니다:새 아키텍처는 이미 기본 전제로 간주할 수 있으며, 향후 작업은 경험과 생태계 품질에 집중될 것입니다.

아래에서는 세 가지 측면에서 살펴보겠습니다: 0.85가 가져온 핵심 변화, 현재 React Native 아키텍처의 핵심 사항, 그리고 Flutter, Ionic, 네이티브 방식과의 성능 및 생태계 비교입니다.

0.85가 가져온 것은 무엇인가?

통합 애니메이션 백엔드: 핵심 경로를 '공식 통제' 하에

0.85에서 가장 주목할 점은 공유 애니메이션 백엔드(Shared Animation Backend) 도입입니다. 오랫동안 React Native 자체 Animated와 커뮤니티의 Reanimated는 사실상 두 개의 세계였습니다. 하나는 단순한 시나리오에 치우쳐 있고, 다른 하나는 성능과 표현력을 위해 많은 로직을 자체적으로 처리했습니다.

0.85에서는 애니메이션 실행의 기본 로직이 RN Core로 내려갔고, 공식 팀과 Software Mansion이 함께 애니메이션 스케줄링 및 실행 경로를 하나의 공통 백엔드로 통합했습니다. 아키텍처 측면에서 이는 몇 가지 실질적인 의미를 갖습니다:

• 애니메이션 스케줄링이 더 이상 '서드파티 마법'에 전적으로 의존하지 않습니다. 핵심 로직이 메인 저장소에 들어가면서 RN 버전에 맞춰 일관성 테스트와 성능 최적화를 수행할 수 있습니다.

• 네이티브 드라이버의 적용 범위가 확대되어 레이아웃 관련 속성을 네이티브 드라이버로 구동할 수 있습니다. 이러한 시나리오는 이전에는 '작성은 가능하지만 많이 의존하기 어려운' 부분이었습니다.

• 비즈니스 팀의 경우 애니메이션 계층 선택에 대한 부담이 줄어듭니다. 공식 및 주요 애니메이션 라이브러리의 조합을 더 안심하고 사용할 수 있으며, 나중에 누가 새 아키텍처를 따라오지 못할까 걱정할 필요가 없습니다.

앱의 애니메이션 양이 많지 않다면 이 변경이 즉시 경험에 영향을 미치지는 않을 수 있습니다. 그러나 복잡한 상호작용과 애니메이션이 많은 제품의 경우 '장기적인 건강성'에 유리합니다.

디버깅 체인 정리: 다중 클라이언트, TLS, 테스트 프리셋 분리

또 다른 몇 가지 변경 사항은 겉으로 보기에는 눈에 띄지 않지만, 일상적인 개발 경험에 영향을 미칩니다:

• Chrome DevTools Protocol 기반의 여러 디버깅 클라이언트를 동시에 지원합니다. 간단히 말해, React Native DevTools, IDE 플러그인, 자동화 디버깅/AI 도구 등을 동시에 연결할 수 있으며, 하나의 '유일한 디버깅 연결'을 놓고 경쟁할 필요가 없습니다.

• Metro dev server가 TLS 구성을 지원합니다. HTTPS/WSS가 필요한 많은 엔터프라이즈 프로젝트의 경우, 이전에는 로컬 디버깅을 위해 구성을 변경하거나 자체 서명 프록시를 설정해야 했지만, 이제는 프레임워크 수준에서 정면으로 해결할 수 있습니다.

• Jest 프리셋이 독립 패키지로 분리되었습니다. 이는 단순히 디렉토리 구조 변경처럼 보이지만, 모노레포 및 크로스 플랫폼 프로젝트에 매우 유용합니다. 테스트 구성이 더 이상 RN 메인 패키지에 강하게 결합되지 않으며, 업그레이드 주기를 더 유연하게 가져갈 수 있고, 회사 내부 스캐폴딩에 더 쉽게 통합할 수 있습니다.

이러한 변경 사항의 공통점은 갑자기 멋진 기능을 해제하는 것이 아니라, 도구 체인에서 낭비하는 시간을 줄여준다는 것입니다.

현재 React Native 아키텍처의 핵심 이해

버전 번호를 가려 놓고 지금 React Native를 논할 때 '새 아키텍처'를 피하기 어렵습니다. 주요 사항을 간단히 복습하면 프레임워크 수준의 비교에 도움이 됩니다.

Bridge에서 JSI로: 통신 방식의 세대 교체

구세대 React Native는 '브리지'에 의존했습니다: JS와 네이티브 간은 직렬화된 메시지 큐를 통해 통신하며, 본질적으로 비동기적이고, 언어 간 데이터 전송을 위해 JSON 수준의 패킹 및 언패킹이 필요했습니다.

새 아키텍처는 JSI로 이 계층을 직접 교체했습니다. JS가 C++ 객체의 참조를 얻을 수 있으며, 양측이 '직접 호출'에 가까운 방식으로 상호작용할 수 있습니다.

이로 인한 직접적인 결과:

• 모든 호출을 강제로 비동기 작업으로 설계할 필요가 없으며, 시나리오에 따라 동기/비동기를 선택할 수 있습니다.

• 직렬화/역직렬화 오버헤드가 크게 줄어들어 CPU가 부족하거나 호출 빈도가 높은 시나리오에서 차이가 두드러집니다.

• 작업을 여러 스레드에 더 자연스럽게 분산할 수 있으며, 모든 트랜잭션을 설명력이 낮은 '브리지 큐'에 몰아넣을 필요가 없습니다.

스택 선정 측면에서 이는 '브리지가 성능 병목이다'라는 이전 인식을 'JSI와 TurboModules를 어떻게 사용하느냐에 달렸다'로 업데이트해야 함을 의미합니다.

TurboModules와 Fabric: 모듈 및 렌더링의 재구성

새 아키텍처의 다른 측면은 TurboModules(새로운 네이티브 모듈 시스템)와 Fabric(새로운 렌더러)입니다.

• TurboModules는 지연 로딩과 타입 안전한 언어 간 호출을 강조하며, Codegen을 통해 TypeScript/Flow 타입에서 C++ 바인딩 코드를 생성하여 글루 레이어 유지보수 비용을 줄입니다.

• Fabric은 기존 UI 관리 계층을 대체하여 렌더링 흐름을 더 일관되게 만들고(Yoga 레이아웃, diff, commit 포함) 여러 플랫폼에 더 잘 적응합니다.

비즈니스 측에 미치는 직접적인 영향:

• 네이티브 모듈을 직접 작성하는 비용과 인지 부담이 낮아집니다. 특히 여러 플랫폼과 여러 버전이 공존하는 대규모 프로젝트에서 그렇습니다.

• 리스트나 많은 뷰 업데이트가 있는 시나리오에서 Fabric은 더 안정적으로 예측 가능한 성능을 제공하며, '간헐적인' 끊김이나 이상한 렌더링 버그를 줄입니다.

React Native 0.85는 아키텍처에 획기적인 변화를 가져오지 않았습니다. 대신, 이미 이 새 아키텍처를 사용하고 있다는 것을 전제로 하여 '정상 유지 관리 기간'으로의 전환을 시작했습니다. 이것이 스택 선정 측면에서의 핵심 신호입니다:프레임워크 자체의 구조는 기본적으로 확정되었으며, 이후 초점은 경험과 생태계 품질로 이동할 것이지, 또 한 번의 완전한 개편이 아닙니다.

성능: React Native 0.85는 어디에 위치하는가?

기술 스택 선정에서 성능을 피할 수 없으므로, React Native를 다른 경로와 함께 살펴보겠습니다.

Flutter와의 차이: 렌더링 권한과 제어 가능성

• Flutter는 자체 렌더링 엔진(Skia 등)을 가지고 있어 레이아웃부터 드로잉까지 모두 자체 제어 하에 있으며, 성능 특성이 비교적 명확합니다. 시작, 스크롤, 애니메이션이 한 번 조정되면 결과가 비교적 안정적이며, '올인원'에 가깝습니다.

• React Native는 여전히 플랫폼 네이티브 컴포넌트를 사용하여 UI를 렌더링하며, 중간에 JS → Native 호출 계층이 하나 더 있습니다. 이 계층은 새 아키텍처에서 더 얇아졌지만 원칙적으로는 여전히 존재합니다.

따라서 극단적인 성능 테스트에서 Flutter는 일반적으로 더 나은 첫 화면 시간과 더 부드러운 긴 리스트 스크롤을 제공합니다. 복잡한 UI 및 애니메이션 시나리오에서 최고 성능에 대한 극한의 요구가 있다면 Flutter가 더 유리합니다.

그러나 대부분의 비즈니스 앱에서 병목은 엔진 자체보다는 데이터 구성, 렌더링 전략, 애니메이션 설계에서 발생합니다. React Native 새 아키텍처 + 새 애니메이션 백엔드는 '네이티브로 실행할 수 있는 부분'을 최대한 네이티브 스레드에 유지하여, 이커머스, 콘텐츠, 커뮤니티와 같은 주류 시나리오에 충분히 견딜 수 있는 경험을 제공합니다. 팀이 React에 더 익숙하다면, 성능 차이 자체가 거부 사유가 되지는 않을 것입니다.

Ionic / WebView 경로와의 비교: 경험과 재사용의 절충

• Ionic과 같은 프레임워크는 본질적으로 WebView에서 실행되는 웹 기술 스택입니다. 가장 적합한 시나리오는 이미 많은 웹 자산을 보유하고 있어 빠르게 '사용 가능한' 앱 셸을 제공해야 하는 경우입니다.

• React Native의 위치는 'JS/React로 네이티브 컨트롤을 구동'하는 데 더 가깝습니다. 상호작용 경험과 시스템 일관성이 훨씬 뛰어나며, 예를 들어 스크롤 피드백, 제스처, 입력 방식 등이 있습니다.

프로젝트가 단순한 정보 표시, 양식 제출만 필요하고 동적 상호작용 요구가 낮다면 Ionic과 같은 솔루션의 비용 이점이 분명합니다. 하지만 '상호작용이 많고 경험 중심'인 비즈니스(예: 콘텐츠 커뮤니티, 이커머스, 도구 앱)에 들어가면 React Native/Flutter와 같은 '프레임워크 + 네이티브' 경로가 더 적합하며, WebView 경로의 한계가 빠르게 드러납니다.

순수 네이티브 개발과의 비교: 상한 vs 생산성

순수 네이티브(Swift/Kotlin)는 설명할 필요 없이 성능과 시스템 통합의 상한이 가장 높으며, 지연 시간에 극도로 민감한 시나리오(게임, 오디오/비디오 처리, 차량, 인간-기계 인터페이스 등)에서 여전히 유일하게 신뢰할 수 있는 선택입니다. React Native의 새 아키텍처는 '일반 비즈니스 시나리오'에서 네이티브와의 격차를 줄이는 데 더 초점을 맞추고 있으며, 대부분의 페이지와 상호작용이 '사용자가 차이를 느끼지 못하는' 수준에 도달하는 것을 목표로 합니다.

팀 및 비용 관점에서:

• 하나의 React Native 코드로 iOS/Android를 모두 커버할 수 있으며, 여러 플랫폼 간 일관성이 훨씬 뛰어납니다.

• React/Web 팀이 이미 있는 회사는 교육 비용이 낮으며, 두 개의 네이티브 팀을 추가로 유지할 필요가 없습니다.

• 진정으로 최고 성능이 필요한 부분은 TurboModules/Fabric을 통해 내려서 네이티브로 모듈을 작성한 후 RN에 다시 연결할 수 있습니다.

이러한 하이브리드 모델은 현재 많은 중대형 기업의 모바일 기술 스택의 현실적인 형태입니다. 핵심 성능에 민감한 모듈은 네이티브로 작성하고, 주변 비즈니스는 React Native로 처리하여 반복 효율성을 높이고 비즈니스 개발 모델을 통일합니다.

생태계: 단순히 '라이브러리가 많고 적음'의 문제가 아니다

스택 선정 시 프레임워크의 생태계 품질은 단일 성능보다 '장기적인 행복도'에 더 큰 영향을 미칩니다.

React Native: React 생태계의 지원 + 새 아키텍처 전환기

React Native 뒤에는 React 생태계가 있습니다. 이는 다음을 의미합니다:

• 다양한 플랫폼 간에 공통으로 사용되는 상태 관리, 데이터 흐름, 엔지니어링 관행을 직접 재사용할 수 있습니다.

• 내비게이션, 제스처, 애니메이션, 미디어, 지도 등 주요 영역에 성숙한 주류 솔루션이 있으며, 대부분 이미 새 아키텍처에 적응하고 있습니다.

현실적으로 고려해야 할 점은 새 아키텍처로의 전환이 하룻밤 사이에 이루어지지 않는다는 것입니다. 오래된 라이브러리가 업데이트되지 않거나 반쯤 적응된 상황이 여전히 발생할 수 있습니다. 새 프로젝트의 경우, 처음부터 'TurboModules와 Fabric을 명확히 지원하는 라이브러리'를 중심으로 스택을 선정하는 것이 좋습니다. 기존 프로젝트의 경우, 핵심 종속성의 유지 관리 상태를 평가한 후 업그레이드 속도를 결정해야 합니다.

Flutter: 통합도가 높고 경로가 명확하다

Flutter의 생태계는 자체 '통일된 세계'에 더 집중되어 있습니다. 플러그인 시스템과 공식 컴포넌트가 비교적 완전하고, 스타일과 동작의 일관성이 높으며, 데스크톱/웹 지원도 비교적 적극적으로 추진되고 있습니다.

문제는 '다른 플랫폼으로 갈 때'의 볼륨과 엔진 부담, 그리고 팀이 Dart와 Flutter 고유의 개발 패러다임을 수용할 의향이 있는지 여부에 더 있습니다.

미래에 하나의 UI를 가능한 한 데스크톱/웹으로 확장하고 싶고, 패키지 크기와 기술 스택 전환 비용을 감수할 수 있다면, Flutter가 더 안정적인 경로입니다.

WebView / Ionic: 극한의 재사용 vs 제한된 상한

Ionic과 같은 솔루션은 이미 성숙한 웹 프론트엔드 체계를 갖추고 있고 모바일 경험에 대한 요구가 높지 않은 팀에 가장 적합합니다. 빠른 배송, 통합 스택, 낮은 유지보수 비용이 주요 장점입니다.

문제도 분명합니다. 렌더링과 상호작용이 완전히 브라우저에 국한되어, 성능 병목 현상이 발생하면 프레임워크 수준에서 많은 최적화를 하기 어렵고, 제품 및 상호작용 설계 수준에서 타협해야 합니다.

네이티브: 규정 준수 및 고위험 시나리오의 안전망 옵션

강력한 규정 준수와 높은 보안이 필요한 산업(금융, 의료, 차량, 정부 프로젝트)에서는 네이티브가 여전히 더 쉽게 통과할 수 있는 경로입니다. 플랫폼 공식 문서가 완전하고, 도구 체인이 성숙하며, 규제 및 감사에 더 익숙합니다.

이러한 시나리오에서는 비즈니스 수준에서 React Native와 같은 크로스 플랫폼 솔루션을 사용하더라도, 주요 프로세스는 네이티브 계층에 두거나 추가적인 보안 검토를 요구하는 경우가 많습니다.

마지막으로 - 아키텍처/스택 선정에 대한 현실적인 조언

0.85 시점에서 모바일 기술 스택을 선택한다면, 다음 질문을 기준으로 걸러낼 수 있습니다:

1. 팀 현황: React 경험이 풍부하고 웹 자산이 많은가, 아니면 처음부터 Dart를 받아들일 수 있는가?

2. 비즈니스 특성: 주로 정보와 양식인가, 아니면 부드러운 상호작용이 필요한 복잡한 인터페이스가 많은가?

3. 성능 상한에 대한 요구: '네이티브에 무한히 가깝거나' 그 이상이 반드시 필요한 시나리오가 있는가?

4. 멀티 플랫폼 통일에 대한 기대: iOS/Android만 보는가, 아니면 장기적으로 데스크톱/웹까지 통합하려는가?

이러한 차원을 종합하면 대략적인 결론은 다음과 같습니다:

• React 팀 + 주류 비즈니스 앱 + iOS/Android 중심: React Native 새 아키텍처 + 0.85 이후 버전이 적절한 균형점입니다.

• 높은 일관성의 크로스 플랫폼 UI가 필요하고, 장기적으로 데스크톱/웹을 명확히 목표로 함: Flutter가 더 적합합니다.

• 비즈니스가 단순하고 웹 자산이 매우 많으며 경험 요구가 보통: Ionic/WebView 솔루션이 비용 효율적입니다.

• 보안/규정 준수/극한 성능: 네이티브가 주요 경로이며, 크로스 플랫폼 솔루션은 보완 또는 주변으로만 사용됩니다.