프론트엔드

[번역] 마이크로 프론트엔드의 장단점 micro frontends pros and cons

개발자R 2022. 11. 8. 10:45
반응형

https://fabrity.com/blog/software-engineering/micro-frontends-pros-and-cons/

 

Micro frontends: pros and cons - Fabrity Software House

Micro frontends can be an alternative to the frontend monolith architecture, especially for more complex projects. Read on to find out more.

fabrity.com

 

글의 번역 글입니다.

 

<본문>

 

웹앱이나 SPA 앱을 만들 때 정말 작은 프로젝트가 아니라면 통상 여러 개발자들이 하나의 나눌 수 없는 코드를 가지고 일을 한다. 왜냐하면 많은 프론트엔드 프레임워크들이 모놀리틱 아키텍쳐 스타일(모든 기능이 한 곳에 있는 것)을 제공하기 때문이다.

 

이것은 팀간의 커뮤니케이션 이슈를 야기하거나 코드간의 문제를 만들어서 결국엔 형편없는 데브옵스가 되어저릴 수 있다. 또한 테스팅이나 개발과 같은 중요한 프로세스를 느리게 하여 납기를 어기는 일이 발생할 수도 있다.

 

이러한 이슈를 해결하기 위해 최근에 등장한 것이 마이크로프론트엔드로 배포하는 것이다. 하나의 큰 모놀리식 아키텍처를 다루기 쉬운 컴포넌트들로 나누고 쪼개는 것이다. 각 컴포넌트들은 각자의 고유한 기능을 가지고 있고, 서로 의존관계가 거의 없다. 이는 더 유연한 프론트엔드 프레임워크를 만들어 각 팀들이 그들이 개발해야하는 기능들에만 집중하고, 에러를 줄일 수 있게 한다. 이러한 접근방식을 적용하는 것이 비즈니스에 적합한지 아닌지 여부는 비즈니스 자체의 규모, 사용가능한 리소스, 전반적인 프로젝트의 복잡도에 따라 달라진다.

 

What is micro frontend architecture?

마이크로 프론트엔드 아키텍처란 무엇인가?

 

앞서 말했듯 이것은 컴포넌트 기반의 아키텍쳐이다. 독립된 마이크로 프론트엔드 어플리케이션이 각자 자신의 기능에만 책임을 지는 것이다. 이것들은 함께 모여서 전체 클라이언트-사이드 유저 인터페이스를 형성한다. 각 프론트엔드는 전체 페이지의 덩어리(chunk) 이지만 모놀리식 아키텍쳐와는 다르게 전체를 구성하진 않는다. 

 

이 프론트엔드 개발 방식은 2020년  Zack Jackson이 그의 2020년 논문 Module Federation 을 설명했을 때 두각을 나타냈다. 논문에서 잭슨은 어떻게 고립되거나 떨어져있는 컴포넌트들이 독립적이게 개발되고, 컴포넌트들을 찾기위해 기존의 모놀리식 없이 배포될 수 있는지 자세히 설명했다.

 

여러 회사들이 모놀리식 프론트엔드 대신 마이크로 프론트엔드를 채택하기 시작했다. 이케아와 스포티파이가 가장 대표적이다.

 

모놀리식 아키텍쳐 하에서, 다른 파트를 맡고있는 개발자들은 그들이 맡고있는 컴포넌트나 어플리케이션들이 모두 상호 의존적이고 하나의 웹 서버에서 돌아가기 때문에 계속 돌고있는 접시들을 가진것과 마찬가지다. 

 

이런걸 말하려고 하는듯...

데브옵스 플랜들과 전담팀이 있다고 하더라도, 이들이 모두 같은 모놀리식 아키텍쳐에 있다는 것은 상호의존성과 공통된 우려로 인한 문제를 야기한다. 이러한 상황에서 일하는 다른 팀들은 종종 우연히 동료를 반대하게 되거나 코드나 데이터베이스에 문제를 일으킬 수 있다.

 

하지만 하나의 마이크로 프론트엔드 컴포넌트에 집중을 하게 되면, 팀들은 개발 진행중에도 각자 독립적으로 개발하고 배포할 수 있어 자율적인 팀이라는 이점이 생기게 된다.

 

다양한 API들과 함수들이 함께 결집되어 하나의 프론트 페이지가 생성된다. 따라서 프론트 페이지는 독립된 특성들의 집합, 상호의존에서 나오는 이슈, 여러 파트에 걸쳐 일하는 팀들이 잠재적인 실수를 만드는 것에서 벗어나게 된다.

 

각 개발팀들에게 구체적인 KPI들과 웹 컴포넌트의 구체적인 스펙이 주어진다면, 그들은 그들이 맡은 부분의 클라이언트 사이드의 인터페이스만 집중할 수 있어 다른 팀들과의 충돌을 걱정할 필요도 없다.

 

아래에서 언급하겠지만, 이것들은 또한 구축, 확장, 테스트, 모듈화 등에서도 부수적인 결과물들을 가져온다.

 

Benefits of micro frontend architecture

마이크로 프론트엔드 아키텍쳐의 장점

 

