HHyo814
발행일

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

교육

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

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

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

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

1. 공부 시작 시각

image

2. 공부 종료 시각

image

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

image

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

image

5. 학습 인증샷 1장

image

6. 학습 후기 700자

esbuild와 SWC 학습 후기 및 느낀점

최근 프론트엔드 빌드 도구를 최적화하는 과정에서 esbuild와 SWC를 학습하고 비교해보는 경험을 했다. 기존에는 Webpack이나 Babel을 사용해왔지만, 더 빠른 빌드 속도를 제공하는 최신 트랜스파일러 및 번들러를 탐색할 필요가 있었다. 특히 Next.js 프로젝트를 진행하면서 SWC를 자연스럽게 접하게 되었고, esbuild도 함께 실험하며 두 도구의 차이를 직접 경험할 수 있었다.

  1. esbuild 학습 후기

esbuild는 Go 언어로 작성된 초고속 번들러다. 공식 문서를 읽어보면서 첫인상은 **"정말 단순하고 빠르다"**였다. 기존 Webpack 설정을 복잡하게 다루던 경험과 비교했을 때, esbuild는 CLI 기반으로도 간단히 실행할 수 있었고, 설정 파일도 짧고 직관적이었다.

학습 과정에서 인상 깊었던 점:

  1. 속도: esbuild는 멀티스레딩을 활용하여 빌드 속도가 매우 빠르다. Webpack에서 10초 넘게 걸리던 빌드가 esbuild로는 1~2초 만에 끝났다.
  2. 번들링 & 트랜스파일링 통합: 보통 Babel과 Webpack을 조합해서 사용해야 했지만, esbuild는 자체적으로 ES6+ 코드를 ES5로 트랜스파일하고 번들링까지 수행할 수 있다.
  3. Tree Shaking & Minification 지원: 기본적으로 Dead Code Elimination과 압축(minify)을 지원하므로 별도의 설정 없이도 최적화된 번들링이 가능했다.
  4. 플러그인 시스템이 제한적: Webpack처럼 다양한 플러그인을 활용하기 어려웠다. 특히, PostCSS나 특정 TypeScript 변환(예: Decorator 지원)에서 Webpack보다 불편한 점이 있었다.

esbuild는 단순한 설정과 빠른 속도가 장점인 반면, 플러그인 확장성이 부족한 점이 단점이었다. 작은 프로젝트나 빠른 개발 환경에서는 매우 유용하지만, 대규모 프로젝트에서는 Webpack이나 다른 툴과 병행해서 써야 할 수도 있겠다는 생각이 들었다.

  1. SWC 학습 후기

SWC(Speedy Web Compiler)는 Rust로 작성된 트랜스파일러로, Next.js의 기본 트랜스파일러이기도 하다. Babel 대체용으로 설계되었으며, 빠른 속도와 TypeScript 및 JSX 지원이 특징이다. SWC를 직접 설정하고 기존 Babel을 대체해보면서 몇 가지 중요한 특징을 경험했다.

학습 과정에서 인상 깊었던 점:

  1. Next.js와의 기본 통합: Next.js는 기본적으로 SWC를 사용하므로 추가 설정 없이 바로 활용할 수 있었다. Babel을 설정할 필요가 없다는 점이 깔끔했다.
  2. TypeScript 및 JSX 트랜스파일링 속도: Babel보다 10배 이상 빠른 속도를 체감할 수 있었다. 특히 대형 TypeScript 프로젝트에서는 빌드 속도가 크게 단축되었다.
  3. 플러그인 지원 부족: esbuild와 마찬가지로 Babel처럼 다양한 플러그인을 지원하지 않는다. 예를 들어, SWC에서 특정 Babel 플러그인을 활용할 수 없는 경우가 있어, 일부 기능을 포기해야 하는 경우가 있었다.
  4. 코드 변환의 차이: Babel과 완전히 동일한 변환을 제공하지 않기 때문에, 기존 Babel 기반의 프로젝트에서 일부 코드가 예상과 다르게 변환될 수도 있다. Babel에서 사용하던 @babel/plugin-proposal-decorators 같은 고급 기능이 완벽히 대응되지 않는 점이 불편했다.

SWC는 Next.js 및 TypeScript 프로젝트에서 최고의 성능을 제공하지만, Babel과 100% 동일한 기능을 제공하지 않는다는 점이 단점이었다. 따라서, Babel 플러그인을 적극적으로 활용하는 프로젝트에서는 SWC로 완전히 전환하는 것이 쉽지 않을 수도 있다.

  1. 느낀점 및 결론

esbuild와 SWC를 학습하면서 느낀 점은 **"속도와 확장성은 반비례할 수 있다"**는 것이었다.

  • esbuild는 번들러 + 트랜스파일러 역할을 동시에 수행하면서 압도적인 속도를 제공했지만, Webpack/Babel의 플러그인 확장성을 완전히 대체하지는 못했다.
  • SWC는 Next.js 환경에서 최고의 성능을 제공했지만, 기존 Babel 기반 프로젝트에서는 일부 호환성 문제가 있을 수 있었다.
  • Webpack + Babel 조합은 여전히 유효하지만, 빌드 속도를 개선하려면 SWC나 esbuild를 적절히 활용하는 것이 필요했다.
  • 중소형 프로젝트에서는 esbuild를 사용하면 간편하고 빠른 개발이 가능했고, Next.js 기반 프로젝트라면 기본적으로 SWC를 활용하는 것이 최적이었다.

결국, 어떤 툴을 선택할지는 프로젝트의 규모와 요구사항에 따라 달라진다. 하지만 확실한 것은, Webpack + Babel 조합을 무조건적으로 사용하기보다는, 최신 트랜스파일러와 번들러를 적극적으로 테스트해보고, 성능 최적화를 위한 최적의 조합을 찾아야 한다는 것이다.

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

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

← 글 목록으로