100 Days of UI Challenge: 컴포넌트와 모션이 디자인 시스템이 되기까지

젠인 토우지의 나오야를 향한 집착이 가히 광적이지만

100 Days of UI Challenge: 컴포넌트와 모션이 디자인 시스템이 되기까지

프롤로그: 매일 하나의 화면을 만든다는 것

100DaysOfUI를 시작할 때의 목표는 거창한 디자인 시스템을 만드는 일이 아니었다. 매일 하나의 UI 또는 모션 패턴을 골라 직접 만들고, 그 과정에서 손에 익지 않은 인터랙션 감각을 되찾는 것이 먼저였다.

그런데 매일의 결과물을 코드로 남기다 보니 질문이 생겼다.

이 작업은 단순한 일회성 화면인가, 아니면 다음 작업에서도 다시 사용할 수 있는 패턴인가?

이 질문이 쌓이면서 프로젝트는 단순한 챌린지 갤러리에서 실험실로 바뀌었다. 글리치 텍스트, 이미지 조각, 스크롤 속도, 픽셀 전환, 물리 기반 텍스트, 카드 스택과 비디오 마스킹이 각각 독립된 작업으로 시작했지만, 시간이 지나며 공통적인 규칙을 드러냈다.

이 글은 100일 동안의 모든 결과물을 완주 목록처럼 과장해 나열하는 글이 아니다. 현재 코드에 남아 있는 Day별 구현과 _Debug 폴더의 실험, 그리고 이후의 Remotion·Lyrics MV 작업으로 이어진 흐름을 중심으로 정리한 누적 UI·모션 리서치 아카이브다.

1. 왜 시작했나: 녹슨 모션 감각을 다시 깨우기

처음에는 다른 사이트의 구조와 애니메이션을 분석하는 일에서 출발했다. Gatsby 기반 사이트의 Header, Hero, Gallery, Events, Contact 구조를 살펴보고, GSAP ScrollTrigger가 React 생명주기와 어떻게 연결되는지 관찰했다.

레퍼런스를 보는 것만으로는 애니메이션의 감각을 체득하기 어려웠다. 실제로 ref를 잡고, 타이밍을 조정하고, 이미지가 로드되는 시점을 기다리고, 스크롤 입력과 애니메이션을 연결해 봐야 어떤 부분이 디자인 의도이고 어떤 부분이 구현상의 제약인지 구분할 수 있었다.

그래서 100DaysOfUI는 다음 세 가지를 동시에 시험하는 프로젝트가 되었다.

• 매일 새로운 시각 언어를 빠르게 프로토타이핑하기
• React 컴포넌트와 스타일을 독립적으로 격리하기
• 구현된 모션을 다시 사용할 수 있는 규칙과 자산으로 분류하기

처음부터 완성된 디자인 시스템을 설계한 것은 아니다. 먼저 많은 것을 만들고, 반복되는 패턴을 관찰한 다음, 나중에 토큰과 컴포넌트 후보를 추출하는 방식에 가까웠다.

2. 프로젝트 구조: Day별 독립성과 공통 시스템

프로젝트의 기본 구조는 Day별 작업을 서로 격리하는 방향으로 구성되었다.

src/100DaysLogs/
├── Days1to10/       # 현재 확인 가능한 구현 없음
├── Days11to20/
├── Days21to30/
├── Days31to40/
├── Days41to50/
├── Days51to60/
├── Days61to70/
├── Logs/
├── _Debug/          # 변형, 보류, 디버깅, 후속 실험
├── common/          # 공통 레이아웃과 유틸리티
├── Index.tsx
├── base.tsx
├── base.module.scss
└── imageData.ts

각 Day는 고유한 테마와 스타일을 가질 수 있어야 했다. 하나의 페이지에 모든 디자인 규칙을 억지로 맞추는 대신, 실험마다 다른 레이아웃·타이포그래피·인터랙션을 허용했다. 대신 반복되는 부분은 공통화할 수 있도록 여지를 남겼다.

