리액트 생태계에는 항상 새로운 기술이 등장하고 있습니다. 이 글에서는 2025년 풀스택 애플리케이션을 위한 인기 있는 리액트 기술 스택들을 살펴보며, 이를 통해 여러분의 제품이나 MVP*를 만들 수 있는 방법을 알아보겠습니다.

*MVP(Minimum Viable Product): 핵심 기능만 갖춘 초기 버전의 제품이나 서비스

 

우선 제가 이 가이드를 작성하게 된 이유를 말씀드리면, 저는 프리랜서 웹 개발자와 개인 창업자로서 수년간 다양한 프로젝트를 진행해 왔습니다. 매년 제가 사용하는 기술 스택을 재평가하고 최신 트렌드를 따라가면서도, 앞으로 몇 년 동안의 프로젝트 안정성과 유지보수성에 주의를 기울이고 있습니다.

 

덧붙이자면, 저는 창업자로서 거의 1년 동안 SaaS*를 개발했고 이 SaaS는 수익성을 갖게 되었습니다. 당시 선택한 기술 스택을 좋아하지만, 새 프로젝트를 시작한다면 다른 기술 스택을 선택할 것입니다.

*SaaS(Service as a Software): 사용자가 소프트웨어를 자신의 컴퓨터에 설치하지 않고 인터넷을 통해 필요할 때마다 이용하는 서비스 모델

 

이 글은 제 연구와 경험, 그리고 2024년 내내 작업한 풀스택 웹 개발 과정에 관한 내용을 바탕으로, 제가 선택한 기술 스택을 반영했습니다. 간략하지만 알차게 담은 목록을 함께 살펴보겠습니다.

 

 

리액트 기술 스택 살펴보기

• Next.js

Next.js는 리액트 위에 구축된 프레임워크입니다. 리액트로 풀스택 애플리케이션을 구축할 때 가장 인기 있는 선택지 중 하나로, 기본적으로 다양한 기능(예: 라우팅, 캐싱)을 제공하고, 다양한 목표를 최적화하기 위한 여러 렌더링 전략을 동일한 애플리케이션 내에서 사용할 수 있으며, 리액트 애플리케이션을 백엔드에 연결하기 위한 최신 리액트 기능(예: 서버 컴포넌트 및 서버 함수)을 모두 지원하고 있습니다.

 

• Astro

Astro는 제품의 랜딩 페이지를 만들기 위한 선택적 대안으로, 정적 및 동적 페이지를 제공할 수 있는 Next.js 프로젝트를 하나의 모놀리식 애플리케이션으로 활용하지 않는 경우 사용할 수 있습니다. Astro를 사용하면 애플리케이션에 서브도메인(예: app.example.com)을 사용하게 되지만, 뛰어난 개발자 경험을 바탕으로 빠른 랜딩 페이지를 만들 수 있습니다. 또한 다양한 종류의 랜딩 페이지 중에서 선택할 수 있어, SaaS 개발에 더 많은 시간을 투자할 수 있습니다. (참고: How to start a React Project)

 

• 서버 컴포넌트

서버 컴포넌트는 모든 React 프레임워크에서 사용할 수 있는 것은 아니지만, Next.js에서는 지원됩니다. 그래서 특별히 언급하고 싶었는데, 이는 풀스택 React 애플리케이션을 구축하는 방식을 바꾸기 때문입니다. 가장 기본적인 형태로, 서버에서 실행되는 컴포넌트를 작성할 수 있게 해주어 서버(예: 데이터베이스)에 접근할 수 있습니다.

 

• 서버 함수

서버 함수는 Next.js에서 지원하는 또 다른 리액트 기능으로, 함수를 호출하는 것만으로 리액트 컴포넌트에서 서버 측 코드를 실행할 수 있게 해줍니다. 이것은 타입이 지정된 원격 프로시저* 호출(RPC)처럼 동작하지만, 내부적으로는 API 엔드포인트*가 자동으로 생성됩니다.

*프로시저: 특정 작업이나 목표를 달성하기 위해 순차적으로 수행해야 하는 일련의 명령어나 단계들을 정의한 것
*엔드포인트: 통신 네트워크에서 통신 채널의 끝부분으로, 서비스나 리소스에 접근할 수 있는 지점 또는 인터페이스를 의미

 

• 서버 액션

