(번역) 2025 리액트 기술 스택

January 06, 2025

원문 : React Tech Stack [2025]

리액트 생태계에서는 항상 새로운 기술들이 등장하고 있습니다. 이번 글에서는 2025년에 풀스택 애플리케이션을 개발하기 위한 인기 있는 리액트 기술 스택 하나(!)를 탐구해 보겠습니다. 이를 통해 여러분만의 제품(예: SaaS) 또는 최소한의 MVP를 만들 수 있을 것입니다.

애초에 이 가이드를 쓴 이유는 무엇인가요? 저는 프리랜서 웹 개발자와 1인 창업자로서 수년 동안 많은 프로젝트를 진행해 왔습니다. 매년 사용하는 기술 스택을 재평가하여 최신 트렌드를 따르면서도 향후 몇 년간 프로젝트의 안정성과 유지보수를 염두에 두고 있습니다.

좀 더 자세히 설명해 드리겠습니다. 참고로, 저는 거의 1년 동안 SaaS를 개발하며 창업자로서 작업해 왔고, 그 SaaS는 수익성을 달성했습니다. 그때 선택했던 기술 스택에 만족하지만, 오늘 새로운 프로젝트를 시작한다면 다른 기술 스택을 선택할 것입니다.

이 글은 2024년 한 해 동안 진행한 풀스택 웹 개발 강의에 대한 연구와 경험, 그리고 제가 선택한 기술 스택을 바탕으로 작성되었습니다.

계속 읽기: The Road to Next

짧지만, 포괄적인 목록을 자세히 살펴보겠습니다.

리액트 기술 스택

Next.js는 리액트 위에 구축된 프레임워크이며, 풀스택 애플리케이션을 개발할 때 가장 인기 있는 선택 중 하나입니다. 그 이유는 라우팅, 캐싱 등의 기능뿐만 아니라 동일한 애플리케이션에서 다양한 목표에 맞게 최적화할 수 있는 다양한 렌더링 전략(예: SSR, ISR)을 제공하기 때문입니다. 또한 최신 리액트 기능(예: 서버 컴포넌트와 서버 함수)을 활용하여 리액트 애플리케이션을 백엔드에 연결할 수도 있습니다.

Astro는 Next.js 프로젝트를 모놀리식 애플리케이션으로 사용하지 않는다면 제품의 랜딩 페이지를 생성하기 위한 선택 사항으로 고려할 수 있습니다. 예를 들어, Next.js는 정적 페이지와 동적 페이지를 한 번에 제공할 수 있지만, Astro를 사용하면 애플리케이션에 별도의 분리된 서브도메인(예: app.example.com)을 사용할 가능성이 있습니다. 하지만, 다양한 랜딩 페이지 템플릿을 선택할 수 있어 개발자 경험을 개선하고 빠른 랜딩 페이지를 생성할 수 있습니다. 이를 통해 SaaS 개발에 더 많은 시간을 집중할 수 있게 됩니다.

계속 읽기 : 리액트 프로젝트를 시작하는 방법

서버 컴포넌트(Server Components)는 모든 리액트 프레임워크에서 사용할 수 있는 것은 아니지만, Next.js 같은 특정 프레임워크에서는 지원됩니다. 서버 컴포넌트는 풀스택 리액트 애플리케이션이 빌드되는 방식을 바꾸기 때문에 추가로 언급하고 싶었습니다. 가장 기본적인 특징으로는 서버에서 실행되는 컴포넌트를 작성할 수 있어 데이터베이스와 같은 서버 리소스에 접근할 수 있습니다.

서버 함수(Server Functions)는 Next.js에서 사용 가능한 또 다른 리액트 기능으로, 이 기능을 언급하고 싶은 이유는 리액트 컴포넌트에서 함수를 호출하는 것만으로도 서버 측 코드를 실행할 수 있게 해 주기 때문입니다. 이는 타입이 지정된 원격 프로시저 호출(RPC)처럼 작동하지만, 내부에는 사용자를 위해 생성된 API 엔드포인트가 있습니다.

서버 액션(Server Actions)은 앞에서 언급한 서버 함수의 하위 집합으로, 보다 사용자 친화적으로 만들기 위해 추상화 계층을 추가하는 몇 가지 라이브러리가 있습니다. 개인적으로 몇 줄의 코드만으로 직접 자신만의 추상화를 쉽게 구현할 수 있기 때문에 (아직) 사용할 필요성을 느끼지 못했습니다. 하지만 기존의 솔루션을 찾고 있다면 next-safe-actions 또는 zsa를 확인해 보세요.

