발표 도입
두레이와 TOAST UI 캘린더를 개발하는 프론트엔드 개발자가 자기소개로 시작한다. '점진적으로 프레임워크를 교체하기'라는 주제를 던지며, 리액트·뷰·앵귤러 선택의 무게와 교체 시기가 왔을 때의 막막함을 화두로 제시한다.
AngularJS처럼 지원이 중단된 프레임워크를 계속 쓸 때의 위험을 설명한다. 보안 이슈, 상태 관리·컴포넌트 기반 등 새 패러다임 적응 곤란, 커리어·채용 문제를 들며, 안정성과 생산성이 높은 최신 프레임워크로 바꿀 이유를 정리한다.
전면 교체는 처음부터 모든 기능을 다시 만들어야 해 시간·비용 리스크가 크다고 지적한다. 시스템을 컴포넌트 단위로 분해해 독립적·선택적으로 조금씩 바꾸고 배포하며 결과를 확인하는 점진적 교체의 장점을 설명한다.
웹 페이지 내 영역을 여러 개로 나눠 각각 독립적인 앱으로 개발한 뒤 합치는 마이크로 프론트엔드 개념을 소개한다. 두레이 주소록의 상·하단 앵귤러는 남기고 중간 영역만 Vue로 바꾸는 식으로 점진 교체에 딱 맞는 전략임을 설명한다.
교체 전 반드시 해야 할 필수 준비로 기능 파악을 강조한다. 기획서 확보, QA 테스트 시트 정독, 문서에 안 드러나는 커스텀 기능은 코드로 파악하기를 권하며, 이 단계를 빼먹으면 반드시 후회한다고 당부한다.
한 페이지에서 두 프레임워크를 돌리는 방법을 세 가지로 프로토타이핑한다. SPA를 포기한 별도 페이지 분리와 iframe 방식은 흰 화면 깜빡임·로딩 저하·통신 제약 등 단점이 커 적합하지 않다고 판단하는 과정을 설명한다.
AngularJS 내부에 Vue 컴포넌트를 삽입하는 방식을 채택해 SPA와 깜빡임 제거를 유지한다. ng-non-bindable로 영역을 나누고 다이나믹·비동기 컴포넌트로 유연성·성능을 확보하며, 리액티브·Vuex dispatch·subscribeAction으로 프레임워크 간 데이터를 주고받는다.
회귀 테스트와 로딩 성능으로 교체 결과를 검증한다. 사전 파악 부실로 스펙 누락 이슈가 나왔음을 인정하고, 불필요한 라이브러리 제거로 오히려 초기 렌더링이 빨라진 결과를 소개하며 점진 교체와 스토리북 활용을 권한다.