Design System as a Storyboard: 디자인 시스템에서 UMAD Lyrics MV까지

Design System as a Storyboard

디자인 시스템을 웹앱 밖으로 꺼내는 일

디자인 시스템이라고 하면 보통 컬러 팔레트, 버튼, 카드, 간격 토큰을 떠올린다. 물론 그것도 맞다.

하지만 디자인 시스템은 그런 표면적 규격으로 정의할 수 없는 것이라 나는 생각한다. 결국은 어떤 조직이나 프로덕트, 공공의 의제나 목적에 따라 어떻게 디자인을 규정하고 시스템을 시각적 문서화로 규정하는 작업 자체를 나는 일컫는다 생각한다.

내가 디자인 시스템을 직접 구성하고 문서화하기 시작하면서 조금 다른 질문을 하게 되었다.

디자인 시스템은 화면의 모양을 통일하는 도구인가, 아니면 생각과 구현이 같은 언어를 사용하게 만드는 계약인가?

이 질문은 처음에는 Antiperfect.Club 리브랜딩과 100 Days of UI 챌린지에서 시작되었다. Figma에서 컴포넌트를 만들고, React와 TypeScript로 옮기고, CSS 변수와 반응형 레이아웃을 정리하면서 반복되는 문제가 보였다.

• 디자이너가 말하는 “큰 제목”은 실제 코드에서 몇 px인가?
• “카드가 조금 떠 보이게”라는 말은 어떤 shadow와 elevation을 의미하는가?
• hover, focus, disabled 상태는 어디까지 정의되어 있는가?
• 컴포넌트의 variant가 많아졌을 때 어떤 축을 먼저 나눌 것인가?
• Figma에서 만든 구조가 실제 React 컴포넌트의 props와 일치하는가?
• 화면을 영상으로 가져가면, 상태와 시간은 어떤 데이터가 되는가?

여기서 디자인 시스템은 단순히 시각적인 규정의 모음이 아니라 의도를 전달하는 언어 체계가 되었다. 그리고 그 언어를 웹앱에만 가둘 이유가 없었다.

Lyrics MV를 기획할 때도 나는 내가 예전에 UX디자인과 개발을 하던 때와 같은 문제를 마주한다. 자막, 이미지, 배경, 셰이더, 전환, 오디오 타임라인을 매번 새로 만들면 작업은 한 편의 영상에서 끝난다. 반대로 컴포넌트와 토큰으로 정리하면, 하나의 장면에서 발견한 규칙을 다음 곡과 다음 장면으로 가져갈 수 있다.

이 근본적인 원칙을 이걸 하나의 브랜딩으로 접근하면 브랜딩 디자인 시스템이 되는 것이고 웹/앱 프로덕트로 가져가면 UX 디자인 시스템이 되는 것이다.

이 글은 디자인 시스템을 어떻게 접근하고 분류했는지, 어떤 언어와 원칙을 세웠는지, 그리고 그것을 역발상으로 UMAD Lyrics MV의 기획·스토리보드·모션 아키텍처에 어떻게 적용하려 했는지를 정리한 기록이다.

1. 출발점: 100 Days of UI는 작은 디자인 시스템 실험이었다

100 Days of UI는 매일 새로운 화면을 만드는 챌린지였지만, 나에게는 단순한 시각 훈련이 아니었다. 각각의 Day는 독립적인 UI 실험이면서 동시에 다음 질문을 던지는 테스트 케이스였다.

• 이 컴포넌트의 핵심 규칙은 무엇인가?
• 어떤 부분은 반드시 재사용되어야 하는가?
• 어떤 부분은 해당 Day의 일회성 연출인가?
• 이 인터랙션은 CSS만으로 충분한가, 아니면 GSAP·Canvas·WebGL이 필요한가?
• 나중에 영상이나 다른 페이지로 옮길 수 있는가?

