팜브릿지의 진화: Vanilla → React Island

의사결정

HTML/CSS/JavaScript만으로 라우팅·상태·이벤트 모듈 자체 구현

근거

백엔드 Spring 전환과 동기화된 일정 안에 안정화해야 하는 제약이 가장 컸습니다. 여기에 SSR 라우팅(서버 렌더된 페이지 셸을 그대로 활용해야 하는 제약)·운영 인력의 장기 유지보수 가능 기술 폭을 함께 고려한 결과, React를 도입하면 구조 설계·학습 비용 때문에 전환 일정 내 안정화가 어렵다고 판단했습니다.

의사결정

Vanilla JS의 한계 인식 + SSR 제약 재검토

근거

화면 단위로 묶여있던 상태와 이벤트가 서로 결합되어, 한 화면을 수정하면 다른 화면에 영향이 가는 사례가 늘었습니다. SSR 라우팅 자체는 SEO와 서버 의존성 때문에 변경할 수 없는 제약이 그대로였습니다.

의사결정

SSR이 페이지 셸을 그대로 그리고, 동적 영역만 React 컴포넌트가 마운트되는 SSR/CSR 하이브리드 구조

근거

전면 전환은 SSR 제약상 불가능했고 일정상도 비현실적이었습니다. 정적 영역은 SSR이 그대로 처리하고, 인터랙션이 필요한 영역만 React로 마운트하는 구조라면 양쪽의 장점을 살리면서 점진적으로 마이그레이션할 수 있다고 판단했습니다.

의사결정

React Query 전면 도입 + 도메인별 훅·유틸 분리 + Jest+MSW 테스트 인프라

근거

React 영역에서 발생하는 API 호출·캐싱·에러 처리를 React Query로 일원화했습니다. 화면 단위로 묶여 있던 로직은 도메인별 훅·유틸로 분리해 prop drilling을 제거했습니다. 부분 도입한 React 영역의 회귀 안정성을 위해 Jest+MSW 기반 테스트 인프라도 함께 구축했습니다.

의사결정

리팩토링 전후 번들·에셋 사이즈를 직접 측정해 React 도입의 성능 영향을 정량 확인

근거

SearchWait 페이지를 기준으로 gzip 전송량을 비교했습니다. React 도입으로 jQuery 등 외부 CDN 의존(약 207 KB)은 사라졌지만, 단일 페이지 첫 진입 비용은 SSR 약 111 KB → React 약 150 KB(gzip)로 오히려 늘었습니다. 단일 페이지만 보면 손해처럼 보이지만, 코드 스플리팅 구조라 사이트 전체·재방문 캐시까지 보면 분할 구조가 역전 우위를 가질 여지가 있다고 분석했습니다. ‘React가 무조건 가볍다’가 아니라, 측정해 보니 트레이드오프였고 그 트레이드오프를 어디서 회수하는지를 이해하는 것이 핵심이었습니다.