본문 바로가기
Frontend2026년 5월 29일2분 읽기

Qwik 2.0 resumability — 1년 운영 후 정직한 평가

YS
김영삼
조회 258
Qwik 2.0 resumability — 1년 운영 후 정직한 평가

핵심 요약

Qwik 2.0 production 1년. resumability로 hydration 비용 0, 100KB만 다운로드로 인터랙티브. 마케팅 사이트 8개에서 압승, 대시보드/admin은 React 유지. 가장 큰 비용 — 신규 인력 채용 어려움.

1. Resumability란

Hydration: 서버 HTML + 전체 JS 다운로드 → 클라이언트에서 다시 컴포넌트 트리 실행. Resumability: 서버에서 직렬화한 state를 그대로 "이어감", 필요한 JS만 lazy load. 1MB JS 사이트가 4KB로 시작.

2. 실측 — 8개 마케팅 사이트

지표Next.jsQwik 2.0
FCP(p75)1.4s0.8s
TTI(p75)2.8s1.1s
Total JS(첫 로드)380KB4KB
Lighthouse Perf7898

3. 대시보드는 안 맞음

빠른 interaction이 많은 대시보드에서는 lazy-load 비용이 더 큼. 사용자가 5분 안에 모든 컴포넌트를 만지면 결국 전체 JS 다운로드. Hydration 비용 절감의 이점이 사라짐. 이 경우 React/Solid가 적합.

4. 채용 — 1년의 가장 큰 비용

Qwik 경험자 풀이 작아 채용 시간 2~3배. 사내 교육 4주 필요. 신규 인력 6명 중 4명이 6개월 내 React 복귀 요청. 결국 marketing 사이트 maintenance 팀만 Qwik 유지, 신규 프로젝트는 React로 회귀.

5. 함정

  • serialize 한도 — 직렬화 불가 타입(Date, Map, Set)을 store에 넣으면 resume 실패, 패턴 학습 필요
  • 3rd-party React 컴포넌트 — qwik-react로 wrap 가능하지만 lazy-load 이점 잃음
  • SEO — robots는 정적 HTML 보지만, 일부 검색엔진은 JS 실행 후 평가, qwik$ 함수 trace 깨지면 SEO 영향
  • 팀 통일성 — React 팀과 Qwik 팀이 분리되면 코드 공유 비용 큼

댓글 0

아직 댓글이 없습니다.
Ctrl+Enter로 등록