테마
마이크로프론트엔드 도입 시점과 판단 기준
절대적 수치 기준이 아닌, 팀의 전조 증상과 환경 조건을 기반으로 도입 여부를 판단하는 방법을 학습한다.
학습 목표
- 모놀리식 프론트엔드에서 마이크로프론트엔드 전환이 필요한 전조 증상을 식별할 수 있다
- 절대적 수치 기준이 아닌 상황 기반 판단의 중요성을 이해한다
- 마이크로프론트엔드 도입이 적합한 4가지 조건을 구체적으로 파악한다
- 자신의 프로젝트에 도입 여부를 판단하는 프레임워크를 갖춘다
Part A. 문제 식별: 전조 증상 인식
절대적 기준은 적절하지 않다
마이크로프론트엔드 도입을 고려할 때, 흔히 절대적 수치 기준을 찾으려 한다.
- "코드가 10만 줄을 넘으면 분리해야 한다"
- "프론트엔드 개발자가 5명 이상이면 도입한다"
- "빌드 시간이 5분을 넘으면 분리가 필요하다"
이런 기준은 참고가 될 수 있지만, 절대적 기준으로 삼기에는 적절하지 않다. 10만 줄이어도 잘 구조화된 코드베이스라면 문제가 없을 수 있고, 3만 줄이어도 뒤엉킨 의존성으로 고통받을 수 있다. 팀의 기술 수준, 도메인 복잡도, 조직 구조, 배포 빈도 등 팀마다 상황이 다르기 때문이다.
대신, 전조 증상에 주목해야 한다. 현재 개발 프로세스에서 반복적으로 경험하는 고통점이 마이크로프론트엔드로 해결 가능한 것인지를 판단하는 것이 올바른 접근이다.
5가지 전조 증상
다음 증상들이 반복적으로, 그리고 점점 심해지는 양상으로 나타난다면 마이크로프론트엔드 도입을 진지하게 검토해야 한다.
증상 1: 코드 수정 후 엉뚱한 곳에서 버그 발생이 점점 늘어남
상품 목록 페이지의 필터 로직을 수정했는데, 장바구니 페이지에서 에러가 발생한다. 공통 상태 객체를 여러 컴포넌트가 직접 참조하고 있어서, 한 곳의 변경이 예측할 수 없는 곳에 영향을 미친다.
이 증상은 모듈 간 결합도가 높아졌음을 의미한다. 코드베이스 내에서 암묵적 의존성이 광범위하게 퍼져 있다는 신호다.
증상 2: 새로운 기능을 위해 기존 코드를 활용하는 것이 두려움
"이 유틸리티 함수를 재사용하면 되지 않나요?"라는 질문에 "건드리면 어디가 깨질지 모르니 새로 만들자"는 답변이 돌아온다. 코드 재사용 대신 복제가 일상화되고, 코드베이스는 점점 비대해진다.
이 증상은 코드베이스의 이해 가능성이 한계에 도달했음을 의미한다. 전체 코드를 이해하는 사람이 없거나 매우 적어진 상태다.
증상 3: 간단한 수정에도 빌드/테스트/배포 시간이 점점 길어짐
버튼 텍스트 하나를 수정했을 뿐인데, CI 파이프라인이 20분간 돌아간다. 전체 앱을 빌드하고, 전체 테스트 스위트를 실행하고, 전체 앱을 배포해야 하기 때문이다.
이 증상은 배포 단위가 너무 커졌음을 의미한다. 변경의 범위와 배포의 범위가 불일치하고 있다.
증상 4: 구현보다 커뮤니케이션 비용이 점점 증가
새 기능을 구현하는 데 2일이 걸리지만, 다른 팀과의 조율에 1주일이 걸린다. 배포 일정 맞추기, 코드 충돌 해결, 공유 모듈 수정 합의 등 커뮤니케이션 오버헤드가 실제 개발 시간을 압도한다.
이 증상은 팀 규모가 하나의 코드베이스에 적합한 수준을 넘어섰음을 의미한다.
증상 5: 동일 기능의 코드가 여기저기서 각각 개발됨
날짜 포맷 함수가 프로젝트 내에 7개 버전으로 존재한다. 각 팀이 서로의 코드를 모르거나, 알더라도 사용하기 어려워서 독자적으로 구현한 결과다.
이 증상은 코드 재사용 체계가 무너졌음을 의미한다. 공유 코드를 만들어도 변경 시 영향 범위를 예측할 수 없어서 아무도 사용하지 않게 된다.
적절한 규모의 팀이란
위 증상들은 결국 팀의 규모가 적절한 범위를 넘어섰을 때 나타난다. 적절한 규모란 다음 두 가지 조건을 동시에 만족하는 상태를 말한다.
두 조건 중 하나라도 무너지면, 현재 아키텍처가 팀의 성장을 제약하고 있다는 신호다. 이때 마이크로프론트엔드가 해결책이 될 수 있다.
Part B. 도입이 적합한 4가지 조건
전조 증상을 인식한 후, 실제로 마이크로프론트엔드를 도입하려면 다음 4가지 조건을 평가해야 한다. 이 조건들은 "도입해야 하는가"가 아니라 "도입할 수 있는가"에 대한 판단 기준이다.
조건 1: 적절한 규모의 팀을 벗어난 경우
가장 근본적인 조건이다. 마이크로프론트엔드의 핵심 가치는 독립적인 팀이 독립적으로 개발하고 배포할 수 있게 하는 것이다. 따라서 다음 두 가지가 전제되어야 한다.
프론트엔드 개발자가 충분해야 한다: 각 마이크로앱을 담당할 팀에 최소한의 프론트엔드 개발 역량이 있어야 한다. 프론트엔드 개발자가 2~3명뿐이라면 마이크로프론트엔드를 도입해도 결국 한 사람이 여러 마이크로앱을 담당하게 되어 분리의 이점이 사라진다.
크로스펑셔널(Cross-functional) 팀 구성이 가능해야 한다: 이상적인 마이크로프론트엔드 팀은 프론트엔드, 백엔드, 디자이너, QA를 모두 포함하는 크로스펑셔널 팀이다. 하나의 기능을 처음부터 끝까지 독립적으로 완수할 수 있는 팀 구조가 가능해야 한다.
조건 2: 기능적으로 마이크로앱으로 분해 가능한 경우
서비스가 명확한 기능 경계를 가지고 있어, 독립적인 마이크로앱으로 분해할 수 있어야 한다.
URL 경로 기준의 명확한 구분: 가장 직관적인 분해 기준은 URL 경로다.
| URL 경로 | 마이크로앱 | 담당 팀 |
|---|---|---|
/products/* | 상품 카탈로그 | 팀 A |
/cart/* | 장바구니 | 팀 B |
/checkout/* | 결제 | 팀 C |
/mypage/* | 마이페이지 | 팀 D |
/admin/* | 관리자 | 팀 E |
이처럼 URL 경로별로 깔끔하게 분리되는 서비스라면 마이크로프론트엔드 적용이 수월하다. 반면 하나의 페이지에 여러 도메인의 기능이 밀접하게 얽혀 있다면, 분해가 어려울 수 있다.
기능 영역 간 데이터 종속성이 적을수록, 통신 비용이 줄어들어 마이크로프론트엔드의 이점이 극대화된다.
조건 3: 런타임에 선택적 조립이 필요한 경우
모든 사용자에게 동일한 기능을 제공하는 것이 아니라, 고객사나 사용자 유형에 따라 다른 기능 조합을 제공해야 하는 경우다.
구체적인 사례:
- B2B SaaS에서 고객사 A에는 대시보드 + 보고서, 고객사 B에는 대시보드 + 결제 + 보고서를 제공
- 사용자 권한에 따라 관리자 기능을 동적으로 추가
- 국가/지역에 따라 다른 규정 준수 모듈을 로드
- 유료 요금제에 따라 프리미엄 기능을 선택적으로 활성화
이런 요구사항이 있을 때, 모놀리식 앱에서는 조건부 렌더링과 기능 플래그로 대응하지만 코드 복잡성이 급격히 증가한다. 마이크로프론트엔드에서는 필요한 마이크로앱만 런타임에 조립하면 되므로 훨씬 깔끔하게 처리할 수 있다.
이 조건은 필수 조건은 아니지만, 해당될 경우 마이크로프론트엔드의 이점이 특히 크다.
조건 4: 마이크로앱별 독립 인프라 구성이 가능한 경우
마이크로프론트엔드의 핵심인 독립적 배포를 실현하려면, 각 마이크로앱이 자체 빌드 파이프라인과 배포 인프라를 가질 수 있어야 한다.
필요한 인프라 요소:
- 마이크로앱별 독립 CI/CD 파이프라인 (빌드, 테스트, 배포)
- 각 마이크로앱의 정적 자원을 호스팅할 CDN 또는 서버
- 경로 기반 라우팅을 위한 리버스 프록시 또는 엣지 서버
- 마이크로앱별 독립적인 모니터링 및 로깅
클라우드 자원(AWS, GCP, Azure 등)을 활용할 수 있는 환경이라면 이런 인프라를 비교적 쉽게 구성할 수 있다. 컨테이너 오케스트레이션(Kubernetes), 서버리스(Lambda, CloudFront), CDN(CloudFront, Cloudflare) 등의 서비스가 마이크로프론트엔드의 독립 인프라를 뒷받침한다.
반대로, 하나의 물리 서버에서 모든 것을 운영해야 하는 제약이 있다면, 독립 인프라 구성이 어려워 마이크로프론트엔드의 핵심 이점을 누리기 어렵다.
종합 판단 프레임워크
전조 증상과 도입 조건을 종합하면, 다음과 같은 판단 흐름을 따를 수 있다.
| 단계 | 질문 | 판단 |
|---|---|---|
| 1단계 | 5가지 전조 증상 중 3개 이상이 점점 심해지고 있는가? | 아니오 -> 현재 아키텍처 유지 |
| 2단계 | 팀 규모가 적절한 범위를 넘어섰는가? | 아니오 -> 코드 리팩토링으로 대응 |
| 3단계 | 서비스를 명확한 기능 단위로 분해할 수 있는가? | 아니오 -> 모듈 단위 리팩토링 선행 |
| 4단계 | 독립 인프라 구성이 가능한 환경인가? | 아니오 -> 인프라 준비 후 재검토 |
| 5단계 | 런타임 선택적 조립이 필요한가? | 해당 시 추가 이점 |
| 최종 | 1~4단계 모두 "예"라면 | 마이크로프론트엔드 도입 적합 |
중요한 점: 마이크로프론트엔드는 문제를 해결하기 위한 도구이지, 그 자체가 목적이 아니다. 현재 겪고 있는 문제가 마이크로프론트엔드로 해결 가능한 것인지, 더 단순한 방법(모듈 분리, 코드 리팩토링, 팀 재구성)으로 해결할 수는 없는지 먼저 검토해야 한다.
핵심 정리
- 절대적 수치 기준(코드 줄 수, 팀원 수)은 참고만 할 뿐 판단 기준으로 삼지 않는다
- 전조 증상을 관찰하는 것이 더 정확한 판단 방법이다: 예측 불가 버그, 코드 활용 두려움, 빌드/배포 지연, 커뮤니케이션 비용 증가, 코드 중복 개발
- 적절한 규모의 팀이란 원활한 의사소통과 전체 코드 이해가 동시에 가능한 수준이다
- 도입 조건 4가지: 팀 규모 초과, 기능 분해 가능성, 선택적 조립 필요성, 독립 인프라 가능성
- 조건 1(팀 규모)과 조건 2(기능 분해)는 필수 조건, 조건 3(선택적 조립)은 추가 이점, 조건 4(독립 인프라)는 실현 조건이다
- 마이크로프론트엔드는 문제 해결 도구이지 그 자체가 목적이 아니다
다음 단계
도입 시점을 판단했다면, 이제 마이크로프론트엔드를 실현하기 위한 핵심 원칙을 이해해야 한다. 다음 문서에서는 독립적 배포의 의미, 합치는 방식의 기준, 그리고 서비스를 어떻게 분리할 것인지에 대한 3가지 전략을 살펴본다.