알스솔루션
팜브릿지 서비스 리팩토링
Vanilla JS로 운영하던 팜브릿지 화면의 유지보수 한계를 React Island 패턴으로 부분 전환. SSR 라우팅 제약 하에서 SSR/CSR 하이브리드 구조 설계
주요 성과
- 배경: Vanilla JS로 운영하던 화면이 상태·이벤트 결합으로 유지보수 비용 누적. SSR 라우팅 구조는 SEO·서버 의존성 때문에 변경할 수 없는 제약 하에서 부분 React 도입 결정
- 의사결정: React Island 패턴 채택 — SSR이 페이지 셸을 그대로 그리고, 동적 영역만 React 컴포넌트가 마운트되는 SSR/CSR 하이브리드 구조로 설계
- React Query 전면 도입으로 API 호출·캐싱·에러 처리 일원화
- 화면 단위로 묶여 있던 로직을 도메인별 훅·유틸로 분리하고, Context 도입으로 prop drilling 제거
- 테스트 인프라(Jest+MSW) 구축으로 React 영역 테스트 커버리지 0% → 약 20% 확보, 회귀 안정성 확보
- 성능 검증: 리팩토링 전후 번들·에셋 사이즈를 직접 실측해 트레이드오프 정량 확인. SearchWait 페이지 기준 jQuery 등 외부 CDN 의존(약 207 KB)은 제거됐으나 단일 페이지 첫 진입 비용은 gzip 약 111 KB → 150 KB로 증가 — 코드 스플리팅 구조라 사이트 전체·재방문 캐시 관점에서 역전 우위 여지가 있다고 분석
전환 자세히 보기
바꿀 수 없는 SSR 라우팅 제약 위에서 React를 어디까지 들여왔는지, 그리고 그 전환의 효과를 체감이 아니라 실측으로 검증한 기록 — 무엇이 좋아졌고, 무엇이 오히려 나빠졌으며, 어디까지가 측정이고 어디부터가 추정인지.
1. 구조 — 페이지가 아니라 섬을 바꾼다
SSR 라우팅은 SEO와 서버 의존성 때문에 변경 대상이 아니었다. 그래서 페이지 전체를 React로 가져오는 대신, 서버가 셸을 그대로 그리고 상호작용이 필요한 영역에만 React를 마운트하는 Island 패턴을 택했다. 전환 범위가 곧 회귀 리스크 범위라, 정적인 곳은 건드리지 않는 것이 그대로 이득이 된다.
2. 측정 기준
동일한 SearchWait 화면을 기준으로 SSR(jQuery) 버전과 React(코드 스플리팅) 버전의 앱 코드·외부 의존·청크 구조를 gzip 전송량 기준으로 비교했다. 폰트 등 양쪽 공통 비용은 제외하고, 비교 가능한 범위의 측정 수치만 사용했다.
3. 전후 비교
앱 코드 첫 진입 (gzip)
증가약 111 KB→약 150 KB
동일 SearchWait 화면. React 런타임 오버헤드(vendor-react gzip 약 45 KB) 포함
jQuery + jQuery-UI (transfer)
개선약 207 KB→제거
공용 CDN이라 타 사이트 캐시 공유 시 실 비용은 명목보다 낮을 수 있음
중복 jQuery 레거시 사본
개선약 750 KB (원본)→정리
jquery_.js · jquery_20131014.js · jquery-1.8.0.min.js 등
청크 분할 / 캐싱
개선페이지마다 원본 재요청→56개 청크 · vendor 공유
해시 파일명으로 장기 캐시 + 안전한 무효화. 효과는 다중 페이지·재방문 가정
4. 전환의 실질 이득
- +의존성 구조 단순화 — React 컴포넌트 모델이 DOM 조작·이벤트 바인딩을 대체하면서 jQuery / jQuery-UI 자체가 불필요해지고, 중복 레거시 사본까지 정리 가능.
- +캐싱 구조 — vendor 청크가 페이지 간 공유되고 해시 파일명으로 장기 캐시·무효화가 안전해져, 다중 페이지·재방문 시 누적 전송량 절감 여지.
- +빌드 파이프라인 확보 — minify·tree-shaking·gzip 등 빌드 최적화 파이프라인을 표준으로 가져갈 수 있음.
- +유지보수성 — 이번 전환의 본래 동기. Vanilla JS에서 화면 단위로 결합돼 있던 상태·이벤트를 도메인별 훅·유틸로 분리하고 React Query로 API·캐싱·에러 처리를 일원화, 테스트 인프라(Jest+MSW)까지 확보해 변경 시 영향 범위를 좁힘.
5. 정직하게 짚는 한계
- −페이지 진입 비용은 오히려 증가했다. 단일 화면만 쓰는 사용자에겐 SSR보다 무겁다 (gzip 약 111 KB → 150 KB).
- −캐싱·누적 전송 우위는 ‘다중 페이지 탐색·재방문’ 가정에서만 성립하는 추정이며, 실제 사용자 트래픽 패턴으로 검증이 필요하다.
- −jQuery 207 KB는 공용 CDN이라 타 사이트 캐시 공유로 실 비용이 명목보다 낮을 수 있어, ‘207 KB 순절감’으로 단정하면 과대평가다.
- −SSR→React 전환 자체의 마이그레이션 비용(공수·회귀 위험)은 별도이며, 번들 분석 범위 밖이다.
→ 전환의 실질 이득은 번들 크기 자체보다 의존성 정리·캐싱 구조·유지보수성에 있다. 단순 페이지 용량만 보면 개선이 아니라는 점은 분명히 해 둔다.