초기 Day에서는 React와 SCSS, GSAP을 이용해 Hero, Gallery, 글리치 텍스트, 이미지 전환을 만들었다. 이후에는 ScrollTrigger, Lenis, Framer Motion, Canvas, Matter.js, Three.js, SVG Filter가 차례로 추가되었다.

대표적인 실험은 다음과 같다.

이 챌린지에서 중요한 것은 모든 Day가 완성품이었다는 사실이 아니다. 오히려 @ts-nocheck, console.log, 주석 처리된 이전 구현, 빈 wrapper, 연결되지 않은 라우트가 많았다. 그 흔적들은 패턴을 추출하기 위한 실험 로그였다.

예를 들어 Day 22–24의 글리치 이미지에서는 같은 이미지를 여러 레이어로 겹치고 CSS animation으로 offset을 만들었다. Day 47의 Pixel Transition에서는 이미지를 작은 픽셀 블록으로 나누어 전환했다. Day 52의 ASCII Text에서는 CanvasTexture와 ShaderMaterial을 이용해 텍스트를 픽셀 문자로 변환했다.

서로 다른 Day처럼 보이지만, 실제로는 다음 공통 원칙을 공유한다.

Input Asset
    ↓
Visual Decomposition
    ↓
Reusable Motion Rule
    ↓
Interaction / Timing
    ↓
Preview
    ↓
Archive

100 Days of UI는 이렇게 나에게 컴포넌트의 원자 단위와 일회성 연출을 구분하는 훈련이 되었다.

관련 기록: 100DaysLogs
관련 기록: KR-how-my-motion-graphics-workflow-has-been-evolved

2. 첫 번째 원칙: 먼저 수집하고, 나중에 정의한다

디자인 시스템을 만들면서 가장 먼저 한 일은 Figma에 컴포넌트를 그리는 것이 아니었다. 내가 이미 만들고 있던 화면과 코드를 수집하는 일이었다.

Discovery 단계

• 기존 페이지와 Day별 컴포넌트 목록 수집
• 반복되는 색상·타이포그래피·간격 확인
• hover, focus, active, disabled 상태 확인
• 레이아웃과 브레이크포인트 확인
• 애니메이션과 정적 스타일 분리
• 실제 코드에서 사용되는 props와 Figma 속성 비교
• 접근성·반응형·성능 제약 기록

이 과정을 거치지 않고 곧바로 “완벽한 디자인 시스템”을 만들면, 실제 작업과 동떨어진 컴포넌트 박물관이 되기 쉽다. 그래서 나는 먼저 코드와 결과물을 포렌식하듯 확인하고, 그 뒤에 언어 체계를 붙이는 방식을 택했다.

graph TD
    A[Existing UI and Motion] --> B[Inventory]
    B --> C[Pattern Extraction]
    C --> D[Token Definition]
    D --> E[Component Contract]
    E --> F[Figma Component]
    E --> G[React Component]
    E --> H[Remotion Component]
    F --> I[Visual QA]
    G --> I
    H --> I

내가 적용한 4단계 작업 순서

1. 분석: 화면과 코드를 보고 반복 패턴을 찾는다.
2. 명세: 이름, 토큰, props, 상태, 동작을 문서화한다.
3. 구현: Figma, React, Remotion에서 같은 계약을 구현한다.
4. 검증: 시각적 결과, 접근성, 반응형, 렌더링 안정성을 확인한다.

이 순서는 Figma Design System Builder 문서의 Discovery → Foundations → File Structure → Components → Integration & QA 흐름과도 맞닿아 있다. 핵심은 한 번에 자동 생성하는 것이 아니라, 각 단계마다 범위를 확인하고 다음 단계로 넘어가는 것이다.

3. 두 번째 원칙: Primitive와 Semantic을 분리한다

디자인 시스템의 가장 중요한 언어 규칙은 이름을 값과 분리하는 것이다.

Primitive
  └─ Semantic
      └─ Component
          └─ Composition / Scene

Primitive: 값 자체

Primitive는 색상, 간격, 폰트 크기처럼 원시값이다.