계속 읽기 : 풀스택 프레임워크로서의 리액트

Tailwind CSS : 개발자 커뮤니티 내에서 계속 의견이 분분하지만, 현재로서는 빠른 제품 개발과 장기적인 CSS 유지보수를 위해 Tailwind CSS가 최적의 선택입니다. 저와 많은 수강생들의 경험에 비추어 볼 때, 한 번 익숙해지면 기존 CSS 방식으로 돌아가는 것은 상상하기 어렵습니다.

Shadcn UI : UI 라이브러리는 수시로 등장하고 사라지지만, Shadcn UI는 1년 넘게 인기를 끌고 있습니다. Tailwind CSS와 원활하게 작동하고, 버전 없는 시스템을 통해 새로운 UI 관리 방식을 제공합니다. 다음 유력한 대안이 나오거나 모든 것이 다시 너무 비슷해 보이기 시작할 때까지는 현재로서는 훌륭한 선택이라고 생각합니다.

Lucide React : 이 아이콘 라이브러리는 Shadcn UI과 함께 제공되기 때문에 다른 것으로 교체할 필요는 없습니다. 다른 인기 있는 제품이 나온다면 다음 프로젝트 진행 시 교체를 고려해볼 수도 있습니다. Lucide React에는 큰 부담이 없기 때문입니다.

계속 읽기 : 리액트의 CSS 스타일링

TypeScript : 이 선택에 대해서는 길게 말할 필요가 없다고 생각합니다. 타입스크립트는 자바스크립트 프로젝트의 업계 표준으로, 개발자 경험을 개선하고 유지보수를 용이하게 하며 버그를 줄여주는 훌륭한 선택입니다.

Zod : 이것은 리액트 프로젝트에서 유효성 검사를 위한 업계 표준으로 자리 잡았는데, 이는 타입스크립트와 잘 맞물리기 때문입니다. 요즘에 저는 서버 측 유효성 검사(예: 서버 액션)에만 Zod를 사용하고 클라이언트 측 폼 검증은 네이티브 HTML 검사로 가볍게 유지합니다. 이렇게 하면 서드파티 폼 라이브러리를 사용하지 않아도 폼 컴포넌트에 복잡성이 생기지 않습니다.

계속 읽기 : 리액트의 상태

nuqs는 Next.js에서 타입을 갖춘 URL 상태(예: 검색, 정렬, 페이지네이션)를 위해 제가 자주 사용하는 솔루션입니다. 다른 프레임워크를 사용하는 경우, 이 기능이 내장되어 있거나 다른 라이브러리를 사용해야 할 수 있습니다. 어떤 경우든 URL 상태 관리를 위한 해결책을 마련하는 것이 중요합니다.

Zustand는 클라이언트 측 상태 관리를 위한 선택 사항입니다. 하지만 URL 상태, 클라이언트 측 데이터 캐싱(예: 리액트 쿼리), 서버 기반 리액트 애플리케이션(예: 서버 컴포넌트)로 인해 클라이언트 측 상태의 필요성이 줄어든 경우가 많아서 요즘에는 거의 사용하지 않습니다.

리액트 쿼리는 무한 스크롤 같은 복잡한 클라이언트 데이터 가져오기 시 유용한 선택적인 솔루션입니다. 하지만 프로젝트 복잡도가 낮을 때는 서버 컴포넌트만 사용합니다.

계속 읽기 : 리액트의 데이터 페칭

Prisma (ORM)는 항상 제가 선택하는 ORM입니다. 하지만 항상 새로운 기술에 대한 과열된 관심이 있기 때문에 Drizzle로 대체할 수도 있습니다. 그렇지만 저는 안정적이면서 이미 많은 프로젝트에서 사용되고 있는 Prisma를 계속 사용할 예정입니다.

Supabase (데이터베이스)는 서비스형 데이터베이스로 제가 선택할 만한 옵션입니다. 이는 Postgres 데이터베이스를 비롯한 더 많은 기능을 제공합니다. 개인적으로는 그 외 부가 기능들을 사용하지 않고 기술 선택의 유연성을 유지하고자 Postgres 데이터베이스만 사용합니다. 또한, 데이터베이스에 대해서는 Prisma를 통해 연결해 사용하며, 이렇게 하면 언제든 다른 데이터베이스(예: Neon)로 교체할 수 있는 유연성을 가질 수 있습니다.

