테마
마이크로프론트엔드 핵심 원칙과 서비스 분리
마이크로프론트엔드의 두 가지 핵심 정의를 이해하고, 서비스를 효과적으로 분리하는 3가지 전략을 학습한다.
학습 목표
- 마이크로프론트엔드 정의의 두 가지 핵심 요소를 명확히 이해한다
- 독립적 배포가 왜 가장 중요한 원칙인지 파악한다
- 엔드투엔드 팀과 콘웨이의 법칙의 관계를 이해한다
- 서비스 분리를 위한 3가지 전략을 구체적으로 학습하고 적용할 수 있다
Part A. 핵심 원칙
마이크로프론트엔드 정의의 두 가지 핵심
마이크로프론트엔드는 단순히 "프론트엔드를 작게 쪼개는 것"이 아니다. 정의에는 두 가지 핵심 요소가 동시에 존재한다.
이 두 핵심은 서로 긴장 관계에 있다. 핵심 1은 분리와 독립성을 강조하고, 핵심 2는 통합과 일체감을 강조한다. 마이크로프론트엔드의 성공은 이 두 가지를 동시에 달성하는 데 있다. 분리만 하고 통합을 소홀히 하면 사용자 경험이 파편화되고, 통합만 강조하면 독립적 배포의 이점을 잃게 된다.
독립적 배포: 가장 중요한 핵심 원칙
두 가지 핵심 중에서도 독립적 배포가 마이크로프론트엔드의 가장 핵심적인 가치다. 독립적 배포가 가능하려면 다음 세 단계가 모두 독립적이어야 한다.
독립적 코드베이스: 각 마이크로앱이 자체 저장소(또는 모노레포 내 독립 패키지)를 가진다. 다른 마이크로앱의 소스 코드를 직접 참조하지 않으며, 공유가 필요한 부분은 별도의 패키지로 추출한다.
독립적 빌드 파이프라인: 각 마이크로앱이 자체 CI/CD 파이프라인을 가진다. 마이크로앱 A를 빌드할 때 마이크로앱 B의 빌드 결과물이 필요하지 않다. 빌드가 실패해도 다른 마이크로앱의 빌드에 영향을 주지 않는다.
독립적 프로덕션 배포: 마이크로앱 A의 새 버전을 프로덕션에 배포할 때, 마이크로앱 B를 함께 배포할 필요가 없다. 각 마이크로앱은 자체 배포 주기와 일정을 가진다.
빌드타임 조합은 MFE가 아닐 수 있다
여기서 중요한 구분이 하나 있다. 만약 여러 마이크로앱을 빌드타임에 합쳐서 하나의 번들로 만든 후 프로덕션에 배포한다면, 이것은 엄밀히 마이크로프론트엔드라고 보기 어렵다는 관점이 있다.
| 구분 | 빌드타임 조합 | 런타임 조합 |
|---|---|---|
| 합치는 시점 | 빌드 시 (npm install, 번들링) | 실행 시 (브라우저 로드) |
| 배포 단위 | 전체 앱 하나 | 마이크로앱 각각 |
| 배포 독립성 | 낮음 (전체 재빌드 필요) | 높음 (개별 배포 가능) |
| MFE 해당 여부 | 논란 있음 | 명확한 MFE |
빌드타임 조합은 npm 패키지 형태로 마이크로앱을 관리하는 방식이다. 코드 분리와 팀 자율성의 이점은 얻을 수 있지만, 최종 배포를 위해서는 전체 앱을 다시 빌드해야 하므로 독립적 배포라는 핵심 원칙이 약화된다. 물론 이 방식도 가치가 있지만, 마이크로프론트엔드의 핵심 이점을 최대로 누리려면 런타임 조합을 지향해야 한다.
"하나의 커다란 앱처럼 동작하느냐"가 기준
마이크로앱을 합치는 방식은 다양하다: Module Federation, iframe, Web Components, 서버사이드 인클루드, 클라이언트사이드 라우팅 등. 어떤 방식을 사용하든 핵심 질문은 하나다.
"사용자가 하나의 커다란 앱을 사용하는 것처럼 느끼는가?"
페이지 전환 시 전체 새로고침이 발생하거나, 영역마다 스타일이 확연히 다르거나, 마이크로앱 간 상태가 공유되지 않아 같은 정보를 반복 입력해야 한다면, 이는 마이크로프론트엔드라 부르기 어렵다. 기술적으로 분리되어 있더라도 사용자 경험 측면에서 하나의 앱처럼 매끄럽게 동작해야 한다.
엔드투엔드 팀과 콘웨이의 법칙
마이크로프론트엔드는 기술적 아키텍처만의 문제가 아니다. 조직 구조와 밀접하게 연결된다.
콘웨이의 법칙(Conway's Law): "소프트웨어의 구조는 그것을 만드는 조직의 커뮤니케이션 구조를 반영한다." 프론트엔드 팀, 백엔드 팀, DBA 팀으로 나뉜 조직은 자연스럽게 프론트엔드-백엔드-데이터베이스로 분리된 3-tier 아키텍처를 만든다.
마이크로프론트엔드가 제대로 작동하려면 엔드투엔드(End-to-End) 팀 구조가 필요하다. 하나의 기능 영역(도메인)에 대해 프론트엔드, 백엔드, 데이터, 디자인, QA를 모두 갖춘 팀이 전체 기능을 독립적으로 완성할 수 있어야 한다.
현실적 과도기
그러나 현실에서 기존 조직을 단번에 엔드투엔드 팀으로 전환하기는 어렵다. 대부분의 조직은 과도기를 거친다.
- 1단계: 기존 프론트엔드 팀 내에서 도메인별 담당을 나눔
- 2단계: 도메인별 담당자 + 해당 백엔드 담당자가 가상 팀(virtual team)을 구성
- 3단계: 가상 팀이 공식적인 크로스펑셔널 팀으로 전환
- 4단계: 각 팀이 자체 BFF(Backend For Frontend)를 운영
BFF 패턴: 각 마이크로프론트엔드 팀이 자체 BFF를 가지면, 프론트엔드에 최적화된 API를 직접 설계하고 운영할 수 있다. 범용 백엔드 API에 의존하지 않으므로 팀 간 조율 비용이 줄어든다.
Part B. 서비스 분리 전략
마이크로프론트엔드의 핵심 원칙을 이해했다면, 다음 질문은 "어떻게 서비스를 분리할 것인가"이다. 하나의 큰 프론트엔드를 어떤 기준으로 마이크로앱으로 나눌 것인지에 대한 3가지 전략을 살펴본다.
전략 1: 페이지 구조를 통한 분리
가장 직관적이고 실행하기 쉬운 전략이다. 서비스의 모든 페이지 경로를 나열하고, 유형별로 팀에 배정한다.
적용 절차
1단계 - 모든 페이지 경로를 리스트업한다:
/ → 메인 홈
/products → 상품 목록
/products/:id → 상품 상세
/cart → 장바구니
/checkout → 결제
/checkout/complete → 결제 완료
/mypage → 마이페이지
/mypage/orders → 주문 내역
/mypage/profile → 프로필 설정
/admin/products → 상품 관리
/admin/orders → 주문 관리
/admin/users → 사용자 관리2단계 - 유형별로 분류하고 팀에 배정한다:
| 팀 | 마이크로앱 | 담당 페이지 |
|---|---|---|
| 팀 카탈로그 | 상품 앱 | /products, /products/:id |
| 팀 커머스 | 구매 앱 | /cart, /checkout, /checkout/complete |
| 팀 고객 | 마이페이지 앱 | /mypage, /mypage/orders, /mypage/profile |
| 팀 운영 | 관리자 앱 | /admin/* |
| 플랫폼 팀 | 앱쉘 | / (홈), 글로벌 네비게이션, 인증 |
3단계 - 한 페이지 내에 여러 목적이 있으면 프래그먼트로 분리한다:
예를 들어 상품 상세 페이지(/products/:id)에 상품 정보와 함께 추천 상품, 리뷰, 장바구니 담기 버튼이 있다면, 상품 정보는 팀 카탈로그가, 장바구니 담기 기능은 팀 커머스가 프래그먼트 형태로 제공할 수 있다.
이 그림에서 핵심 개념인 **프래그먼트(Fragment)**가 등장한다. 프래그먼트는 한 팀이 소유하면서 다른 팀의 페이지에 런타임으로 삽입되는 코드 조각이다. 페이지의 주인은 팀 카탈로그지만, 장바구니 버튼이라는 프래그먼트는 팀 커머스가 소유하고 독립적으로 배포한다.
전략 2: 고객 요구사항 중심 분리
페이지 구조가 아닌, 사용자가 서비스에서 달성하려는 목적(미션) 을 기준으로 분리하는 전략이다. 각 팀에 명확한 미션을 부여하고, 그 미션에 필요한 페이지와 프래그먼트를 배정한다.
팀 미션 기반 분리 예시
전자상거래 서비스를 예로 들면 다음과 같다.
팀 인스파이어(Inspire): "사용자가 새로운 상품을 발견하고 영감을 얻게 한다"
- 담당: 홈 페이지, 카테고리 탐색, 추천 상품, 검색 결과, 프로모션 배너
- 핵심 지표: 탐색 깊이, 체류 시간, 상품 클릭률
팀 디사이드(Decide): "사용자가 구매 결정을 내리도록 돕는다"
- 담당: 상품 상세, 리뷰, 비교, 위시리스트, 재고 정보
- 핵심 지표: 상세 페이지 전환율, 장바구니 추가율
팀 체크아웃(Checkout): "사용자가 빠르고 안전하게 결제를 완료하게 한다"
- 담당: 장바구니, 결제, 배송 정보, 주문 확인, 결제 수단 관리
- 핵심 지표: 결제 완료율, 이탈률, 평균 결제 시간
이 전략의 장점은 각 팀이 비즈니스 성과에 직접 연결된 미션을 가진다는 것이다. 기술적 분리가 아닌 비즈니스 가치 중심의 분리이므로, 팀의 의사결정이 사용자 가치에 직접적으로 연결된다.
전략 3: 도메인 주도 설계(DDD) 기반 분리
가장 체계적이면서도 난이도가 높은 전략이다. 에릭 에반스(Eric Evans)의 도메인 주도 설계(Domain-Driven Design) 원칙을 프론트엔드에 적용한다.
핵심 개념
보편 언어(Ubiquitous Language): 도메인 전문가와 개발자가 동일한 용어를 사용한다. "상품"이 카탈로그 팀에서는 "표시 가능한 아이템"을, 재고 팀에서는 "관리 가능한 SKU"를 의미할 수 있다. 이런 의미 차이를 명확히 하는 것이 첫 번째 단계다.
바운디드 컨텍스트(Bounded Context): 동일한 용어가 다른 의미를 가지는 경계를 식별한다. 각 바운디드 컨텍스트가 하나의 마이크로앱(또는 관련 마이크로앱 그룹)이 된다.
적용 예시
전자상거래 서비스에서 "주문(Order)"이라는 개념을 중심으로 바운디드 컨텍스트를 식별해보면 다음과 같다.
| 바운디드 컨텍스트 | "주문"의 의미 | 관심사 |
|---|---|---|
| 카탈로그 | 상품과 가격 정보 | 표시, 검색, 필터 |
| 장바구니 | 구매 의사가 담긴 목록 | 수량, 쿠폰, 총액 |
| 결제 | 금전 거래 대상 | 결제 수단, 승인, 영수증 |
| 배송 | 물리적 배달 대상 | 주소, 추적, 상태 |
| 고객 서비스 | 문의/반품 대상 | 이력, 환불, 교환 |
각 컨텍스트에서 "주문"은 같은 단어지만 다른 속성과 행위를 가진다. 이 경계가 곧 마이크로앱의 경계가 된다.
백엔드 마이크로서비스 도메인 모델 활용
이미 백엔드가 마이크로서비스 아키텍처로 구성되어 있다면, 백엔드의 도메인 모델을 활용할 수 있다. 백엔드 마이크로서비스의 바운디드 컨텍스트가 프론트엔드 마이크로앱의 경계와 대응되는 경우가 많기 때문이다.
다만, 프론트엔드의 관심사는 백엔드와 다를 수 있으므로 1:1 매핑을 강제하지 말고, 참고 자료로 활용하는 것이 적절하다. 하나의 프론트엔드 마이크로앱이 여러 백엔드 마이크로서비스의 데이터를 조합해야 할 수도 있다.
프래그먼트(Fragment)의 역할
세 가지 전략 모두에서 공통적으로 등장하는 개념이 프래그먼트다. 프래그먼트는 하나의 팀이 소유하면서 다른 팀의 페이지에 런타임으로 공유되는 코드 조각이다.
프래그먼트의 특징
- 소유권이 명확하다: 프래그먼트는 반드시 하나의 팀이 소유한다
- 독립적으로 배포된다: 프래그먼트를 소유한 팀이 독립적으로 업데이트할 수 있다
- 런타임에 삽입된다: 빌드타임이 아닌 런타임에 호스트 페이지에 통합된다
- 자체 상태를 가질 수 있다: 독립적인 상태 관리를 하면서, 필요시 호스트와 통신한다
프래그먼트는 마이크로프론트엔드에서 페이지 수준 분리로는 해결되지 않는 영역을 다루는 핵심 메커니즘이다. 하나의 페이지에 여러 도메인의 기능이 공존할 때, 프래그먼트를 통해 각 도메인 팀이 자신의 영역을 독립적으로 관리할 수 있다.
핵심 정리
| 원칙/전략 | 핵심 내용 |
|---|---|
| 핵심 정의 (1) | 독립적으로 개발, 운영, 배포 가능한 마이크로앱 |
| 핵심 정의 (2) | 여러 마이크로앱을 합쳐 하나의 큰 웹앱처럼 동작 |
| 가장 중요한 원칙 | 독립적 배포 (코드베이스 -> 빌드 -> 프로덕션 모두 독립) |
| 빌드타임 조합 | 독립적 배포 원칙이 약화되므로 엄밀한 MFE가 아닐 수 있음 |
| 통합의 기준 | 사용자가 하나의 앱처럼 느끼는가 |
| 조직 구조 | 콘웨이의 법칙에 따라 엔드투엔드 팀 구성 필요, BFF 패턴 활용 |
| 분리 전략 1 | 페이지 구조 기반 - URL 경로별 팀 배정, 프래그먼트 분리 |
| 분리 전략 2 | 고객 요구사항 중심 - 팀 미션 기반 분리, 비즈니스 가치 연결 |
| 분리 전략 3 | DDD 기반 - Ubiquitous Language, Bounded Context 식별 |
| 프래그먼트 | 런타임에 다른 팀 페이지에 삽입되는 독립적 코드 조각 |
기억할 점: 분리 전략은 하나만 선택하는 것이 아니다. 초기에는 페이지 구조 기반으로 시작하고, 팀이 성숙해지면서 고객 요구사항 중심이나 DDD 기반으로 발전시켜 나갈 수 있다. 중요한 것은 분리의 기준이 명확하고, 팀 전체가 그 기준에 합의하는 것이다.
다음 단계
핵심 원칙과 서비스 분리 전략을 이해했다면, 이제 분리된 마이크로앱을 어떻게 통합할 것인지를 살펴볼 차례다. 다음 문서에서는 SSI, 빌드타임, iframe, Web Components, JavaScript, Module Federation의 6가지 통합 방식을 개괄적으로 비교한다.