MFA (Micro Frontend Architecture)

Overview

해당 포스팅은 MFA 강좌를 수강하고 MFA에 대해서 공부한 내용을 기록하기 위한 포스팅 입니다.

MFA가 무엇인지 살펴보고 조직에서 MFA 도입을 고려하면 좋은 시점에 대해서 고민해보도록 하겠습니다.

마지막으로는 대표적으로 MFA를 구현하는 방식에 대해서 남겨보도록 하겠습니다.

MFA에 대해서 궁금하신 분들은 아래 강의를 통해서 접해보시면 좋을것 같습니다. (관계자 아님, 내돈 내산)
> 강의 바로가기

 

MFA

MFA는 Micro Frontend Architecutre의 약자로써 기존의 모놀리식 프론트엔드를 앱 단위로 잘개 쪼개어 하나의 애플리케이션으로 통합하는 현대식 프론트엔드 아키텍처 입니다.

 

잘개 쪼갠다고 하는데 무엇을 쪼갤 수 있을까요? 당근 플랫폼을 예시로 들어서 살펴보도록 하겠습니다.

 

https://www.daangn.com/

 

 

당근의 홈 화면 입니다. 상단의 네비게이션 바를 살펴보면 당근 플랫폼 속에서 중고거래, 동네업체, 알바, 부동산 등 여러개의 서비스를 운영중인 것을 확인할 수 있습니다.

 

이외에 지역 광고, 사용자 관련 인증, 비즈니스 등 여러 서비스를 살펴보면 당근이라는 커다란 플랫폼 속에서 여러 작고 커다란 서비스들이 운영되는 것을 확인할 수 있습니다.

 

만약 당근 플랫폼이 모놀리식 프론트엔드를 운영한다면 다음과 같이 도식화를 할 수 있을 것 같습니다.

모놀리식 프론트엔드는 다양한 말로 설명할 수 있겠습니다만, 저는 여기서 전통적인 프론트엔드 방식으로 모든 서비스를 하나의 코드베이스로 개발, 운영하는 형태의 프론트엔드 라고 정의해보도록 하겠습니다.

 

당근이라는 커다란 플랫폼 (밖에 위치한 도형) 속에 중고거래, 중고차 등 여러 서비스가 존재합니다. 여기서 밖에 위치한 도형은 하나의 코드베이스이고, 여러 서비스들은 각각의 애플리케이션이 아닌 하나의 커다란 코드베이스 속의 모듈 (코드)로써 존재하고 있습니다.

 

위 서비스를 MFA 구조로 잘게 잘라봅시다! 당근은 명확하게 서비스 단위를 나눌 수 있기 때문에 MFA 구조로 설계한다면 보다 명확하게 애플리케이션을 나눌 수 있을 것 같습니다. (실제로 운영을 한다면 보다 더 복잡한 설계가 필요할 것 입니다.)

 

위 도식에서의 플랫폼은 코드 베이스가 아닌 플랫폼 바운더리 입니다. 당근이라는 플랫폼의 통합을 관리하는 메인 애플리케이션과 각각의 서비스 단위의 애플리케이션을 잘게 나누었습니다. 각각의 애플리케이션은 개발 단계에서 독립적으로 띄울 수 있고 운영 단계에서는 통합 애플리케이션에 주입해 통합 애플리케이션에서 해당 애플리케이션을 띄우는 방식으로 운영하게 됩니다.

 

MFA는 MSA와 비슷한 면모가 많습니다. 서비스 단위로 서버를 잘게 쪼개듯이 프론트엔드 애플리케이션도 서비스 단위로 잘게 쪼개어 아키텍처를 설계합니다.

 

그럼 MFA를 왜 도입해야 할까, MFA 도입을 고민하면 좋은 시점은 언제일까에 대해서 생각해보도록 하겠습니다.

 

MFA를 왜 도입해야할까?

아키텍처를 변경하는 과정은 단순히 엔지니어링 관점에서 의사결정을 할 수 없습니다. 아키텍처를 변경하는 과정에서 조직의 변경이 필요할 수 있을 뿐더러 개발, 운영 단계에서 상당히 많은 부분이 변경될 수 있고 챙겨야 할 수 있기 때문입니다.

그럼에도 불구하고 MFA 도입을 해야하는 이유를 시뮬레이션 해보도록 하겠습니다.

 

저는 10명의 프론트엔드 엔지니어가 속해있는 팀의 프론트엔드 리더 개발자 입니다.

