정말 오래전부터 개발자 커뮤니티에서는 전설처럼 회자되던 그것. 슬랙 채널이나 개발자 포럼에서 은밀하게 이야기되던 ‘리액트 네이티브의 새로운 아키텍처’ — JSI, Fabric, TurboModules라는 삼두마차가 마치 “바로 코앞”에 있는 것처럼 느껴지곤 했습니다. 많은 이들이 이를 허황된 이야기로 치부하기도 했습니다. “베이퍼웨어( Vaporware: 개발 계획만 있고 실제 제품은 나오지 않는 것을 의미) 아니냐”는 비난까지도 있었습니다. 하지만 마침내 우리는 그 순간을 맞았습니다. 단순한 출시가 아닙니다. 이것은 근본적인 플랫폼의 변화이며, 자바스크립트가 모바일 경험의 핵심인 네이티브 코드와 상호작용하는 방식을 완전히 뒤엎는 혁신입니다. 그 파장은 실로 엄청날 것입니다.
모두가 기대하고, 아니 최소한 희망했던 것은 바로 속도였습니다. 더 빨라진 앱, 더 부드러운 애니메이션, 덜한 끊김 현상. 물론 그런 부분들을 얻었습니다. 하지만 그것뿐만이 아닙니다. 모바일 경험의 상당 부분을 차지하는 두 코드 세계를 잇는 ‘파이프라인’ 자체를 근본적으로 재해석했습니다. 마치 마차에서 자기부상열차로 업그레이드하는 것과 같습니다. 단순히 빨라진 것이 아니라, 움직임의 새로운 패러다임 자체가 열린 셈이죠.
기존 방식은요? 바로 ‘브릿지(Bridge)’였습니다. 두 방 사이에 손으로 쓴 편지를 조심스럽게 전달하는, 매우 정중하지만 동시에 매우 신중한 메신저를 상상해보세요. 자바스크립트는 메시지를 작성하고, JSON 직렬화라는 봉투에 담아 브릿지로 보냅니다. 브릿지는 조심스럽게 봉투를 열어 내용을 읽고(역직렬화), 네이티브 측에 전달합니다. 네이티브 측은 작업을 마치고, 답장을 써서 그것도 똑같이 봉투에 담아 다시 보냅니다. 모든 과정에서 이런 일이 반복되었습니다. 이 시스템은 작동은 했지만, 세 가지 고질적인 문제를 안고 있었습니다:
기본적으로 비동기, 필요에 의해 동기. 때로는 답을 지금 당장 알아야 할 때가 있습니다. 예를 들어, 애니메이션을 실행하기 전에 특정 요소의 정확한 픽셀 위치를 알아야 할 때 말이죠. 브릿지는 느린 비동기 왕복 통신을 강요하거나, 오래된 캐시 데이터를 사용할 수 있는 취약한 임시방편을 요구했습니다. 이상적이지 않았죠.
직렬화 오버헤드. 모든. 메시지. 마다. JSON으로 변환했다가 다시 되돌리는 수고를 거쳐야 했습니다. 스크롤, 제스처, 프레임마다 발생하는 애니메이션과 같이 빈번하게 발생하는 이벤트의 경우, 이 과정이 누적되었습니다. 마치 “안녕”이라고 말하기 위해 메신저에게 소설을 전보로 번역해서 보내고, 다시 받아 번역하라고 시키는 것과 같았습니다.
예비 초기화. 앱에서 사용하든 안 하든, 모든 네이티브 모듈이 시작 시점에 활성화되었습니다. 서드파티 SDK로 가득 찬 대규모 앱은 지연되는 초기 로딩 시간을 의미했습니다. 마치 나중에 필요할지도 모른다는 생각에 집 안의 모든 물건을 챙겨 이삿짐을 싸는 것과 같았죠.
이제 마법이 시작되는 곳입니다. 바로 JSI입니다. JavaScript Interface. 이 브릿지를 완전히 제거합니다. 이제 자바스크립트는 네이티브 객체에 직접 참조를 보유하고, 직렬화 없이 동기적으로 네이티브 메서드를 호출할 수 있습니다. 자바스크립트가 이제 네이티브 방에 직접 손을 뻗어, 어깨를 톡톡 두드리는 네이티브 함수를 호출하고 즉각적인 응답을 받는다고 상상해보세요. 기다릴 필요도, 번역할 필요도 없습니다.
자바스크립트 관점에서 JSI 기반 함수를 호출하는 것은 일반 자바스크립트 함수를 호출하는 것과 동일하게 느껴집니다. JSI 호스트 객체 프로토콜을 통해 네이티브 구현이 자바스크립트 스레드에서 동기적으로 실행되기 때문입니다.
이것이 바로 TurboModules의 기반입니다. TurboModules는 네이티브 코드에 접근하는 새로운 방식입니다. 이들은 두 가지 엄청난 이점을 제공합니다. 바로 지연 로딩(lazy loading)과 타입 안전성(type safety)입니다. 지연 로딩이란 모듈이 실제로 사용될 때만 로드된다는 의미입니다. 따라서 앱에 50개의 네이티브 모듈이 있지만 특정 화면에서 5개만 사용한다면, 초기화되는 것은 해당 5개뿐입니다. 시작 시간이 극적으로 단축됩니다. Codegen을 통한 타입 안전성은 타입 불일치로 인한 지저분한 런타임 오류를 과거의 유물로 만듭니다. TypeScript 또는 Flow로 사양이 작성되고, Codegen은 자동으로 네이티브 코드를 생성하여 자바스크립트에서 보낸 것이 네이티브 측에서 기대하는 것과 정확히 일치하도록 보장합니다.
마치 매우 숙련되고 능숙한 이중 언어 개인 비서(JSI)를 갖는 것과 같습니다. 이 비서는 즉각적으로 정보를 가져올 뿐만 아니라, 사소한 부분까지(TurboModules 및 Codegen) 여러분의 구체적인 요구사항을 이해하여 오해가 없도록 보장합니다. 이것은 단순한 업그레이드가 아닙니다. 크로스 플랫폼 개발에서 이전에는 불가능하다고 여겨졌던 성능을 해방시키는 패러다임 전환입니다. 비동기 추측의 시대는 끝났습니다. 직접적이고 성능이 뛰어난 상호작용의 시대가 도래했습니다.
그렇다면 Fabric은요? Fabric은 리액트 네이티브의 새로운 렌더링 시스템입니다. 컴포넌트 트리를 네이티브 UI 요소로 변환하는 시각 엔진이죠. 이전 렌더러는 동기적이고 단일 스레드였습니다. 하지만 Fabric은 동시성(concurrency)을 위해 구축되었습니다. 렌더링 작업을 우선순위로 지정하고, 일시 중지하고 다시 시작할 수 있으며, 심지어 다른 스레드에서 렌더링할 수도 있습니다. 복잡한 UI와 애니메이션에 엄청난 이점을 제공하며 훨씬 더 부드러운 시각적 경험을 가능하게 합니다. 마치 벽화를 그리는 과로한 단일 화가에서, 각기 다른 부분에 특화되어 동시에 효율적으로 작업할 수 있는 조율된 예술가 팀으로 업그레이드하는 것을 상상해보세요.
기존 앱에 대한 전환은 순탄할까요? 이것이 바로 백만 달러짜리 질문입니다. 크고 확립된 앱을 새로운 아키텍처로 마이그레이션하는 것은 주말 프로젝트가 아닙니다. 새로운 컴포넌트를 이해하고, 일부 네이티브 모듈 상호작용을 재작성해야 할 수 있으며, 철저한 테스트가 필요합니다. 문서에는 이 점이 명확하게 나와 있습니다. 이는 즉각적인 스위치 전환이 아니라 마이그레이션입니다. 팀은 계획을 세우고, 자원을 할당하고, 관련된 복잡성을 감당할 준비가 되어 있어야 합니다.
오픈소스 개발자에게는 이것이 무엇을 의미할까요? 새로운 기회를 의미합니다. 새로운 아키텍처는 더 빠르고, 더 강력한 라이브러리를 구축할 수 있는 초대장입니다. 기존 라이브러리를 조정해야 할 수도 있습니다. 리액트 네이티브 자체에 기여하는 사람들에게는 성능 최적화의 새로운 지평이 열립니다. 기본 메커니즘이 그 어느 때보다 더 접근 가능하고 강력해졌습니다. 크로스 플랫폼 애플리케이션이 달성할 수 있는 것의 경계를 넓힐 기회입니다.
JSI란 정확히 무엇인가요?
JSI, 즉 JavaScript Interface는 기존의 비동기 브릿지를 대체하는 핵심 컴포넌트입니다. 자바스크립트가 네이티브 메서드를 직접 동기적으로 호출하고 네이티브 객체에 대한 참조를 보유할 수 있게 하여, 직렬화 오버헤드를 제거하고 실시간 양방향 통신을 가능하게 합니다.
TurboModules는 기존 NativeModules보다 왜 더 나은가요?
TurboModules는 지연 초기화 기능을 제공합니다. 즉, 처음 사용될 때만 로드되어 앱 시작 시간을 크게 개선합니다. 또한 Codegen을 통해 타입 안전성을 도입하여 자바스크립트와 네이티브 코드 간의 데이터 타입 불일치로 인한 런타임 오류를 방지합니다.
새로운 아키텍처가 모든 성능 문제를 해결하나요?
JSI, TurboModules, Fabric을 갖춘 새로운 아키텍처는 JS와 네이티브 코드 간의 통신 및 렌더링 성능을 극적으로 향상시키지만, 모든 성능 병목 현상을 해결하는 만능 해결책은 아닙니다. 개발자는 최상의 결과를 얻기 위해 여전히 자바스크립트 코드와 네이티브 구현을 최적화해야 합니다.
Fabric은 UI 성능에 어떤 영향을 미칩니까?
Fabric은 리액트 네이티브의 새로운 동시 렌더링 시스템입니다. 렌더링 작업의 우선순위를 지정하고, 일시 중지 및 재개할 수 있게 하여 UI 스레드를 더 반응적으로 만들어, 특히 복잡한 UI에서 더 부드러운 애니메이션과 더욱 유려한 사용자 경험을 제공합니다.
마이그레이션의 어려움은 무엇인가요?
기존 리액트 네이티브 앱을 새로운 아키텍처로 마이그레이션하는 것은 복잡할 수 있습니다. 호환성과 안정성을 보장하기 위해 신중한 계획, 네이티브 모듈의 잠재적 리팩토링, 광범위한 테스트가 필요합니다. 크거나 성숙한 애플리케이션의 경우 상당한 노력이 필요합니다.
**
🧬 관련 인사이트
자주 묻는 질문**
리액트 네이티브의 새로운 아키텍처는 정확히 무엇을 하나요? 기존의 비동기 브릿지를 직접적이고 동기적인 JavaScript Interface(JSI)로 교체하고, 시작 시간을 개선하기 위해 지연 로딩되는 TurboModules와 더 부드러운 UI를 위한 동시 렌더링 시스템인 Fabric을 도입합니다.
제 리액트 네이티브 앱이 즉시 빨라지나요? 네이티브 모듈 통신과 UI 렌더링에서 상당한 성능 향상을 위한 기반을 제공합니다. 실제 속도 향상은 앱의 특정 사용 사례와 새 아키텍처 내에서 코드가 얼마나 잘 최적화되었는지에 따라 달라집니다.
앱 전체를 다시 작성해야 하나요? 대부분의 앱은 점진적인 마이그레이션이 가능합니다. TurboModules 및 JSI와 호환되도록 개별 네이티브 모듈을 업데이트하거나 다시 작성해야 할 가능성이 높습니다. 완전한 재작성은 아니지만, 전용 노력이 필요합니다.
