알고리즘 동작이 머리에 안 그려질 때. 글로 읽는 것보다 한 단계씩 움직이는 걸 보는 편이 빠르다. Tools의 research 역할로 두었다. 코드를 만들거나 검사하는 도구가 아니라 읽고 배우는 자료다. 코드 예시가 5개 언어로 제공된다. 개념을 이해한 뒤 쓰는 언어로 바로 옮겨볼 수 있다. midudev의 프로젝트가 이 컬렉션에서 넷째다 — autoskills, CanIRun.ai, Tailwind Animations, 그리고 이것. 학습용이다. 실무에서 바로 쓰는 물건은 아니고 면접 준비나 개념 복습 때 여는 쪽.
상용 디자인 도구의 오픈소스 대안을 찾을 때. 제너러티브 아트나 실험적인 이미지 처리처럼 상용 도구에 없는 것들이 섞여 있다. Tools의 다른 directory와 대상이 갈린다 — Toolfolio는 일반 SaaS, Dev Resources는 개발자 도구, Public APIs는 API, 이건 크리에이티브·디자인 쪽 오픈소스다. 큐레이션이라 규모는 작다. 대신 전부 오픈소스라 라이선스 부담이 적다. 마지막 갱신일이 표시된다. 오래된 목록인지 확인하고 볼 것.
타이밍을 눈으로 맞춰야 하는 복잡한 애니메이션을 만들 때. 코드에서 숫자를 고치고 새로고침하는 반복 대신 타임라인에서 끌어 조정한다. Tools의 build로 두었다. 결과물을 프로젝트에 넣는 라이브러리이면서 동시에 편집 도구라 애매하지만, 만드는 데 쓰는 쪽에 무게를 두었다. UI Components의 연출 계열과 층위가 다르다. 저들은 완성된 효과를 주고, 이건 내가 원하는 움직임을 직접 설계하는 도구다. 3D(THREE.js·React Three Fiber) 쪽에서 특히 쓰인다. UI Components의 ThreeUI나 View3D로 만든 장면에 움직임을 입힐 때. 에디터는 개발 중에만 쓰고 프로덕션 번들에서는 빠지도록 설정해야 한다. 확인할 것. 학습 곡선이 있다. 단순한 등장·퇴장 효과라면 Tailwind Animations나 Framer Motion이 빠르다.
국내 서비스에 필요한 데이터를 찾을 때. 공공데이터포털·행정안전부·국토교통부 같은 국내 출처가 정리돼 있어 영어권 목록에서는 안 나오는 것들이 잡힌다. Tools의 Public APIs와 짝이다. 저쪽은 글로벌 위주, 이건 국내 위주. 국내 주소·부동산·교통·행정 데이터가 필요하면 여기부터 볼 것. 국내 공공 API는 대개 신청과 승인 절차가 있고 일일 호출 한도가 있다. 목록에서 찾은 뒤 실제 발급 조건을 확인할 것. 이 컬렉션에서 세 번째 한국어 자료다(BananaX, Velopers에 이어). MIT로 명확하다. 다만 이건 목록의 라이선스이고 개별 API의 이용 약관은 각각 다르다.
사이드 프로젝트나 데모에 쓸 데이터 출처를 찾을 때. 날씨·환율·지도·이미지처럼 직접 만들 필요 없는 것들을 훑는다. Tools의 Dev Resources와 같은 제작자(Marcel Cruz)다. 저쪽은 도구, 이건 API로 대상이 갈린다. 등재는 되어 있어도 서비스가 죽었거나 인증 정책이 바뀐 경우가 흔하다. 쓰기 전에 실제로 호출해볼 것. 무료 API는 호출 제한과 서비스 종료 위험이 따른다. 프로덕션에 넣을 거면 유료 대안이 있는지 함께 확인할 것.
국내 기업들이 실제로 어떤 문제를 어떻게 풀었는지 훑을 때. 해외 자료와 달리 국내 서비스 규모와 환경이 전제된 사례라 바로 대입해보기 좋다. 블로그를 하나씩 찾아다닐 필요가 없다는 게 핵심. 카테고리 필터로 관심 영역만 볼 수 있다. Tools의 Deta Surf와 같은 research 역할이나 성격이 다르다 — 저쪽은 자료를 모으고 정리하는 도구, 이건 읽을 자료 자체를 공급하는 곳이다. 이 컬렉션에서 두 번째 한국어 자료다(첫 번째는 Design의 BananaX). 정기적으로 들르는 용도다. 특정 문제를 풀 때 검색하는 곳은 아니다.
자료를 여러 곳에서 모아 정리해야 할 때. 브라우저·PDF 뷰어·노트 앱을 오가는 대신 한 곳에서 끝내는 것이 목적이다. 데이터가 로컬에 저장되고 내보내기가 된다. 노트 도구는 갇히면 빠져나오기 어려운데 그 위험이 낮은 편이다. 오픈 베타다. 기능과 형식이 바뀔 수 있으니 중요한 자료를 전부 옮기기 전에 내보내기가 실제로 되는지 확인할 것. Tools의 다른 항목과 성격이 다르다. 코드를 만들거나 검사하는 도구가 아니라 자료를 모으고 읽는 도구라 research 역할로 따로 두었다. 브라우저를 겸하므로 기본 브라우저를 바꾸는 부담이 있다. 리서치 세션에만 따로 쓰는 편이 현실적이다.
"이 버튼 색 좀 바꿔줘"를 말로 설명하기 어려울 때. 화면에서 요소를 집으면 에이전트가 그 코드로 바로 간다. 컴포넌트가 여러 파일에 흩어진 큰 프로젝트일수록 값어치가 크다. Tools의 Expect와 같은 제작자 계열(Million/Aiden Bai)이다. 저쪽은 변경분을 브라우저로 검증하는 쪽, 이건 변경할 위치를 찾아주는 쪽이라 작업 흐름에서 앞뒤로 붙는다. 개발 중에만 쓰는 도구다. 프로덕션 번들에 들어가지 않도록 설정을 확인할 것. "2배 빠르다"는 제작자 측 주장이다. 직접 써보고 판단할 것. 라이선스가 명시돼 있지 않다. GitHub에서 확인할 것.
새 프로젝트의 린트·포맷 설정을 잡을 때. 규칙을 직접 고르고 충돌을 맞추는 과정을 건너뛴다. Tools의 Oxc와 층위가 다르다 — Oxc는 린터·포매터 자체이고, 이건 그것들(Oxlint 포함)을 어떻게 설정할지를 정해주는 프리셋이다. 둘은 경쟁이 아니라 위아래로 겹친다. 에이전트 연동이 핵심 중 하나다. 규칙을 사람과 에이전트가 같이 지키게 만드는 게 목적이라, Claude Code로 작업이 잦다면 값어치가 크다. 프리셋이므로 팀의 기존 규칙과 충돌할 수 있다. 진행 중인 프로젝트에 넣으면 대량의 수정이 한 번에 생길 수 있으니 새 프로젝트나 별도 브랜치에서 먼저 시도할 것. 채택 기업 목록은 사이트 자체 주장이다. 라이선스도 명시돼 있지 않으니 GitHub에서 확인할 것.
디스코드 봇을 만들 때. discord.js를 그대로 쓰면 이벤트 등록과 커맨드 배포를 매번 직접 엮어야 하는데 그 뼈대를 대신 잡아준다. 이 컬렉션에서 처음 나온 백엔드·봇 영역이다. 지금까지는 프론트엔드 UI와 개발 보조 도구 위주였다. discord.js 위에 한 겹 더 올라간다. 문제가 생기면 discord.js 쪽 문서까지 봐야 하므로, 단순한 봇이면 discord.js만으로도 충분하다. 커뮤니티 운영용 봇(공지, 역할 부여, 문의 접수 등)을 만들 일이 생기면 출발점으로 볼 것. MIT라 상업 사용에 제약이 없다.
"이거 변환하는 사이트 뭐였지" 하고 매번 검색하게 되는 작업들을 한곳에서 끝낸다. 북마크 하나로 자잘한 도구 여러 개를 대체하는 게 요지. 자체 호스팅이 가능한 게 실질적인 강점이다. 사내 데이터나 토큰을 남의 사이트에 붙여넣기 꺼려진다면 Docker로 올려두고 그쪽을 쓸 것. 공개 사이트에 민감한 값을 넣지 말 것. Tools의 Toolfolio·Dev Resources와 다르다 — 저쪽은 도구를 찾는 목록이고, 이건 도구 자체다. 그래서 directory가 아니라 build로 두었다. GPLv3다. 코드를 가져다 쓰는 게 아니라 서비스를 쓰는 것이므로 대개 문제되지 않지만, 포크해 사내 배포판을 만들 거면 라이선스 조건을 확인할 것.
반투명 유리 느낌이나 볼록한 뉴모피즘 카드를 만들 때. backdrop-filter와 그림자 값을 손으로 맞추면 오래 걸리는데 슬라이더로 조절해 값을 가져온다. Tools의 FormSCN·ChartCN과 같은 갈래다 — 웹에서 만들어 코드만 내보내는 생성기. 뽑아낸 CSS는 하드코딩된 값이다. 디자인 토큰을 쓰는 프로젝트라면 그대로 넣지 말고 변수로 바꿔 넣을 것. 글래스모피즘은 backdrop-filter 성능 부담이 있고 배경에 따라 대비가 무너져 가독성이 떨어지기 쉽다. 큰 영역이나 본문 위에는 신중할 것. 개인이 만든 소규모 도구다. 사라져도 문제없도록 결과 CSS만 챙겨두면 된다.
카테고리는 정해졌는데 후보를 모르겠을 때 훑는 용도. 인증·테스팅·호스팅처럼 한 번 정하면 오래 가는 선택 앞에서 목록을 넓게 보기 좋다. Tools의 Toolfolio와 같은 갈래(directory)지만 이쪽이 개발자 쪽에 특화돼 있다. 일반 SaaS까지 다루는 Toolfolio보다 밀도가 높다. 커뮤니티 제출 기반이라 등재 기준이 느슨하다. 후보 수집까지만 쓰고 판단은 따로 할 것. 광고 상품이 있다는 점도 감안할 것. 학습 자료까지 포함한다는 게 Toolfolio와 다른 점이다. 새 분야를 시작할 때의 출발점으로도 쓸 수 있다.
차트를 붙일 때. Recharts 설정을 문서 보며 맞추는 대신 데이터를 넣고 눈으로 확인한 뒤 코드를 가져온다. Tools의 FormSCN과 같은 갈래다 — 웹에서 만들어 코드만 내보내는 생성기. 라이브러리로 설치하는 물건이 아니다. 내보낼 때 데이터를 박을지 props로 받을지 고를 수 있다. 실제 프로젝트에 넣을 거면 props 쪽을 고를 것. UI Components의 Liveline과 용도가 갈린다 — 저건 실시간으로 흐르는 차트, 이건 정적인 데이터를 보여주는 일반 차트다. 결과가 Recharts 코드다. 이미 다른 차트 라이브러리를 쓰고 있다면 중복이 생긴다.
API를 외부에 공개하거나 팀 내부에 문서화해야 할 때. 명세 하나에서 문서·SDK·테스트가 같이 나오므로 API가 바뀔 때 셋이 어긋나는 문제가 줄어든다. API 클라이언트만 따로 쓸 수도 있다. 오픈소스에 오프라인 우선이라 Postman 대체로 가볍게 시작해볼 만하다. 플랫폼 전체를 도입하려면 OpenAPI 명세를 제대로 유지해야 한다. 명세가 없거나 낡아 있으면 여기부터가 일이다. MCP 서버를 제공해 에이전트가 API를 이해하고 호출하게 만들 수 있다. 자사 API를 에이전트에 열 계획이 있다면 이 부분을 볼 것. 오픈소스 컴포넌트와 유료 클라우드가 섞여 있다. 어디까지 무료인지 먼저 확인할 것.
애니메이션이 어딘가 이상한데 너무 빨라서 안 보일 때. 0.2초짜리 트랜지션을 늦춰 프레임 단위로 확인한다. 개발자 도구로는 잡기 어려운 부분이다. 역할은 audit으로 두었다 — 만드는 도구가 아니라 만든 결과를 들여다보는 도구다. Expect·Oxc와 같은 갈래이며 이건 눈으로 보는 검사에 해당한다. Design의 Easing Graphs와 함께 쓰면 좋다. 저기서 곡선을 고르고, 여기서 실제 화면이 그 곡선대로 움직이는지 늦춰서 확인한다. Chrome 확장으로 쓰면 남의 사이트 애니메이션도 뜯어볼 수 있다. 레퍼런스를 분석할 때 유용하다. npm 패키지는 개발 중에만 쓸 것. 프로덕션 번들에 들어갈 이유가 없다.
필드가 많은 폼을 짤 때. 손으로 쓰면 지루하고 실수가 나오는 Zod 스키마와 React Hook Form 연결을 한 번에 뽑아낸다. 코드를 내보내는 도구다. 라이브러리로 설치하는 게 아니라 결과물만 가져와 프로젝트에 붙인다. 그래서 UI Components가 아니라 Tools에 뒀다. 회원가입·로그인·2FA 템플릿이 있어 인증 화면 초안을 빠르게 잡을 수 있다. 다만 뽑아낸 코드는 시작점이며 검증 규칙과 에러 문구는 직접 다듬어야 한다. UI Components의 editorcn과 같은 제작자(Abdullah Mukadam)다. Better Auth·Drizzle·Prisma를 전제한 코드가 섞여 나올 수 있다. 다른 스택이면 내보낸 코드를 손봐야 한다.
기사나 문서를 긁어와 텍스트만 다뤄야 할 때. RAG 인덱싱, 요약 파이프라인, 스크랩 기능처럼 본문 품질이 결과를 좌우하는 곳에 쓴다. Mozilla Readability의 대안이며 차이는 세 가지 — 요소 제거가 더 보수적이고, 각주·코드블록 형식을 일관되게 정규화하며, 메타데이터를 더 많이 뽑는다. Readability로 본문이 잘려 나가는 문제를 겪었다면 바꿔볼 만하다. CLI가 있어 라이브러리로 붙이기 전에 npx로 몇 개 URL을 돌려보고 품질을 먼저 확인할 수 있다. 브라우저와 Node 양쪽에서 동작한다. 서버에서 쓰려면 JSDOM이나 linkedom이 별도로 필요하다. MIT라 상업 사용에 제약이 없다.
로컬 모델을 돌려보려는데 어떤 걸 받아야 할지 모를 때. 기기를 감지해 등급으로 정리해주므로 받아보고 실패하는 시행착오가 줄어든다. 새 맥이나 GPU를 살지 고민할 때 기기 비교로 미리 가늠해볼 수도 있다. 속도는 추정치다. 양자화 수준이나 컨텍스트 길이에 따라 실제는 달라지니 등급은 후보를 좁히는 용도로만 쓸 것. Tools의 autoskills와 같은 제작자(midudev)다. 역할은 directory로 두었다 — Toolfolio처럼 무언가를 고르기 위해 찾아보는 곳이지, 프로젝트에 넣거나 결과물을 검사하는 도구가 아니다.
에이전트가 뽑아낸 화면이 어딘가 뻔하고 밋밋할 때. 무엇이 문제인지 61개 항목으로 짚어주고 명령으로 고쳐 나간다. Tools의 autoskills와 같은 갈래 — 둘 다 에이전트에 지식을 붙이는 스킬이다. autoskills는 스택에 맞는 스킬을 자동으로 찾아 깔고, 이건 디자인 한 분야를 깊게 판다. Design의 getdesign.md와 짝으로 쓸 수 있다. 저쪽이 따를 기준(DESIGN.md)을 주고, 이쪽이 그 기준대로 됐는지 보며 다듬는다. CI 검사가 있어 파이프라인에도 넣을 수 있다. 검사 성격이 강해 audit으로 볼 여지도 있으나, 설치해서 결과물을 만들어내는 쪽에 무게를 두어 build로 분류했다.
에이전트가 고친 코드를 사람이 일일이 확인하기 벅찰 때. 변경분에서 테스트 계획을 만들어 실제 브라우저로 돌려보므로 스크린샷 대조보다 신뢰도가 높다. 성능 지표(INP·LCP)와 npm 의존성 취약점까지 한 번에 본다는 게 특징. 별도 도구를 여럿 돌릴 필요가 줄어든다. 로컬 실행이라 코드가 외부로 나가지 않는다. Tools의 audit 중 Is Agentic·Is Your Site Agent-Ready는 배포된 공개 URL을 스캔하는 쪽이고, 이건 배포 전 단계를 본다. --ci로 파이프라인에 넣을 수 있다. 다만 자동 생성된 테스트 계획이 항상 옳지는 않으니 초기에는 무엇을 검사했는지 읽어볼 것.
카테고리는 아는데 어떤 제품이 있는지 모를 때 훑는 용도. 예를 들어 "소셜 예약 도구" 같은 막연한 단계에서 후보를 모을 때. 직접 쓰는 도구가 아니라 도구를 찾는 곳이다. 여기서 고른 것을 각 컬렉션에 따로 저장하는 식으로 쓰면 된다. 디렉터리 특성상 등재 기준이 느슨하고 제휴 링크가 섞이기 쉽다. 순위나 "Best" 표기를 그대로 믿지 말고 후보 수집까지만 쓸 것. 개발 도구에 특화된 곳은 아니다. 프론트엔드 라이브러리를 찾는다면 UI Components에 모아둔 레지스트리들이 훨씬 밀도가 높다.
린트·포맷이 느려서 커밋 전 대기가 길어질 때. Oxlint는 ESLint 호환이라 설정을 크게 바꾸지 않고 얹어볼 수 있다. 전부를 한 번에 갈아탈 필요는 없다. 린터만 먼저 붙여 체감하고 나머지는 나중에 봐도 된다. 규칙 800+라고 해도 ESLint 플러그인 생태계 전체를 덮지는 못한다. 쓰던 플러그인이 많으면 빠지는 규칙부터 확인할 것. oxc-minify는 알파다. 프로덕션 번들에는 아직 이르다. Vite를 만든 VoidZero가 관리하므로 Vite/Rolldown 쪽과 함께 갈 가능성이 높다.
로딩 중 화면이 덜컹거릴 때(레이아웃 시프트). 스켈레톤을 손으로 그리면 실제 레이아웃과 어긋나기 마련인데 그 어긋남 자체를 없애는 접근이다. 목록·카드처럼 같은 모양이 반복되는 화면에서 효과가 크다. 빌드 시점에 캡처하는 구조라 UI를 고치면 다시 돌려야 한다. CI에 넣어두지 않으면 스켈레톤만 옛 모습으로 남는다. UI Components의 transitions.dev에도 스켈레톤 로더가 있지만 그건 손으로 맞추는 템플릿이고, 이건 자동 생성이다.
제품 소개 영상이 필요한데 After Effects를 다룰 줄 모를 때. 화면 녹화보다 나은 결과를 영상 편집 없이 얻는 게 목적이다. 애니메이션과 타이밍이 이미 정해진 조각을 에이전트가 조합하는 구조다. 그래서 빠른 대신 완전히 새로운 연출은 어렵다. Tools의 HyperFrames와 갈린다 — HyperFrames는 코드로 영상을 직접 짜는 쪽(정밀·자동화), 이건 말로 시켜서 뽑는 쪽(속도). 반복 자동 생성이면 HyperFrames, 일회성 소개 영상이면 이쪽. MIT에 무료라 라이선스 부담이 없다.
새 프로젝트를 열었을 때 한 번 돌릴 것. 스택에 맞는 스킬을 알아서 찾아주므로 어떤 스킬이 있는지 몰라도 된다. 먼저 dry-run으로 무엇이 설치될지 확인한 다음 실행하는 편이 안전하다. 설치되는 건 결국 에이전트에게 주는 지침 파일이다. 내용은 직접 열어보고 프로젝트 관행과 어긋나는 부분은 손볼 것. Tools의 agentcn과 다르다 — agentcn은 에이전트 자체를 만드는 레시피, 이건 이미 쓰는 에이전트에 지식을 붙이는 쪽.
CLI 도구를 React로 짜고 싶을 때의 뼈대. 앱 구조와 실행 환경을 담당한다. UI Components의 termcn과 짝이다 — Gridland가 틀이면 termcn이 그 안에 넣는 조각(표·차트·스피너 등). 둘 다 OpenTUI 계열이라 같이 쓰기 좋다. 브라우저에서도 같은 코드가 도는 게 특징. 터미널 앱의 데모 페이지를 웹으로 그대로 내보낼 수 있다. Bun 전제로 안내되므로 Node 환경이라면 먼저 확인할 것.
Tools의 Is Agentic과 같은 목적이지만 보는 층위가 다르다. 둘 다 돌려보고 비교할 것. Is Agentic은 에이전트가 실제로 사이트를 돌아다닌 경로를 보여주는 쪽(행동 관찰), 이건 표준 구현 여부를 항목별로 체크하는 쪽(스펙 대조)이다. 커머스 표준(x402·UCP·ACP)까지 본다는 게 이 도구의 특징이다 — 에이전트가 대신 결제·주문하는 흐름을 대비하는 항목들이다. robots.txt의 AI 봇 규칙처럼 당장 고칠 수 있는 것부터 권고해주니 배포 후 한 번 돌릴 것.
에이전트를 처음부터 짜기 전에 여기 레시피를 먼저 볼 것. 구조를 통째로 가져다 고치는 편이 빠르다. 프레임워크별로 갈리므로(Mastra, LangGraph 등) 쓸 스택부터 정하고 들어갈 것. 주식 분석 MCP나 로컬 도구에 에이전트를 붙일 때의 출발점으로 쓸 만하다.
반복적으로 찍어내야 하는 영상이 있을 때(제품 소개, 데이터 기반 리포트 영상 등). 결정론적 렌더라 CI에 걸어 자동 생성할 수 있다. 일회성 영상 하나뿐이면 그냥 영상 편집기가 빠르다.