• root layout과 반응형 breakpoint
• viewport와 media query 처리
• 이미지·갤러리 데이터 구조
• typography와 spacing 규칙
• 애니메이션 초기화 및 ref 관리
• 모달과 미디어 렌더링 책임

이 구조는 “모든 화면을 똑같이 만드는 디자인 시스템”보다 “서로 다른 화면에서 재사용 가능한 계약을 발견하는 시스템”에 가깝다.

graph TD
    A[100 Days UI Challenge] --> B[Daily UI Components]
    B --> C[Independent Day Themes]
    B --> D[Shared Utilities]
    B --> E[Motion Experiments]
    E --> F[GSAP and ScrollTrigger]
    E --> G[Canvas and WebGL]
    E --> H[Physics and Pointer Interaction]
    E --> I[Typography Systems]
    C --> J[Figma Storyboard]
    D --> K[Design Tokens]
    E --> L[Remotion Components]
    I --> M[Kinetic Typography]
    G --> N[Texture and Background Tools]
    J --> O[Lyrics MV Design System]
    K --> O
    L --> O
    M --> O
    N --> O

3. 1단계 — 글리치와 이미지 조각: 화면을 깨뜨리는 법

초반의 대표적인 실험은 화면을 안정적으로 보여주는 대신, 화면이 깨지고 분해되고 다시 조립되는 순간을 인터페이스로 사용하는 작업이었다.

Day16 — 텍스트와 이미지 왜곡 화면

텍스트와 이미지에 distortion overlay를 겹치고, useRef로 실제 DOM 요소를 제어했다. React는 화면의 구조와 상태를 담당하고, GSAP은 시간에 따른 변형을 담당하는 식으로 역할을 분리했다.

• 목적: 정적인 화면에 불안정한 시각적 상태 만들기
• 기술 방식: React, GSAP, useRef, SCSS Module
• 도입 방식: 오버레이 레이어와 원본 콘텐츠를 분리한 뒤 timeline으로 변형
• 아키텍처: page → visual container → distortion layer → GSAP timeline
• 아카이브 아이템: 글리치 텍스트, 왜곡 이미지, overlay 패턴

Day18 — “Can you hear me?” 글리치 텍스트

문장을 단순히 흔드는 것이 아니라 여러 단계의 timeline으로 쪼개어 텍스트가 나타나고 흔들리고 사라지는 리듬을 실험했다. 이 작업에서 텍스트는 정보이면서 동시에 화면의 시간축을 표시하는 그래픽 요소가 되었다.

Day19 — Gridbox Image Glitch Move

이미지를 하나의 평면으로 다루지 않고 여러 블록으로 나누어 이동시켰다. 이 패턴은 뒤에 등장하는 픽셀 전환과 텍스처 레이어의 기초가 되었다.

Image
 └── Grid container
      ├── Block 01 → position / opacity / delay
      ├── Block 02 → position / opacity / delay
      └── Block n  → position / opacity / delay

Day20 — My World Is Shattered V2

여러 프레임을 관리하고, random positioning을 적용해 이미지가 화면 안에서 흩어지는 구성을 만들었다. 이 단계에서 중요한 것은 random 값 자체보다, 여러 객체를 하나의 timeline에서 조정하는 방식이었다.

화면을 깨뜨리는 효과는 장식이 아니라, 콘텐츠의 순서와 전환을 설계하는 방법이 될 수 있었다.

4. 2단계 — 스크롤과 갤러리: 입력을 시간축으로 바꾸기

Day21 — Two Flames와 스크롤 기반 Hero

Hero 컴포넌트와 스크롤 영역을 분리하고 GSAP ScrollTrigger를 연결했다. Locomotive Scroll과 함께 사용하면서 부드러운 스크롤과 ScrollTrigger의 기준점이 서로 다르게 계산되는 문제도 경험했다.

이 작업에서 배운 것은 라이브러리를 추가하는 것보다 입력의 주체를 명확히 하는 일이 먼저라는 점이었다.