:root {
  --color-magenta-500: #ff00ff;
  --color-cyan-500: #00ffff;
  --color-neutral-000: #000000;
  --color-neutral-100: #ffffff;

  --space-1: 4px;
  --space-2: 8px;
  --space-3: 12px;
  --space-4: 16px;
  --space-6: 24px;
  --space-8: 32px;
}

Semantic: 역할과 의도

Semantic token은 그 값이 어디에 쓰이는지 설명한다.

:root {
  --color-surface-canvas: var(--color-neutral-000);
  --color-text-primary: var(--color-neutral-100);
  --color-action-primary: var(--color-magenta-500);
  --color-effect-chromatic: var(--color-cyan-500);
  --motion-gap-default: var(--space-4);
}

#ff00ff라고만 쓰면 색상값은 알 수 있지만, 그 색이 CTA인지, 글리치 효과인지, 활성 상태인지 알 수 없다. 반면 --color-effect-chromatic는 색상의 역할을 설명한다.

이 구분은 Lyrics MV에서 훨씬 더 중요해진다. 영상에서 0.8이라는 값은 무엇인가? 셰이더 강도인가, 자막 opacity인가, 오디오 반응성인가? 단순 숫자를 그대로 전달하면 장면이 늘어날수록 의미가 무너진다.

그래서 MV용 토큰은 다음처럼 의미를 포함해야 한다.

const motionTokens = {
  timing: {
    lyricEntry: 18,
    lyricExit: 12,
    beatAccent: 4,
    sceneTransition: 24,
  },
  typography: {
    lyricPrimary: 144,
    lyricSecondary: 72,
    letterSpacingTight: -0.04,
  },
  texture: {
    vhsSubtle: 0.25,
    vhsStrong: 0.72,
    glitchAccent: 0.48,
  },
};

값은 나중에 바뀔 수 있다. 하지만 lyricEntry, sceneTransition, vhsStrong라는 의미는 남아야 한다.

4. 세 번째 원칙: 컴포넌트는 모양이 아니라 계약이다

Figma Component Contract 문서에서 컴포넌트는 단순한 프레임이 아니다. 컴포넌트가 어떤 props와 상태를 갖고, 어떤 토큰을 사용하며, 어떤 제약을 지키는지 정의하는 계약이다.

웹앱용 컴포넌트 계약 예시

interface ServiceBlockProps {
  title: string;
  description: string;
  showcase: {
    title: string;
    content: string;
  };
  techStack: string[];
  state?: 'default' | 'hover' | 'focused';
}

이 계약을 기준으로 Figma에서는 다음을 정의할 수 있다.

• Component Set
• Variant Property
• State Property
• Text Property
• Instance Swap
• Auto Layout
• Token Binding

React에서는 같은 계약이 props와 타입으로 나타난다. 이때 Figma의 Variant와 TypeScript의 union type이 서로 다른 이름을 사용하면 핸드오프가 다시 번역 작업이 된다.

Figma Variant: State = Default | Hover | Focused
TypeScript:    state: 'default' | 'hover' | 'focused'

모션·영상용 컴포넌트 계약

UMAD Lyrics MV에서는 이 계약이 시간축까지 포함해야 한다.

interface KineticLyricProps {
  text: string;
  startFrame: number;
  endFrame: number;
  splitMode?: 'none' | 'words' | 'characters' | 'balanced';
  motionVariant: 'typewriter' | 'slide' | 'stack' | 'marquee' | 'glitch';
  stagger?: number;
  easing?: string;
  position?: {
    x: number | string;
    y: number | string;
  };
  texture?: {
    shaderType?: 'none' | 'vhs' | 'halftone' | 'glitch' | 'dither';
    intensity?: number;
    blendMode?: string;
  };
}

이제 컴포넌트는 단순히 “글자를 보여주는 박스”가 아니다.

• 언제 등장하는가
• 언제 사라지는가
• 몇 글자 또는 몇 줄로 나뉘는가
• 어떤 모션 variant를 사용하는가
• 오디오와 어떤 관계를 갖는가
• 텍스처는 어느 정도 강도로 적용되는가
• 어떤 출력 환경에서 안정적으로 렌더링되는가

