2026년 9월 프론트엔드 라이브러리 지도 — 11개 라이브 데모로 직접 보고 고르기

크게 보기

들어가며: 라이브러리 목록보다 역할 분담표가 필요합니다

"요즘 프론트엔드는 뭘 써야 하나요?"라는 질문에 라이브러리 이름 열 개를 늘어놓는 답은 도움이 되지 않습니다. Tailwind CSS와 Motion과 Three.js는 비교할 대상이 아니기 때문입니다. 하나는 스타일을, 하나는 상태 변화의 전달을, 하나는 3D 렌더링을 맡습니다. 좋은 선택은 "무엇이 인기인가"가 아니라 "이 화면의 어떤 문제를 누가 맡는가"에서 나옵니다.

이 글은 두 부분으로 되어 있습니다. 앞부분은 서비스의 뼈대가 되는 여섯 가지(Tailwind CSS, shadcn/ui, Motion, GSAP, Lenis, Three.js)를 역할별로 정리하고, 뒷부분은 2026년에 새롭게 눈에 띈 도구들(Paper Shaders, Torph, Sileo, Silk, Pretext, json-render 등)을 다룹니다. 그리고 말로만 설명하지 않도록, 대부분의 라이브러리를 이 페이지에서 실제로 설치해 돌리는 데모 11개를 붙였습니다. 각 데모 머리말에 그 데모가 실제로 불러 쓰는 패키지와 버전을 적어 두었습니다.

1. 한눈에 보기: 여섯 가지 기반의 역할과 현재 버전

크게 보기

과거 자료를 그대로 따라 하면 틀리기 쉬운 지점이 네 군데 있습니다. Framer Motion의 설치 이름(지금은 motion), shadcn/ui의 기본 기반(Radix → Base UI), GSAP의 가격과 라이선스(무료지만 MIT 아님), Lenis의 '동작 줄이기' 처리(이제 기본으로 존중)입니다. 아래에서 하나씩 다룹니다.

2. Tailwind CSS: 스타일 라이브러리가 아니라 디자인 시스템의 구현 수단

Tailwind는 색·간격·레이아웃·타이포그래피를 유틸리티 클래스로 표현합니다. v4부터는 CSS의 @theme에 디자인 토큰을 정의하고 이를 유틸리티와 연결하는 방식이 중심입니다. 그래서 클래스를 많이 쓰는 것 자체가 목적이 되면 곤란합니다. 먼저 제품 전체의 규칙을 정하고, Tailwind가 그 규칙을 구현하게 만드는 순서를 권합니다.

2026년의 변화. 2월의 4.2는 mauve·olive·mist·taupe 새 팔레트, pbs-*·inset-s-* 같은 논리 방향 유틸리티, font-features-*를 더했고, 5월의 4.3은 높이까지 기준으로 삼는 @container-size, scrollbar-*, zoom-*, tab-* 유틸리티를 더했습니다. 이 중 서비스 설계에 가장 쓸모 있는 것은 화려한 효과가 아니라 컨테이너 쿼리입니다. 같은 카드가 사이드바·대시보드·본문에서 각자 알맞게 바뀌게 만들 수 있습니다. 아래 데모의 슬라이더로 카드가 놓인 칸의 너비를 바꿔 보세요.

9월 9일, Tailwind Labs가 Shopify에 합류했습니다. 공식 발표에 따르면 오픈소스 프로젝트는 MIT 라이선스를 유지하고 기존 팀이 계속 관리합니다. 대신 Tailwind Plus·ui.sh 같은 상용 제품은 사업을 키우지 않는 방향으로 바뀌어, 기존 고객 지원은 이어가되 신규 가입은 받지 않습니다. "Tailwind Plus를 사서 시작하자"는 계획은 이제 가정할 수 없습니다.

3. shadcn/ui · Base UI · React Aria: 애니메이션보다 먼저 정할 것

버튼·입력창·팝오버·모달·콤보박스 같은 기본 인터페이스를 먼저 정해야 그 위에 움직임을 얹을 수 있습니다. shadcn/ui는 컴포넌트 소스를 프로젝트에 가져와 소유·수정하는 방식입니다. 제품에 맞게 고치기 좋지만, 가져온 소스의 변경과 유지보수도 팀의 몫이 됩니다.

