마이크로 프런트엔드 개념과 절충점

마이크로 프런트엔드는 마이크로서비스 개념을 사용자 인터페이스 계층으로 확장한 것입니다. 하나의 웹 애플리케이션을 여러 팀이 각각 소유하고 독립적으로 개발하고 배포하는 프런트엔드 조각으로 나눕니다.

주요 통합 전략은 세 가지입니다. 빌드 시점 통합(npm 패키지), 서버 측 통합(엣지 조합), 런타임 통합(Module Federation, iframe, 웹 구성 요소)입니다.

공유 구성 요소를 npm 패키지로 게시합니다. 간단하지만 변경할 때마다 모든 사용자를 다시 릴리스하고 다시 배포해야 하므로 진정한 독립 배포가 아닙니다.

Webpack 5 Module Federation을 사용하면 한 애플리케이션(호스트)이 런타임에 다른 애플리케이션(리모트)의 구성 요소를 로드할 수 있어 진정한 독립 배포가 가능합니다.

최대한의 격리를 위해 iframe에 마이크로 프런트엔드를 삽입합니다. 장점은 CSS와 JS 충돌이 전혀 없다는 것입니다. 단점은 사용자 경험이 좋지 않고(스크롤, 포커스, 크기 조정), 상태를 공유하기 어려우며, 검색 엔진 최적화에 불리하다는 것입니다.

각 마이크로 프런트엔드를 사용자 지정 요소로 감쌉니다. 어떤 프레임워크에서도 작동하고 네이티브 격리를 제공하지만, 컨텍스트 공유와 같은 React 전용 기능은 사용할 수 없습니다.

독립 배포(다른 팀의 사용자 인터페이스를 건드리지 않고 한 팀의 사용자 인터페이스만 배포), 팀의 자율성(각 팀이 자체 기술 스택과 의존성을 선택), 확장성(코드 충돌 없이 팀들이 병렬로 작업)이 가능합니다.

운영 복잡성(더 많은 저장소, 지속적 통합 파이프라인, 배포), 번들 중복(공유하지 않으면 React가 여러 번 로드됨), 성능 오버헤드, 경계를 넘어 발생하는 문제를 디버깅하기 어려운 점이 비용으로 발생합니다.

마이크로 프런트엔드는 여러 대규모 팀이 같은 제품에서 작업하거나, 영역마다 서로 다른 기술 스택이 필요하거나, 각 영역을 완전히 독립적으로 배포해야 할 때 가장 유용합니다.

소규모 팀에서는 오버헤드가 이점보다 크므로 피하세요. 단순한 애플리케이션이나 프런트엔드 전체를 직접 관리할 수 있는 경우에도 피하는 것이 좋습니다. 이런 경우에는 Nx/Turborepo를 사용한 모노레포로 충분한 경우가 많습니다.

통합 전략과 관계없이 공유 디자인 시스템을 사용하면 마이크로 프런트엔드 전체에서 시각적 일관성을 유지할 수 있습니다. 디자인 시스템은 패키지로 게시하거나 Module Federation을 통해 노출할 수 있습니다.

런타임에 마이크로 프런트엔드를 진정으로 독립 배포할 수 있게 하는 통합 방식은 무엇인가요?

마이크로 프런트엔드는 팀의 자율성과 독립 배포를 위해 사용자 인터페이스를 분해합니다. 통합 방법은 간단하지만 독립적이지 않은 npm 패키지부터 런타임에 작동하며 진정한 독립 배포를 지원하는 Module Federation까지 다양합니다. 운영 비용을 고려하세요. 마이크로 프런트엔드는 여러 대규모 팀이 참여하는 제품에 적합하지만, 소규모 프로젝트에는 복잡성을 더합니다.