User scroll
   ↓
Smooth scroll layer
   ↓
ScrollTrigger progress
   ↓
Hero / image / text animation

Day22–24 — Blue Summer Grids

여러 이미지를 데이터 배열로 관리하고 카드형 갤러리로 배치했다. VanillaTilt와 같은 인터랙션을 카드에 연결해, 단순한 이미지 목록을 포인터에 반응하는 공간으로 확장했다.

imageData.ts에는 Day22–24 이미지와 Day28–30 패널, Day58 스냅샷이 하나의 데이터 구조로 정리되어 있다. 이 파일은 작업 결과물을 나중에 다시 조합할 수 있도록 만든 작은 콘텐츠 아카이브이기도 하다.

Day25 — VFX.js 이미지 효과

이미지에 후처리 효과를 적용하는 실험이다. React 컴포넌트가 이미지의 생명주기를 관리하고, VFX.js 인스턴스가 시각 효과를 처리하도록 연결했다. 이 과정은 CSS 효과만으로는 다루기 어려운 이미지 변형과 이후의 WebGL 셰이더 실험으로 이어졌다.

Day28–30 — Beherit / The Game Changer

패널과 프레임을 나누고, ScrollTrigger에 따라 텍스트와 이미지 레이어를 순차적으로 노출했다. 여러 패널 이미지는 imageData.ts에서 데이터로 관리되며, 화면 구성과 콘텐츠 자산을 분리하는 방향을 보여준다.

• 목적: 이미지·텍스트·패널의 레이어드 내러티브
• 기술 방식: React, GSAP, ScrollTrigger, SCSS
• 도입 방식: 스크롤 위치를 장면 진행률로 사용
• 아키텍처: page → section → panel → text/image layer
• 후속 연결: 스토리보드, 씬 단위 영상 구성

5. 3단계 — 물리·포인터·무한 루프: 컴포넌트를 살아 움직이게 하기

Day35 — Circular Text

텍스트를 한 줄의 문장이 아니라 원형 경로를 따라 배치되는 시각 컴포넌트로 만들었다. 이후 키네틱 타이포그래피에서 텍스트의 위치, 방향, 간격을 속성으로 다루는 데 필요한 기초가 되었다.

Day36 — Falling Text

Matter.js와 Canvas를 사용해 텍스트를 물리 오브젝트처럼 떨어뜨렸다. 텍스트를 DOM에 고정된 요소로 보지 않고, 단어 또는 글자 단위의 body로 변환하는 접근이다.

Text string
   ↓ split into words / characters
Physics bodies
   ↓ gravity / collision / restitution
Canvas renderer

이 실험은 텍스트 애니메이션에서 “몇 초 동안 이동한다”는 시간 기반 접근을 넘어, 공간과 충돌을 함께 설계할 수 있다는 가능성을 보여주었다.

Day38 — Infinite Scroll

자동 재생, wheel, drag 입력을 하나의 무한 루프에 통합했다. GSAP Observer와 requestAnimationFrame, wrap logic을 사용해 아이템이 경계를 넘으면 반대편으로 순환하도록 구성했다.

• 목적: 끝이 없는 갤러리와 입력 반응 구현
• 기술 방식: GSAP, Observer, requestAnimationFrame
• 도입 방식: 사용자의 입력값과 자동 진행값을 동일한 progress로 변환
• 아키텍처: wrapper → item loop → observer → transform update
• 후속 연결: Scroll Velocity, Remotion timeline

Day40 — 이미지 갤러리와 스택

이미지 asset을 여러 위치와 크기로 배치하고, 갤러리 자체를 장면의 구성 요소로 다루었다. 카드 하나의 완성도보다 이미지 묶음의 리듬과 여백, 겹침을 관찰하는 단계였다.

6. 4단계 — 픽셀·노이즈·타이포그래피: 시각 언어를 패턴으로 분류하기

Day41 이후에는 하나의 효과보다 반복해서 사용할 수 있는 모션 문법을 찾는 일이 중요해졌다.

