0ldh

React 프로젝트를 시작하기 전

Thu, 02 Apr 2026 00:00:00 GMT

React 프로젝트를 할 때 마다 Next.js를 고집하려고 했었는데, 최근에 든 생각이 ‘Next.js는 좀 과한가(over-engineering)?’ 였다. 물론 Next.js는 훌륭한 프레임워크이고, 많은 프로젝트에서 훌륭한 선택지이지만, 굳이? 라는 생각이 들 때가 종종 있었어서, React 관련 라이브러리들을 찾아보다가 좋은 글을 발견해서 옮겨왔다. 번역은 클로드가 해주었다.

클로드 버디 너무 귀엽다. (한국시간 기준)4월 1일 새벽에 Claude Code의 소스코드가 유출되고 안에 있던 기능 중 하나인데, 4월 1일 점심쯤에 추가되었다. 처음엔 만우절용 이벤트인줄

2025년 React 라이브러리 가이드

원문: React Libraries for 2025 — Robin Wieruch (2025년 2월 17일)

React는 꽤 오랜 시간 존재해왔으며, 그동안 방대하면서도 때로는 압도적인 라이브러리 생태계가 형성되었습니다. 다른 언어나 프레임워크에서 전환하는 개발자들은 React로 웹 애플리케이션을 구축하는 데 필요한 수많은 라이브러리들을 탐색하는 데 어려움을 겪곤 합니다.

React의 핵심은 함수 컴포넌트를 사용하여 컴포넌트 기반 사용자 인터페이스를 구축하는 것입니다. React Hooks와 같은 내장 솔루션으로 로컬 상태를 관리하고, 사이드 이펙트를 처리하며, 성능을 최적화할 수 있지만, 결국 모든 것은 함수(컴포넌트와 훅 모두)를 활용하여 UI를 구성하는 것으로 귀결됩니다.

이 글에서는 2025년에 꼭 알아야 할 React 라이브러리들을 살펴봅니다. 이 라이브러리들은 React로 대규모 애플리케이션을 개발하기 위한 핵심 구성 요소입니다. 초보자든 숙련된 개발자든, 이 가이드가 방대한 React 생태계를 쉽게 탐색하는 데 도움이 될 것입니다.

새로운 React 프로젝트 시작하기

React 초보자가 가장 먼저 하는 질문은 “React 프로젝트를 어떻게 셋업하나요?“입니다. 워낙 많은 도구가 있다 보니 올바른 선택을 하기가 부담스러울 수 있습니다. React 커뮤니티에서 가장 인기 있는 옵션은 Vite입니다. Vite를 사용하면 다양한 라이브러리(React 포함)와 선택적 TypeScript 지원으로 프로젝트를 쉽게 생성할 수 있습니다. Vite는 또한 뛰어난 성능을 제공합니다.

이미 React에 익숙하다면 Vite 대신 인기 있는 (메타) 프레임워크 중 하나를 고려해볼 수 있습니다. Next.js는 React 위에 구축된 널리 사용되는 선택지로, React의 기본기를 이해하는 것이 필수입니다. 다양한 렌더링 기법, 파일 기반 라우팅, API 라우트 등 많은 기능이 기본 내장되어 있습니다.

Next.js는 처음에 서버 사이드 렌더링(웹 애플리케이션)에 사용되었지만, 정적 사이트 생성(웹사이트)이나 기타 렌더링 패턴(ISR 등)에도 활용할 수 있습니다. 가장 최근 Next.js에 추가된 것은 React Server Components(RSC)와 React Server Functions(RSF)로, 2023년부터 React 컴포넌트를 클라이언트에서 서버로 이동시키는 큰 패러다임 전환에 기여하고 있습니다.

Next.js의 대안으로는 TanStack Start(베타)와 React Router(Remix에서 전환 중)가 있으며, 이들은 아직 React Server Components를 지원하지 않습니다.

정적 콘텐츠의 성능이 최우선이라면 Astro를 살펴보세요. 프레임워크에 구애받지 않는 도구로, 컴포넌트에 React를 사용하더라도 브라우저에는 HTML과 CSS만 전달합니다. JavaScript는 컴포넌트에 상호작용이 필요할 때만 로드되어 최적의 성능을 보장합니다.

Vite 같은 도구가 어떻게 동작하는지 이해하고 싶다면 직접 React 프로젝트를 셋업해 보세요. 순수 HTML과 JavaScript 프로젝트에서 시작하여 React와 관련 도구(Webpack, Babel 등)를 직접 추가합니다. Vite가 Webpack의 후계자가 된 이후 실무에서 할 일은 아니지만, 기반 도구를 이해하는 좋은 학습 경험이 됩니다.

React 베테랑이라면 Nitro, Redwood, 또는 Waku도 확인해 보세요. Waku는 Zustand 개발자가 만들었으며, React Server Components(RSC) 지원도 포함되어 있습니다.

추천:

Vite → 클라이언트 사이드 렌더링 React 애플리케이션
Next.js → 서버 사이드 렌더링 React 애플리케이션
Astro → 정적 사이트 생성 React 애플리케이션

React를 위한 패키지 매니저

JavaScript 생태계(따라서 React)에서 라이브러리(의존성, 노드 패키지)를 설치하는 데 가장 널리 사용되는 패키지 매니저는 npm입니다. 모든 Node.js 설치에 포함되어 있기 때문입니다. 하지만 yarn과 pnpm도 훌륭한 대안입니다. 특히 pnpm은 더 높은 성능을 제공합니다.

