웹 애플리케이션의 발전
과거 중복을 없애기 위해 <frameset>이 <iframe>이라는 유산을 남겼다. 이후 SSI가 PHP로 대체되었다가, 웹 2.0이 나오며 AJAX 등의 새로운 기능 등장으로 새로운 국면을 맞았습니다. 여기에서부터 CSR프레인워크가 등장하기 시작했습니다. 또한 브라우저의 UI에서 직접 웹서비스를 재사용 하는 방식이 인기를 끌기 시작했습니다.
이는 프론트와 백엔드간의 분리를 가속했는데, 서버, DB처리, 페이지처리 등을 하나의 코드에서 처리하던 모놀리스 방식이 사라져갔습니다. 이러면서 페이지 관련 작업은 브라우저에서 처리하도록 발전했는데 이를 SPA라고 합니다. 이는 API설계의 고도화를 불러왔지만, 보안 설정, 배포 관점 등에서 문제가 발생했습니다. 또한 UX관점에서도 고려해줘야할 부분들이 많아져 작업에 할애하는 시간들이 길어졌습니다.
하지만 규모가 큰 웹을 밴엔드와 프론트를 분리해서 작업하는 것이 더 효울적으로 개발할수 있기 때문에 사용되고 있습니다.
마이크로서비스
SOA와 마이크로서비스
SOA는 기존부터 존재했지만, 기술적 한계로 사장되었다가, 도커 등의 기술들로 문제가 해결되었습니다. 이후 팀에서 사용하는 일반적인 디자인 패턴을 사용하여 마이크로서비스라는 일반적 아키텍처 스타일을 형성하게되었습니다.
마이크로서비스를 사용할 때는 한가지만 담당하는 서비스를 구축해야하는데 이는 단일 책임 원칙을 적용할 수 있습니다. 이는 백엔드 구축 방식에 초점이 맞춰져있는데, 프론트엔드 또한 이를 따라가야했습니다.
마이크로서비스의 장점
마이크로서비스와 마이크로 프론트엔드는 서로 배경과 역사가 유사하기 때문에 설명된 것입니다. 따라서 이를 참고한다면 추후 디자인 의사 결정에 도움이 됩니다.
마이크로서비스의 장점에는 아래와 같은 장점이 있습니다.
•
장애는 단일 서비스와 직접적으로 관련
•
여러 팀이 독립적으로 작업 가능
•
배포 규모가 작음
•
프레임워크과 언어 선택 가능
•
초기 출시기간 단축
•
아키텍처 경게 뚜렷
마이크로서비스의 단점
아래와 같은 단점이 있습니다.
•
오케스트레이션 복잡성 증가
•
다중 장애 지점
•
디버깅 및 테스트 복잡
•
책임감 부족
•
서로 다른 서비스간 결과적 비일관성
•
버전관리 어려움
오케스트레이션 : 컴퓨터 시스템과, 애플리케이션, 자동화 구성 등 관리 및 조정
‘마이크로’와 ‘프론트엔드’
프론트엔드단에서 코드가 폭발적으로 증가함에따라, 규모가 커지고 마이크로 프론트엔드가 주목받고 있습니다.
웹 표준의 부상
문제점으로 코드가 충돌을 피하기위해 격리해야하지만, 리소스를 공유할 수 있어야합니다. 또한 각 기기나 브라우저간의 특성을고려해야합니다.
웹 컴포넌트를 통한 격리
3이러한 갭슐화를 위해 사용할 수 있는 방법이 shadow DOM입니다. 이를 통해 숨겨진 DOM트리에 root가 따로 존재해 원하는 모든 요소를 격리해서 붙일 수 있습니다. 그러나 JS는 다르게 돌아가는데, 전역변수를 통해 상위 스크립트에 접근할 수 있기 할 수 있기때문입니다.
이러한 것들을 해결하는 방법이 <iframe>을 통한 격리입니다.
프레임 통신
iframe과 페이지간 통신의 경우엔 window.postMessage를 통해서 통신을 할 수 있스빈다.
또한 다른 방법으로 직접 격리가아닌 웹 워커를 이용한 방법이 있습니다.
웹 워커와 프락시
웹 워커도 메인 스레드와 워커 스레드간 통신을 위해서 window.postMessage를 사용해야 합니다. iframe과 차이점은 window객체와 다른 전역 콘텍스트에서 실행된다는 점 입니다.
만약 각 웹 워커들이 서로 다른 전역 콘텍스트에 있을 때는 프락시를 사용해주면됩니다. 프락시를 사용할 경우 객체 엑세스 및 함수 호출을 포착할 수 있습니다.
이러한 방법들을 통해 모듈화를 구현할 수 있습니다.
출시 기간 단축
조직 적응 시간 단축
최근 개발자들의 근속 연수가 줄어드는데 각 프로젝트의 규모를 줄여 조직에 적응하는 시간을 단축해줬습니다. 단 복잡한 버그의 경우 여러 프로젝트 이해도가 필요해 디버깅이 더 힘들어진다는 단점이 있습니다.
여러 개의 팀
모듈화를 통해서 서로 각자의 팀에서 고유한 프로세스와 일정을 가지고 움직일 수 있어, 외부와 작업을 할 때 큰 이점을 가져다 주었습니다. 또한 DDD를 여러팀과 결합해서 할 수 있기 때문에 더욱 효율적인 방법이 됩니다.
피처 격리
마이크로 프론트엔드라면 그 부분이 빠져도 정상적으로 동작할 만큼 독립적으로 구성되어져있어야 합니다.
A/B 테스팅
A/B 테스팅을 도입해 사용자의 피드백을 도입할 수 있습니다. 만약 이를 모놀리식에서 적용한다면 만은 코드수정이 있어야 하지만 모듈화가 되어있다면 코드 변경없이도 적용할 수 있습니다.