7월 3일, 신규 프로젝트의 기본 기반이 Base UI로 바뀌었습니다. npx shadcn init의 기본 선택과 문서의 기본 탭이 Base UI가 됐습니다. 공식 변경 기록은 shadcn/create에서 새로 만든 프로젝트들이 Base UI를 Radix보다 2 대 1로 많이 골랐다는 점을 이유로 듭니다. Radix는 계속 지원되고, 새 컴포넌트도 두 기반 모두로 나오며, 기존 프로젝트를 옮길 필요는 없다고 명시했습니다. 같은 달 React Aria 기반도 추가됐습니다.

한 제품 안에서 세 기반을 무계획하게 섞지 말고, 공통 기반 하나를 정한 뒤 특정 요구가 있을 때만 예외를 두기를 권합니다. 그리고 어떤 기반이든 조합한 화면의 접근성까지 자동으로 보장되지는 않습니다. 모달 포커스, 입력 오류 안내, 키보드 순서는 직접 검증해야 합니다.

4. Motion: React 애플리케이션의 기본 모션 층

현재 공식 문서의 이름은 Motion for React(구 Framer Motion)입니다. 새로 설치한다면 이렇게 씁니다.

npm install motion

import { motion, AnimatePresence } from "motion/react";

옛 예제의 framer-motion과 지금 문서의 motion/react를 섞어 쓰지 말고, 프로젝트에서 쓸 패키지와 문서 버전을 먼저 통일하세요. (npm의 framer-motion 패키지도 같은 버전으로 계속 배포되지만, motion이 그것을 감싸는 현재 경로입니다.)

Motion이 가장 잘하는 일은 React 상태의 변화를 화면 변화로 자연스럽게 잇는 것입니다. 핵심은 "움직이게 만들기"가 아니라 사용자가 무엇이 바뀌었는지 이해하게 만들기입니다. 아래 데모는 서비스 화면에서 가장 자주 나오는 네 가지 상황을 실제 Motion으로 구현한 것입니다. 모션 시간 토큰을 바꾸고 '동작 줄이기'를 켜서 차이를 보세요.

유지보수 신호. 9월 28일 13.4.5는 부모가 레이아웃 애니메이션을 중단할 때 자식이 튀는 문제, 다른 퇴장 애니메이션이 끝나는 순간 추가된 자식이 사라지는 문제를 고쳤고, 다음 날 13.4.6은 React transition 중 mode="wait"의 새 자식이 사라지는 문제를 고쳤습니다. 상태 변화가 겹치는 실제 애플리케이션에서 중요한 수정들입니다. 한편 생태계는 엔진을 넘어 Motion UI, Motion Studio 같은 도구로 넓어지고 있는데, 무료 MIT인 엔진과 유료인 Motion+ 도구·컴포넌트는 구분해야 합니다.

번들 크기. LazyMotion과 경량 m 컴포넌트로 필요한 기능 묶음만 불러올 수 있습니다. 다만 일반 motion 컴포넌트를 함께 쓰면 경량화 효과가 줄어듭니다. 그리고 단순한 hover 색 변화까지 Motion으로 만들 필요는 없습니다. 공식 문서도 그런 경우엔 CSS transition이 가볍다고 설명합니다(8장).

5. GSAP: 복합 타임라인과 정교한 연출

GSAP은 DOM·SVG·Canvas 등 무엇이든 시간축 위에서 제어하는 범용 애니메이션 도구입니다. Motion과의 구분은 이렇게 권합니다.

Motion은 "이 상태가 되면 어떻게 바뀌는가", GSAP은 "이 장면에서 무엇이 어떤 순서로 움직이는가"를 기준으로 고릅니다.

절대적인 경계는 아닙니다. Motion도 스크롤 애니메이션을 지원하고, GSAP으로도 작은 인터페이스 효과를 만들 수 있습니다. 하지만 여러 요소를 한 시간축에 묶어 이름 붙은 장면으로 나누고, 되감고, 스크롤 진행률에 붙이는 일은 GSAP이 가장 편합니다. ScrollTrigger의 scrub(스크롤 진행률 연동), pin(구간 고정), snap(지점 맞춤)이 그 도구입니다. 아래 데모는 같은 타임라인을 버튼으로도, 스크롤로도 조종합니다.

