[MFA] 마이크로프론트엔드란?
들어가며
현재 실무에서 모노레포 방식으로 웹 프론트엔드 개발중인 쿰척 개발자입니다. 현재 프론트엔드 개발자로 전향한지 1년5개월 정도 되었는데 모노레포란? 그리고 마이크로프론트엔드란? 아직 정확하게 공부한적이 없어 이렇게 포스팅 하게 되었습니다. 이번글은 마이크로프론트엔드에 대해서 포스팅을 하겠습니다. 이 개념은 처음에는 다소 낯설게 느껴졌지만, 점차 그 가능성과 유연성에 매료되기 시작했고, 마이크로 프론트엔드는 각각의 기능이 독립적으로 작동하면서도 하나의 큰 애플리케이션을 형성하는 현대적인 개발 방식입니다. 이 글을 통해, 마이크로 프론트엔드의 특징, 장단점 등을 살펴보려고 합니다.
1. 특징
마이크로 프론트엔드는 대규모 웹 애플리케이션을 작은, 독립적인 부분으로 나누는 아키텍쳐 스타일입니다. 이는 각 팀이 자신들의 기능 영역에 집중할 수 있게 하며, 다양한 프레임워크를 사용하여 서로 다른 부분을 개발할 수 있는 유연성을 제공합니다.
2. 장, 단점
장점
- 점진적 개발 및 업그레이드: 각 구성 요소를 독립적으로 업그레이드할 수 있습니다. 이는 전체 시스템을 한 번에 업데이트할 필요 없이, 필요한 부분만 선택적으로 개선할 수 있다는 것을 의미합니다.
- 기술 스택 다양성: 개별 서비스는 서로 다른 프레임워크나 라이브러리를 사용하여 구축될 수 있습니다. 이는 기술 선택의 유연성을 제공하며, 특정 기술에 대한 의존성을 줄이는 데 도움이 됩니다.
- 팀 자율성 증가: 각 팀은 자신들이 담당하는 애플리케이션 부분에 대한 완전한 통제력을 가지게 됩니다. 이는 팀의 생산성과 효율성을 높이는 동시에, 팀 간의 의존성을 줄이고 각 팀의 독립적인 결정을 가능하게 합니다.
- 확장성: 로운 기능을 추가하거나 기존 기능을 변경하는 것이 기존의 모놀리식 구조보다 쉬워집니다. 시장의 변화나 사용자의 요구에 빠르게 대응할 수 있으며, 애플리케이션을 지속적으로 개선하고 혁신하는 것이 더 쉬워집니다.
- 독립적인 개발 및 배포: 특정 배포 범위가 줄어들고 테스트, 업그레이드, 업데이트를 독립적으로 하여 빌드 및 배포시간이 줄고, 장애 파급 범위가 작아지면서 팀에 유연성을 제공
- 코드베이스 관리의 단순화: 작은 코드베이스는 관리하기 더 쉽고, 오류 발견과 수정이 더욱 용이합니다.
- 재사용성 증가: 공통된 기능이나 컴포넌트는 여러 마이크로 애플리케이션에서 재사용될 수 있습니다. 이는 개발 시간과 노력을 줄이는 데 도움이 됩니다.
단점
- 복잡한 설정과 관리: 여러 개의 독립적인 컴포넌트로 구성되어 있기 때문에, 시스템의 전반적인 구조가 복잡해질 수 있습니다. 이는 관리와 유지보수의 어려움을 초래할 수 있습니다.
- 성능 문제: 각 마이크로 프론트엔드 컴포넌트가 독립적으로 로드되고 실행되기 때문에, 웹 페이지의 로딩 시간이 길어지거나 성능 저하가 발생할 수 있습니다
- 통합 문제: 각각의 마이크로 프론트엔드 컴포넌트를 효과적으로 통합하는 것은 까다로울 수 있습니다. 이들 간의 상호작용과 데이터 통신을 관리하는 것이 복잡하게 될 수 있습니다.
- 디자인 일관성 유지: 다양한 팀이 작업함에 따라 UI/UX의 일관성을 유지하는 것이 어려울 수 있습니다.
- 팀 간 협업 문제: 서로 다른 기술 스택과 작업 방식으로 인한 협업의 어려움이 발생할 수 있습니다.
- 중복 코드: 각 컴포넌트가 독립적으로 작동하기 때문에, 공통 기능이나 라이브러리가 여러 컴포넌트에 걸쳐 중복될 수 있습니다. 이는 코드베이스의 중복을 증가시키고, 유지보수의 복잡성을 높일 수 있습니다.
- 초기 구축 비용: 마이크로 프론트엔드 아키텍처를 새롭게 도입하고 설정하는 데는 상당한 시간과 노력이 필요합니다. 이는 새로운 아키텍처 설계, 개발 프로세스의 정립, 팀원들의 교육 및 적응 과정 등 초기 투자가 크게 요구됩니다.
3. 프로젝트 관리 기법 - 멀티레포, 모노레포
- 멀티레포: 각 마이크로 프론트엔드 애플리케이션이 서로 다른 저장소에 존재합니다. 독립성이 높지만, 종속성 관리가 복잡해질 수 있습니다.
- 모노레포: 모든 마이크로 프론트엔드 애플리케이션이 하나의 저장소에서 관리됩니다. 종속성 관리가 용이하지만, 대규모 프로젝트에서 복잡성이 증가할 수 있습니다.
4. 마이크로 프론트엔드 도입 체크
- 프로젝트 규모가 크고 복잡한 경우:
- 여러 팀이 동시에 다양한 기능을 개발해야 할 때.
- 애플리케이션의 각 부분이 서로 다른 기능이나 목적을 가지고 있을 때.
- 코드 수정 후 사이드 이펙트로 인한 버그가 자주 발생하는 경우:
- 작은 변경이라도 전체 시스템에 영향을 미칠 수 있는 복잡한 코드 구조가 있을 때.
- 새로운 기능을 위해 기존 코드를 활용하기 어려운 경우:
- 기존 시스템이 너무 복잡하거나 기술적으로 제한적일 때.
- 간단한 수정 사항 적용을 위한 통합, 테스트, 빌드, 배포 시간이 점점 길어지는 경우:
- 작은 변경이나 업데이트조차 전체 시스템의 재배포를 요구할 때.
- 작업을 위한 커뮤니케이션이 많아지는 경우:
- 여러 팀 또는 부서 간의 의사소통이 복잡하고 시간이 많이 소요될 때.
- 동일한 기능 개발을 위해 여러 곳의 작업자가 필요한 경우:
- 하나의 기능을 구현하기 위해 다양한 전문 지식을 요구하는 복잡한 작업 환경이 있을 때.
- 기능적으로 마이크로 앱으로 분해가 가능한 경우:
- 애플리케이션의 각 부분이 독립적으로 기능할 수 있고, 서로 다른 팀이나 기술 스택으로 개발 가능할 때.
마치며
마이크로 프론트엔드 아키텍처에 대해 알아본 후 이 아키텍처는 대규모 복잡한 애플리케이션 개발에 있어 혁신적인 접근법을 제공한다는 것을 알게 되었고, 독립적인 구성 요소의 개발과 배포는 개발 과정의 유연성을 대폭 향상시키고 팀의 자율성을 증가시키며, 전체 시스템의 안정성을 개선할 수 있습니다. 이러한 점들은 특히 복잡한 시스템을 개발하고 유지해야 하는 대규모 조직에 매우 유익하다고 생각합니다.
하지만, 마이크로 프론트엔드의 도입은 모든 상황에서 이상적인 해결책이 되는 것은 아닙니다. 특히 작은 규모의 프로젝트나 간단한 애플리케이션에서는 이 아키텍처의 복잡성과 관리 필요성이 오히려 단점으로 작용할 수 있습니다. 따라서, 마이크로 프론트엔드를 도입할 때는 프로젝트의 규모, 팀의 구조, 기술적 요구사항 등 여러 요소를 면밀히 고려해야 합니다.
참고