FE 아키텍처 변경과 이유 with 셸 앱(Sheel App)

기존에는 Vue3와 Next를 같이 사용해서 프론트엔드 MSA를 구현하려고 했다.

사실 Next로 프로젝트를 하는 것이 주 목표였고, Vue3는 부가적으로 가져가는 것이 목표였다.

백엔드를 다 만들고 나서 프론트엔드를 생각해 보는데, 문득 어떻게 구현을 해야 할지를 생각해 봤다.

Vue와 React를 합친 MSA는 셸 앱(Shell App)으로 구현이 가능하다고 한다.

하지만 Next는 좀 다르다. 그 이유를 아래에서 설명해 보겠다.

셸 앱(Shell App)이란?

셸 앱은 마이크로 프론트엔드 아키텍처의 '뼈대' 또는 '컨테이너' 역할을 하는 핵심 애플리케이션이다.

 

가장 쉬운 비유는 스마트폰의 홈 화면

• 셸 앱 (Shell App) = 스마트폰 홈 화면: 상단 상태 바, 하단 독(Dock)처럼 항상 고정되어 보이는 공통 UI를 가지고 있다.
• 마이크로 앱 (Micro App) = 개별 앱 아이콘: 사용자가 특정 앱 아이콘을 누르면, 홈 화면의 메인 영역에 해당 앱이 실행된다. 다른 앱을 실행하면 이전 앱은 사라지고 그 자리에 새로운 앱이 나타난다.

이처럼 셸 앱은 전체 애플리케이션의 기본 틀을 잡고, URL이나 사용자 행동에 따라 필요한 마이크로 앱을 '불러와서' 지정된 공간에 '끼워 넣는' 역할

셸 앱의 핵심 책임

• 공통 레이아웃 렌더링: 헤더, 푸터, 네비게이션 메뉴 등 공통 영역을 렌더링하고 유지
• 라우팅 (Routing): URL을 해석하여 어떤 마이크로 앱을 보여줘야 할지 결정하는 '교통정리' 역할
• 인증 및 전역 상태 관리: 로그인 상태, 인증 토큰 등 모든 마이크로 앱이 공유해야 하는 전역 상태를 중앙에서 관리
• 마이크로 앱 로딩 및 생명주기 관리: 필요한 마이크로 앱을 동적으로 불러오고(Lazy Loading), 화면에 렌더링(Mount) 및 제거(Unmount)하는 전체 생명주기를 책임

MFE 역할에 Vue/React가 적합하고 Next.js가 부적합한 이유

결론부터 말하면, Vue/React는 부품(라이브러리)으로 설계되었고, Next.js는 완성된 자동차(프레임워크)로 설계되었기 때문이다.

마이크로 프론트엔드는 여러 개의 '부품'을 하나의 '자동차(셸 앱)'에 조립하는 방식이므로, Vue/React가 그 역할에 훨씬 적합하다.

Vue / React (라이브러리)

• 설계 철학: Vue와 React의 핵심은 UI를 렌더링하는 '뷰(View) 라이브러리'입니다. 이들은 스스로 완전한 애플리케이션이 되려고 하지 않습니다. 라우팅, 상태 관리 등은 개발자가 다른 라이브러리를 선택하여 조립해야 한다.
• 역할: 이들의 역할은 명확하다. "데이터를 주면, 화면의 특정 부분을 그려주는 것"입니다. 마치 자동차의 '엔진'처럼, 하나의 기능에 집중한다.
• MFE 적합도: 이러한 특징 덕분에 Vue/React로 만든 앱은 독립적인 '부품'이 되기 매우 쉽다. 셸 앱이 "이 <div> 안에 너 자신을 그려줘"라고 명령하면, Vue/React 앱은 그저 자신의 역할에 맞게 UI를 렌더링 해주면 그만이다. 셸 앱의 통제에 순응하기 좋은 구조이다.

Next.js (프레임워크)

• 설계 철학: Next.js는 단순한 뷰 라이브러리가 아니라, 자체 서버, 파일 기반 라우팅 시스템, 서버 사이드 렌더링(SSR) 기능까지 모두 내장한 풀스택 프레임워크이다.
• 역할: Next.js는 스스로가 '완성된 자동차'가 되도록 설계되었다. 자체적인 규칙과 생명주기를 가지고 전체 애플리케이션을 지배하려고 한다.
• MFE 적합도: '완성된 자동차(Next.js)'를 다른 '완성된 자동차(셸 앱)' 안에 넣으려고 하면 충돌이 발생한다.
  • 라우터 충돌: 셸 앱의 라우터와 Next.js의 라우터 중 누가 URL을 통제해야 할까?
  • 서버 충돌: 셸 앱의 서버와 Next.js의 서버는 어떻게 연동해야 할까? SSR 결과물은 누가 만들어서 합쳐야 할까?
  • 이처럼 Next.js는 스스로가 '주인'이 되려는 성격이 강해서, 다른 앱의 '부품'으로 들어가기에는 너무 무겁고 복잡하며 많은 문제를 일으킨다.