서로 의존하거나 공통 커스텀 UI 컴포넌트를 공유하는 여러 React 애플리케이션을 만드는 경우, 모노레포(monorepo) 개념을 확인해 보세요. 앞서 언급한 모든 패키지 매니저는 자체 워크스페이스 기능을 사용하여 모노레포를 생성할 수 있지만, yarn이나 pnpm을 사용하는 것이 개발자 경험이 가장 좋았습니다. Turborepo와 같은 모노레포 파이프라인 도구와 결합하면 모노레포 경험이 완벽해집니다.

추천:

하나의 패키지 매니저를 선택하고 일관되게 사용
- 기본이자 가장 널리 사용 → npm
- 성능은 높지만 인기는 상대적으로 적음 → pnpm
모노레포가 필요하다면 Turborepo 확인

React 상태 관리

React는 로컬 상태 관리를 위한 두 가지 내장 훅을 제공합니다: useState와 useReducer. 전역 상태 관리를 위해서는 내장 useContext 훅을 사용하여 props에 의존하지 않고 최상위 컴포넌트에서 하위 컴포넌트로 데이터를 전달할 수 있으며, 이는 prop drilling을 효과적으로 방지합니다.

이 세 가지 React 훅을 통해 개발자는 React의 useState/useReducer 훅으로 컴포넌트에 코로케이팅하거나, useContext 훅과 결합하여 전역으로 관리하는 강력한 상태 관리를 구현할 수 있습니다.

공유/전역 상태에 React의 Context를 너무 자주 사용하고 있다면, Zustand를 꼭 확인해 보세요. 스토어에 연결된 모든 React 컴포넌트에서 읽고 수정할 수 있는 전역 애플리케이션 상태를 관리할 수 있습니다.

Zustand가 React 커뮤니티에서 사실상의 표준이 되어가고 있지만, 많은 프로젝트에서 여전히 Redux를 사용합니다. 개인적으로 지난 몇 년간 프리랜서 작업에서 Redux를 사용한 적이 없으며, 단순성 때문에 Zustand를 선호합니다. 하지만 Redux로 만들어진 오래된 React 애플리케이션은 많이 만나게 될 것입니다.

Redux를 사용한다면 Redux Toolkit도 꼭 확인하세요. 상태 머신에 관심이 있다면 XState나 Zag를 살펴보세요. Zustand나 Redux가 마음에 들지 않지만 전역 스토어가 필요하다면, Mobx, Jotai, Nano Stores 같은 다른 인기 있는 로컬 상태 관리 솔루션도 확인해 보세요.

추천:

useState/useReducer → 코로케이팅 또는 공유 상태
useContext를 선택적으로 사용 → 적은 전역 상태에 활용
Zustand(또는 대안) → 많은 전역 상태에 활용

React 데이터 패칭

React의 내장 훅은 UI 상태에는 훌륭하지만, 원격 데이터의 상태 관리(캐싱)에는 TanStack Query(이전 React Query)와 같은 전용 데이터 패칭 라이브러리를 사용하는 것을 추천합니다.

TanStack Query 자체는 상태 관리 라이브러리로 보지 않습니다. 주로 API에서 원격 데이터를 가져오는 데 사용되기 때문입니다. 하지만 이 원격 데이터의 모든 상태 관리(캐싱, 낙관적 업데이트 등)를 대신 처리해 줍니다.

TanStack Query는 REST API를 소비하도록 설계되었습니다. 그러나 요즘은 GraphQL도 지원합니다. React 프론트엔드를 위한 더 전문적인 GraphQL 라이브러리를 찾고 있다면 Apollo Client(인기), urql(경량), Relay(Facebook 제작)를 확인해 보세요.

이미 Redux를 사용하고 있으면서 TanStack Query 대신 Redux에 통합된 데이터 패칭을 추가하고 싶다면, RTK Query를 확인해 보세요. Redux에 데이터 패칭을 깔끔하게 통합합니다.

프론트엔드와 백엔드(둘 다 TypeScript)를 모두 제어한다면, 엔드투엔드 타입 안전 API를 위해 tRPC를 확인해 보세요. 생산성과 개발자 경험(DX)이 엄청나게 향상됩니다. TanStack Query와 결합하여 데이터 패칭의 모든 편의 기능을 누리면서 타입이 지정된 함수를 사용하여 프론트엔드에서 백엔드를 호출할 수도 있습니다.

마지막으로, React Server Components/Server Functions(RSC/RSF)를 지원하는 (메타) 프레임워크(예: Next.js)를 사용한다면, 데이터 패칭에 이를 활용할 수 있습니다. 서버에서 데이터를 가져와 클라이언트로 전달할 수 있어, 클라이언트 측 데이터 패칭 라이브러리가 필요 없게 됩니다.

추천:

서버 사이드 데이터 패칭
- React Server Components/Functions ((메타) 프레임워크가 지원하는 경우)
클라이언트 사이드 데이터 패칭
- TanStack Query (REST API 또는 GraphQL API)
  - axios 또는 fetch와 결합
- Apollo Client (GraphQL API)
  - 더 정교한 GraphQL 경험을 위해
tRPC → 긴밀하게 결합된 클라이언트-서버 아키텍처

React Router를 이용한 라우팅

Next.js 같은 React 프레임워크를 사용하고 있다면 라우팅은 이미 해결되어 있습니다. 하지만 프레임워크 없이 클라이언트 사이드 렌더링만으로 React를 사용한다면(예: SSR 없는 Vite), 가장 인기 있는 라우팅 라이브러리는 React Router입니다.

