1. 그 애니메이션, 왜 항상 어색할까

“이거 좀 더 부드럽게 해주세요.”

디자이너와 프론트엔드 개발자 사이에서 가장 많이 오가는 말일 것이다. 디자이너는 Figma에서 Smart Animate로 매끄러운 프로토타입을 만들고, 개발자는 그걸 보고 CSS transition을 작성한다. 그런데 결과물은 늘 다르다. 프로토타입에서는 “탄력 있게 튀어오르는” 버튼이었는데, 실제 구현에서는 그냥 크기가 변하는 버튼이 된다.

왜 이런 일이 반복될까? 근본 원인은 세 가지다.

이 간극은 디자인 시스템이 성숙해도 쉽게 메워지지 않는다. 색상과 타이포그래피는 디자인 토큰으로 표준화되었지만, 애니메이션만큼은 여전히 “감”으로 전달되고 “감”으로 구현되는 영역으로 남아 있다.

2. Pencil Creator가 제안하는 접근법

Pencil Creator는 이 문제를 풀기 위해 조금 독특한 방법을 택했다. “Animation-First Design” — 정적 디자인보다 애니메이션을 먼저 설계한다는 원칙이다.

솔직히 말하면, 대단한 플랫폼이라기보다는 하나의 실험적인 워크플로우에 가깝다. 하지만 그 실험이 꽤 흥미로운 결과를 만들어내고 있어서 소개하고자 한다.

2.1 핵심 아이디어: WPF 애니메이션을 공통 언어로

Pencil Creator는 WPF(Windows Presentation Foundation)의 XAML Storyboard를 애니메이션 정의의 기준점으로 사용한다.

<DoubleAnimation
  Storyboard.TargetProperty="(UIElement.RenderTransform).(TranslateTransform.Y)"
  To="-18"
  Duration="0:0:0.2"
  EasingFunction="{StaticResource QuadraticEase}" />

“왜 WPF?”라고 물을 수 있다. WPF의 Storyboard는 애니메이션의 대상 속성(TargetProperty), 지속 시간(Duration), 이징 함수(EasingFunction), 반복 동작(RepeatBehavior)을 명시적으로 선언한다. 디자이너의 “톡톡 튀는 느낌”을 ElasticEase라는 이름과 수치로 고정시킬 수 있는 것이다.

이 XAML 정의가 Pencil 디자인 파일(.pen)의 시각적 카드로 변환되고, 최종적으로 웹의 CSS/JS 애니메이션으로 구현된다.

2.2 3단계 파이프라인: 조사 → 설계 → 구현

Pencil Creator의 워크플로우는 세 가지 케이스(Case)로 나뉜다.

이 세 단계가 분리되어 있다는 점이 중요하다. Case A에서 만든 애니메이션 카드는 여러 프로젝트에서 재사용된다. 특정 프로젝트를 위해 만들고 버리는 것이 아니라, 라이브러리처럼 계속 쌓인다.

2.3 재사용 가능한 애니메이션 라이브러리

현재 wpf-animation.pen 파일에는 12개 카테고리, 40개 이상의 애니메이션 기법 카드가 정리되어 있다.

각 카드에는 Before → After 시각 미리보기, XAML 코드 스니펫, 적용 대상 속성 설명이 포함된다. 디자이너는 시각적으로 어떤 움직임인지 확인하고, 개발자는 정확한 수치를 코드에서 가져갈 수 있다.

2.4 룩앤필 + 애니메이션, 분리하되 함께

Pencil Creator에서 프로젝트 디자인(Case B)을 하면, 두 가지 산출물이 나온다.

1. 정적 디자인: 화면별 레이아웃, 색상, 타이포그래피 (일반적인 디자인 시안)
2. 애니메이션 가이드: 어떤 요소에 어떤 애니메이션을 적용할지, WPF 기법과 함께 명시

이 둘이 물리적으로 분리되어 있어서, 룩앤필을 변경해도 애니메이션 정의가 깨지지 않고, 그 반대도 마찬가지다. 디자인 시스템이 진화할 때 애니메이션만 독립적으로 업데이트할 수 있다는 뜻이다.

