게시일

모노레포(Monorepo) 마이크로 프론트엔드(Micro frontends) 아키텍처

작성자
  • 이름
    Twitter
시리즈: 마이크로 프론트엔드
에피소드: (1/1)
  • 모노레포(Monorepo) 마이크로 프론트엔드(Micro frontends) 아키텍처

마이크로 프론트엔드(Micro frontends)

모노리식 프론트엔드는 애플리케이션의 모든 기능이 단일 코드베이스에 포함되어 있습니다. 이 방식은 초기 개발 속도가 빠르고, 빌드 및 배포 설정이 단순하며, 개발 환경 구성도 쉽습니다. 모든 기능이 함께 빌드되고 테스트되므로 일관성 유지에 장점이 있지만, 프로젝트 규모가 커질수록 문제가 발생합니다. 예를 들어, 작은 변경 사항 하나가 전체 애플리케이션의 빌드 시간배포 속도에 영향을 미칠 수 있습니다. 또한, 시스템이 복잡해질수록 팀 간 커뮤니케이션 비용이 급증하고, 특정 기능에 문제가 생길 경우 장애가 전체 시스템에 파급될 위험이 큽니다.

마이크로 프론트엔드는 애플리케이션을 독립적인 기능 단위로 나누어 관리합니다. 각 단위는 별도의 팀이 개발하고, 독립적으로 빌드배포할 수 있습니다. 이렇게 하면 각 기능이 분리된 코드베이스에서 관리되기 때문에 프로젝트가 대규모로 확장되더라도 팀들이 자율적으로 작업할 수 있습니다. 마이크로 프론트엔드는 기술 스택도 유연하게 선택할 수 있어, 팀이 필요에 따라 최적의 기술을 사용할 수 있습니다. 다만, 이 구조는 런타임 통합 및 서비스 간 커뮤니케이션이 필요해 아키텍처 복잡성이 증가할 수 있습니다.

모노리식 프론트엔드(Monolithic frontend) vs. 마이크로 프론트엔드(Micro frontends)

특성모노리식 프론트엔드마이크로 프론트엔드
초기 개발 속도빠르다느리다
빌드/배포 설정단순복잡
개발 환경 설정간단복잡
커뮤니케이션 비용시스템 커질수록 커짐작음
배포 시간느리다빠르다
에러/장애 파급 범위크다작다
자율성낮다높다

언제 마이크로 프론트엔드가 필요한가?

  • 규모가 큰 모놀리식 프론트엔드(monolithic frontend) 아키텍처에서 발생하는 문제 해결을 위해:
    • 작업을 위한 커뮤니케이션 비용이 증가하고, 팀 간 협업이 어려워진다.
    • 기존 코드베이스에서 새로운 기능을 추가할 때 예상치 못한 버그가 발생할 수 있다.
    • 간단한 수정 사항이 전체 시스템 빌드 및 배포 시간을 늘리며 비효율적이 된다.
    • 같은 기능을 제공하기 위해 중복 작업이 발생할 위험이 있다.
  • 각 팀이 충분한 인원을 갖추고 있고 독립적인 작업이 필요한 경우:
    • 프론트엔드 개발자가 많아 각 팀이 자율적으로 프로젝트를 진행할 수 있을 때.
    • Cross-functional 팀(디자인, 개발, QA 등)을 구성할 수 있는 환경이 마련되어 있을 때.
  • 서비스가 기능적으로 URL 경로 등을 기준으로 분리 가능한 경우.
  • 런타임에 여러 마이크로 앱을 선택적으로 조합해서 제공해야 하는 경우.
  • 각 마이크로 앱이 독립적으로 클라우드 자원을 활용하거나 인프라를 관리할 필요가 있는 경우.

마이크로 프론트엔드 아키텍처 장점

  • 복잡성이 줄어들고 관리하는 코드량이 줄어들어 코드 퀄리티 향상.
  • 테스트 및 배포 범위가 작아져 빌드 시간 단축과 함께 리스크 감소.
  • 특정 기능에서 문제가 발생하더라도 전체 시스템에 미치는 영향이 적어 단일 장애 지점(Single point of failure) 을 피할 수 있음.
  • 각 팀이 독립적으로 개발 및 배포할 수 있어 오너십자율성이 높아짐.
  • 점진적 개선 및 기술 업그레이드가 수월해져 장기적으로 프로젝트를 유지하기 쉬움.
  • 팀이 자신에게 맞는 기술 스택을 선택할 수 있어 효율적인 개발 가능.
  • 서로 다른 팀들이 동시에 작업하더라도 개발 주기가 더 빨라짐.

마이크로 프론트엔드 단점

  • 중복 코드가 발생할 가능성이 있어, 리소스 관리에 신경 써야 함.
  • 아키텍처 초기 구축 시 비용이 크며, 학습 곡선이 존재함.
  • 서비스 간 통합 및 커뮤니케이션이 복잡해져 추가적인 인프라 설정 필요.
  • 빌드 시 문제는 없을 수 있으나, 런타임 통합 중 오류가 발생할 수 있음.
  • 전체적인 리소스 크기가 커질 수 있어 성능 최적화 필요.
  • 일관적인 사용자 경험(UX) 을 제공하기 위해 추가적인 장치나 정책 필요.
  • 기술 격차로 인해 팀 간 기술 부조화가 발생할 위험이 있음.

마이크로 프론트엔드 기술 / 도구

  • Nginx와 proxy를 사용한 페이지 분리 및 통합.
  • Nginx와 SSI(Server-side Includes) 를 사용하여 서버에서 기능을 통합.
  • Web components로 클라이언트에서 런타임 통합.
  • iframe을 사용하여 다양한 마이크로 앱을 런타임에 통합하는 방식.
  • Webpack Module Federation으로 다양한 마이크로 앱을 동적 로딩 및 공유.

모노레포(Monorepo)

  • "모노레포는 여러 프로젝트가 단일 리포지토리에 포함되어 있는 구조입니다."
  • 마이크로 프론트엔드 아키텍처에서 모노레포 사용은 필수는 아니지만, 효율성을 높일 수 있습니다.

마이크로 프론트엔드에서 모노레포의 장점 / 단점

  • 모든 프로젝트가 한 리포지토리에 있어 설정이 일관성을 가지며, 동일한 개발 경험(DX)을 제공합니다.
  • 전체 프로젝트의 히스토리를 한눈에 파악할 수 있습니다.
  • 기존 코드를 재사용할 때 비용이 작고, 프로젝트 생성 비용이 낮아집니다.
  • 상대적으로 의존성 연결이 쉬워 과도한 연결이 발생하지 않도록 관리 필요.
  • 하나의 CI/CD 파이프라인으로 통합 가능하며, 전체적인 개발 프로세스를 효율적으로 관리할 수 있습니다.
  • 모노레포 툴을 사용하여 성능 분석 및 프로젝트 관리가 용이합니다.

모노레포 기술 / 툴

  • Package manager workspaces:
    • npm workspaces, yarn workspaces, pnpm workspaces.
  • Lerna, Nx, Rush, Turborepo와 같은 관리 툴:
    • 캐싱 기능으로 빌드 속도 향상.
    • 작업 오케스트레이션을 통해 빌드 프로세스를 최적화.
    • 변경 사항 감지로 효율적인 재빌드 가능.
    • 의존성 관계 시각화로 코드 구조 이해에 도움.
    • 코드 공유 및 효율적인 리소스 관리.