서버 액션은 서버 함수의 하위 집합입니다. 사용자 친화적으로 만들기 위한 추상화 레이어를 추가하는 여러 라이브러리가 있지만, 개인적으로는 몇 줄의 코드로 자체 추상화를 쉽게 구현할 수 있기 때문에 아직 사용할 필요성을 느끼지 못했습니다. 그러나 이미 만들어진 솔루션을 찾고 있다면, next-safe-actions 또는 zsa를 확인해 보세요. (참고: React as a full-stack framework)

 

 

• Tailwind CSS

개발자 커뮤니티 내에서 의견이 계속 나뉘고 있지만, 빠른 제품 개발과 장기적인 CSS 유지보수를 위해 오늘날 Tailwind가 최선의 선택이라고 생각합니다. 제 경험과 많은 학생들의 경험에 따르면, 일주일 정도 Tailwind에 익숙해지면 전통적인 CSS 접근 방식으로 돌아가는 것을 상상하기 어렵습니다.

 

• Shadcn UI

UI 라이브러리는 오고 가지만, Shadcn UI는 1년 넘게 인기를 끌고 있습니다. Tailwind CSS와 원활하게 작동하고 버전 없는 시스템으로, UI 관리에 새로운 접근 방식을 제공하는 인기 있는 선택지입니다. 새로운 대세가 등장하거나, 모든 것이 다시 너무 비슷해지기 전까지는 좋은 선택이라고 말할 수 있습니다.

 

• Lucide React

이 아이콘 라이브러리는 이미 Shadcn UI와 함께 제공되기 때문에 다른 것으로 대체할 필요가 없을 것입니다. 다른 대안이 등장하면 다음 프로젝트에서 전환을 고려할 것입니다. Lucide React에는 큰 투자가 필요하지 않습니다. (참고: CSS Styling in React)

 

• 타입스크립트

이 선택에 대해 많이 말할 필요는 없을 것 같습니다. TypeScript는 JavaScript 프로젝트의 업계 표준이 되었으며, 더 나은 개발자 경험, 적은 버그, 유지보수가 용이한 코드를 위한 훌륭한 선택입니다.

 

• Zod

리액트 프로젝트에서 유효성 검사를 위한 업계 표준으로, 타입스크립트와 잘 어울립니다. 요즘 저는 서버 측 유효성 검사(예: 서버 액션)에만 사용하고, 클라이언트 측 폼은 네이티브 HTML 유효성 검사로 가볍게 유지하고 있습니다. 이렇게 하면 서드파티 폼 라이브러리 없이도 폼 컴포넌트에 복잡성이 없어집니다. (참고: State in React)

 

• nuqs

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

 

• Zustand

Zustand는 클라이언트 측 상태 관리를 위한 선택적 옵션입니다. 그러나 URL 상태, 클라이언트 측 데이터 캐싱(예: React Query), 서버 주도 리액트 애플리케이션(예: 서버 컴포넌트)이 클라이언트 측 상태 관리의 필요성을 줄여주었기 때문에 요즘은 클라이언트 측 상태를 거의 사용하지 않습니다.

 

• React Query

React Query는 클라이언트 측 데이터를 가져와야 할 때, 특히 무한 스크롤과 같은 복잡한 구현에 선택적으로 사용하는 옵션입니다. 그러나 프로젝트 복잡성이 낮을 때는 서버 컴포넌트만 사용하는 것이 좋습니다. (참고: Data Fetching in React)

 

• Prisma(ORM)

Prisma는 항상 제가 선택하는 ORM*입니다. 그러나 최신 트렌드에 대한 관심이 항상 있기 때문에, 필요하다면 Drizzle로 대체할 수도 있습니다. 저는 Prisma가 안정적인 선택이고 이미 많은 프로젝트에서 사용되고 있기 때문에 당분간은 Prisma를 고수할 것입니다.

*ORM(Object-Relational Mapping): 객체 지향 프로그래밍 언어와 관계형 데이터베이스 사이의 데이터를 변환하는 프로그래밍 기법

 

 

• Supabase(데이터베이스)

Supabase는 서비스형 데이터베이스로 제가 선택하는 옵션입니다. PostgreSQL 데이터베이스와 더불어 많은 기능을 제공합니다. 개인적으로는 기술 선택의 유연성을 유지하기 위해 다른 기능들의 종속성을 피하고, 데이터베이스 기능만 사용합니다. 데이터베이스의 경우, Prisma로만 연결하고 Supabase의 다양한 기능은 많이 사용하지 않음으로써, 필요할 때 언제든지 다른 데이터베이스(예: Neon)로 교체할 수 있게 합니다.

 

