Merge pull request #86 from XionWCFM/post

docs: Future Frontend (2025년의 FE 개발자는 어떤 기술 스택을 선택해야 할까?) Release

apps/blog/posts/frontend/future-frontend.mdx

@@ -0,0 +1,163 @@
+---
+title: 2025년의 FE 개발자는 어떤 기술 스택을 선택해야 할까?
+description: 뭐가 이렇게 많냐..
+thumbnail: fallback
+categories: frontend
+writeDate: 2024-11-27T08:29:07.053Z
+releaseDate: 2024-11-27T14:32:00.053Z
+canView: true
+authority: public
+---
+
+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에 대한 지원을 종료](https://github.com/module-federation/core/issues/3153)하기로 밝혔습니다.
+
+기존에 제공되던 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의 버전 업데이트에 따라 쉽게 깨져버리는 문제가 있었죠
+
+<br/>
+
+next.js는 생성해야할 페이지가 많아지고 무거운 프로젝트가 되면 빌드 속도가 매우 느려지는 문제가 존재합니다. 물론 이 문제는 Next.js 15를 출시하며 App Router의 빌드 방식을 효율화하는 것을 통해 어느정도 개선이 이루어지긴 했습니다.
+
+기존의 경우 정적 생성 프로세스에서 클라이언트 측 탐색을 위한 데이터 생성을 위해 한번, 초기 페이지 방문을 위한 HTML 생성을 위해 한번 총 두번의 렌더링을 거쳤는데요 15부터는 첫번째 렌더링 결과물을 재사용하는 형태로 빌드를 개선했다고 밝혔습니다.
+
+실제로도 next.js 15로 업그레이드한 이후 저는 빌드 속도가 약 1/2 가량 줄어들기도했습니다. 그러나 그럼에도 불구하고 여전히 next.js는 다른 프레임워크에 비해 빌드가 느립니다.
+
+turbo pack이 이 문제를 해결해줄 수 있을까요? 저는 작년부터 turbopack을 기다려왔지만 이제는 너무 늦은 것 같기도 합니다. next 15에서 출시한 개발 전용 터보팩 사용은 제 개발 환경과 잘 호환되지 않아 사용을 멈추기도 했어요
+
+<br/>
+
+
+## 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는 출시된지 얼마 되지않은 도구입니다. 저는 아주 많이 사용하는 도구이며 정말... 정말 빠릅니다. 커다란 프로젝트도 몇초안에 포매팅이 끝날만큼 빠르더라구요
+
+<br/>
+
+다만 팀 차원에서 도입하기에는 아직 여러가지 리스크가 있기도 합니다.
+
+제대로 사용하기 위해서 vscode의 경우 익스텐션의 설치가 거의 강제되는 한편 아직 인지도가 높은 도구가 아니다보니 사용 경험이 있는 팀원들을 찾는 것이 Prettier보다 많이 어렵습니다.
+
+또한 개발중인 만큼 유명한 규칙들만 우선 지원하고 있고 플러그인 생태계가 미약하여 커스텀 규칙을 설정하는 것이 사실상 불가능합니다.
+
+ES Lint를 깊게 사용하고 있는 팀이라면 이부분이 가장 도입이 꺼려지는 부분일 것 같습니다.
+
+다행히 BiomeJs는 포매터만 사용하거나 린터만 사용하는 것도 가능하니 Format에 큰 규칙이 없다면 Foramtter로만 사용하는 것도 고려해볼 수 있지 않을까해요
+
+## 소.. 솔직히.. Tailwind Css가 최고라고 생각해요..
+
+2024년 스타일링, CSS 도구는 tailwind css, Shadcn, Radix UI의 해였다고 생각해요
+
+특히 tailwind css의 Utility First 철학은 많은 사람들이 거부감을 표출한 철학이지만 저는 결국엔 이 방식이 가장 정답에 근접하다고 생각합니다.
+
+<br/>
+
+재사용하지 못하고 중복으로 작성된 CSS는 프로젝트가 커져갈수록 네트워크 페이로드를 크게 차지하는 괴물이 됩니다.
+
+이 문제를 해결하기 위해서는 최대한 CSS를 재사용하는 것이 답이겠죠 그런데 언제 어디서나 재사용 가능하려면 어떻게 기능을 쪼개야할까요?
+
+제가 생각하는 정답은 더이상 쪼갤 수 없는 단위까지 쪼개면 언제나 재사용할 수 있다.입니다.
+
+
+## 모노레포 도구 Nx 냐 Turborepo 냐
+
+Nx는 오픈소스 커뮤니티 기반 , Turbo Repo는 Vercel 팀이 개발하는 도구로 아까전의 next.js vs Module Federation과 비슷한 느낌이 들기도 합니다.
+
+개인적으로는 Turbo Repo가 손에 익어서 그냥 Turbo Repo를 사용하고 있습니다만 사실 둘 다 웬만한 킬러기능들은 전부 지원하고 있기에 아무거나 골라도 될 것 같습니다.
+
+## 마치며
+
+이미 글이 너무 길어진 것 같아 더 다루지는 않았지만 이 외에도 올해 주목할만한 많은 프레임워크, 라이브러리들이 출시되기도 했습니다.
+
+특히 ModernJS의 서버 스택으로 채택되어 있는 Hono는 서버리스로 간단한 서버를 배포하고 싶을 때 정말 좋은 선택지가 될 것 같다는 생각이 들기도 했고요
+
+제가 요즘 가장 많이 사용하는 라이브러리 중 하나인 @suspensive/react 역시 개발 경험을 크게 끌어올려준 라이브러리로 내년에도 많이 사용하지 않을까 싶습니다.
+

apps/blog/posts/frontend/what-is-design-system.mdx

@@ -0,0 +1,116 @@
+---
+title: Spectrum 디자인시스템을 보고 생각한 디자인 시스템
+description: 컬러, 텍스트만 정의하면 그게 디자인 시스템일까요?
+thumbnail: fallback
+categories: frontend
+writeDate: 2024-11-25T08:29:07.053Z
+releaseDate: 2024-11-25T11:34:00.053Z
+canView: false
+authority: public
+---
+
+디자인 시스템이란 무엇일까요?  저는 사실 예전에 블로그를 옮기면서 이런 글을 작성하기도 했습니다 [Tistory에서 nextjs 기반의 개인 블로그로 이주한 후기](https://www.xionwcfm.com/posts/retrospect/blog-migration) 이 글에서 저는 디자인 시스템을 설계했다고 했는데요
+
+사실 디자인 시스템을 찾아보면 볼수록 저때 제가 한 것은 디자인 시스템을 구현한게 아니라는 생각이 명확해져서 부끄러워지기도 했습니다.
+
+왜 이렇게 생각을 하게 되었는지, Spectrum의 디자인 시스템을 보며 생각을 정리해보고자 합니다.
+
+## 디자인 시스템? 스타일 가이드? 컴포넌트 라이브러리? UI Kit? Pattern Ui?
+
+디자인 시스템이란 무엇일까요? What Is Design System을 검색하면 가장 먼저 발견할 수 있는 figma의 글을 인용해봅시다. [What Is Design System](https://www.figma.com/blog/design-systems-101-what-is-a-design-system/)
+
+디자인 시스템은 본질적으로 제품의 경험, 느낌을 일관되게 유지하는 컴포넌트와 표준이라고 소개합니다.
+
+반면 스타일 가이드는 시각적 요소와 사용 방법을 정의한 것입니다. 색상, 글꼴 등 디자인에 사용되는 스타일의 모음이라고 할 수 있습니다.
+
+[Shopfify의 디자인 가이드라인 문서](https://developer.spotify.com/documentation/design?_conv_v=vi%3A1*sc%3A1*cs%3A1722268940*fs%3A1722268940*pv%3A1*seg%3A%7B10031564.1-10034364.1-10034366.1%7D*exp%3A%7B100330256.%7Bv.1003131869-g.%7B%7D%7D-100342530.%7Bv.1003164138-g.%7B%7D%7D%7D&_conv_s=si%3A1*sh%3A1722268939610-0.8234804752476994*pv%3A1) 를 참고해보면 혼란스럽기도 합니다.
+
+실제로 생각했던 것과 달리 스타일 가이드는 어떤 디자인 자산을 어떻게 사용해야하는지에 대한 구체적인 가이드라인을 제시하기도 합니다. 마치 제가 디자인 시스템의 영역이라고 생각했던 것까지도요
+
+
+<br/>
+
+저는 다양한 글들을 탐독한 결과 이런 형태로 생각하기로 결정했습니다.
+
+1. 디자인 시스템이란 스타일 가이드와 지침을 포함하는 개념이다.
+
+2. 스타일 가이드는 디자인 시스템의 일부가 될 수 있으며 디자인과 관련된 구체적인 가이드라인을 가진다.
+
+3. 컴포넌트 라이브러리, UI Kit과 같은 것은 스타일 가이드 혹은 디자인 시스템의 구현체가 되기도 하며 그것들을 현실세계에서 구현한것이다.
+
+4. 디자인 시스템을 사용자에게 일관된 제품 경험(UX)를 제공하기 위한 표준과 지침이다. 
+
+
+즉 스타일 가이드가 레고라면 디자인 시스템은 레고를 어떻게 조립해야하는가? 왜 이렇게 조립해야하는가? 에 대한 지침이라고 볼 수 있지않을까요?
+
+
+## Spectrum의 디자인 시스템
+
+사실 이 글을 작성하면서 많은 레퍼런스를 참고해보았지만 "그래서 디자인 시스템과 스타일 가이드의 정확한 차이가 무엇일까?" 라는 의문을 떨칠수는 없었습니다.
+
+이제 아래부터는 개발적인 세부사항 측면에서 Spectrum의 디자인 시스템에서 배우게된 인상적인 점들을 다루어보고자 합니다.
+
+
+![디자인 시스템](/posts/1.webp)
+
+### Design Token의 계층 구조
+
+![디자인 토큰](/posts/2.webp)
+
+개인적으로 컴포넌트 라이브러리를 빌드하면서 가장 크게 느낀 필요성은 디자인 토큰의 계층화였습니다.
+
+예를 들어 이런 요구사항이 가장 어려운 점 중 하나였는데요. focus 상태일때 보여지는 색상을 만약 blue-800에서 blue-850으로 전환해야한다면 어떨까요?
+
+만약 위 사진의 GlobalToken 까지만 토큰을 추상화하였다면 모든 focus 상태가 존재하는 컴포넌트를 순회하며 색상을 바꾸어야하는 리스크가 생기게됩니다.
+
+따라서 디자인 토큰을 정의할 때에는 Alias를 활용하여 사용사례를 기준으로 토큰을 정의하고 의존하는 것이 중요합니다.
+
+
+### Platform Scale
+
+모바일의 시대가 열리면서 사람들은 소프트웨어를 커다란 화면의 PC에서 사용하기도하고 조그마한 화면의 모바일에서 사용하기도 합니다. 주로 PC에서는 마우스를 사용하고 모바일에서는 손가락을 사용하곤합니다.
+
+이때 모바일 구성요소는 손가락으로 사용하기 때문에 상대적으로 정교한 작업이 어렵다는 특징이 있습니다. 우리의 엄지, 검지 손가락은 마우스보다 작으니까요.
+
+이러한 특징을 반영하여 Spectrum은 모바일 환경에서 1: 1.25 비율의 배율을 사용합니다. 모바일 구성요소는 데스크톱보다 25% 크게 디자인하는것이죠
+
+또 모바일에서 원활한 터치히트 경험을 제공하기 위해 상호작용 가능한 요소의 가로 세로 크기를 48px 이상으로 유지하기 위해 노력합니다.
+
+
+### 다국어를 지원하는 제품의 디자인 시스템은 어떤 것을 고려해야할까?
+
+![디자인 토큰](/posts/3.webp)
+
+![디자인 토큰](/posts/4.webp)
+
+언어는 각자의 고유한 특성이 존재합니다. 한자, 영어, 일본어, 한글 등 각각의 언어는 고유한 특성을 지닙니다.
+
+또한 아랍어, 히브리어와 같은 언어는 오른쪽에서 왼쪽으로 읽고 씁니다. 즉 이러한 언어적 특성은 디자인 시스템을 구성할 때 추가적인 고려가 필요합니다. 
+
+즉 이렇게 읽는 순서가 통상적인 언어와 반대인 언어의 경우 일관된 UX를 제공하기 위해 UI를 미러링하는 작업이 필요합니다. (개인적인 생각으로는 개발자입장에서 다국어 지원에서 이런 지점들을 깔끔하게 구현하기 위해선 꽤 많은 고민이 필요할 것 같네요)
+
+
+## 마치며
+
+제가 이해한 바를 전달하고자 노력하는 과정에서 정확하지 못한 정보를 기술하였을 수 있습니다.
+
+혹시 오류를 발견하신다면 [email protected]으로 연락주시면 감사하겠습니다.
+
+읽어주셔서 감사합니다.
+
+
+## 레퍼런스
+
+https://www.wix.com/studio/blog/design-system-vs-style-guide
+
+https://www.figma.com/blog/design-systems-101-what-is-a-design-system
+
+https://spectrum.adobe.com/page/principles/
+
+https://www.frontify.com/fr/blog/design-system-vs-style-guide/
+
+https://www.uxpin.com/studio/blog/design-systems-vs-pattern-libraries-vs-style-guides-whats-difference/
+
+https://www.uxpin.com/studio/blog/codifying-design-system/
+
+https://medium.com/design-bootcamp/design-systems-vs-style-guides-vs-ui-kit-79edfa022ab6