ease-in을 쓰고, scale(0)에서 등장시키고, 키보드 액션에 애니메이션을 붙이는 — 에이전트가 반복하는 "작지만 치명적인" 실수들을 규칙·수치·검사표로 못 박는다.
(저장소: emilkowalski/skills · 스킬 4종 · 순수 마크다운 · MIT · Vercel·Linear 출신, animations.dev 운영 · TrendShift 오늘 Daily 2위 · New 2026)
이 저장소가 대체 무엇인가.
"디자이너·엔지니어가 더 나은 인터페이스를 만들도록 돕는, 도메인 전문가의 감각을 담은 AI 에이전트용 스킬 모음"이다. npx skills@latest add emilkowalski/skills 한 줄로 설치하면, Claude Code·Cursor 같은 코딩 에이전트가 UI를 만들거나 리뷰할 때 Emil Kowalski의 애니메이션 철학 — 어떤 easing을 언제 쓰고, 몇 ms가 적당하며, 무엇은 아예 애니메이션하면 안 되는지 — 을 기준으로 판단하게 된다.
에이전트(요리사)는 손이 빠르고 재료(코드)를 다룰 줄 알지만, 간을 어떻게 맞춰야 "맛있다"고 느껴지는지는 모른다. 이 저장소는 셰프가 수년간 Vercel·Linear의 주방에서 체득한 간 맞추기 — "enter는 ease-out, 300ms를 넘기지 마라, 아무것도 무(無)에서 나타나지 않는다" — 를 레시피 노트 4권으로 정리해 꽂아둔 것이다. 요리사가 바뀌어도 맛은 유지된다.
스킬은 4종으로 역할이 나뉜다: emil-design-eng(메인 — 애니메이션 의사결정 프레임워크 + 컴포넌트 원칙), review-animations(모션 코드만 엄격 심사하는 리뷰어), animation-vocabulary(모호한 묘사 → 정확한 용어 역방향 사전), apple-design(애플 WWDC 디자인 강연을 웹으로 번역한 원론).
2026년 "AI skills" 붐의 한가운데서, 이 레포가 특별한 이유.
README의 핵심 주장: 에이전트는 애니메이션의 재료를 자주 잘못 고른다. enter 애니메이션에 ease-in(반응이 느려 보이는 대표 원인)을 쓰거나, 반투명 그림자 대신 solid border를 고른다. 이런 작은 선택들이 복리로 쌓여 인터페이스를 "훌륭함"과 "그냥 그럼"으로 가른다는 것. 저자의 에세이 "Agents with Taste"의 실전판으로, 에이전트가 저지를 수 있는 실수를 목록화하고 고치는 법을 명시하는 방식으로 스킬을 설계했다.
Emil Kowalski는 Sonner(React 토스트, 주간 npm 다운로드 1,300만+)와 Vaul(드로어) 제작자로, Vercel·Linear에서 일했고 유료 강의 animations.dev를 운영한다. 스킬 내용이 추상적 조언이 아니라 실제로 수백만 명이 쓰는 컴포넌트를 만들며 검증된 수치와 패턴(velocity > 0.11이면 dismiss, 버튼은 scale(0.97), 스태거는 30~80ms)이라는 점이 차별점이다.
README의 문장이 이 레포의 정체성을 요약한다: "AI는 전문성을 대체하지 않는다 — 전문성에서 뽑아낼 수 있는 것을 증폭시킨다." 2026년 TrendShift에 스킬 레포가 줄줄이 오르는 가운데(오늘 토픽 3위가 #AI skills), 범용 엔지니어링 스킬(예: 이미 분석한 mattpocock/skills)과 달리 이 레포는 디자인·모션이라는 좁고 깊은 영역을 판다. "무엇이든 하는 스킬"이 아니라 "한 분야 전문가의 눈"을 파는 것 — 스킬 생태계가 성숙하며 나타나는 전문화 단계의 대표 사례다.
mattpocock/skills(TS·엔지니어링 전반, 오늘 16위)가 "시니어 엔지니어의 습관"이라면, emilkowalski/skills는 "시니어 디자인 엔지니어의 눈"이다. 같은 스킬 포맷·같은 배포 채널(skills.sh)을 쓰지만 파는 전문성이 다르다. VoltAgent/awesome-design-md(오늘 6위, 브랜드 디자인 시스템 모음)와도 결이 다르다 — 그쪽이 "무엇을 그릴지(look)"라면 이쪽은 "어떻게 움직일지(feel)"다.
코드 0줄. 그래서 "스택"은 스킬 파일 포맷과 그것이 다루는 웹 플랫폼 지식이다.
| 층 | 구성 | 설명 |
|---|---|---|
| 포맷 | SKILL.md (YAML frontmatter + Markdown) | Claude Code 등 에이전트가 읽는 표준 스킬 포맷. name·description이 트리거 역할 |
| 배포 | skills.sh · npx skills add | npm처럼 스킬을 설치하는 생태계. 리더보드로 인기 추적 |
| 대상 런타임 | Claude Code, Cursor 등 코딩 에이전트 | 스킬을 로드해 UI 생성·리뷰 시 판단 기준으로 사용 |
| 지식 원천 | emilkowal.ski 아티클 · animations.dev 강의 · WWDC 강연 | 저자 개인 사이트 글, 자신의 강의, 애플 디자인 세션의 증류 |
| 라이선스 | MIT (2026) | 자유롭게 포크·수정 가능 |
| 영역 | 구체 기술 |
|---|---|
| CSS 모션 | transition vs @keyframes, @starting-style, cubic-bezier 커스텀 커브, clip-path: inset(), 3D transform |
| JS 모션 | 스프링 물리(Motion/Framer Motion), WAAPI(element.animate), Pointer Events + setPointerCapture |
| 성능 | GPU 합성(transform/opacity만), 메인스레드 vs 컴포지터, CSS 변수 재계산 폭풍, will-change |
| 제스처 | 속도 기반 dismiss, 러버밴딩, 모멘텀 투영, 멀티터치 보호 |
| 접근성 | prefers-reduced-motion · prefers-reduced-transparency · (hover:hover) and (pointer:fine) 게이팅 |
| 재질·타이포 | backdrop-filter 반투명 재질, optical sizing·tracking·leading (apple-design) |
description이 "언제 이 스킬을 꺼내 쓸지"를 결정하는 라우팅 신호가 되고, 본문이 실제 행동 지침이 된다. 함수가 아니라 "읽고 따르는 매뉴얼"에 가깝다.스킬 4종의 역할 분담과, 마크다운으로 "행동"을 설계하는 패턴들.
emil-design-eng와 review-animations는 리뷰 결과를 반드시 Before/After/Why 마크다운 표로 내게 한다. 흥미로운 건 방식이다 — 옳은 예시만 주는 게 아니라, 에이전트가 실제로 자주 저지르는 "틀린 포맷"(Before:/After:를 줄줄이 나열)을 명시하고 "절대 이렇게 하지 마라"고 못 박는다. LLM의 나쁜 습관을 예측해 선제 차단하는, 스킬 작성의 모범 기법이다.
review-animations는 리뷰를 감(感)이 아니라 구조로 만든다:
| 층 | 내용 | 예 |
|---|---|---|
| 10대 비타협 기준 | 모든 diff가 측정되는 원칙. 위반 = finding | "정당화된 모션", "빈도 적합성", "sub-300ms", "GPU 속성만" |
| 즉시 플래그 트리거 | 보이면 무조건 지적하는 패턴 목록 | transition: all, scale(0) 등장, 키보드 액션 애니메이션 |
| 교정 우선순위 9단계 | 수정 제안 시 앞 단계를 우선 | 1. 삭제 → 2. 축소 → 3. easing 교체 → … → 9. 접근성·조화 |
마지막 판정은 Block 또는 Approve로 이분화되고, "승인은 기본값이 아니라 획득하는 것"이라는 공격적 리뷰 자세가 frontmatter부터 명시된다(disable-model-invocation: true — 에이전트가 임의로 켜지 못하고 사용자가 명시적으로 불러야 하는 스킬).
review-animations는 SKILL.md(판단 방법, 112줄)와 STANDARDS.md(정확한 수치·커브·인용용 카탈로그, 188줄)를 분리한다. "finding에 정확한 값이 필요할 때만 STANDARDS.md를 로드하라" — 컨텍스트를 아끼는 점진적 공개(progressive disclosure) 패턴이다. 판단 로직은 항상 메모리에, 참조 테이블은 필요할 때만.
animation-vocabulary는 보통 사전과 방향이 반대다. 사용자가 "팝오버가 버튼에서 자라나는 그거"라고 느낌으로 묘사하면 → Origin-aware animation이라는 정확한 용어를 돌려준다. 목적이 명확하다: 올바른 단어를 알아야 AI에게 원하는 애니메이션을 정확히 시킬 수 있다. "용어집을 그대로 인용하라(패러프레이즈 금지)", "근접 용어는 대비해서 보여줘라", "없으면 없다고 말해라" 같은 지침이 환각을 차단한다.
페르소나+판단 기준 주입(emil-design-eng), 엄격한 심사 절차(review-animations), 조회 전용 레퍼런스(animation-vocabulary), 원론 지식 증류(apple-design). 스킬을 직접 만들려는 사람에게 이 레포는 4가지 아키타입의 실물 견본이다.
전체 344KB, 마크다운 6개 파일. 작지만 밀도가 높다.
합계 1,481줄. 참고로 emil-design-eng 하나가 전체의 46%를 차지하는 본체이고, 나머지 셋은 특화 위성이다. 각 SKILL.md의 frontmatter description은 단순 소개가 아니라 에이전트가 "언제 이 스킬을 로드할지" 판단하는 라우팅 규칙이라, 유독 길고 구체적이다(특히 apple-design과 animation-vocabulary).
이 레포에서 배울 것은 두 겹이다: ① 모션 크래프트 그 자체, ② 전문성을 스킬로 인코딩하는 법.
emil-design-eng의 뼈대. 코드보다 먼저 답해야 하는 질문 순서가 정해져 있다:
| 질문 | 판단 기준 |
|---|---|
| 1. 애니메이션해야 하나? | 하루 100회+ 보는 것(키보드 단축키, 커맨드 팔레트)은 절대 금지. 수십 회는 최소화, 가끔(모달·토스트)은 표준, 드물면(온보딩) 딜라이트 허용 |
| 2. 목적이 뭔가? | 공간 일관성 / 상태 표시 / 설명 / 피드백 / 급변 방지 중 하나여야. "멋있어서"는 자주 보이는 요소에선 무효 |
| 3. 어떤 easing? | 등장·퇴장 → ease-out · 화면 내 이동 → ease-in-out · 호버·색 → ease · 등속(마퀴) → linear. ease-in은 UI에 절대 금지 |
| 4. 얼마나 빨리? | 버튼 피드백 100~160ms · 툴팁 125~200ms · 드롭다운 150~250ms · 모달 200~500ms. UI는 300ms 미만 |
ease-in은 느리게 시작한다 — 그런데 사용자가 가장 집중해서 보는 순간이 바로 시작 지점이다. 같은 300ms라도 ease-in 드롭다운이 ease-out보다 체감상 훨씬 느리다. "지각된 성능(perceived performance)"이 실제 성능만큼 중요하다는 것 — 빠르게 도는 스피너가 같은 로딩 시간을 더 짧게 느끼게 하는 것과 같은 원리다.
수백만 명이 쓰는 컴포넌트에서 검증된 규칙: 아무것도 무에서 나타나지 않는다(scale(0) 금지 → scale(0.95)+opacity), 팝오버는 트리거에서 자라난다(transform-origin을 트리거로; 단 모달은 중앙 예외), 누를 수 있는 것은 눌린 티가 난다(:active에 scale(0.97)), 어색한 크로스페이드는 blur 2px로 봉합한다(두 상태가 겹쳐 보이는 걸 하나의 변형으로 착시).
가장 값진 실무 지식 중 하나. Motion의 단축 속성(x, y, scale)은 메인 스레드의 rAF로 돌아서 페이지 로딩 중엔 프레임이 떨어진다. 전체 transform 문자열을 넘겨야 하드웨어 가속된다. 실제로 Vercel 대시보드 탭 애니메이션이 이 문제로 프레임 드랍 → CSS 애니메이션(오프 메인스레드)으로 교체해 해결했다는 실전 사례가 실려 있다. 같은 맥락: 부모의 CSS 변수를 갱신하면 모든 자식이 스타일 재계산(recalc storm) — 요소의 transform을 직접 만져라.
애플 Designing Fluid Interfaces(WWDC 2018)의 웹 번역. 핵심 원칙은 인터럽트 가능성("생각과 제스처는 병렬로 일어난다") — 닫히는 모달을 다시 잡으면 손가락을 따라와야지, 다 닫힌 뒤 다시 열리면 안 된다. 구체 기법: 릴리즈 속도를 스프링 초기 속도로 넘기는 velocity handoff, 릴리즈 지점이 아니라 모멘텀이 향하는 지점으로 스냅하는 투영 함수((v/1000)·d/(1−d), d≈0.998 — 교과서의 v²/2a가 아니라 애플이 실제로 쓰는 지수 감쇠형), 경계에서 점점 저항하는 러버밴딩 공식까지 코드로 제공된다.
스킬을 만들려는 사람에게 이 레포가 가르치는 것: (a) 모호한 조언("좋은 easing을 써라")이 아니라 결정 트리와 수치 표로 쓸 것, (b) 에이전트의 예상 실수를 "틀린 예"로 명시해 선제 차단할 것, (c) 판단 로직과 참조 수치를 분리(progressive disclosure)할 것, (d) 심사 스킬엔 명시적 판정 기준(Block/Approve)과 교정 우선순위를 줄 것, (e) 페르소나("당신은 잔혹한 안목의 시니어 모션 리뷰어다")로 기본 자세를 고정할 것.
사실상 없다 — 이 레포의 미덕이다.
| 항목 | 요구 |
|---|---|
| 설치 | npx skills@latest add emilkowalski/skills (Node.js만 있으면 됨) 또는 SKILL.md를 에이전트 스킬 폴더에 복사 |
| 런타임 | 스킬을 지원하는 코딩 에이전트 (Claude Code, Cursor 등) |
| 실습 환경 | 브라우저 + DevTools (Animations 패널). 제스처 실습은 실기기 폰 권장 — 시뮬레이터보다 실제 하드웨어 |
| 선택 | Motion(Framer Motion) 설치된 React 프로젝트 — 스프링 예제 실습용 |
스킬을 "읽는" 데서 끝내지 말고, 돌려보고 내 것으로 만들기.
npx skills@latest add emilkowalski/skills로 설치한 뒤, 애니메이션이 있는 내 프로젝트에서 review-animations를 명시적으로 호출해 리뷰를 받아본다. Before/After/Why 표에서 transition: all·ease-in·scale(0) 같은 트리거가 몇 개나 걸리는지 세어보고, Block인지 Approve인지 확인한다.
드롭다운 하나를 ease-in 300ms과 cubic-bezier(0.23, 1, 0.32, 1) 200ms(스킬의 강한 ease-out) 두 버전으로 만들어 나란히 비교한다. DevTools로 5배 슬로모션 재생도 해본다 — "같은 시간인데 왜 체감이 다른가"를 눈으로 확인하는 게 목적.
스킬의 clip-path 패턴대로: 빨간 오버레이에 clip-path: inset(0 100% 0 0) → :active에서 2초 linear로 inset(0 0 0 0), 릴리즈 시 200ms ease-out으로 스냅백, 버튼엔 scale(0.97). 비대칭 타이밍(누름은 신중하게 느리게, 응답은 빠르게)을 체득하는 최고의 미니 과제.
토스트나 카드에 드래그 dismiss를 구현하되, 거리 임계값만이 아니라 velocity = |거리|/시간 > 0.11이면 짧은 플릭으로도 dismiss되게 한다. 릴리즈 속도를 스프링 초기 속도로 넘겨(velocity handoff) 드래그→애니메이션 이음새가 사라지는 것까지 확인하면 합격.
이 레포의 4가지 아키타입 중 하나를 골라 내 도메인의 스킬을 작성한다(예: 백엔드라면 "API 에러 응답 심사 스킬"). review-animations 구조를 그대로 빌려 — 비타협 기준 5개, 즉시 플래그 트리거, Before/After/Why 표, Block/Approve 판정 — 실제 에이전트에 물려 내 코드에 돌려본다. 스킬 작성 패턴이 몸에 붙는다.
모션 크래프트를 체계적으로 쌓는 4주 코스.
transition vs @keyframes의 차이(인터럽트 가능성!), easing 4종의 느낌, @starting-style로 JS 없는 enter 애니메이션을 익힌다. emil-design-eng의 의사결정 프레임워크 4질문을 외운다. 목표: 아무 UI나 보고 "이건 애니메이션하면 안 되는 요소"를 골라낼 수 있게 되기.
translateY(100%)가 왜 px보다 나은지(자기 크기 기준), transform-origin, 3D transform, clip-path: inset()의 4가지 활용(리빌·hold-to-delete·탭 색전환·비교 슬라이더)을 실습한다. 목표: 실습 과제 3번을 스킬 안 보고 다시 만들기.
스프링 물리(damping·response, 애플의 2-파라미터 사고법), velocity handoff, 모멘텀 투영, 러버밴딩을 apple-design 스킬로 공부하고 Motion 라이브러리로 구현한다. Vaul·Sonner 소스를 열어 실제 적용을 확인한다. 목표: 실습 과제 4번 완성.
GPU 합성 원리, Framer Motion 단축 속성 함정, CSS 변수 recalc storm을 DevTools Performance 패널로 실측한다. prefers-reduced-motion 3종 신호를 컴포넌트에 내장한다. 마지막으로 실습 과제 5번(내 도메인 스킬 만들기)으로 마무리. 목표: 스킬의 소비자에서 생산자로.
이 레포를 소화하면 animations.dev 강의, Sonner/Vaul 소스코드, 애플 WWDC 디자인 세션이 훨씬 잘 읽힌다. 그리고 스킬 생태계 쪽으로는 anthropics/skills(공식 표준), mattpocock/skills(엔지니어링), obra/superpowers(방법론)와 비교하며 읽으면 "좋은 스킬이란 무엇인가"에 대한 자기 기준이 생긴다.
문서에 나온 용어를 한자리에.
cubic-bezier(0.23, 1, 0.32, 1))를 권한다. easing.dev에서 고른다.--radix-popover-content-transform-origin 변수 활용). 모달만 중앙 예외.useEffect+data-mounted 패턴을 대체하는 현대적 enter 애니메이션 기법.(v/1000)·d/(1−d)). 플릭이 "던지는 느낌"이 나는 이유.transform·opacity만 애니메이션하면 레이아웃·페인트를 건너뛰고 GPU가 처리해 메인 스레드가 바빠도 부드럽다. width·height·margin 애니메이션은 셋 다 다시 해서 jank의 원인.element.animate() — JS의 제어력과 CSS의 성능(하드웨어 가속·인터럽트 가능)을 동시에 주는 브라우저 내장 API. 라이브러리 없이 프로그래밍 방식 애니메이션이 필요할 때.npx skills add owner/repo로 npm처럼 설치하고, 리더보드로 인기 스킬을 추적한다.더 깊이 파고들 곳.