마이크로 프론트엔드의 등장
micro-frontends-architecture
마이크로 프론트엔드의 등장
MSA ??
- Microservices Architecture 마이크로 서비스 아키텍처에서 각 애플리케이션은 더 작고 느슨하게 결합되고 독립적으로 배치 가능한 여러 서비스로 구성된다.
- 보통 백엔드에서 사용된다. 모놀리식 아키텍쳐(서비스)와 대비되는 개념이다.
- API 서비스를 나누지 UI와는 관련없는 용어다.
발전 과정
- 실제로 개발을 할때는 우리 모두 다 맨 우측으로 개발하지 않는다.
- 프로젝트 성격, 팀의 규모, 상황을 고려하자
- 항상 절대적으로 맞는 아키텍쳐는 없다(폴더구조랑 똑같다. 아키텍처는 항상 최적의 상황이 있다.)
모놀리스
- 프론트엔드, 백엔드, 데이터베이스에 이르기까지 하나의 팀에서 하나의 프로그램을 함께 만들고, 수정하고 배포하게 된다.
- HTML을 수정해도 적용하려면 전체 프로그램을 배포해야한다.
- API 수정해도 적용하려면 전체 프로그램을 배포해야한다.
- 데이터베이스에 스키마를 변경해도 전체에 영향을 미치는 그런
- 보통은 MVP를 빠르게 만들고 증명해야 하기 때문에 이런 방식을 많이 쓰게 된다.
모놀리스의 프론트엔드와 백엔드를 나누는 이유
- 더 많은 사람들이 많은 일을 동시에 할 수 있도록 효율성을 향상시키기 위해
- API 인터페이스를 기반으로 소통하게 된다.
백엔드에서는 MSA로 발전하게 된다.
- 백엔드에서는 백엔드 서비스를 더 전문적으로 만들고 고도화 시킬 목적으로 마이크로 서비스를 도입한다.
- BFF, GraphQL과 같은 개념과 기술들이 생겨난다.
Micro Frontends
- 개발 효율성 향상을 위한 도입이어야 한다.
독립적으로 제공 가능한 프론트엔드 애플리케이션이 더 큰 전체로 구성되는 아키텍쳐 스타일
End-to-End 팀들
- 마이크로 프론트엔드에서는 개발부터 배포까지, 즉 조직의 문제를 다 해결하는 팀이다.
마틴 파울러가 말하는 소프트웨어 아키텍처의 중요성
아키텍처란?
구성요소들간의 관계, 환경, 설계와 발전을 관리하는 원칙으로 이루어진 시스템의 근본적인 구조
패배한다.
개발자로서 전문적인 수준의 품질을, 훌륭한 코드를, 좋은 설계를 이런 관점으로 일을 한다면 우리는 패배할 것이다. 왜냐하면 장인정신과 경제의 싸움이 될 것이기 때문이다. 늘 이기는 것은 경제의 싸움이다.
품질과 비용의 트레이드오프
소프트웨어의 품질은 다른 개념이다. 평가하는 사람은 외부의 사람들(소비자)은 우리의 내부품질을 볼 수 없다. 즉 그래서 소프트웨어의 품질은 내부적인 품질과, 외부적인 품질 두 가지가 있다. 아키텍쳐란 내부품질에 속해 있다.
같은 기능이라면 소비자는 100달러가 더 비싼 (내부품질이 더 좋은 소프트웨어) 프로덕트를 구매하지 않는다.
마이크로 프론트엔드 아키텍처
- 초기 개발속도가 느리다.
- 빌드 / 배포 설정이 복잡하다.
- 개발 환경 설정 복잡하다.
- 그러나 커뮤니케이션 비용이 시스템이 커진다고 해서 영향을 받지 않는다.
- 배포시간이 빠르다.
- 장애 파급 범위가 작다.
- 자율성이 높아진다.
마이크로 프론트엔드가 필요할까
언제 도입을 검토할까??
- 일단 규모가 커야합니다.
- 코드의 양이 많다. (10만줄?)
- 팀원이 많다.
- 제공하는 기능이 많다.
- 기능이 50가지
- 서비스의 100페이지?
라고 따지면 문제가 있다. 단순히 규모가 크다고 마이크로 프론트엔드 아키텍처를 도입한다고??
규모가 커도 문제 없이 잘 돌아가는데 굳이 도입을 고려할 필요가 없다. 규모가 크다는 절대적인 조건을 가지고 도입을 고려하는게 아니라 문제가 생기는 근본적인 원인을 잘 검토해보자.
전조 증상
- 코드를 수정했는데, 엉뚱한 곳에서 문제가 발생
- 새로운 기능을 위해 기존 코드를 활용하기가 무섭다.
- 간단한 수정 사항을 적용하기 위해 통합, 테스트, 빌드 및 배포 시간이 점점 길어진다.
- 작업을 위한 커뮤니케이션이 점점 늘어난다.
- 동일한 기능을 제공하기 위해 여기 저기서 각각 개발하는 일이 늘어난다.
적절한 규모의 팀을 넘어서 이러한 전조증상들을 관리할 수 없다면, 마이크로 프론트엔드 도입을 고려해보자.
적절한 규모란? 하나의 팀이 의사소통하면서 해당 서비스의 모든 기능을 이해할 수 있는 수준.
도입했는데 얻게 되는 장점
- 덜 복잡하고, 적은 양의 코드를 관리하여 코드의 품질을 높일 수 있다.
- 배포의 범위가 줄어들어 빌드 및 배포 시간이 줄고 위험도가 줄어든다.
- 단일 장애 지점을 피할 수 있다.
- 점진적으로 업그레이드 하기에 용이하다.
- 요구사항에 맞춰 애플리케이션을 자유롭게 조립하여 제공할 수 있다.
- 팀이 주도적으로 자유롭게 기술 스택을 선정하고 스케줄을 조정할 수 있다.
- 서로 다른 팀이 독립적으로 작업을 할 수 있기 때문에 개발 주기가 더 빨라질 수 있다.
단점
- 중복 코드가 발생할 수 있다.(라이브러리, 구현 코드)
- 전체적인 리소스의 크기가 커져 성능 저하에 주의해야 한다.
- 초기 구축 비용이 발생한다.
- 다양한 마이크로 프론트엔드 간의 통합과 통신에서 추가적인 복잡성이 발생한다.
- 빌드 타임에서는 문제가 발생하지 않지만, 런타임에 동적으로 통합하는 과정에서 문제가 발생할 수 있다.
- 각각 자율적으로 발전하는 어플리케이션간의 일관적인 UX 제공을 위한 장치가 필요하다. (디자인 시스템-> 개발해야 한다..)
- 마이크로 프론트엔드마다 기술적인 격차가 벌어질 수 있다.(문서 공유를 하자.)
도입이 필요한 경우
- 소수의 개발자만 있고 의사 소통에 문제가 없는 경우, 장점보다 비용이 더 커서 좋지 않다.
- 프론트엔드 개발자가 많은 경우
- 서비스가 URL 경로를 기준으로 기능적으로 구분이 가능한 경우
- 어떤 팀이 어떤 부분에 책임을 가지고 있는지가 명확하게 구분이 가능해야 한다.
- 런타임에 여러가지 마이크로 앱을 선택적으로 조립해서 제공해야 하는 경우
- 독립적으로 인프라 구성이 가능한 경우 (클라우드)
- 마이크로 앱을 같은 서버에 배포한 경우 의미가 적어진다.
마이크로 프론트엔드
독립적으로
주요 요소
independently deliverable
- 마이크로 프론트엔드 앱들은 독립적이지만 혼자 있을때 의미를 가지는 앱이 아니다.
- 독릭적인 배포가 핵심이다.(개별 배포)
- 복잡하고 거대한 덩어리를 더 작고 관리하기 쉬운 조각으로 잘게 쪼개서 개발하면 많은 이점이 발생하고, 기술선택, 코드베이스, 팀 구성, 릴리스 프로세스는 독립적으로 작동하고 발전할 수 있게 된다.
composed into a greater whole
- 작은 애플리케이션이 모여 더 큰 전체로 합쳐지는 것.
- 합쳐진 앱이 하나의 커다란 앱이 되는 것이다.
시스템과 조직이 닮아간다.
- End-to-End Teams with Micro Frontends
점진적으로 BFF를 사용하자
프론트엔드 팀이 과도기적 현상을 겪고 있는 경우, 당장 마이크로 프론트엔드 아키텍처로 넘어가기에는 힘든 경우
서비스를 나누는 방법
- 페이지를 기준으로
- 고객 요구 사항을 중심으로 (결제, 리스트 등)
- 도메인 주도 설계를 통해
다음편에서는 마이크로 프론트엔드를 구성하기 위한 도구에 대해 알아보자.