MFA 강의를 수강하고

 
지난 7월 21일 MFA 강의 수강을 시작하면서 글을 작성했다.

MFA, Monorepo 강의 수강을 시작하며

 
두 달이 지난 시점에서 강의를 완강했다. 부록 한 파트가 남긴 했는데 레거시 환경에서의 점진적 전환에 관한 파트는 넘어가도 괜찮겠다는 생각이 들어서 수강하지 않았다.
 
강의를 듣기 전까지는 MFA에 대해서 자세하게 알지 못했다.
MSA는 근무한 팀에서도 택하고 있는 아키텍처이고, 화제성이 많은 아키텍처이기 때문에 잘 알고 있었다.
MFA도 MSA처럼 프론트엔드 애플리케이션을 서비스 단위로 쪼개는 것에 대해서는 알고 있었지만, 정확히 어떤 방식으로 구현을 할지에 대해서는 생각해보지 못했던 것이다.
회사에서도 MFA에 대한 이야기가 나왔고, 평상시에 MFA와 모노레포에 대한 두려움을 가지고 있었고 요즘 많은 채용 공고의 JD에서 확인할 수 있었기 때문에 해당 기술은 내 커리어에 있어서 반드시 알아야 하는 기술이라고 생각이 들었다.
그렇게 해당 강의를 수강하고 다양한 프론트엔드 도구들과 기술들에 대해서 하나씩 알아보고 실습을 통해 토이 프로젝트로 MFA를 구현하는 단계까지 끝냈다.
 
강의를 수강하고 나서 든 생각은 MFA는 특정 기술이 아닌 아키텍처 라는 것 이다.
MFA를 특정 기술처럼 생각하고 이야기 하는 내용을 많이 들었지만 강의를 듣고 나서는 MFA는 결국엔 A(Architecture)일 뿐 구현하는 방법(기술)은 다양하다 라는 것 이다.
따라서 MFA에 접근을 하려고 한다면 기술적인 관점 보다는 아키텍처 적인 관점과 조직, 비즈니스적인 관점에서 접근을 해야 한다는 생각이다.
 
특정 서비스를 운영하다보면 트레픽이 늘어나고, 고객의 다양한 니즈를 충족시키기 위해 다양한 하위 서비스가 운영될 수 있다. 서비스가 확장됨에 따라서 조직의 규모가 확장이 되고, 중복되는 코드베이스, 늘어나는 협업의 비용, 애매해지는 오너십에 대한 문제가 생길 수 있다.
이런 문제를 단번에 해결할 수 없지만 아키텍처적인 관점에서 해결할 수 있는 것이 MFA 라고 생각한다.
 
MFA를 도입해 중복되는 코드를 패키지 단위로 분리해 재사용 하고, 서비스를 App 단위로 분리해 개발, 운영을 하며 코드 베이스의 컨플릭을 방지하며 낭비되는 협업의 비용을 줄인다. 그리고 마지막으로 분리된 App을 통해 해당 서비스의 오너쉽을 명확히 하여 소비자가 더욱 신뢰할 수 있는 서비스를 만든다. MFA를 도입할 경우 위 문제를 가장 이상적이고 아름다운 방안으로 해결할 수 있다.
 
하지만 MFA가 만능은 아니다. MFA를 도입하려면 조직적인 관점에서도 개편이 필요한 법이다. 또한 현재의 개발 문화를 변경해야 할 수 있기 때문에 조직원들의 충분한 공감과 이해가 필요하다.
 
지난 7월 강의를 수강할 시점에 팀 내에서 논의했던 MFA에 대한 이야기는 미뤄질 것 같다. 폭풍같던 8월이 흘러갔고, 폭풍의 결과로 다른 팀에 배치되어 프론트엔드를 보고 있기 때문이다. 하지만 결국 다시 원래의 팀과 원래 개발했던 제품으로 돌아갈 것이고 그때서야 MFA에 대한 이야기를 다시 한번 논의해볼 수 있지 않을까 생각한다.
 
아직은 익숙하지 않은 MFA를 조금 더 연습하고 싶어서 당근을 모티브로 아키텍처를 나누는 연습(토이 프로젝트)을 해보고 있다. 아직은 시작 단계여서 작은 코드 베이스 이지만, 연습을 통해 MFA에 조금 더 가까워지고 싶다는 생각이다.
 
MFA에 대해서 궁금하고 학습을 원한다면 아래 강의를 수강해보는 것도 괜찮을 것 같다. 
 

Micro Frontend부터 모노레포까지 대규모 서비스를 위한 프론트엔드 아키텍처