하지만 올해는 TanStack Router의 해가 될 수도 있습니다. React를 위한 새로운 라우팅 라이브러리로, 특히 프로젝트에서 TypeScript를 사용한다면 React Router의 훌륭한 대안입니다. 아직 베타이지만, TanStack에 익숙한 사람이라면 훌륭할 것이라는 걸 알 것입니다.

React Router와 TanStack Router(TanStack Start 포함) 모두 React Server Components(RSC) 지원을 작업 중입니다. 이를 통해 다양한 용도(번들 크기 축소, 서버 사이드 데이터 패칭 등)로 서버에서 컴포넌트를 실행할 수 있게 됩니다.

React 프로젝트에 라우터를 도입하기 전에, React를 막 배우는 중이라면 먼저 React의 조건부 렌더링을 시도해 보세요. 라우팅을 대체하지는 않지만, 페이지 레벨에서 컴포넌트를 교체하는 것이 어떻게 동작하는지 엿볼 수 있습니다.

추천:

서버 사이드 라우팅: Next.js
클라이언트 사이드 라우팅:
- 가장 많이 사용: React Router
- 트렌드: TanStack Router

React에서의 CSS 스타일링

React에서의 스타일링/CSS에 대한 옵션과 의견은 매우 다양하므로, 하나의 섹션으로 모든 것을 담기에는 부족합니다.

React 초보자라면 JSX에서 스타일 객체를 사용하여 인라인 스타일과 기본 CSS로 시작해도 괜찮습니다. 다만 실제 애플리케이션에서는 거의 사용하지 않아야 합니다:

const Headline = ({ title }) =>
  <h1 style={{ color: 'blue' }}>
    {title}
  </h1>

인라인 스타일은 React의 JSX에서 JavaScript로 동적으로 스타일을 추가할 수 있고, 외부 CSS 파일은 React 애플리케이션의 나머지 스타일을 담을 수 있습니다:

import './Headline.css';

const Headline = ({ title }) =>
  <h1 className="headline" style={{ color: 'blue' }}>
    {title}
  </h1>

애플리케이션이 커지면 다른 스타일링 접근법을 확인해야 합니다. 한 가지 팁: React에서 className을 조건부로 적용하고 싶다면 clsx 같은 유틸리티 라이브러리를 사용하세요.

첫째, 가장 인기 있는 유틸리티 퍼스트 CSS 솔루션으로 Tailwind CSS를 추천합니다. 미리 정의된 CSS 클래스가 제공되어 개발자로서 더 효율적이고 React 애플리케이션의 디자인 시스템을 간소화합니다. 다만 모든 클래스를 알아야 하고 많은 CSS 클래스를 인라인으로 작성해야 하는 트레이드오프가 있습니다:

const Headline = ({ title }) =>
  <h1 className="text-blue-700">
    {title}
  </h1>

둘째, 여러 CSS-in-CSS 솔루션 중 하나인 CSS Modules를 살펴보는 것을 추천합니다. CSS Modules는 CSS를 컴포넌트와 함께 위치한 모듈로 캡슐화할 수 있습니다. 이렇게 하면 스타일이 실수로 다른 컴포넌트로 누출되지 않습니다:

import styles from './style.module.css';

const Headline = ({ title }) =>
  <h1 className={styles.headline}>
    {title}
  </h1>

셋째, 여러 CSS-in-JS 솔루션 중 하나인 Styled Components를 소개합니다(더 이상 추천하지는 않습니다). 이 접근법은 styled-components 라이브러리(또는 emotion 같은 대안)로 제공되며, JavaScript로 생성된 스타일링을 React 컴포넌트와 같은 파일 또는 인접 파일에 함께 배치합니다:

import styled from 'styled-components';

const BlueHeadline = styled.h1`
  color: blue;
`;

const Headline = ({ title }) =>
  <BlueHeadline>
    {title}
  </BlueHeadline>

CSS-in-CSS를 선택하든 유틸리티 퍼스트 CSS를 선택하든 여러분의 몫입니다. 트렌드는 Tailwind CSS를 업계 표준으로 하는 유틸리티 퍼스트 CSS로 향하고 있습니다. CSS-in-JS 솔루션은 서버 사이드 환경에서의 성능 및 하이드레이션 문제로 인기가 줄었지만, 새로운 솔루션들(Styled Components나 Emotion만큼 인기 있지는 않지만)이 이 문제를 해결하고 있습니다.

확인해볼 만한 다른 라이브러리: PandaCSS, linaria, vanilla-extract, nanocss, UnoCSS, Styled JSX

추천:

유틸리티 퍼스트 CSS (가장 인기)
- 예: Tailwind CSS
CSS-in-CSS
- 예: CSS Modules
CSS-in-JS
- 예: StyleX (Facebook 제작, 유틸리티 퍼스트 CSS로 컴파일)

React UI 라이브러리

초보자에게는 재사용 가능한 컴포넌트를 처음부터 직접 만드는 것이 훌륭하고 추천할 만한 학습 경험입니다. 드롭다운, 셀렉트, 라디오 버튼, 체크박스 등을 직접 만들 수 있어야 합니다.

하지만 모든 컴포넌트를 직접 만들 리소스가 없다면, 동일한 디자인 시스템, 기능, 접근성 규칙을 공유하는 다수의 미리 만들어진 컴포넌트에 접근할 수 있는 UI 라이브러리를 사용할 수 있습니다:

Material UI (MUI) (프리랜서 프로젝트에서 여전히 가장 많이 요구됨)
Mantine UI (2022년 가장 인기)
Chakra UI (2021년 가장 인기)
Hero UI (이전 Next UI)
Park UI (Ark UI 기반)
PrimeReact

