시세나 센서값처럼 계속 갱신되는 숫자를 보여줄 때. 일반 차트 라이브러리는 갱신마다 다시 그려 뚝뚝 끊기는데, 이건 값 사이를 보간해 흐르게 만드는 게 목적이다. 오더북 라벨, 캔들, 기간 선택 버튼이 기본 탑재라 금융 시세 화면에 바로 맞는다. 주식·코인 대시보드를 만든다면 처음부터 다시 짜는 것보다 빠르다. 용도가 좁다. 정적인 데이터를 보여줄 거면 Recharts 같은 범용 차트가 낫다. 이건 '실시간'이 전제다. Canvas 기반이라 DOM 노드가 늘지 않아 갱신이 잦아도 버틴다. 다만 접근성(스크린리더)은 별도로 챙겨야 한다. 라이선스가 명시돼 있지 않다. 상업 사용 전 GitHub이나 npm에서 확인할 것.
숫자나 라벨이 실시간으로 바뀌는 자리에 쓴다. 값이 툭 교체되면 눈에 거슬리는데 그 사이를 이어준다. 카운터, 상태 표시, 탭 전환 시 제목 같은 곳. UI Components의 libraries.dev와 같은 방식이다 — 이펙트 하나만 npm 패키지로 가져오는 형태. 세트를 깔 필요가 없다. 의존성이 없고 프레임워크 4종을 지원해서 프로젝트를 가리지 않는다. 이 점은 이 컬렉션에서 드문 편이다. 0.1.3 버전이다. 아직 초기이므로 API가 바뀔 수 있고, 프로덕션에 넣을 거면 버전을 고정할 것.
이미 shadcn/ui 테마를 쓰고 있고 색·반경이 어긋나지 않는 이펙트를 원할 때. 테마 호환을 전면에 내세운 점이 이 계열에서 드문 강점이다. Pixel Perfect UI와 스택이 거의 같다(Tailwind + Motion + GSAP, 복붙). 갈리는 건 테마 연동 — 이쪽은 shadcn 토큰을 따르고, 저쪽은 독립적이다. shadcn 위에 올린 프로젝트면 이쪽이 덜 손간다. Tailwind v4 전제다. v3 프로젝트라면 그대로 붙지 않는다. 베타이고 컴포넌트 수도 공개돼 있지 않다. 목록을 먼저 훑어 쓸 만한 게 있는지 확인한 뒤 판단할 것. 라이선스 종류도 GitHub에서 확인 필요.
이펙트 하나가 필요한데 문서를 읽고 옵션을 이해한 뒤 쓰고 싶을 때. 문서 우선을 내세운 만큼 설명이 상대적으로 충실한 편이다. 연출 계열에서 GSAP까지 쓰는 몇 안 되는 곳이다. 대부분은 Motion(Framer Motion)만 쓰는데 여기는 GSAP과 WebGL도 섞는다. 그만큼 무거워질 수 있으니 필요한 것만 골라 넣을 것. Spell UI와 성격이 가깝다 — 둘 다 CLI 없이 복붙이고 단품 연출 위주다. 다만 이쪽이 문서가 낫고, Spell UI는 연출이 더 뾰족하다. 개인이 만든 소규모 프로젝트다. 유지보수가 끊길 가능성을 감안하고, 복붙 방식이라 가져온 뒤에는 내 코드로 관리할 것.
문서 사이트나 개발자 대상 랜딩을 만들 때. 코드 블록, GitHub 스타 수·기여자 표시, 요금제 표처럼 이런 사이트에 반복해서 나오는 조각이 모여 있다. UI Components의 연출 계열과 목적이 다르다. 저쪽은 시선을 끄는 연출이고, 이건 개발자 사이트에 필요한 기능성 블록이다. 화려함이 아니라 정보를 보여주는 쪽. GitHub 데이터를 서버에서 ISR로 가져오는 구조라 클라이언트 요청이 늘지 않는다. 다만 Next.js App Router 전제이므로 다른 환경이면 손봐야 한다. 코드 하이라이팅은 Shiki다. 이미 다른 하이라이터를 쓰고 있다면 중복이 생기지 않는지 확인할 것. 전면 무료를 명시한 몇 안 되는 곳 중 하나다. 다만 라이선스 종류 자체는 사이트에 적혀 있지 않으니 GitHub에서 확인할 것.
청구서·리포트를 PDF로 만들 때. 표·헤더·푸터 같은 조각이 준비돼 있어 @react-pdf/renderer를 맨손으로 쓰는 것보다 빠르다. UI Components의 pdfcn과 정면으로 겹친다. 고르는 기준은 기반 스택 — 이건 @react-pdf/renderer(널리 쓰이고 자료가 많음), pdfcn은 Takumi/Forme(더 새로움). 기존 프로젝트가 @react-pdf/renderer를 쓰고 있다면 이쪽이 답이다. 라이선스도 갈린다 — 이건 MIT로 명확하고 pdfcn은 미표기다. 상업 프로젝트라면 이 차이가 결정적일 수 있다. 복붙 방식이라 업스트림 수정은 따라오지 않는다.
프로필 사진을 올리지 않은 사용자의 기본 아바타가 필요할 때. 회색 사람 아이콘 대신 계정마다 다른 얼굴이 나와 목록에서 구분이 쉬워진다. 결정론적이라는 게 핵심이다 — 같은 이메일이면 어느 기기에서 보든 같은 얼굴이다. 서버에 저장하거나 캐시할 필요가 없다. 얼굴 형태로 고정된다. 추상 패턴을 원하면 DiceBear나 boring-avatars 쪽이 선택지가 넓다. Next.js 라우트 핸들러가 딸려 있어 이미지 URL로도 뽑을 수 있다. 메일 본문처럼 React를 못 쓰는 곳에 넣을 때 유용하다. MIT라 상업 사용에 걸림돌이 없다.
한 화면에서 시선을 잡을 요소가 딱 하나 필요할 때. 세트로 깔고 가는 라이브러리가 아니라 개별 연출을 골라 쓰는 곳이다. 같은 연출 계열 중에서도 성격이 가장 뾰족하다 — Magic UI·Componentry가 범용 세트라면 여기는 Perspective Book이나 Exploding Input처럼 특정 연출 하나로 승부한다. 그만큼 프로젝트에 맞는 게 없을 확률도 높다. CLI가 없어 코드를 직접 복사한다. 업데이트를 따라가는 경로가 없으니 가져온 시점에서 내 코드로 확정된다. 라이선스 미표기 — 상업 사용 전 GitHub에서 확인할 것.
챗 인터페이스나 에이전트 화면을 만들 때. 메시지 스트리밍, 추론 과정 표시, 출처 인용, 코드 블록처럼 매번 다시 짜게 되는 것들이 준비돼 있다. Vercel AI SDK를 쓰고 있다면 1순위다. 같은 팀이 만들어 연동이 전제돼 있다. UI Components의 mcpcn과 겹치는 영역이 있다 — mcpcn은 Base UI 기반의 개인 프로젝트, 이건 shadcn/ui 기반의 Vercel 공식. 기존 스택이 shadcn/ui라면 이쪽이 자연스럽다. 소스를 프로젝트에 복사해 넣는 방식이라 업스트림 수정은 따라오지 않는다. 고쳐 쓸 자유와 맞바꾸는 부분.
연출 계열 중 유료 티어가 아예 없는 쪽. Magic UI·Aceternity·beUI는 좋은 것이 Pro에 몰려 있는데 여기는 전부 열려 있다. 예산이 걸리거나 오픈소스 프로젝트라면 여기부터 볼 것. 대신 규모가 작다(50종). 원하는 게 없을 확률이 다른 곳보다 높으니 먼저 목록을 훑고 판단할 것. MCP를 지원해서 Claude Code에서 직접 골라 설치할 수 있다. 같은 방식은 AI Canvas·Aceternity·Originkit에도 있다.
제품을 3D로 돌려보게 하거나 AR로 실제 공간에 놓아보게 할 때. 가구·기기처럼 크기 감이 중요한 상품에서 값어치가 크다. 공간을 보여주는 View360과 반대로 이건 물체 하나에 초점이 맞춰져 있다. glTF 모델이 있어야 시작된다 — 모델 제작 비용이 실제 도입 장벽이다. UI Components의 ThreeUI와 다르다. 저쪽은 장식용 비주얼, 이건 실제 모델 뷰어.
매장이나 실내 공간을 360도로 보여줘야 할 때. 사진 여러 장 대신 공간 자체를 전달하는 용도. 파노라마 이미지/영상 전용이다. 개별 제품을 돌려보게 하려면 View3D 쪽이 맞다. MIT라 라이선스 고민이 없다 — 이 컬렉션에서 상업 사용이 명시적으로 확인된 몇 안 되는 항목.
상품 목록이나 커뮤니티 피드처럼 아이템이 계속 늘어나는 화면을 만들 때. 상품 그리드나 피드에 바로 해당된다. 직접 구현하면 스크롤 위치 복원과 높이 계산에서 반드시 막히는데 그 부분이 해결돼 있다. 카드 높이가 제각각이면 Masonry, 사진 위주로 줄을 꽉 채우려면 Justified를 볼 것. 이 컬렉션의 shadcn 계열과 달리 복붙이 아니라 npm 의존성이다.
MCP 서버나 에이전트 앱의 화면을 만들 때. 채팅 버블·상태 표시·통계 카드처럼 매번 다시 짜게 되는 것들이 모여 있다. Tools의 agentcn이 로직이라면 이건 그 화면 쪽이다. 둘을 같이 보면 된다. Radix가 아니라 Base UI 기반이다. 기존 shadcn/ui 컴포넌트와 섞을 때 동작 차이를 확인할 것.
글쓰기 화면이 필요할 때. 커뮤니티나 블로그 글 작성기에 바로 맞는다. 툴바형과 Notion식 블록형 중 고를 수 있다. 커뮤니티 글이면 블록형, 상품 설명처럼 짧은 서식이면 툴바형이 무난하다. Tiptap 기반이라 확장·플러그인은 Tiptap 생태계를 그대로 따른다. 이 컬렉션의 shadcn-labs 계열과 달리 제작자가 다르다.
청구서·명세서·리포트를 PDF로 뽑아야 할 때. 주문 영수증이나 정산서에 바로 대응된다. 템플릿이 인보이스 쪽에 치우쳐 있으므로 일반 문서 레이아웃이 필요하면 맞지 않는다. Takumi/Forme 스택을 얹어야 하니 기존 PDF 생성 방식이 있다면 교체 비용을 먼저 볼 것.
거래 메일이나 마케팅 메일 템플릿이 필요할 때. 주문 확인·환영 메일·신상품 안내가 그대로 있다. React Email / MJML React / JSX Email 중 무엇을 쓰는지에 따라 설치 경로가 갈리므로 먼저 정할 것. 메일은 클라이언트마다 렌더가 제각각이다. 가져다 쓴 뒤 실제 발송 테스트는 반드시 거칠 것.
링크를 공유했을 때 뜨는 미리보기 카드를 손보고 싶을 때. 공유 링크가 카톡·트위터에서 밋밋하게 보인다면 여기서 템플릿을 가져다 쓰는 게 제일 빠르다. Next.js의 ImageResponse(내부적으로 Satori)를 이미 쓰고 있다면 바로 얹힌다. 직접 디자인할 필요가 없어지는 게 핵심. 페이지마다 동적으로 생성하는 구조라 빌드가 아니라 요청 시점에 그려진다 — 응답 시간과 캐싱을 같이 확인할 것.
앱 안에 영상 UI를 넣어야 할 때. 플레이어 껍데기부터 오버레이까지 이미 만들어져 있어 직접 짜는 수고를 던다. Tools의 HyperFrames와 헷갈리지 말 것 — HyperFrames는 영상 파일(MP4)을 만들어내는 쪽, 이건 앱 화면에서 영상을 보여주는 쪽이다. Editframe에 묶이므로 그쪽 요금·제약을 먼저 확인할 것. 라이선스도 미표기라 상업 사용 전 GitHub에서 확인.
CLI 도구를 만들 때. 로컬 데스크탑 앱이나 MCP 서버에 진행 상황·표·차트를 터미널로 보여줄 일이 생기면 여기부터. 웹에는 쓸 수 없다. Ink 위에서 도는 별개 세계다.
이미 만들어둔 컴포넌트에 움직임만 얹고 싶을 때. 컴포넌트를 주지 않으므로 다른 연출 계열와 경쟁이 아니라 같이 쓰는 물건이다. CSS 버전이 있어서 React가 아닌 곳에도 적용된다. 모달 전환과 스켈레톤 로더가 실무에서 바로 쓰인다.
Framer로 디자인할 때. 이 컬렉션에서 유일하게 디자인 툴 캔버스에 직접 붙는다. 코드만 필요하면 다른 연출 계열가 낫다. 라이선스 미표기라 상업 프로젝트에 쓰기 전 반드시 확인.
버튼·모달·토스트·탭 같은 기본 컴포넌트에 애니메이션이 이미 들어간 버전이 필요할 때. React 19 / Tailwind 4 기준이라 구버전 프로젝트에는 맞춰야 한다. 커맨드 팔레트와 다이나믹 아일랜드가 특히 쓸만하다.
섹션 배경이나 히어로에 3D·WebGL 비주얼이 필요할 때. 성능 부담이 크니 페이지당 하나 정도로 제한할 것. 라이선스·가격이 사이트에 없다. 상업 사용 전 확인 필수.
새 프로젝트를 시작할 때 가장 먼저 깔 것. 이 컬렉션의 나머지 대부분이 이걸 전제로 하므로 순서가 뒤바뀌면 손해다. 폼·테이블·다이얼로그 같은 제품 내부 UI는 거의 이걸로 끝난다. 화려함이 필요하면 그때 연출 계열를 위에 얹는다.
랜딩·마케팅 페이지를 빠르게 찍어낼 때. 히어로·피처·가격 블록이 페이지 단위로 준비돼 있다. 제품 내부 UI에는 과하다. 좋은 블록은 All-Access(1회 결제)에 몰려 있으니 무료분으로 먼저 훑고 판단할 것.
Claude Code·Cursor로 작업하다가 컴포넌트 탐색과 설치를 에이전트에 맡기고 싶을 때. MCP 연결이 핵심이다. 직접 고를 생각이면 연출 계열 쪽 개별 라이브러리가 더 빠르다.
특정 이펙트 하나만 딱 필요할 때(테두리 빛, 구체, 액체 금속 등). npm 패키지라 복붙이 아니라 의존성으로 들어간다. 그래서 shadcn을 안 쓰는 프로젝트에도 넣을 수 있는 게 장점. Image Generation만 Three.js가 필요하다.
shadcn/ui를 이미 깐 상태에서 개별 요소에 움직임을 더하고 싶을 때. 컴포넌트 단위로 골라 쓰기 좋다. 페이지를 통째로 찍어내야 하면 Aceternity, 섹션 배경이면 ThreeUI 쪽이 맞다.