2.5 하네스가 자동으로 품질을 체크한다

Pencil Creator에는 디자인 하네스가 내장되어 있다. 즉, 하네스란 AI 에이전트의 행동을 구조화하는 사전 설정 체계인데, 여기서는 디자인 작업의 품질을 자동으로 평가하는 역할을 한다.

각 케이스마다 3축 100점 평가가 자동으로 실행된다.

솔직히 지금 단계에서 이 평가가 완벽하다고 말하기는 어렵다. 하지만 “자동 검수가 존재한다”는 것 자체가 의미 있다. 평가 규칙이 마음에 들지 않으면 제거하거나 수정할 수 있고, 프로젝트가 성숙해지면 규칙도 함께 진화한다. v2.0에서 v2.2까지 세 번의 하네스 업그레이드가 이미 이루어졌다 — “.pen 파일만으로는 정밀도가 부족하다”는 관찰에서 “.pen + .xaml 이중 참조 필수”로 기준이 강화된 것이 대표적인 예다.

2.6 GitHub Pages에 딸각

완성된 웹 산출물은 태그 하나로 GitHub Pages에 배포된다.

git tag v1.0.0
git push origin v1.0.0
# 1~2분 후 → https://psmon.github.io/pencil-creator/ 에서 확인

push 할 때마다 배포되는 것이 아니라, 태그를 찍을 때만 배포된다. 개발 중에는 자유롭게 커밋하고, 준비가 되면 태그 한 번으로 공개한다. 현재 두 개의 데모가 라이브로 동작 중이다.

• Sample 00: 벚꽃 파티클 애니메이션 놀이터 (4개 데모, 인터랙티브 슬라이더)
• Sample 01: 사계절 WPF 쇼케이스 (12 카테고리, 36개 기법 전체 데모)

Pencil Creator 랜딩 페이지 — 두 개의 데모 카드가 디자이너 친화적인 크림톤 UI로 배치되어 있다.

3. 실제로 어떻게 보이나

백 마디 설명보다 한 번 보는 것이 낫다. Four Seasons 데모 페이지에서 실제로 구현된 애니메이션 일부를 소개한다.

3.1 데모 구성: 사계절 테마

각 데모에는 WPF XAML 원본 코드가 함께 표시되어, “이 웹 애니메이션이 어떤 WPF 정의에서 변환되었는지”를 바로 확인할 수 있다. 일부 데모에는 인터랙티브 슬라이더가 있어서, 꽃잎 개수나 낙하 속도 같은 파라미터를 실시간으로 조절해 볼 수 있다.

3.2 Sample 00: 벚꽃 파티클 놀이터

Cherry Blossom Petal Fall 데모. 슬라이더로 꽃잎 개수, 낙하 속도, 바람 표류를 실시간 조절할 수 있다. 하단에는 이 애니메이션의 원본 WPF XAML 코드가 함께 표시된다. QuadraticEase로 자연스러운 가속 낙하를, RotateTransform으로 회전하는 꽃잎을 구현했다.

3.3 Sample 01: 사계절 WPF 쇼케이스

Four Seasons Animation Showcase 히어로 영역. 보라빛 그라데이션 배경 자체가 ColorAnimation + GradientStop으로 구현된 WPF 기법이다. Spring, Summer, Autumn, Winter 네 계절 버튼으로 36개 데모를 탐색할 수 있다.

Summer 섹션의 인터랙티브 UI 컴포넌트들. Floating Label, ComboBox, Toggle Switch 같은 실무에서 바로 쓸 수 있는 데이터 입력 컨트롤부터, Snackbar Toast, Progress Bar, Badge Counter 같은 피드백 컴포넌트, Ripple Button, Accordion 같은 인터랙티브 요소까지 — 각 카드 하단에 WPF 애니메이션 속성이 한 줄로 요약되어 있어 디자이너와 개발자가 동일한 언어로 소통할 수 있다.