라이선스는 꼼꼼히. 2025년 4월 3.13부터 SplitText·MorphSVG 같은 옛 유료 플러그인까지 모두 무료가 됐습니다. 비용 때문에 뺐던 기능이 있다면 다시 검토할 만합니다. 하지만 무료와 MIT는 다릅니다. GSAP은 자체 표준 라이선스('no charge' license)를 쓰고, 일반 웹사이트·애플리케이션 사용과 달리 Webflow의 시각적 애니메이션 빌더와 경쟁하는 노코드 도구에 탑재하는 경우를 따로 규정합니다. 시각적 빌더를 만든다면 그 조항을 별도로 확인하세요.

React에서의 원칙. 공식 통합은 @gsap/react의 useGSAP()입니다. 내부적으로 gsap.context()로 범위를 정하고 언마운트 때 정리하며, 나중에 실행되는 이벤트 콜백에는 contextSafe가 필요할 수 있습니다. 그리고 가장 중요한 원칙 하나.

크게 보기

한 요소의 같은 속성은 한 도구만 제어하게 하세요. GSAP이 어떤 요소의 transform을 바꾸는 동안 Motion도 같은 요소를 움직이면 두 엔진이 매 프레임 값을 덮어쓰며 떨림이 생깁니다. 함께 써야 한다면 바깥 래퍼는 GSAP, 안쪽 버튼은 Motion처럼 소유 범위를 나눕니다.

6. Lenis: 애니메이션 엔진이 아니라 스크롤 감각을 조정하는 도구

Lenis는 스크롤 움직임을 보간해 부드럽게 만들고, 스크롤 상태를 다른 연출과 동기화하게 돕습니다. 패키지 이름은 lenis, React 통합은 lenis/react입니다. @studio-freight/lenis로 시작하는 옛 예제와 구분하세요.

Lenis와 ScrollTrigger를 연결하는 공식 예제가 있지만, ScrollTrigger를 쓰려고 Lenis가 필요한 것은 아닙니다. 위 GSAP 데모도 기본 스크롤로 돌고 있습니다. 차이는 휠·트랙패드의 '감각'에서 납니다. 아래 두 칸을 마우스 휠이나 트랙패드로 번갈아 스크롤해 보세요.

8월 5일 1.3.26에서 달라진 점. 이제 운영체제의 prefers-reduced-motion: reduce를 존중합니다. 동작 줄이기를 켠 사용자에게는 보간을 없애고 프로그램으로 이동하는 스크롤도 즉시 이동시키면서, DOM·WebGL 동기화에 필요한 스크롤 이벤트는 그대로 유지합니다. "Lenis는 동작 줄이기를 처리하지 않는다"는 과거 설명은 현재 버전에 맞지 않습니다. 다만 스크롤 관성만 사라지고 배경 패럴랙스와 3D 카메라 이동이 그대로 남으면 충분하지 않으니, 페이지 전체의 모션 정책은 따로 점검하세요.

7. Three.js: 효과보다 '3D가 필요한 이유'부터

Three.js는 3D 렌더링 라이브러리이고, React Three Fiber(R3F)는 Three.js 장면을 React 컴포넌트로 구성하는 렌더러, Drei는 카메라 컨트롤·모델 로딩 같은 반복 구현을 돕는 도우미 모음입니다. R3F는 v8이 React 18, v9가 React 19에 대응합니다(9월 24일 9.8.1의 peer 의존성은 React 19.x). Three.js만 최신으로 올리지 말고 React·R3F·Drei를 묶어서 관리하세요.

성능 설계의 핵심은 R3F 공식 가이드가 말하는 필요할 때만 렌더링(on-demand rendering)입니다. 장면이 멈춰 있는데도 매 프레임 GPU를 돌리면 배터리와 발열로 돌아옵니다. 아래 데모에서 '항상 렌더'와 '필요할 때만'을 바꿔 가며 초당 렌더 횟수를 보세요. 데모 자체도 권장 로딩 구조(정적 미리보기 → 사용자가 선택 → 3D 로딩)를 따릅니다.

