이 글은, https://martinfowler.com/articles/micro-frontends.html 페이지를 번역한 글 입니다.
저는 번역 경험이 거의 없습니다. 서투른 글이라 번역체의 분명하지 않은 문장 표현들이 종종 있겠습니다만.. 너그러이 보아 주셨으면 좋겠고, 얼마든지 개선점이나 조언 주시면 감사하겠습니다. 저는 이 문서의 내용이 분명 우리에게 도움이 될 것이라 생각하고, 많은 분들과 나누고 싶습니다.
(그리고 문서가 좀 깁니다. 따로 편집하거나 요약하지 않았습니다.)
미흡한 자료 보아 주셔서 감사합니다 :)
Micro Frontends
좋은 프론트엔드 개발은 어렵습니다. 크고 복잡한 제품에서 많은 팀이 동시에 작업할 수 있도록 프론트엔드 개발을 확장하는 것은 더욱 어렵습니다. 이 기사에서는 모놀리틱 프론트엔드를 더 작고 관리하기 쉬운 여러 부분으로 나누는 최근 추세와 이 아키텍처가 어떻게 프론트엔드 코드에서 팀의 작업효율과 효율성을 높이는지를 설명합니다. 다양한 이점과 그 비용에 관해 이야기 할 뿐만 아니라, 사용할 수 있는 구현방법중 일부를 다룰 것이며, 이 기술을 보여주는 예제 애플리케이션 전체에 대해 자세히 살펴볼 것입니다.
2019 년 6 월 19 일
Cam Jackson은 ThoughtWorks의 풀 스택 웹 개발자 겸 컨설턴트로, 대규모 조직의 프론트엔드 개발 프로세스 및 프랙티스를 확장하는 방법에 특히 관심을 가지고 있습니다. 그는 여러 국가의 여러 업계 고객과 협력하여 웹 어플리케이션을 보다 효율적이고 효과적으로 딜리버리할 수 있도록 지원했습니다.
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-Service 는 폭발적인 인기를 얻었습니다. 많은 조직에서는 이 아키텍처 스타일을 사용하여 대규모 모놀리틱 백엔드의 한계를 피했습니다. 이처럼 서버 측 소프트웨어를 제작하는 방법에 관해 많이 쓰여지는 동안 많은 기업들이 단일체 프론트엔드 코드베이스로 계속 고심하고 있습니다.
아마도 점진적이거나 반응이 빠른 웹 어플리케이션을 만들고 싶지만 이러한 기능을 기존 코드에 쉽게 통합 할 수는 없습니다. 아마도 새로운 JavaScript 언어 기능 (또는 JavaScript로 컴파일 할 수 있는 수많은 언어 중 하나)을 사용하고 싶지만 기존 빌드 프로세스에 이러한 빌드 도구를 넣을 수는 없습니다. 또는 여러 팀이 단일 제품을 동시에 작업 할 수 있도록 개발 규모를 조정하고 싶지만 기존 모노리쓰의 결합 및 복잡성은 모든 사람이 서로의 발가락을 밟고 있음을 의미합니다. 이들은 모두 고객에게 고품질의 경험을 효율적으로 제공함에 있어서 부정적인 영향을 줄 수 있는 모든 실제적 문제입니다.
최근 복잡하고 현대적인 웹 개발에 필요한 전반적인 아키텍처와 조직 구조에 점점 더 많은 관심을 기울이고 있습니다. 특히 프론트엔드의 단일 구조를 개별적으로 개발, 테스트 및 배포 할 수 있는 작고 간단한 덩어리로 분해하는 패턴이 나타나고 있으며 이것은 고객에게 단일 응집력있는 제품으로 나타납니다. 우리는 이 기법을 Micro-Frontends 라고 부르며 , 다음과 같이 정의합니다.
“독립적으로 제공 가능한 프론트엔드 애플리케이션들로
더 큰 하나의 전체 어플리케이션을 구성하는 아키텍처 스타일”
ThoughtWorks 기술 레이더의 2016 년 11월호에는 조직이 평가해야하는 기술로 Micro-Frontends를 나열했습니다 . 우리는 나중에 이것을 Trial로 승격시켰고 마지막에는 Adopt로 승격 시켰습니다. 즉, 그렇게 하는 것이 타당할 때 사용해야 하는 입증된 접근 방법이라고 봅니다.
Micro-Frontends 에서 본 주요 이점 중 일부는 다음과 같습니다.
- 더 작고, 응집력 있고, 유지 보수가 쉬운 코드베이스
- 이전보다 더 많은 분할, 증가 방식으로 일부씩 나누어 업그레이드, 업데이트 또는 재작성할 수 있음
이러한 장점은 당연하게도 기존의 마이크로서비스가 제공할 수 있는 장점 중 일부와 동일합니다.
물론, 소프트웨어 아키텍처에는 공짜가 없습니다. 모든 것은 비용이 듭니다. 일부 Micro-Frontends 구현은 dependency의 중복을 초래하여 사용자가 다운로드해야하는 바이트 수가 증가합니다. 또한 팀 자율성이 극적으로 증가하면 팀 작업 방식이 단편화 될 수 있습니다. 그럼에도 불구하고 우리는 이러한 위험을 관리할 수 있으며 Micro-Frontends의 이점이 비용보다 중요한 경우가 있다고 판단합니다.
이점
특정 기술 접근이나 구현 세부 사항에 관해 Micro-Frontends를 정의하는 대신, 등장하는 속성과 이점에 중점을 두었습니다.
1. 점차적인 업그레이드
많은 조직에서 이것이 Micro-Frontends 여행의 시작입니다. 오래되고 커다란 프론트엔드의 단일체는 예전의 기술 스택이나 딜리버리 압박으로 작성된 코드에 의해 유지되고 있으며, 완전히 새로 구축하고 싶은 지경에 이르고 있습니다. 전체 재구축의 리스크를 피하기 위해 우리는 오래된 어플리케이션을 한부분씩 나누어 처리하는 것을 선호합니다. 그리고 그 동안 모노리스에 짓눌리지 않고 새로운 기능을 고객에게 계속 제공하려 합니다.
이는 종종 Micro-Frontends 아키텍처로 이어집니다. 한 팀이 AS-IS 코드에 대한 수정을 거의 하지 않고 새것을 제작할때까지 모든 기능이 멀쩡하다면 다른 팀에서도 새 코드작성에 참여하기를 원할 것입니다. 기존 코드는 여전히 유지,관리해야 하며 어떤 경우에는 계속해서 여기에 새 기능을 추가해야 할지도 모릅니다. 그러나 이제는 선택이 가능합니다.
여기서 우리는 제품의 개별 부분에 대해 사례별로 의사 결정을 내릴 수 있고 아키텍처, 종속성 및 사용자 경험을 점진적으로 업그레이드 할 수 있는 자유를 누리게 됩니다. 메인 프레임워크에 큰 변화가 있는 경우 각 마이크로 프론트엔드는 새 코드 작성을 멈추고 모든 것을 한꺼번에 업그레이드하도록 강요당하는 것이 아니라 언제든지 각자 업그레이드 할 수 있습니다. 우리가 새로운 기술이나 새로운 상호 작용 방식을 실험하기를 원한다면, 우리는 이전보다 훨씬 더 독립적으로 그것을 수행할 수 있습니다.
2. 단순하고, 분리된 코드베이스
개별적인 마이크로 프론트엔드의 소스코드는 정의상 단일 단일 프론트엔드의 소스 코드보다 훨씬 작습니다. 이 작은 코드베이스는 개발자가 작업하는 것이 더 쉬워집니다. 특히, 서로에 대해 알지 못하는 컴포넌트 간의 의도하지 않거나 부적절한 결합으로 인해 발생하는 복잡성을 피합니다. 어플리케이션의 제한된 컨텍스트 주위에 경계선을 그어서 우발적인 결합이 발생하기 어렵게 만듭니다.
물론, 하나의 높은 수준의 아키텍처 결정(예 : “Micro Frontends를 만들어 보자”)이 코드 품질을 높여주는 것은 아닙니다. 우리는 어떤 경우에서든 코드에 대해 생각하고 품질에 노력을 기울이는 것을 피하면 안됩니다. (이는 늘 신경써서 잘 해야 하는 문제입니다.) 대신, 우리는 나쁜 결정을 어렵게 만들고, 좋은 결정을 쉽게 내리게 만들어서 성공으로 스스로를 유도합니다. 예를 들어, 제한된 컨텍스트 내에서는 도메인 모델을 공유하는 것이 어려워지므로 개발자는 자연스레 그렇게 할 가능성이 적어집니다. 이와 같이, Micro Frontends 는 어플리케이션의 여러 부분간에 데이터와 이벤트가 어떻게 전달되는지에 대해 명시하고, 숙고하도록 유도합니다. 이는 우리가 어쨌든 해야만 했던 것입니다.
3. 독립적인 배포
마이크로 서비스와 마찬가지로 마이크로 프론트엔드의 독립적인 배치가 중요합니다. 이렇게 하면 모든 배포의 범위가 줄어들어 관련 위험이 줄어 듭니다. 프론트엔드 코드가 호스팅되는 방식이나 장소에 관계없이 각 micro frontends application에는 프로덕션 환경을 구축, 테스트 및 배포하는 자체 파이프라인이 있어야 합니다. 우리는 다른 코드베이스 또는 파이프 라인의 현재 상태를 거의 고려하지 않고 각 micro frontends 를 배치할 수 있어야 합니다. 오래된 모노리틱이 고정된 수동 분기별 릴리즈 사이클에 있든, 옆 팀이 반쯤 완료했든, 손상된 기능을 마스터브랜치에 밀어 넣었든, 상관없습니다. 주어진 micro frontend application이 프로덕션으로 갈 준비가 되었다면 그렇게 할 수 있어야 합니다.
4. 자율적인 팀
코드베이스와 출시주기를 분리하는데 더 수준높은 이점을 제공하기 때문에 아이디어를 생산에서 출시에 이르기까지 제품의 일부분을 완전히 소유할 수 있는 독립적인 팀을 확보하는 것이 중요합니다. 팀은 고객에게 가치를 전달하는 데 필요한 모든 것을 완벽하게 소유할 수 있으므로 신속하고 효과적으로 이를 수행할 수 있습니다. 이를 위해 팀은 기술 역량보다는 비즈니스 기능의 수직적 부분을 중심으로 구성되어야 합니다. 이 작업을 쉽게 수행할 수 있는 방법은 최종적으로 사용자가 볼 수 있는 내용을 기반으로 제품을 파편화하는 것입니다. 따라서 각 micro frontend application은 단일 페이지를 캡슐화하고 단일 팀이 완전히 소유합니다. 팀의 작업 그룹이 Styling, Form 또는 Validation과 같은 기술적 또는 “수평적” 관심사를 중심으로 형성되어 버리면 작업 그룹의 응집력이 높아져 버립니다.
간단히 말해서
간단히 말해, 마이크로 프론트엔드는 크고 무시무시한 것들을 더 작고 관리하기 쉬운 조각으로 분할한 다음 이들간의 종속성에 대해 명시합니다. 기술 스택, 코드베이스, 팀 및 릴리즈 프로세스는 과한 조정없이 각각 독립적으로 작동하고 진화할 수 있어야 합니다.
예제
고객이 배달음식을 주문할 수 있는 웹 사이트에 대해 생각해 봅시다. 표면적으로는 매우 단순한 컨셉이지만, 제대로 해보고자 한다면 꽤 세부적인 묘사가 가능합니다.
- 고객이 식당을 탐색하고 검색할 수 있는 랜딩페이지가 있어야 합니다. 레스토랑은 가격, 요리 또는 고객이 이전에 주문한 것을 포함하여 여러 가지 속성으로 검색과 필터링이 가능해야 합니다.
- 각 레스토랑은 메뉴 항목들을 보여주는 자체 페이지가 필요하며, 고객이 할인, 음식 결제 및 특별 요청을 통해 원하는 것을 선택할 수 있습니다
- 고객은 주문 내역을 보고, 배송을 추적하고, 결제 옵션을 설정할 수 있는 프로필 페이지가 있어야 합니다.
각 페이지마다 복잡성이 있으므로 각 부분마다 전담 팀을 쉽게 도출할 수 있으며 각 팀은 다른 모든 팀과 독립적으로 자신들의 페이지를 작업할 수 있어야 합니다. 다른 팀과의 충돌이나 조율에 대한 걱정 없이 코드를 개발, 테스트, 배포 및 유지할 수 있어야 합니다. 그렇지만 고객은 계속해서 하나의 완벽한 웹 사이트를 보아야 합니다.
이 기사의 나머지 부분에서는 필요한 모든 곳에서 이 예제 어플리케이션을 사용할 것입니다.
