API를 외부에 공개하거나 팀 내부에 문서화해야 할 때. 명세 하나에서 문서·SDK·테스트가 같이 나오므로 API가 바뀔 때 셋이 어긋나는 문제가 줄어든다. API 클라이언트만 따로 쓸 수도 있다. 오픈소스에 오프라인 우선이라 Postman 대체로 가볍게 시작해볼 만하다. 플랫폼 전체를 도입하려면 OpenAPI 명세를 제대로 유지해야 한다. 명세가 없거나 낡아 있으면 여기부터가 일이다. MCP 서버를 제공해 에이전트가 API를 이해하고 호출하게 만들 수 있다. 자사 API를 에이전트에 열 계획이 있다면 이 부분을 볼 것. 오픈소스 컴포넌트와 유료 클라우드가 섞여 있다. 어디까지 무료인지 먼저 확인할 것.
랜딩 페이지에 스크롤 연동 연출이 필요할 때. 스크롤에 맞춰 움직이는 요소는 직접 만들면 성능과 되감기 처리에서 손이 많이 간다. 연출 계열에서 Componentry와 성격이 가장 가깝다 — 둘 다 Vercel OSS 후원에 전면 무료, shadcn CLI 설치다. 규모는 이쪽이 46종으로 조금 크고 랜딩 특화가 뚜렷하다. Aceternity UI와도 겹치는 영역인데, 저쪽은 페이지 블록이 통째로 있고 좋은 것이 유료에 있다. 이쪽은 전부 무료지만 조각 단위가 많다. 버튼·텍스트·레이아웃으로 계열이 나뉘어 있어 필요한 것만 골라 넣기 쉽다. "10k+ 개발자가 사용"은 사이트 자체 홍보 문구다. 판단 근거로 삼지 말 것.
애니메이션이 어딘가 이상한데 너무 빨라서 안 보일 때. 0.2초짜리 트랜지션을 늦춰 프레임 단위로 확인한다. 개발자 도구로는 잡기 어려운 부분이다. 역할은 audit으로 두었다 — 만드는 도구가 아니라 만든 결과를 들여다보는 도구다. Expect·Oxc와 같은 갈래이며 이건 눈으로 보는 검사에 해당한다. Design의 Easing Graphs와 함께 쓰면 좋다. 저기서 곡선을 고르고, 여기서 실제 화면이 그 곡선대로 움직이는지 늦춰서 확인한다. Chrome 확장으로 쓰면 남의 사이트 애니메이션도 뜯어볼 수 있다. 레퍼런스를 분석할 때 유용하다. npm 패키지는 개발 중에만 쓸 것. 프로덕션 번들에 들어갈 이유가 없다.
지도에 마커나 오버레이를 얹어야 할 때. Mapbox GL을 직접 쓰면 지도 인스턴스와 이벤트를 명령형으로 다뤄야 하는데 그 부분을 컴포넌트로 감싼다. React 흐름과 어긋나지 않는 게 요지. 날씨·재난 연출(사이클론, 산불, 레이더)이 기본 제공된다. 반대로 말하면 일반적인 위치 표시 서비스에는 필요 없는 것들이 섞여 있다는 뜻이니 번들 크기를 확인할 것. Mapbox GL은 별도 계정과 토큰이 필요하고 사용량 과금이 있다. 무료로 가려면 MapLibre GL 쪽을 선택할 것 — 이 라이브러리가 둘 다 지원하는 게 실질적인 장점이다. 지도 타일 비용은 이 라이브러리와 별개다. 도입 전 타일 제공자부터 정할 것.
필드가 많은 폼을 짤 때. 손으로 쓰면 지루하고 실수가 나오는 Zod 스키마와 React Hook Form 연결을 한 번에 뽑아낸다. 코드를 내보내는 도구다. 라이브러리로 설치하는 게 아니라 결과물만 가져와 프로젝트에 붙인다. 그래서 UI Components가 아니라 Tools에 뒀다. 회원가입·로그인·2FA 템플릿이 있어 인증 화면 초안을 빠르게 잡을 수 있다. 다만 뽑아낸 코드는 시작점이며 검증 규칙과 에러 문구는 직접 다듬어야 한다. UI Components의 editorcn과 같은 제작자(Abdullah Mukadam)다. Better Auth·Drizzle·Prisma를 전제한 코드가 섞여 나올 수 있다. 다른 스택이면 내보낸 코드를 손봐야 한다.
이미 Lucide를 쓰고 있다면 그대로 갈아끼울 수 있다. 같은 아이콘 세트 위에 움직임만 얹은 형태라 모양이 바뀌지 않는다. 사이드바 메뉴나 툴바처럼 호버가 잦은 자리에 쓴다. 전체에 다 붙이면 산만해지니 주요 동선 몇 개만. Design의 다른 아이콘 자료와 형태가 다르다 — Iconly Pro와 Central Icon System은 내려받아 쓰는 자료이고, 이건 npm으로 들어오는 React 컴포넌트다. 움직임이 코드에 포함돼 있다. reduced-motion을 존중하고 트리 셰이킹이 되는 점이 실무에서 중요하다. 아이콘 542종을 넣어도 쓰는 것만 번들에 들어간다. MIT라 상업 사용에 걸림돌이 없다. Lucide 자체도 ISC로 열려 있다.
시세나 센서값처럼 계속 갱신되는 숫자를 보여줄 때. 일반 차트 라이브러리는 갱신마다 다시 그려 뚝뚝 끊기는데, 이건 값 사이를 보간해 흐르게 만드는 게 목적이다. 오더북 라벨, 캔들, 기간 선택 버튼이 기본 탑재라 금융 시세 화면에 바로 맞는다. 주식·코인 대시보드를 만든다면 처음부터 다시 짜는 것보다 빠르다. 용도가 좁다. 정적인 데이터를 보여줄 거면 Recharts 같은 범용 차트가 낫다. 이건 '실시간'이 전제다. Canvas 기반이라 DOM 노드가 늘지 않아 갱신이 잦아도 버틴다. 다만 접근성(스크린리더)은 별도로 챙겨야 한다. 라이선스가 명시돼 있지 않다. 상업 사용 전 GitHub이나 npm에서 확인할 것.
애니메이션이 어딘가 어색한데 원인을 모를 때. 대개 지속 시간이 아니라 이징이 문제다. 여기서 곡선을 눈으로 비교하면 어떤 느낌을 원하는지 빨리 정해진다. 이름만으로는 감이 안 오는 것들(Anticipate, Overshoot Out 등)을 그래프로 확인할 수 있는 게 핵심. ease-in-out만 반복해 쓰는 습관에서 벗어나는 데 도움이 된다. UI Components의 transitions.dev와 짝이다 — 저쪽은 완성된 트랜지션을 주고, 여기서는 그 안에 넣을 곡선을 고른다. Torph와 같은 제작자(Lochie)가 참여했다. 읽는 자료다. 구현은 CSS cubic-bezier나 쓰는 애니메이션 라이브러리의 값으로 옮겨 적는다.
숫자나 라벨이 실시간으로 바뀌는 자리에 쓴다. 값이 툭 교체되면 눈에 거슬리는데 그 사이를 이어준다. 카운터, 상태 표시, 탭 전환 시 제목 같은 곳. UI Components의 libraries.dev와 같은 방식이다 — 이펙트 하나만 npm 패키지로 가져오는 형태. 세트를 깔 필요가 없다. 의존성이 없고 프레임워크 4종을 지원해서 프로젝트를 가리지 않는다. 이 점은 이 컬렉션에서 드문 편이다. 0.1.3 버전이다. 아직 초기이므로 API가 바뀔 수 있고, 프로덕션에 넣을 거면 버전을 고정할 것.
컴포넌트를 처음부터 설계할 때. "이걸 뭐라고 부르지", "어떤 상태를 갖춰야 하지", "접근성은 뭘 지켜야 하지"에 실제 사례로 답이 나온다. 같은 것을 여러 시스템이 다르게 부르는 문제를 푸는 데 특히 좋다. 팀 안에서 용어를 정할 때 근거로 쓸 만하다. Design의 다른 inspiration과 층위가 다르다 — Navbar Gallery는 네비게이션 한 종류의 시각 사례, Inspo는 사이트 전체 캡처, 이건 컴포넌트 단위의 명세와 접근성 비교다. 보기 좋은 것이 아니라 올바른 것을 찾는 쪽. 복붙용 코드 창고가 아니다. 쓸 코드는 UI Components에서 가져오고, 여기서는 무엇을 만들지를 정한다.
버튼 클릭이나 알림에 소리를 넣고 싶을 때. 효과음을 직접 찾아 다니면 라이선스와 음색 통일에서 시간을 잡아먹는데 그걸 던다. Design의 다른 asset(아이콘·로고)과 같은 갈래이며 이건 소리다. 시각이 아니라 청각 자료라는 점만 다르다. 주의: 웹에서 소리는 기본이 꺼짐이어야 한다. 사용자가 켠 적 없는 소리가 나면 불쾌감으로 이어진다. 설정에서 끌 수 있게 하고 prefers-reduced-motion처럼 조용한 기본값을 둘 것. 소리는 의미를 실어야 한다. 성공·실패·알림 정도로 몇 개만 정해 일관되게 쓰고, 모든 클릭에 붙이지 말 것. 라이선스 종류가 명시돼 있지 않다. 상업 프로젝트라면 GitHub에서 확인할 것.
이미 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에서 확인할 것.
결제 수단 아이콘, 소셜 로그인 버튼, 기술 스택 배지처럼 남의 브랜드 로고가 필요할 때. 공식 프레스킷을 하나씩 찾아다니는 수고를 던다. Design의 다른 아이콘 자료와 용도가 다르다 — Iconly Pro와 Central Icon System은 내가 그리는 UI 아이콘이고, 이건 정해진 형태가 있는 남의 로고다. 셋은 경쟁이 아니라 용도가 갈린다. 중요: 라이브러리가 오픈소스라는 것과 로고를 마음대로 써도 된다는 것은 별개다. 브랜드 로고는 상표이므로 각 회사의 브랜드 가이드라인(색 변경 금지, 최소 여백, 제휴 오인 금지 등)을 따라야 한다. 특히 자사 서비스가 그 브랜드와 제휴한 것처럼 보이게 쓰면 문제가 된다. MCP 서버가 있어 에이전트에게 "결제사 로고 넣어줘"를 맡길 수 있다.
기사나 문서를 긁어와 텍스트만 다뤄야 할 때. RAG 인덱싱, 요약 파이프라인, 스크랩 기능처럼 본문 품질이 결과를 좌우하는 곳에 쓴다. Mozilla Readability의 대안이며 차이는 세 가지 — 요소 제거가 더 보수적이고, 각주·코드블록 형식을 일관되게 정규화하며, 메타데이터를 더 많이 뽑는다. Readability로 본문이 잘려 나가는 문제를 겪었다면 바꿔볼 만하다. CLI가 있어 라이브러리로 붙이기 전에 npx로 몇 개 URL을 돌려보고 품질을 먼저 확인할 수 있다. 브라우저와 Node 양쪽에서 동작한다. 서버에서 쓰려면 JSDOM이나 linkedom이 별도로 필요하다. MIT라 상업 사용에 제약이 없다.
로컬 모델을 돌려보려는데 어떤 걸 받아야 할지 모를 때. 기기를 감지해 등급으로 정리해주므로 받아보고 실패하는 시행착오가 줄어든다. 새 맥이나 GPU를 살지 고민할 때 기기 비교로 미리 가늠해볼 수도 있다. 속도는 추정치다. 양자화 수준이나 컨텍스트 길이에 따라 실제는 달라지니 등급은 후보를 좁히는 용도로만 쓸 것. Tools의 autoskills와 같은 제작자(midudev)다. 역할은 directory로 두었다 — Toolfolio처럼 무언가를 고르기 위해 찾아보는 곳이지, 프로젝트에 넣거나 결과물을 검사하는 도구가 아니다.
에이전트에게 "이런 느낌으로"를 말로 설명하기 어려울 때. MCP로 붙여두면 에이전트가 실제 사이트 캡처와 DESIGN.md를 직접 찾아 참조한다. Design의 getdesign.md와 같은 갈래이며 더 넓다 — 저쪽은 DESIGN.md 위주(550곳), 이쪽은 캡처 2,320장까지 포함(832곳)하고 MCP 연동이 붙는다. 에이전트에 상시 물려둘 용도라면 이쪽이 낫다. Navbar Gallery처럼 사람이 눈으로 훑는 용도로도 쓸 수 있다. 다만 그쪽은 네비게이션만 모은 전문 갤러리이고 이쪽은 사이트 전체다. 남의 사이트 캡처가 원본이다. 참고까지만 하고 그대로 베끼지 말 것. 라이선스도 명시돼 있지 않다.
같은 형식의 영상을 반복해서 편집할 때. 인트로·자막·컷 규칙을 Skill로 굳혀두면 다음 영상부터 그대로 적용된다. 회차물이나 정기 콘텐츠에서 값어치가 크다. Design의 Daydream과 직접 경쟁한다. 갈리는 지점은 두 가지 — (1) 처리 위치: Daydream은 로컬에서 끝나고, 이쪽은 클라우드 전사와 생성 모델을 쓴다. 외부에 나가면 안 되는 푸티지라면 Daydream. (2) 반복성: 매번 다른 영상이면 Daydream, 같은 포맷을 찍어낸다면 이쪽. macOS 26(Tahoe) 이상만 된다. 구형 맥이나 Windows면 선택지에서 빠진다. 편집기 자체는 무료고 생성 기능만 크레딧이다. 생성을 안 쓰면 비용이 들지 않는다.
영상을 직접 손으로 편집해야 하는데 컷 작업이 번거로울 때. 트랜스크립트에서 문장을 지우면 그 구간이 잘리는 방식이라 말 위주 영상에서 특히 빠르다. Design의 Photon Studio와 같은 부류다 — 사람이 조작하는 데스크탑 앱이고 처리가 로컬에서 끝난다. 이미지는 Photon, 영상은 이쪽. Tools의 Remocn·HyperFrames와 혼동하지 말 것. 저쪽은 코드나 프롬프트로 영상을 생성하는 프로젝트용 도구이고, 이건 실제 촬영분을 편집하는 편집기다. 편집 결과를 Final Cut·Premiere로 넘길 수 있어 기존 작업 흐름에 중간 단계로 끼워 넣을 수 있다. 무료 티어가 있으니 먼저 써보고 판단할 것. 유료는 월 $20부터다.
에이전트가 뽑아낸 화면이 어딘가 뻔하고 밋밋할 때. 무엇이 문제인지 61개 항목으로 짚어주고 명령으로 고쳐 나간다. Tools의 autoskills와 같은 갈래 — 둘 다 에이전트에 지식을 붙이는 스킬이다. autoskills는 스택에 맞는 스킬을 자동으로 찾아 깔고, 이건 디자인 한 분야를 깊게 판다. Design의 getdesign.md와 짝으로 쓸 수 있다. 저쪽이 따를 기준(DESIGN.md)을 주고, 이쪽이 그 기준대로 됐는지 보며 다듬는다. CI 검사가 있어 파이프라인에도 넣을 수 있다. 검사 성격이 강해 audit으로 볼 여지도 있으나, 설치해서 결과물을 만들어내는 쪽에 무게를 두어 build로 분류했다.
청구서·리포트를 PDF로 만들 때. 표·헤더·푸터 같은 조각이 준비돼 있어 @react-pdf/renderer를 맨손으로 쓰는 것보다 빠르다. UI Components의 pdfcn과 정면으로 겹친다. 고르는 기준은 기반 스택 — 이건 @react-pdf/renderer(널리 쓰이고 자료가 많음), pdfcn은 Takumi/Forme(더 새로움). 기존 프로젝트가 @react-pdf/renderer를 쓰고 있다면 이쪽이 답이다. 라이선스도 갈린다 — 이건 MIT로 명확하고 pdfcn은 미표기다. 상업 프로젝트라면 이 차이가 결정적일 수 있다. 복붙 방식이라 업스트림 수정은 따라오지 않는다.
에이전트가 고친 코드를 사람이 일일이 확인하기 벅찰 때. 변경분에서 테스트 계획을 만들어 실제 브라우저로 돌려보므로 스크린샷 대조보다 신뢰도가 높다. 성능 지표(INP·LCP)와 npm 의존성 취약점까지 한 번에 본다는 게 특징. 별도 도구를 여럿 돌릴 필요가 줄어든다. 로컬 실행이라 코드가 외부로 나가지 않는다. Tools의 audit 중 Is Agentic·Is Your Site Agent-Ready는 배포된 공개 URL을 스캔하는 쪽이고, 이건 배포 전 단계를 본다. --ci로 파이프라인에 넣을 수 있다. 다만 자동 생성된 테스트 계획이 항상 옳지는 않으니 초기에는 무엇을 검사했는지 읽어볼 것.
프로필 사진을 올리지 않은 사용자의 기본 아바타가 필요할 때. 회색 사람 아이콘 대신 계정마다 다른 얼굴이 나와 목록에서 구분이 쉬워진다. 결정론적이라는 게 핵심이다 — 같은 이메일이면 어느 기기에서 보든 같은 얼굴이다. 서버에 저장하거나 캐시할 필요가 없다. 얼굴 형태로 고정된다. 추상 패턴을 원하면 DiceBear나 boring-avatars 쪽이 선택지가 넓다. Next.js 라우트 핸들러가 딸려 있어 이미지 URL로도 뽑을 수 있다. 메일 본문처럼 React를 못 쓰는 곳에 넣을 때 유용하다. MIT라 상업 사용에 걸림돌이 없다.
발표 자료나 문서에 넣을 도식을 AI로 뽑을 때. 프롬프트를 처음부터 쓰는 대신 원하는 스타일의 예시를 고르고 복사하는 방식이라 시행착오가 줄어든다. 결과물이 이미지다. 웹에 넣을 도식이라면 코드로 그리는 편이 수정과 반응형에 유리하니 용도를 구분할 것. 스타일을 하나 정해 문서 전체에 같은 계열로 밀면 통일감이 생긴다. 매번 다른 프롬프트를 쓰면 제각각이 된다. Design의 getdesign.md와 같은 결 — 둘 다 AI에 넘기는 재료다. 저쪽은 코드 생성용 디자인 기준, 이쪽은 이미지 생성용 프롬프트.
한 화면에서 시선을 잡을 요소가 딱 하나 필요할 때. 세트로 깔고 가는 라이브러리가 아니라 개별 연출을 골라 쓰는 곳이다. 같은 연출 계열 중에서도 성격이 가장 뾰족하다 — Magic UI·Componentry가 범용 세트라면 여기는 Perspective Book이나 Exploding Input처럼 특정 연출 하나로 승부한다. 그만큼 프로젝트에 맞는 게 없을 확률도 높다. CLI가 없어 코드를 직접 복사한다. 업데이트를 따라가는 경로가 없으니 가져온 시점에서 내 코드로 확정된다. 라이선스 미표기 — 상업 사용 전 GitHub에서 확인할 것.
챗 인터페이스나 에이전트 화면을 만들 때. 메시지 스트리밍, 추론 과정 표시, 출처 인용, 코드 블록처럼 매번 다시 짜게 되는 것들이 준비돼 있다. Vercel AI SDK를 쓰고 있다면 1순위다. 같은 팀이 만들어 연동이 전제돼 있다. UI Components의 mcpcn과 겹치는 영역이 있다 — mcpcn은 Base UI 기반의 개인 프로젝트, 이건 shadcn/ui 기반의 Vercel 공식. 기존 스택이 shadcn/ui라면 이쪽이 자연스럽다. 소스를 프로젝트에 복사해 넣는 방식이라 업스트림 수정은 따라오지 않는다. 고쳐 쓸 자유와 맞바꾸는 부분.
제품 전반에 일관된 선 아이콘이 필요할 때. 굵기와 모서리를 맞출 수 있어 기존 타이포·버튼과 톤을 맞추기 쉽다. Design의 Iconly Pro와 갈린다 — Iconly는 플랫·3D·애니메이션까지 여러 계열을 담은 팩이고, 이건 한 가지 선 스타일을 체계적으로 밀고 가는 쪽. 제품 UI의 기본 아이콘 세트로는 이쪽이 맞고, 마케팅 페이지에 3D 아이콘이 필요하면 Iconly. React 패키지가 있어 개발에서 바로 import해 쓸 수 있다. Figma·Framer 플러그인도 있어 디자인·구현 간 세트가 어긋나지 않는다. 라이선스가 명시돼 있지 않다. 상업 사용 전 Pro 조건을 확인할 것.
카테고리는 아는데 어떤 제품이 있는지 모를 때 훑는 용도. 예를 들어 "소셜 예약 도구" 같은 막연한 단계에서 후보를 모을 때. 직접 쓰는 도구가 아니라 도구를 찾는 곳이다. 여기서 고른 것을 각 컬렉션에 따로 저장하는 식으로 쓰면 된다. 디렉터리 특성상 등재 기준이 느슨하고 제휴 링크가 섞이기 쉽다. 순위나 "Best" 표기를 그대로 믿지 말고 후보 수집까지만 쓸 것. 개발 도구에 특화된 곳은 아니다. 프론트엔드 라이브러리를 찾는다면 UI Components에 모아둔 레지스트리들이 훨씬 밀도가 높다.
린트·포맷이 느려서 커밋 전 대기가 길어질 때. Oxlint는 ESLint 호환이라 설정을 크게 바꾸지 않고 얹어볼 수 있다. 전부를 한 번에 갈아탈 필요는 없다. 린터만 먼저 붙여 체감하고 나머지는 나중에 봐도 된다. 규칙 800+라고 해도 ESLint 플러그인 생태계 전체를 덮지는 못한다. 쓰던 플러그인이 많으면 빠지는 규칙부터 확인할 것. oxc-minify는 알파다. 프로덕션 번들에는 아직 이르다. Vite를 만든 VoidZero가 관리하므로 Vite/Rolldown 쪽과 함께 갈 가능성이 높다.