|

이 작업들은 모두 완성된 하나의 제품이라기보다, 이후 다른 화면에서 꺼내 쓸 수 있는 모션의 단위였다. 예를 들면 Decrypted Text의 글자 교체 방식은 타이틀 등장에, Pixel Transition은 장면 전환에, Variable Proximity는 사용자의 위치를 시각적으로 피드백하는 타이포그래피에 적용할 수 있다.

Pixel과 Noise가 남긴 것

픽셀과 노이즈는 이미지의 품질을 낮추는 효과처럼 보이지만, 실제로는 화면의 해상도와 시간성을 조절하는 레이어였다. 화면을 얼마나 잘게 나눌 것인지, 어느 순서로 보여줄 것인지, 원본 이미지와 변형 이미지 사이의 거리를 어떻게 만들 것인지가 모두 별도의 설계 변수가 되었다.

이 관점은 이후 Dithering, VHS Degradation, TextureMix 같은 셰이더 기반 작업에서 다시 등장한다.

7. 5단계 — 갤러리에서 미디어 컴포넌트로

Day53–56 — 갤러리와 리스트 구조

Day53–55는 갤러리와 리스트 레이아웃을 반복해서 변형하고, Day56은 여러 이미지 asset을 사용하는 갤러리 구성으로 확장했다. 같은 콘텐츠라도 카드의 순서, 크기, 여백, 겹침에 따라 전혀 다른 화면 리듬이 만들어졌다.

이 시기부터 콘텐츠와 표현을 분리하는 일이 중요해졌다.

interface ImageItemData {
  id?: number;
  coverImg?: string;
  title?: string;
  label?: string;
}

실제 데이터는 완벽하게 채워진 CMS 모델이 아니어도 괜찮았다. 중요한 것은 갤러리 컴포넌트가 이미지의 구체적인 출처와 무관하게 배열을 받아 렌더링할 수 있는 구조를 갖추는 일이었다.

Day58–59 — Silk와 인터랙티브 텍스처

Silk 계열 작업은 갤러리의 콘텐츠보다 배경과 질감 자체를 실험하는 방향으로 이동했다. 흐르는 표면, 빛의 변화, 포인터에 반응하는 텍스처를 화면의 배경 컴포넌트로 구성했다.

이때의 질문은 “이미지를 어디에 놓을까?”에서 “장면의 표면은 어떻게 움직여야 할까?”로 바뀌었다. 이후 Background Mix와 Texture Mix로 이어지는 출발점이다.

Day60 — 대형 레이아웃과 정보 페이지

SCSS 변수, breakpoint, typography, layout을 함께 다루며 개별 효과보다 페이지 전체의 구조를 점검했다. 매일의 작은 실험이 실제 페이지 안에서 어떻게 공존할 수 있는지 확인하는 단계였다.

8. 6단계 — 카드 스택과 비디오 마스킹

Day61 — Card Swap Animation

Card Swap은 카드가 단순히 순서대로 바뀌는 것이 아니라, 시간과 공간의 슬롯을 이동하는 구조로 설계되었다. forwardRef와 여러 ref를 사용해 카드의 실제 위치를 추적하고, slot 계산과 GSAP timeline을 분리했다.

Card component
   ↓
Slot calculation
   ↓
Position / scale / opacity
   ↓
GSAP timeline
   ↓
Card swap interaction

• 목적: 카드 스택의 순환과 깊이감 표현
• 기술 방식: React, forwardRef, GSAP, ScrollTrigger
• 도입 방식: 카드마다 목표 슬롯을 계산한 뒤 timeline으로 이동
• 아키텍처: Card → Slot → Timeline
• 후속 연결: 다중 비디오, Stagger, 씬 전환

이 작업은 컴포넌트가 단순한 모양이 아니라, 위치·상태·전환에 대한 계약을 가져야 한다는 것을 보여주었다.

Day62 — 텍스트 비디오 마스킹