하지만 트렌드는 헤드리스 UI 라이브러리로 이동하고 있습니다. 스타일링 없이 현대적인 컴포넌트 라이브러리에 필요한 모든 기능과 접근성을 갖추고 있습니다. 대부분 Tailwind 같은 유틸리티 퍼스트 CSS 솔루션과 결합됩니다:

shadcn/ui (2023~2024년 가장 인기)
Radix (shadcn/ui의 기반)
React Aria
Ark UI (Chakra UI 제작자)
Ariakit
Daisy UI
Headless UI
Tailwind UI (유료)

다른 UI 라이브러리에 비해 상대적으로 유행에서 벗어난 것들:

React 애니메이션 라이브러리

웹 애플리케이션의 모든 애니메이션은 CSS에서 시작됩니다. 하지만 CSS 애니메이션이 요구사항을 완전히 충족하지 못한다는 것을 곧 깨닫게 됩니다. React에서 인기 있는 애니메이션 라이브러리는 다음과 같습니다:

Motion (가장 추천, 이전 Framer Motion)
react-spring

React 시각화 및 차트 라이브러리

차트를 처음부터 직접 만들고 싶다면 D3를 빼놓을 수 없습니다. 놀라운 차트를 만드는 데 필요한 모든 것을 제공하는 저수준 시각화 라이브러리입니다. 하지만 D3를 배우는 것은 또 다른 모험이므로, 많은 개발자들은 유연성을 대가로 모든 것을 해결해주는 React 차트 라이브러리를 선택합니다:

Recharts (개인적으로 추천)
- 바로 사용 가능한 차트
- 뛰어난 컴포저빌리티
- 선택적 컴포저빌리티를 통한 커스터마이징
visx
- 고수준 추상화보다 저수준 D3에 가까움
- 학습 곡선이 가파름
더 많은 기성 차트, 커스터마이징이 어려움

React 폼 라이브러리

React에서 폼을 위한 가장 인기 있는 라이브러리는 단연 React Hook Form입니다. 유효성 검사(zod가 가장 인기), 폼 제출, 폼 상태 관리 등 필요한 모든 것을 제공합니다.

새롭게 떠오르는 대안으로 풀스택 애플리케이션과 더 잘 통합되는 Conform이 있습니다.

대안으로 Formik이나 React Final Form을 사용할 수 있습니다. React UI 라이브러리를 사용한다면, 이 폼 라이브러리들과 어떻게 통합되는지 확인해 보세요.

추천:

React Hook Form
- 유효성 검사를 위한 zod 통합

React 코드 구조

통일되고 합리적인 코드 스타일을 갖추려면 React 프로젝트에 ESLint를 사용하세요. ESLint 같은 린터는 특정 코드 스타일을 강제합니다. 예를 들어, ESLint로 인기 있는 스타일 가이드를 따르도록 요구할 수 있습니다. IDE/에디터에 ESLint를 통합하면 모든 실수를 지적해 줍니다.

통일된 코드 포맷을 갖추려면 React 프로젝트에 Prettier를 사용하세요. 소수의 선택적 설정만 있는 독선적인 코드 포맷터입니다. 에디터나 IDE에 통합하여 파일을 저장할 때마다 코드를 포맷할 수 있습니다. Prettier는 ESLint를 대체하지 않지만, ESLint와 잘 통합됩니다.

2025년의 떠오르는 스타로 Biome(이전 Rome)이 있을 수 있습니다. ESLint와 Prettier는 설정과 특히 상호 작용 면에서 가장 좋아하는 유틸리티는 아닙니다. 하지만 모든 웹 개발자의 일상에서 필수적입니다. Biome은 빠르고(Rust 기반) 올인원 도구 체인을 제공하여 Prettier와 ESLint의 대안이 되고자 합니다.

추천:

ESLint + Prettier
선택적으로 Biome 확인

React 인증

React 애플리케이션에서 회원가입, 로그인, 로그아웃 같은 인증 기능을 도입할 수 있습니다. 비밀번호 재설정이나 변경 기능도 자주 필요합니다. 이런 기능은 React를 넘어서며, 백엔드 애플리케이션이 처리합니다.

가장 좋은 학습 경험은 직접 인증이 포함된 풀스택 애플리케이션을 구현하는 것입니다(예: The Road to Next). 인증에는 많은 보안 위험과 세부 사항이 있으므로, 프로덕션에서는 서드파티 서비스를 사용하는 것을 추천합니다:

Lucia (리소스)
- Oslo: 인증 및 암호화
- Arctic: 50개 이상 프로바이더 지원 OAuth 2.0
Better Auth
Auth.js
Clerk (유료) 또는 Kinde (유료)
Supabase (Auth)
AuthKit
Auth0
AWS Cognito

React 백엔드

React를 서버로 이동시키는 강한 트렌드가 있으므로, React 프로젝트의 가장 자연스러운 환경은 Next.js(주로 동적 웹 애플리케이션)나 Astro(주로 정적 웹사이트) 같은 (메타) 프레임워크입니다. React Router(이전 Remix)와 TanStack Start도 훌륭한 대안이지만, 개발 초기 단계에 있습니다.

여러 이유로 풀스택 프레임워크를 사용할 수 없지만 JS/TS는 사용할 수 있다면, tRPC나 Hono를 확인해 보세요. 오래되었지만 가장 인기 있는 Node 백엔드인 Express도 있습니다. 다른 대안으로는 Fastify, Nest, Elysia가 있습니다.

Koa와 Hapi도 언급할 가치가 있습니다.

React 데이터베이스

