이 글은, https://martinfowler.com/articles/micro-frontends.html 페이지를 번역한 글 입니다.
저는 번역 경험이 거의 없습니다. 서투른 글이라 번역체의 분명하지 않은 문장 표현들이 종종 있겠습니다만.. 너그러이 보아 주셨으면 좋겠고, 얼마든지 개선점이나 조언 주시면 감사하겠습니다. 저는 이 문서의 내용이 분명 우리에게 도움이 될 것이라 생각하고, 많은 분들과 나누고 싶습니다.
(그리고 문서가 좀 깁니다. 따로 편집하거나 요약하지 않았습니다.)
미흡한 자료 보아 주셔서 감사합니다 :)
Contents
(이 페이지에서 볼 내용 끝에 * 로 표시)
• 이점 (Benefits)
⁃ 점차적인 업그레이드 (Incremental upgrades)
⁃ 단순하고 분리된 코드베이스 (Simple, decoupled codebases)
⁃ 독립적인 배포 (Independent deployment)
⁃ 자율적인 팀 (Autonomous teams)
⁃ 간단히 말해서 (In a nutshell)
• 예제 (The example)
• 통합에 대한 접근 방식 (Integration approaches)
⁃ 서버사이드 템플릿 구성 (Server-side template composition)
⁃ 빌드 타임 통합 (Build-time integration)
⁃ iframe을 통한 런타임 통합 (Run-time integration via iframes)
⁃ JavaScript를 통한 런타임 통합 (Run-time integration via JavaScript)
⁃ 컴포넌트를 통한 런타임 통합 (Run-time integration via Web Components)
• 스타일링 (Styling)
• 공유컴포넌트 라이브러리 (Shared component libraries)
• 어플리케이션 간 통신 (Cross-application communication)
• 백엔드 통신 (Backend communication)
• 테스팅 (Testing)
• 상세 예제 (The example in detail)
⁃ 컨테이너 (the container)
⁃ 마이크로 프론트엔드 (The micro frontends)
⁃ 라우팅을 통한 어플리케이션 간 통신 (Cross-application communication via routing)
⁃ 공통 컨텐츠 (Common content)
⁃ 인프라 (Infrastructure)
• 단점 (Downsides) *
⁃ 페이로드 크기 (Payload size) *
⁃ 환경의 차이 (Environment differences) *
⁃ 운영 및 거버넌스 복잡성 (Operational governance complexity) *
• 결론 (Conclusion) *
단점
이 글의 시작에서 모든 아키텍처와 마찬가지로 Micro Frontends 에도 장단점이 있다고 언급했습니다. 앞서 언급한 이점들에는 비용이 수반되며, 여기서 다루겠습니다.
1. 페이로드 크기
각각 독립적으로 구축된 JavaScript 번들은 의존성의 중복을 야기하여 최종 사용자에게 네트워크를 통해 전송해야 하는 바이트 수를 증가시킬 수 있습니다. 예를 들어, 모든 마이크로프론트엔드 어플리케이션에 각각 React 가 포함되어 있다면, 고객에게 React 를 n 번 다운로드하게 합니다. 페이지 성능과 사용성 사이에는 직접적인 관계가 있습니다. 고도로 발달된 도시 외에는 대부분 훨씬 느린 인터넷 환경에서 실행되기 때문에, 우리는 다운로드 크기에 대해 신경을 써야 합니다.
이 문제는 해결하기 쉽지 않습니다. 팀이 App을 독립적으로 컴파일하여 자발적으로 작업하게 하려는 욕구와, 공통된 dependency를 공유 가능한 방식으로 어플리케이션을 빌드하고자 하는 욕구 사이에는 팽팽한 긴장감이 있습니다. 하나의 접근법은 우리가 데모 앱에서 설명했던 방법으로, 컴파일된 번들로부터 공통 dependency를 외부화하는 것입니다.
하지만 이 방식을 따라가자마자, 어플리케이션에 약간의 빌드 타임 커플링을 다시 발생시켰습니다. 그것은 그들 사이에 생긴 “우리 모두는 이러한 dependency의 정확한 버전을 사용해야 한다”는 암묵적인 계약입니다. 종속성에 큰 변화가 있는 경우, 우리는 결국 대규모로 조정된 업그레이드 작업이나 한꺼번에 전체를 릴리즈할 필요가 있을 수 있습니다. 이것은 우리가 처음부터 마이크로 프론트엔드 아키텍쳐를 통해 피하려고 노력했던 것입니다!
이 내재된 긴장감은 어려운 문제이지만 항상 나쁜 소식인 건 아닙니다.
첫째, 중복 dependencies에 대해 아무것도 하지 않더라도, 하나의 모놀리틱 프론트엔드보다 개별 페이지가 더 빨리 로드될 수 있습니다. 그 이유는, 각 페이지를 독립적으로 컴파일함으로서, 코드를 효과적으로 분할했기 때문입니다.
고전적 모노리스에서는 어플리케이션의 페이지가 로드될 때마다 모든 페이지의 소스 코드와 dependencies를 한꺼번에 다운로드합니다. 독립적으로 빌드함으로써, 모든 단일 페이지는 해당 페이지의 소스 및 dependencies만 다운로드합니다. 이로 인해 초기 페이지 로드는 빨라질 수 있지만, 사용자가 각 페이지에서 동일한 패키지를 다시 다운로드해야하므로 후속으로 진행되는 페이지 탐색은 느려질 수 있습니다. 불필요한 dependencies로 어플리케이션을 부풀리지 않거나, 사용자가 일반적으로 어플리케이션 내에서 한 두 페이지만 사용한다는 사실을 안다면, 패키지가 중복 되더라도 성능면에서 이득을 얻을 수 있습니다.
이전 단락에는 “may”및 “possibly ‘s”가 많이 있는데, 모든 어플리케이션에는 항상 고유한 성능면의 특성이 있음을 강조합니다. 어떤 변경이 성능에 어떤 영향을 미칠 지 확실하게 알고 싶다면, 실제 측정 말고는 달리 대안이 없습니다. 우리는 팀이 몇 KB단위의 자바스크립트에 대해 고민하는 걸 본 적이 있는데, 알고보니 이는 MB단위의 고해상도 이미지를 다운로드하거나, 매우 느린 데이터베이스에 대해 고가의 쿼리를 실행하기 위해서였습니다. 따라서, 모든 아키텍처에서 성능 이슈를 고려하는 것은 중요하지만, 실제 병목이 어디서 일어나는지에 대해 확실히 점검해야 합니다.
2. 환경의 차이
우리는 다른 팀이 개발한 다른 모든 Micro Frontends에 대해 고려할 필요없이 하나의 Micro Frontends를 개발할 수 있어야 합니다. 프로덕션 환경에 보관할 컨테이너 어플리케이션 내부가 아니라, 빈 페이지에서 Micro Frontends를 “독립 실행형” 모드로 실행할 수도 있습니다. 특히 실제 컨테이너가 복잡한 레거시 코드베이스일 때 개발이 훨씬 간단해질 수 있는데, 주로 Micro Frontends를 사용하여 레거시에서 새로운 코드로 점진적으로 마이그레이션 할 때 그렇습니다. 그러나 프로덕션과는 완전히 다른 환경에서 개발을 진행함으로서 발생할 수 있는 위험이 있습니다. 개발 시점의 컨테이너가 프로덕션 컨테이너와 다르게 동작한다면, Micro Frontends가 고장나거나, 프로덕션 환경에 배포했을 때 다르게 작동할 것임을 알 수 있습니다. 특히 우려스러운 부분은, 컨테이너나 다른 Micro Frontends가 가져올 수 있는 전역 스타일입니다.
여기서 해결책은 환경의 차이점에 대해 걱정해야 하는 다른 상황과 다르지 않습니다. 우리는 프로덕션과 같은 환경이 아닌 상태에서 로컬로 개발하는 경우, Micro Frontends를 프로덕션 환경과 같은 환경에 정기적으로 통합하고 배포 할 수 있도록 할 필요가 있습니다. 그리고 통합 문제를 가능한 한 빨리 파악하기 위해 수동 및 자동화테스트를 같은 환경에서 수행해야 합니다. 이것이 문제를 완전히 해결하지는 못하지만, 궁극적으로 우리가 무게를 두어야 하는 또다른 포인트입니다 : 단순해진 개발 환경의 생산성 향상이 통합 이슈의 위험을 무릅쓸 가치가 있습니까? 대답은 프로젝트에 달려 있습니다!
3. 운영 및 거버넌스 복잡성
마지막 단점은 마이크로 서비스와 직접 평행한 단점입니다. 더 분산된 아키텍처로서, Micro Frontends 는 필연적으로 더 많은 것들을 고려하고 관리해야 됩니다. — 더 많은 레파지토리, 더 많은 빌드/배포 파이프라인, 더 많은 서버, 더 많은 도메인 등. 그래서, 이 아키텍처를 채택하기 전에 고려해야 할 몇 가지가 있습니다 :
- 추가로 필요한 인프라를 적절히 프로비저닝하고 관리하기에 충분한 자동화 기능을 갖추고 있습니까?
- 프론트엔드 개발, 테스트 및 릴리스 프로세스를 여러 어플리케이션으로 확장 가능합니까?
- 툴링 및 개발 프랙티스에 대한 결정이 보다 분산되고 통제하기 어려워질 텐데, 괜찮겠습니까?
- 많은 독립적인 프론트엔드 코드베이스에서 최소한의 품질, 일관성, 거버넌스 수준을 어떻게 보장하시겠습니까?
우리는 아마도 이 주제들에 대해 토론하는 또 다른 기사들을 작성할 수 있을 것입니다. 우리가 만들고자 하는 요점은, 당신이 Micro Frontends Architecture를 선택할 때 정의상 하나의 큰 것이 아니라 많은 작은 것들을 생성하는 것을 선택하는 것입니다. 혼란을 일으키지 않고 그러한 접근 방식을 채택하는데 필요한 기술적, 조직적인 성숙도가 있는지 그 여부를 고려해야 합니다.
결론
프론트엔드 코드베이스가 지난 몇 년 동안 계속해서 복잡해짐에 따라, 더 확장 가능한 아키텍처에 대한 필요성이 커지고 있음을 알게 되었습니다. 우리는 기술적 요소와 도메인 요소 사이의 적절한 결합과 그 결합 수준을 설정하는 명확한 경계를 이끌어 낼 수 있어야 합니다. 우리는 독립적이고 자율적인 팀들에 걸쳐 소프트웨어 딜리버리를 확장할 수 있어야 합니다.
유일한 접근 방식은 아니지만, Micro-Frontends 가 이러한 이점을 제공하는 실제 사례를 많이 보아 왔으며, 점차 이 기술을 새로운 코드베이스뿐만 아니라 레거시 코드베이스에도 적용할 수 있었습니다. Micro-Frontends 가 여러분과 여러분의 조직에 적합한 접근 방식인지 아닌지는 몰라도, 우리는 이것이 프론트엔드 엔지니어링과 아키텍처가 지속적인 트렌드의 일부가 되기를 바라고, 진지하고 당연한 것으로 여겨지기를 바랍니다.