를 함께 정의하는 작은 제작 계약이다.

5. Figma 디자인 시스템의 접근 방식

5.1 토큰부터 만든다

Figma에서 컴포넌트를 만들기 전에 Variable Collection을 먼저 만든다.

• Tier 1: Primitives — 원시값
• Tier 2: Semantics — 역할 기반 alias
• Tier 3: Component / Scene — 실제 사용 맥락

변수에는 가능한 역할에 맞는 Scope를 부여해야 한다.

모든 변수에 ALL_SCOPES를 부여하면 편해 보일 수 있지만, 그 순간 변수의 의도가 사라진다. 디자인 시스템은 무엇이든 어디에나 넣을 수 있게 만드는 것이 아니라, 잘못된 조합을 어렵게 만드는 시스템이어야 한다.

5.2 Variant 축은 제한한다

Variant를 무작정 조합하면 하나의 컴포넌트가 수십 개의 상태를 가진 괴물이 된다. 그래서 primary axis를 먼저 정하고, 조합이 30개를 넘으면 컴포넌트 세트를 분리한다.

웹 버튼이라면 다음과 같다.

Button
├── Style: Primary | Secondary | Ghost
├── Size: Small | Medium | Large
├── State: Default | Hover | Focused | Disabled
└── Icon: None | Leading | Trailing

Lyrics MV의 타이포그래피도 똑같다.

KineticLyric
├── Motion: Typewriter | Slide | Stack | Marquee | Glitch
├── Split: None | Words | Characters | Balanced
├── Direction: Left | Right | Up | Down
├── Density: Loose | Regular | Tight
└── Texture: None | VHS | Dither | RGB Shift

단, 모든 축을 한 컴포넌트에 곱하지 않는다. Motion, Texture, Layout을 필요에 따라 별도 레이어로 분리한다.

5.3 Grid는 문서이자 검증 도구다

Figma에서 Variant를 논리적인 행과 열에 배치하면 시각적 QA가 쉬워진다.

• 열: interaction state
• 행: size × style
• 헤더: variant 이름과 token
• 컨테이너: 컴포넌트 세트의 경계

이 구조는 Type Mix나 MoShader Showcase의 Mega Grid에도 그대로 적용된다. 한 화면에서 여러 모션과 셰이더를 비교하는 것은 단순한 쇼케이스가 아니라 variant drift를 찾는 검증 화면이다.

6. 디자인 시스템을 UMAD Lyrics MV로 역변환하기

여기서 역발상이 시작된다.

일반적인 흐름은 다음과 같다.

Design System → Web App

내가 UMAD Lyrics MV에서 시도한 흐름은 이렇다.

Design System
      ↓
Motion and Texture System
      ↓
Lyrics MV Storyboard
      ↓
Remotion Composition

웹앱용 디자인 시스템의 요소를 영상 언어로 바꾸면 다음과 같다.

UMAD의 기획 출발점

UMAD Lyrics MV를 기획할 때 먼저 영상을 상상하고 바로 컴포넌트를 만들지 않았다. 다음 순서를 거쳤다.

1. 곡의 정서와 가사 구조를 분석한다.
2. 보컬, 비트, 전환 포인트를 시간축에 표시한다.
3. Figma에서 장면별 이미지를 수집하고 moodboard를 만든다.
4. 색상, 타이포그래피, 그리드, 질감의 규칙을 추출한다.
5. 규칙을 component variant와 motion token으로 번역한다.
6. Jitter, Cavalry 또는 TouchDesigner로 빠르게 움직임을 확인한다.
7. Remotion schema에 실제 frame 범위와 props를 기록한다.
8. 필요한 경우 WebGL shader와 texture layer를 연결한다.
9. 씬 단위로 preview하고, 승인된 버전을 최종 Composition에 반영한다.