Lucia (인증): 요즘 저는 Lucia를 사용하고 있습니다. 비록 이 라이브러리가 더 이상 유지 보수되지 않지만, 여전히 학습 자료로 활용되고 있습니다. Lucia는 Oslo, Argon2, 그리고 선택적으로 Arctic 같은 라이브러리를 통해 인증의 기본 개념을 가르쳐 주기 때문입니다. 이를 통해 Clerk나 Kinde와 같은 서드파티 술루션에 의존하지 않고, 필요에 맞춘 커스텀 인증 시스템을 직접 구축할 수 있습니다.

S3 (파일 업로드): Amazon AWS S3, 미리 서명된 URL(presigned URLs), 그리고 AWS IAM을 사용해 파일 업로드 시스템을 직접 구축하는 것은 어렵지 않습니다. 이는 가장 저렴한 비용으로 파일을 저장할 수 있는 유연성을 제공합니다. 저는 다른 서드파티 솔루션을 추천하지 않는데, 이는 한 번 구현하면 잊어버릴 수 있는 작업이기 때문입니다. 대부분의 서드파티 서비스도 동일한 API를 사용하므로, 필요시 나중에 제공업체를 변경할 수도 있습니다.

Inngest (큐): 최근 프로젝트에서 더 정교한 작업 오케스트레이션을 통해 백엔드를 확장해야 할 때 Inngest를 사용했습니다. 개인적으로 시간이 크게 중요하지 않고 백그라운드에서 실행될 수 있는 작업에 이것을 활용합니다. Inngest는 설정과 유지보수가 쉬운 큐 시스템으로서 탁월한 선택입니다.

React Email + Resend: 전자는 리액트 컴포넌트로 이메일 템플릿을 생성할 수 있게 해 주고, 후자는 이메일 발송에 탁월한 솔루션입니다. 이전에는 React Email을 활용할 수 있는 Postmark를 사용했었지만, Resend로 전환한 후 매우 만족하고 있습니다.

Vercel (호스팅): 저는 Vercel을 수년간 사용해 왔습니다. 과거에는 Zeit라는 회사명으로, Now라는 서비스명으로 운영되었습니다. Vercel은 풀스택 애플리케이션 호스팅을 위한 훌륭한 솔루션을 제공하지만, 사람들이 이를 사용하는 데 망설이는 이유도 이해할 수 있습니다. 만약 셀프 호스팅이 가능한 대안을 찾고 계신다면, Hetzner나DigitalOcean에 Coolify를 설치해서 사용하는 것을 추천드립니다.

계속 읽기 : 리액트 프로젝트를 위한 라이브러리

CloudFlare (도메인) : 여러 해 동안 다양한 도메인 관리 서비스를 사용해 봤지만, 요즘은 CloudFlare에 매우 만족하며 모든 도메인을 관리하고 있습니다. CloudFlare는 훌륭한 UI를 제공하며, DNS 레코드에 추가 정보를 첨부할 수 있어 서비스 추적이 더 쉬워집니다.

Stripe (결제 게이트웨이) : 결제 게이트웨이에 대해 강력히 추천하는 서비스는 없습니다. Stripe를 몇 년간 사용해 왔고 만족스럽지만, 사람들이 이를 사용하는 데 주저하는 이유도 이해할 수 있습니다. 훌륭한 문서와 API를 제공하는 한편, API와 기능의 범위를 계속 확장하여 다소 부담스러울 수 있기 때문입니다.

계속 읽기 : 리액트에서의 폼 검증

테스트 및 툴링: 테스팅 및 도구에 대해서도 특별히 강력하게 추천하는 건 없습니다. 요즘은 React Testing Library와 Cypress/Playwright의 조합이 테스트에 적합한 선택이라고 생각합니다. 툴링으로는 ESLint(미래에는 Biome일 수도 있음)와 Prettier를 추천합니다. Storybook을 대체할 수 있는 좋은 대안을 기대하긴 하지만, 여전히 UI 문서를 작성하는 데는 Storybook을 기본 도구로 사용하고 있습니다. 추가적으로, 터미널에서 타입스크립트(예: 데이터베이스 시딩)를 실행하기 위해 tsx를 사용하고 있습니다.

기본적으로 이것들은 제가 오늘 새로운 프로젝트를 시작한다면 선택할 기술 스택이며, “The Road to Next”에서 포괄적인 풀스택 애플리케이션을 위해 가르치는 내용이기도 합니다. 이 글이 여러분의 다음 프로젝트를 위한 결정을 내리는 데 도움이 되길 바랍니다.

🚀 한국어로 된 프런트엔드 아티클을 빠르게 받아보고 싶다면 Korean FE Article(https://kofearticle.substack.com/)을 구독해주세요!