비디오 레이어와 텍스트 레이어를 결합해 영상이 글자의 내부에서 보이도록 만들었다. video ref와 텍스트 마스크를 함께 사용하면서 미디어와 타이포그래피가 하나의 장면 안에서 서로의 컨테이너가 되는 구조를 실험했다.

이 패턴은 나중에 Lyrics MV에서 가사, 영상, 배경 텍스처를 결합하는 핵심적인 시각 문법으로 확장되었다.

9. _Debug: 실패와 보류 작업도 아카이브에 포함하기

_Debug 폴더는 완성된 제품 목록과 분리해서 읽어야 한다. 이곳에는 구현이 중단된 작업, 다른 환경에서 옮겨오며 발생한 호환성 문제, 아이디어 검증용 프로토타입, 이전 실험의 변형이 함께 있다.

주요 실험 카테고리는 다음과 같다.

BurgerLanding
GridScrollGallery
ImageHoverTransition
InfiniteWebGLGallery
LightOutGSAPParallax
LiquidDistortion
NoiseMoireMemories
ParallaxEffectGSAP
PixelTransition
Rejouice
SteppingTransition
FlagTextSect
MicroComponents
MicroSketch
MicroTesting
shaderEffectsComp

이 목록을 완성도 순서로 정렬할 필요는 없다. 오히려 _Debug는 다음 질문을 남긴다.

• 이 효과는 실제 사용성을 해치지 않는가?
• 포인터와 스크롤이 동시에 들어올 때 상태가 충돌하지 않는가?
• 이미지 로딩 전후의 레이아웃이 달라지지 않는가?
• Vite, React, Remotion 등 다른 런타임에서도 같은 결과를 재현할 수 있는가?
• 라이브러리의 래퍼를 사용할 것인가, 원본 인스턴스를 직접 제어할 것인가?

특히 Day59 계열의 스크롤 실험에서 Lenis와 GSAP ScrollTrigger를 연결하는 과정은 편의성과 제어권 사이의 trade-off를 드러냈다. 래퍼 컴포넌트는 빠르게 시작하기 좋지만, 타이밍과 생명주기를 세밀하게 제어해야 할 때는 원본 라이브러리를 직접 다루는 편이 더 명확할 수 있었다.

실패한 코드는 버려지는 것이 아니라, 다음 시스템에서 피해야 할 조건을 알려주는 테스트 케이스가 된다.

10. 갤러리 리팩토링: 시각 실험에서 데이터 계약으로

100DaysOfUI 작업은 애니메이션만의 문제가 아니었다. 미디어 갤러리와 모달을 구현하는 과정에서는 데이터 구조의 중복도 큰 문제였다.

초기에는 아이템 자체의 type과 내부 media.type이 중복되어 이미지, 비디오, iframe, 외부 링크를 일관되게 처리하기 어려웠다. 이를 다음처럼 단순화하는 방향으로 정리했다.

interface GalleryItem {
  id: string;
  title: string;
  media?: {
    type: 'image' | 'video' | 'iframe';
    url: string;
  };
  link?: string;
}

이 구조에서는 media.type이 미디어의 종류를 단일하게 책임진다.

• media가 있으면 이미지·비디오·iframe 렌더링
• media가 없고 link가 있으면 외부 링크
• 둘 다 없으면 안내 메시지

모달은 다음 UX 조건을 함께 처리했다.

• ESC 키로 닫기
• 배경 클릭으로 닫기
• 내부 콘텐츠 클릭은 전파 중단
• 모달이 열려 있을 때 body scroll lock
• 미디어 타입별 렌더링 분리

이 경험은 “멋있는 효과를 만드는 것”과 “사용자가 예측 가능한 방식으로 콘텐츠를 탐색하는 것”이 같은 수준에서 중요하다는 사실을 확인하게 했다.

11. UI 컴포넌트에서 모션 컴포넌트로

