한줄 요약 — 디자이너가 상상한 애니메이션이 개발자의 코드를 만나면 왜 어색해질까? Pencil Creator는 WPF 애니메이션 정의를 Pencil 디자인 파일과 연결하여, 디자이너의 의도가 코드로 정확히 전달되는 파이프라인을 제공한다. 아직 걸음마 단계이지만, “재사용 가능한 애니메이션 설계 시스템”이라는 방향성만은 분명하다. 대상 독자: 디자이너 & 프론트엔드 개발자 | 작성 기준: 2026-03 | GitHub | Live Demo |
“이거 좀 더 부드럽게 해주세요.”
디자이너와 프론트엔드 개발자 사이에서 가장 많이 오가는 말일 것이다. 디자이너는 Figma에서 Smart Animate로 매끄러운 프로토타입을 만들고, 개발자는 그걸 보고 CSS transition을 작성한다. 그런데 결과물은 늘 다르다. 프로토타입에서는 “탄력 있게 튀어오르는” 버튼이었는데, 실제 구현에서는 그냥 크기가 변하는 버튼이 된다.
왜 이런 일이 반복될까? 근본 원인은 세 가지다.
| 문제 | 디자이너 관점 | 개발자 관점 |
|---|---|---|
| 수치 부재 | “톡톡 튀는 느낌으로” | “cubic-bezier(?, ?, ?, ?) 값이 뭐죠?” |
| 도구 불일치 | Figma의 easing preset은 CSS preset과 다름 | Figma Code 패널은 색상/간격만 내보내고 애니메이션 로직은 빠짐 |
| 어휘 격차 | “스냅피하게”, “바운시한 진입” | “키프레임 보간, 인터폴레이터, 렌더 성능” |
이 간극은 디자인 시스템이 성숙해도 쉽게 메워지지 않는다. 색상과 타이포그래피는 디자인 토큰으로 표준화되었지만, 애니메이션만큼은 여전히 “감”으로 전달되고 “감”으로 구현되는 영역으로 남아 있다.
Motion Token이란? Material Design 3에서 도입된 개념으로, 색상 토큰처럼 애니메이션의 지속 시간(duration)과 이징 곡선(easing)을 이름 있는 값으로 정의하는 것이다. 예: |
Pencil Creator는 이 문제를 풀기 위해 조금 독특한 방법을 택했다. “Animation-First Design” — 정적 디자인보다 애니메이션을 먼저 설계한다는 원칙이다.
솔직히 말하면, 대단한 플랫폼이라기보다는 하나의 실험적인 워크플로우에 가깝다. 하지만 그 실험이 꽤 흥미로운 결과를 만들어내고 있어서 소개하고자 한다.
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 애니메이션으로 구현된다.
Pencil Creator의 워크플로우는 세 가지 케이스(Case)로 나뉜다.
| 케이스 | 입력 | 출력 | 하는 일 |
|---|---|---|---|
| Case A 템플릿 보강 | 웹에서 WPF 예제 조사 | 애니메이션 카드 + .xaml 파일 | 새로운 애니메이션 기법을 조사하고 재사용 가능한 카드로 만든다 |
| Case B 프로젝트 설계 | 템플릿 카드 참조 | 정적 디자인 + 애니메이션 가이드 | 실제 프로젝트에 어떤 기법을 어디에 적용할지 설계한다 |
| Case W 웹 구현 | .pen 파일 + .xaml 참조 | HTML/CSS/JS | 설계된 애니메이션을 웹으로 변환한다 |
이 세 단계가 분리되어 있다는 점이 중요하다. Case A에서 만든 애니메이션 카드는 여러 프로젝트에서 재사용된다. 특정 프로젝트를 위해 만들고 버리는 것이 아니라, 라이브러리처럼 계속 쌓인다.
현재 wpf-animation.pen 파일에는 12개 카테고리, 40개 이상의 애니메이션 기법 카드가 정리되어 있다.
| 카테고리 | 예시 기법 | 활용 장면 |
|---|---|---|
| 데이터 입력 컨트롤 | Floating Label, Toggle Switch | 폼 입력 UX |
| 피드백 & 알림 | Snackbar Toast, Progress Bar | 사용자 피드백 |
| 내비게이션 | Page Transition, Tab Slide, Hamburger Morph | 화면 전환 |
| 장식 & 배경 | Gradient Background, Floating Particles | 시각적 풍부함 |
| 3D 변환 | Flip Card, Morphing Shape, Elastic Spring | 인터랙티브 요소 |
| 텍스트 & 순차 | Typewriter, Marquee, Staggered List | 콘텐츠 등장 |
| 인터랙티브 UI | Ripple Button, Accordion, Tooltip | 사용자 인터랙션 |
| 데이터 시각화 | Skeleton Shimmer, Circular Progress | 로딩 & 차트 |
| 자연 파티클 | Cherry Blossom Fall, Petal Scatter | 감성적 효과 |
각 카드에는 Before → After 시각 미리보기, XAML 코드 스니펫, 적용 대상 속성 설명이 포함된다. 디자이너는 시각적으로 어떤 움직임인지 확인하고, 개발자는 정확한 수치를 코드에서 가져갈 수 있다.
Pencil Creator에서 프로젝트 디자인(Case B)을 하면, 두 가지 산출물이 나온다.
이 둘이 물리적으로 분리되어 있어서, 룩앤필을 변경해도 애니메이션 정의가 깨지지 않고, 그 반대도 마찬가지다. 디자인 시스템이 진화할 때 애니메이션만 독립적으로 업데이트할 수 있다는 뜻이다.
Pencil Creator에는 디자인 하네스가 내장되어 있다. 즉, 하네스란 AI 에이전트의 행동을 구조화하는 사전 설정 체계인데, 여기서는 디자인 작업의 품질을 자동으로 평가하는 역할을 한다.
각 케이스마다 3축 100점 평가가 자동으로 실행된다.
| 케이스 | 축 1 | 축 2 | 축 3 |
|---|---|---|---|
| Case A (조사) | 리서치 신규성 (35점) | 시각화 표현력 (35점) | 기술 메타 완결성 (30점) |
| Case B (설계) | 요구사항 커버리지 (35점) | 애니메이션 가이드 풍부성 (35점) | 디자인 품질 & 분리 (30점) |
| Case W (구현) | 디자인 커버리지 (35점) | 애니메이션 충실도 (35점) | 독창적 확장 (30점) |
솔직히 지금 단계에서 이 평가가 완벽하다고 말하기는 어렵다. 하지만 “자동 검수가 존재한다”는 것 자체가 의미 있다. 평가 규칙이 마음에 들지 않으면 제거하거나 수정할 수 있고, 프로젝트가 성숙해지면 규칙도 함께 진화한다. v2.0에서 v2.2까지 세 번의 하네스 업그레이드가 이미 이루어졌다 — “.pen 파일만으로는 정밀도가 부족하다”는 관찰에서 “.pen + .xaml 이중 참조 필수”로 기준이 강화된 것이 대표적인 예다.
완성된 웹 산출물은 태그 하나로 GitHub Pages에 배포된다.
git tag v1.0.0 git push origin v1.0.0 # 1~2분 후 → https://psmon.github.io/pencil-creator/ 에서 확인 |
push 할 때마다 배포되는 것이 아니라, 태그를 찍을 때만 배포된다. 개발 중에는 자유롭게 커밋하고, 준비가 되면 태그 한 번으로 공개한다. 현재 두 개의 데모가 라이브로 동작 중이다.
Pencil Creator 랜딩 페이지 — 두 개의 데모 카드가 디자이너 친화적인 크림톤 UI로 배치되어 있다.
백 마디 설명보다 한 번 보는 것이 낫다. Four Seasons 데모 페이지에서 실제로 구현된 애니메이션 일부를 소개한다.
| 계절 | 카테고리 | 대표 기법 |
|---|---|---|
| 봄 | 자연 파티클, 장식 효과 | Cherry Blossom Fall, Floating Particles, Pulsing Glow |
| 여름 | 데이터 입력, 피드백, 인터랙티브 | Floating Label, Snackbar Toast, Ripple Button |
| 가을 | 내비게이션, 경로, 데이터 시각화 | Page Transition, Parallax Layers, Skeleton Shimmer |
| 겨울 | 3D 변환, 텍스트, 축제 | Flip Card 3D, Typewriter Text, Confetti Burst |
각 데모에는 WPF XAML 원본 코드가 함께 표시되어, “이 웹 애니메이션이 어떤 WPF 정의에서 변환되었는지”를 바로 확인할 수 있다. 일부 데모에는 인터랙티브 슬라이더가 있어서, 꽃잎 개수나 낙하 속도 같은 파라미터를 실시간으로 조절해 볼 수 있다.
Cherry Blossom Petal Fall 데모. 슬라이더로 꽃잎 개수, 낙하 속도, 바람 표류를 실시간 조절할 수 있다. 하단에는 이 애니메이션의 원본 WPF XAML 코드가 함께 표시된다. QuadraticEase로 자연스러운 가속 낙하를, RotateTransform으로 회전하는 꽃잎을 구현했다.
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 애니메이션 속성이 한 줄로 요약되어 있어 디자이너와 개발자가 동일한 언어로 소통할 수 있다.
WPF의 애니메이션 속성이 웹에서 어떻게 대응되는지, 몇 가지 예를 보면:
| WPF | Web 구현 |
|---|---|
DoubleAnimation TargetProperty="Y" | CSS transform: translateY() |
ScaleTransform | CSS transform: scale(x, y) |
RotateTransform | CSS transform: rotate(deg) |
SineEase EaseInOut | CSS ease-in-out |
ElasticEase | cubic-bezier(0.175, 0.885, 0.32, 1.275) |
RepeatBehavior="Forever" | CSS animation-iteration-count: infinite |
| Canvas 파티클 시스템 | requestAnimationFrame + Canvas API |
모든 구현은 외부 라이브러리 없이 순수 HTML/CSS/JS로 이루어진다. 바닐라로 작성되어 있어 어떤 프레임워크에든 통합할 수 있다.
여기서 겸손해질 필요가 있다. Pencil Creator는 아직 많은 것이 부족하다.
이 프로젝트를 만든 사람은 디자인 전문가가 아니다. “디자인 못 알못”에서 시작해서 WPF 애니메이션 조사를 3회차 반복한 정도 — 말하자면 견습생 수준이다. 12개 카테고리 40개 카드라고 했지만, 전문 모션 디자이너가 보면 아직 기초적인 수준에 머물러 있을 것이다.
현재 WPF XAML을 기준점으로 삼고 있지만, 실무에서는 더 다양한 소스가 필요하다.
부족한 점이 많지만, 한 가지는 자신 있게 말할 수 있다. 이 파이프라인을 통하면, 견습생 수준의 디자인 역량으로도 꽤 괜찮은 애니메이션 데모를 일관된 품질로 만들어낼 수 있다.
비결은 파이프라인 자체에 있다. 조사(Case A)에서 축적된 라이브러리가 설계(Case B)의 기반이 되고, 하네스의 자동 평가가 “이건 좀 부족하네”를 알려준다. 개인의 디자인 감각에만 의존하지 않고, 시스템이 품질을 보장하는 구조인 셈이다.
RPG 레벨 시스템까지 붙어 있어서(현재 Lv.24 “키보드 워리어”), 더 나은 점수를 받으려는 동기부여가 자연스럽게 생긴다. 지금 애니메이션이 약하다는 것을 알고 있지만, 이 시스템 위에서 계속 쌓아가면 언젠가는 — 감히 말하건대 — 꽤 위대한 라이브러리가 될 수 있지 않을까.
관심이 생겼다면, 시작은 간단하다.
# 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 자동 배포 |
라이브 데모를 먼저 둘러보고 싶다면:
이 글은 글작성 하네스 AI를 통해 자동 작성되었습니다. 작성 도구: Claude Code (Opus 4.6) + BloomLabs Content Harness v0.10.0 |
빌드 배포도 귀찮아 이미자동화해둠( 이소스를 받으면 스킬에 포함되었으니 github이용하면 활용가능) - CICD라 불리는 영역인데..이것을 CDPR 이라 부르기로함
사펑같은 느낌 만들어주기도 해서 이 자동화를 그냥 CDPR이라고 부르기로함 ..다음에는 CDPR수행 한방으로 묶기가능(나눠하기 조차 입력하기 귀찮은경우)
하네스 1.0.4가 만든 퀄리티의 평가는 독자에게