우리가 운영중인 서비스는 현재 메인 서비스 외에 6개의 작고 큰 서비스를 포함하고 있습니다. 서비스가 지속적으로 확장됨에 따라서 코드 베이스도 커져가고, 민첩하게 개발해야하는 단계에서 코드 중복을 고려하지 못하고 개발이 진행되며 점점 코드의 복잡도가 높아지고 있습니다. 코드 베이스가 커져감에 따라서 형상 관리에 있어서 부담감을 느끼고 있으며 개발된 코드를 빌드, 배포 하는 과정이 상당히 오랜 시간이 소요되어서 개발 생산성을 저하시키고 있습니다. 저희 서비스는 지금도 너무 잘 운영되어져 앞으로도 계속 확장될 전망입니다. 이런 시점에 개발자들의 협업하는 프로세스를 명확하게 하고 빌드, 배포 시간을 단축하여 효율적인 프론트엔드 파트를 운영하고 싶습니다. 마지막으로 하나의 서비스에서 장애가 나도 전체 서비스에 장애가 전파가 되지 않았으면 좋겠습니다. 어떤 방식을 통해서 현재 상황을 개선해볼 수 있을까요?

 

상상의 나래를 펼쳐가며 상황을 시뮬레이션 해봤습니다. 위와 같은 상황은 어떤 엔지니어든 겪을 수 있는 상황일 것 같습니다. 위 상황속에서 MFA를 도입하기 위해 설득할 수 있는 포인트가 몇 가지 존재합니다.

 

1. 지속적으로 확장되는 서비스

2. 코드 베이스의 복잡도

3. 빌드, 배포 시간의 단축

4. SPOF

 

지속적으로 확장되는 서비스

서비스가 현재까지 확장되었고 앞으로도 확장될 여지가 깊다면 이는 MFA 도입을 고려해봐야 할 시점입니다. 서비스가 이미 성숙한 단계에 머물러 앞으로 현재의 유저가 유지되거나 축소될 여지가 있다면 해당 서비스에 MFA를 도입하는건 비용 낭비일 수 있습니다. 하지만 서비스가 아직 도약기에 있어 앞으로 확장될 수 있다면 MFA로 아키텍처를 재설계해 추후 추가될 서비스를 더욱 빠르게 개발, 서빙하고 안정성 있게 프론트엔드 애플리케이션을 확장할 수 있습니다.

 

코드 베이스의 복잡도

하나의 코드 베이스로 여러 서비스를 개발하다보면 복잡도는 당연히 높아질 수 밖에 없습니다. 게다가 빠르게 확장되는 서비스에서는 코드 중복과 복잡도 (기술 부채)를 어느정도 용인할 수 있기 때문에 공통 컴포넌트 및 로직의 경우 특정 비즈니스 로직이 섞이게 된다면 다른 서비스에서 사용하기 위해 또 다른 컴포넌트를 만들어야 할 수 있고 계속해서 기술 부채가 쌓이다보면 코드 베이스의 복잡도가 높아지고 응집도는 낮아지게 됩니다. 결국 이런 상황은 새로운 개발자가 팀에 합류했을 때 인수인계에 부담감을 줄 수 있고 사이드 이펙트 또한 예측이 어려워 질 수 있습니다.

MFA를 도입하게 된다면 코드 베이스의 복잡도를 낮출 수 있습니다. 만약 공통으로 사용하는 UI-KIT이나 컴포넌트, 로직을 별도의 레포지토리로 분리하여 사용한다면 더욱 명확해질 것 입니다. 서비스 간 관계를 명확하게 하고, 통합 애플리케이션에 서비스 애플리케이션을 주입함으로써 서비스 단위의 독립성을 유지합니다. 이로 인해 서비스의 유지 보수에도 이점이 생기게 됩니다.

 

빌드, 배포 시간의 단축

하나의 커다란 코드 베이스를 빌드 후 배포하는 과정은 오랜 시간이 소요될 수 있습니다. 만약 MFA를 도입하게 된다면 변경된 서비스만 빌드 후 재배포 할 수 있기 때문에 상대적으로 빌드, 배포 시간이 단축됩니다. 이로 인해 개발자의 생산성을 향상시킬 수 있습니다.

MFA와 함께 모노레포를 도입하고 모노레포 관리 도구들에서 지원해주는 빌드 캐싱 기능을 활용한다면 빌드, 배포 시간의 단축에 대한 이점을 더욱 명확하게 누릴 수 있습니다.

 

SPOF (Single Point of Failure)