React에만 국한된 것은 아니지만, 풀스택 React 애플리케이션이 인기를 끌면서 React는 그 어느 때보다 데이터베이스 레이어에 가까워졌습니다. Next.js 애플리케이션을 개발할 때 대부분 데이터베이스 ORM을 다루게 됩니다. 요즘 가장 인기 있는 ORM은 Prisma입니다. 트렌드 대안으로는 Drizzle ORM이 있습니다.

다른 대안으로는 Kysely와 database-js(PlanetScale 전용)가 있습니다.

데이터베이스 선택에 있어서 Supabase(또는 Firebase)는 유효한 데이터베이스 프로바이더입니다. Supabase의 PostgreSQL은 셀프 호스팅하거나 유료 서비스로 사용할 수 있습니다.

인기 있는 서버리스 데이터베이스 대안으로는 PlanetScale(유료), Neon, Xata, Turso가 있습니다.

React 호스팅

React 애플리케이션을 배포하고 호스팅하는 것은 다른 웹 앱을 배포하는 것과 비슷합니다. 환경을 완전히 제어하려면 Digital Ocean이나 Hetzner 같은 서비스를 고려해 보세요. 이러한 옵션은 인프라를 직접 관리할 수 있게 해줍니다.

호스팅 플랫폼이 모든 것을 관리해주는 편리한 접근법을 선호한다면, Vercel이 좋은 선택입니다. 특히 Next.js로 빌드된 프로젝트에 적합합니다.

중간 지점으로 Coolify가 있습니다. 어느 정도 자율성을 제공하면서 많은 호스팅 작업을 간소화합니다.

Firebase/Supabase 같은 서드파티 BaaS(Backend as a Service)를 이미 사용하고 있다면 호스팅도 제공하는지 확인해 보세요. 다른 인기 있는 호스팅 프로바이더로는 Render, Fly.io, Railway, 또는 CloudFlare/AWS/Azure/Google Cloud에 직접 배포하는 방법이 있습니다.

React 테스팅

React 애플리케이션 테스팅의 백본은 Vitest(추천) 또는 Jest 같은 테스트 프레임워크입니다. 테스트 러너, 어설션 라이브러리, 스파이/모킹/스터빙 기능을 제공합니다. 종합적인 테스트 프레임워크에 필요한 모든 것이 갖춰져 있습니다.

결국 인기 있는 React Testing Library (RTL)를 사용하게 될 것입니다. RTL은 테스트 프레임워크 환경 내에서 사용되며, React를 위한 종합적인 테스팅 라이브러리입니다. RTL을 사용하면 컴포넌트를 렌더링하고 HTML 요소에서 이벤트를 시뮬레이션할 수 있습니다. 그 후 테스트 프레임워크가 어설션에 사용됩니다.

React E2E(End-to-End) 테스팅 도구로는 Playwright(추천)와 Cypress가 가장 널리 추천되는 인기 옵션입니다. 두 도구 모두 브라우저 내에서 사용자 상호작용을 자동화하고 시뮬레이션하여, React 애플리케이션이 사용자 관점에서 예상대로 동작하는지 확인할 수 있습니다.

추천:

유닛/통합 테스트: Vitest + React Testing Library (가장 인기)
E2E 테스트: Playwright (또는 Cypress)
선택적으로 Vitest로 스냅샷 테스트

React와 불변 데이터 구조

바닐라 JavaScript는 데이터 구조를 불변으로 다루기 위한 충분한 내장 도구를 제공합니다. 하지만 팀과 함께 불변 데이터 구조를 강제해야 한다면, 가장 인기 있는 선택은 Immer입니다.

React 국제화(i18n)

React 애플리케이션의 국제화(i18n)에 대해서는 번역뿐만 아니라 복수형, 날짜와 통화 포맷팅, 그리고 여러 다른 것들도 고려해야 합니다. 이를 위한 가장 인기 있는 라이브러리는 다음과 같습니다:

React 리치 텍스트 에디터

React의 리치 텍스트 에디터로는 다음을 떠올릴 수 있습니다:

React 결제

React 애플리케이션에 결제 솔루션을 통합할 때 Stripe와 PayPal이 가장 일반적으로 사용되는 프로바이더입니다. 둘 다 React를 위한 매끄러운 통합 옵션을 제공합니다.

PayPal
Stripe
- React Stripe Elements
- Stripe Checkout

다른 결제 프로바이더로는 경쟁사에 인수된 Braintree(PayPal)와 Lemon Squeezy(Stripe)가 있습니다.

React에서의 시간 처리

React 애플리케이션에서 날짜, 시간, 타임존을 자주 다룬다면, 이를 효율적으로 관리하기 위한 전용 라이브러리를 고려해 보세요:

React 데스크톱 애플리케이션

Electron과 Tauri가 크로스 플랫폼 데스크톱 애플리케이션을 위한 대표적인 프레임워크입니다.

React 파일 업로드

type="file" 속성의 input 필드
react-dropzone

React 이메일

HTML만으로 이메일을 렌더링하는 것은 고통스럽습니다. 다행히 React 컴포넌트로 반응형 HTML 이메일을 만들 수 있도록 도와주는 라이브러리들이 있습니다:

이메일 서비스 프로바이더를 찾고 있다면 Resend, Postmark, SendGrid, Mailgun을 확인해 보세요.

드래그 앤 드롭

개인적으로 react-beautiful-dnd의 후속 라이브러리를 사용해 보았고 부정적으로 말할 것이 없습니다. 훨씬 더 많은 유연성과 옵션을 제공하지만 학습 곡선이 가파른 인기 대안으로는 dnd kit가 있습니다.