100DaysOfUI의 작업들은 시간이 지나며 Figma와 Remotion의 언어로 다시 해석되었다. UI의 버튼, 카드, 텍스트, 갤러리라는 단위가 영상에서는 장면, 레이어, 타이밍, 전환이라는 단위로 바뀌었다.

Web UI component
  ├── visual style
  ├── interaction state
  ├── content contract
  └── responsive behavior

        ↓ reinterpret

Motion component
  ├── visual style
  ├── timeline state
  ├── scene contract
  └── deterministic rendering

이 변환에서 중요한 것은 UI 컴포넌트를 그대로 영상에 복사하는 일이 아니었다. 컴포넌트가 가진 시각적 규칙과 상태 변화를 추출해 영상의 시간축에 다시 배치하는 일이었다.

• Decrypted Text → 가사 또는 타이틀의 등장 규칙
• Pixel Transition → 씬 전환 규칙
• Falling Text → 물리 기반 타이포그래피
• Card Swap → 이미지·비디오 슬롯 전환
• Silk → 배경과 텍스처 레이어
• Text Video Mask → 가사와 미디어의 결합

이후 TypeMix에서는 키네틱 타이포그래피 프리셋과 IMotionPreset 타입을 정의하고, TextureMix에서는 쉐이더 레이어와 복합 프리셋, 선언적 Scene System으로 확장했다. 다만 이것들은 100Days 당시 이미 완성되어 있던 시스템이 아니라, 이전의 작은 실험들이 후대에 재분류되고 구조화된 결과다.

12. 디자인 시스템으로 재해석하기

100DaysOfUI를 지나고 나서야 디자인 시스템을 “처음부터 완벽하게 설계하는 문서”로 생각하지 않게 되었다. 나에게 디자인 시스템은 반복되는 작업 속에서 발견되는 규칙을 기록하고, 다음 작업이 그 규칙을 이해할 수 있도록 만드는 장치에 가깝다.

Primitive

가장 작은 시각 단위다.

• 색상과 투명도
• typography scale
• spacing
• grid cell
• pixel block
• image layer
• easing과 duration

Semantic

Primitive가 특정 목적을 갖도록 조합된 단위다.

• glitch overlay
• gallery card
• scrolling text
• image trail
• transition mask
• texture background
• card slot

Component / Scene

여러 규칙을 묶어 실제 사용자 경험 또는 영상 장면을 만드는 단위다.

• Gallery Scene
• Card Swap Scene
• Kinetic Typography Scene
• Texture Background Scene
• Lyrics MV Scene

이 구조에서 컴포넌트는 모양이 아니라 계약이다. 어떤 props를 받고, 어떤 상태를 가지며, 어느 타이밍에 시작하고, 다른 컴포넌트와 어떻게 결합할 수 있는지를 정의해야 한다.

100DaysOfUI는 100개의 완성품을 만드는 도전이 아니라, 어떤 시각적 패턴이 컴포넌트가 되고 어떤 코드는 일회성 실험으로 남는지를 분류하는 장기 리서치였다.

13. 작업별 아카이브 인덱스

아래 표는 현재 코드와 로그에서 확인되는 작업을 목적과 후속 연결 중심으로 압축한 것이다.

14. 시각적 아이템과 에셋 아카이브

코드와 함께 확인되는 주요 시각 자산은 다음과 같다.

• Day22–24: Blue Summer Grids 이미지 세트
• Day28–30: Capa 1.png부터 Capa 7.png까지의 패널 이미지
• Day40: 이미지 갤러리 자산
• Day56: gallery images 1.jpg–20.jpg 계열 자산
• Day58: Frame_4_1.png, Screenshot_2025_10_10.png, Snapshot 계열 스냅샷
• Day68: door.jpg
• ImageHoverTransition: diss.png, 01.png, 02.png, sponsor-logo.png

디지털 가든에 실제 파일이 연결되지 않은 작업은 임의의 이미지 embed를 만들지 않고 후보로 남기는 편이 정확하다.