R3F에서는 <Canvas frameloop="demand">와 invalidate()로 같은 구조를 만듭니다. 또 프레임마다 React setState를 부르지 말고 useFrame 안에서 객체 참조를 직접 바꾸고 시간 차이(delta)를 반영하라고 권합니다. WebGPU는 Three.js의 WebGPURenderer가 WebGPU를 먼저 시도하고 안 되면 WebGL 2로 대체하는 구조를 제공합니다. 다만 이름만으로 모든 기기에서 더 빠르다고 가정하지 말고, 실제로 쓸 재질·셰이더·후처리를 대상 기기에서 확인하세요.

8. 라이브러리 전에: 브라우저 기본 기능으로 되는가

크게 보기

View Transition API는 문서 안팎의 상태 전환을 시각적으로 이어 주고, CSS 스크롤 구동 애니메이션(animation-timeline: view()/scroll())은 스크롤이나 요소의 화면 진입 정도를 애니메이션 시간축으로 씁니다. 후자는 메인 스레드 밖에서 돌아 스크롤 중에도 가볍습니다. 둘 다 점진적 향상으로 쓰세요. 지원하지 않는 브라우저에서도 탐색·콘텐츠·핵심 기능은 그대로 동작해야 합니다. 아래 데모는 이 브라우저가 무엇을 지원하는지 먼저 알려 줍니다.

Next.js에서 View Transition을 쓴다면 API 지원과 별개로 라우팅·포커스 이동·스크롤 복원까지 함께 검증해야 합니다. API 하나를 추가했다고 페이지 전환 설계가 끝난 것은 아닙니다.

9. 새롭고 흥미로운 도구들: "어디서 사용자가 새로움을 느끼게 할 것인가"

앞의 여섯 가지가 "무엇으로 구축할 것인가"였다면, 지금부터는 "어디에서 사용자가 새로운 경험을 느끼게 할 것인가"를 정하는 도구들입니다. 모두 2026년에 처음 나온 것은 아니어서 첫 배포일을 함께 적었습니다.

9-1. Paper Shaders: 움직임이 아니라 재질을 만든다

크게 보기

Paper Shaders는 요소를 이동·확대하는 대신 화면의 표면 자체를 바꿉니다. 리퀴드 메탈, 플루티드 글라스, 물, 종이 질감, 디더링, 하프톤, 메시 그라디언트 같은 효과를 React 컴포넌트 하나로 씁니다. "Three.js로 장면을 만들기엔 과하고, CSS 그라디언트로는 아쉬운" 자리에 먼저 시험할 후보입니다. 아래 데모는 라이브러리에 들어 있는 프리셋을 그대로 불러 옵니다. 리퀴드 메탈은 코어닷투데이 심볼 SVG에, 이미지 효과는 이 글의 삽화에 적용했습니다.

변경 기록에는 화면 밖으로 나가면 애니메이션을 멈추는 처리, 종이 질감 개선, Apache-2.0으로의 라이선스 변경이 있습니다. 다만 README가 0.0.x에서도 호환성을 깨는 변경이 생길 수 있으니 버전을 고정하라고 명시합니다. package.json에 ^ 없이 정확한 버전을 적으세요.

9-2. Torph · Sileo · WebHaptics: 작은 면적의 완성도

Torph는 문자열이 바뀔 때 텍스트 자체를 모핑합니다. 숫자가 들어 있으면 자릿값별로 굴러가고(1,204 → 1,318이면 천의 자리는 그대로), 통화 기호·구분자는 제자리를 따라갑니다. 예약하기 → 좌석 확인 중 → 예약 확정, 12개 결과 → 128개 결과, ₩120,000 → ₩135,000 같은 자리에 맞습니다. Sileo는 SVG 모핑과 스프링 물리로 알림의 '형태'가 바뀌는 토스트입니다. sileo.promise()로 로딩 → 성공/실패를 한 알림 안에서 잇습니다. WebHaptics는 success·nudge·error·buzz 프리셋과 지원 여부 확인 API를 줍니다.

세 도구 모두 보조 수단으로 설계하세요. 토스트는 잠깐 떴다 사라지므로 실패처럼 행동이 필요한 정보는 화면에도 남깁니다. 진동은 기기·운영체제·브라우저마다 다르고 Vibration API가 없는 환경이 많으므로, 정보나 성공 여부를 촉각에만 의존하지 않습니다. 진동은 버튼을 누를 때마다가 아니라 선택이 확정되는 순간, 드래그한 카드가 목표에 안착하는 순간, 작업이 성공하거나 실패한 순간처럼 조작의 경계에만 붙이기를 권합니다.

