Skip to main content

Chapter 1. Module Federation 개요와 도입 판단 기준

1. Module Federation이란​

Module Federation은 서로 다른 프론트엔드 애플리케이션이 런타임에 다른 애플리케이션의 모듈을 동적으로 불러와 사용하는 방식

  • 기존처럼 하나의 애플리케이션을 빌드할 때 모든 코드를 미리 묶는 것이 아니라,
  • 배포가 끝난 뒤에도 필요한 모듈을 조합할 수 있다는 점이 핵심
  • 즉, 어떤 애플리케이션은 자신의 기능만 배포하고, 다른 애플리케이션은 그 기능을 원격 모듈(remote module) 형태로 가져와 실행할 수 있다.
  • 이 구조에서는 각 애플리케이션이 완전히 하나의 번들로 고정되지 않고, 실행 시점에 연결된다.

2. 왜 사용하는가​

2.1 독립 배포​

Module Federation의 가장 큰 장점은 독립 배포다. 특정 기능을 수정했다고 해서 전체 프론트엔드를 다시 빌드하고 재배포할 필요가 없다. 해당 기능을 담당하는 애플리케이션만 배포하면 되고, 이를 사용하는 쪽은 런타임에 최신 버전을 불러올 수 있다.

이 구조는 배포 속도를 높이고, 장애 영향 범위를 줄이며, 릴리스 주기를 팀별로 유연하게 운영할 수 있게 해준다.

2.2 팀 간 개발 분리​

대규모 조직에서는 하나의 프론트엔드 저장소와 배포 파이프라인을 여러 팀이 공유할수록 충돌이 많아진다. Module Federation은 기능 단위를 기준으로 애플리케이션 경계를 나누기 때문에, 각 팀이 서로의 코드베이스에 과도하게 의존하지 않고 병렬 개발할 수 있다.

이때 팀은 자신이 소유한 도메인에 대해 기술 선택, 배포 일정, 품질 관리 책임을 더 명확하게 가져갈 수 있다.

2.3 대규모 프론트엔드의 확장성​

서비스가 커질수록 하나의 프론트엔드 애플리케이션 안에 모든 기능을 담는 구조는 점점 비대해진다. 코드베이스가 커지고, 빌드 시간이 늘어나며, 작은 변경도 전체 서비스에 영향을 줄 수 있다.

Module Federation은 이러한 문제를 완화한다. 기능별로 애플리케이션을 나누고, 필요한 시점에만 가져와서 실행함으로써 구조적 확장성을 확보할 수 있다.

2.4 공통 기능 재사용​

헤더, 푸터, 공통 UI, 인증, 권한 처리, 디자인 시스템과 같은 기능은 여러 서비스에서 반복적으로 사용된다. Module Federation을 활용하면 이러한 공통 기능을 하나의 애플리케이션 또는 모듈로 제공하고, 여러 소비 애플리케이션이 이를 재사용할 수 있다.

다만 단순 재사용만을 목적으로 도입하기보다는, 독립 배포와 팀 분리라는 구조적 요구가 함께 있을 때 더 큰 효과를 얻는다.

3. 언제 적합한가​

3.1 여러 팀이 같은 서비스 또는 플랫폼을 나눠 개발하는 경우​

여러 팀이 하나의 사용자 경험 안에서 서로 다른 기능을 맡고 있다면 Module Federation은 매우 유효하다. 예를 들어 검색, 주문, 결제, 마이페이지를 서로 다른 팀이 담당한다면, 각 도메인을 독립적으로 운영하면서도 하나의 서비스처럼 연결할 수 있다.

3.2 특정 도메인을 독립 배포해야 하는 경우​

어떤 기능은 변경 주기가 빠르거나, 장애 대응이 민감하거나, 실험이 자주 필요하다. 이런 도메인은 전체 프론트엔드와 분리해 자체 배포 단위로 가져가는 것이 유리하다. Module Federation은 이러한 요구에 잘 맞는다.

3.3 점진적 마이그레이션이 필요한 경우​

레거시 프론트엔드를 한 번에 모두 교체하기 어려운 상황도 많다. 이때 기존 애플리케이션 위에 새로운 기능을 점진적으로 올리거나, 일부 영역만 신규 스택으로 이전하는 방식이 필요하다.

Module Federation은 기존 시스템을 유지하면서도 새로 만든 영역을 런타임에 연결할 수 있으므로, 단계적 전환 전략에 적합하다.

4. 언제 부적합한가​

4.1 서비스 규모가 작고 배포 단위가 단순한 경우​

작은 규모의 서비스에서는 Module Federation이 주는 이점보다 운영 복잡도가 더 클 수 있다. 팀도 적고 배포 주기도 단순하다면, 하나의 프론트엔드 애플리케이션으로 관리하는 편이 더 효율적이다.

4.2 런타임 복잡도를 감당할 필요가 없는 경우​

Module Federation은 런타임에 원격 모듈을 불러오므로, 네트워크 의존성, 버전 호환성, 장애 전파, 로딩 전략 등 추가 고려 사항이 생긴다. 이런 복잡도를 해결할 만큼의 조직적·기술적 필요가 없다면 굳이 도입할 이유가 약하다.

4.3 조직 구조상 독립 운영 이점이 크지 않은 경우​