[이미지 후보: Day19 Gridbox Glitch의 블록 분해 구조]
[이미지 후보: Day38 InfiniteScroll의 입력과 loop 구조]
[이미지 후보: Day61 CardSwap의 slot 계산]
[이미지 후보: Day62 Text Video Mask의 레이어 구성]

아카이브 페이지에서 중요한 것은 모든 화면을 장식처럼 나열하는 것이 아니다. 각 이미지가 어떤 문제를 해결하기 위한 시도였고, 어느 패턴이 다음 작업으로 이동했는지를 함께 보여주는 것이다.

15. 100DaysOfUI에서 나만의 제작 도구로

작은 UI 실험은 이후 Figma 스토리보드와 모션 디자인 시스템으로 다시 정리되었다. 반복되는 레이아웃과 애니메이션을 블록으로 추상화하고, typography·이미지·텍스처·전환을 조합할 수 있는 구조를 만들었다.

그 결과는 다음의 도구와 작업으로 연결되었다.

• KR-design-system-as-storyboard-umad-lyrics-mv
• KR-My-own-production-tools-for-my-mvs
• [[ KR-VFX-In-Codes ]]
• KR-figma-to-jitter-and-remotion
• KR-developing-my-own-aesthetics

특히 TypeMix는 Day72의 Weight Wave와 Day75의 Directional Pop처럼 텍스트의 무게와 방향을 모션 프리셋으로 재구성한 결과다. TextureMix는 Silk와 Noise, Pixel, Dithering 계열의 관심이 쉐이더 레이어와 선언적 씬 시스템으로 확장된 사례다.

이후 Lyrics MV 작업에서는 화면 안의 텍스트와 이미지가 단순한 UI 요소가 아니라, 음악의 박자와 서사를 전달하는 장면 구성 요소가 되었다.

Daily UI experiment
    ↓
Reusable visual pattern
    ↓
Figma storyboard / motion token
    ↓
React or Remotion component
    ↓
Texture / Type / Background tool
    ↓
Lyrics MV scene system

중요한 것은 처음부터 이 결말을 알고 있었던 것이 아니라는 점이다. 각각의 작업은 당시에는 작은 실험이었고, 나중에야 서로 연결되는 공통 문법이 보이기 시작했다.

에필로그: 100일은 끝난 것이 아니라 라이브러리가 되었다

100DaysOfUI에서 얻은 가장 큰 결과는 100개의 화면이 아니다. 어떤 인터랙션이 다시 사용할 수 있는 패턴인지, 어떤 코드는 특정 화면에만 남겨야 하는지, 어떤 실패가 다음 설계의 제약조건이 되는지를 구분하는 감각이다.

처음의 질문은 “오늘은 무엇을 만들까?”였다. 시간이 지나며 질문은 이렇게 바뀌었다.

• 이 패턴의 최소 단위는 무엇인가?
• 어떤 상태를 props로 노출해야 하는가?
• 웹과 영상에서 공통으로 사용할 수 있는 규칙은 무엇인가?
• 이 시각 효과는 콘텐츠를 돕는가, 아니면 콘텐츠를 가리는가?
• 다음 작업자가 이 컴포넌트를 어떻게 이해할 것인가?

그래서 이 챌린지는 완성된 제품이라기보다 계속 업데이트되는 라이브러리다. Day별 코드는 서로 다른 미학을 보존하고, 공통 유틸리티는 반복을 줄이며, _Debug의 실패 로그는 다시 같은 문제를 겪지 않도록 한다.

그리고 그 라이브러리는 지금도 확장 중이다.

100 Days of UI
    ↓
React UI component experiments
    ↓
GSAP / ScrollTrigger / Canvas / WebGL
    ↓
Design tokens and component archive
    ↓
Remotion motion graphics
    ↓
TypeMix / TextureMix / Background Mix
    ↓
Lyrics MV production system

결국 100일 동안 만든 것은 UI만이 아니었다. 반복해서 만들고, 깨뜨리고, 분류하고, 다시 조합하는 나만의 시각적 제작 언어였다.