9-3. Silk: 모바일 웹을 앱처럼 느끼게 하는 시트

Silk는 React용 스와이프 시트·패널에 집중합니다. 중간 높이에서 멈추는 시트(detent), 여러 장이 쌓이는 시트, 키보드가 올라올 때 높이를 조정하는 시트, 깊이감 있는 전환 등을 제공하고, 터치·휠 입력·스냅 지점·포커스·배경 스크롤 잠금을 다룹니다. 스타일은 강제하지 않습니다. 모바일 예약 UI라면 이런 흐름을 시험할 만합니다.

모바일 비중이 높은 서비스라면 장식 효과보다 이쪽을 먼저 시험하기를 권합니다. 공식 예제의 Sheet with Keyboard·Sheet with Detent·Sheet with Stacking을 실제 휴대전화에서 비교해 보세요. 이 글에 Silk 데모가 없는 이유도 적어 둡니다. npm 패키지의 라이선스가 MIT가 아니라 "silkhq.com/terms의 약관을 따른다"로 되어 있고 사이트에 별도 이용 신청(Get Access) 경로가 있어, 상업 사이트인 이 블로그에 넣기 전에 약관 검토가 필요했습니다. 도입 전에 약관을 먼저 확인하세요.

9-4. Pretext: 2026년 신생 도구 중 기술적으로 가장 흥미로운 후보

크게 보기

Pretext는 UI 컴포넌트가 아니라 텍스트 측정과 줄바꿈·높이 계산 라이브러리입니다. 3월 말 첫 공개 후 반년 만에 GitHub 별 5만을 넘겼습니다. 핵심은 일을 두 단계로 나누는 것입니다.

이 높이 값이 열어 주는 것이 많습니다. 추정치 없는 목록 가상화, 요약 길이가 제각각인 카드의 배치(masonry), 여러 줄 텍스트를 가장 좁은 폭으로 감싸는 '말풍선 딱 맞추기', 새 텍스트가 들어올 때 스크롤 위치 고정. 아래 데모는 한국어 문장으로 앞의 두 가지를 실제로 계산합니다. 한국어에 중요한 wordBreak: 'keep-all'(어절 단위 줄바꿈) 옵션도 켜 보세요.

한계도 분명합니다. CSS·글꼴 렌더링 엔진 전체를 대체하지 않으며, 글꼴 이름·크기·줄 높이·줄바꿈 규칙이 실제 CSS와 정확히 맞아야 합니다. README는 macOS의 system-ui 정확도 문제와 가변 글꼴 설정의 제한을 적고, 계산 결과를 실제 표시 높이와 대조해 검증하라고 권합니다. 데모가 예측값과 DOM 실측값을 나란히 보여 주는 이유입니다.

9-5. json-render: AI가 답변 대신 '쓸 수 있는 화면'을 구성한다

크게 보기

이것은 애니메이션이 아니라 인터페이스를 만드는 방식의 변화입니다. 개발자가 쓸 수 있는 컴포넌트·속성·액션을 카탈로그로 정의하면, AI는 그 범위 안에서 JSON 명세를 만들고, 렌더러가 등록된 컴포넌트로 그립니다. 모델이 만든 임의의 React 코드를 실행하는 방식과 다릅니다. 명세는 JSON Patch(RFC 6902) 줄 단위로 스트리밍되므로 화면이 생성되는 도중에도 조금씩 그려집니다.

"지난달과 이번 달 세미나 신청을 비교해 줘"라는 질문에 텍스트 답변 대신 기간 요약 지표 + 비교 차트 + 상세 표를 돌려주는 식입니다. 아래 데모는 미리 녹화한 모델 스트림을 실제 json-render 컴파일러와 렌더러에 흘려 넣습니다. 세 번째 '위험한 요청' 시나리오에서는 카탈로그에 없는 컴포넌트와 액션이 어떻게 걸러지는지 보세요.

9-6. Streamdown + AI Elements: AI 작업 과정을 보이게

