Microservice
마이크로 프론트엔드(Micro-Frontends)는 요즘 흔히 이야기가 나오는 마이크로서비스 아키텍처에서 영감을 받은 새로운 아키텍처이다. 이 아키텍처의 핵심 아이디어는 모놀리식(monolithic) 코드베이스를 더 작은 부분으로 나누어,
- 여러 팀이 독립적으로 작업할 수 있으며
- 배포 규모가 작고
- 장애는 단일 서비스에만 직접 관련되게 된다.
- 또한 프레임워크와 프로그래밍 언어를 개발 팀에 맞게 자유롭게 선택할 수 있으며,
- 초기 출시 기간도 짧고 서비스 단위로 명확한 아키텍처 경계를 가지고 있다.
(당연히 위의 이야기는 잘 구축되었을 때의 해피 케이스이므로 현실에선 저렇지 않다고 너무 모라고 하시지 마시고, 열린 마음으로 계속 글을 읽어주세요ㅎㅎ)
사실 위의 장점은 마이크로 프론트엔드만의 장점이기 보다는 마이크로서비스가 갖는 장점이긴 한데 대부분 유사한 이점을 가지고 있다. 그리고 당연히 단점도 존재한다.
- 디버깅의 복잡성 증가 및 테스트가 어려워짐: 한가지 서비스에서 발생한 작은 버그 코드가 이 서비스에 의존하는 유관 서비스들로 퍼져 서비스가 장애가 난 원인의 근본 원인을 찾기가 더욱 힘들다.
- 장애(실패) 지점이 여러 서비스에서 존재
- 책임감 부족
- 버전 관리 지옥…
- 네트워킹, 지속성 계층, 통신 프로토콜, 보안 및 기타 여러 수준에서의 복합성 처리
어떤 이야기든 결론은 비슷한거 같지만, 우리 제품의 상황에 맞는 선택과 아키텍처를 적용하는게 중요하다.
Micro-frontend 등장
사실 마이크로 프론트엔드가 대부분의 서비스에서 필요한 부분은 아니었다. 왜냐하면 모든 비즈니스 로직은 서버에서 실행되었으며 클라이언트는 그 계산 결과만 표시해주는 단순한 씬 클라이언트(thin client)에 불과했기 때문이다.
하지만 시간이 지나고 우리의 웹은 사용자와 더 많은, 더 나은 상호 작용들이 늘어났으며, 프론트엔드의 크기는 점점 비대해졌다. 이젠 더이상 씬 클라이언트(thin client)라고 부를 수 없게 된 것이다. 또한 프론트엔드의 기술을 매년 진화하고 트랜드가 너무 빨리 바뀌면서 아무리 잘 관리한 프로젝트라도 몇년 후에는 그 것을 관리할 수 있는 개발자를 뽑기조차 힘들어졌다. 그렇다고 무턱대고 프로젝트 전부를 새로운 기술과 코드 베이스로 마이그레이션하거나 리펙토링하는 것은 현실적으로 힘들었으며, 이것들로 인해 새로운 기능들을 미룰 수도 없는 상황이 된다. (사실 JQuery를 사용하지 않게 될 줄은 꿈에도 몰랐다.)
우리가 가진 모놀리식 접근 방법으로는 해결하기 어려워졌고, 백엔드에서 마이크로 서비스를 통해 비슷하게 문제를 해결했듯이 프론트엔드에서도 이를 도입하여 문제를 해결하고자 했다.
Micro-frontend에 대해 좀더 생각해보자
프론트엔드를 단순하게 마이크로 서비스처럼 나눈다고 생각했을 때는 간단하게 생각할 수도 있지만, 그건 HTML을 여러개 나누어 합친다는 식으로 생각했을 때 이야기이다. 생각보다 복잡한 문제가 많이 존재한다.
전역 변수는? 기존에 번들링 했던 여러 assets들은? 개별 서비스에서 URL에 따라 잘 연동될 수 있을까? 로그인 관리는? 각각의 서비스가 모두 리소스를 새로 만들어 사용한다면 사용자의 컴퓨터의 자원이 근방 고갈될텐데 등…
위와 같은 이유를 포함해서 많은 기술적, 경험적 이유를 통해 마이크로 프론트엔드를 구축하는 것은 매우 어려운 작업이었으나, 최근에는 이와 관련해 꽤 많은 솔루션과 실제 구축 사례들이 컨퍼런스나 블로그 글 등을 통해 많이 발표되고 있다. 우리의 프론트엔드의 코드베이스가 폭발적으로 증가하고 다른 주기를 갖는 여러 프론트엔드 팀이 계속 생겨나고 있다면 마이크로 프론트엔드는 이때 발생하는 여러 문제를 나름 효과적으로 해결할 수 있는 한 방법이 될 것이다.
- 추가 장점1: 큰 모놀리식 저장소보다 여러 개의 작은 저장소를 사용하여, 문서를 쉽게 최신으로 유지할 수 있으며, 더 작은 커밋 히스토리를 유지할 수 있다.
- 추가 장점2: 외부 개발자 등과 함께 일할때 코드 베이스를 분리하여 개발을 요청한 범위 이외의 저장소에는 쉽게 접근을 막을 수도 있다.
- 추가 장점3: POC(최소 실행 가능한 제품)을 만들어 피드백을 받거나, A/B테스트 등을 하는 등의 비즈니스 관점에서도 마이크로 프론트엔드는 충분히 매력적이다.
- 추가 단점1: 어떤 코드가 어떤 저장소에 있는지 아는 것이 미덕이 되고, 시스템을 완전히 이해하려면 훨씬 더 많은 전문 지식이 필요하게 될 수 있다.
- 추가 단점2: 유지 보수가 만만치 않다.
여기까지 정말 간단하게나마 마이크로 서비스부터 마이크로 프론트엔드의 등장까지 요약해 봤다. 이제 조금씩 세부적으로 들여다 보자. 먼저 샘 뉴먼의 저서 마이크로서비스 아키텍처 구축에 나온 마이크로서비스 원칙에 대해서 먼저 살펴보려고 한다.
Microservice 원칙
아래와 같은 원칙을 수용하여 마이크로서비스를 개발하는 것을 권한다. 물론 마이크로 프론트라고 예외는 아니다.
[출처] https://samnewman.io/talks/principles-of-microservices
비즈니스 도메인을 중심으로 모델링
이는 도메인 중심 설계에서 이야기한 핵심 원칙이다. 각 소프트웨어는 조직이 하는 일을 반영하고, 우리는 비즈니스 전반에 걸쳐 유비쿼터스 언어를 활용하여 도메인 및 하위 도메인을 기반으로 아키텍처를 설계해야 한다는 가정에서 시작한다. 비즈니스 관점에서 모델링할 때 시스템에 대한 더 나은 이해, 비즈니스 도메인의 기술 표현에 대한 더 쉬운 정의, 팀이 운영해야 하는 명확한 경계 등 여러 이점을 제공한다.
자동화 문화
강력한 자동화 문화를 통해 저 빠르고 안정적인 방식으로 마이크로서비스를 적용할 수 있으며, 마이크로서비스 아키텍처의 핵심 프로세스 중 하나이다.
구현 세부 정보 숨기기
동일한 비즈니스 도메인 내에서 서비스를 캡슐화하며, API를 통해 필요한 것만 노출하고 나머지 구현은 숨긴다. 이를 통해 시스템의 나머지 부분에 영향을 주지 않고 내부 논리를 원하는 대로 변경할 수 있다.
모든 것을 분산화
기술적 문제가 있더라도 모놀리스를 사용하면 조직에서 가장 경험이 많은 사람들이 주요 의사 결정을 내리는 경우가 많고, 직면한 문제에 대해 타협점을 만들고 넘어가는 경우가 많지만, 이러한 결정을 분산화하면 팀이 직면한 문제를 기반으로 기술적인 방향을 취할 수 있으므로 전체 시스템에 긍정적 영향을 미칠 수 있다.
독립적 배포
마이크로서비스의 핵심 중 하나이다. 모놀리스를 사용하면 제품을 배포하고 롤백하는데 많은 시간이 걸리며 매번 전체 시스템을 배포해야 한다. 하지만 독립적인 배포를 통해 전체 API 계층을 손상시킬 가능성을 줄이면서 자율적으로 배포할 수 있으며, 더 적은 위험으로 마이크로서비스의 새 버전을 출시할 수도 있다.
실패 격리
서비스 장애 등으로 하나 이상의 마이크로서비스에 연결할 수 없는 경우 시스템의 나머지 부분은 사용할 수 있어야 한다. 마이크로서비스가 자율적이고 독릭적이라는 사실은 장애 격리의 개념을 강화한다.
고도로 관찰 가능
일반적으로 모놀리식 아키텍처를 선호하는 이유 중 하나는 단일 시스템을 관찰하기 때문이다. 마이크로서비스는 많은 자유와 유연성을 제공하지만 이것들이 무료는 아니다. 로그와 모니터링을 주시해야 하며, 특정 클라이언트 요청을 끝까지 파악할 준비가 되어 있어야 한다. 따라서 시스템을 고도로 관찰 가능하게 유지하는 것은 마이크로서비스의 주요 과제 중 하나이다.
참고 링크
2편에서 계속