flowchart TD
    A[UMAD Audio and Lyrics] --> B[Beat and Subtitle Analysis]
    B --> C[Scene Map]
    C --> D[Figma Moodboard]
    D --> E[Design Tokens]
    E --> F[Motion Component Contracts]
    F --> G[Type Mix / Texture Mix / Background Mix]
    G --> H[Remotion Scene Schema]
    H --> I[Preview and QA]
    I --> J[Final MV Render]

이렇게 하면 “가사에 어떤 효과를 넣을까?”라는 막연한 질문이 다음처럼 구체화된다.

• 이 문장은 KineticWord/Stack인가?
• 이 구간은 Texture/VHS/Strong인가?
• 이 장면의 배경은 Background/NeonGrid/Slow인가?
• 이 전환은 SceneTransition/Wipe/24frames인가?
• 이 컴포넌트는 30fps와 60fps에서 같은 진행률을 유지하는가?

디자인 시스템이 영상의 storyboard grammar가 되는 순간이다.

7. UMAD Scene Contract

UMAD를 위한 하나의 씬은 다음처럼 정의할 수 있다.

interface UmadSceneConfig {
  id: string;
  name: string;
  startFrame: number;
  endFrame: number;
  background: {
    preset: 'solid' | 'neonGrid' | 'vhs' | 'proceduralNoise';
    params: Record<string, number | string>;
  };
  lyrics: Array<{
    id: string;
    text: string;
    startFrame: number;
    endFrame: number;
    component: 'typewriter' | 'kineticWord' | 'stack' | 'marquee' | 'glitch';
    typography: {
      fontFamily: string;
      fontSize: number;
      letterSpacing: number;
      colorToken: string;
    };
    motion: {
      variant: string;
      stagger?: number;
      easing?: string;
    };
    texture?: {
      type: string;
      intensity: number;
      blendMode: string;
    };
  }>;
  transition?: {
    type: 'fade' | 'slide' | 'wipe' | 'glitch';
    durationInFrames: number;
  };
}

이 계약이 있으면 Figma의 storyboard와 Remotion 코드 사이에 중간 언어가 생긴다. 디자이너가 “이 장면의 텍스트는 세로로 쌓이고, 1초 뒤 사라진다”고 말하면 다음과 같이 명세할 수 있다.

scene: verse-01
lyric: 나는 말이야~
component: KineticLyric/Stack
startFrame: 120
endFrame: 180
stack: 2 rows × 3 columns
entry: wave
exit: fadeOut
next: 꿈이 있었어 / slideIn

이것은 단순한 애니메이션 옵션이 아니다. 장면의 의도, 시간, 레이아웃, 컴포넌트, 다음 상태를 한 줄로 전달하는 계약이다.

8. WebGL과 디자인 시스템: Texture도 Token이 된다

WebGL 셰이더는 보통 개발자의 영역처럼 보인다. 하지만 Lyrics MV에서는 shader도 디자인 시스템의 일부가 될 수 있다.

예를 들어 VHS라는 이름만으로는 충분하지 않다. 다음 질문이 필요하다.

• 어느 시대의 VHS인가?
• 화면 전체에 적용하는가, 특정 이미지에만 적용하는가?
• 강도는 어느 정도인가?
• 자막 가독성을 방해하지 않는가?
• 프리뷰와 최종 렌더에서 같은 결과가 나오는가?
• 이 효과는 다른 장면에서도 재사용 가능한가?

그래서 셰이더를 다음처럼 역할과 파라미터로 정의한다.

ShaderToy에서 참고한 mainImage, iTime, iChannel0 같은 실행 규칙은 Remotion·Three.js 환경에 맞게 변환해야 한다. preserveDrawingBuffer, useCurrentFrame(), frame / fps, texture loading, DPR와 FBO 설정도 컴포넌트 계약의 일부가 된다.

Shader Library = atoms
Universal Wrapper = lifecycle engine
Schema Registry = parameter contract
Preview Showcase = visual QA
Remotion Bridge = frame-based renderer

