2026년 React Native 새로운 아키텍처: Hermes V1, 브릿지리스 모드와 면접 질문

React Native의 새로운 아키텍처는 2026년에 완전한 성숙기에 도달했습니다. React Native 0.84에서 Hermes V1이 기본 엔진으로 채택되었고, 0.85에서는 레거시 브릿지의 모든 흔적이 제거되었습니다. 개발자는 아키텍처 플래그나 호환성 레이어를 신경 쓸 필요 없이 네이티브에 근접한 성능을 얻을 수 있게 되었습니다.

React Native 아키텍처 스택의 변화

기존 React Native 아키텍처는 JavaScript와 네이티브 코드 사이의 메시지 전달을 위해 단일 스레드 비동기 JSON 브릿지에 의존했습니다. 터치 이벤트, 레이아웃 계산, 모듈 호출 등 모든 상호작용이 이 병목을 통과해야 했습니다. 새로운 아키텍처는 이 파이프라인의 각 레이어를 직접적이고 동기적인 대안으로 교체합니다.

| 레이어 | 기존 아키텍처 | 새로운 아키텍처 | |--------|-------------|----------------| | JS 엔진 | JavaScriptCore | Hermes V1 (바이트코드 + JIT) | | 렌더러 | Paper (비동기 브릿지) | Fabric (동기, 공유 C++) | | 네이티브 모듈 | 브릿지 모듈 (JSON 직렬화) | TurboModules (JSI, 직접 호출) | | 통신 | 비동기 JSON 브릿지 | JSI (JavaScript Interface) | | 초기화 | 브릿지 초기화 + 모듈 등록 | 브릿지리스 (지연, 온디맨드) |

JSI(JavaScript Interface)가 이 모든 것의 기반입니다. 모든 호출을 JSON으로 직렬화하여 큐에 전달하는 대신, JSI는 C++ 호스트 객체를 JavaScript에 직접 노출합니다. 이전에는 JSON 인코딩, 브릿지 큐잉, JSON 디코딩이 필요했던 TurboModule 호출이 이제는 직접적인 함수 호출로 완료됩니다.

Hermes V1: 기본 JavaScript 엔진

Hermes V1은 2026년 2월에 출시된 React Native 0.84에서 기본 엔진이 되었습니다. 이것은 이전 Hermes 버전의 점진적 업데이트가 아니라 컴파일러와 VM의 완전한 재작성입니다.

개선 사항은 네 가지 영역에 걸쳐 있습니다. 새로운 바이트코드 형식을 갖춘 재작성된 컴파일러, 개선된 JIT 컴파일러, Hades 동시 가비지 컬렉터, 그리고 React 19에서 사용되는 최신 JavaScript 패턴에 대한 향상된 지원입니다.

// Comparing startup and runtime metrics

// Hermes V1 bytecode is pre-compiled at build time
// No parse-compile step at runtime = faster cold starts

// Cold start comparison (production build, Pixel 8):
// Hermes V1:  ~850ms TTI
// JSC:        ~1200ms TTI  (29% slower)

// Memory footprint (complex app, 50+ screens):
// Hermes V1:  ~45MB baseline
// JSC:        ~72MB baseline (38% more)

// GC pause comparison (FlatList, 500+ complex cells):
// Hermes V1 (Hades):  <12ms max pause
// Old Hermes:         ~45ms occasional pauses
// Result: zero dropped frames in scroll benchmarks

동시 가비지 컬렉터인 Hades는 특별한 주목을 받을 만합니다. 이전 Hermes 버전은 stop-the-world 방식의 GC를 사용하여 리스트 스크롤 중에 간헐적으로 눈에 보이는 끊김을 유발했습니다. Hades는 백그라운드 스레드에서 동시에 컬렉션을 실행하여 GC 일시 정지를 12ms 미만으로 유지합니다. 복잡한 셀을 가진 긴 리스트를 렌더링하는 앱에서 JavaScript 측 프레임 드롭의 마지막 원인을 제거하는 것입니다.

