Micro Frontends 번역글 1/5 요약

이 글에서는 Cam Jackson의 Micro Frontends 번역 글을 보고 내가 쉽게 보려고 요점만 정리해봤다.

 

Micro Frontends의 정의

프론트엔드의 단일 구조를 개별적으로 개발, 테스트 및 배포 할 수 있는 작고 간단한 덩어리로 분해하는 패턴이 나타나고 있으며 이것은 고객에게 단일 응집력있는 제품으로 나타납니다. 우리는 이 기법을 Micro-Frontends 라고 부르며 , 다음과 같이 정의합니다.

독립적으로 제공 가능한 프론트엔드 애플리케이션들로 더 큰 하나의 전체 어플리케이션을 구성하는 아키텍처 스타일

 

장점

• 더 작고, 응집력 있고 유지보수가 쉬운 코드 베이스
• 이전보다 더 많은 분할, 증가 방식으로 일부씩 나누어 업그레이드, 업데이트 또는 재작성 할 수 있음

단점

• dependeny의 중복을 초래하여 사용자가 다운로드 해야하는 바이트 수가 증가
• 팀 자율성이 극적으로 증가하면 팀 작업 방식이 탄편화 될 수 있음

이점에 대해 더 자세히 알아보자.

 

이점

1. 점차적인 업그레이드

오래되고 커다란 프론트엔드를 업그레이드 하려고 할 때, 전체 재구축의 리스크를 피하고 오래된 어플리케이션을 한부분씩 나누어 처리하는 데에 용이하다.

 

2. 단순하고 분리된 코드베이스

개별적인 마이크로 프론트엔드의 소스코드는 단일 프론트엔드의 소스코드보다 훨씬 작아서 개발자가 작업하는 것이 더 쉬워진다. 특히, 서로에 대해 알지 않아야 하는 구성 요소 간의 의도하지 않은 부적절한 결합으로 인해 발생하는 복잡성을 피한다.

 

3. 독립적인 배포

마이크로 프론트엔드의 독립적인 배포 가능성이 핵심이다. 이렇게 하면 주어진 배포 범위가 줄어들어 관련 위험이 줄어든다.
각 마이크로 프론트엔드는 자체적인 파이프라인이 있어야 하며, 다른 코드베이스나 파이프라인의 현재 상태를 거의 고려하지 않고 각 마이크로 프론트엔드를 배포할 수 있어야 한다.

 

 

 

4. 자율적인 팀

아이디어 구상에서 생산 및 그 이상까지 제품의 한 부분을 소유할 수 있는 완전히 독립적인 팀을 구성하는 데 도움이 된다. 따라서 팀이 신속하고 효과적으로 고객에게 가치를 제공한다.
이것이 작동하려면 기술적 능력보다는 단일 팀이 엔드 투 엔드를 소유하는 수직적 비즈니스 기능을 중심으로 구성되어야 한다.

 

 

 

간단히 말해서

마이크로 프론트엔드는 커다란 것을 작고 관리하기 쉬운 조각으로 나눈다음 이들 사이의 종속성을 명시하는 것이다. 기술, 코드베이스, 팀 및 릴리즈 프로세스에 제한 없이 독립적으로 작동하고 발전할 수 있어야 한다.

 

 

 

참고:
https://martinfowler.com/articles/micro-frontends.html
https://medium.com/@juyeon.kate/micro-frontends-%EB%B2%88%EC%97%AD%EA%B8%80-1-5-29c80baf5df