React Native JSI: 직접 연결은 무엇을 해결하고 무엇을 남기는가

30초 요약

JavaScript Interface(JSI)는 JavaScript 엔진과 React Native의 C++ 기반을 연결한다. JavaScript와 C++가 서로의 객체를 참조하고 함수를 직접 호출할 수 있게 해 과거 Bridge의 비동기 큐와 값 변환에 의존하던 경계를 바꿨다.

그러나 직접은 다음을 뜻하지 않는다.

• 계산 비용이 0이 된다.
• 호출이 자동으로 백그라운드 스레드로 이동한다.
• 입력 타입, 오류와 취소가 자동으로 안전해진다.
• JSI 자체가 카메라·저장소 같은 앱 기능이다.

JSI는 연결 기반이다. 새 렌더러인 Fabric과 새 네이티브 모듈 체계인 TurboModules가 그 기반을 사용하며, 실제 실행 위치와 앱 API 계약은 각각 따로 정한다.

이 글을 관통하는 상황: 직접 호출인데 버튼이 300ms 멈춘다

가상의 영수증 앱이 촬영한 이미지의 체크섬을 계산한다고 하자. 체크섬은 입력 데이터에서 일정한 규칙으로 만든 짧은 확인값이다. 코드의 imageBytes는 이미지 픽셀을 바이트 단위의 숫자로 담은 입력이다. 개발자는 과거 비동기 API를 다음 동기 함수로 바꾸고 “JSI 직접 호출이므로 응답도 빨라질 것”이라고 예상한다.

function handleVerifyPress() {
  setStatus('검증 중')
  const checksum = ReceiptImageHost.hashLargeBuffer(imageBytes)
  setStatus(`완료: ${checksum}`)
}

hashLargeBuffer는 설명을 위해 JavaScript에 노출한 가상 C++ 함수다. 이 글에서는 실제 네이티브 모듈이나 C++ 코드를 만들지 않는다.

기록을 보기 전에 어떤 증거를 찾아야 할지 먼저 예측한다.

1. JavaScript에서 C++ 함수까지 연결됐는지는 어느 시점으로 확인할 수 있는가?
2. 300ms 계산은 호출 함수가 돌아오기 전과 후 중 언제 끝날 것으로 예상하는가?
3. 그동안 다음 JavaScript 버튼 처리는 실행될 것으로 예상하는가?

아래 fixture, 즉 미리 준비한 가상 증거 묶음은 같은 시간 기준으로 관찰 결과를 정리한다. React Native가 고정 형식으로 출력하는 로그가 아니다.

0ms    JavaScript handleVerifyPress 시작
1ms    C++ hashLargeBuffer 진입
301ms  C++ hashLargeBuffer 계산 종료
302ms  JavaScript handleVerifyPress 종료
303ms  다음 JavaScript onPress 처리

기록은 연결 실패가 아니라 성공한 동기 호출이 실행 경로를 오래 점유한 상태를 보여 준다. Bridge의 직렬화 비용을 없애도 체크섬 계산 자체의 300ms는 사라지지 않는다.

JSI는 엔진과 C++ 애플리케이션 사이의 인터페이스다

JSI는 Hermes만의 앱 기능 이름도 아니다. JavaScript 런타임과 C++ 호스트 애플리케이션이 상호작용할 수 있게 하는 낮은 수준의 기반이다.

이 변화가 줄이는 것은 연결 과정의 제약과 비용이다. 호출한 함수 안에서 실제로 수행하는 이미지 계산, 파일 읽기나 압축 비용까지 없애는 것은 아니다.

JSI와 그 위를 사용하는 체계는 같지 않다

따라서 “JSI 호출이 실패했다”는 말만으로는 조사 범위가 너무 넓다.

함수를 찾지 못함         → 모듈 등록·생성된 연결 코드부터 확인
입력 타입이 플랫폼별로 다름 → 모듈 타입 계약과 구현을 확인
화면이 반영되지 않음       → Fabric·호스트 컴포넌트 경계를 확인
함수는 되지만 응답이 늦음   → 실행 위치와 실제 작업 시간을 확인

직접은 무료나 백그라운드라는 뜻이 아니다

New Architecture는 동기 호출도 지원한다. 동기는 호출한 쪽이 반환값을 받을 때까지 같은 호출 흐름에서 기다린다는 뜻이다.

따라서 다음 등식은 성립하지 않는다.

JSI 직접 호출 = 계산 비용 없음
JSI 직접 호출 = 자동 백그라운드 실행
네이티브 C++  = JavaScript 응답과 무관

관통 사례에서는 C++ 진입이 1ms에 확인됐으므로 연결 자체는 성공했다. 문제는 301ms까지 반환하지 않은 동기 계산이다. 다음 onPress가 303ms에야 처리된 기록도 같은 실행 경로가 기다렸다는 증거다.

관찰 기록에서 연결과 실행을 나눠 읽는다