3.4 WPF → Web 변환의 실제

WPF의 애니메이션 속성이 웹에서 어떻게 대응되는지, 몇 가지 예를 보면:

모든 구현은 외부 라이브러리 없이 순수 HTML/CSS/JS로 이루어진다. 바닐라로 작성되어 있어 어떤 프레임워크에든 통합할 수 있다.

4. 남은 과제 — 솔직하게

여기서 겸손해질 필요가 있다. Pencil Creator는 아직 많은 것이 부족하다.

4.1 디자인 견습생의 고백

이 프로젝트를 만든 사람은 디자인 전문가가 아니다. “디자인 못 알못”에서 시작해서 WPF 애니메이션 조사를 3회차 반복한 정도 — 말하자면 견습생 수준이다. 12개 카테고리 40개 카드라고 했지만, 전문 모션 디자이너가 보면 아직 기초적인 수준에 머물러 있을 것이다.

4.2 더 전문화된 소스가 필요하다

현재 WPF XAML을 기준점으로 삼고 있지만, 실무에서는 더 다양한 소스가 필요하다.

• Lottie/Rive 같은 전문 애니메이션 포맷과의 연동
• 동영상이나 GIF 레퍼런스에서 애니메이션 파라미터를 추출하는 방법
• Scroll-driven Animation, View Transition API 같은 최신 웹 표준 반영
• 접근성(a11y) 관점의 reduced-motion 지원

4.3 그래도 이 정도는 양산할 수 있다

부족한 점이 많지만, 한 가지는 자신 있게 말할 수 있다. 이 파이프라인을 통하면, 견습생 수준의 디자인 역량으로도 꽤 괜찮은 애니메이션 데모를 일관된 품질로 만들어낼 수 있다.

비결은 파이프라인 자체에 있다. 조사(Case A)에서 축적된 라이브러리가 설계(Case B)의 기반이 되고, 하네스의 자동 평가가 “이건 좀 부족하네”를 알려준다. 개인의 디자인 감각에만 의존하지 않고, 시스템이 품질을 보장하는 구조인 셈이다.

RPG 레벨 시스템까지 붙어 있어서(현재 Lv.24 “키보드 워리어”), 더 나은 점수를 받으려는 동기부여가 자연스럽게 생긴다. 지금 애니메이션이 약하다는 것을 알고 있지만, 이 시스템 위에서 계속 쌓아가면 언젠가는 — 감히 말하건대 — 꽤 위대한 라이브러리가 될 수 있지 않을까.

5. 시작하기

관심이 생겼다면, 시작은 간단하다.

# 1. 리포지토리 클론
git clone https://github.com/psmon/pencil-creator.git
cd pencil-creator

# 2. Claude Code에서 열기
claude

# 3. 애니메이션 조사 시작
> "wpf-템플릿조사 후 템플릿보강해"   # Case A

# 4. 프로젝트에 적용
> "wpf-animation 이펙트를 참고해 내 프로젝트 디자인해줘"   # Case B

# 5. 웹으로 구현
> "펜슬 참고해서 HTML 만들어줘"   # Case W

# 6. 배포
git tag v1.0.0 && git push origin v1.0.0   # GitHub Pages 자동 배포

라이브 데모를 먼저 둘러보고 싶다면:

• 벚꽃 파티클 놀이터 — 인터랙티브 슬라이더로 파라미터를 조절해 보세요
• 사계절 쇼케이스 — 36개 애니메이션 기법을 한 페이지에서 확인

참고 자료

1. psmon/pencil-creator — GitHub 리포지토리 (MIT License, 2026-03)
2. 5 Steps for Including Motion Design in Your System — designsystems.com
3. Including Animation In Your Design System — Smashing Magazine
4. Material Design 3 Motion Tokens — Google, 2026
5. 왜 디자이너와 개발자의 협업은 이토록 힘이 들까? — Brunch
6. Animation/Motion Design Tokens — Oscar Gonzalez, Medium