React 모바일 개발

React를 웹에서 모바일로 가져오기 위한 대표적인 솔루션은 여전히 React Native입니다. React Native 애플리케이션을 만들기 위한 가장 인기 있는 프레임워크는 Expo입니다. 웹과 모바일에서 통합된 컴포넌트가 필요하다면 Tamagui를 확인해 보세요.

React VR/AR

React로 가상 현실이나 증강 현실에 뛰어드는 것이 가능합니다. 솔직히 이 라이브러리들을 직접 사용해 본 적은 없고 대부분 초기 단계(실험적)이지만, React에서 AR/VR 하면 떠오르는 것들입니다:

react-three-fiber (인기 있는 3D 라이브러리, VR 예제도 있음)
react-360 (아카이브됨)
aframe-react (더 이상 유지보수되지 않음)

React 디자인 프로토타이핑

UI/UX 배경에서 왔다면, 새로운 React 컴포넌트, 레이아웃, UI/UX 컨셉을 빠르게 프로토타이핑하기 위한 도구를 사용하고 싶을 것입니다. 개인적으로 Figma를 사용합니다. 러프하지만 가벼운 스케치에는 Excalidraw를 좋아하고, 다른 사람들은 tldraw를 선호합니다.

React 컴포넌트 문서화

컴포넌트 문서를 작성해야 한다면, 다양한 멋진 React 문서화 도구들이 있습니다. 여러 프로젝트에서 Storybook을 사용해 보았고 중립적인 의견을 가지고 있습니다. 다른 솔루션들에 대해서도 좋은 평가를 들었습니다:

마무리

궁극적으로 React 생태계는 React를 중심으로 한 유연한 프레임워크로 기능합니다. 어떤 라이브러리를 도입할지 정보에 기반한 선택을 할 수 있으며, 작게 시작하여 특정 과제를 해결하기 위해 필요에 따라 라이브러리를 추가할 수 있습니다. 반대로, React만으로 요구사항이 충족된다면 코어 라이브러리만 사용하여 가벼운 셋업을 유지할 수 있습니다.

Antigravity와 Codex에 정착하기까지

Thu, 26 Feb 2026 00:00:00 GMT

AI 코딩 에이전트와의 시작

나는 꽤 오래전부터 AI 코딩 에이전트를 사용해왔다. GitHub Copilot 초창기 Beta 때 Waitlist에 등록하고, VSCode-insider에서 처음 써봤으니 말이다.

VSCode-insider에서 GitHub Copilot Chat을 사용할 수 있게 됐다는 2023년 5월 24일 메일이다.

생각보다 꽤 많이 오래 전이다. 2024년도 일 줄 알았는데…

결제내역을 확인해보니 23년 5월 14일부터 Copilot 1년 요금제를 결제하고 시작했다. 그 이후로 쭉 사용하다가, Copilot 1년 요금제를 다시 결제한 지 얼마 안 되어 Cursor의 존재를 알게 됐다. 처음 Cursor를 써봤을 때, Tab 자동완성 기능이 너무 편해서 깜짝 놀랐던 기억이 난다.

하지만 이미 Copilot 1년 요금제를 결제한 상태라 선뜻 추가 결제를 하지 못하고 있다가, 9월에 Cursor 한 달 요금제로 시험 삼아 써보기로 했다. 한 달간의 경험이 워낙 좋았어서, 이중 지출을 감수하고 Cursor도 1년을 결제했다.

그런데 Cursor 1년 요금제를 결제하고 나서 사용하는 동안, 수많은 AI 코딩 에이전트들이 쏟아져 나오기 시작했다. 그렇게 오래된 만큼 AI 코딩 에이전트의 발전을 꽤 가까이서 지켜볼 수 있었고, 많은 IDE와 CLI를 사용해보며 거쳐왔다.

거쳐온 AI 코딩 에이전트들

그동안 사용해본 AI 코딩 에이전트는 다음과 같다.

GitHub Copilot
Cursor
Windsurf
Warp
Kiro
Zed
Gemini Code Assist
Claude Code(클로드 코드)
Gemini CLI
Codex(코덱스)
Antigravity
TRAE
v0
Tabnine

이 외에도 다른 AI 코딩 에이전트들이 있었을 거라고 생각하지만, 기억나는 것만 적었다. TRAE는 SWE-Bench가 높길래 사용해보려 했는데, 대규모 개인정보 무단 수집 논란 때문에 사용하지 않았다.

결제까지 했던 에이전트

대부분 무료체험 기간이 있었는데, 체험 후 결제까지 진행했던 에이전트는 다음과 같다.

GitHub Copilot
Cursor
Claude Code(클로드 코드)
Gemini CLI
Antigravity ( 현재 사용중 - IDE)
Codex(코덱스) ( 현재 사용중 - Antigravity에서 Extension으로 사용중)

결제하지 않았지만 인상 깊었던 에이전트

결제하고 싶었지만 아쉬운 부분이 있어서 결제까지는 하지 않은 에이전트들도 있다. 공통적으로 UI/UX가 개인적으로 매우 마음에 들었었다.

Warp (터미널, 영어 장벽)
Zed (IDE, 영어 장벽)
Kiro (IDE, 무거움)
v0 (코드 생성, 회사 프로젝트보다는 개인 아이디어 구현에 적합하다고 느낌)

특히 Kiro에 대해서는 할 말이 좀 있다. Kiro의 Spec 기반 개발 방식이 너무 마음에 들었다. Requirement > Design > Task List > Implement plan 순서로 진행되는 워크플로우와 UI/UX가 인상적이었고, 심지어 테마 색감까지 마음에 들어서 테마를 직접 만들어 사용하기도 했다.