이 구조가 있어야 Type Mix의 타이포그래피와 Texture Mix의 표면 효과를 같은 씬에 조합할 수 있다.

관련 기록: KR-WebGL-Computational-Visuals-VFX-In-Codes
관련 기록: KR-My-own-production-tools-for-my-mvs
관련 기술 문서: MoShader Showcase Integration.md

9. 도입한 원칙과 내가 만든 언어 체계

9.1 이름은 역할을 설명해야 한다

purple2, bigText, effect3 같은 이름은 처음에는 빠르지만 시간이 지나면 아무것도 설명하지 못한다.

대신 다음처럼 이름을 짓는다.

Color/Surface/Canvas
Color/Text/Primary
Typography/Lyric/Primary
Motion/Lyric/Stack/Wave
Texture/VHS/Subtle
Background/NeonGrid/Slow
Transition/Glitch/Accent

Figma layer, React component, Remotion config가 같은 namespace를 공유하면 문서와 코드 사이의 번역 비용이 줄어든다.

9.2 상태와 변형을 분리한다

상태는 시간에 따라 변하는 조건이고, 변형은 다른 표현 방식이다.

Variant: Stack | Marquee | Glitch
State: Enter | Hold | Exit

Stack과 Marquee가 서로 종속되어서는 안 된다. Sequence가 현재 화면을 덮어쓰는 기능으로 오해되어서도 안 된다. 하나의 씬 안에 여러 text event가 순서대로 실행되려면, sequence는 레이어와 시간의 컨테이너여야 한다.

9.3 토큰은 장면의 결정을 줄여야 한다

토큰화의 목적은 선택지를 무한히 늘리는 것이 아니다. 매번 처음부터 고민해야 하는 결정을 줄이는 것이다.

Notionally free choice
    ↓
Curated token set
    ↓
Controlled variant
    ↓
Scene-specific adjustment

기본 규칙은 시스템이 제공하고, 장면의 감정과 서사는 디렉터가 결정한다.

9.4 접근성과 가독성도 연출의 일부다

디자인 시스템에서 WCAG, 키보드 포커스, prefers-reduced-motion을 고려했던 것처럼, 영상에서도 가독성과 자극 강도를 관리해야 한다.

• 글리치가 텍스트를 완전히 읽을 수 없게 만들지 않는가
• 강한 RGB 분리가 장면의 의미를 가리지 않는가
• 빠른 플래시가 과도하게 반복되지 않는가
• 작은 화면에서도 자막이 충분히 보이는가
• 배경과 텍스트의 대비가 유지되는가
• 16:9와 9:16에서 핵심 요소가 잘리지 않는가

“멋있으니까 넣는다”가 아니라, 그 효과가 장면의 정보와 감정을 어떻게 돕는지 설명할 수 있어야 한다.

10. 내가 작업하며 참고하고 따온 방식

내 디자인 시스템은 어느 한 문서에서 그대로 가져온 것이 아니다. 여러 작업과 문서에서 다음의 사고방식과 기술 패턴을 추려 조합했다.

이것은 복사가 아니라 번역이다. 기존 웹앱의 컴포넌트 구조를 그대로 MV에 붙인 것이 아니라, 웹에서의 상태·변형·토큰·계약을 영상의 시간·씬·모션·질감으로 다시 매핑한 것이다.

11. 한계와 현실적인 타협

디자인 시스템을 만들었다고 해서 모든 문제가 사라지는 것은 아니다. 오히려 문서와 토큰이 늘어나면 새로운 문제가 생긴다.

• 토큰을 지나치게 만들면 시스템이 무거워진다.
• Variant 축을 너무 많이 만들면 컴포넌트가 관리 불가능해진다.
• Figma와 실제 코드 사이에 drift가 생긴다.
• 디자인 가이드는 있는데 실제 사용처가 부족할 수 있다.
• 셰이더 프리뷰와 최종 렌더링의 결과가 다를 수 있다.
• 자동화가 오히려 시각적 판단을 제한할 수 있다.

