[frontend] 모노레포와 프론트엔드의 마이크로 아키텍쳐

동아리 홈페이지 리팩토링을 진행하면서, 기존 코드를 통해 하나의 레포지토리에 홈페이지와 어드민 페이지를 모두 두고 관리하게 되었다.

 

 

그리고 이 과정에서 모노레포가 무엇인지 알게되었고, 이를 정리해보고자 한다.

 

모노레포란?

위의 예시처럼 두개 이상의 프로젝트를 하나의 레포지토리에서 관리하는 소프트웨어 전략이라고 한다. 

 

이는 기존 프론트엔드 전략에서 많이 쓰이던 '모놀리식 서비스 아키텍쳐'의 단점을 보완하기 위해 만들어졌다.

 

'멀티레포'는 모노레포와 반대로 기존에 주로 쓰이던 전략이다. 여러 개의 레포를 사용하여 팀별, 혹은 프로젝트 별로 나누어 레포를 생성하고 개발한다. 보통 프로젝트 별로 완전히 분리되어 서로 영향을 주는 경우는 없지만, 실무에서는 영향을 주기도 한다고 한다.

 

출처: https://green-labs.github.io/monorepo-microfrontend

 

이 이미지를 확인하면 명백한데, 대부분은 '멀티레포 + 모놀리식 아키텍쳐'를 사용한다. 모놀리식 아키텍쳐는 기본적으로 다양한 기능이 하나의 레포에 있기 때문에, 하나의 레포 내에서 서로 강하게 연결되어있다.

 

또한 하나의 레포 내에 있기 때문에 각 기능이 모두 같은 기술 스택을 이용해야 한다. 장점은 같은 코드 베이스 내에 존재하기 때문에 네트워크 대기 시간이 발생하지 않는다고 한다.

 

모놀리식 아키텍쳐의 단점은 모듈화를 통해 해결할 수 있는데, 이는 우리가 평소 개발할 때 주의하는 것들이라고 할 수 있다.

- 자주 사용하는 로직은 재사용 가능하도록 구현
- 로직이나 값을 수정할 때 전체를 교체할 필요 없도록 구현

 

그리고 이러한 특성 덕분에 오픈 소스 프로젝트들은 주로 '멀티레포 + 모듈러 아키텍처'를 사용한다.

 

 

멀티레포의 문제점

- 각 레포별로 다른 컨벤션, 라이브러리, 프레임워크

- 새로운 프로젝트 생성 시마다 새로운 세팅의 비용적 문제

- 중복된 코드, 프로젝트 관리 비효율

 

등 다양한 문제가 발생할 수 있다.

 

물론 멀티레포는 독립적 개발이 가능해서 다른 프로젝트와의 의존성을 줄일 수 있고, 개발이 더 간단하다는 등 여러 장점이 존재하기 때문에 많이 사용된다.

 

 

마이크로 프론트엔드 아키텍쳐

데이터 단위로 작게 나누어 여러개의 독립적인 프론트엔드 앱을 모아서 더 큰 하나의 앱을 구성하는 아키텍쳐이다.

 

가장 유명한 예시로는 구글 서비스가 될 수 있다. 구글의 메일, 드라이브, 캘린더 등 서비스들은 디자인과 기능을 통합 시켰지만 여러 서브도메인에 걸쳐서 독립적인 앱으로서 실행되고 있다고 한다! 

 

 

이는 서로 다른 도메인이지만 마치 같은 페이지간 이동하는 것 같은 착각을 일으킨다.

 

이러한 마이크로 프론트엔드 아키텍쳐를 통해 서비스는 

- 각 마이크로 서비스는 독립적으로 개발, 배포, 확장이 가능하기 때문에 서비스 유연성이 올라간다. (리펙토링 용이)
- 공유 가능한 위젯이나 페이지를 통해 업그레이드가 쉽다.

 

등 여러 장점이 존재한다.

 

 

 

모노레포와 마이크로 프론트엔드 아키텍쳐

모노레포 개발을 하면 노드 패키지 매니저로 'Yarn-Berry'를 많이 사용한다고 한다. 그 이유로는 PnP 방식을 이용해 노드 모듈 폴더 없이 관리가 가능하고, 여러 패키지를 하나의 레포에서 관리하기 용이하기 때문이다.

'Yarn-Berry'는 여러 프로젝트를 하나의 레포에서 관리하는 모노레포에는 특히 효율적이라고 할 수 있다.

 

마이크로 프론트엔드 아키텍쳐는 독립적인 프론트엔드 앱으로 하나의 앱을 구성하는 만큼, 각 독립적인 앱들을 다양한 레포에서 관리한다면 구현이 어려울 것이다. 따라서 이 때 모노레포를 사용하는 것이다.

 

각 독립적인 앱들을 모노레포를 사용하여 하나의 레포에서 관리한다면 같은 컨벤션과 디자인, 폴더 구조 등을 통해 더 효율적이고 유지보수가 쉬워질 것이라고 생각한다. 또한 여러 패키지간의 의존성도 관리하기 쉬워질 것이다.

 

프론트엔드 아키텍처의 핵심 요소 중 하나는 성능 최적화이다. 모노레포는 프로젝트 간의 의존성을 최적화하고, 불필요한 중복 패키지를 줄이며 빌드 성능을 개선할 수 있는 구조를 제공한다. 또한, 모노레포에서는 공통 패키지의 의존성 충돌을 쉽게 해결하고, 전반적인 패키지 업데이트를 한 번에 처리할 수 있기 때문에 프로젝트 규모가 커질수록 유리하다고 할 수 있다.

 

 

결론

 

프론트엔드 아키텍처와 모노레포는 대규모 애플리케이션에서 코드 재사용성, 협업 효율성, 성능 최적화를 위한 강력한 조합이다. 모노레포를 활용하면 프론트엔드 아키텍처에서 여러 프로젝트 간의 의존성, 코드 공유, 빌드 및 배포를 체계적으로 관리할 수 있어, 대규모 애플리케이션 개발에 유용할 것이다.

 

 

 

 

 

.

.

.

.

참고자료

 

모노레포 - 마이크로 아키텍처를 지향하며

모노레포 이렇게 좋은데 왜 안써요?