요즘 프론트엔드 분야 기술 블로그와 유튜브 영상, 교육 콘텐츠, 콘퍼런스 발표에서 꾸준히 등장하는 키워드가 있는데요. 바로 ‘마이크로프론트엔드(Micro Frontend)’입니다. 이는 오늘날 프론트엔드 기술 트렌드이자 웹 개발의 혁신적인 아키텍처 패턴으로 꼽히는데요. 프론트엔드를 개별로 개발, 배포할 수 있는 더 작고 독립적인 단위 또는 모듈로 세분화하는 게 특징이죠. 마이크로프론트엔드는 모놀리식 프론트엔드 한계를 보완할 수단으로 주목받습니다.
저는 프론트엔드 엔지니어로서 마이크로프론트엔드를 깊이 알고자 여러 자료를 찾아보고 개념과 특징, 적용 방법 등을 학습했는데요. 오늘은 제가 학습 과정에서 정리한 마이크로프론트엔드 지식을 나누고자 합니다. 지금부터 마이크로프론트엔드 개념과 특징, 등장 배경, 장단점, 도입 시 고려 사항과 모범 관행을 자세히 살펴보겠습니다.
마이크로프론트엔드 개념과 특징
마이크로프론트엔드는 대규모 웹 애플리케이션의 프론트엔드 개발을 위한 아키텍처 패턴입니다. 이는 웹사이트나 웹 애플리케이션을 ‘독립적인 팀이 소유한 기능의 구성’으로 보는데요. 애플리케이션을 작고 독립적인 모듈로 분할하며, 이 모듈은 개별로 개발, 배포, 유지 관리하는 게 기본 아이디어죠.
다시 말하면, 마이크로프론트엔드는 프론트엔드를 애플리케이션의 특정 기능이나 특징을 각각 담당하는 여러 독립적인 모듈로 나누는데요. 예를 들어, 쇼핑몰 웹사이트에 마이크로프론트엔드를 적용하면 상품 목록, 로그인, 회원가입, 장바구니, 결제 등 기능을 별도 프론트엔드 모듈로 분리할 수 있습니다.
마이크로프론트엔드는 모듈식 접근방식을 취해 유연성, 확장성, 독립적 개발에 도움이 됩니다. 핵심 특징은 다음과 같은데요.
- 파트는 세분화되고, 도메인 경계는 두텁습니다. 이에 각 기능은 각 마이크로프론트엔드 안에서 작동합니다.
- 애플리케이션이 느슨하게 결합했습니다. 따라서 모든 컴포넌트를 독립적으로 구축, 배포, 확장할 수 있으며, 이는 독립적으로 실패할 수 있습니다.
- 팀은 자율적으로 운영됩니다. 이에 기술 스택을 자유롭게 채택할 수 있 고, 다른 개발팀과 릴리즈를 조율할 필요가 없습니다.
- 각 팀의 애플리케이션 코드는 분리됐습니다. 같은 프레임워크를 사용할 때도 여러 작업팀 간에 런타임은 공유되지 않습니다. 애플리케이션에 글로벌 변수나 공유 상태가 없습니다.
- 각 마이크로프론트엔드를 하나의 페이지에서 응집력 있는 형태로 결합합니다.
마이크로프론트엔드 등장 배경
‘마이크로프론트엔드’라는 용어는 2016년 ThoughtWorks Technology Radar에 처음 등장했습니다. 마이크로프론트엔드가 필요한 이유는 오늘날 애플리케이션이 복잡하고, 기능이 다양하며, 규모가 커지면서 모놀리식 프론트엔드에 한계가 나타났기 때문인데요. 대규모 애플리케이션에는 기능과 코드가 많아 유지 관리하고 확장하기 어렵습니다. 모놀리식 프론트엔드에서는 모든 컴포넌트와 기능이 상호 연결됐고, 서로 의존하는데요. 따라서 애플리케이션이 성장함에 따라 이를 확장하고, 유지 관리하며, 업데 이트하기가 힘듭니다.
아울러 모놀리식 프론트엔드는 단일 기술 스택을 사용해 구축되기에 새로운 도구나 프레임워크를 채택하기 어려운데요. 미국 IT 기업 Infracloud에 따르면, 새로운 기술을 통합하려면 상당한 리팩토링이 필요합니다. 또 애플리케이션의 특정 부분에 더 효율적이고, 현대적이며, 적합한 기술을 사용해야 하고요. 이에 소프트웨어 개발 분야에서는 마이크로프론트엔드가 대두됐습니다.
마이크로프론트엔드는 마이크로서비스 개념을 프론트엔드 분야에 확장했는데요. 그동안 개발자들은 데이터베이스, 백엔드, 프론트엔드를 한 곳에서 관리하는 모놀리식 아키텍처로 복잡한 문제를 해결하는 데 한계를 느꼈습니다. 이에 백엔드와 프론트엔드 개발을 분리해 복잡도를 낮추려 했는데요. 결과는 효과적이었지만 복잡도를 더 줄일 방법이 필요했죠.
따라서 백엔드 진영에서는 하나의 백엔드를 서로 다른 서비스로 나누고 모듈화해 개별로 개발, 배포, 확장하는 마이크로서비스가 등장했고요. 이는 애플리케이션을 작고 독립적인 서비스 단위로 분리해 복잡한 문제를 더 쉽고 유연하게 해결했습니다. 한편, 프론트엔드 개발에도 여러 병목 현상이 있었는데요. 마이크로서비스 개념을 프론트엔드에도 적용해 문제를 개선하고자 했죠.
마이크로프로트엔드 장점
마이크로프론트엔드 장점으로 크게 4가지를 꼽을 수 있습니다.
독립적이고 자유로운 기술 선택
마이크로프론트엔드를 사용하면 여러 팀이 애플리케이션의 다양한 부분을 독립적으로 작업할 수 있습니다. 각 팀은 각 마이크로프론트엔드에 적합한 기술, 프레임워크를 선택할 수 있는데요. 즉, 특정 작업에 따라 아키텍처, 기술 스택, 코딩 스타일, 테스트 등을 스스로 결정할 수 있죠. 이로써 팀은 제약을 덜 받고, 동기를 더 부여받아 더 높은 품질의 코드를 작성할 수 있습니다.
개발, 릴리즈 속도 향상
마이크로프론트엔드를 사용하면 여러 소규모 팀이 동시에 다양한 기능을 개발, 배포해 개발 시간을 줄이고, 릴리즈 속도를 높일 수 있습니다. 이는 단일팀이 모든 새로운 기능을 구현하는 모놀리식 프론트엔드와 대조적이죠. 마이크로프론트엔드를 구축하는 건 거대한 모놀리식 소프트웨어를 구축하는 것보다 훨씬 더 빠르고 쉬운데요. 이는 프론트엔드 개발 프로세스를 크게 향상해 새로운 기능을 신속히 구현하는 데 도움이 됩니다.
유지 관리 용이
마이크로프론트엔드는 작은 부품 단위로 구성돼 테스트하고 유지 관리하기 쉽습니다. 작은 소프트웨어 부분으로 작업하면, 각 기능의 워크플로를 더 잘 이해할 수 있어 원활한 유지 관리에 도움이 되죠. 아울러 마이크로프론트엔드의 코드양은 모놀리식 프론트엔드보다 상당히 적은데요. 코드를 관리하기 쉬워 개발자가 실수할 가능성이 작습니다. 개발자는 노력을 적게 들이면서 빠르게 작업해 생산성을 향상할 수 있고요.
공통 기능 재사용
마이크로프론트엔드는 공통 워크플로 요구사항이 있는 여러 애플리케이션을 개발할 때 유용하죠. 이는 공통 기능을 재사용해 새로운 애플리케이션을 만드는 시간과 노력을 줄일 수 있는데요. 예를 들어, 회사에 결제 처리 기능이 필요한 여러 사이트가 있을 때, 매번 기능을 처음부터 개발하는 대신, 모든 애플리케이션에서 같은 기능을 수행하는 마이크로프론트엔드를 가져와 반복 사용할 수 있습니다.
마이크로프로트엔드 단점
마이크로프론트엔드 단점은 크게 세 가지로 나뉩니다.
웹 애플리케이션 페이로드 확대
마이크로프론트엔드는 의존성을 복제하고, 프레임워크와 라이브러리를 번들로 묶어 웹 애플리케이션의 페이로드(전송되는 순수한 데이터) 크기를 키웁니다. 따라서 리소스를 신중히 캐싱하고, 의존성을 세심히 선택하며, 거의 사용하지 않는 페이지를 주의해서 분리해야 합니다.
웹사이트 스타일, UX/UI 일관성 약화
여러 팀이 독립적으로 마이크로프론트엔드에서 작업하면 전체 그림을 확인하지 못할 수 있죠. 이에 웹사이트 스타일과 UX/UI가 일관되지 않을 수 있습니다. 따라서 공통 컴포넌트와 스타일 가이드를 만들고, 서로 지속적으로 소통해 통일성을 유지하는 게 좋습니다.
운영 복잡성
마이크로프론트엔드를 채택하면 운영 복잡성이 발생하는데요. 이러한 접근 방식은 더 많은 리포지터리와 도구, CI/CD 파이프라인, 복잡한 인프라를 전제하기 때문입니다.
마이크로프론트엔드 도입 고려 사항
마이크로프론트엔드가 ‘요즘 트렌드’라는 이유로 이를 맹목적으로 도입하는 건 적절하지 않습니다. 프로젝트 상황을 고려해 도입 시점을 정하는 게 좋은데요. 특히 프로젝트 규모가 작을 때는 가급적 도입하지 않는 걸 권장하기도 합니다. 예를 들어, 작고 단순한 웹사이트에 마이크로프론트엔드를 구현하는 건 지나치고요. 이는 개발 프로세스를 복잡하게 만들 수 있죠.
프로젝트 초기에 ‘서비스가 어떻게 확장될지’ 모르는 상황에서 이를 임의로 나누고, 이미 나눈 서비스를 나중에 재배치하려면 어렵습니다. 서비스 방향이 잡혀 나눌 서비스 윤곽이 보일 때 분류하는 게 적절하죠. 프로젝트 규모가 커지고, 설계와 유지 관리 리소스가 충분할 때 마이크로프론트엔드를 도입하면 더 큰 효과를 누릴 수 있습니다.
마이크로프론트엔드 도입을 고려할 때, 다음 질문을 스스로 던지세요.
- 마이크로프론트엔드를 사용할 때 얻는 이점은 무엇인가? 그 이점이 크고 명확한가?
- 마이크로프론트엔드를 적용할 때 성능 문제는 없는가? 사용자에게 어떤 영향을 미칠까?
- 마이크로프론트엔드가 우리 조직의 개발 프로세스 문제를 효과적으로 해결하는가?
- 마이크로프론트엔드를 설계하고 유지 관리하는 리소스가 충분한가?
마이크로프론트엔드 방법론은 개발팀 인원, 기술 스택, 개발 방식 등에 따라 달라질 수 있는데요. 각 팀 환경에 적합한 방식을 충분히 검토해야 합니다. 또 이를 실무에 적용할 때 ‘마이크로프론트엔드 장점을 극대화하고, 단점을 최소화할 수 있는지’도 고려해야 합니다.
마이크로프론트엔드 모범 관행
미국 IT 기업 Infracloud와 콜롬비아 IT 기업 Aplyca는 다양한 마이크로프론트엔드 모범 관행을 제안하는데요. 이 중 10가지를 추려 공유합니다.
- 수평적 팀 피하기
- 팀 코드 분리하기
- 의존성 관리 워크플로 만들기
- CI/CD 수용하기
- 컴포넌트 라이브러리 사용하기
- 모니터링과 에러 핸들링 구현하기
- 다양한 수준으로 테스트하기
- 성능 최적화 기술 적용하기
- 마이크로프론트엔드에 적합한 규모 찾기
- 너무 많은 마이크로프론트엔드 만들지 말기
맺음말
지금까지 마이크로프론트엔드 개념과 특징, 등장 배경, 장단점, 도입 시 고려 사항과 모범 관행을 알아봤습니다.
마이크로프론트엔드는 대규모 웹 애플리케이션의 프론트엔드 개발을 위한 아키텍처 패턴이고요. 이는 애플리케이션을 작고 독립적인 모듈로 분할하며, 이 모듈은 개별로 개발, 배포, 유지 관리할 수 있습니다.
마이크로프론트엔드를 사용하면 기술을 독립적이고 자유롭게 선택할 수 있고요. 개발과 릴리즈 속도를 높이며, 쉽게 유지 관리할 수 있습니다. 또 공통 기능을 재사용할 수 있죠. 그러나 웹 애플리케이션 페이로드가 커지고, 웹사이트 스타일과 UX/UI 일관성이 약화하는 단점이 있습니다. 운영도 복잡해지고요.
마이크로프론트엔드를 도입할 때는 프로젝트 상황을 고려하고요. 프로젝트 규모가 커지고, ‘이 접근방식이 프로젝트에 적합한지’ 확인했을 때 적용하는 걸 권장합니다.