그래서 모든 것을 시스템화하지 않는다. 반복되는 규칙은 시스템에 넣고, 장면의 고유한 판단은 디렉터에게 남겨둔다.

System owns:
- naming
- tokens
- constraints
- reusable patterns
- validation

Director owns:
- meaning
- emphasis
- rhythm
- cultural context
- final taste

이 구분이 없으면 디자인 시스템은 또 하나의 감옥이 된다. 사용자가 실제로 필요로 하지 않는 variant를 40개씩 만들고, 아무도 쓰지 않는 규칙을 관리하게 된다. 디자인 시스템의 목표는 모든 가능성을 저장하는 것이 아니라, 반복되는 좋은 판단을 재사용 가능하게 만드는 것이다.

12. 에필로그: 디자인 시스템은 제작자의 사고를 외부화한다

내가 디자인 시스템을 만들게 된 이유는 다른 사람과 협업하기 위해서만은 아니었다. 혼자 작업하더라도 내가 매번 반복하는 판단을 잊지 않기 위해서였다.

100 Days of UI에서 만든 작은 버튼과 갤러리, 글리치 텍스트, 이미지 트레일, ASCII 효과는 각각 하나의 작은 실험이었다. Antiperfect.Club 리브랜딩에서는 그 실험을 정보 구조와 하드 스펙으로 정리했다. Figma에서는 토큰과 컴포넌트 계약으로 언어화했다. WebGL과 Remotion에서는 그 언어를 시간축과 렌더링 조건까지 포함하는 영상 시스템으로 확장했다.

그리고 UMAD Lyrics MV에서는 디자인 시스템을 다시 storyboard language로 바꾸었다.

UI Component
   ↓
Motion Component
   ↓
Scene Component
   ↓
Lyrics MV Composition

이제 하나의 가사를 보고도 다음과 같이 생각할 수 있다.

• 이 문장의 정보 밀도는 어느 정도인가?
• 어떤 타이포그래피 variant가 감정에 맞는가?
• Stack과 Marquee 중 무엇이 장면의 방향성을 설명하는가?
• 배경은 텍스트를 받쳐주는가, 아니면 경쟁하는가?
• 이 shader는 단순히 멋있는가, 아니면 음악의 질감을 번역하는가?
• Figma의 아이디어가 Remotion에서 실제 frame으로 재현되는가?

디자인 시스템은 결과물을 똑같이 만드는 규칙이 아니다. 서로 다른 결과물들이 같은 의도와 품질 기준을 공유하게 만드는 구조다.

그래서 이 글은 다음 시리즈로 이어진다.

100 Days of UI
      ↓
Design System and Component Contracts
      ↓
My Own Production Tools for My MVs
      ↓
UMAD Lyrics MV Storyboard
      ↓
Lyrics MV Projects
      ↓
All Experiments Combined into Making MVs

결국 내가 만들고 있는 것은 디자인 시스템이면서, 모션 시스템이고, 영상 제작 시스템이다. 그리고 그 모든 시스템의 중심에는 여전히 하나의 질문이 남는다.

이 화면과 이 프레임을 통해, 관객에게 무엇을 느끼게 할 것인가?

그 질문에 답하기 위해 토큰을 만들고, 컴포넌트를 분리하고, 스토리보드를 그리고, 다시 코드를 쓴다. 시스템은 창작을 대신하지 않는다. 다만 창작자가 더 중요한 판단에 집중할 수 있도록 반복되는 혼란을 정리해준다.

관련 시리즈:

• KR-My-own-production-tools-for-my-mvs
• KR-my-own-production-tool-type-mix
• KR-my-own-production-tool-texture-mix
• KR-my-own-production-tool-bg-maker
• KR-WebGL-Computational-Visuals-VFX-In-Codes
• KR-Lyrics-MV-Projects
• KR-Lyrics-MV-Project-Compound-Convergent-Directing-Retrospective
• KR-All-experiments-combined-into-making-MVs