기술 구조는 조직 구조와 맞물린다. 실제로는 하나의 팀이 전체 프론트엔드를 관리하고 있고, 기능 간 소유권도 명확히 나뉘지 않는다면 Module Federation의 효과는 제한적이다. 이 경우 오히려 관리 포인트만 늘어날 수 있다.

5. 기존 방식과의 차이​

5.1 모놀리식 프론트엔드와의 차이​

모놀리식 프론트엔드는 모든 기능이 하나의 코드베이스와 하나의 빌드 결과물 안에 포함된다. 구조가 단순하고 초기 개발 속도가 빠르지만, 규모가 커질수록 빌드와 배포, 협업 비용이 증가한다.

반면 Module Federation은 기능을 분리된 애플리케이션 단위로 나누고, 이를 런타임에 조합한다. 즉, 모놀리식은 빌드 시점 통합, Module Federation은 실행 시점 통합이라는 차이가 있다.

5.2 iframe 기반 분리와의 차이​

iframe은 가장 강한 분리 방식을 제공한다. 각 화면이 완전히 독립된 문서와 실행 환경을 가지므로 충돌이 적다. 하지만 스타일 일관성 유지, 라우팅 통합, 상태 공유, 자연스러운 사용자 경험 측면에서는 제약이 많다.

Module Federation은 iframe보다 훨씬 자연스럽게 하나의 애플리케이션처럼 통합할 수 있다. DOM, 라우팅, 상태, 공통 라이브러리 공유 전략을 더 유연하게 가져갈 수 있다는 점에서 더 긴밀한 통합 방식에 가깝다.

5.3 CDN/S3 스크립트 위젯 로딩 방식과의 차이​

전통적인 위젯 로딩 방식은 외부 스크립트를 CDN이나 S3에서 내려받아 페이지에 삽입하는 구조다. 간단한 배너, 챗봇, 추천 위젯처럼 특정 기능을 삽입하는 데는 유용하지만, 애플리케이션 수준의 의존성 관리나 모듈 공유에는 한계가 있다.

Module Federation은 단순히 스크립트를 삽입하는 수준이 아니라, 모듈 단위의 의존성과 공유 라이브러리를 고려하면서 통합할 수 있다는 점에서 더 체계적이다. 즉, 위젯 로딩이 “스크립트 포함”에 가깝다면, Module Federation은 “애플리케이션 간 모듈 연합”에 가깝다.

6. Micro-Frontend 전체 개념 안에서의 위치​

Micro-Frontend는 프론트엔드를 작은 단위로 나누어 개발·배포·운영하는 아키텍처 전반을 뜻한다. Module Federation은 그중 하나의 구현 방식이다.

즉, Micro-Frontend는 상위 개념, Module Federation은 이를 구현하는 구체적인 기술 전략 중 하나라고 볼 수 있다.

Micro-Frontend를 구현하는 방식은 여러 가지가 있다. 예를 들어 iframe 기반 통합, 라우팅 기반 통합, 서버 조합, 스크립트 위젯 삽입 같은 방식도 모두 가능하다. Module Federation은 이들 중에서 런타임 모듈 공유와 독립 배포를 동시에 지원하는 현대적인 접근에 해당한다.

따라서 Micro-Frontend를 검토한다고 해서 반드시 Module Federation을 써야 하는 것은 아니다. 반대로 Module Federation을 검토할 때도 단순히 기술 기능만 볼 것이 아니라, 조직 구조, 배포 전략, 팀 경계, 운영 복잡도까지 함께 판단해야 한다.

7. 도입 판단 기준 요약​

다음 질문에 “예”가 많을수록 Module Federation 도입 적합성이 높다.

질문판단 포인트
여러 팀이 하나의 플랫폼을 나눠 개발하는가?팀 단위 분리 필요성
도메인별로 배포 주기가 다른가?독립 배포 필요성
특정 기능을 자주 개선하거나 실험하는가?빠른 릴리스 필요성
레거시에서 점진적으로 이전해야 하는가?점진적 마이그레이션 필요성
공통 기능을 여러 앱에서 재사용해야 하는가?재사용성과 공유 전략

반대로 아래 조건이 많다면 신중해야 한다.

질문판단 포인트
서비스가 작고 단일 팀이 운영하는가?과도한 구조 도입 가능성
배포 파이프라인이 단순하고 문제없나?독립 배포 필요성 부족
런타임 로딩, 버전 호환, 장애 대응 복잡도를 감당할 이유가 적은가?운영 비용 증가 가능성
기능 소유권이 팀별로 명확하지 않은가?조직 구조와의 불일치

8. 정리​

Module Federation은 프론트엔드 애플리케이션을 런타임에 조합할 수 있게 해주는 기술이며, 특히 독립 배포, 팀 간 개발 분리, 대규모 서비스 확장성, 점진적 마이그레이션이 필요한 환경에서 강력한 선택지가 된다.

하지만 모든 프로젝트에 적합한 것은 아니다. 작은 규모의 서비스나 단순한 조직 구조에서는 오히려 복잡도만 늘어날 수 있다. 따라서 도입 여부는 기술 자체보다도 조직 구조, 배포 전략, 서비스 규모, 운영 방식을 함께 보고 판단해야 한다.

원하면 다음 단계로 이어서 Chapter 2. Module Federation 핵심 개념(Host, Remote, Shared, Runtime) 형태로 바로 정리해주겠다.