docs(10_Wiki): 위키 전체 재구성 — Topic_* 폴더를 4개 카테고리로 통합 + 대규모 중복 제거
Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를 Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류. - 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로 자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거, 동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거. - 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming, Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business, Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로, 나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는 title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백). 원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지. - 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서. - 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는 지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지. - Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경. - 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.
This commit is contained in:
@@ -0,0 +1,36 @@
|
||||
---
|
||||
category: Frontend
|
||||
tags: [auto-wikified, technical-documentation, frontend]
|
||||
title: React Native
|
||||
description: "React Native는 2015년 메타(Meta, 구 Facebook)에서 개발한 오픈 소스 크로스 플랫폼 모바일 애플리케이션 개발 프레임워크이다 [1, 2]."
|
||||
last_updated: 2026-05-04
|
||||
---
|
||||
|
||||
# React Native
|
||||
|
||||
## 📌 Brief Summary
|
||||
React Native는 2015년 메타(Meta, 구 Facebook)에서 개발한 오픈 소스 크로스 플랫폼 모바일 애플리케이션 개발 프레임워크이다 [1, 2]. 자바스크립트(JavaScript)와 타입스크립트(TypeScript)를 기반으로 하여 단일 코드베이스로 iOS, Android, 웹 및 데스크톱 애플리케이션을 구축할 수 있다 [1, 3]. 고유한 렌더링 엔진 대신 호스트 운영체제의 기본(Native) UI 컴포넌트를 사용하여 사용자에게 100% 네이티브와 같은 외관과 동작을 제공하는 것이 가장 큰 특징이다 [3, 4].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
* **자바스크립트 생태계 및 React 패러다임 활용**
|
||||
React Native는 세계에서 가장 널리 사용되는 자바스크립트와 React 패러다임을 그대로 모바일 환경에 적용한다 [5, 6]. 이는 웹 개발자가 상대적으로 낮은 학습 곡선으로 모바일 개발에 진입할 수 있게 하여 '인재 이동성(Talent Portability)'을 제공하며, 단일 팀이 웹과 모바일 코드베이스 전반에 기여할 수 있는 전략적 이점을 창출한다 [7, 8]. npm 저장소의 방대한 라이브러리는 물론, Zustand, TanStack Query(React Query)와 같은 웹 생태계의 상태 관리 도구들을 그대로 활용할 수 있다 [9, 10].
|
||||
* **네이티브 UI 렌더링 (Native Components)**
|
||||
React Native는 자바스크립트 코드를 실제 플랫폼의 네이티브 UI 컴포넌트(iOS의 `UIView`, Android의 `View`)로 변환하여 렌더링한다 [4, 11]. 이러한 렌더링 방식 덕분에 플랫폼 고유의 스크롤 물리 효과, 텍스트 선택 동작, 자동 수정, 동적 타입, 접근성 기능(VoiceOver, TalkBack) 등을 추가적인 노력 없이 자연스럽게 상속받아 온전한 네이티브 사용자 경험(UX)을 제공한다 [4, 12].
|
||||
* **새로운 아키텍처 (New Architecture)의 도입**
|
||||
기존 React Native의 가장 큰 성능 병목으로 지적되던 비동기 자바스크립트 브릿지(Bridge)를 제거하고, 성능을 극대화하기 위해 아키텍처를 대대적으로 개편하였다 [13, 14].
|
||||
* **JSI (JavaScript Interface):** 브릿지를 대체하는 기초 레이어로, 자바스크립트 코드가 C++를 통해 네이티브 객체를 직접적이고 동기적으로 호출할 수 있게 하여 직렬화(Serialization) 오버헤드를 완전히 제거한다 [15, 16].
|
||||
* **Fabric:** JSI를 기반으로 구축된 새로운 UI 렌더링 시스템으로, 메인 스레드에서 동기적인 레이아웃 계산과 렌더링을 가능하게 하여 UI 반응성을 크게 향상시킨다 [16, 17].
|
||||
* **TurboModules:** 앱 시작 시 모든 네이티브 모듈을 로드하던 기존 방식 대신, 필요할 때만 지연 로딩(Lazy-loading)하는 모듈 시스템으로 초기 시작 시간과 메모리 사용량을 대폭 줄여준다 [16, 18].
|
||||
* **Expo 에코시스템을 통한 개발 표준화**
|
||||
최근 React Native 개발에서는 Expo가 프로덕션 앱 구축의 실질적인 표준(De Facto Standard)으로 자리 잡았다 [19, 20]. EAS(Expo Application Services)를 이용한 클라우드 빌드 및 배포 자동화, Expo Router를 통한 파일 기반 네비게이션, 그리고 네이티브 코드를 직접 건드리지 않고도 외부 라이브러리를 통합할 수 있는 Config Plugins 기능 등을 제공하여 개발 생명주기를 획기적으로 간소화한다 [19, 20].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
|
||||
* **플랫폼 파편화 및 유지보수 비용:** iOS와 Android의 네이티브 모듈은 독립적으로 진화하기 때문에, OS 업데이트나 네이티브 플랫폼의 변경 사항에 따라 플랫폼 종속적인 수정이 필요할 수 있다 [21]. 이로 인해 브릿지 및 서드파티 라이브러리 관련 버그를 해결하기 위한 장기적인 유지보수 오버헤드가 발생한다 [22-24].
|
||||
* **버전 업그레이드의 복잡성:** 주요 버전 업데이트 시 광범위한 테스트가 요구되며, 서드파티 라이브러리가 새로운 OS 버전을 즉각적으로 지원하지 않을 경우 호환성 문제가 발생할 수 있다 [22].
|
||||
* **디버깅 난이도:** 자바스크립트 로직과 네이티브 코드가 결합된 하이브리드 환경의 특성상, 에러가 네이티브 영역(혹은 서드파티 라이브러리의 네이티브 코드)에서 발생할 경우 원인을 추적하고 디버깅하는 과정이 순수 네이티브 개발보다 훨씬 복잡해진다 [25, 26].
|
||||
* **커스텀 UI 및 복잡한 애니메이션 한계:** 네이티브 컴포넌트를 사용하기 때문에 플랫폼 표준 인터페이스 구현에는 유리하지만, 렌더링 파이프라인을 완전히 통제하는 Flutter와 비교했을 때 플랫폼 종속성을 벗어나는 극도로 복잡한 맞춤형 애니메이션이나 고사양 그래픽 처리를 구현하는 데에는 구조적 한계가 존재한다 [27-29].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-03*
|
||||
Reference in New Issue
Block a user