Hermes V1은 React Native 0.84에서 WebAssembly 지원도 도입했습니다. Rust, C, C++로 작성된 성능 크리티컬 코드를 WASM으로 컴파일하여 앱 내에서 실행할 수 있으며, 플랫폼별 바인딩을 작성하지 않고도 디바이스 상의 AI 추론, 고밀도 수치 연산, 기존 네이티브 라이브러리의 재사용이 가능합니다.

Fabric 렌더러: 동기 레이아웃과 렌더링

Fabric은 iOS와 Android에서 공유하는 C++ 코어를 가진 렌더러로 Paper를 대체합니다. 핵심적인 차이점은 레이아웃 계산이 브릿지를 통해 비동기적으로 수행되는 것이 아니라 JavaScript 스레드에서 동기적으로 실행된다는 것입니다.

이 동기 모델은 Paper에서는 불가능했던 두 가지 기능을 가능하게 합니다.

1. 동시 렌더링 지원: Fabric은 React 19의 동시 기능과 통합됩니다. Fabric이 렌더링을 중단하고 재개할 수 있기 때문에 Transitions, Suspense 경계, useTransition이 올바르게 작동합니다.

2. 직접 C++ 레이아웃: Yoga(레이아웃 엔진)가 JavaScript 런타임과 동일한 메모리 공간에서 실행됩니다. 플렉스박스 계산에 대한 직렬화 오버헤드가 없습니다.

// Concurrent features work correctly with Fabric
import React, { useState, useTransition } from 'react'
import { View, Text, FlatList, TextInput, StyleSheet } from 'react-native'

type Item = { id: string; name: string; category: string }

function SearchableList({ items }: { items: Item[] }) {
  const [query, setQuery] = useState('')
  const [filtered, setFiltered] = useState(items)
  const [isPending, startTransition] = useTransition()

  const handleSearch = (text: string) => {
    setQuery(text) // Urgent: update input immediately
    startTransition(() => {
      // Non-urgent: filter can be deferred
      const result = items.filter(item =>
        item.name.toLowerCase().includes(text.toLowerCase())
      )
      setFiltered(result)
    })
  }

  return (
    <View style={styles.container}>
      <TextInput
        value={query}
        onChangeText={handleSearch}
        placeholder="Search items..."
        style={styles.input}
      />
      {isPending && <Text style={styles.pending}>Filtering...</Text>}
      <FlatList
        data={filtered}
        keyExtractor={item => item.id}
        renderItem={({ item }) => (
          <View style={styles.row}>
            <Text>{item.name}</Text>
          </View>
        )}
      />
    </View>
  )
}

const styles = StyleSheet.create({
  container: { flex: 1, padding: 16 },
  input: { borderWidth: 1, borderColor: '#ccc', padding: 12, marginBottom: 8 },
  pending: { color: '#888', marginBottom: 4 },
  row: { padding: 12, borderBottomWidth: 1, borderBottomColor: '#eee' },
})

이 예제의 useTransition 훅은 Fabric이 중요한 이유를 보여줍니다. Paper에서는 렌더러가 진행 중인 렌더링을 중단할 수 없었기 때문에 startTransition이 아무런 효과가 없었습니다. Fabric의 React 19 동시 모드와의 통합으로 지연 업데이트가 설계된 대로 작동하며, 백그라운드에서 수천 개의 항목을 필터링하면서도 텍스트 입력의 응답성이 유지됩니다.

TurboModules와 JSI: 직렬화 오버헤드 제거

TurboModules는 기존의 NativeModules 시스템을 대체합니다. 성능 차이는 JSON 직렬화의 완전한 제거에서 비롯됩니다. 브릿지 모듈 호출은 다음 경로를 따랐습니다: JS 객체 → JSON.stringify → 브릿지 큐 → JSON.parse → 네이티브 호출 → JSON.stringify → 브릿지 큐 → JSON.parse → JS 콜백. TurboModule 호출은 JSI를 통한 직접적인 C++ 함수 호출입니다.

