안녕하세요, 소플입니다.
지난 매거진(React Conf 2025 (Day 1))에 많은 분들께서 뜨거운 관심을 보여주셨는데요,
이번 매거진에서는 지난 매거진에 이어 2025년 리액트 컨퍼런스 둘째 날에 발표된 내용들을 한 번 정리해보도록 하겠습니다 😀
목차
React Native Keynote
Jorge Cohen (React Team @ Meta)
Nicola Corti (React Team @ Meta)
Rubén Norte (React Team @ Meta)
Alex Hunt (React Team @ Meta)
Riccardo Cipolleschi (React Team @ Meta)
💡 소플의 한 줄 요약
React Native 생태계의 발전과 새로운 기능 소개
🔗 영상 링크
Jorge Cohen
React Native 개요 및 미래
- React Native: "learn once, write anywhere"로 적은 코드로 멀티플랫폼 앱 개발, 코드 공유
- React Conf 앱: 단일 코드베이스로 플랫폼별 디자인 언어 구현
- "It's React. Truly Native": 네이티브 모듈/widgets/live activities로 진정한 네이티브 경험 제공
- React의 선언적 UI, 컴포넌트 기반 아키텍처, state management, hot reload, 개발자 경험이 업계 표준화
Nicola Corti
React Native 현황 및 생태계
- 다운로드:
- 주간 200만 → 400만 (100% 성장)
- 2025년 현재까지 총 1.2억 회 이상
- 릴리스:
- 2025년부터 연 6회
- React Native 0.82("A New Era") 출시
- 올해 12월에 0.83 릴리즈 예정
- 생태계:
- 수상 앱:
- Rise: React Native Skia로 UI/애니메이션
- Runna: 네이티브 통합, Skia로 운동 요약
- Partiful: Play Store Best, app clips/live activities 통합
- New Architecture 성공 사례:
- 마이그레이션 사례:
- AI 앱: Mistral Le Chat, Replit, Vercel v0, Microsoft Copilot for Office(Word)
- 미래 플랫폼:
- Amazon Vega OS:
- Fire TV에 React Native 내장
- The First React Native OS
- VR:
React Native 툴링
- Expo:
- SDK 54: React Native 0.81, Liquid Glass, iOS pre-compiled binaries
- Expo App Awards로 혁신 앱 조명
- Expo Launch로 빠른 앱 출시
- React Native DevTools:
- 새로운 디버거 아키텍처로 React Native/Hermes 통합
- Radon IDE 등 타사 툴링에서 inline breakpoints 지원
Rubén Norte
New Capabilities
- New Architecture:
- Web Convergence:
- React Strict DOM: HTML/CSS polyfill로 웹 기능 지원
- DOM APIs (v0.82):
- 네이티브 컴포넌트 layout/position 접근
- 50개 이상 속성/메서드, 10개 웹 인터페이스 추가
- Meta의 Visual Completion Tracker 같은 JS 라이브러리 통합
Alex Hunt
- Web Performance APIs:
- Event Timings: 사용자 입력과 UI 업데이트 사이의 시간 (앱의 응답성)
- Long Tasks: 이벤트 루프에서 여러 프레임에 걸쳐 렌더링을 방해하고 차단하는 긴 작업을 노출하여 성능 저하를 나타낼 수 있음
- User Timings: 앱이 자체적으로 커스텀 성능 이벤트를 보고할 수 있게 해줌
performance.mark()
: 특정 순간을 레이블링
performance.measure()
: 시간 범위를 기록
- Performance Observer: 프로덕션 환경 성능 측정
- React Native DevTools (v0.83 예정):
- Performance Panel: Timeline view, JS Samples, User Timings, React Performance Tracks, Cascading updates
- Network Panel: Fetch/XHR/Image 요청 검사, Request Initiator, Network track 동기화
- Desktop App: zero setup, Auto-raise on breakpoints, Saved window arrangements
Riccardo Cipolleschi
Future of React Native
- The New Architecture:
- 0.76부터 기본 활성화, 0.82부터 유일 아키텍처 (The only Architecture)
- 장점:
- 번들 크기 1MB 감소
- 빌드 시간 단축(iOS 기준 300초 → 140초)
- 더 단순한 멘탈 모델
- 더욱 빠른 기능 개발
- 마이그레이션: 0.81로 테스트 후 0.82로 이동, Interop Layers 유지
- Hermes V1:
- 성능: 벤치마크 60% 향상, Expensify 앱 최대 9% 개선
- Modern JavaScript 기능:
- ES6 classes
- public/private class fields
let
/const
bindings
- Async functions
- New
Set
methods
- 0.82에서 experimental feature 제공
React Native, Amplified
Giovanni Laquidara (Sr Developer Evangelist @ Amazon)
Eric Fahsl (Principal Product Manager @ Amazon)
💡 소플의 한 줄 요약
React Native가 내장된 Vega OS 소개 및 Amazon의 앱 개발 생태계 공유
🔗 영상 링크
Amazon Devices 개요
- 2007년 OG Kindle 언급
- 현재 이어버드, TV, 태블릿, 스마트 홈 등 다양한 디바이스 출시
- 디바이스 운영체제는 Linux, Android, AOSP 등. Fire TV와 태블릿 포함
Vega OS 소개
- Amazon에서 개발한 새로운 운영체제
- 다양한 디바이스에서 실행 가능
- React Native 내장
- 8일 전 공식 발표
- Low-footprint 디바이스부터 고급 디바이스까지 지원
Vega OS의 기술적 특징
- Linux 기반, Yocto 사용
- OSS 미들웨어 포함
- Weston (그래픽)
- GStreamer (미디어)
- React Native Libraries와 Runtime 내장
- 기존 Android 기반 디바이스보다 30% 더 자원 효율적
- Amazon Silicon에서 실행
- Fire TV Stick에서 3P Apps 지원
React Native와 Vega OS 통합
- React Native for Vega는 OS에 내장 (
@amazon-devices/react-native-kepler
)
- React Native 0.72 버전 사용
- New Architecture 지원
- JSI, Fabric, C++ 지원
- Rust 지원 준비 중
- Core React Native의 80% 지원
- 40개 이상 RN 라이브러리 포팅
- WebView 지원
- Hermes와 React Native Runtime 동적 링크
- 앱 간 라이브러리 및 런타임 공유
- Smooth한 사용자 경험 제공
Amazon의 앱 개발
- Fire TV UI, Launcher App, Settings, App Store 모두 React Native로 구축
- 최적화
- Native C++ Components
- Fast Image Pipeline
- Seamless한 앱 전환 경험
- 다양한 디바이스에서 동일 코드베이스 사용 가능
개발자 도구 및 지원
- Vega Developer Tools, 9월 30일 Public Beta 출시
- 개발 도구
- CLI
- Emulator
- VS Code Plugin (Vega Studio)
- Hello World 템플릿으로 쉬운 시작 가능
- Manifest File로 앱 정보 및 권한 정의
- Amazon Q 및 Kiro로 AI 기반 개발 지원
앱 포팅 및 디버깅
- 기존 React Native 앱을 Vega로 간단히 포팅 가능
- Amazon Devices Namespace(
@amazon-devices/
)로 라이브러리 변경
- 지원 라이브러리
- React Native Video Library
- W3C Media Player
- Vega Studio로 디버깅 통합
- Break Point
- CPU/Memory Profiling
- Chrome Developer Tools 통합
커뮤니티 및 오픈 소스
- Meta, Software Mansion과 협력
- ABI 및 API Stability 제공
- 포팅된 라이브러리
- Reanimated
- Expo Libraries
- Media Player, Ads, Analytics
- github.com/amazonappdev에서 샘플 앱 오픈 소스 제공
- MonorepoTV App으로 다중 플랫폼 지원
개발자 피드백 및 향후 계획
- Public Beta 단계, 피드백 수용
- 부스에서 Kiro Credit Codes 제공
- Library Maintainer와 포팅 협력
- 최신 React Native 버전 업데이트 예정
- 개발자 포럼 및 문서 지원
React Strict DOM
Nicolas Gallagher (Software Engineer @ Meta)
💡 소플의 한 줄 요약
단일 React UI 구축 방식으로 웹과 네이티브를 아우르기 위한 비전
🔗 영상 링크
현재 상황
- React의 혁신: React의 컴포넌트 모델은 UI 구축 방식을 변화시켰으나, 기술 스택은 웹과 네이티브 간 단절(fragmentation) 로 인해 비효율적
- 문제점:
- 플랫폼별 API 학습 필요, 코드 이식성 부족
- 스타일링 선택(CSS modules, utility CSS 등)의 다양성으로 코드베이스 불일치
- 네이티브로의 전환 시 React Native의 다른 API로 인해 재작업 필요
- 단절은 개발자 부담, 커뮤니티 분열, LLM과 같은 신기술 활용 저해
비전: 통합된 React 프레임워크
- 목표:
- 웹과 네이티브를 아우르는 단일 React UI 구축 방식
- One React: Learn Once. Write Once.
- 과거 시도:
- React Native for Web: 웹 품질 미달, 기존 웹 코드와의 비호환성
- 새로운 UI 라이브러리: 마이그레이션 비용 높고 시각적 회귀 문제
- 해결책:
- Meta의
react-strict-dom
은 React DOM과 React Native를 통합
- 플랫폼 간 일관된 UI 설명 제공
- 장점:
- 플랫폼별 선택 및 스타일링 논쟁 감소
- 기존 웹 코드 재사용으로 빠르고 안전한 네이티브 전환
- 웹 개발자의 익숙한 API 활용, 네이티브의 스타일 캡슐화 유지
react-strict-dom
의 접근
- 구성:
- HTML 모듈: React DOM의 크로스 플랫폼 컴포넌트 서브셋
- CSS 모듈: React Native 스타일시트의 향상된 크로스 플랫폼 버전
- 특징:
- 웹에서는 React DOM과 유사, 엄격한 타입의 props 및 React Native 스타일 prop 지원
- 네이티브에서는 웹 API를 네이티브 API로 매핑, 플랫폼별 렌더링 충실
- StyleX로 CSS 기능 확장, 캡슐화 유지
성과 및 사례
- Facebook VR 앱: 웹 코드를
react-strict-dom
으로 네이티브화
- 빠른 기능 배포, 일관된 경험 제공
- 네이티브 품질 유지, 성능 저하 최소화
- 성과:
- 웹과 60% 코드 공유
- 웹에서
div
10%, span
20% 렌더링
- 시각적/성능 회귀 거의 없음
- 성능 최적화: 네이티브 렌더링 속도 2.5배 개선, JavaScript 폴리필 최적화
도전 과제
- 트레이드오프: 네이티브에서 폴리필로 인한 런타임 비용
- 미해결 과제: 크로스 플랫폼 컴포넌트 유닛 테스트 간소화
미래 비전
- React Native 개선: HTML, CSS, DOM API의 고성능 렌더러로 진화(현재 63% 지원)
- 애니메이션: 크로스 플랫폼 애니메이션 API 실험(웹: Web Animations API, 네이티브: C++ 기반)
- 스타일링 통합: StyleX 피드백 반영, 통합된 스타일링 솔루션 제공
- 목표:
- 단절 감소, 중복 노력 최소화
- 컴포넌트 네이티브 스타일링 기본 제공
- 일관성과 품질을 위한 기반 구축
- AI와의 연계: 명확한 API로 LLM 학습 최적화, 코드 생성의 일관성 보장
결론
- react-strict-dom은 웹과 네이티브를 통합하여 React의 잠재력을 극대화
- 웹 API 표준화로 개발자 친화성 및 코드 이식성 강화
- 커뮤니티의 피드백과 참여로 미래 형성
Reimagining Lists in React Native
Luna Wei (React Team @ Meta)
💡 소플의 한 줄 요약
사용자 경험과 성능 두 마리의 토끼를 모두 잡기 위한 VirtualView 컴포넌트 소개
🔗 영상 링크
발표자 소개
- 발표자: Luna Wei, 7년간 React 조직에서 활동
- 발표 주제: Reimagining Lists in React Native
- React Native 팀의 새로운 아키텍처와 리스트 최적화에 대한 논의
- 출산 휴가 후 복귀, 새로운 아키텍처 관련 API 작업 참여
새로운 아키텍처
- Meta에서 1년간 React Native 앱을 새로운 아키텍처로 마이그레이션
- 새로운 아키텍처는 기본 아키텍처로 설정됨
- 목표: 이전 아키텍처에서 불가능했던 기능과 개선 사항 활성화
- 주요 초점: 리스트, 특히 Blanking List 문제 해결
Blanking List 문제
- 리스트 스크롤 시 콘텐츠가 사라지는 현상
- 모바일 앱에서 중요한 문제, 사용자 경험에 부정적 영향
- 원인: 가상화(virtualization)와 아키텍처의 한계
- 가상화: 보이는 항목만 렌더링, 스크롤에 따라 항목 업데이트
- 아키텍처: 백그라운드 스레드에서 렌더링, 메인 스레드와의 비동기 처리로 인해 렌더링 지연
- 결과: 빠른 스크롤 시 렌더링되지 않은 항목으로 인해 빈 화면 발생
해결 방안: 동기 이벤트와 VirtualView
- 동기 이벤트(Synchronous Events)
- 메인 스레드에서 스크롤 이벤트 발생 시 JS 엔진 접근
- 렌더링 완료 후 메인 스레드에서 페인트, 백그라운드 스레드로 JS 엔진 반환
- 문제: JS 엔진의 단일 스레드 특성으로 인해 지연 가능
<VirtualView />
- 실험적 컴포넌트, 0.82 릴리스에 포함
- 뷰포트와의 관계에 따라 hidden, prerender, visible 모드 정의
- 모드 변경 이벤트에 따라 동기/비동기 렌더링 및 우선순위 결정
- hidden → prerender: 비동기, 낮은 우선순위
- prerender → visible: 렌더링 불필요 (이미 prerendered)
- hidden → visible: 동기, 높은 우선순위로 즉시 렌더링
<VirtualView />
는 blanking 문제를 해결하며 적절한 스레드에서 렌더링
Virtual Collections
<VirtualView />
를 활용한 virtual column과 virtual row
- 리스트 프리미티브로, 지연 마운트, 레이아웃, 가상화에 초점
- 스크롤 뷰와 분리, 최소 API로 조합성 극대화
- 동작
- visible 영역의 빈 공간을 메인 스레드에서 렌더링
- prerender 영역은 백그라운드 스레드에서 처리
- 최적화된 파라미터와 동적 prerender 영역 탐색 중
현재 상태와 미래
- Virtual column은 FlatList를 대체 하는 것은 아님, 복잡성 외부로 위임
- 실험적 컴포넌트, 프로덕션 테스트 중
- 0.83 릴리스에서 virtual column/row 문서화 예정
- 커뮤니티 피드백 요청, 최신 문서에서 컴포넌트 이름 확인 필요
- 추가 최적화와 DOM API, Intersection Observer 등 활용 예정
결론
- React Native의 런타임 관리로 유연성과 제어 가능
- 동기 렌더링과 새로운 컴포넌트로 모바일 UI 프레임워크 수준의 성능 제공
- 10년간의 기술 축적 기반, 2016년 렌더링 분할부터 Hermes 최적화까지
- 팀과 커뮤니티에 감사, 리스트 관련 추가 논의 환영
React Everywhere: Bringing React Into Native Apps
Mike Grabowski (Founder & CTO @ Callstack)
💡 소플의 한 줄 요약
React와 React Native를 구분하지 말고 단일 코드베이스로 크로스 플랫폼 앱을 개발해보자!
🔗 영상 링크
발표자 소개 및 배경
- 발표자: Mike, Callstack의 CTO이자 Founder
- React Native를 2016년부터 사용 및 개발
- React Native 릴리스 및 커뮤니티 패키지 기여
- Callstack은 React 및 React Native로 Universal Apps를 구축하는 소프트웨어 컨설팅 회사
- 주제: React를 웹을 넘어 Native Apps로 확장하는 방법
WebView의 한계
- WebView는 native app 내부에 포함된 embedded web browser
- iOS: WebKit + JSC
- Android: Chromium + V8
- 장점: 빠른 통합
- 단점:
- UX 저하 (gesture 반응 느림, 부드럽지 않은 UI)
- 복잡한 native communication bridge 필요
- serialization으로 인한 performance bottleneck
- Web팀과 Native팀 간 ownership 불명확, 개발 속도 저하
React Native의 등장
- React components를 native UI로 실행
- React는 UI와 memory를 관리하는 라이브러리 → renderer 필요
- ReactDOM → 웹, React Native → 모바일
- React Native는 React components를 native performance로 렌더링
Brownfield 접근
- 기존 앱 일부에 React Native를 점진적으로 도입
- React처럼 “작게 시작할 수 있음”
- 기존 Native App에 React Native view를 삽입 가능
- iOS, Android, Vega 등 cross-platform 코드 공유
- React Native를 기존 앱에 쉽게 통합하기 위한 Callstack의 라이브러리
- ReactNativeView 같은 helper 제공
- runtime initialization, component 렌더링, navigation bridging 자동 처리
- rock: React Native 앱을 단일 라이브러리로 번들링 하기 위한 도구
- iOS: XCFramework / Android: AAR 형태로 패키징
- RN runtime, native modules, JS bundle, assets 포함
Universal 코드 작성
- Logic: 대부분 웹과 호환 (
useState()
, useEffect()
, fetch
등)
- View Layer: Metro bundler의
.native.tsx
/ .web.tsx
확장으로 플랫폼별 파일 선택
- 라이브러리:
- Platform APIs: Expo SDK (
expo-device
, camera 등)로 단일 API 제공
React Native의 이점
- Performance 개선:
- WebView보다 빠른 렌더링
- Shared memory 기반 communication으로 bottleneck 해소
- Ownership 통합:
- 웹, iOS, Android를 단일 팀에서 관리
- Single codebase로 다중 플랫폼 배포
점진적 Migration 전략
- WebView부터 React Native로 교체 시작 (웹 코드 활용 용이)
- 단일 view → screens → 전체 user flows로 확장
- KPI 설정 후 속도에 맞춰 진행
결론 및 메시지
- WebView는 종종 타협의 결과물, React Native가 근본적 해결책
- Logic 및 UI 공유를 통한 조직 효율성 향상
- React Native는 “다른 기술”이 아니라 React의 또 다른 target
- React 개발자라면 누구나 cross-platform UI 구축 가능
- 핵심 관점: “우리는 React로 멋진 UI를 만드는 개발자다”
How Parcel Bundles React Server Components
Devon Govett (Software Architect @ Adobe)
💡 소플의 한 줄 요약
Parcel bundler에서 RSC를 지원하는 방법과 장점 소개
🔗 영상 링크
발표 소개
- Devon Govett:
- Parcel v2.14.0에서 React Server Components (RSC) 지원 추가
- RSC는 서버에서만 실행되며 브라우저에서 실행되지 않음
- 데이터베이스 직접 접근 가능, Code Splitting 개선, Network Waterfalls 제거
Parcel의 RSC 지원 특징
- Parcel은 framework가 아닌 bundler
- 개발자가 web server, routing 등 직접 처리해야 함
- Express server 예시: server component를 HTML로 렌더링
- First-class RSC 지원으로 다른 framework (e.g., React Router)의 RSC 구현 용이
- 레이어 분리로 어떤 앱에도 RSC 쉽게 추가 가능
fetchRSC
: fetch
를 감싼 래퍼 → React element로 확인되는 Promise 반환
- React 19의 Promise 렌더링 지원 활용
- 컴포넌트에서 Promise를 직접 반환하거나 다른 JSX로 감쌀 수 있음
- 서버에서 렌더링된 콘텐츠가 클라이언트 앱에 삽입됨
- SSR 처리 방식:
- 예시에서는 SSR(서버 사이드 렌더링) 없음
- 클라이언트에서 직렬화된 컴포넌트를 렌더링
- 성능이 중요한 페이지에는 선택적으로 SSR 추가 가능
전통적 SPA 문제점
- 단일 entry JS bundle과 클라이언트 routing
- dynamic import로 on-demand module 로드
- 브라우저가 초기화 후 URL 확인 → 추가 코드 로드 → Network Waterfall 발생
- 중첩 route와 dynamically loaded component로 앱 느려짐
- 수동 preloading: 구현 어려움, React composition 위배
RSC의 해결 방식
- 서버와 클라이언트를 단일 module graph로 병합
"use client"
지시어로 서버가 클라이언트에 props
전달
- React와 bundler가 코드와 데이터 자동 preload
Parcel의 구현 메커니즘
- 각 module에 environment (서버/브라우저 실행 위치) 연결
"use client"
지시어:
- environment를 React Client로 변경
- proxy module 생성
- Client Reference: bundle ID, export 이름, preload bundle URLs 포함
- RSC payload: streaming JSON format으로 브라우저 전송 및 역직렬화
- React lazy component로 client reference 확인 및 렌더링
CSS 지원
- Server Components에서 CSS side effect import 처리
- code-splitting boundaries에
<link />
태그 자동 주입
- React 19의
precedence
prop으로 head hoist 및 중복 제거
- CSS 로드 완료까지 suspend → flash of unstyled content 방지
Code Splitting 개선
- Parcel의 통합 module graph로 environment 간 code splitting 확장
- 공통 dependencies bundle 공유
"use client"
가 명시적 splitting point 아님 → Client Components 단일 bundle 그룹화
- 서버 코드 구조에 따른 최적화 가능
Network Waterfalls 제거
- 서버 dynamic import: zero latency (디스크 로드)
- 서버 데이터 로드 빠름 (data center 근접)
- HTML에 client components preload tags 자동 삽입
- 중첩 수준 무관 병렬 로드
- 데이터 내장으로 별도 API 요청 불필요
- 컴포넌트 구조 변경 없이 SPA 버전과 동일 코드로 waterfalls 제거
결론
- RSC가 bundler와 React runtime 협력으로 code/data 병렬화
- low-level APIs로 framework 개발 지원
- server functions 등 추가 주제 언급
- 자세한 블로그 게시물 안내
Designing Page Transitions
Delba de Oliveira (DX Engineer @ Vercel)
💡 소플의 한 줄 요약
View Transitions를 사용해서 만든 발표 자료로 View Transitions 설명하기
🔗 영상 링크
문제 인식
- 많은 사람들이 open web을 믿고 web의 번영을 원함
- Mobile 앱은 세밀한 transitions로 사용자 경험 향상
- Web의 SaaS dashboard는 animations 부족
- Web에서 animation은 장식으로 여겨짐
View Transitions 소개
- View Transitions API가 server-rendered pages 간 animating 어려움 해결
- Browser가 new page painting 전 old/new page 상태 pause
- React에서
<ViewTransition />
component로 opt-in
- 기본 crossfade transition 제공
구현 예시 (Next.js + React)
기본 Slide Transition
- CSS keyframes로 horizontal motion 정의
- Specific class names target
enter
/exit
props에 classes map
- 문제: 모든 transition이 같은 방향
방향 커스터마이징
- Custom Link 컴포넌트 생성
- Next.js
<Link />
, startTransition()
, router.push()
type
prop으로 transition type 전달
- Previous/Next 버튼에 방향 할당
enter
/exit
props 업데이트로 방향별 애니메이션 구현
Shared Element Transitions
- Header, Footer 등 변하지 않는 요소 제자리 고정
- 중첩된
<ViewTransition />
에 unique name 부여
- Main transition에서 제외됨
- 변하는 요소는 브라우저가 scale/position 자동 처리
Motion Design 팁
- Motion Blur: 빠른 움직임에 블러 효과 적용 (눈의 피로 감소)
- Easing/Duration: 짧고 유동적인 animation
- Reduced Motion: 접근성 고려해 motion 줄임/제거
- Composition: Reusable components로 패턴 추출, NPM packages publish
내부 동작 원리
- DevTools animations panel로 pseudo-elements(
::view-transition
) 관찰
- Browser가 old/new pages의 temporary pseudo-elements 생성
- Static images 간 animation으로 고성능
- DOM pixel-by-pixel 업데이트 피함
- Developer 역할: 요소 선택, animation 설계, React/browser coordination 위임
결론
- 이번 발표 자체가 View Transitions로 구축
- 간단 시작 → 복잡한 animations layer-in
- Animations는 장식 아님, 사용자 안내 및 polished 경험 제공
- React/Next.js View Transitions로 웹 표준 향상 기대
Build Fast, Deploy Faster—Expo in 2025
Evan Bacon (Software Engineer @ Expo)
💡 소플의 한 줄 요약
Expo와 AI의 조합으로 빠르게 앱 만들고 배포하기
🔗 영상 링크
Expo의 주요 기능
- Expo는 개발자들이 고품질 모바일 경험을 빠르게 구축할 수 있게 함
- WWDC의 liquid glass effects 등 최신 효과를 즉시 앱에 추가 가능
- Link previews, context menus 등 플랫폼 최적화 효과 포함
- 직관적이고 composable한 React-first API 제공
- React Compiler 기본 활성화로 성능 최적화 (특히 저사양 Android에서 우수)
- Live activities, home screen widgets, app clips 등 네이티브 기능 쉽게 통합
배포 혁신
- Web의 EAS Deploy처럼 모바일에서도 즉시 배포 가능
npx testflight
명령으로 빌드, 서명, TestFlight 전송 자동화
- TestFlight setup end-to-end 자동화로 Apple 웹사이트 양식 작성 불필요
- EAS Build 업그레이드, Bun 사용, Metro Bundler 최적화, iOS React Native pre-compile로 4배 빠른 빌드
- 기본 프로젝트 5분 내 배포
- Expo Launch로 브라우저에서 one-click deployment, iPhone에서 10분 내 end-to-end 앱 런치 가능
- Tesla나 심지어 Apple Watch에서도 Xcode projects를 컴파일할 수 있음을 의미
- 10분 이내라는 것은 하루에 약 144번의 배포를 의미
라이브 데모
- 모바일 코드 에디터 프로토타입 시연 (Monaco editor 기반)
- 실시간 코드 편집과 자동 업데이트
- AI Copilot으로 코드 생성
- Expo API Routes, server actions 활용
- Pokédex 앱 40초 내 생성
- 검색, favorites, liquid glass effects, context menus 포함
- Expo Launch로 App Store 배포 시작 가능
새로운 발표: Expo CSS 지원
- Mark Lawlor와 협력한 네이티브 앱용 CSS 지원 추가
- Scoped CSS 코드 작성, cross-platform 사용
- Tailwind 곧바로 사용 가능
- Native monospaced fonts, high performance animations 쉽게 구현
- Pseudo-classes, Media queries, CSS variables 활성화
- Gradients 등 CSS properties 네이티브 지원 (spec compliant)
- 더 적은 hooks/imports, web zero overhead, backwards compatible
마무리
- React, Expo Router, EAS, CSS 지원으로 bleeding edge 앱 개발 가능
- React Native CSS package로 즉시 테스트 가능
The React Router take on RSC
Kent C. Dodds (Software Engineer Educator)
💡 소플의 한 줄 요약
아주 쉽게 React Router에 RSC를 적용하는 방법
🔗 영상 링크
인트로 및 간단한 React Router 앱 데모
- React Router 앱을 통해 영화 컬렉션 관리 데모 시연
- 영화 트레일러 시청, 좋아요 표시 기능 포함
- Lord of the Rings를 좋아요로 표시하는 예시
Vite 설정과 RSC 활성화 (🔗 관련 문서)
- Vite config에서 React Router framework mode 사용
- RSC를 위한 Vite plugin(
@vitejs/plugin-rsc
) 추가로 Server Components 지원
- 기존 앱에 점진적으로 RSC 도입 가능
<Scripts />
element 제거로 warning 해결
점진적 RSC 도입 방법
- Heavy component server 이동:
loader
export를 Server Component로 변환
- 기존 Client Component를 server로 옮겨 성능 최적화
- 전체 route를 Server Component로 변환:
default export
→ named ServerComponent
로 변경, async
함수로 데이터 로딩
loader
완전 제거 및 props
불필요
Nested Routes와 Team별 독립적 적용
- Parent route가 Server Component여도 child route는 Client Component로 유지 가능
- 깊이 있는 nesting 지원 (Server → Client → Server...)
- 팀별 독립적 RSC 적용 가능, shell 팀과 page 팀 간 의존성 최소화
Server Actions 활용
- 기존
action
제거하고 일반 form
+ setIsFavorite
server function 사용
"use server"
지시어를 사용해서 client에서 server function 호출
- Full-stack component pattern 불필요, form component 재사용성 향상
Client Component 전환 시 주의점
- Server Component에서
useState()
등 client hook 사용 시 "use client"
지시어 필수
- 필요한 부분만
"use client"
적용 후 client-only 컴포넌트로 분리
RedwoodSDK: Web Standards Meet Full-Stack React
Peter Pistorius (Co-creator @ RedwoodSDK)
Aurora Scharff (Web developer and consultant @ Crayon Consulting)
💡 소플의 한 줄 요약
Redwood SDK의 탄생 배경과 주요 특징 소개
🔗 영상 링크
Redwood SDK 탄생 배경
- 약 1년 전, GitHub 창립자 Tom Preston-Werner로부터 RedwoodJS 관리 책임 요청을 받았으나 처음 거절
- 밤새 고민 끝에 세상에 내놓고 싶은 framework 개발 결정
- 이 framework를 Redwood SDK라 명명
Redwood SDK 주요 특징
기반 기술
- Vite plugin으로 SSR, React Server Components, server functions, real-time features 지원
- Vite, TypeScript, React, web standards 기반
- 특별한 syntax나 compiler magic 없음
Routing
- 모든 route는 단순 function
- Request 받아 response 또는 page 반환
- Web standards 기반 (네이티브 Web API)
- Response stream, protocol upgrade, dev tools debugging 가능
- R2 storage로 파일 직접 stream
Request Flow
- Interrupters: Route 도달 전 request 가로채기, auth 확인, redirect, response 중단
- Middleware: Route 실행 전후 logic 실행, headers inject, context 설정, edge stream
Document Control
- Total Control 제공 (wrapper나 black box 없음)
- Wire 전송 내용 선택, client-side React on/off, preload tags, inline styles 가능
React Server Components
- Server-first 접근
- Component server에서 실행 → HTML browser로 직접 stream
- 상호작용 필요시
"use client"
로 client component 표시
Cloudflare 최적화
- Adapter 없이 Cloudflare Workers용 특별 구축
- Local 실행 = Production 실행
- Development에서 Miniflare로 Cloudflare Workers 에뮬레이션
Demo 주요 내용
기본 구조
worker.tsx
파일이 Cloudflare Worker entry point
- Route function으로 response objects 또는 JSX 반환
- Middleware로 common headers 설정, Durable Objects로 user session 관리
- App context: Server-side 정보 공유용 mutable object
Server Components
- 기본적으로 Server Components
- Suspense로 streaming 및 fallback UI 지원
- Cloudflare D1 database에서 데이터 fetch 후 JSX render
- Web standard forms 사용
- No JS document에서도 Server Component로 동작
- Interrupters로 route 보호 (authenticated 체크, login redirect)
Client-side Interactivity
"use client"
로 client component 활성화
useActionState()
, server functions 호출
- Client-side navigation으로 View Transitions 지원
- 내부 link 가로채서 URL push, RSC payload fetch, client hydration
Advanced React Features
use()
, async producer, useOptimistic()
, actions 활용
- To-do items에 View Transitions 적용
- Optimistic updates와 server sync
Real-time Features
- Durable Objects로 theme/reactions 관리
- WebSockets 연결로 bidirectional communication
- Real-time client init으로 fetch-based에서 stream-based RSC payload로 전환
- Pathname 기반 client 간 RSC payload 공유
Deployment
pnpm release
로 one-command deploy
- Cloudflare에 website upload, database/assets 생성
결론
- Web standards 기반 request/response
- Complete document control
- Cloudflare Durable Objects, database 활용
- Server components streaming
- No JS SSR → Hydration → View transitions → Real-time까지 동일 앱에서 구현
- React, TypeScript, Cloudflare를 응집력 있게 결합한 web standards 기반 framework
TanStack Start
Tanner Linsley (Owner @ TanStack)
Jack Herrington (Blue Collar Coder)
💡 소플의 한 줄 요약
TanStack Start로 Full-stack React 앱을 쉽게 구축하는 방법
🔗 영상 링크
서론 및 메시지
- 발표자는 아이들에게 멋지다는 걸 증명해야 하며, React Conf 무대에 서서 겸허함을 느낌
- TanStack 팀은 TanStack Start가 Full-stack React 앱 구축의 최선의 방법이라고 믿음
- Start는 TypeScript로 작성된 것이 아닌 진정 type-safe하며, type inference가 핵심
- 코드가 적고 기본적으로 안전하며, 별다른 노력 없이도 실수를 방지할 수 있음
TanStack Start의 주요 특징
- Client-first 접근:
- 전통 SPA 아키텍처에 가까움
- React 개발자들이 익숙한 speed, simplicity, libraries, patterns 유지
- 필요 시 server-side capabilities 추가 가능, TanStack Router 덕분
- TanStack Router는 type safety와 DX가 우수하며 full-stack 앱에 업그레이드
- Start는 Router의 강점을 상속받아 SPA 경험 위에 full-stack 솔루션 제공
데모 시연
- 간단한 라우팅: 파일 기반 라우트 생성 (e.g.,
hello.tsx
), 자동 인식
- SSR 토글: SSR이 기본,
ssr: false
로 SPA 전환
- Data Loading: Loader 추가로 strongly typed 데이터 사용
- Links와 Params: TypeScript로 routes와 params 자동 완성 및 체크
- Server Functions: Method 선택, input validation, middleware (e.g., logging) 쉽게 추가, currying 지원
- API Routes: 파일 라우트에 server handler로
GET
/POST
등 처리
Create Start App
- CLI로 앱 생성:
npm create @tanstack/start@latest
- toolchain, hosting (Nitro 지원), add-ons (Neon, Prisma 등) 선택
- UI 기반 빌드: 브라우저 프리뷰, ORPC/tRPC/Table/Store 등 라이브러리 통합
- Sponsors/Partners (Prisma, Neon, Convex)로 DB, auth 등 모든 것 지원
결론
- 또 다른 프레임워크 필요성에 대한 의문 인정
- React 생태계의 안정성(stable)·개방성(open)·독립성(independent) 강조
- 5년 동안 커뮤니티 주도 개발로 TanStack Start와 Router 구축
- 여러분들이 가장 좋아하는 프레임워크가 되길 원함, 시도와 피드백 요청
What's The Framework of the React Future?
Jack Herrington (Blue Collar Coder)
Tanner Linsley (Owner @ TanStack)
Devon Govett (Software Architect @ Adobe)
Kent C. Dodds (Software Engineer Educator)
Michał Pierzchała (Principal Engineer @ Callstack)
Peter Pistorius (Co-creator @ RedwoodSDK)
Evan Bacon (Software Engineer @ Expo)
Josh Story (Engineer @ Vercel)
💡 소플의 한 줄 요약
각 리액트 프레임워크 대표 주자들의 한 판 토론
🔗 영상 링크
Michał Pierzchała (Principal Engineer @ Callstack)
- Rock 프레임워크 소개
- React Native 프레임워크
- 두 가지 핵심 목표:
- 구형 React Native CLI 앱을 최신 도구로 마이그레이션 (로컬/원격 캐싱 활용)
- Rock Brownfield 기능으로 기존 네이티브 iOS/Android 앱에 React Native 통합 지원
- AI 도구와 LLM 활용
- 인간에게 쉬운 작업(composition, co-location)은 LLM에게도 쉬움
- Helpers/라이브러리로 에뮬레이터 호출 간소화 → 토큰 절약
- 경력별 도구: 주니어(콘솔 로그) → 시니어(Chrome DevTools, React DevTools 연결)
- 핵심: 개발자 편의성 우선 = LLM 효율성 ↑
- 로컬 LLM
- 현재 4K처럼 초기 단계, 2~3년 후 큰 진전 예상
- 장점:
- Apple/Google 제공 모델에 국한되지 않음
- ExecuTorch로 원하는 모델 실행
- 자원 공유로 메모리 관리 간편
- 미래:
- 강력 디바이스에서 수백만 하이퍼-퍼스널 UI 생성
- 서버 → 로컬 전환
- 도전: UI 버전 테스트 어려움
Josh Story (Engineer @ Vercel)
- Next.js 프레임워크 철학
- 최고의 사용자 경험을 쉽게 구축할 수 있도록 하는 것이 목표
- 2022년부터 App Router 개발 (React Server Components 구현)
- 향후 2주 내 컨퍼런스에서 Partial Pre-rendering 등 새로운 기능 발표 예정
- 스트리밍과 AI
- 과거에는 불가능했던 스트리밍 SSR이 이제 필수 기능
- LLM 토큰 스트리밍을 20분간 지속하는 앱들이 가능해짐
- MCP (Model Context Protocol)
- 개발자 경험 개선을 위해 MCP 탐색 중
- 코드 마이그레이션, 디버깅, 프레임워크 상태 이해를 위한 인터페이스 개발
Kent C. Dodds (Software Engineer Educator)
- Remix 프레임워크 특징
- React 자체가 미래의 프레임워크
- 모든 React 프레임워크들이 수렴하고 있음
- Shopify의 강력한 투자 지원
- Ryan Florence와 Michael Jackson의 10년간 사용자 케어 입증
- RSC (React Server Components)
- React 프레임워크라면 필수 요소
- 생태계의 큰 부분을 지원하지 않으면 일부만 지원하는 것
- AI와 에이전트
- 코로케이션(co-location)이 AI에 중요 (예: Tailwind)
- 에이전트 간 통신: "내 사람이 당신 사람에게 연락할 것" 모델
- 은행과 같은 조직이 자체 에이전트를 만들고 MCP 서버로 노출
- 온디바이스 LLM이 미래
- React에 원하는 것
- API 변경 없이 내부 개선하는 방식 선호
- 시그널(Signals)에 대한 관심 표명
Peter Pistorius (Co-creator @ RedwoodSDK)
- Redwood 프레임워크 특징
- "이미 사용하고 있다" - TypeScript, React 사용자라면 Redwood 사용 중
- 학습할 것이 없음 - 이미 알고 있는 기술
- 경량, 조합 가능, 서버 우선
- 마법 없음, 타입 생성 없음
- 이해 가능하고 추적 가능한 코드
Evan Bacon (Software Engineer @ Expo)
- Expo 프레임워크 비전
- 유니버설 React 프레임워크
- 모바일 폼팩터의 최적화와 웹의 배포 이점 결합
- 햅틱, 제스처 등 네이티브 기능 + 웹의 파일 기반 라우팅, 서버 액션, API 라우트
- 웹과 네이티브 수렴
- Activity API 같은 웹의 사려 깊은 API가 모든 곳에서 작동
- iOS의 Liquid Glass, HDR 전환 같은 네이티브 기능도 발전
- 서로 중간에서 만나는 방향
- AI 도구로서의 Expo
- Mistral 앱이 Expo 앱
- 상위 10개 개발 도구 중 4개가 Expo 도구
- "기계를 만드는 기계"가 되는 것이 목표
- 스트리밍 프리미티브가 모든 것에 내장
- MCP 지원
- Expo Go에 MCP 통합 탐색 중 (프로토타이핑 브라우저)
- 컨텍스트 윈도우 관리가 중요
Tanner Linsley (Owner @ TanStack)
- 외부 스토어 문제
- React가 더 많은 상태를 소유하려 함
useExternalStore()
같은 기능 필요
- 트랜지션, 서스펜스 등 기능을 활용하면서도 데이터 소유권 유지 필요
- 세밀한 성능 제어
- React Compiler는 훌륭하지만 명시적 API도 필요
- Deep context selector API 원함
- 세밀한 렌더링 지원과 풀 트랜지션 지원 사이의 균형 필요
- 프레임워크 수렴
- 모든 프레임워크가 수렴하는 것은 React의 좋은 징조
- 궁극적으로 메타 프레임워크가 필요 없어지는 것이 목표
- React Foundation이 이러한 방향성 유지에 도움이 될 것
Devon Govett (Software Architect @ Adobe)
- Parcel 번들러 관점
- 기존 클라이언트 앱에 서버 컴포넌트 추가하기 쉬움
- SSR 없이 서버 컴포넌트 임베드 가능
- React Router의 번들러 교체 가능 기능 지원
- 서버 컴포넌트 라이브러리
- npm에 서버 컴포넌트 라이브러리가 더 많이 나올 것 기대
- 인증, 폼 검증 등의 컴포넌트화
- 프레임워크에 구애받지 않는 사용 가능
Async React (continued)
Ricky Hanlon (React Team @ Meta)
💡 소플의 한 줄 요약
지난 10년 동안 Async를 향해 달려온 Ricky의 열정
🔗 영상 링크
⚠️ Day 1에 시간 부족으로 하지 못한 데모 시연 진행
데모 앱 소개
- React 16 기반의 synchronous TODO 앱
useEffect()
로 데이터 fetching
- 네트워크 지연 시 janky한 경험 발생 (체크 후 refetching으로 항목 팝인)
- 탭 전환 시 문제 (In Progress/Complete 탭에서 데이터 불일치)
문제점
- 화면에 결과를 commit한 후 fetching → 데이터 충돌 가능성
- 클라이언트 캐시/스토어로는 근본 해결 어려움
- 서버 refetch 필요하지만 조정(coordinate) 부족
해결 방법: Transitions 적용
startTransition()
으로 pending state 관리
complete
로직을 transition 내부로 이동
- 그러나
useEffect()
기반 구조적 문제로 여전히 janky
Suspense로 전환
useEffect()
→ Suspense 대체
- Promise 캐싱 및
revalidate()
함수 업데이트
- Suspense fallback으로 로딩 상태 제공
- View Transition API로 애니메이션 추가
탭 전환 개선
- 탭 변경 시
startTransition()
적용
useOptimistic()
으로 즉각적인 탭 상태 업데이트
- Optimistic tab과 pending state로 사용자 피드백 개선
- Glimmer effect로 로딩 상태 표시
검색 기능 개선
- 검색 시
startTransition()
적용
- Optimistic search value로 타이핑 지연 해결
- Suspense boundary로 로딩 상태 관리
미래 비전: 라이브러리 계층화
- 데이터 fetching 라이브러리: Suspense 기본 지원, pre-loading
- Router: Transitions 기본 사용, background rendering
- 디자인 컴포넌트:
action
props, optimistic updates 내장
action
Props 패턴 (React 19)
- 콜백이 자동으로
startTransition()
내 실행
- Mutation, navigation 등 async 작업 지원
- 버튼 컴포넌트가 로딩 상태 자동 처리
- 수동
useOptimistic()
, startTransition()
불필요
Async React 핵심
- Transitions: Async 기능 조정, 부드러운 로딩 시퀀스
useOptimistic()
: 지역적 즉각적 피드백
<Suspense />
: 로딩 상태 제공
<ViewTransition />
: 최종 결과 애니메이션
필요 사항
- async design: Action props, Optimistic updates, 로딩 상태를 위한 새로운 디자인 패턴
- async router: Transitions, routes를 위한 Activity, Transition Types
- async data: Suspending, Prefetching, refetching 패턴
- 커뮤니티 협력으로 패턴 이해 및 롤아웃 지원
- Router, 데이터 라이브러리, 디자인 컴포넌트 표준화
- 교육자와 협력하여 앱 구축 방법 교육
결론
- 단순하고 선언적 코드로 복잡한 async 처리 자동화
- 네트워크 속도에 관계없이 최적화된 UX
- 인간과 AI 모두에게 친화적인 아키텍처
- "두 걸음 앞으로" 비전 실현
이번 컨퍼런스의 마지막 발표를 마치면서, Ricky는 지난 10년간의 여정을 회상하며 살짝 눈시울을 붉혔습니다.
Ricky의 마지막 멘트를 매거진 말미에 담아봅니다.
Ricky
마지막으로, 저는 수년 동안 이 모든 기능에 힘써주신 모든 분들께 감사하다고 말하고 싶습니다.
특히 Seb에게 감사하다고 말하고 싶습니다.
Seb, 당신은 10년 전에 우리를 이 여정에 올려놓았고, 항상 쉽지는 않았습니다.
지저분했지만, 당신은 우리 모두에게 영감을 주었고, 당신이 해온 모든 것에 감사드립니다.
둘째 날은 대부분 React Native와 관련된 발표들로 구성되었습니다.
개인적으로 오래 전부터 모바일 앱을 개발할 때 React Native를 사용하고 있는데,
그동안의 React Native의 발전 과정을 돌아보니 감회가 새롭네요.
주변에 React Native를 사용하는 개발자분이 있다면 이 글을 공유해주시면 도움이 될 것 같습니다ㅎㅎ
그럼 저는 다음에 또 유익한 글로 찾아뵙겠습니다!
지금까지 소플이었습니다. 감사합니다 😀