MSA 혹은 마이크로서비스 라는 용어는 보통 백엔드에서 사용이 되는 용어이다. 이와 대비되는 이전의 아키텍처를 모놀리식 아키텍처 혹은 모놀리스 라고 하는데 모놀리스에서 마이크로서비스로의 발전 과정에 대해 다룰 때 보통 UI에 대한 내용은 다루지 않는다. 즉, 마이크로서비스 라는 말은 프론트엔드와는 큰 관련이 없는 용어였다.
하지만 마이크로 서비스가 발전하면서 이런 접근 방식을 프론트엔드까지 확장하려는 시도가 생겼고 그러면서 마이크로 프론트엔드라는 용어가 생겨났다.
그래서 정의가 뭔데?
An architectural style where independently deliverable frontend applications are composed into a greater whole
독립적으로 제공 가능한 프론트엔드 애플리케이션이 더 큰 전체로 구성되는 아키텍처 스타일
핵심은 볼드체 부분이다. 마이크로 프론트엔드를 적용했다면 독립적으로 제공이 가능해야하고 이렇게 독립적으로 제공된 애플리케이션이 더 큰 전체로 구성되어야 한다.
독립적으로 제공 가능하다.
어떤 팀 혹은 어떤 집단에 독립적으로 개발하고 운영하고 있는 작은 부분의 애플리케이션이지만 명확하게 혼자 동작해서 유저에게 제공하는 애플리케이션일 필요는 없다. 마이크로 앱들은 혼자서 있을 때 존재의 이유가 있는 앱들이 아니다.
더 큰 전체로 구성된다.
독립적으로 배포되는 작은 앱들을 따로 따로 사용하면 그건 마이크로 프론트엔드가 아니다. 중요한 건 합치는 방식이 구체적으로 규정되어 있지 않지만, 합쳐진 것이 마치 하나의 커다란 어플리케이션처럼 동작하느냐가 마이크로 프론트엔드이냐 아니냐를 정한다는 것이다.
Monolithic Frontend와 Micro Frontends 비교
| Monolithic Frontend | Micro Frontends | 설명 | |
|---|---|---|---|
| 초기 개발 속도 | 빠르다 | 느리다 | 모놀리식은 복잡한 사전 설정없이 바로 개발을 시작할 수 있지만 마이크로 프론트엔드에선 앱을 나누고 미리 정해둬야할 것들이 있으며 패키지 레벨에서 공통 라이브러리를 설계하는 등의 작업이 필요 |
| 빌드 / 배포 환경 설정 | 단순 | 복잡 | 모놀리식의 경우엔 모노레포가 아닌 경우가 많고, 단일 코드 베이스 프로젝트이기 때문에 훨씬 더 쉽다. 하지만 마이크로 프론트엔드는 보통 모노레포이며 모노레포 상에서 여러가지 패키지와 마이크로 앱들이 문제없이 빌드 배포되야하고 빌드 서버의 캐싱과 같은 것도 고려해야함 |
| 개발 환경 설정 | 간단 | 복잡 | 모놀리식은 서버를 한대만 띄으면 되지만 마이크로 프론트엔드는 여러 앱을 동시에 띄워야 함 |
| 커뮤니케이션 비용 | 시스템의 크기와 비례 | 적다 | 모놀리식은 시스템이 커질수록 커뮤니케이션해야할 사람 수가 늘어나지만 마이크로 프론트엔드는 end to end 팀 내부에서 모든걸 진행하기 때문에 시스템의 크기가 상관없이 일정 |
| 배포 시간 | 느리다 | 빠르다 | 모놀리식은 시스템이 커질수록 기술적인 시간뿐만 아니라 의존성으로 인해 전체 배포 시간도 점점 늘어난다. 하지만 마이크로 프론트엔드는 각각이 독립적인 배포를 하기 때문에 시간이 적게 걸림 |
| 장애 파급 범위 | 크다 | 작다 | 놀리식의 경우 그 범위가 크고 시스템이 커질수록 예측이 더욱 어려워지게 되는데 마이크로 프론트엔드에서는 장애의 범위를 각 마이크로 앱 수준으로 작게 만들수 있음 |
| 자율성 | 낮다 | 높다 | 기술 선택의 자율성, 라이브러리 업그레이드의 자율성, 배포 주기의 자율성, 개발 스케줄의 자율성 모두 마이크로 프론트엔드에서 훨씬 높음 |
언제 쓰느게 좋을까?
규모가 크다
절대적인 수치는 없다. 지금 팀에서 이런저런 문제가 발생하는데 이유를 찾다가 우리 팀이 다루는 프로젝트의 규모가 너무 크지않나? 라는 생각에 도달했다면 규모가 큰 것이다.
이런 저런 문제들
- 코드 수정 후 엉뚱한 곳에서 버그가 튀어나온다.
- 새로운 기능을 위해 기존 코드를 활용하기 무섭다.
- 간단한 수정사항 적용을 위한 통합, 테스트, 빌드 및 배포 시간이 점점 길어진다.
- 작업을 위한 커뮤니케이션 비용이 점점 늘어난다.
- 동일한 기능을 위해서 여기저기서 각각 개발하는 일이 늘어난다.
기능적으로 마이크로 앱으로 분해가 가능한 경우
서비스가 url 경로를 기준으로 기능적으로 구분이 가능한 경우가 좋으며 어떤 팀이 어떤 부분에 책임을 가지고 있는지가 명확하게 구분이 가능해야한다. 이렇게 분해한 후에 불분명하거나 중복된 부분이 발생되지 않아야 한다.
런타임에 여러가지 마이크로 앱을 선택적으로 조립해서 제공해야 하는 경우
예를 들면, 특정 고객사에게만 제공해야하는 기능이 있을 때 런타임에 특정 버전을 사용하도록 처리하면 레고처럼 쉽게 블록을 조합하여 제공할 수 있습니다.
마이크로 앱이 독립적으로 인프라 구성이 가능한 경우
같은 서버를 마이크로 앱마다 나눠서 사용하는 것보다 클라우드 자원을 충분히 활용 가능한 경우 사용하는 것이 좋다.물론 항상 자원은 아껴야 하지만, 마이크로 앱들을 서로 다른 서버에 배포하는 것이 낭비가 되는 경우에는 사용하지 않는 것이 좋다.
이 내용을 거꾸로 생각해보면 마이크로 앱이 독립적으로 인프라 구성이 가능하지 않고 다 같은 인프라를 나눠서 쓰고 있다면 마이크로 프론트엔드를 도입하지 않는것이 낫다는 뜻이다. 마이크로 프론트엔드의 이점으로 단일 장애 지점을 없애고 싶은건데 빌드하고 배포된 리소스가 같은 인프라에 있고 이 인프라에 문제가 생기면 사실상 단일 장애 지점이 되기 때문이다.
도입하면 뭐가 좋을까?
장점이 많으니 요즘 다들 웅성웅성하는거다.
- 덜 복잡하고, 적은 양의 코드를 관리하여 코드의 품질을 높일 수 있다.
- 배포의 범위가 줄어들어 빌드 및 배포 시간이 줄고 위험도가 줄어든다.
- 단일 장애 지점을 피할 수 있다.
- 점진적으로 업그레이드하기 좋다.
- 요구사항에 맞춰 어플리케이션을 자유롭게 조립하여 제공할 수 있다.
- 독립적으로 개발 및 배포할 수 있기 때문에 오너십을 가진 팀이 자유롭게 스케줄을 조정할 수 있다.
- 팀이 주도적으로 자유롭게 기술 스택을 선택할 수 있다.
- 서로 다른 팀이 독립적으로 작업을 할 수 있기 때문에 개발 주기가 더 빨라질 수 있다.
도입하면 무조건 좋을까?
그렇진 않다. 일단 저 위에 조건들이 만족되지 않으면 좋은 효과를 볼 수 있다고 보장하기 어렵다. 마이크로 프론트엔드가 가지는 단점은 아래와 같다.
- 중복코드가 발생할 수 있다.
- 전체적인 리소스의 크기가 커져 성능 저하에 대한 주의가 필요하다.
중복된 종속성 때문에 번들링된 동일한 패키지를 여러 부분이 불러오며 속도 저하의 문제가 생길 수 있다. - 초기 구축 비용이 든다.
- 다양한 마이크로 프론트엔드 간의 통합과 통신에서 추가적인 복잡성이 발생할 수 있다.
- 빌드 타임에선 문제가 없지만 런타임에서 동적으로 통합하는 과정에서 문제가 발생할 수 있다.
- 일관적인 ux를 제공하기위한 장치가 필요하다.
- 마이크로 프론트엔드마다 기술적인 격차가 벌어질 수 있다.
마지막 단점은 마이크로서비스와 직접적인 연관이 있다. 보다 분산된 아키텍처인 마이크로 프론트엔드는 필연적으로 더 많은 리포지토리, 더 많은 도구, 더 많은 빌드/배포 파이프라인, 더 많은 서버, 더 많은 도메인 등 관리해야 할 항목이 많아지게 된다.
따라서 이러한 아키텍처를 채택하기 전에
- 추가로 필요한 인프라를 프로비저닝하고 관리할 수 있는 충분한 자동화가 마련되어 있는지
- 프론트엔드 개발, 테스트 및 릴리스 프로세스를 여러 애플리케이션으로 확장할 수 있는지
- 툴링 및 개발 관행이 점점 더 분산되고 제어가 어려워지는 것에 대한 의사 결정에 익숙한지
- 수많은 독립적인 프론트엔드 코드베이스에서 최소한의 품질, 일관성 또는 거버넌스를 어떻게 보장할 것인지
중요한 점은 마이크로 프론트엔드를 선택할 때 정의상 하나의 큰 것이 아니라 여러 개의 작은 것을 만드는 것을 선택한다는 것이다. 즉, 혼란을 일으키지 않고 이러한 접근 방식을 채택하는 데 필요한 기술적, 조직적 성숙도를 갖추고 있는지 고려해야 한다.
결론
멋져보인다고 함부로 막!!! 대입할 수 있는 아키텍쳐는 아닌게 확실하다. 일단 충분한 수의 프론트 개발자가 확보되어야 고려 가능한거 같다. 공부해보면서 내가 다닌 회사들 중 적용해볼만한 회사가 있나..도 생각해봤는데 택도 없는 듯 하다. 이렇게 이론적인 부분만 들어선 ??? 이게 되는게 맞아?? 싶기도 해서 다음번엔 프로젝트를 하면서 공부해봐야겠다.