// TurboModule spec using the Codegen
import type { TurboModule } from 'react-native'
import { TurboModuleRegistry } from 'react-native'

export interface Spec extends TurboModule {
  // Synchronous: returns immediately, no bridge round-trip
  getDeviceModel(): string
  getOSVersion(): string
  getBatteryLevel(): number

  // Asynchronous: for operations that genuinely need async
  getStorageUsage(): Promise<{ used: number; total: number }>
}

export default TurboModuleRegistry.getEnforcing<Spec>('DeviceInfo')

// Native Android implementation of the TurboModule
package com.app.modules

import com.facebook.react.bridge.ReactApplicationContext
import com.facebook.react.bridge.ReadableMap
import com.facebook.react.bridge.WritableNativeMap
import com.facebook.react.module.annotations.ReactModule

@ReactModule(name = "DeviceInfo")
class DeviceInfoModule(reactContext: ReactApplicationContext) :
  NativeDeviceInfoSpec(reactContext) {

  // Synchronous via JSI - no bridge, no JSON, no queue
  override fun getDeviceModel(): String {
    return android.os.Build.MODEL
  }

  override fun getOSVersion(): String {
    return "Android ${android.os.Build.VERSION.RELEASE}"
  }

  override fun getBatteryLevel(): Double {
    val manager = reactApplicationContext
      .getSystemService(android.content.Context.BATTERY_SERVICE)
      as android.os.BatteryManager
    return manager.getIntProperty(
      android.os.BatteryManager.BATTERY_PROPERTY_CAPACITY
    ).toDouble()
  }

  override fun getStorageUsage(
    promise: com.facebook.react.bridge.Promise
  ) {
    val stat = android.os.StatFs(
      android.os.Environment.getDataDirectory().path
    )
    val map = WritableNativeMap().apply {
      putDouble("used", (stat.totalBytes - stat.availableBytes).toDouble())
      putDouble("total", stat.totalBytes.toDouble())
    }
    promise.resolve(map)
  }

  override fun getName(): String = "DeviceInfo"
}

핵심 사항은 getDeviceModel(), getOSVersion(), getBatteryLevel()이 동기적이라는 점입니다. JavaScript 스레드가 네이티브 코드를 직접 호출하고 동일한 틱에서 반환 값을 받습니다. Promise도 콜백도 브릿지 왕복도 없습니다. 이것은 JSI에 의해서만 가능합니다.

브릿지리스 모드: 무엇이 제거되었고 왜 중요한가

브릿지리스 모드는 React Native 0.73에서 도입되어 0.74에서 기본값이 되었습니다. Fabric과 TurboModules가 채택된 후에도 기존 브릿지는 글로벌 이벤트 이미터, 타이머, 에러 핸들링을 처리하기 위해 시작 시 초기화되었습니다. 브릿지리스 모드는 이러한 나머지 시스템을 JSI 기반 구현으로 이전합니다.

실질적인 영향은 다음과 같습니다.

• 더 빠른 시작: 브릿지 초기화 오버헤드가 없습니다. 런타임은 지연 로딩을 통해 앱이 실제로 사용하는 것만 부트스트랩합니다.
• 메모리 감소: 시작 시 브릿지 데이터 구조가 할당되지 않습니다.
• 깔끔한 에러 핸들링: 에러 바운더리와 글로벌 에러 핸들러가 브릿지 폴백 없이 새로운 아키텍처를 통해 작동합니다.

React Native 0.82에서 기존 브릿지가 영구적으로 비활성화되었습니다. 2026년 4월에 출시된 React Native 0.85에서는 브릿지 관련 모든 코드가 코드베이스에서 제거되었습니다. 폴백 경로는 존재하지 않습니다.

프로덕션 마이그레이션: 실제 성능 벤치마크