1. Library development - 라이브러리 개발

각자 팀들이 담당하는 컴포넌트들을 테스트하고 배포하는 여러 팀들이 코드를 재사용할 수 있고, 다른 프로젝트에도 그 컴포넌트를 재도입할 수 있다. 이를 통해 회사는 회사 자체의 웹 컴포넌트, 웹 애플리케이션 라이브러리 에코시스템을 만들 수 있다.

 

2. Flexibility and variation - 유연성과 변동성

개발자는 자신이 담당하는 프론트엔드를 만들 때 리액트나 뷰 등 자신이 원하는 프론트엔드 프레임워크나 언어를 고를 수 있다. 이를 통해 개발자는 최고의 작업 선호와 편안함을 얻을 수 있으며, 하나의 프로젝트라고해서 다 동일한 프레임워크나 언어를 쓰지 않으므로 통찰력있고 다이나믹한 사고를 할 수 있다.

 

3. Speed - 속도

프로젝트에서 충분한 프론트 팀을 고용할 수 있는 충분한 리소스가 있는 경우, 각 팀이 자체적으로 마이크로 프론트엔드 컴포넌트, 목표, 납기에 맞추어, 독자적인 테스팅과 배포를 책임지며 신속하게 일할 수 있다.

 

4. Scalability - 확장성

앱이나 웹 페이지가 복잡해지면 시간이 지나며 확장을 해야한다.  프로젝트의 리소스가 충분하여 여러 팀을 구성할 수 있는 경우, 여러 팀들은 점진적으로 그들의 프론트엔드 부분을 업그레이드하고, 관리가능한 속도로 어플리케이션을 확장할 수 있다.

 

5. Developer experience - 개발자 경험

단일의 마이크로서비스 코드를 배우는 것이 전체 모놀리식 코드를 배우는 것보다 쉽다. 또한 개발자는 그들의 컴포넌트를 작업할 때에 그들이 익숙하고 편안한 언어를 선택할 수 있다. 따라서 기업은 경험이 많은 구성원에게만 의존할 필요가 없기 때문에 잠재적으로 여러 애플리케이션에서 작업할 수 있는 더 많은 잠재적 인력 풀에 액세스할 수 있다. 이것은 또한 예산 고려에도 이점이다.

 

6. Independent deployment and testing - 독립 배포 및 테스트

각 팀들은 본인이 개발한 것만 배포한다. 프론트엔드가 독립적이기 때문에 배포나 변경사항들은 특정 마이크로서비스에만 국한되지 전체에 변경을 주지 않는다. 이는 또한 팀들이 각자 부분들만 테스트하고 모니터링을 담당하기 때문에 전체 프로젝트를 동시에 모니터링하거나 테스트할 필요가 없다는걸 의미한다.

 

Drawbacks of micro frontend architecture

마이크로 프론트엔드의 단점

 

1.Resources - 리소스

위에서 언급한 마이크로프론트엔드 아키텍쳐의 장점들을 실현하기 위해선 프로젝트는 반드시 여러 팀으로 이루어져야한다. 비즈니스가 충분히 크지 않거나 리소스가 없다면 마이크로서비스는 분명 성가시거나 공수만 드는게 된다.

한 팀으로 구성되면 여러 모듈의 개발, 테스팅, 여러 언어들을 사용하게 될 것이다. 이건 시간낭비다. 팀이 분리되어있어야 마이크로서비스가 고려될 수 있다.

 

2.  Complexity - 복잡도

마이크로프론트엔드 아키텍처를 활용하면 프로젝트 지연의 위험이 커진다. 개발자는 시간이 지남에따라 프로젝트를 너무 컴포넌트로 가득 채워서 여러팀에 걸친 여러 테스트 및 배포단계에서 문제가 생길 수 있다. 

이를 위해서 컴포넌트의 정확한 수와 범위를 결정하는 플래닝 단계가 아주 세세하고 복잡해진다. 마찬가지로, 각 개발 팀이 따를 정확한 KPI도 요구된다. 이 모든 것들은 더더 많은 관리 포인트와 리소스를 필요로 한다.

 

3. Payload - 페이로드

마이크로서비스는 공통된 디펜던시들이 중복될 수 있다. 예를 들어 마이크로프론트엔드가 작동하기 위해 특정 프로그램이 설치되어야한다면, 다른 클라이언트 측 사용자들도 해당 사본을 다운로드 해야한다. 이는 각 컴포넌트마다 완벽한 기능과 브라우저 지원을 보장하기 위해 여러가지 다운로드가 필요하다는 뜻이다.

많은 유저 컨텍스트가 인프라에 의존하는 것이고, 이건 곧 (유저 컨텍스트가) 개발자에 의해 관리되는 것보다 훨씬 성능이 딸리고, 결국 추가적인 데이터 요구가 이루어져 단점이다. 사용자는 성능이 떨어지는 웹 앱을 사용하지 않을 것이다.. 네이티브 브라우저가 지원되는 컴포넌트를 사용하는 것은 다운로드로 인한 의존도를 줄여주기 때문에 이런 문제를 어느정도 줄일 수 있다.

반응형