[FEConf 2023] 대형 웹 애플리케이션 Micro Frontends 전환기

200개 페이지가 넘는 복잡하고 큰 SaaS 웹 제품을 UI 컴포넌트 단위의 작은 앱으로 쪼개 독립적으로 개발, 배포할 수 있는 Micro Frontends 아키텍처로 전환한 여정을 FE Conf에서 공유합니다.

레퍼런스가 부족하고 불확실성이 큰 기술 도입에 어떤 설득과 의사결정이 필요한지, 팀의 기능 개발 속도를 최대한 늦추지 않고 제품의 아키텍처를 바꾸려면 어떻게 해야 하는지와 같은 질문들에 대해 플렉스팀이 찾아갔던 답을 확인해 보세요.

- 플렉스팀이 풀고 있는 문제와 팀에 관심이 있으시다면플렉스팀 Product Engineer(FE) 채용 페이지를 참고해주세요.
- 기술 포스팅을 포함해 잡다한 글이 올라오는 제 블로그에도 놀러오세요!

Transcript

1. 대형 웹 애플리케이션 Micro Frontends 전환기 ӣઙഄ | ೒۩झ౱
3. 대형 웹 애플리케이션의 아키텍처 마이그레이션 여정 더 좋은 제품, 일하는 방식을 위한 아키텍처 변경🧑⚖ 부족한 레퍼런스, 불확실한 기술 검증 과정 🤔 (2022.06 ~ 2023.03, 약 8개월)
4. 목차 1. flex 제품 & 코드베이스 소개 2. 문제 탐구의 시작 3. Proof of Concepts 4. Actions 5. 마이그레이션 완료
5. flex 제품 & 코드베이스 소개
6. ઁಿ ࢎ૓җ ࢸݺ GNB
7. ઁಿ ࢎ૓җ ࢸݺ GNB
8. ઁಿ ࢎ૓җ ࢸݺ GNB
10. 통합의 경험
11. 구성원 초대
12. 구성원 초대 근로계약
13. 구성원 초대 근로계약 근무/휴가
14. 구성원 초대 근로계약 근무/휴가 급여명세서
15. 구성원 초대 근로계약 근무/휴가 급여명세서 각 과정에서 발생하는 데이터 사용 통합의 경험!
17. 🤯
18. 200개 이상의 URL 17개로 분리된 앱 8.7GB의 전체 코드베이스 그것보다 많은 공용 패키지와 참조
20. 🍄 문제 탐구의 시작 (2022.06)
21. 기존 아키텍처 문제 탐구의 시작
22. 기존 아키텍처의 문제들 1. 유저에게 하나의 앱을 쓰는 경험을 전달할 수 없다. 2. 스쿼드 독립적, 효율적인 개발이 힘들다. 문제 탐구의 시작
23. 기존 아키텍처의 문제들 1. 유저에게 하나의 앱을 쓰는 경험을 전달할 수 없다.
24. 기존 아키텍처의 문제들 2. 스쿼드 독립적, 효율적인 개발이 힘들다.
25. Module Federation이란? Micro Frontends 하나의 앱을 독립적인 배포가 가능한 모듈 단위(js번들)로 나누어 브라우저의 런타임에 동적으로 통합 Micro Frontends의 구현 방식 중 하나, Run-time Integration via javascript
26. Module Federation Workflow Micro Frontends
27. flex with Module Federation Micro Frontends
28. 기존 아키텍처의 문제들 1. 유저에게 하나의 앱을 쓰는 경험을 전달할 수 없다. → 런타임에는 하나의 앱으로 2. 스쿼드 독립적, 효율적인 개발이 힘들다. → 배포단위를 더 작게 쪼개서 런타임에 통합 Micro Frontends 아키텍처로 해결
29. 런타임 통합 Micro Frontend 아키텍처의 장점 배포 단위 더 작게 쪼개기 + 하나의 앱을 사용하는 경험까지
30. 런타임 통합 Micro Frontend 아키텍처의 장점 배포 단위 더 작게 쪼개기 + 하나의 앱을 사용하는 경험까지 🤔 flex에서도 잘 동작할까?
31. 🤔 Proof of Concepts (2022.07 ~ 2022.08)
32. Micro Frontends 체험존 개장 🎉 Proof of Concepts
33. Nextjs에서는 Module Federation을 적용할 수 없을까? Proof of Concepts
34. Nextjs를 떼어낸 이유 Proof of Concepts
35. 트레이드 오프 Proof of Concepts
36. 트레이드 오프 Proof of Concepts PoC에서 감지하지 못한 문제가 발생한다면? 😵💫
37. 실패하면 어떡하지? 😭 Proof of Concepts 우리가 도입하고자 하는 것은 Micro Frontends이지, Module Federation이 아니다 Decision Tree & Fallback Plan 앱은 계속 커지고 많아질 것이며 당면한 문제는 지속될 것이다. 결국 Micro Frontends는 가야할 길이다.
38. 🔨 Actions (2022.09 ~ 2023.03)
39. 새 애플리케이션 기반 다지기 팀 차원의 자신감 향상시키기 기능 개발 속도 최대한 유지하기 전사가 참여하는 마이그레이션 QA (2022.11 ~ 2022.12) (2023.01 ~ 2023.03) (2022.9 ~ 2022.10) (2022.10 ~ 2022.11)
40. 팀 차원의 자신감 향상시키기 지식 공유, 팀 전체의 지식 수준 향상 데모 환경 배포로 남은 가설 검증
41. 미지의 세계와의 조우 팀 차원의 자신감 향상시키기
42. 데모 환경 발전시키며 남은 가설들 검증하기 팀 차원의 자신감 향상시키기
43. 데모 환경 배포 팀 차원의 자신감 향상시키기 프로덕션과 동일한 사내 인프라를 이용하여 데모 환경 배포 빌드, 배포 과정을 미리 경험하고 이슈 식별
44. 새 애플리케이션 기반 다지기 Micro Frontends의 리스크 완화
45. 리스크 완화하기 새 애플리케이션 기반 다지기 1. Module Federation 전방향(Omnidirectional) 리스크 2. 런타임 에러 리스크
46. 전방향(Omnidirectional) 리스크 새 애플리케이션 기반 다지기
47. 전방향(Omnidirectional) 리스크 새 애플리케이션 기반 다지기 다른 앱의 런타임에 부를 수 있는 코드 지정 (Remote) 해당 앱의 런타임에 로드하는 다른 앱의 URL (Host)
48. 전방향(Omnidirectional) 리스크 새 애플리케이션 기반 다지기 Host와 Remote가 동시에 될 수 있는 Micro App 하나의 Config로 Host-Remote 단방향 레이어 강제 Host앱만이 다른 Remote를 로드할 수 있음
49. 런타임 에러 리스크 - 에러 격리 새 애플리케이션 기반 다지기 전체 장애로 이어지는 Remote App 로드 실패 Remote App 로드 실패시에도 앱의 다른 기능을 사용할 수 있어야 한다.
50. 런타임 에러 리스크 - 2가지 로컬 개발 환경 새 애플리케이션 기반 다지기 dev:multiple - host, gnb 앱을 함께 로컬 개발 서버에 띄움 dev:standalone - 특정 Remote앱 하나만 로컬 개발 서버로 띄움 속도 이점, 빠른 개발 가능 각각 다른 포트에 앱이 띄워짐, 런타임 안정성 검증
51. 기능 개발 속도 최대한 유지하기 기능 개발을 최대한 블락하지 않는 아키텍처 마이그레이션 전략
52. 점진적 마이그레이션 불가능 기능 개발 속도 최대한 유지하기
53. 빠른 팀의 속도 기능 개발 속도 최대한 유지하기 flex의 기능은 빠른 속도로, 많은 업데이트가 이루어진다. 아키텍처 마이그레이션이 기능 개발 속도를 느리게 만들지 않아야 팀의 속도를 유지할 수 있다.
54. 두 가지 환경에서 동시에 빌드 성공시키기 기능 개발 속도 최대한 유지하기
55. 두 가지 환경에서 동시에 빌드 성공시키기 기능 개발 속도 최대한 유지하기 🚘 👩💻🧑💻 📦 부릉부릉 기존 아키텍처
56. 두 가지 환경에서 동시에 빌드 성공시키기 기능 개발 속도 최대한 유지하기 🚘 👩💻🧑💻 📦 부릉부릉 🚍 부릉부릉 새로운 아키텍처
57. 두 가지 환경에서 동시에 빌드 성공시키기 기능 개발 속도 최대한 유지하기 🚘 👩💻🧑💻 📦 부릉부릉 🚍 부릉부릉 폴짝
58. 두 가지 환경에서 동시에 빌드 성공시키기 기능 개발 속도 최대한 유지하기 🚘 👩💻🧑💻 📦 부릉부릉 🚍 부릉부릉 착
59. 두 가지 환경에서 동시에 빌드 성공시키기 기능 개발 속도 최대한 유지하기 👩💻🧑💻 📦 🚍 부릉부릉 착
60. 두 가지 환경에서 동시에 빌드 성공시키기 기능 개발 속도 최대한 유지하기 👩💻🧑💻 📦 🚍 부릉부릉 😎 달리는 차에서 다른 차로 뛰어 옮겨가기
61. 두 가지 환경에서 동시에 빌드 성공시키기 기능 개발 속도 최대한 유지하기
62. 두 가지 환경에서 동시에 빌드 성공시키기 기능 개발 속도 최대한 유지하기
63. 두 가지 환경에서 동시에 빌드 성공시키기 기능 개발 속도 최대한 유지하기 기존 앱 deprecate, 프로덕션 대체
64. 호환 패키지 대체하기 기능 개발 속도 최대한 유지하기 분리한 패키지의 컴포넌트에서 Nextjs 구현체를 import하는 경우 -> Micro App에서 빌드 에러
65. 호환 패키지 대체하기 기능 개발 속도 최대한 유지하기 Micro App의 webpack 설정을 이용해 빌드타임에 대체 기존 내부 패키지의 인터페이스를 그대로 유지한 Micro App 호환되는 패키지 제작
66. 전사가 참여하는 마이그레이션 QA 점진적 스테이징 환경 마이그레이션 기존 기능 개발과 함께하는 QA
67. 점진적 환경 대체 및 이슈 식별 전사가 참여하는 마이그레이션 QA
68. 점진적 환경 대체 및 이슈 식별 전사가 참여하는 마이그레이션 QA 제품 기능 QA에 사용하는 스테이징 환경 대체 시작
69. 점진적 환경 대체 및 이슈 식별 전사가 참여하는 마이그레이션 QA 브라우저 쿠키를 통해(App-Type) 기존 앱 / Micro Frontend 앱간 전환 가능 🍪 제품 기능 QA에 사용하는 스테이징 환경 대체 시작
70. 이슈 해결 과정 전사가 참여하는 마이그레이션 QA
71. 전사의 소망과 힘을 모아 전사가 참여하는 마이그레이션 QA 점진적 대체로 효과적인 이슈 조기 식별 아키텍처와 함께 일하는 환경도 함께 마이그레이션
72. 전사의 소망과 힘을 모아 전사가 참여하는 마이그레이션 QA 점진적 대체로 효과적인 이슈 조기 식별 아키텍처와 함께 일하는 환경도 함께 마이그레이션
73. 🚀 마이그레이션 완료 (2023.03.23)
74. 성과 1. 유저 경험 개선 - 하나의 앱을 쓰는 경험 2. 배포 단위 세분화 - 전체 장애/롤백 상황 최소화 3. 개발 생산성 개선 - 빌드 시간 평균 70% 개선(20분 → 5분)
75. 남은 문제들 1. 개발자 경험(DX) - 기성 프레임워크 따라가려면 멀었다 2. 아직 존재하는 런타임 리스크 - 앱 간 상태 분리, 배포 순서 3. SSR 구현 및 서버 리소스 활용 - 정적 자원 서빙 역할만 하고 있음
76. 남은 문제들 1. 개발자 경험(DX) - 기성 프레임워크 따라가려면 멀었다 2. 아직 존재하는 런타임 리스크 - 앱 간 상태 분리, 배포 순서 3. SSR 구현 및 서버 리소스 활용 - 정적 자원 서빙 역할만 하고 있음 ✨ 이게 특히 재밌습니다 Micro Frontends에서의 SSR..?
77. 🍇
78. podojs flex Micro Frontends 프레임워크 포도 한 알이 각각의 Micro App, 모여서 한 송이를 이루는 것이 현재의 flex와 비슷 각각 앱에 대한 오너십은 독립적이면서도 원팀(한 송이)로 일하고자 하는 팀의 의지
79. Recap - 복잡하고 많은 flex 웹앱: 앱 별로 분리해 인프라단에서 라우팅 - 런타임 통합 Micro Frontends로 마이그레이션 - 각각의 분리된 앱들을 아우르는, 하나의 앱을 쓰는 경험 - 스쿼드 독립적인 개발이 가능한 환경 - PoC: 가설 검증, 체험존, 기술 리서치
80. Recap - Actions: 마이그레이션 진행 - 팀 내 자신감 향상: 기술 리서치 및 공유, 데모 환경 배포 - 새 애플리케이션 기반 다지기: 런타임 통합 리스크 완화 - 기능 개발 속도 유지하면서 마이그레이션 - 전사가 참여하는 마이그레이션 QA - 마이그레이션 완료: 8개월간의 여정 종료, 유저 경험/개발 경험/빌드 성능 향상 - podojs: 프레임워크화를 통한 앞으로의 과제의 효과적 해결
81. 🍇👩🌾🧑🌾👨🌾