Micro Frontends의 개념
Micro Frontends는 대규모 프론트엔드 프로젝트를 더 작고, 관리 가능한 부분으로 나누는 접근 방식입니다. 이 개념은 백엔드의 마이크로서비스 아키텍처(MSA)에서 영감을 받았으며, micro-frontends.org에서 자세히 설명되어 있습니다. 이 방식의 핵심은 큰 애플리케이션을 분할하여, 각 팀이 독립적으로 작업할 수 있는 구조를 만드는 것입니다. 이렇게 하면 각 팀은 자신의 기술 스택을 선택하고, 애플리케이션의 특정 부분에 집중할 수 있습니다. 결과적으로, 마이크로 프론트엔드는 개발 효율성을 높이고, 코드베이스의 복잡성을 줄이며, 더 빠른 기능 출시를 가능하게 합니다.
Module Federation 개념 설명
Module Federation은 웹팩(Webpack) 5의 주요 기능 중 하나로, 다른 JavaScript 애플리케이션에서 작성된 코드를 런타임에 동적으로 로드하고 공유할 수 있는 방법을 제공합니다. 이 기능을 사용하면, 서로 다른 프론트엔드 애플리케이션 간에 모듈(컴포넌트, 라이브러리, 함수 등)을 공유할 수 있습니다. 이는 마이크로 프론트엔드 아키텍처를 구현하는 데 필수적인 기술입니다. Module Federation을 사용하면 각 팀이 독립적으로 개발 및 배포할 수 있으며, 전체 애플리케이션은 여전히 일관된 사용자 경험을 제공할 수 있습니다.
Module Federation의 주요 이점
집중화된 문제 해결 및 빠른 배포
MSA로 분리되고 Module Federation을 적용한 구조에서는, 예를 들어 'Account' 서비스에 문제가 발생했을 때 해당 서비스만을 수정하여 전체 시스템의 문제를 해결할 수 있습니다. 이는 문제의 원인을 빠르게 식별하고, 수정된 부분만을 신속하게 배포함으로써 전체 서비스의 가동 중단 시간을 최소화합니다.
책임 소재의 명확화와 책임감 증진
각 서비스가 MSA 방식으로 독립적으로 운영되므로, 문제 발생 시 책임 소재를 명확하게 파악할 수 있습니다. 이는 팀원들이 자신이 맡은 서비스에 대한 책임감을 갖고, 보다 집중적으로 문제를 해결하려는 동기를 부여합니다.
향상된 빌드 성능
전통적인 모노리식 구조와 달리 Module Federation을 사용하면 필요한 컴포넌트만을 동적으로 불러올 수 있습니다. 이는 전체 프로젝트의 빌드 시간을 현저히 줄이며, 따라서 개발 과정이 보다 효율적이고 빠르게 진행됩니다. 결과적으로, 개발자들은 빠른 피드백 루프를 경험하며, 사용자에게도 더 신속하게 기능을 제공할 수 있습니다.
Module Federation 사용 시 주의사항
Module Federation은 마이크로 프론트엔드 아키텍처에서 강력한 도구로 자리 잡았지만, 올바르게 사용하지 않으면 예상치 못한 문제를 초래할 수 있습니다.
1. 모듈 사용의 단방향성 유지
Module Federation을 통해 모듈을 공유할 때는, 모듈의 사용 방향을 명확하게 하나의 방향으로 유지하는 것이 중요합니다. 여러 서비스가 상호 간에 모듈을 가져다 쓰게 되면, 결국 의존성의 복잡성이 증가하여 코드의 가독성과 유지보수성이 떨어지는 '스파게티 코드'를 생성할 위험이 있습니다. 따라서, 모듈은 일반적으로 하위 수준에서 상위 수준으로, 또는 명확하게 정의된 공유 포인트를 통해서만 통행되어야 합니다.
잘못된 사용 예:
상황을 가정해 보면, '사용자 프로필' 모듈이 사용자의 프로필 정보를 표시하는 기능을 가지고 있습니다. 이때, '주문 관리' 모듈도 사용자의 주문 이력 중 일부를 '사용자 프로필' 모듈 내에 직접 표시하려고 합니다. 만약 '주문 관리' 모듈이 '사용자 프로필' 모듈 내의 함수나 컴포넌트를 직접 호출하게 되면, 이 두 모듈 간에 양방향 의존성이 생기게 됩니다. 이는 '사용자 프로필' 모듈을 업데이트할 때 '주문 관리' 모듈에도 영향을 줄 수 있으며, 코드의 복잡성을 증가시키고 유지보수를 어렵게 만듭니다.
올바른 사용 예:
단방향성을 유지하려면, '주문 관리' 모듈은 '사용자 프로필'에 특정 사용자의 주문 이력을 요청하고, '사용자 프로필' 모듈은 해당 데이터를 받아 자신의 UI 내에서 독립적으로 표시합니다. 이 경우, '주문 관리' 모듈은 '사용자 프로필' 모듈에 대한 직접적인 의존성 없이 동작할 수 있으며, 각 모듈은 자신의 기능에만 집중할 수 있습니다. 만약 '사용자 프로필' 모듈이 업데이트되어도, '주문 관리' 모듈은 변경 없이 계속해서 작동합니다. 이렇게 모듈 간의 명확한 인터페이스와 계약을 통해 단방향 의존성을 유지함으로써, 시스템의 견고성을 유지할 수 있습니다.
2. 버전 관리와 의존성 해결
공유 모듈의 버전 관리는 Module Federation을 사용할 때 중대한 과제 중 하나입니다. 버전 충돌이나 호환성 문제를 피하기 위해 yarn resolutions 같은 도구를 활용하여 프로젝트 내에서 사용하는 모든 패키지의 버전을 명시적으로 고정할 수 있습니다. 이를 통해 의존성 문제를 미리 방지하고, 일관된 개발 환경을 유지할 수 있습니다.
3. 성능 최적화 고려
Module Federation을 사용하면 각각의 모듈이 독립적으로 로드되기 때문에, 초기 로드 시간에 영향을 줄 수 있습니다. 네트워크 요청이 증가할 수 있으므로, 모듈의 크기 최적화, 캐싱 전략, 그리고 필요에 따른 레이지 로딩의 구현이 중요합니다. 이는 사용자 경험에 직접적인 영향을 미치므로, 성능과 로드 시간에 대한 면밀한 테스트와 평가가 필요합니다.
4. 명확한 모듈 경계 정의
Module Federation을 사용할 때 각 모듈의 경계를 명확하게 정의하는 것이 중요합니다. 모듈 간의 경계가 모호하거나, 하나의 모듈이 너무 많은 기능을 담당하게 되면, 모듈의 독립성이 저하되고, 재사용성과 유지보수성이 감소합니다. 따라서 각 모듈의 책임과 기능을 명확히 하고, 각각이 독립적으로 기능할 수 있도록 설계해야 합니다.
Module Federation 사용 시 피해야 할 주요 Anti-patterns
Module Federation은 현대 웹 개발에서 흔히 접하는 패러다임의 한계를 극복하도록 설계되었지만, 잘못 사용하면 기대한 이점을 얻기 어렵습니다. 효과적인 사용을 위해 피해야 할 핵심 안티 패턴을 다음과 같이 정리했습니다:
1. 과도한 모듈 공유
마이크로 프론트엔드 환경에서 모든 기능을 공유하려는 시도는 오히려 관리의 복잡성을 증가시킵니다. 각 팀이 자유롭게 모듈을 공유하면 종속성이 뒤얽히고, 결과적으로 시스템 전체의 안정성이 떨어질 수 있습니다. 공유는 필요한 최소한으로 제한하고, 모듈은 명확하고 단순한 계약에 의해 공유되어야 합니다.
2. 무분별한 종속성 포함
개별 마이크로 프론트엔드 애플리케이션의 과도한 외부 종속성 포함은 충돌과 복잡성을 초래합니다. 필수적인 라이브러리만을 포함하고, 가능하다면 피어 의존성(peer dependencies)을 활용하여 모듈 간의 충돌을 방지하는 것이 중요합니다.
3. 비동기 로딩 관리 실패
Module Federation을 사용하면 모듈 로딩 실패나 지연이 발생할 수 있습니다. 이러한 문제를 적절히 관리하지 않으면 사용자 경험이 저하될 수 있습니다. 비동기 모듈 로딩에 대한 견고한 에러 핸들링과 상태 관리 전략이 필수적입니다.
참고 글
- https://micro-frontends.org/
- https://martinfowler.com/articles/micro-frontends.html
'Frontend > Module Federation' 카테고리의 다른 글
Module Federation을 위한 안전한 React 컴포넌트 로더 구현하기 (0) | 2024.11.24 |
---|---|
BroadcastChannel API란? (2) | 2024.11.10 |