이 작업 방식에서 많은 영감을 받아, Claude code agents orchestra의 CLAUDE.md.example에 청사진(Blueprint)을 제공하라는 지침을 추가하게 됐다. Kiro의 영향인지는 확실치 않지만, 이후 출시되거나 업데이트된 AI 코딩 에이전트들에는 Plan Mode가 추가되는 추세가 생겼다. Github에서도 AI 코딩 에이전트가 Spec 기반으로 개발하도록 Spec-kit을 오픈소스로 선보이기도 했다.

다만 Kiro는 전체적으로 무거운 느낌이 있어서 결제까지는 하지 않았다. ( 지금은 CLI까지 나와서 다시 써봐도 좋을 듯하다 )

결제 후 사용했던 에이전트 후기

결제한 에이전트들을 실제로 사용하면서 느꼈던 점들을 정리해보았다.

GitHub Copilot

초창기에 사용했는데, 당시에는 굉장히 놀랍고 신기했다. 하지만 지금 돌아보면 모델 성능 자체가 부족해서 사람이 꽤 많이 손을 봐야 했다.

Copilot을 쓸 때 영어 노래 가사와 번역본을 .json 파일에 구조에 맞게 입력하는 작업을 했었다. 영상 자막 타이밍에 맞춰 시간대별로 가사를 분류하고, 타임라인에 맞게 배치해야 하는 작업이었다. 그런데 내가 제공한 번역본을 사용하지 않고, Copilot이 영어 가사를 마음대로 번역해서 자막을 생성해버리는 큰 사고가 있었다. 결국 모든 팀원이 잘못 번역된 자막을 찾아 검수하는 작업을 해야 했다. 그때 생각하면 아직도 팀원들에게 죄송하고 감사하다… ( 이후에 그럴 수 있다고 위로까지 해주셔서 정말 감사했다… ) 그 사건 이후로는 AI 결과물을 두 번, 세 번 확인하는 버릇이 생겼다.

나름 긍정적인 영향도 있었는데, 이때부터 다른 개발자 팀원분들도 AI를 사용하게 되셨다. ( 부장님까지 )

좋은 에이전트였으나, Cursor의 등장 이후로는 자연스럽게 Copilot을 사용하지 않게 되었다.

Cursor

Tab 자동완성 기능이 첫인상부터 강렬했다. 1년 구독 기간 동안 Composer, Bugbot 등 신규 기능이 지속적으로 추가되어 매우 만족스러웠다. 하지만 요금제가 비싸져서, 다른 AI 코딩 에이전트들을 살펴보게 되었다.

Claude Code(클로드 코드)

아마 클로드 코드에 가장 많이 지출한 것 같다.

클로드 코드를 쓰면서 MCP(Model Context Protocol)를 처음 접하게 되었다. 처음에는 MCP를 많이 설치해봤지만, 결국 실제로 쓰는 기능은 몇 개 안 되어서 최소화했다. (뭐든 과한 건 별로라고 느꼈다)

그중 zen-mcp-server(지금은 pal-mcp-server)가 가장 인상 깊었다. 기존 AI 코딩 에이전트는 단일 모델만 사용했는데, 이 MCP를 통해 여러 모델을 동시에 연결하여 AI끼리 협업하고 교차 검증하는 워크플로우를 구성할 수 있었다. 덕분에 OpenRouter도 처음 사용해봤다. 다만 API 비용이 추가로 발생해서, 결국 사용을 중단하게 됐다.

이후 Subagent 기능이 등장하면서, 각 subagent에게 개별적인 페르소나(시스템 프롬프트, rule)를 부여할 수 있게 되었다. zen-mcp-server에서 얻은 아이디어를 응용해, 오케스트레이션(orchestration) 워크플로우로 작업을 수행하는 Claude code agents orchestra를 구현하기도 했다.

요금제는 $20 플랜으로 시작해서 직전에는 $100 플랜까지 올렸는데, Opus 모델을 충분히 사용하기에는 여전히 모자란 느낌이 있었다. 차선책으로 Opus로 계획을 짜고, Sonnet으로 코드를 작성하는 방식으로 사용해봤다.

클로드 코드는 Codex와 한동안 병행했지만, Codex 대비 사용량이 적고 비용이 높아서 결국 Codex로 완전히 넘어가게 되었다.

Gemini CLI

사실상 무료로 사용 가능했던 걸로 기억한다. Pro 요금제에서 한도가 좀 더 넉넉했던 걸로 기억한다. CLI로 Gemini를 처음 사용해봤는데, 잔버그가 꽤 있었다. 결과물도 만족스럽지 않아서 점점 사용하지 않게 되었다.

Codex

Claude Code 대비 사용량이 넉넉하고 GPT 모델도 마음에 들어서 가성비로 선택했다. 무엇보다 Codex 전용 모델이 따로 존재한다는 점이 매력적이었다. 처음에는 CLI로 사용했는데, 지금은 Antigravity의 Extension으로 사용하고 있다. 아직 한국어 말투가 어색한 부분이 있지만 전반적으로 만족하고 있다. ChatGPT에서도 GPT 5.2 Pro를 유용하게 활용하고 있다.

Antigravity에 정착한 이유

정착하게 된 가장 큰 이유는 솔직히 금전적인 부분이다. Google AI Pro 대학생 요금제를 1년 동안 사용 중이었는데, 마침 Antigravity가 출시되어 추가 비용 부담 없이 쓸 수 있었다.

