[FE] flex 팀의 마이크로 프론트엔드 전환기 - 정리

기존

• 17개의 nextjs 앱의 모노레포, 인프라 레벨에서 라우팅해줌
• 제품 전체 200개 이상의 url
• 제품 전체 8.7GB 코드베이스
• 각 스쿼드에서 페이지 별로 앱을 나눠서 개발
• 단점
  • 페이지 이동할 때마다 유저에게 하나의 앱을 쓰는 경험을 주기 힘듦.
    • 다른 nextjs 앱이기 때문에 페이지 로딩 시 html, js, css를 전부 다시 내려받아야함
  • 스쿼드 독립적, 효율적인 개발이 힘듦.
    • 앱 간의 의존성이 있음
    • 공통 컴포넌트의 경우 한번 수정되도 모든 앱에 영향을 끼쳐서 작은 이슈에도 전체 롤백해야함

Module Federation PoC

• Nextjs에 적용 가능한 오픈소스 기반의 Module Federation을 적용할 수 있는 플러그인 존재
• 기존 앱에 적용해보니까 동작하는 것은 확인
• 그러나, Next.js 측에서 모듈 페더레이션을 공식적으로 지원할 생각이 없어보였고, 오픈 소스 기반의 플러그인에 큰 프로젝트의 아키텍처를 맡길 수 없다는 판단내림
• ⇒ Nextjs 떼어내기

Nextjs를 전면 SPA로 마이그레이션하기

• Next.js의 SSR을 하드하게 사용하고 있지 않다.
• flex는 B2B saas라서 SEO 등 SSR이 강점을 보일 수 있는 부분이 적다.
• 한정된 리소스로 Module Federation을 적용하면서 SSR까지 가져가기는 힘드라.

 

성과

1. 유저 경험 개선 : 하나의 앱을 쓰는 경험
2. 배포 단위 세분화 : 전체 장애/롤백 상황 최소화
3. 개발 생산성 개선 : 빌드 시간 평균 70% 개선

남은 문제점

1. 개발자 경험(DX) : nextjs가 주던 개발 편의성을 누리지 못하게됨
2. 아직 존재하는 런타임 리스크 : 앱 간 상태 분리, 배포 순서 등
3. SSR 구현 및 서버 리소스 활용 : 정적 자원 서빙 역할만 하고 있음