GPT에게 물어본 MFE 꿀팁 정리

JACKJACK·2025년 8월 7일
post-thumbnail

🌐 Micro Frontend에서 서브도메인 전략을 사용하는 이유와 실전 팁

Micro Frontend(MFE) 구조를 도입한 대기업 대부분은 서브도메인 전략을 선택한다. 단순히 도메인을 나누는 차원을 넘어, CORS/CSP 관리, 캐시 이슈, 에러 분리, 리소스 경로 문제 해결까지 여러 문제를 동시에 해결할 수 있기 때문.

CORS 문제를 구조적으로 해결할 수 있다

도메인이 완전히 다르면, CORS 설정을 N:M으로 반복해서 추가해야 한다.

서브도메인을 쓰면 *.company.com 범위 내에서 통일된 CORS 설정이 가능하다.

Access-Control-Allow-Origin: https://*.company.com

CSP(Content-Security-Policy) 설정이 훨씬 간단해진다

보안을 위해 CSP를 강하게 설정하려면 script-src에 각 도메인을 명시해야 한다.
MFE를 고정된 서브도메인에 배치하면 CSP도 예측 가능하게 관리할 수 있다.

Content-Security-Policy: script-src 'self' https://login.company.com https://main.company.com;

도메인 구조 예시

앱 기능서브도메인
메인 호스트https://app.company.com
로그인 MFEhttps://login.company.com
마이페이지 MFEhttps://mypage.company.com
상품 리스트 MFEhttps://products.company.com

🔁 remoteEntry.js 캐싱 이슈와 버전 관리

  • 문제
    remoteEntry.js가 브라우저에 캐시되어 변경 사항이 반영되지 않는 문제가 발생한다. 이로 인해 모듈 불일치 오류가 생기고 앱이 깨질 수 있다.
  • 해결
    쿼리 파라미터 또는 해시를 활용해 버전 캐싱을 통제한다.
remotes: {
  mfeA: "mfeA@https://mfe-a.company.com/remoteEntry.js?v=20250630"
}

🔗 공유 라이브러리는 singleton으로 고정해야 한다

React나 ReactDOM을 각 앱에서 별도로 로드하면 다음 문제가 발생한다.

  • Context 깨짐
  • Hook 동작 오류
  • Portal 기능 비정상
shared: {
  react: { singleton: true, requiredVersion: '^18.2.0' },
  'react-dom': { singleton: true, requiredVersion: '^18.2.0' },
}

🖇공유 설정을 따로 관리하고 싶다면?

모노레포가 아니라면 shared-mf-config 같은 패키지를 만들어 사내 NPM 레지스트리로 배포한다. 각 앱은 해당 패키지를 의존성으로 설치해 공유 설정을 통일할 수 있다.

// shared-mf-config/shared.js
module.exports = {
  react: {
    singleton: true,
    requiredVersion: '^18.2.0',
  },
  'react-dom': {
    singleton: true,
    requiredVersion: '^18.2.0',
  },
};

⚠️ MFE 로딩 실패가 전체 앱을 깨지 않도록 방어해야 한다

remoteEntry.js가 로딩 실패하면 앱 전체가 하얗게 죽는 경우가 많다.
-> MFE 단위로 ErrorBoundary를 적용해 방어 로직을 추가한다

<ErrorBoundary fallback={<div>⚠️ 모듈 로딩 실패</div>}>
  <RemoteMfeComponent />
</ErrorBoundary>

🔄 리소스 경로 꼬임 방지

MFE 내부에서 리소스 상대 경로가 꼬이면 요청 실패가 발생한다. 브라우저 기준이 아닌 실제 배포 위치를 기준으로 경로를 설정해야 한다.

  • Webpack 설정
output: {
  publicPath: 'auto'
}
  • Vite 기준
const base = new URL(import.meta.url).origin;
fetch(`${base}/api/survey`);

🩺 remoteEntry.js 헬스체크는 필수이다.

MFE는 다른 팀에서 관리하거나 CDN에 올라가 있다. remoteEntry.js가 죽어 있으면 앱은 실패한다. CI/CD에서 사전 체크를 넣어야 한다. Slack, Email 등 알림 시스템과 연동하면 실패 시 빠르게 대응할 수 있다.

  • Jenkins 파이프라인 예시
stage('RemoteEntry.js Health Check') {
  steps {
    script {
      def remoteEntryUrl = 'https://remote-app.com/assets/remoteEntry.js'

      def response = sh(
        script: "curl -o /dev/null -s -w \"%{http_code}\" ${remoteEntryUrl}",
        returnStdout: true
      ).trim()

      if (response != '200') {
        error("remoteEntry.js 헬스체크 실패! HTTP 상태 코드: ${response}")
      } else {
        echo "remoteEntry.js 헬스체크 성공! HTTP 상태 코드: ${response}")
      }
    }
  }
}

✅ 결론

서브도메인 전략은 단순한 구조 분리를 넘어서, 보안, 운영 편의성, 캐시 관리, 장애 방어까지 한 번에 해결할 수 있는 강력한 접근 방식이다. Micro Frontend 구조를 도입한다면, 서브도메인 전략을 적극적으로 검토해야 한다.

profile
러닝커브를 빠르게 극복하자🎢

0개의 댓글