기존 아키텍처에서 새로운 아키텍처로의 프로덕션 마이그레이션은 주요 메트릭에서 일관된 개선을 보여줍니다.

| 메트릭 | 기존 아키텍처 | 새로운 아키텍처 | 개선 | |--------|-------------|----------------|------| | 콜드 스타트 (TTI) | 1.4초 | 0.8초 | 43% 향상 | | 화면 전환 | 180ms | 110ms | 39% 향상 | | 메모리 기준선 | 89MB | 66MB | 26% 감소 | | JS→네이티브 호출 | ~5ms (비동기) | ~0.1ms (동기) | 40배 향상 | | GC 최대 일시 정지 | 45ms | 12ms | 73% 단축 | | FlatList 스크롤 (1000개 항목) | 간헐적 끊김 | 부드러운 60fps | 프레임 드롭 없음 |

사용자 대면 품질에 가장 큰 영향을 미치는 개선은 GC 일시 정지의 단축입니다. Hades는 컬렉션 일시 정지를 1프레임 예산(60fps에서 16.6ms) 미만으로 유지하여, 복잡한 React Native 앱에서 가장 흔한 눈에 보이는 끊김의 원인을 제거합니다.

2026년 생태계 호환성

생태계는 새로운 아키텍처에 완전히 수렴했습니다. Expo SDK 55 이후 버전은 새로운 아키텍처에서만 실행되며, 비활성화 옵션이 없습니다. 주요 라이브러리 호환성은 다음과 같습니다.

• React Navigation 7.2 이상: 네이티브 스택 스크린을 포함한 완전한 Fabric 지원
• Reanimated 3.5 이상: React Native 0.85와 공유 애니메이션 백엔드
• Gesture Handler 2.16 이상: JSI 기반 직접 제스처 인식
• Vision Camera 4.0 이상: JSI를 통한 프레임 처리
• Detox: 새로운 아키텍처 호환 E2E 테스트

Expo를 사용하는 팀의 경우, npx create-expo-app은 새로운 아키텍처가 기본으로 활성화된 프로젝트를 생성합니다. 별도의 설정이 필요하지 않습니다.

React Native 0.75 이하 버전의 앱은 마이그레이션이 필수입니다. 기존 브릿지는 0.82 이상에서 영구적으로 제거되었습니다. TurboModule spec 없이 NativeModules를 직접 사용하는 서드파티 라이브러리는 업데이트가 필요합니다.

기술 면접 질문: React Native 새로운 아키텍처

다음 질문들은 2026년 시니어 React Native 면접에서 자주 출제됩니다. 각 답변은 스태프/시니어 레벨에서 기대되는 깊이를 다루고 있습니다.

Q1: 기존 브릿지와 JSI의 차이를 설명하십시오. JSI가 동기적 네이티브 호출을 가능하게 하는 이유는 무엇입니까?

브릿지는 JS에서 네이티브로의 모든 메시지를 JSON으로 직렬화하고 비동기 큐에 넣은 후 네이티브 측에서 역직렬화했습니다. JSI(JavaScript Interface)는 C++ 호스트 객체를 JavaScript VM에 직접 노출합니다. JSI를 통해 등록된 네이티브 함수는 직렬화나 큐잉 없이 네이티브 코드를 인라인으로 실행하는 일반 JavaScript 함수로 나타납니다. JSI는 중간 메시지 큐 없이 동일한 스레드 컨텍스트에서 작동하므로 동기 호출이 가능합니다.

Q2: Fabric 렌더러는 Paper가 해결할 수 없었던 어떤 문제를 해결합니까?

Paper는 브릿지를 통해 비동기적으로 렌더링하여 React 동시 기능을 지원하는 것이 불가능했습니다. Paper는 진행 중인 렌더 트리를 중단할 수 없었기 때문에 startTransition 호출이 효과가 없었습니다. Fabric은 공유 C++ 코드로 렌더링을 구현하고 React 19의 리컨실러와 직접 통합하여 동시 렌더링, Suspense, Transitions를 지원합니다. Yoga를 통한 레이아웃 계산도 동일한 메모리 공간에서 동기적으로 수행되어 크로스 브릿지 레이아웃의 지연 시간이 제거됩니다.

