Micro Frontend(MF)란?
하나의 웹 애플리케이션을 여러개의 작고 독립적인 서비스의 모음으로 구성하는 아키텍처를 말합니다.
다음과 같은 장점이 있습니다.
- 관심사 분리로 인한 개발 속도 향상 및 높은 유지보수성
- 독립적인 서비스 구성으로 인해 배포 및 단일 테스트 향상
여러개의 서비스를 가지고 있기에 발생하는 어려움도 있습니다.
- 여러 서비스를 하나로 묶기에 복잡성 증가, 퍼포먼스 오버헤드 발생 가능
- 다양한 서비스및 환경으로 인해 전체적인 테스트 및 디버깅 어려움
현재 서비스가 가진 문제
제가 담당하는 프로젝트는 디지털 학습지입니다.
학습지라는 도메인 특성상 문제 화면을 학습지 앱, LMS(학습데이터 조회 대시보드), CMS(문제 데이터 생성보드) 각각 보여줬어야 했습니다.
문제 UI 같은 경우 사내 공용 라이브러리로 있었지만 해당 프로젝트에 맞는 비지니스 로직(date fetch, etc)은 실제 구현해야 했습니다.
그러다 보니 각각의 프로덕트에 현하면서 여러가지 문제점이 발생했습니다.
- 동일한 비지니스 로직을 각각 여러번 개발해야했습니다.
- 각각의 프로덕트에 발생하는 버그들이 해당 프로덕트에 국한된건지 아니면 전체적인 이슈인지 까지 알아내는데 시간이 많이 걸렸습니다.
- 해당 문제 화면에 대한 이슈를 각각 프로덕트 담당자가 계속 트래킹해야해서 전체 프로젝트에
어떻게 해결했나
문제 화면을 분리하여 독립적인 서비스로 만들어야 했습니다.
MF library나 Webpack5 modulefederation도 고려해보았으나 문제 화면 서비스 같은경우 부모 서비스와 통신해야 하는 케이스가 적었기에 iframe을 사용하는게 적합했습니다.
- 문제 화면 서비스를 생성하고 문제 UI 렌더링 및 비지니스 로직을 옮겼습니다.
- 부모 서비스와 문제 화면 서비스가 서로 통신할 수 있도록 postMessage를 사용하여 API 규약을 정했습니다.
- iframe 같은 경우 보안 이슈가 발생할수 있기에 origin을 서로 확인하는 작업 및 CSP(content security policy)를 해당 주소로 추가합니다.
결과
MF를 도입하면서 문제 화면에 대한 관심사가 분리가 되어서 전반적인 유지보수성 및 코드복잡성이 개선되었습니다.