MFA로 구조를 재설계 함으로써 단일 장애 지점이라고 불리우는 장애 전파를 예방할 수 있습니다. 통합 애플리케이션에 각각의 서비스 애플리케이션에 주입해 각각의 서비스 애플리케이션에서 발생하는 장애가 다른 서비스에 영향을 끼치지 않도록 합니다.

만약 특정 서비스 애플리케이션에 장애가 발생해 이용할 수 없게 된다면 플랫폼 서비스 자체가 다운 되는 것이 아닌, 장애가 발생한 서비스만 다운되게 됩니다. 그리고 장애 조치를 통해 해당 서비스를 빌드 후 재배포 하여 정상적으로 서비스를 할 수 있도록 운영할 수 있습니다.

 

MFA로 프론트엔드 아키텍처를 재설계 한다면 위와 같은 이점을 누릴 수 있게 됩니다. 

 

MFA에 대한 고민이 유효한 시점

각 서비스와 팀의 상황이 다르기 때문에 어떤 시점이 유효한 시점이다 라는 정답을 내릴수는 없습니다.

하지만 위와 같은 상황을 겪고 있다던지, 프론트엔드 개발자들끼리 협업에 대한 어려움을 겪고 있다. 혹은 서비스의 복잡도가 개발 생산성을 저하시키고 있다 의 경우에는 아키텍처 변경을 고민해봐도 될 시점이지 않을까 싶습니다.

위에도 언급했다시피 아키텍처의 재설계는 반드시 조직 차원에서의 이해가 필요합니다. 그렇기 때문에 유관 부서와의 협업, 협의도 고려해야 합니다.

 

대표적으로 MFA를 구현하는 방식

MFA를 구현하는 방법은 여러 방법이 있습니다.

각각의 애플리케이션을 빌드 타임에 통합하는 방식, iframe을 통한 통합 방식, 마지막으로 Module Federation 방식이 있습니다.

구현하는 방식은 재각각 이지만 여러 팀에서 가장 많이 사용하고 있으며 MFA의 장점을 명확하게 누릴 수 있는 구현 방식은 Module Federation 방식 입니다.

해당 글은 MFA를 구현하는 방식에 대한 글이 아니기 때문에 Webpack을 사용해 MFA를 구현하는 방식은 다른 글을 통해서 살펴보도록 하겠습니다.

 

 

Module Federation 방식은 Webpack 5버전에 도입된 방식으로 shell, remote를 활용해 런타임에 remote 애플리케이션을 shell 애플리케이션에 주입하는 방식입니다. 런타임을 통해서 애플리케이션을 주입하기 때문에 자연스럽게 코드 스플리팅이 적용됩니다. mf-app 탬플릿을 활용해 쉽게 SPA(Single Page Application) MFA를 구현할 수 있고, NEXT.js를 활용해도 쉽게 MFA를 구현할 수 있습니다.

 

Vite를 활용한 React 프로젝트 역시 Module Federation을 활용해 MFA를 구현할 수 있습니다. 아래 플러그인은 Webpack의 Module Federation에 감명을 받고 커뮤니티에서 만들어 제공하는 플러그인입니다.

vite-plugin-fedration

 

하지만 해당 플러그인은 Vite에서 직접 제공하는 것이 아닌, 커뮤니티를 통해 오픈소스로서 제공하고 있습니다. 그렇기 때문에 해당 플러그인을 통해 프로덕션을 운영하기 위해서는 많은 고민이 필요합니다. 아직 Vite 자체에서 Module Federation을 제공하고 있지는 않지만, Evan You의 Vite 마일스톤에 Module Federation이 포함되어 있다고 하니 기대를 걸어볼 수 있겠습니다.

 

 

아래 레포지토리를 통해 Module Federation을 구현한 다양한 예제 코드를 살펴보실 수 있습니다.

레포지토리 살펴보기

 

마치며

이번 글을 통해서 MFA에 대해서 간단히 살펴보고 MFA 도입을 고민할 시점과 고민할 이유에 대해서 살펴봤습니다.

MFA는 기술이 아닌 아키텍처 입니다. 아키텍처를 구현할 수 있는 기술(방법)은 다양합니다. 하지만 아키텍처를 도입하기 위해 타당한 이유를 찾고 조직을 설득하는 과정은 명확해야 합니다.

그런 과정을 위해서 조금 더 자세하게 살펴보고 생각하고 이번 글을 통해서 흔적을 남기고 싶었습니다.

 

읽어봐주셔서 감사합니다! 다른 생각이 있으시다면 댓글은 환영입니다!