실무에서는 로그 하나를 “JSI가 느리다”로 요약하지 않고 구간을 나눈다.

이 가상 기록은 실제 성능 수치를 대신하지 않는다. 운영 구현에서는 release 빌드의 측정 도구로 각 구간을 확인해야 한다. 이 글의 기록이 증명하는 것은 “직접 연결이 성공해도 큰 동기 계산은 남는다”는 판단 구조다. 도구와 실제 기기 측정 범위는 29편에서 다룬다.

연결 가능성과 운영 계약을 분리한다

hashLargeBuffer를 운영 가능한 기능으로 만들려면 적어도 다음 질문에 답해야 한다.

• 큰 계산은 JavaScript나 UI 응답을 막지 않는 별도 실행 흐름에서 수행하는가?
• 결과가 나중에 도착한다면 완료와 오류를 Promise나 사건 중 어떤 방식으로 전달하는가?
• 화면이 사라지거나 새 이미지가 선택됐을 때 이전 작업을 취소하거나 결과를 무시할 수 있는가?
• 계산이 끝날 때까지 imageBytes의 메모리를 누가 소유하고 안전하게 유지하는가?
• Android와 iOS가 같은 입력, 오류와 체크섬 규칙을 제공하는가?

교정 방향은 “JSI를 비동기로 바꾼다”가 아니다. JSI는 기반이므로, 실제 모듈 API가 큰 작업을 별도 실행 흐름으로 넘기고 완료를 나중에 전달하도록 설계한다. 반대로 아주 작은 값을 즉시 읽는 함수라면 동기 호출이 적절할 수 있다. 선택 기준은 이름이 아니라 측정한 작업 비용과 호출 계약이다.

예를 들어 모듈이 “호출을 받으면 큰 계산을 별도 작업 흐름에서 수행하고, 완료 또는 오류를 Promise로 전달한다”는 계약을 제공한다면 호출부는 다음 모양이 된다. 이 코드는 JSI가 아니라 그 위를 사용하는 가상 모듈 API의 교정 예다.

async function handleVerifyPress() {
  setStatus('검증 중')
 
  try {
    const checksum = await ReceiptImageModule.hashLargeBufferAsync(imageBytes)
    setStatus(`완료: ${checksum}`)
  } catch {
    setStatus('검증 실패')
  }
}

같은 300ms 계산을 별도 실행 흐름으로 보낸다는 계약을 가정하면, 교정 후에는 다음과 같은 증거를 기대한다. 이 기록도 실제 React Native의 고정 로그가 아니라 계약을 검증하기 위한 가상 기록이다.

0ms    JavaScript handleVerifyPress 시작
1ms    네이티브 작업 접수, 별도 실행 흐름에서 계산 시작
2ms    JavaScript는 Promise 완료를 기다리며 다음 작업을 처리할 수 있음
3ms    다음 JavaScript onPress 처리
301ms  네이티브 계산 종료
302ms  Promise 완료, JavaScript 상태를 완료로 변경

이 최소 교정의 성공 조건은 단순히 최종 체크섬이 같은 데서 끝나지 않는다. 다음 onPress가 계산 종료보다 먼저 처리되고 완료·실패 상태가 한 번만 도착해야 한다. 작업 취소와 이전 결과 무시는 이 코드에 아직 구현되지 않은 별도 통합 계약이다. 실제 구현에서는 그 계약까지 추가한 뒤 Android와 iOS 각각의 release 빌드에서 순서와 결과를 측정한다.

같은 상황을 다시 진단한다

문제       JSI 기반 동기 체크섬 호출 뒤 다음 버튼 처리가 300ms 늦음
잘못된 판단 직접 네이티브 호출이므로 계산은 자동으로 빠르고 백그라운드에서 실행됨
관찰       C++ 진입은 성공했지만 함수가 300ms 뒤 반환하고 다음 onPress도 그 뒤 실행됨
원인       연결이 아니라 큰 동기 계산이 호출 경로를 점유함
행동       작업 위치와 비동기 완료·오류·취소·메모리 소유 계약을 모듈 API에 명시
검증       다음 onPress가 계산 완료 전에 처리되고 완료·오류가 한 번만 도착하는지 release에서 측정

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

• JSI와 그 위의 Fabric·TurboModule·Codegen 책임을 섞지 않았는가?
• 직접, 동기, 백그라운드를 같은 뜻처럼 사용하지 않았는가?
• 큰 네이티브 작업의 실제 실행 위치와 시간이 측정됐는가?
• 완료·오류·취소와 입력 데이터 수명 계약이 있는가?
• Android와 iOS의 API 결과를 각각 검증했는가?

기억할 문장은 짧다.

JSI는 연결 기반이다. 직접 연결은 계산 비용과 실행 계약을 대신하지 않는다.

다음 글에서는 이 기반을 사용하는 Fabric이 React의 계산을 Android와 iOS의 실제 화면에 어떻게 반영하는지 살펴본다.