Antigravity Agent
10 KiB
category, tags, title, description, last_updated
| category | tags | title | description | last_updated | ||||
|---|---|---|---|---|---|---|---|---|
| Architecture |
|
React Native Performance Optimization | React Native의 성능 최적화는 주로 자바스크립트 스레드와 네이티브 스레드 간의 통신 병목 현상을 해결하는 데 초점을 맞추고 있습니다. | 2026-05-04 |
React Native Performance Optimization
📌 Brief Summary
React Native의 성능 최적화는 주로 자바스크립트 스레드와 네이티브 스레드 간의 통신 병목 현상을 해결하는 데 초점을 맞추고 있습니다. 최근 '새로운 아키텍처(New Architecture)'의 도입을 통해 기존의 비동기 브릿지(Bridge) 구조를 제거하고 동기식 통신을 가능하게 하여 성능을 극적으로 향상시켰습니다. 이를 통해 직렬화 오버헤드를 줄이고, 렌더링 속도와 앱의 초기 로딩 및 메모리 성능을 효율적으로 최적화하고 있습니다.
📖 Core Content
- 새로운 아키텍처(New Architecture)와 브릿지리스 모드: 과거 React Native의 가장 큰 성능 병목은 JS와 네이티브 간의 통신을 담당하며 데이터를 JSON 문자열로 직렬화했던 비동기 브릿지였습니다 [1]. 최근 버전(0.74 이상)에서는 이를 기본적으로 제거한 브릿지리스 아키텍처를 채택하여 성능을 크게 최적화했습니다 [1, 2].
- JSI (JavaScript Interface): 기존 브릿지를 대체하는 경량 C++ 기반의 레이어로, 자바스크립트 코드가 네이티브 객체에 대한 직접적이고 동기적인 참조를 가질 수 있게 합니다 [3, 4]. 이로 인해 통신 간의 데이터 직렬화(Serialization) 오버헤드가 완전히 제거되어 실시간에 가까운 고성능 통신이 가능해집니다 [3, 4].
- Fabric 렌더러: 새로운 UI 관리 및 렌더링 시스템으로, 비동기적 왕복 처리 없이 메인 스레드에서 네이티브 뷰를 측정하고 렌더링할 수 있습니다 [4, 5]. 이는 React 18의 동시성(Concurrent) 렌더링을 지원하며, 동기적인 레이아웃 계산을 통해 UI 요소의 반응성과 애니메이션이 훨씬 매끄럽게 동작하도록 개선합니다 [4, 5].
- TurboModules: 기존 네이티브 모듈은 앱 시작 시 모두 한꺼번에 초기화되어 시작 시간을 늦추는 원인이었으나, TurboModules는 모듈이 처음 사용될 때만 로드되는 지연 로딩(Lazy Loading) 방식을 도입했습니다 [4, 6]. 이는 앱의 초기 시작 성능을 높이고 초기 메모리 사용량(Footprint)을 크게 줄여줍니다 [4, 6].
- Codegen 도입: 자바스크립트와 네이티브(Java/Kotlin, Objective-C/Swift) 간 통신을 위한 C++ 보일러플레이트 코드를 빌드 타임에 자동으로 생성해 줍니다 [7]. 이는 두 계층 간의 강력한 타입 안전성을 제공하여 런타임이 아닌 컴파일 타임에 오류를 잡아냄으로써 성능과 코드 안정성에 기여합니다 [7].
⚖️ Trade-offs & Caveats
- 초기 시작 시간(Cold Start) 지연: AOT(Ahead-Of-Time) 컴파일을 통해 머신 코드로 직접 변환되는 방식과 달리, React Native는 앱 실행 시 자바스크립트 엔진(주로 Hermes)을 초기화하고 JS 번들을 파싱하는 과정을 거쳐야 합니다 [8]. 이 과정 때문에 대체로 300~600ms 수준의 초기 콜드 스타트 지연 시간이 발생할 수 있습니다 [8].
- 기존 브릿지 아키텍처의 레거시 부채: 새로운 아키텍처로 완전히 전환하지 않은 환경에서는 자바스크립트와 네이티브 간 브릿지 통신에서 메모리 누수(Memory leaks)가 발생할 수 있으며, 시간이 지남에 따라 점진적인 성능 저하 문제가 발생할 수 있습니다 [9].
- 서드파티 라이브러리 및 유지보수의 복잡성: 새로운 아키텍처와 JSI의 성능적 이점을 온전히 얻기 위해서는 서드파티 라이브러리들 역시 새 구조를 지원해야 합니다 [4, 9]. 또한 OS 업데이트나 메이저 버전 업그레이드 시 플랫폼 종속적인 코드 재작성과 광범위한 테스트가 요구되어, 큰 유지보수 비용(최대 2~3개월 소요)이 발생할 수 있습니다 [7, 9].
- 애니메이션 제어의 렌더링 한계: 자체적인 렌더링 파이프라인을 온전히 통제하는 방식이 아니므로, 매우 복잡한 커스텀 애니메이션(파티클 효과 등)에서는 렌더링 성능의 한계가 드러날 수 있습니다 [10, 11]. 하지만 실제 네이티브 플랫폼 컴포넌트를 직접 사용하기 때문에 별도의 커스텀 렌더링 트리를 유지할 필요가 없어, 기본 메모리 사용량과 번들 크기는 더 작게 유지되는 긍정적 반대 급부도 가집니다 [8, 12].
Last updated: 2026-05-03
📚 Legacy Insights & Additional Context
Note
Below is content merged from previous versions of this documentation.
📌 Brief Summary
성능 최적화(Performance Optimization)는 소프트웨어의 기능적 동작을 동일하게 유지하면서 시간이나 메모리와 같은 자원 사용량을 개선하기 위해 내부 구조를 변경하는 과정입니다 [1-3]. 코드를 더 이해하고 수정하기 쉽게 만드는 리팩토링(Refactoring)과 유사하게 기능은 유지하지만, 구조 개선이 아닌 속도 향상이나 자원 효율성을 주된 목적으로 삼는다는 점에서 구별됩니다 [1, 2, 4]. 성공적인 성능 최적화를 위해서는 이해하기 쉬운 코드로 먼저 리팩토링하여 튜닝하기 좋은 상태를 만드는 것이 필수적인 선행 조건으로 간주됩니다 [5-7].
📖 Core Content
-
리팩토링과 최적화의 관계: 소프트웨어 개발에서 기능 추가나 버그 수정과 달리, 리팩토링과 최적화는 모두 기존 기능을 불변으로 유지하면서 다른 속성을 변경한다는 공통점을 가집니다 [4]. 리팩토링은 프로그램의 구조(Structure)를 변경하는 반면, 최적화는 자원 사용량(Resource Usage)을 변경합니다 [2, 3].
-
성능 개선을 위한 3가지 접근 방식 [8-11]:
- 시간 예산 할당 (Time Budgeting): 심박조율기처럼 지연된 데이터가 치명적인 하드 실시간(Hard real-time) 시스템에서 주로 사용되며, 각 컴포넌트에 엄격한 시간과 자원 예산을 할당하는 방식입니다 [8].
- 지속적 주의 (Constant Attention): 모든 프로그래머가 항상 성능을 높게 유지하기 위해 노력하는 방식이지만, 실제로는 프로그램을 이해하고 수정하기 어렵게 만들어 개발 속도를 늦추기 때문에 효과적이지 않습니다 [9].
- 프로파일러 기반 튜닝 (Profiler-Driven Tuning): 대부분의 프로그램은 아주 작은 일부 코드에서 대부분의 시간을 낭비한다는 통계에 기반한 접근입니다 [10]. 성능에 신경 쓰지 않고 구조가 잘 짜인(Well-factored) 프로그램을 먼저 만든 후, 프로파일러를 사용해 시간과 공간을 소비하는 '핫스팟(Hot spots)'을 찾아 집중적으로 최적화합니다 [10, 11].
-
잘 리팩토링된 코드가 최적화에 미치는 이점: 잘 구조화된 프로그램은 기능 추가 속도를 높여주어 성능 튜닝에 투자할 시간을 더 많이 확보해 줍니다 [6]. 또한, 코드의 의도가 명확하고 구조가 잘게 나누어져 있어 성능 분석 시 더 세밀한 단위(Finer granularity)로 프로파일링하고 튜닝할 수 있는 이점을 제공합니다 [6].
-
성능 최적화 관련 기법: 기존 알고리즘이 유지보수할 수 없는 성능 병목 지점이 되었을 때 전체 구현을 교체하는 '알고리즘 전환(Substitute Algorithm)' 기법이 사용될 수 있습니다 [12]. 또한, 임시 변수를 질의 함수로 바꾸는 기법(Replace Temp with Query)은 데이터 흐름을 명확히 하여 향후 최적화, 메모이제이션(Memoization) 또는 병렬 실행을 지원하는 토대가 됩니다 [13]. 하드웨어 측면에서는 소프트웨어가 병렬 프로세서나 벡터 유닛의 이점을 취할 수 있도록 조정하는 작업도 포함됩니다 [14].
⚖️ Trade-offs & Caveats
-
단기적 성능 저하와 장기적 튜닝 용이성의 상충 (Trade-off): 코드를 이해하기 쉽게 만드는 리팩토링 과정은 종종 단기적으로 프로그램의 실행 속도를 느리게 만들 수 있습니다 [5, 7]. 예를 들어, 임시 변수를 제거하는 리팩토링 과정에서 루프가 여러 번 실행되거나 계산이 중복되어 성능 비용을 지불해야 할 수 있습니다 [15, 16]. 그러나 이러한 단기적인 성능 저하를 감수하면 오히려 강력한 최적화 옵션을 발견하기 쉬워지므로 최종적으로는 더 빠른 소프트웨어를 만들 수 있습니다 [7, 17].
-
최적화로 인한 코드 가독성 저하: 성능을 개선하기 위한 코드 변경은 대개 프로그램의 복잡도를 높이고 코드를 이해하기 어렵게 만듭니다 [1, 9]. 이것이 '지속적 주의' 방식이 오히려 개발을 느리게 만들고 낭비를 초래하는 주된 이유입니다 [9].
-
추측에 기반한 최적화의 위험성 (Caveat): 성능 최적화 시 가장 주의해야 할 점은 시스템을 잘 안다고 생각하여 병목 지점을 함부로 추측(Speculate)해서는 안 된다는 것입니다 [5, 18]. 경험 많은 개발자의 좋은 아이디어조차 실제 측정 결과와 다를 때가 많으므로, 반드시 프로파일러 도구로 실제 성능을 측정(Measure)한 후 최적화를 진행해야 합니다 [5, 11, 19].
-
AI 도구 활용 시 제약 사항: 성능이 중요한 최적화(Performance-critical optimization) 작업은 복잡성이 매우 높은 작업이므로, AI 코딩 도구를 사용할 경우 오히려 작업 속도를 지연시키거나 방해가 될 수 있습니다 [20, 21]. 따라서 이러한 맥락에서는 AI 지원 없이 전문가의 판단에 의존하는 것이 권장됩니다 [21].
Last updated: 2026-05-03