json-render가 화면의 구성을 다룬다면, 이 조합은 답변과 실행 과정의 표현을 다룹니다. Streamdown은 스트리밍 중인 불완전한 마크다운(닫히지 않은 굵은 글씨·코드 블록 등)을 깨지지 않게 그리고, 코드·수식·Mermaid·CJK 플러그인을 제공합니다(9월 30일 2.7.0). AI Elements는 대화창만이 아니라 Confirmation, Tool, Plan, Task, Inline Citation, Artifact처럼 AI 서비스의 상태와 결과를 표현하는 구성 요소를, shadcn/ui처럼 소스를 가져오는 레지스트리 방식으로 제공합니다.

"응답을 기다리는 말풍선"에서 벗어나 AI가 지금 무엇을 하고 있고 사용자가 어디에 개입해야 하는지를 보여 줄 수 있습니다. AI 서비스라면 시각 효과보다 먼저 검토할 영역입니다.

9-7. Agentation: 사용자 화면이 아니라 개발 과정을 바꾸는 도구

Agentation은 화면에서 요소를 직접 찍어 위치·선택자 같은 맥락과 수정 의견을 AI 코딩 도구에 넘기는 개발용 도구입니다. "오른쪽 위 카드 아래 버튼 간격을 줄여 줘"라고 말로 설명하는 대신 요소를 가리키는 것이죠. 1월에 공개됐고 9월 22일 3.1.2까지 왔으며, 레이아웃 배치·섹션 재정렬 정보 전달과 MCP 연동도 들어 있습니다. AI로 프론트엔드를 반복 수정한다면 효과 라이브러리 하나보다 작업 흐름을 크게 바꿀 수 있습니다. 개발 환경에만 넣고, MIT가 아닌 PolyForm Shield 라이선스(경쟁 제품에 쓰는 것을 제한)를 확인하세요.

10. 컴포넌트 컬렉션: 기본 체계를 대체하지 말고 보강하는 재료

React Bits 라이선스는 특히 구분하세요. 라이선스 파일은 "애플리케이션·웹사이트·제품의 일부로서" 상업적 이용을 포함해 사용을 허용하지만, 컴포넌트 자체를 단독으로든 묶음으로든 다른 프레임워크로 옮긴 형태로든 판매·재라이선스·재배포하는 것은 금지합니다. 회사 홈페이지에 효과를 넣는 것과 그 효과를 템플릿 상품으로 파는 것은 다른 문제입니다.

디자인 원칙도 하나. 한 화면에서 강한 연출을 맡는 구간을 제한하세요. 첫 화면은 React Bits의 특징적인 배경을 쓰더라도, 기능 설명·요금·문의·신청 영역은 공통 디자인 시스템으로 돌아오게 합니다. 서로 다른 컬렉션의 효과를 계속 이어 붙이기보다 색·속도·모서리·그림자·인터랙션 규칙을 통일하는 편이 완성도가 높습니다.

11. 사용성을 받치는 라이브러리: 상태를 어디에 둘 것인가

시각적 모션만큼 중요한 것이 검색·입력·데이터 로딩·표 탐색입니다. 모두 설치하라는 뜻이 아닙니다. 단순 소개 사이트에는 TanStack Table도 Zustand도 필요 없습니다.

가장 권하고 싶은 것은 상태의 자리를 먼저 나누는 것입니다. 같은 정보를 여러 곳에 중복 저장하지 않기 위한 설계입니다.

그리고 목적이 좁다면 더 단순한 도구가 나을 수 있습니다. AutoAnimate(목록 추가·삭제·재정렬을 한 줄로, 동작 줄이기 반영), Anime.js(프레임워크 독립 DOM·SVG 타임라인, GSAP의 대안으로 비교), Rive·dotLottie(디자이너가 만든 벡터 애니메이션 재생), PixiJS(3D가 필요 없는 대량 2D 그래픽), Unicorn Studio(셰이더·이미지 효과를 시각 편집기로 만들어 임베드)가 그렇습니다. 작은 목록 효과 하나를 위해 Motion·GSAP·Anime.js·AutoAnimate를 모두 넣는 구성은 피하세요.

12. Next.js에 얹는 구조와 모션 토큰

모션이 필요하다고 페이지 전체를 Client Component로 바꾸지 말고, 인터랙션이 필요한 경계만 분리하세요. 이 블로그도 그렇게 되어 있습니다. 본문은 서버에서 그리고, 위의 데모 11개는 각각 next/dynamic으로 필요할 때만 불러옵니다. 그래서 Three.js나 Paper Shaders는 이 글을 여는 순간이 아니라 해당 데모가 필요할 때 내려받습니다.