• Lucia(인증)

라이브러리로서 지원이 중단되었음에도 요즘에는 Lucia를 사용합니다. 그러나 여전히 Oslo, Argon2, 선택적으로 Arctic과 같은 라이브러리를 통한 인증의 기본 개념을 가르치는 학습 자료로 사용됩니다. 따라서 Clerk나 Kinde와 같은 서드파티 솔루션에 의존하지 않고, 자신의 필요에 맞게 맞춤화된 직접 구현한 인증 시스템을 갖게 됩니다.

 

• S3(파일 업로드)

Amazon의 AWS S3, 사전 인증된 URL, AWS IAM을 사용하여 자체 파일 업로드 시스템을 구축하는 것은 어렵지 않으며, 가장 저렴한 비용으로 파일을 저장할 수 있는 유연성을 제공합니다. “한 번 구현하고 잊어버리는” 시나리오이므로, 다른 서드파티 솔루션을 사용하지 않는 것은 추천하지 않습니다. 대부분의 서드파티 서비스는 동일한 API를 사용하므로, 필요한 경우 나중에 다른 서비스로 전환할 수 있습니다.

 

• Inngest(큐)

정교한 작업 조율과 백엔드 확장이 필요한 최근 프로젝트에서는 Inngest를 사용했습니다. 개인적으로는 시간에 민감하지 않고, 백그라운드에서 실행할 수 있는 작업에 이를 사용합니다. 간편하게 설정하고 유지할 수 있는 큐 시스템으로 좋은 선택이라고 생각합니다.

 

• React Email + Resend

전자는 리액트 컴포넌트로 이메일 템플릿을 만들 수 있게 해주고, 후자는 이메일을 보내기 위한 훌륭한 솔루션입니다. 이전에는 React Email도 사용할 수 있는 Postmark를 사용했지만, Resend로 전환한 것에 꽤 만족하고 있습니다.

 

• Vercel(호스팅)

저는 몇 년 동안 Vercel을 사용해 왔습니다. 예전에는 Zeit라고 불렸고, 서비스 이름은 Now였습니다. 풀스택 애플리케이션 호스팅을 위한 훌륭한 솔루션을 제공하지만, 사람들이 사용을 주저하는 이유도 이해합니다. 자체 호스팅 대안을 찾고 있다면, Coolify와 함께 Hetzner/DigitalOcean을 사용하는 것을 추천합니다. (참고: Libraries for React projects)

 

• CloudFlare(도메인)

수년간 다양한 도메인 제공업체를 사용했지만, 요즘에는 CloudFlare를 사용하여 모든 도메인을 관리하는 데 꽤 만족하고 있습니다. 훌륭한 UI를 제공하고, DNS 레코드에 추가 정보를 첨부할 수 있어 서비스를 추적하기 쉽습니다.

 

• Stripe(결제 게이트웨이)

결제 게이트웨이에 대한 강력한 추천은 없습니다. 저는 몇 년 동안 Stripe를 사용했고 만족하고 있습니다. 하지만 사람들이 사용을 주저하는 이유를 알 수 있는데, 이미 훌륭한 문서와 API가 있음에도 불구하고, API와 기능이 늘어나서 부담스러울 수 있기 때문입니다.

 

• 테스트 및 도구

테스트와 도구에 대한 강력한 추천은 없습니다. 요즘에는 React Testing Library와 Cypress/Playwright를 혼합하여 사용하는 것이 테스트에 좋은 선택이라고 생각합니다. 도구의 경우, ESLint(앞으로는 Biome일 수도 있음)와 Prettier를 추천합니다. 비록 Storybook 대안이 생기기를 바라고 있지만, 여전히 UI 문서화에는 Storybook이 가장 편리한 솔루션입니다. 추가로 터미널에서 타입스크립트를 실행(예: 데이터베이스 시딩)하기 위해 tsx를 사용하고 있습니다.

 

 

마치며

지금까지 살펴본 내용들은 제가 새 프로젝트를 시작할 때 선택할 기술 스택이며, `The Road to Next`에서 풀스택 애플리케이션 개발을 위해 가르치고 있는 내용이기도 합니다. 이 글이 여러분이 다음 프로젝트에서 기술 스택을 선택하는 데 도움이 되길 바랍니다.

---

<원문>

React Tech Stack [2025]