대형 웹 애플리케이션 Micro Frontends 전환기

1. 마이크로 프론트엔드 아키텍처의 개념과 통합 방식

마이크로 프론트엔드는 단일 대형 앱을 팀별로 독립 개발·배포 가능한 여러 앱으로 분리하는 아키텍처입니다. 통합 방식 세 가지: (1) 런타임 통합(Module Federation) — 브라우저에서 실시간으로 원격 모듈 로드, (2) 빌드 타임 통합 — npm 패키지로 배포해 빌드 시 합침, (3) iframe — 가장 격리되지만 UX·통신 제약. 토스/flex 같은 대형 앱에서는 독립 배포가 핵심이므로 런타임 통합이 가장 적합합니다.

핵심 용어

2. Webpack Module Federation 설정

Module Federation은 Host(Shell)와 Remote(마이크로 앱) 관계로 구성됩니다. Remote의 webpack.config에서 `exposes`로 외부에 노출할 모듈을 정의하고, Host에서 `remotes`로 Remote URL을 지정합니다. `shared` 설정이 핵심: React 같은 공통 라이브러리를 shared에 등록하면 중복 로드를 방지합니다. 주의: 버전이 다를 경우 `singleton: true`로 하나의 인스턴스만 사용하도록 강제하지 않으면 React 컨텍스트가 공유되지 않는 문제가 발생합니다.

핵심 용어

3. 점진적 마이그레이션 전략

기존 대형 앱을 한 번에 전환하지 않고 점진적으로 마이그레이션하는 전략입니다. Strangler Fig 패턴: 기존 앱을 점진적으로 새 아키텍처로 교체하되, 전환 중에도 서비스가 중단되지 않도록 합니다. 효과적인 순서: (1) 가장 독립성이 높은 모듈부터 분리, (2) 새 기능은 새 아키텍처로 개발, (3) 기존 기능은 변경이 필요할 때 마이그레이션. PoC로 기술 검증 후 팀에 수치로 성과를 보여주는 과정이 중요합니다.

핵심 용어

4. MFE에서의 공유 상태와 인증 처리

여러 마이크로 앱이 사용자 인증 정보를 공유해야 할 때 문제가 발생합니다. 해결 전략: (1) 인증 토큰은 localStorage/쿠키로 공유 — 가장 단순하지만 보안 주의 필요, (2) 인증 서비스를 Shell App에서 관리하고 마이크로 앱에 prop/context로 전달, (3) BFF(Backend for Frontend) 패턴으로 게이트웨이에서 인증 처리. 전역 상태(Redux, Zustand)는 Module Federation의 shared 설정으로 인스턴스를 공유할 수 있지만, 이는 독립성을 해치므로 최소화해야 합니다.

핵심 용어

Q1. 마이크로 프론트엔드 아키텍처를 도입하면 어떤 문제를 해결할 수 있고 어떤 비용이 발생하나요?

힌트

[감점 답변] 정의만 반복하거나 "마이크로 프론트엔드 아키텍처를 도입하면 어떤 문제를 해결할 수 있고 어떤 비용이 발생하나요?"에 대해 장단점 없이 단편적으로 답하면 감점 포인트입니다. 면접관은 실무 적용 경험이 부족하다고 판단합니다. [좋은 답변] 해결 문제: 팀별 독립 배포(배포 결합 제거), 빌드 속도 개선, 기술 스택 자율성을 설명하세요. 발생 비용: 네트워크 오버헤드(remoteEntry.js 추가 로드), 공유 상태 관리 복잡도, Shell/Remote 간 통신 설계 비용, 팀 간 인터페이스 합의 비용을 언급하세요. 언제 MFE가 적합한지(팀이 크고 배포 충돌이 잦을 때)와 적합하지 않은지(소규모 팀, 초기 스타트업)도 설명하면 좋습니다.

Q2. Module Federation에서 shared 설정을 하는 이유와 버전 충돌이 발생하면 어떻게 처리하나요?

힌트

[감점 답변] 정의만 반복하거나 "Module Federation에서 shared 설정을 하는 이유와 버전 충돌이 발생하면 어떻게 처리하나요?"에 대해 장단점 없이 단편적으로 답하면 감점 포인트입니다. 면접관은 실무 적용 경험이 부족하다고 판단합니다. [좋은 답변] shared 없이 React를 Host와 Remote 각각 번들하면 두 개의 React 인스턴스가 생겨 Context, Hooks가 동작하지 않는다고 설명하세요. 버전 충돌 해결: `singleton: true`로 하나의 인스턴스만 사용하도록 강제, `requiredVersion`으로 허용 버전 범위 지정. 단, singleton은 버전이 다를 경우 런타임 경고가 발생하므로 버전을 맞추는 것이 근본 해결책임을 언급하면 됩니다.

Q3. 대규모 레거시 앱을 마이크로 프론트엔드로 전환할 때 어떤 전략으로 접근하시겠어요?

힌트

[감점 답변] 정의만 반복하거나 "대규모 레거시 앱을 마이크로 프론트엔드로 전환할 때 어떤 전략으로 접근하시겠어요?"에 대해 장단점 없이 단편적으로 답하면 감점 포인트입니다. 면접관은 실무 적용 경험이 부족하다고 판단합니다. [좋은 답변] Strangler Fig 패턴을 중심으로 설명하세요: 기존 앱은 건드리지 않고 새 기능부터 새 아키텍처로 개발 → 기존 기능은 수정 필요 시 점진적 전환. PoC로 기술 검증 후 수치(빌드 시간, 배포 빈도)로 팀 설득 → 가장 독립성 높은 모듈부터 분리 → 롤백 계획 준비 순서로 설명하면 체계적인 답변이 됩니다.

Q4. 마이크로 앱들이 공통으로 사용하는 디자인 시스템을 어떻게 공유하나요?

힌트

[감점 답변] 정의만 반복하거나 "마이크로 앱들이 공통으로 사용하는 디자인 시스템을 어떻게 공유하나요?"에 대해 장단점 없이 단편적으로 답하면 감점 포인트입니다. 면접관은 실무 적용 경험이 부족하다고 판단합니다. [좋은 답변] 두 가지 방법을 비교하세요: (1) npm 패키지로 배포 — 버전 관리 명확, 변경 시 각 앱이 직접 업데이트 필요, (2) Module Federation으로 런타임 공유 — 항상 최신 버전 사용, 하지만 디자인 시스템 변경이 모든 앱에 즉시 영향. 실무에서는 디자인 시스템은 npm 패키지로 안정적으로 관리하는 것이 일반적임을 언급하면 됩니다.

Q5. 마이크로 프론트엔드 환경에서 E2E 테스트를 어떻게 구성하나요?

힌트

[감점 답변] 정의만 반복하거나 "마이크로 프론트엔드 환경에서 E2E 테스트를 어떻게 구성하나요?"에 대해 장단점 없이 단편적으로 답하면 감점 포인트입니다. 면접관은 실무 적용 경험이 부족하다고 판단합니다. [좋은 답변] 두 레벨의 테스트를 설명하세요: (1) 각 마이크로 앱 단위 테스트 — 독립적으로 실행 가능, (2) Shell App에서의 통합 E2E — 실제 사용자 흐름을 전체 시스템으로 테스트. 개발 환경에서 로컬 Remote를 연결하는 방법(로컬 포트 지정)과 CI에서 각 Remote를 스테이징 URL로 테스트하는 방법도 언급하면 실무 이해도를 어필할 수 있습니다.