개요

얼마 전에 링크드인에서 올리브영 개발자분께서 공유하신 마이크로 프론트엔드에 대한 포스팅을 봤다. 마이크로 서비스 아키텍처에 대해서는 들어봤는데 마이크로 프론트엔드에 대해서는 들어본 적이 없어서 궁금해서 봤는데 되게 흥미로운 내용이어서 따로 더 찾아보게 되었다.

마이크로 프론트엔드(Micro Frontend)는 대규모 프론트엔드를 각 영역별 애플리케이션으로 나누고 각각 따로 개발·테스트·배포한 후 하나의 서비스처럼 제공하는 아키텍처 패턴이다.

코드를 여러 디렉터리에 나눴더라도 상품 화면을 수정했을 때 결제나 회원 화면까지 다시 빌드해야 한다면 마이크로 프론트엔드의 장점을 제대로 활용했다고 보기 어렵다.

예를 들어 쇼핑몰은 다음처럼 나눌 수 있다.

E-Commerce Web
├── Product MFE   상품 조회와 상세
├── Cart MFE      장바구니
├── Order MFE     주문과 결제
└── Account MFE   로그인과 마이페이지

사용자는 shop.example.com 하나를 이용하지만 내부에선 여러 프론트엔드 애플리케이션이 화면을 구성하게 된다. 각 MFE는 비즈니스 영역을 하나씩 소유하고 자체적으로 코드베이스와 배포 주기를 가질수있다.

배경

작은 서비스의 SPA는 보통 한 레포에 한 배포 파이프라인으로 충분하다.

Frontend
├── components
├── pages
├── hooks
├── services
└── store

서비스, 조직이 커지면 상품, 주문, 결제, 회원, 검색, 추천 등 다양한 기능들이 계속 추가되게 되는데, 처음에는 기존 코드를 돌려쓰기 쉬워 보이지만 시간이 지날수록 서로 얽히고 꼬인다.

그 결과는 다음과 비슷해진다.

상품팀 ─┐
결제팀 ─┤
회원팀 ─┼── 하나의 Repository
검색팀 ─┤   하나의 Build
추천팀 ─┘   하나의 Deployment

코드의 양만이 문제가 아니라 한 팀에서 변경하는 걸 검토하기 위해 다른 팀의 상태와 배포 일정을 알아야하고 작은 수정을 할 때도 전체 빌드와 릴리스에 포함하게 된다.

마이크로 프론트엔드는 이런 병목을 비즈니스 단위로 나눠 해결하려는 방식이다.

Product Team  → Product MFE  → Pipeline A ─┐
Order Team    → Order MFE    → Pipeline B ─┼─ Shell → User
Account Team  → Account MFE  → Pipeline C ─┘

각각의 팀이 그 팀의 영역을 기획부터 운영까지 완전히 맡도록 하는 것이다.

결론

마이크로 프론트엔드는 프론트엔드를 여러개로 쪼갠다는 개념보다는 여러 팀이 대규모 서비스 하나에서 각각 자신의 영역을 관리할 수 있도록 하는 방법에 가깝다.

그 대가로 CI/CD와 관측성, 통합 테스트, dependency 관리, 성능, 보안의 복잡도가 늘어난다. Module Federation이나 single-spa를 도입한다고 이 문제가 자동으로 해결되지는 않는다. 런타임에 함께 실행되는 MFE는 여전히 같은 페이지의 권한과 사용자 경험을 공유하며, 기술 혼합도 독립 배포를 보장하지 않는다.

그 대신 구조가 복잡해지기 때문에 소수 팀에서 운영하는 소규모 서비스에서는 권장하기 힘들다. 하지만 팀마다 릴리즈 주기가 다르고 병목이 있다면 복잡해지는걸 감수하고 도입해보는 것을 고려할만 한 것 같다.

참고 자료