하지만 그 외에도 충분히 매력적인 기능들이 있었다.

Agent Manager를 사용한 병렬 작업: Claude Code도 병렬 작업이 가능했지만, CLI 환경이다 보니 진행 상황을 눈으로 직접 확인하기 쉽지 않았다. Antigravity는 이 부분이 시각적으로 훨씬 편했다.
Implement Plan: 마크다운으로 읽기 좋은 계획서를 작성해준다. 사용자가 계획서에서 바로 특정 부분에 대해 질문하거나 리뷰를 남겨 재제출을 요구할 수 있어서, 만족할 만한 계획서가 나올 때까지 반복할 수 있다.
Walkthrough: 작업이 완료되면 계획서처럼 작업 내용을 보여주는데, 어떤 작업을 진행했고 어느 부분을 수정했는지 한눈에 파악할 수 있어서 좋다.
모델 선택지: Gemini뿐만 아니라 최신 버전의 Opus도 사용할 수 있다. (한도가 적지만)

물론 초기에는 잔버그(설정을 해두어도 기본 세팅으로 돌아간다거나)도 있었고, “캐시 좀 지워줘” 라는 말에 D드라이브를 증발시키는 사고도 있었다.

하지만 잔버그들은 점차 수정되고 있고, 앞의 사건은 권한 설정을 제대로 해두면 예방할 수 있다. Antigravity의 작업 방식 자체가 마음에 들고, 최신 Opus 모델까지 쓸 수 있다는 점이 결정적이었다.

마무리

꽤 많은 AI 코딩 에이전트를 거치면서 느낀 점이 있다.

우선, CLI 기반 에이전트는 macOS에서는 잘 동작하지만, Windows에서는 지원이 원활하지 않아 WSL을 사용해야 하는 경우가 많아 불편했다.

그리고 결국 사용되는 LLM 모델들(GPT, Claude, Gemini 등)은 비슷비슷해서, AI 코딩 에이전트를 선택할 때는 UI/UX가 얼마나 마음에 드느냐, 사이드 기능(Cursor의 Tab, Kiro의 Spec 기반 개발 등)이 얼마나 생산성을 높여주느냐에 따라 갈리는 것 같다.

하지만 어떤 에이전트를 사용하든, 결국 가장 큰 결과물의 차이를 만들어내는 것은 개인의 프롬프트 역량이라고 생각한다.

지금 내가 사용하는 방식(Antigravity + Codex)은 추후 서술해보도록 하겠다.

Claude code agents orchestra 업데이트

Wed, 25 Feb 2026 00:00:00 GMT

내가 작업한 오픈소스 중에서 가장 많은 Star를 받은 프로젝트가 있는데, 바로 claude-code-agents-orchestra이다.

이 프로젝트는 기존 Claude Code Agent의 Subagent 기능을 활용해 여러 에이전트가 팀을 이루고, Claude가 적절한 팀을 찾아 작업을 할당하도록 돕는 도구이다. 최근 새롭게 추가된 Skills 기능을 이 프로젝트에 어떻게 접목할지 리서치하던 중, Vercel 블로그에서 매우 흥미로운 글을 발견했다.

바로 Jude Gao님이 작성한 AGENTS.md outperforms skills in our agent evals라는 포스트다.

AGENTS.md와 Skills 비교 실험

이 글은 AI 코딩 에이전트에게 프레임워크(Next.js) 관련 지식을 제공할 때 어떤 컨텍스트 전달 방식이 가장 효과적인지 실험한 결과를 다룬다.

컨텍스트 제공 방식 (Configuration)	통과율 (Pass Rate)	기준 대비 (vs Baseline)
기본 (Baseline - no docs)	53%	-
스킬 (Skill - default behavior)	53%	+0p
명확한 스킬 사용 지시 (Skill with explicit instructions)	79%	+26p
`AGENTS.md` 인덱스 명시 (`AGENTS.md` docs index)	100%	+47p

실험 결과에서 알 수 있듯, 능동적으로 도구를 호출하도록 유도하는 Skills 방식보다 AGENTS.md를 통해 정적(수동적)으로 컨텍스트 지도를 만들어 제공하는 방식이 압도적으로 효과적이었다.

프로젝트 개선 아이디어

이 대목에서 큰 힌트를 얻었다. 현재 내 프로젝트의 핵심인 Subagent를 호출하는 기능 역시 Skills와 동일한 ‘능동적 도구 호출’ 방식이다.

Vercel의 실험 결과처럼 수동적 컨텍스트 제공이 유리하다면, Subagent의 역할과 호출 방법 역시 CLAUDE.md (또는 AGENTS.md)를 통해 정적인 인덱스로 제공하는 것이 훨씬 뛰어난 성능을 보일 것이라는 가설을 세우게 되었다.

해당 블로그에서 제안한 효율적인 인덱싱 방식은 아래와 같다.

[Next.js Docs Index]|root: ./.next-docs
|IMPORTANT: Prefer retrieval-led reasoning over pre-training-led reasoning
|01-app/01-getting-started:{01-installation.mdx,02-project-structure.mdx,...}
|01-app/02-building-your-application/01-routing:{01-defining-routes.mdx,...}

마무리 및 향후 계획

위 구조를 참고하여 Subagent 관리 방식을 개편하는 PR을 작성해 두었다.

다만, 현재 사용 중인 Codex의 구독 기간이 남아있어 당장 테스트하기는 어렵다. 향후 Claude Code를 다시 사용하게 되는 시점에 직접 테스트해 본 뒤 병합할 예정이다.

클로드 넘 비싸…