[마이크로프론트엔드] Monolith vs Micro frontend

Micro frontend Architecture

• 독립적으로 운영 및 개발이 가능한 프론트엔드 애플리케이션들로 더 큰 하나의 전체 애플리케이션을 구성하는 아키텍처

• 하나의 독립적인 기능(서비스)는 독립적으로 운영

• 독립적인 CI/CD 파이프라인을 통해 독립적으로 빌드-테스트-배포

• 각 서비스는 최종적으로 유저가 사용하는 하나의 프로덕트로 합쳐지기 때문에 유저는 독립적인 서비스의 조합으로 인식하지 않음

Monolith Architecture

• 하나의 패키지에 모든 기능이 포함된 구조로 애플리케이션을 구성하는 아키텍처

• 하나의 레포지토리 내에 하나의 큰 앱만 존재하기 때문에, 모든 코드는 기본적으로 공유되며 형식이 통일되어 있음

• 최종적인 프로덕트 전체를 빌드-테스트-배포

Monolith vs Micro frontend

• 기존 Monolith frontend의 문제점 및 한계점

• 문제 1: 기능 간 의존성 문제

  • 특정 기능의 문제가 발생하면 다른 기능에도 영향을 끼치는 의존성 문제 발생

  • 서로 의존하고 있는 기능들 사이에 발생한 문제 원인 파악부터 어려움

  • 특정 기능에 새로운 것을 추가하거나 기존 코드를 수정했을 때 의존성을 가지는 다른 기능들에 문제가 발생할 수 있음을 계속해서 개발자가 고려해야함

  • → Micro frontend architecture는 다른 기능에 영향을 받지 않는 독립적인 패키지로써 개발이 가능하기 때문에 의존성 문제가 거의 발생하지 않음

• 문제 2: 비효율적인 빌드 및 배포 프로세스

  • 버그가 발생하거나 서버 인터페이스가 변경되어 코드를 수정할 때 수정된 코드를 배포하기 위한 빌드를 진행할 때 약간의 수정 사항만 있어도 전체를 다시 빌드하고 배포해야 함 (stage 기준 15~20분 소요)

  • 여러 기능을 여러 개발자가 개발하거나 수정할 때 각 팀에서 개발한 기능을 배포하기 전 코드를 합치는 과정에서 수많은 conflict 발생하여 피로도가 높음

  • → Micro frontend architecture는 독립적인 빌드-배포 프로세스로 운영할 수 있기 때문에 코드를 수정하면 해당 서비스만 배포하면 해당 서비스를 포함하는 host app 및 프로덕트에 실시간으로 반영이 됨

  • → 배포 후 반영 시간 단축, 개발 시간 절약

• 문제3: 동일 기능을 여러번 개발

  • B2B 서비스의 특성 상, 고객의 니즈나 사업적 목적에 따라 플랫폼이 다양할 수 있고 기능을 다르게 제공해줘야 함

  • 즉 하나의 서비스를 여러 개의 앱에서 운용할 때 동일한 로직을 앱마다 구현해줘야 하기 때문에 리소스의 낭비가 발생

  • 하나의 서비스의 업데이트를 위해 수정해야할 중복 코드가 늘어남

  • → Micro frontend architecture는 단일 비즈니스 로직을 여러 환경에서 사용할 수 있어 중복 코드 관리가 줄어들고 리소스의 낭비가 없음