Q3: 새로운 아키텍처에 Hermes가 필요한 이유는 무엇입니까? 다른 엔진을 사용할 수 있습니까?

새로운 아키텍처는 JSI에 의존하며, JSI는 JavaScript 엔진이 C++ 호스트 객체 등록을 지원할 것을 요구합니다. Hermes는 처음부터 JSI 통합을 염두에 두고 설계되었습니다. JavaScriptCore도 이론적으로 JSI를 지원할 수 있지만, 공식 구현과 테스트는 Hermes를 기반으로 구축되어 있습니다. Hermes V1은 바이트코드 사전 컴파일(런타임 파싱 제거), Hades 동시 GC(12ms 미만 일시 정지), WebAssembly 지원을 추가로 제공하며, 이는 React Native의 JSC 통합에서는 사용할 수 없습니다.

Q4: TurboModules는 개발자 관점에서 기존 NativeModules API와 어떻게 다릅니까?

TurboModules는 빌드 시 타입 안전한 네이티브 바인딩을 생성하는 Codegen spec(TurboModule을 확장하는 TypeScript 인터페이스)이 필요합니다. 기존 NativeModules는 타입 검사 없는 런타임 리플렉션을 사용했습니다. TurboModules는 동기적 반환 값(Promise뿐만 아니라), 지연 초기화(모듈은 처음 접근 시에만 로드), JSON 직렬화 없는 직접 JSI 호출을 지원합니다. 개발자는 TypeScript spec을 작성하고, Codegen을 실행하며, 생성된 네이티브 인터페이스를 구현합니다.

Q5: 브릿지리스 모드를 설명하고, Fabric과 TurboModules만 사용하는 경우와 비교하여 무엇이 제거되는지 설명하십시오.

Fabric과 TurboModules를 채택한 후에도 기존 브릿지는 글로벌 이벤트 이미터, 타이머, 에러 핸들링, 기타 런타임 인프라스트럭처를 처리하기 위해 시작 시 초기화되었습니다. 브릿지리스 모드는 이러한 나머지 브릿지 의존 시스템을 JSI 기반 구현으로 대체합니다. 브릿지 초기화 오버헤드를 제거하고 기준선 메모리 사용량을 줄이며 전체 런타임이 JSI를 통해 작동하도록 보장합니다. React Native 0.85 이후, 브릿지리스 모드가 유일한 작동 모드입니다.

이러한 질문을 작동하는 코드 예제와 함께 연습하면 개념적 이해와 실용적 기억력 모두 강화됩니다.

결론

• Hermes V1은 React Native 0.84 이상에서 콜드 스타트 29% 향상, 메모리 38% 감소, 12ms 미만의 GC 일시 정지를 기본으로 제공합니다
• Fabric은 Paper가 결코 지원할 수 없었던 React 19 동시 기능(Transitions, Suspense)을 가능하게 합니다
• TurboModules는 JSON 직렬화를 제거하여 직접 JSI 호출을 통해 JS→네이티브 호출을 40배 향상시킵니다
• 브릿지리스 모드는 마지막 브릿지 의존성을 제거하며, React Native 0.85에는 브릿지 코드가 전혀 남아 있지 않습니다
• 생태계는 완전히 호환됩니다. Expo SDK 55 이상, React Navigation 7.2 이상, Reanimated 3.5 이상 및 모든 주요 라이브러리가 새로운 아키텍처만을 지원합니다
• 면접 준비는 JSI 메커니즘, Fabric과 Paper의 트레이드오프, TurboModule Codegen 워크플로우, 브릿지리스 모드 런타임 변경 사항에 집중해야 합니다