MSA 마이크로 서비스 아키텍처, MFA 마이크로 프론트엔드 아키텍처, 모노레포

하나의 코드 베이스에 모든 것을 때려넣은 모놀리틱 아키텍처와 대비되는 개념. 모놀리틱은 구현 속도는 빠르지만 스파게트 코드가 되기 쉽다. 초기 스타트업에서 빠른 개발을 위해 모놀리틱을 사용하는 경우가 많다. 

MSA는 서비스를 잘게 쪼갠다. 예를 들어, 상품 서비스, 결제 서비스, 장바구니 서비스 등으로 쪼개서 각자 따로 관리한다.  하나의 서비스가 다른 서비스에 영향을 미치지 않는다는 장점이 있다. 

MSA를 사용할 때는 프론트와 백 사이에 API 게이트웨이를 두어서 엔드포인트를 하나로 통일할 수 있게 하는 경우가 많다. 이렇게 되면 프론트는 각각의 서버에 대해서 알 필요가 없어지고 API를 찌르기만 하면 된다. API 게이트웨이는 여러 API를 묶어주는 aggregation 역할 이외에도, 스케일링, 인증 등도 수행한다. 

 

MFA는 MSA에 맞춰 프론트엔드 구조를 짜는 것을 의미한다. 결제 페이지에서 서버가 결제, 상품, 장바구니로 나뉘었어도 프론트엔드는 그대로 하나의 결제 페이지를 보여준다면 대응이 어려울 수 있다. 즉 프론트엔드도 결제 fd, 상품 fe, 장바구나 fe로 나뉘는 것이다. 이렇게 되면 배포할 일이 더 많아지기는 하지만 각각의 기능이 격리가 가능하다. 

이렇게 구분된 fe를 하나로 통합하는 방법은 굉장히 다양하다. MFA가 권장하는 방식 중 하나는 iframe을 쓰는 것이다. 결제, 장바구니, 상품 등을  따로 배포한 뒤 통합 fe에서 iframe을 통해 불러오는 것이다. 대표적으로 네이버 지도가 iframe 격리를 사용한다. 좌측의 플레이스 따로 우측의 지도 따로 운영된다. 

그러나 이러한 방식은 개발자가 너무 많이 필요하고 ux적인 문제도 있다. 

따라서 이보다는 모노레포 방식이 더 선호된다. 

모노레포, 즉 하나의 repository 내에서 각각의 기능을(상품, 결제, 장바구니) 패키지로 구현하여 이들을 import해가는 방식으로 구현하는 것이다. 즉 모노레포는 관심사만 분리하는 것이다. 이렇게 하면 결제가 필요한 다른 페이지에서도 결제 패키지를 import하기만 하면 바로 페이지에서 사용이 가능하다는 장점이 있다. 또한 페이지와 패키지 사이에 인터페이스를 뚫어서 패키지 다운에 대한 처리를 더욱 유연하게 대응할 수 있다.

BFF 레이어는 추상화 또한 수행한다. 예를 들어 결제, 카트 서버가 따로 있고 카트에 있는 아이템을 가져와서 결제에 보내줘야 하는 플로우가 있을 때, 이런 플로우를 fe에서는 그냥 pay라는 이름으로 부르고 이것이 BFF에 전달되면 BFF는 카트 서버에서 아이템을 가져와서 결제 서버에 쏴주는 식으로 구현이 가능하다. 

BFF는 모놀리틱에서는 정말 쓸모가 없으나 MSA에서는 매우 유용하다. 아직 국내에서는 BFF를 사용하는 조직이 그렇게 많지는 않다.