주의할 점 두 가지. next/dynamic의 ssr: false는 Client Component 안에서만 쓸 수 있고, 'use client' 자체가 서버 사전 렌더링을 끄는 뜻은 아닙니다. 또 코드 분할과 "쓸 때까지 실행하지 않기"는 따로 설계해야 합니다. 3D를 별도 파일로 나눴어도 첫 화면에 바로 표시한다면 초기 로딩 비용은 그대로입니다(7장 데모가 '3D 불러오기' 버튼을 두는 이유).

공통 모션 규칙도 먼저 정하세요. 아래 수치는 표준이나 조사 통계가 아니라 초기 디자인 토큰으로 제안하는 출발값이고, 4장 Motion 데모의 토큰 버튼이 이 값을 씁니다.

사용자가 기다려야 하는 모션과, 작업하면서 자연스럽게 스쳐 가는 모션을 구분하세요. 전자는 짧을수록 좋습니다.

13. 성능·접근성 검수 기준

성능은 프레임률 하나로 판단하지 않습니다. Core Web Vitals의 '좋음' 기준은 LCP 2.5초 이하, INP 200ms 이하, CLS 0.1 이하이고, 사용자 경험의 75번째 백분위수로 평가합니다. 모션이 부드러운 것만큼 첫 콘텐츠가 늦지 않은지, 클릭에 바로 반응하는지, 화면이 갑자기 밀리지 않는지가 중요합니다.

크게 보기

접근성은 모션 설정 하나로 끝나지 않습니다. WCAG의 상호작용 애니메이션 기준(2.3.3)은 불필요한 움직임을 끌 수 있게 하라는 내용인데, 이 기준은 AAA 수준입니다. 동작 줄이기를 지원한다고 접근성 전체를 충족했다고 말할 수는 없습니다. 그리고 이 글에서 계속 본 것처럼, 그 설정 하나도 도구마다 따로 챙겨야 합니다.

14. 직접 골라 보기

지금까지의 권고를 한 도구로 모았습니다. 만들 화면의 성격을 고르면 공통 기반 위에 무엇을 얹고 무엇을 넣지 않을지 보여 줍니다.

작은 데모 하나로 새 도구들을 한꺼번에 시험해 보고 싶다면 이런 조합을 권합니다. Paper Shaders로 첫 화면의 재질을 만들고, Torph로 상태 문구를 전환하고, Sileo로 작업 결과를 알리고, 모바일에서는 Silk로 상세 정보를 여는 구성입니다. 텍스트가 많은 화면은 Pretext, AI가 화면을 구성해야 하는 영역은 json-render를 별도 실험으로 붙이세요.

마치며

2026년의 프론트엔드 라이브러리는 어느 때보다 많고, 어느 때보다 잘 만들어져 있습니다. 그래서 오히려 "무엇을 넣지 않을지"가 더 중요해졌습니다. 이 글의 데모를 만들면서도 같은 원칙을 따랐습니다. 본문은 서버에서 그리고, 각 라이브러리는 그 데모가 필요할 때만 불러오고, 한 요소는 한 도구만 움직이게 했습니다. 스타일은 Tailwind, 구조는 shadcn/ui, 상태 변화는 Motion으로 기반을 깔고, 나머지는 그 화면이 정말 필요로 할 때 얹으세요.

참고한 자료

• Tailwind CSS: Tailwind Labs is joining Shopify · CHANGELOG · 호환성 문서
• shadcn/ui: July 2026 — Base UI as the Default · July 2026 — React Aria
• Motion: 문서 · CHANGELOG
• GSAP: 3.15 Release · Standard License · React 통합(useGSAP)
• Lenis: 저장소·릴리스 · Three.js: 저장소 · R3F 성능 가이드
• 새 도구: Paper Shaders · Torph · Sileo · Silk · Pretext · WebHaptics · json-render · Streamdown · AI Elements · Agentation
• 컬렉션·라이선스: Magic UI · React Bits 라이선스
• 웹 표준: Core Web Vitals · WCAG 2.3.3 Animation from Interactions · View Transition API (MDN) · CSS 스크롤 구동 애니메이션 (MDN)