안녕하세요, 소플입니다.
이미 유튜브로 라이브 스트리밍을 보신 분들도 계시겠지만, 지난 주에 2025년 리액트 컨퍼런스가 있었습니다.
이틀에 걸쳐서 진행된 이번 행사에서는 React와 React Native에 대한 다양한 주제들로 굉장히 풍성했는데요,
이번 매거진에서는 먼저 React Conf 2025의 첫째 날에 발표된 내용들을 한 번 요약해서 살펴보도록 하겠습니다 😀
목차
React Keynote
Seth Webster (Head of React @ Meta)
Joe Savona (React Team @ Meta)
Mofei Zhang (React Team @ Meta)
Lauren Tan (React Team @ Meta)
Jack Pope (React Team @ Meta)
💡 소플의 한 줄 요약
리액트 팀 멤버들이 직접 전해주는 최신 리액트 뉴스!
🔗 영상 링크
Joe Savona
React 19 업데이트 및 커뮤니티 소식
- React 19 Release Candidate (RC) 피드백 반영:
- 커뮤니티 피드백을 통해 컴포넌트 일시 중단 시 형제 컴포넌트를 처리하는 방식을 개선
sibling pre-warming
기능 추가
- 이를 통해 사용자 경험(UX)과 데이터 로딩 성능을 동시에 향상
- React 문서 업데이트:
- 사용자 피드백을 반영하여 프레임워크 없이 처음부터 리액트 앱을 만드는 방법에 대한 새로운 가이드 페이지 추가
- React 19.1 출시:
- 개발 환경에서 오류의 원인을 더 정확히 추적할 수 있는 Owner Stacks 기능 지원
- 커뮤니티 성과:
- NPM에서 리액트 누적 다운로드 60억 회 돌파
- Expo, Next.js 등 생태계 전반에서 서버 컴포넌트가 주류로 자리 잡음
- React와 AI:
- 리액트의 선언적이고 조합 가능한 접근 방식이 대규모 언어 모델(LLM) 및 AI 에이전트 개발에도 유용함이 입증됨
Mofei Zhang
React 19.2의 새로운 기능
<Activity />
- UI와 내부 상태를 숨기거나 복원할 수 있는 기능
- 숨겨진 컴포넌트의 업데이트 우선순위를 낮춰, 보이는 UI의 반응성을 극대화
useEffectEvent()
- 개발자가 이펙트(effect)를 더 세밀하게 제어할 수 있는 고급 훅(hook)
- 부분 사전 렌더링 (Partial Pre-rendering):
- 앱의 정적인 부분을 미리 렌더링하여 CDN에서 제공하고, 동적 콘텐츠는 나중에 채우는 서버 기능
- 이를 통해 초기 로딩 속도를 크게 개선
- 성능 트랙 (Performance Tracks):
- 크롬 개발자 도구의 성능 패널에서 리액트 작업의 타임라인을 시각적으로 분석할 수 있는 새로운 프로파일링 도구
Jack Pope
향후 기능 미리보기 (Canary)
- View Transitions (
<ViewTransition />
):
- UI 변화를 부드럽게 연결하는 애니메이션을 선언적으로 구현할 수 있는 리액트 최초의 내장 애니메이션 API
- 리액트의 동시성 렌더링 모델과 완벽하게 통합되어 비동기 작업 중에도 부드러운 전환 효과를 제공
- Fragment Refs 및 새로운 구성 모델:
- 플랫폼 API(이벤트 리스너, 포커스 관리 등)를 더 쉽고 선언적으로 구성할 수 있는 새로운 방식
- 제품 코드의 복잡성을 크게 낮추고 서버 컴포넌트와의 호환성을 높임
Lauren Tan
React Compiler 1.0
- 가용성: React Compiler 사용 가능. (NPM 설치는 기조연설 당일 늦게 릴리스 예정)
- 설치 및 도입:
babel-plugin-react-compiler
, 새로운 ESLint 플러그인 설치로 사용 시작
- 새로운 ESLint 플러그인, 컴파일러 기반 규칙 포함. 컴파일러 독립 적용 가능, 'Rule of React' 위반 탐지 지원
- 기존 ESLint 설정 사용자(
exhaustive-deps
, rules-of-hooks
)는 권장 규칙 프리셋을 참조하도록 업데이트해야 새로운 규칙을 모두 적용받을 수 있음
- 주요 기능 및 이점:
- 웹, 모바일, TV, 터미널 등 모든 플랫폼에서 작동하는 빌드 도구
- 컴포넌트, 훅 자동 최적화
- 코드 재작성 없이 바로 사용 가능
- 리액트 19뿐만 아니라 17과 18에서도 작동
- 단순한 메모이제이션 대체를 넘어 코드를 깊이 이해하고 더 나은 리액트 코드 작성을 도와줌
- 자동 메모이제이션:
useMemo()
, useCallback()
, React.memo()
를 수동으로 사용해야 하는 번거로움 제거
- 선언적인 코드 작성에만 집중할 수 있게함
- 컴파일러가 arrow function 등 놓치기 쉬운 메모이제이션 버그까지 처리하여 성능 개선
- 코드 분석 및 진단:
- 코드에 대한 깊은 이해를 바탕으로 상세한 진단 정보를 제공하고 리액트 규칙 위반을 감지
- 감지 사례:
- 이펙트 내
setState
호출
- 렌더링 중
ref
접근
- 렌더링 중
setState
호출(무한 루프 유발)
- 함수로 감싸 숨긴 렌더링 중
setState
호출
- 성능 결과 (메타 퀘스트 스토어):
- 초기 로딩, 페이지 간 이동 최대 12% 향상
- 일부 상호작용 2배 이상 빨라짐
- 메모리 사용량 중립 유지
- 권장 사항:
- 모든 신규 애플리케이션은 첫날부터 컴파일러를 사용해야 함
- 기존 애플리케이션도 컴파일러 도입을 권장하며, 점진적 도입 가이드가 제공됨
- 모든 앱은 린터(ESLint 플러그인)를 사용해야 함 (컴파일러와 독립적)
- 생태계 지원: Expo, Vite, Next.js 팀과의 협력을 통해 신규 앱에 컴파일러를 기본 활성화하거나 활성화된 템플릿을 선택할 수 있는 옵션을 제공
Seth Webster
React Foundation (리액트 재단) 설립
- 배경: 리액트의 미래를 위해 어떤 한 회사, 사람, 또는 팀보다 더 오래 지속될 수 있는 구조가 필요했음
- 설립 목적: 리액트가 독립적이고, 커뮤니티 중심적이며, 모두를 위해 만들어지도록 보장하는 구조를 제공
- 의미: 리액트의 미래가 더 이상 메타의 것이 아닌 커뮤니티의 것임을 선언
- 파트너십: Meta, Amazon, Expo, Callstack, Microsoft, Software Mansion, 그리고 Vercel의 지원과 함께 비전과 미래를 만들어갈 것을 제안
- 커뮤니티의 역할 강조:
- 리액트는 커뮤니티의 힘으로 오늘날과 같은 가장 인기 있는 선언적 UI 프레임워크가 되었음
- 재단 설립을 통해 이러한 정신을 지속시키고 리액트의 밝고 진보적인 미래를 보장하고자 함
View Transitions and Activity
Chance Strickland (Software Engineer @ WorkOS)
💡 소플의 한 줄 요약
Activity와 View Transitions를 활용하여 사용자 경험 향상시키기
🔗 영상 링크
Activity API를 활용한 상태 관리 개선
- 사이드바 검색 기능에서 사용자가 입력한 검색어가 사이드바를 닫았다 열어도 유지되지 않는 문제 해결
- 전통적인 state lift-up 방식 대신
<Activity />
component 사용
mode
prop을 통해 컴포넌트를 조건부 렌더링이 아닌 visible
/hidden
상태로 전환
- React state뿐만 아니라 DOM state(uncontrolled input, 스크롤 위치 등)도 자동으로 보존
- 컴포넌트 간 coupling 없이 깔끔하게 상태 관리 가능
Activity의 추가 활용 사례
- 비디오 썸네일 클릭 시 비디오 로딩을 백그라운드에서 미리 시작(pre-loading)
hidden
상태에서도 렌더링되므로 video element의 preload
prop 활용 가능
- 사용자가 클릭했을 때 즉각적인 응답 제공 및 로딩 화면 제거
View Transitions API 통합
- Theater mode 전환 시 부드러운 애니메이션 구현
- 기존 방식의 문제점:
- Server Components에서 hooks 사용 불가
- ref forwarding의 복잡성
flush sync
같은 비동기 처리의 어려움
- 새로운 방식: React의
startTransition
내에서 자동으로 View Transition 트리거
<ViewTransition />
component를 사용하여 선언적으로 애니메이션 정의
- React가 자동으로 asset 로딩 대기 및 깜빡임 방지 처리
enter
/exit
props를 통한 CSS class name 제어로 커스텀 애니메이션 가능
name
prop을 공유하여 서로 다른 React tree 간의 seamless transition 구현
결론
- Activity와 View Transitions는 복잡한 UI 상태 관리와 애니메이션을 composable하고 declarative하게 만드는 React의 새로운 접근 방식
- 개발자가 복잡한 DOM 조작이나 ref 관리 없이 선언적 코드만으로 우수한 사용자 경험 제공 가능
가용성
- Activity: React 19.2 stable release에서 사용 가능
- View Transitions: Canary 버전에서 사용 가능
Ruslan Lesiutin (React Team @ Meta)
💡 소플의 한 줄 요약
리액트 팀 엔지니어가 직접 알려주는 성능 측정 도구 사용 방법
🔗 영상 링크
데모 앱 설명
- 기능:
- 상품을 장바구니에 추가
- 장바구니 버튼 클릭 시 checkout form 표시
- Code Execution Panel:
- 실시간으로 React/JS 이벤트 및 state 업데이트 표시
- 예: Hover 시 state 업데이트, 클릭 시 loading state, 비동기 요청, Suspense boundary 렌더링
- 주요 동작:
- Hover: State 업데이트
- 클릭: Loading state, 비동기 요청, cart 컴포넌트 표시, fallback UI, Activity API로 checkout form pre-rendering
- Performance Tracks 활용:
- Chrome DevTools에서 React 실행 흐름 시각화
Scheduler Track
- 설명: Concurrent Rendering의 작업 오케스트레이터, 우선순위별 작업 조율
- Subtrack:
- Blocking: 동기 작업 (예: 버튼 클릭 UI 업데이트)
- Cascading Update (빨간색): 성능 병목/불필요한 re-render 표시
- Transition: 비동기 백그라운드 작업 (예: Cart visibility 업데이트)
- Suspense: Suspense boundary 렌더링
- 컴포넌트 mount/reconnect, pre-rendering (Activity API)
- Idle: 가장 낮은 우선순위 작업
- 특징: 상위 우선순위 작업 먼저 실행, Activity API와 연동
Components Track
- 설명: 컴포넌트 render/effect 시각화, flame graph로 렌더링 시간 표시
- 기능:
- Hover 이벤트: Blocking 우선순위로 state 업데이트
- 클릭 이벤트: Blocking (loading state) + Transition (비동기 요청)
- Props 변경 및 re-render 원인 확인
- 노란색 entry: 새로 mount된 컴포넌트
Server Components Track
- Server Component 및 요청 추적
- 자세한 내용은 react.dev 문서 참조
- 지원 버전: React 19.2부터 기본 포함
- 활성화:
- 개발 빌드: 자동 활성화
- 프로파일링 빌드:
<Profiler>
컴포넌트 또는 React DevTools 확장 필요
- 기존 React Devtools의 Profiler Panel이 사라지는가?
- 기존 정보는 유지되며, Timeline 기능은 Performance Tracks로 대체
- 설명: Suspense boundary 상태 시각화, 원인 분석 (
Promise
, network, React.lazy
등)
- Suspense Reveal Timeline: 앱 상태 재생, Suspense 해제 순서 확인
- 출시:
- 일부 기능: React DevTools 7에 포함
- Suspense Panel: 2025년 말 출시 예정
🔗 React Performance Tracks 공식문서
In case you missed the memo
Cody Olsen (Staff Engineer @ Sanity Studio team)
💡 소플의 한 줄 요약
망설이지 말고 React Compiler를 즉시 도입하라는 피카츄의 외침
🔗 영상 링크
Sanity Studio 개요
- Sanity: 콘텐츠 운영 시스템(Content Operating System)
- Riot Games(게임 lore), AT&T(신규 폰), RBI(버거) 등의 콘텐츠 배포에 활용
- 다양한 React 앱을 통해 콘텐츠 운영 지원
- Sanity Studio:
- 초기: CMS로 시작
- 현재: Vite 기반 React 프레임워크로 발전
- 철학: 비즈니스에 맞춘 콘텐츠 생성, "저장 버튼" 제거
- 오래된 코드베이스(brownfield), React 15 및 Flowtype 사용 경험
- 2024년: 성능 한계 도달, 작은 re-render로 인한 성능 저하
React Compiler 도입 배경
- 문제점:
- 대규모 스튜디오 성능 분석 시 과도한 데이터로 인해 문제 파악 어려움
- 작은 re-render로 인한 성능 저하("death through a thousand cuts")
- React Compiler:
- 2024년 발표, 성능 문제 해결 가능성
- 요구사항: 코드가 React 규칙 준수, pure해야 함
- 실험적 단계에서 linter를 통해 정적 분석으로 버그 탐지
도입 과정 및 결과
- 초기 시험:
- 1,000개 이상 컴포넌트 memoized, 일부는 linter로 문제 확인
- 예: rich text editor에서 ESLint 주석 문제 발견
- 해결책:
- 조건부 실행 및 render 중 처리로 성능 개선
- pre-compiled 코드 배포로 고객에게 즉각적인 성능 향상 제공
- 도전 과제:
- 다양한 프레임워크와 플랫폼에서 React Compiler 코드 배포
- 서버 컴포넌트: state/re-render 없으므로 별도 export 필요
- 성과:
- npm 라이브러리에서 1년간 사용, 소비자 측 변경 없이 성능 향상
- 고객의 커스텀 React 컴포넌트와 훅에서도 컴파일러 활용
- Next.js 애플리케이션 및 experimental React 기반 신제품 성공
주요 교훈
- Auto-memoization의 힘:
- 수동 memoization 불가능한 최적화 수행
- 세밀한 memoization(예: theme provider, context)으로 성능 향상
- context 조건부 구독 및 브랜치 memoization 가능
- React에 대한 새로운 학습:
- 문제 원인 재발견:
styled-components
관련 성능 병목 발견
useInsertionEffect()
미사용으로 인한 jank 문제
- 컴파일러로 디버깅 시간 단축, 더 중요한 문제 해결 가능
React Compiler 채택 방법
- 적용 대상 선정:
- 초기 렌더링이 아닌 re-render 최적화에 초점
- 데이터 테이블, 차트 등 re-render 빈번한 영역 타겟
- Chrome FPS meter 및 React DevTools로 re-render 시각화
- Linter 활성화:
- 사전 점검으로 문제 탐지, 문제 없으면 최적화 성공 가능성 높음
- 컴파일러 설정:
- 프레임워크별 설정 후 재측정
- FPS 개선 및 memoized 컴포넌트 확인
- 성과 측정:
- eFPS Suite로 편집 성능 측정
- 평균 20~30% 성능 향상, 디자인 시스템 100% 컴파일 시 추가 20~30% 향상
새로운 코드 작성 흐름
- 과거:
- Make it work → Make it right (Sentry,
console.log
) → Make it fast (수동 memoization)
- 느리고 비효율적
- 현재:
- Make it work에 집중, linter로 Make it right 통합
- React 기본 원칙 학습으로 문제 해결 효율성 증가
핵심 이점
- 숨겨진 버그 탐지
- React 기본 원칙 학습
- 의존성 병목(예:
styled-components
) 발견
- 코드 품질 향상, 외부 도구 의존성 감소
결론
- React Compiler: 필수 도구, 즉시 도입 권장
- 성능 최적화 및 코드 품질 개선에 큰 기여
Async React
Ricky Hanlon (React Team @ Meta)
💡 소플의 한 줄 요약
리액트에 찾아온 Async by default 시대
🔗 영상 링크
들어가며
React의 역사와 프로젝트 시작
- 2015~2016년 회의록을 통해 React의 incremental rendering 지원을 위해 전체 architecture 재작성 시작
- 새로운 APIs와 model 도입, 이해 어려움과 혁신의 위험성 인지
2017년 Sebastien의 비전
- React의 혁신 방향 제시, innovation window 개념 도입
- 혁신은 선형적이지 않고 지저분하며, 명확한 목표 없이 진행됨
- Innovation Window
- 혁신은 기존 아이디어가 local maximum에 도달 후 새로운 아이디어로 대체
- 성공 사례(카세트→CD)와 실패 사례(Betamax, MiniDisc) 언급
개발 과정의 도전
- 2017년 이후 지저분한 개발 과정, 팀과 사용자 모두 완전한 이해 부족
- Hooks 도입:
- async components 쉽게 작성 가능
useMemo()
, useCallback()
의 복잡한 rules 문제
- Concurrent rendering을 위한
startTransition()
, useDeferredValue()
출시
- suspense-enabled data fetching library 없이는 사용 어려움.
최근 발전
use()
, useOptimistic()
, <Activity />
, <ViewTransitions />
, scheduling features와 통합된 animations 출시
- 2017년 약속한 기능 완성, React의 다음 evolution이 명확해짐
- 사용자들은 여전히 Transitions, Suspense, Server Components를 이해하는데 어려움을 겪음
Async React
Async React 소개
- Transitions는 단순 performance issue 해결이 아닌, asynchronous apps를 위한 새로운 구조
- Async React는 반응성 있는 asynchronous apps 구축에 초점
UI와 State
- UI를 state의 function으로 봄, synchronous updates에 적합
- Async 도입 시 network time으로 인해 복잡한 중간 state 발생
HTML과 JavaScript의 한계
- 순수 HTML: 버튼 클릭 시 반응 없음, top-down 콘텐츠 로드
- JavaScript: spinner로 busy indication 개선, 하지만 페이지 로드 시 여전히 번쩍임
- Client-side libraries: 과도한 loading states로 사용자 피로 유발
Async React의 솔루션
- Async 중심 앱 구조로 빠른/느린 network 모두 대응
- 이상적인 loading sequence
- 즉각적 busy indicator
- loading indicator
- animated done state
- Suspense, router, caching으로 중간 loading states 제거
데모 시연
- Login page에서 pending state 제거
startTransition
으로 깜빡임 개선
- Suspense boundary, animations 추가로 부드러운 cross-fade animation 구현
- Data fetching과 UI updating의 coordination problem 해결
마치며
- Router, data fetching, design components에 async 통합으로 사용성 개선
- 복잡한 APIs와 features를 단순화해 사용자 경험 향상 목표
⚠️ 시간 부족으로 데모 시연은 Day 2 마지막 세션에 이어서 진행함
React and AI
Christopher Chedeau (Software Engineer @ Meta)
Kent C. Dodds (Software Engineer Educator)
Shawn (swyx) Wang (Cognition)
Lee Robinson (VP of DX @ Cursor)
Theo Browne (Youtuber?)
💡 소플의 한 줄 요약
AI 시대에 적응하기 위한 리액트 개발자들의 전략
🔗 영상 링크
Lee Robinson
- 패널 소개: Chris, Kent, Swyx, Theo와 함께 React와 AI 코딩의 교차점 논의
- 주요 질문:
- Meta 내부 AI 활용 방식 (Chris)
- 개발자들의 AI 사용 실수 및 학습 포인트 (Kent)
- Library/Framework 빌더들의 AI 기회
- Frontier models의 React 코드 품질 제약 요인 (Swyx)
- React 코드 생성 시 필요한 rules/context의 공통점
- React 코드 생성의 한계와 미래
- Pro-tip: Knip 같은 특정 툴로 에이전트 방향 효과적 설정
Christopher Chedeau
- Meta의 AI 활용:
- 버그 수정/앱 변경 시 component 코드 위치 탐색에 주로 활용
- Chrome extension 구현: React component stack으로 요소의 컴포넌트 이름 파악
- 코드베이스에서 파일 탐색 후 LLM에 prompt 전달
- Non-engineers(PM, designers, managers)도 코딩 시작 가능
- LLM rules: 대규모 코드베이스의 특정 영역 특이사항을 markdown file로 context 주입
- Code mode: js CodeShift의 AST transform에서 Markdown 기반 예시로 LLM이 코드 변환, code migration에 유용
- Pro-tip: React compiler linters 사용 권장
- React Conf 창립:
- 2015년 Jordan Walke에게 React 학습 후 컨퍼런스 조직
- 티켓 판매 사이트 다운될 정도로 폭발적 반응
- 10년 후 ChatGPT 등 gen AI tool들이 React로 작성됨
Kent C. Dodds
- AI 사용 실수:
- 모두가 현재 실수 중, 1년 후 돌아보면 잘못됨
- "더 많은 context일수록 좋다"는 오해
- 올바른 context 식별이 가장 중요
- 개발자 문제점: ChatGPT에 질문 그대로 입력, 스스로 질문하지 않음
- Context 확보: Sentry 에러 메시지, Cursor 브라우저 기능, Playwright MCP server 등 활용
- 개인 선호: Cursor Tap Complete로 작성 코드로 모델 direct/prompt
Shawn Wang
- 코드 품질:
- 대부분 모델이 React 잘 다룸, 문제는 quality 정의
- 좋은 React 코드 기준이 사람마다 달라 reward policy 정의 어려움
- 모델은 대규모 코드베이스 학습 시 mean으로 회귀
- Multi-dimensional quality: Design, instruction following, prompt ability가 중요, 다양한 코드 스타일 지원 필요
- Tab Complete → Agentic Coding 전환:
- 기존 세대는 Tab Complete 선호, Gen Zs는 다름
- 2년간 entire file changes 방식으로 큰 변화, 생산성 높고 개발 문턱 낮춤
- Pro-tips:
- Sub-agents와 verifier agent 사용, generator-verifier gap 활용
- AI code review로 팀 부담 감소
- 커리어 팁: AI 분야 사람들의 front-end 부족, React 개발자가 AI Engineer로 career upgrade 기회
Theo Browne
- AI 시대의 API:
- Stable API 유지 중요, deprecated API 회피에 더 많은 context 필요
- Improvements는 API changes 없이 발생해야 함
- React Compiler: 인턴, 숙련 엔지니어, AI agent 모두에게 혜택
- 미래 툴: Existing APIs/solutions 개선, 더 나은 insights, old/new versions 모두 지원
- React의 강점: Complete backwards compatibility 유지하며 혁신, AI 툴 구축 default가 된 이유
- 개선 필요:
- LSP(Language Server Protocol) access 없이 TSC build 실행하는 AI 툴들
- high-quality inputs(더 나은 TypeScript 에러) 제공 필요
- 기술 추상화 진화:
- 개인적으로 Post-TypeScript 시대에 코딩을 시작, legacy knowledge 부담 없음
- Assembly → C → JavaScript 발전처럼, AI는 React 위 새로운 abstraction layer
- 툴 개선으로 하위 계층 신경 쓸 필요 감소, 다음 세대 개발자들의 context 낭비 방지
추가로 대화 마지막에 Shawn이 말한 내용이 흥미로워서 따로 첨부해봅니다ㅎㅎ
Shawn
사실 제 팁은 기술적인 것보단 커리어 관련 조언이에요. 여러분, AI 쪽 사람들은 프론트엔드를 잘 못해요.
이게 제가 ‘AI Engineer’라는 운동(?)을 시작한 이유예요. 왜냐면, 지금이 리액트 개발자들에게는 커리어를 한 단계 업그레이드할 수 있는 절호의 기회거든요.
파이썬 하는 사람들한테 가서 이렇게 말할 수 있어요.
“그래, 너희는 백엔드 잘하잖아. 프론트엔드는 우리가 맡을게.”
절대 ComfyUI 코드베이스를 보지 마세요. 진짜 괴로울 겁니다. 그 사람들도 열심히 하긴 하는데, 너무 끔찍해요.
정말 대단한 프로젝트이긴 한데, 코드 자체는 정말 형편없어요. 그들이 만든 것 중 제일 괜찮은 게 Streamlit 정도예요.
그러니까, 여러분이 “이 정도는 내가 더 잘할 수 있겠다”라고 생각해도 돼요.
그들은 정말 몰라요. 이건 우리한테 너무 쉬운 일이에요.
그래서 제 요점은, 이건 개발자들에게 커리어 전환의 기회라는 거예요.
지금 이 흐름을 제대로 못 보고 있다면, 진짜로 한번 뛰어들어 보길 권해요.
그들은 여러분을 원해요.
좋은 프론트엔드 개발자를 구하기가 정말 어렵거든요.
Joe Savona (React Team @ Meta)
💡 소플의 한 줄 요약
리액트 핵심 개발자와 함께하는 렌더링 성능 심층 탐구
🔗 영상 링크
주제 및 접근 방식
- 주제: React 성능, 특히 렌더링 성능(Rendering Performance)에 대한 심층 탐구
- 접근 방식: 전체적인 성능 최적화를 위한 Holistic Approach
- 애플리케이션의 시간 소모를 큰 그림으로 분석
- Concurrency 지원 추가: I/O bound, CPU bound 작업 최적화
React Compiler와 Incremental Computation
- 렌더링 성능 이해를 위한 다년간의 탐구
- Incremental Computation(증분 계산) 개념 도입
- 입력 변경 시 출력 효율적 업데이트
- React는 Incremental UI System
벤치마크 설계
- 다양한 Real-world Scenarios를 대표하는 벤치마크 설계
- 과도한 최적화(Over-optimize) 방지를 위해 다양한 벤치마크 사용
- Draw Benchmark:
- 매우 단순화된 프로토타이핑 앱(Prototyper)
- 텍스트 라벨과 박스 생성 지원
- 자동화된 스크립트로 React 로고 생성 (5,000 interactions)
- DOM을 동기적으로 업데이트, Layout/Paint는 단일 실행
- 순수 프레임워크 성능(Pure Framework Performance) 측정
실험 설계 및 Data Model
- 실험 설계:
- 한 번에 하나의 변수만 변경
- 주요 변수: Data Model과 Update Algorithm
- Data Model:
- 모든 앱 상태를 단일 State Value에 저장
- Context를 통해 데이터 전달
- 각 컴포넌트는 Context에서 필요한 데이터 읽기
- 거대한 Hash Map 형태로 State 저장 및 Context Value로 설정
- Update Algorithm:
- 변경된 데이터에 따라 컴포넌트 업데이트
- React (Baseline), React Compiler, Signals, React Fir, External Store 등 다양한 알고리즘 실험
Update Algorithm 실험
- React (Baseline):
- 최소한의 수동 메모이제이션(Manual Memoization)
- 5,000 interactions에 약 4초 소요
- React Compiler:
- Context 기반 앱에서 성능 크게 개선
- 컴포넌트를 더 작은 논리 단위로 분리
- 변경된 엔티티만 업데이트, 불필요한 작업(No-op) 최소화
Signals 기반 접근
- Signals 기반 런타임 프로토타입 개발
- Pull-based/Lazy Incremental Computation Graph
- 예상보다 성능 개선 미흡
- Context 변경 시 모든 노드 무효화로 비효율적
React Fir (Hybrid Eager-Lazy Algorithm)
- 새로운 증분 렌더링 접근법
- 제한된 프로토타입, 모든 React 기능 지원하지 않음
- Draw Benchmark에서 탁월한 성능
- 실제 앱 적용 시 추가 작업 필요
External Store 및 결합 접근
- External Store 사용:
- 간단한 Store 정의 (
get
, subscribe
, update
함수)
- Targeted Updates로 성능 개선
- Context 대비 적은 작업 무효화
- 결합 접근:
- React Fir + External Store 조합으로 최고 성능 달성
- 단순화된 벤치마크(Draw)에서는 뛰어난 결과
- 복잡한 앱에서는 성능 이점 감소
주요 교훈
- Data Model이 Incremental Algorithm만큼 중요
- Domain-specific 접근법이 Signals 같은 일반적인 증분 알고리즘보다 우수
- 단일 벤치마크의 개선이 모든 시나리오에 적용되지 않음
- 실제 앱 적용 시 이점 감소 가능성
빠른 앱 구축을 위한 권장 사항
- Transitions, Optimistic Updates, Suspense 활용
- Virtualization 및
<Activity />
Component로 보이는 영역에만 업데이트 제한
- 적절한 Data Modeling으로 최고 성능 달성
- Concurrent Stores 지원을 위한 새로운 API 개발 중
결론
- React 성능 최적화는 Data Model과 Rendering Algorithm의 균형 필요
- 실험 결과는 실제 앱에 적용 전 추가 검증 필요
- Concurrent Stores API로 더 나은 성능 기대
The invisible craft of great UX
Michał Dudak (Base UI Developer @ MUI)
💡 소플의 한 줄 요약
작은 디테일이 사용자 경험에 큰 영향을 미친다
🔗 영상 링크
발표자 소개
- 이름: Michał Dudak
- 역할: 훌륭한 UI를 위한 도구 개발, MUI 팀과 함께 Base UI (unstyled component library) 개발
- 목표: 사용자 경험을 향상시키는 UI 세부 사항과 상호작용 공유
훌륭한 UI의 비밀 재료
- 문제점: Figma에서는 멋지게 보이지만 구현 시 부족함 발생
- 해결책: 사용자 경험을 저하시키는 작은 세부 사항과 상호작용에 주목
- 의식적으로 눈에 띄지 않는 디테일이 중요
- 잘못 구현되면 사용자 경험 저하
상호작용 예시
드롭다운 메뉴
- 기본 동작: 클릭, 마우스 이동, 클릭
- 파워 유저: 클릭-드래그-놓기 기술 선호
- 해결책: 운영 체제 패턴에 익숙한 사용자 기대 충족, UI에 구현 시 편안함 제공
운영 체제별 UI 차이
- Mac OS: 팝오버가 트리거를 덮음
- Windows: 팝업이 트리거 아래 나타남
- 해결책: OS 확인 후 사용자 친화적인 UI 렌더링
툴팁과 생산성
- 문제: 툴팁의 기본 지연 시간은 생산성 저해 가능
- 해결책:
- 관련 트리거 간 툴팁 이동 시 지연 제거
- 사용자의 부정확한 마우스 이동 고려, 지연 복원 방지
사용자 의도 파악
- 중요성: DOM 이벤트 직접 처리 대신 사용자 의도 해석
- 예시: 팝오버
- 클릭/호버로 열리는 팝오버의 문제 (예: 호버로 열린 후 클릭 시 닫힘)
- 해결책: 열림 이벤트 직후 클릭 다르게 처리, 열림 방식에 따라 닫힘 방식 결정
중첩된 대화 상자
- 문제: 사용자가 추가 대화 상자가 있음을 인지해야 함
- 해결책: 하위 대화 상자를 축소 표시, 미묘한 애니메이션 추가로 효과적 알림
숫자 필드
- 기능: 입력, 증가/감소 버튼, 화살표 키, 수정 키로 큰 단계 증가
- 고급 기능: 스크럽 (마우스 드래그로 값 즉시 업데이트)
- 문제: 뷰포트 가장자리에서 스크럽 불가
- 해결책:
- 커서 고정
- 일정 거리 이동 후 커서 순간 이동
- 뷰포트 가장자리에서도 스크럽 지속
다중 팝오버
- 기본 방식: 각 팝오버마다 별도 팝업 요소 렌더링
- 대안: 단일 팝업 요소 재사용, 너비/높이/위치 애니메이션, 내용만 변경
- 장점: 성능 향상 (데이터 무거운 앱에서 효율적, 예: 300개 팝오버 → 1개로 축소)
- 적용 사례: Google Calendar의 이벤트 세부 정보 표시
결론
- 핵심 메시지: 작은 디테일과 상호작용이 사용자 경험에 큰 영향
- 권장사항: Base UI 사용 또는 직접 상호작용 구현
- 자료: 데모는 Michal Dudak의 GitHub에서 확인 가능
Building an MCP Server for a React Component
James Swinton (Developer Relations Lead @ AG Grid)
💡 소플의 한 줄 요약
MCP 서버를 활용해서 빠르고 정확하게 리액트 컴포넌트 만들기
🔗 영상 링크
발표자 소개
- 이름: James Swinton-Bland
- 직함: AG Grid의 DevRel Lead
- 경력: AG Grid에서 약 2년 근무
- AG Grid: 데이터 그리드 라이브러리 제공, React 애플리케이션 통합 가능
- 주요 기능: 통합 차트 기능(Excel처럼 데이터 그리드에서 차트 생성)
- AG Charts: JavaScript 차트 라이브러리, React 지원, 독립형 사용 가능
컨텍스트 문제 (The Context Problem)
- 문제 정의: AG Grid의 방대한 문서와 예제(36만 개 이상, 4개 프레임워크, 90개 버전)
- LLM 한계:
- 모든 훈련 데이터의 평균을 취해 미묘한 응답 생성
- 코딩/문서 참조 시 결정론적 답변 부족
- 특정 버전 문서 참조 불가(버전 인식 부족)
- API 변경/폐기 시 최신 정보 반영 어려움
- 예시: 레거시 CSS → 새로운 Theming API 전환
- Theming API는 LLM에 적합하지만, 기존 CSS 콘텐츠로 인해 LLM이 잘못된 응답 생성 가능
모델 컨텍스트 프로토콜 (MCP)
- 정의: AI 애플리케이션을 외부 시스템(문서 등)에 연결하는 오픈 소스 표준
- 비유: USB-C 포트처럼 표준화된 연결 방식 제공
- 작동 방식:
- MCP 호스트: LLM(Claude, Cursor, Copilot 등)에 MCP 서버 설치
- MCP 클라이언트: 세션 시작 시 서버와 1:1 통신(stdio 또는 HTTP)
- 기능: Prompts, Resources, Tools 제공
- 백업: 외부 데이터베이스, 파일 시스템 등
MCP 기능
- Prompts (프롬프트):
- MCP 작성자가 주제 전문가로 작성
- 사용자가 일반적인 사용 사례에 맞는 명확한 지침 참조 가능
- 예: AG Grid의 빠른 시작 프롬프트(사용자 정의 매개변수 지원)
- Resources (리소스):
- 문서, 예제, API 참조 등 MCP 서버 내 리소스 참조
- LLM에 추가 컨텍스트 제공
- Tools (도구):
- 실행 가능한 함수로 AI 작업 수행
- 예: 문서 검색 도구(쿼리, 프레임워크, 버전 전달 → 외부 서버 API 호출 → 압축된 Markdown 형식으로 결과 반환)
AG Search
- 목적: 프레임워크/버전별 컨텍스트를 LLM 최적화된 검색 도구로 제공
- 구현:
- 36만 개 문서/예제를
<h2 />
수준으로 청킹
- 청크를 임베딩 모델(OpenAI 등)로 변환 → 벡터 배열 생성
- 벡터 배열을 Postgres 데이터베이스에 저장(최적화된 쿼리 지원)
MCP 서버 상호 작용 과정
- MCP 서버가 문서 검색을 위한 도구 호출
- 쿼리, 프레임워크, 버전 전달 → AG Search로 요청
- 임베딩 모델로 쿼리 분석 → 벡터 배열 생성 → 하이브리드 쿼리 생성
- Postgres에서 pgvector 플러그인으로 코사인 유사성 분석
- 가장 근접한 결과 반환 → 압축된 Markdown 형식으로 LLM에 제공
데모
- 시나리오: Claude에서 빠른 시작 프롬프트 호출
- AG Grid React 컴포넌트 생성(정렬, 필터링, 행 그룹화, 편집 기능 포함)
- MCP가 버전 파악 → 문서 검색 → AI가 코드 작성
- 결과: 몇 분 만에 완성된 AG Grid React 컴포넌트
결론
- MCP 서버: AG Grid 문서와 LLM 통합으로 정확한 컨텍스트 제공
- 추가 자료: QR 코드로 문서 확인, LinkedIn에서 발표 슬라이드 공유
Why React Native apps make all the money
Perttu Lähteenlahti (Senior Developer Advocate @ RevenueCat)
💡 소플의 한 줄 요약
React Native로 만든 앱이 돈을 더 잘 버는 이유와 RevenueCat을 통한 수익화 방법
🔗 영상 링크
React Native 앱의 수익화 성과
- RevenueCat 분석:
- 75,000개 앱 분석, 총 100억 달러 이상의 수익 창출
- React Native, Swift, Android, Flutter, Cordova 등 다양한 기술 비교
- 성과:
- React Native는 다운로드 대비 유료 전환율, 설치당 수익, 고객 생애 가치(LTV)에서 우수
- 유일한 약점: 1년차 유지율(year one retention)에서 다소 낮은 성과
- 이유 추측: 사용자가 1년 내 필요한 가치를 얻고 이탈 가능성
React Native의 강점
- 크로스 플랫폼 개발:
- iOS, Android, 웹을 지원하며 각 플랫폼에 최적화된 네이티브 느낌 제공
- 단일 코드베이스로 빠른 개발과 시장 출시 시간 단축
- 개발자 채용 용이성:
- Pragmatic Engineer 뉴스레터에 따르면, React Native는 우수한 개발자 고용이 용이
- Flutter나 Swift보다 접근성이 높음
- 수익화 이점:
- 단일 코드베이스로 모든 플랫폼에서 기능 일관성 유지
- 구독, 광고 등 수익화 전략 적용 용이
RevenueCat을 통한 수익화 방법
- 서비스 개요:
- 구독 및 인앱 구매를 위한 백엔드 솔루션 제공
- iOS, Android, 웹(Stripe, Paddle 통합) 지원
- SDK 제공, 스토어 특이사항 및 영수증 검증 처리
- 주요 기능:
- 페이월, 분석 도구, 고객 그룹 타겟팅 및 실험 기능
- 가격 실험 및 자동화 지원
- 사용자 친화적인 UI로 수익 시각화
- Expo와의 통합:
- 단일 코드베이스로 iOS, Android, 웹에서 수익화 가능
- 간단한 설정: React Native Purchases SDK 설치 및 초기화
- 플랫폼별 API 키 연결
- iOS: App Store Connect
- Android: Google Play Console
- 웹: Stripe
- 페이월 및 구매 패키지 메서드 활용
구현 예시
- 설정:
- SDK 초기화 후 플랫폼별 API 키 설정
useEffect()
로 플랫폼 확인 및 초기화
- 구매 프로세스:
purchasePackage()
호출로 제품 표시 및 구매 처리
- RevenueCat UI 라이브러리로 사용자 정의 페이월 제공
getCustomerInfo()
로 구매 내역 및 자격 확인
- 특징:
- 사용자 ID를 통해 웹, iOS, Android 간 동일 사용자 추적
- 30개 이상의 페이월 템플릿 및 커스텀 페이월 지원
결론
- React Native는 빠른 개발, 크로스 플랫폼 지원, 우수한 수익화 성과로 앱 개발에 최적
- RevenueCat은 간단한 통합으로 모든 플랫폼에서 효율적인 수익화 지원
Modern emails using React
Zeno Rocha (Founder & CEO @ Resend)
💡 소플의 한 줄 요약
리액트를 사용해서 편리하게 이메일을 만드는 방법
🔗 영상 링크
이메일 제작의 도전 과제
- 과거: 브라우저 호환성 문제 (예: IE 6, 다양한 접두사 및 폴리필 필요)
- 현재: 웹사이트는 호환성이 개선되었으나, 이메일은 여전히 문제
- SVG,
border-radius
등 일부 CSS 속성 미지원
- Gmail, Yahoo Mail, Outlook, Apple Mail 등 다양한 클라이언트에서 일관된 렌더링 어려움
- caniemail.com 같은 호환성 확인 도구 필요
- 문제 인식: 기존 오픈소스 솔루션(HEML, mjml 등)은 업데이트 및 문서화 부족, 최신 기술 미적용
- 아이디어: React와 최신 기술(Tailwind, TypeScript)을 활용해 이메일 제작 간소화
- 시작: 도메인 구매 후 사이드 프로젝트로 react.email 개발
- 특징:
- create-email package: 템플릿 생성 자동화, 로컬 서버에서 테스트 가능
- 컴포넌트 기반:
Html
, Head
, Body
, Container
등 재사용 가능한 컴포넌트 제공
- 스타일링: Vanilla CSS, Tailwind 지원
- TypeScript: 변수 설정으로 빌드 안정성 강화
- 장점: 최신 기술로 개발자 친화적인 환경 제공
이메일 제작 과정
- 코딩:
- Stripe 이메일 템플릿을 참고
- Tailwind로 스타일링, TypeScript로 변수 관리
- 테스트:
- 로컬 환경에서 모바일/데스크톱 뷰 전환
- 다양한 이메일 클라이언트(Apple Mail, AOL, Outlook)에서 렌더링 테스트
- 링크 오류 검사(linter로 잘못된
href
, 404
링크 탐지)
- 호환성 매트릭스 및 스팸 검사 도구 제공
- 전송:
- Render 유틸 함수로 컴포넌트를 HTML로 변환
- 모든 이메일 서비스와 호환 가능한 HTML 출력
Resend: 이메일 API로 확장
- 배경: 더 나은 DX를 위한 이메일 API 개발
- 성과:
- Warner Brothers, HBO Max 등 주요 기업 사용
- 50만 명 이상 사용자 보유
- 1,800만 달러 이상 투자 유치
- 현재: React Email 웹사이트 개편 예정, 컨퍼런스에서 부스 운영
결론 및 제안
- 사이드 프로젝트의 가치: 관심사와 기술 학습을 결합해 혁신 가능
- 행동 촉구: 아이디어가 있다면 즉시 시작 (첫 커밋, 첫 푸시)
- 커뮤니티 참여: 컨퍼런스 부스 방문 또는 온라인 웹사이트 확인 권장
React team Q&A
Shruti Kapoor (Software Engineer, Educator, YouTuber)
Mofei Zhang (React Team @ Meta)
Joe Savona (React Team @ Meta)
Ruslan Lesiutin (React Team @ Meta)
Lauren Tan (React Team @ Meta)
Ricky Hanlon (React Team @ Meta)
Jack Pope (React Team @ Meta)
Seth Webster (Head of React @ Meta)
💡 소플의 한 줄 요약
리액트 팀의 열정을 엿볼 수 있는 Q&A 세션
🔗 영상 링크
Shruti Kapoor (사회자)
- 역할: 전 Slack 소프트웨어 엔지니어, 현재 전업 유튜버
- 활동: Reddit, Twitter, GitHub issues, 라이브스트림, Slido를 통해 질문 수집 및 전달
- React 19에서 가장 좋아하는 기능:
useEffectEvent()
- 이유: 코드를 깔끔하게 정리, ESLint 예외 처리 남용 방지
- React Foundation: 설립 소식 전달 및 관련 질문 진행
Lauren Tan
- React 19에서 가장 좋아하는 기능:
useEffectEvent()
(본인이 작성한 PR)
- 특징: 새로운 advanced API, 채팅방 웹소켓 연결 등 드문 use case에서 의존성 배열 없이 이벤트 발생
- 주의사항: 남용 방지를 위해 "effect가 필요한가?" 질문 필요, linter 사용 권장
- React Compiler
- 수동 memoization된 코드가 있어도 최적화 가능
useMemo()
/useCallback()
즉시 제거 불필요
- React Compiler 채택 장애: Babel plugin, Rust-based tooling (SWC) 전환 트렌드
- 미래 계획: Static Hermes로 TypeScript 컴파일러와 natively built binary 결합, 또는 Rust 포팅
- React Compiler 도입 이후
useMemo()
/useCallback()
을 삭제해야 될까?
- 새로운 코드 작성 시:
useMemo()
나 useCallback()
을 사용할 필요가 없음
- 사용자 기능 개발에 집중
- 메모이제이션에 대해 걱정하지 않아도 됨
- 기존 코드 사용 사례:
- 이미 작동하는 코드에서는
useMemo()
제거 시 신중해야 함
- 그대로 두어도 문제 없음
- 부담을 가질 필요 없음
- AI 조언:
- AI는 코드 작성을 대체하는 도구가 아닌 페어 프로그래밍 파트너로 활용
- 생산성 집착으로 코드 이해 없이 무분별하게 PR 생성하는 것은 위험
- AI 코드 검토 및 수정에 더 많은 시간 소요 가능
- AI가 작성한 코드를 이해하지 못하면 개발자 본인에게 손해
- 개발자의 핵심 역량은 도구 사용 지식, 이를 AI에 완전히 아웃소싱하는 것은 위험
Joe Savona
- React 19에서 가장 좋아하는 기능: Partial Prerendering
- 특징: 미리 작업 시작 후 클라이언트 렌더링 시점에 재개
useMemo()
/useCallback()
Deprecation: 현재 계획 없음
- 컴파일러가 추론 가이드로 사용, edge case에서 수동 memoization 활용
- 컴파일러는 Babel transform 이상의 정교한 컴파일러, 데이터 모델링 중요
- Svelte와 비교: React Compiler는 코드 깊이 이해, 개발자는 데이터 모델링 집중
- 커뮤니티 요청:
- 라이브러리 개발자들이 실험적 릴리스(Canary) 를 사용해 테스트하고 피드백을 주면 좋음
- Rust 생태계는 주요 패키지의 단위 테스트로 컴파일러 변경 시 생태계 붕괴를 방지하지만, 우리는 아직 그 수준에 도달하지 못함
- Canary나 메인 브랜치를 주기적으로 체크해주면 큰 도움이 됨
- 이슈를 적극적으로 제보해달라 — “누군가 이미 제보했을 거야”라고 생각하지 말 것
- X(트위터)에서 언급만 되고 이슈로 등록되지 않으면 팀이 인지하지 못할 수 있음
Jack Pope
- React 19에서 가장 좋아하는 기능:
async actions
+ useOptimistic()
<Activity />
UI 패턴:
- Tabs를 Activity로 래핑, least recently used cache처럼 유지
- Prerendering 활용
- Virtualization에서 viewport 근처는 Activity hidden, 멀리 있는 항목은
null
렌더링
- 커뮤니티 요청:
- GitHub에 issue 올릴 때 Code Sandbox 첨부
- Canary/Experimental releases로 피드백 제공
Ruslan Lesiutin
- React 19에서 가장 좋아하는 기능: DevTools의 Owner Stacks (19.1 추가)
- 특징: root부터 element까지 JStack 선언 안정적 캡처
- React Profiler vs Performance Tracks:
- React DevTools: React-specific 정보 제공
- Performance Tracks: 브라우저 트랙과 React 정보 통합 타임라인
Mofei Zhang
- React 19에서 가장 좋아하는 기능: Performance Tracks
- 특징: scheduler introspect, UI blocking 작업과 덜 중요한 작업 시각화
- React Compiler:
- 수동 memoization: expensive computation 최적화 부족 시 유용
- Rules of React breakages로 기존 앱에서 수동 memoization 유지 가능
- Meta 적용 경험: 수십만 컴포넌트 중 소수만 수정
- React Compiler 도입 이후
useMemo()
/useCallback()
을 삭제해야 될까?
- Rules of React를 따르는 경우 안전함
- React Compiler는 수동 메모를 보존하므로, 삭제 시 효과 다르게 실행 가능
- 삭제 후 테스트 필요
- 새 코드에서는 사용하지 않아도 되지만, 기존 코드에서는 테스트 후에 신중하게 제거할 것을 권장
- linter 사용 권장
- AI 조언:
- 사람들은 앞으로도 앱의 유지보수와 디버깅을 담당할 것
- AI는 아키텍처 결정을 돕거나 컴포넌트를 작성하는 데 도움을 줄 수 있지만, 문제가 생기면 사람이 해결해야 함
Ricky Hanlon
- Async React 발표
- 시간 부족으로 중단됨, 다음날 발표 2부로 대체 예정
- React 19에서 가장 좋아하는 기능: View Transitions
- 특징: 예상치 못한 애니메이션 방지, cross fades/shared elements animations 쉽게 추가
- concurrent rendering 및 scheduling 이점
- Early Adopters 인사이트: 기능 사용 어려움, 새로운 concepts
<Activity />
작동 원리:
hidden
상태: display: none
래핑, DOM 시각적 제거
- render/update는 별도 queue에 schedule, CPU idle time에 background rendering
- 사용자 상호작용 시 visible 콘텐츠 우선
hidden
전환 시 effects unmount (논란 가능), React state/DOM 저장
- 다중 탭
<Activity />
: 성능 문제 없음, 메모리 문제 가능
- 계획: least recently used 기반 DOM garbage collect, mode option 추가
- Framework-dependent features: routing, data fetching 등 연결 어려움, 자체 framework 구축 유도
- 커뮤니티 요청:
- 성공 사례와 긍정적인 피드백을 더 많이 공유해줬으면 함
- 우리는 이 기술에 열정을 가지고 있고, 그 노력이 결실을 맺는 걸 보고 싶음
Seth Webster
- React 19에서 가장 좋아하는 기능: View Transitions
- 특징: delight를 first-class citizen으로
- React Foundation:
- 아이디어
- governance/staging system 반영
- board advisory/technical governance/community contributors 통합
- 목표: ad hoc PR 방식에서 명확한 pathways 제공
- 재정 기여와 발언권:
- Meta: 초기 5년간 큰 governance stake, 매년 vote 감소, 5년 후 동일 vote
- 커뮤니티가 점진적으로 역할 확대
- Meta와 관계: 동일 인력 투자, wearable devices 등 성능 작업 집중
- AI 조언:
- AI와 React의 프리미티브를 활용하면 문제 해결 아이디어를 빠르게 실현 가능
- 커리어 측면에서의 조언:
- 코드 리뷰와 앱 설계 능력을 키워라
- LLM은 맥락 부족 시 잘못된 결정을 내리기 쉬움
- 앱이 커질수록 컨텍스트 윈도우 한계로 인해 구조적 설계가 중요함
- 아키텍처 패턴과 대규모 확장(0 → 수십억 사용자) 경험을 학습하라
- AI 활용 관점:
- 현재 AI는 아키텍처 설계나 대규모 확장에서 한계가 있음
- 하지만 점점 발전할 것이므로 AI를 활용해 5~10배 효율적인 엔지니어가 되어야 함
- 개인적 성향:
- React 코드를 직접 작성하는 즐거움이 있음
- AI로 코드 생성이 가능하더라도, 스스로 코드를 쓰는 방식을 선호
- 핵심: 자신에게 맞는 방식으로 일하라
- 커뮤니티 요청:
- React 팀은 커뮤니티를 위해 일하는 것을 진심으로 사랑함
- X(트위터)에서 ‘Signals’ 관련 논쟁이 생기면 팀원들이 개인적으로 상처받음
- “최고의 기술을 찾자”는 열린 마음과 학문적 접근을 바람
- 커뮤니티와 서로에게 감사와 친절을 보여주길 요청
- React를 사용하고 이 자리에 함께한 모든 사람들에게 감사
이번 매거진은 AI의 도움을 받아서 요약하긴 했지만, 컨퍼런스 영상을 모두 시청하고 정리하느라 꽤 힘들었네요 🥲
열심히 작성한 글인 만큼 주변에 많이 공유해주시면 너무 뿌듯할 것 같습니다ㅎㅎ
그리고 관심 있는 세션은 글로만 보기 보다는 실제 발표 영상을 보시는 것을 추천드립니다.
Day 2에 대한 내용도 곧 정리해서 올릴 예정이니 기대해 주세요!
지금까지 소플이었습니다. 감사합니다 😀