2025년의 FE 개발자는 어떤 기술 스택을 선택해야 할까?
frontend
유길종(XionWCFM)
2024.11.27. 14:32
2024년도 거의 끝나버렸습니다. 나이를 먹을수록 한해 한해 가는 것이 점점 빨라지는 것 같다는 생각이 들기도 하는데요 이정도 속도면 슬슬 묫자리도 좀 찾아봐야하나 싶기도 하네요
개인적으로 "2024년은 AI의 해다".라는 생각을 합니다. 2023년도의 제게는 구글링보다 쓸모없던 챗지피티, 생성형 AI들이 이제는 확실히 구글링보다 효율적인 도구가 되었습니다.
물론 오늘 이야기할 주제에서도 AI는 빠질 수 없는 키워드일 것 같은데요 그럼 시작해보겠습니다.
춘추전국시대같았던 프론트엔드 개발
"FE는 트렌드가 빠르게 변한다" 라는 이야기는 지금까지 모두의 상식처럼 통용되던 이야기였습니다. 정신차리고 보면 열광하던 기술스택들이 레거시가 되어있기도했고요 (Redux ㅜㅜ)
반면 2024년도에 제가 느낀 FE 개발은 이제 어느정도 답지가 나온 것처럼 느껴지는 것 같습니다. 서버상태는 리액트쿼리, 스키마 밸리데이션은 zod 이런 식으로요
특히 AI의 발전으로 인해 이제 기술 스택은 "얼마나 빠른가" , "얼마나 가벼운가" , "얼마나 심플한가" 와 같은 가치보다는 "AI가 참고할 레퍼런스가 많이 있는가?" 가 기술 스택 선택의 새로운 표준이 될 것 같다는 생각이 듭니다.
이런 부분은 특히 라이브러리를 사용할 때 많이 느껴지는 지점인데요 커뮤니티 리소스가 풍부하고 사용량이 높은 라이브러리에 대한 코드의 품질과 나온지 얼마 되지 않은 신규 버전, 혹은 신규 라이브러리에 대해 생성하는 코드의 품질이 크게 차이가 난다는 것을 느낄 수 있었습니다.
그래서 앞으로는 커뮤니티 리소스가 이미 풍부한 도구가 있는 분야는 신규 라이브러리가 역전하기 쉽지 않아질 것 같아요
우리 그냥 스키마는 Zod 쓸까?
이런 부분에 있어 zod의 성장은 눈에띕니다. 경쟁자인 yup, superstruct 등의 라이브러리들의 다운로드수는 전년도 수치를 웃도는 정도에 그치지만 zod는 작년대비 7배 가량의 성장을 보였습니다. (200만에서 1500만으로)
많은 프레임워크, 라이브러리들이 zod를 일류로 지원하고있거나 지원하기 시작했고 다양한 편의성 라이브러리들도 zod를 기반으로 하는 경우가 많아졌습니다.
zod는 가벼운 프로젝트에 사용하기엔 번들 크기가 너무 크다와 같은 단점이 존재하지만 생태계가 크다는 장점으로 인해 앞으로도 더 많이 사용될 것 같아요
Next.js Vs Module Federation | Vercel Vs OpenSource
마이크로프론트엔드 개발 환경을 위한 핵심 기술인 Module Federation은 2024년 10월 공식적으로 Next.js에 대한 지원을 종료하기로 밝혔습니다.
기존에 제공되던 Pages Router Module Federation에 대한 지원은 유지되지만 핵심 팀에서 신규 개발이 이루어지지는 않을 것이라고 밝혔습니다.
If you are exploring microfrontends, do not use Next.js! It is a hostile framework and Vercel is an adversary of federation
next.js는 현시점에서 가장 많이 사용되는 프론트엔드 프레임워크 중 하나이며 실제 프로덕션에서도 많이 사용되고 있는 기술입니다.
그러나 next.js는 대부분의 프론트엔드 생태계와 원활히 호환되지 않습니다. Module Federation은 물론이고 Vite과도 잘 동작하지 않습니다.
next.js를 esbuild, rspack 등 비교적 빠른 빌드 도구를 통합해보려는 시도가 있었지만 Next.js의 버전 업데이트에 따라 쉽게 깨져버리는 문제가 있었죠
next.js는 생성해야할 페이지가 많아지고 무거운 프로젝트가 되면 빌드 속도가 매우 느려지는 문제가 존재합니다. 물론 이 문제는 Next.js 15를 출시하며 App Router의 빌드 방식을 효율화하는 것을 통해 어느정도 개선이 이루어지긴 했습니다.
기존의 경우 정적 생성 프로세스에서 클라이언트 측 탐색을 위한 데이터 생성을 위해 한번, 초기 페이지 방문을 위한 HTML 생성을 위해 한번 총 두번의 렌더링을 거쳤는데요 15부터는 첫번째 렌더링 결과물을 재사용하는 형태로 빌드를 개선했다고 밝혔습니다.
실제로도 next.js 15로 업그레이드한 이후 저는 빌드 속도가 약 1/2 가량 줄어들기도했습니다. 그러나 그럼에도 불구하고 여전히 next.js는 다른 프레임워크에 비해 빌드가 느립니다.
turbo pack이 이 문제를 해결해줄 수 있을까요? 저는 작년부터 turbopack을 기다려왔지만 이제는 너무 늦은 것 같기도 합니다. next 15에서 출시한 개발 전용 터보팩 사용은 제 개발 환경과 잘 호환되지 않아 사용을 멈추기도 했어요
Module Federation 2 더 발전해버린 마이크로 프론트엔드
마이크로 프론트엔드는 규모가 큰 팀이나 커다란 프로덕트를 개발해야하는 상황에서 큰 장점을 지니는 개발 방법론입니다. 그러나 웹에서 구동된다는 프론트엔드 개발의 특성상 마이크로프론트엔드는 여러가지 기술적 챌린지들에 직면해왔습니다.
대표적인 문제로 리소스 공유 문제가 존재합니다. 모든 마이크로 서비스가 각자 동일한 라이브러리를 가지고 한페이지에 로드된다면 어떨까요? 단일 서비스 대비 로드해야하는 자바스크립트의 크기가 * N이 될 것입니다. 게다가 이 문제는 CSS에도 동일하게 적용됩니다.
그외에도 다양한 문제점들이 존재합니다만 제가 생각했을 때 MFA의 가장 큰 문제는 DX 였습니다. 빠르게 움직일 수 있는 아키텍처라 하더라도 개발자 경험이 좋지 않다면 빠르게 갈 수 없다고 생각했거든요 그런 측면에서 올해 출시된 Module Federation 2의 개발 경험은 놀라웠습니다.
Vite 플러그인을 이용하여 직접 모듈 페더레이션 개발 환경을 구성할 때 느꼈던 어려운 점들이 모두 깔끔하게 해결된 것은 물론이고 Remote Type Hint를 기반으로 한 타입스크립트 자동 지원과 RsPack의 빠른 컴파일 속도는 정말 놀라웠어요
게다가 Module Federation의 1급 지원을 받는 Modern.js를 이용하면 Streaming SSR 기반의 MFA 또한 쉽게 구현할 수 있더라구요
개인적인 생각으로는 이제 앞으로 점점 더 마이크로프론트엔드를 채택하는 것이 쉬워질 것, 그리고 마이크로프론트엔드를 채택한다면 Modern.js도 함께 채택하는 경우가 늘어날 것 이라고 생각해요
React Native와 Expo
개인적으로 RN은 올해보다 내년을 더 기대하고 있는 기술 중 하나입니다.
2024년 10월 React Native 팀은 수년간 준비해온 새로운 리액트 네이티브 아키텍처를 공개했습니다. 그와 더불어 Expo는 사실상 리액트 네이티브계의 Next.js와 같은 존재가 된 것 같아요
저는 크로스 플랫폼의 특성으로 인해 개발 환경 구성이 매우 까다로운 점이 개발자가 느끼는 가장 큰 페인포인트였다고 생각해요 (저는 그랬거든요)
Expo가 이런 문제들을 많이 해결해주어서 이제 간단한 요구사항의 앱을 만들 때에는 Expo를 쓰지 않을 이유가 없어진 것 같습니다.
다만 React Native는 아직 Pnpm, 모노레포와의 호환이 잘 이루어지지 않는 점이 가장 아쉬운 것 같아요(내년이 오면 해결되지않을까요?)
PnP는 못 써먹겠다.
Yarn2의 핵심기능 중 하나인 PnP는 node_modules 방식에 비해 디스크 용량을 효율적으로 사용할 수 있고 빠른 설치 속도를 지닌다는 장점이 존재합니다.
그러나 PnP는 모든 생태계에서 널리 사용되기엔 문제가 있는 것 같아요.
호환이 잘 되지 않는 도구들이 여럿 존재하기도 하고 기술 특성상 디버깅에 있어 AI에게 유의미한 도움을 받기 어렵다는 문제가 있었습니다.
저 역시 작년에는 Yarn2를 메인 패키지매니저로 사용해왔지만 이 부분에서 큰 불편을 느껴 Pnpm으로 패키지매니저를 옮기기도 했습니다.
Cursor의 시대가 올까요?
Cursor는 올해 출시된 AI 도구 중 가장 자주 사용하기도하고 가장 편리하다는 생각이 드는 도구이기도 합니다.
Cursor의 가장 큰 장점은 코드베이스를 학습하는 것은 물론 코딩스타일을 지정해주는 것도 가능하다는 것입니다.
한번 잘 학습시켜두면 내가 자주 짜는 코딩스타일로 지루한 반복 코드를 순식간에 생성해주니 생산성 향상에 큰 도움이 되었어요
Eslint , Prettier Vs BiomeJs
Eslint와 Prettier는 전통적으로 프론트엔드 생태계에서 많이 사용되어온 도구입니다. 역사가 오래된 만큼 생태계에 다양한 플러그인들이 존재하며 레퍼런스도 많은 만큼 AI의 도움을 받기에도 딱 좋은 도구들이죠
그러나 위 두 도두들은 프로젝트의 규모가 커지면 성능 문제가 발생하기도 합니다. Prettier의 경우 프로젝트 규모가 커지면 한번 프로젝트 전체에 대해 포매팅을 돌리는데 몇십초 정도가 소모되기도 하더라구요
반면 BiomeJs는 출시된지 얼마 되지않은 도구입니다. 저는 아주 많이 사용하는 도구이며 정말... 정말 빠릅니다. 커다란 프로젝트도 몇초안에 포매팅이 끝날만큼 빠르더라구요
다만 팀 차원에서 도입하기에는 아직 여러가지 리스크가 있기도 합니다.
제대로 사용하기 위해서 vscode의 경우 익스텐션의 설치가 거의 강제되는 한편 아직 인지도가 높은 도구가 아니다보니 사용 경험이 있는 팀원들을 찾는 것이 Prettier보다 많이 어렵습니다.
또한 개발중인 만큼 유명한 규칙들만 우선 지원하고 있고 플러그인 생태계가 미약하여 커스텀 규칙을 설정하는 것이 사실상 불가능합니다.
ES Lint를 깊게 사용하고 있는 팀이라면 이부분이 가장 도입이 꺼려지는 부분일 것 같습니다.
다행히 BiomeJs는 포매터만 사용하거나 린터만 사용하는 것도 가능하니 Format에 큰 규칙이 없다면 Foramtter로만 사용하는 것도 고려해볼 수 있지 않을까해요
소.. 솔직히.. Tailwind Css가 최고라고 생각해요..
2024년 스타일링, CSS 도구는 tailwind css, Shadcn, Radix UI의 해였다고 생각해요
특히 tailwind css의 Utility First 철학은 많은 사람들이 거부감을 표출한 철학이지만 저는 결국엔 이 방식이 가장 정답에 근접하다고 생각합니다.
재사용하지 못하고 중복으로 작성된 CSS는 프로젝트가 커져갈수록 네트워크 페이로드를 크게 차지하는 괴물이 됩니다.
이 문제를 해결하기 위해서는 최대한 CSS를 재사용하는 것이 답이겠죠 그런데 언제 어디서나 재사용 가능하려면 어떻게 기능을 쪼개야할까요?
제가 생각하는 정답은 더이상 쪼갤 수 없는 단위까지 쪼개면 언제나 재사용할 수 있다.입니다.
모노레포 도구 Nx 냐 Turborepo 냐
Nx는 오픈소스 커뮤니티 기반 , Turbo Repo는 Vercel 팀이 개발하는 도구로 아까전의 next.js vs Module Federation과 비슷한 느낌이 들기도 합니다.
개인적으로는 Turbo Repo가 손에 익어서 그냥 Turbo Repo를 사용하고 있습니다만 사실 둘 다 웬만한 킬러기능들은 전부 지원하고 있기에 아무거나 골라도 될 것 같습니다.
마치며
이미 글이 너무 길어진 것 같아 더 다루지는 않았지만 이 외에도 올해 주목할만한 많은 프레임워크, 라이브러리들이 출시되기도 했습니다.
특히 ModernJS의 서버 스택으로 채택되어 있는 Hono는 서버리스로 간단한 서버를 배포하고 싶을 때 정말 좋은 선택지가 될 것 같다는 생각이 들기도 했고요
제가 요즘 가장 많이 사용하는 라이브러리 중 하나인 @suspensive/react 역시 개발 경험을 크게 끌어올려준 라이브러리로 내년에도 많이 사용하지 않을까 싶습니다.
유길종(XionWCFM)
무언가를 쉽게 설명 해낼 때 쾌감을 느끼는 사람입니다.
현재는 프론트엔드 개발자로 일하고 있습니다.