패스트 캠퍼스 챌린지 20일차 미션 (2월 20일) : 마이크로 FE 강의 후기

이 글은 네이버 블로그에 2025년 2월 20일에 올렸던 것을 그대로 옮겨온 것입니다.

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

[ 마이크로 프론트엔드(MFA:Micro Frontend Architecture) : 대규모 서비스 설계부터 운영까지 (feat.모노레포&모듈페더레이션)

1. 공부 시작 시각

2. 공부 종료 시각

3. 클립 1번 수강 인증 사진

4. 클립 2번 수강 인증 사진

5. 학습 인증샷 1장

6. 학습 후기 700자

마이크로 프런트엔드에서 서버 측 SSL 통합을 학습하며 느낀 점

마이크로 프런트엔드를 구현하는 여러 가지 방법 중에서, 서버에서 SSL을 이용해 프래그먼트를 통합하는 방식을 직접 실습해 보면서 기대했던 것과 달랐던 점이 많았다. 처음에는 단순히 Nginx를 사용해 여러 마이크로 프런트엔드 애플리케이션을 하나로 합치는 정도로 생각했지만, 실제로 구현하면서 보안, 성능, 유연성이라는 요소가 서로 긴밀하게 엮여 있다는 점이 흥미로웠다.

특히, 보안적인 측면에서 이 방식이 가지는 강점을 체감할 수 있었다. 클라이언트에서 여러 개의 서비스를 직접 호출하는 방식은 종종 CORS 이슈나 인증 관련 문제를 일으키지만, 서버 측에서 SSL을 통해 통합하면 이런 문제를 상당 부분 해결할 수 있었다. 다만, SSL 인증서를 설정하고 관리하는 과정은 생각보다 까다로웠고, 운영 환경에서 갱신 주기를 신경 써야 한다는 점도 새롭게 깨달은 부분이었다.

또한, 서버에서 프래그먼트를 조립한 후 클라이언트로 전달하는 방식이기 때문에, UX가 더 부드러워진다는 점이 인상적이었다. 클라이언트 사이드에서 여러 개의 마이크로 프런트엔드를 각각 요청하면 화면이 깜빡이거나 레이아웃이 잠깐 어긋나는 현상이 발생할 수 있는데, 서버 측에서 통합하니 이런 문제를 상당 부분 줄일 수 있었다. 사용자 입장에서 보면 마치 하나의 거대한 애플리케이션처럼 느껴지기 때문에, "마이크로 프런트엔드인데 모놀리식처럼 작동하는" 묘한 경험을 하게 되었다.

하지만 단점도 확실히 체감했다. 프래그먼트 간의 상태 관리가 어렵다는 점이 특히 아쉬웠다. 클라이언트 사이드에서는 상태 공유를 위해 글로벌 스토어나 이벤트 버스를 활용할 수 있지만, 서버에서 통합하면 개별 프래그먼트가 독립적으로 동작하면서 서로의 상태를 공유하는 것이 어렵다. 이를 해결하려면 쿠키나 세션을 활용해야 하는데, 그렇게 되면 결국 서버 의존성이 커지는 문제를 피하기 어렵다.

또 하나 느낀 점은, 서버의 부담이 커질 수밖에 없다는 점이다. 클라이언트 사이드 통합 방식에서는 사용자의 브라우저가 각 프래그먼트를 개별적으로 요청해 로드하지만, 서버 측에서는 모든 요청을 받아서 통합한 후 반환해야 하기 때문에 부하가 몰릴 가능성이 크다. 트래픽이 적을 때는 큰 문제가 없지만, 고부하 환경에서는 로드 밸런싱과 캐싱 전략을 적극적으로 활용해야 한다는 점을 다시 한번 실감했다.

결론적으로, 이 방식이 마이크로 프런트엔드의 완벽한 해결책은 아니지만, 보안과 사용자 경험을 중요하게 고려해야 하는 프로젝트라면 꽤 괜찮은 선택지라는 점을 배웠다. 하지만 반대로, 빠른 상태 공유가 필요하거나 서버 부하를 최소화해야 하는 경우라면, 클라이언트 사이드 통합 방식과 적절히 조합해야 할 것 같다. 이번 학습을 통해 단순히 기술을 배우는 것을 넘어, 아키텍처 설계에서 "무엇을 우선순위로 둬야 하는가"라는 더 큰 고민을 하게 된 점이 가장 큰 수확이었다.

필수 URL https://bit.ly/4gL1f1o

#패스트캠퍼스 #직장인자기계발 #직장인공부 #환급챌린지 #패스트캠퍼스후기 #오공완