Kinetic Motion In Codes: 2025년, 글자가 움직이기 시작한 기록

Last updated August 24, 2026 – ArtXTech

Kinetic Motion In Codes: 2025년, 글자가 움직이기 시작한 기록

글자가 가만히 있지 않고, 박자에 맞춰 튀고 흩어지고 다시 문장으로 수렴하는 걸 본 적이 있는가?

스마트폰 디스플레이의 픽셀 하나를 맞추기 위해, 혹은 영상 타임라인 위에서 1프레임(0.016초) 단위로 미세하게 어긋나는 글자의 자간과 베지어 이징 곡선을 뜯어고치며 밤을 새워본 적이 있는가?

글자가 가만히 서 있지 않고 비트의 어택에 맞춰 튀어 오르고, 산산이 흩어졌다가 다시 서늘한 문장으로 수렴하는 순간.

2025년의 나는 이 질문 하나를 붙들고 키보드를 두드렸다. 처음부터 거창한 영상 시스템을 만들 생각은 아니었다. 한 줄의 텍스트를 조금 더 까리하게 보여주고 싶었을 뿐인데, 어느 순간 splitText, stagger, letterSpacing, frame을 붙잡고 밤을 새우는 사람이 되어 있었다.

출발점: 웹 애니메이션의 감각을 다시 깨우기

과거 나는 GSAP과 HTML5 Canvas, CSS3를 쥐어짜며 150KB라는 극단적인 용량 제한 안에서 가장 유려한 인터랙션과 모션을 뽑아내는 웹 배너/인터랙티브 개발을 했었다. 하지만 2024년 대학원 복학 이후 연구와 이론에 치이면서 손끝의 모션 감각이 녹슬어가는 것을 뼈저리게 느꼈다.

2025년, 나는 녹슨 감각을 강제로 깨우기 위해 GSAP, React, TypeScript, Remotion을 한 테이블 위에 올려두고 다시 연결하기 시작했다.

키네틱 타이포그래피는 단순히 글자에 opacity를 주는 일이 아니었다. 문장을 글자 단위로 분해하고, 각 글자의 위치와 속도, 간격, 방향을 계산한 뒤, 음악과 화면의 타이밍에 맞춰 다시 조립해야 했다. 키네틱 타이포그래피(Kinetic Typography)는 단순히 CSS에 transition: all 0.3s ease를 걸거나 텍스트의 opacity를 깜빡이는 수준의 장난질이 아니다.

문장을 음절과 글자, 글리프(Glyph) 단위의 데이터로 분해하고,
각 글자의 3차원 위치, 각도, 속도, 스케일, 지연(Stagger) 값을 물리 공식처럼 계산한 뒤,
사운드의 트랜지언트(Transient)와 화면의 프레임 레이트에 완벽하게 동기화해 재조립하는 **‘시간 축의 아키텍처’**다.

Title06Motion

ChaoticTypo01

KineticSamples

1. 짧은 실험을 반복하는 방식

처음부터 3분짜리 풀스크린 뮤직비디오를 만들겠다는 허황된 목표를 잡았다면 3일 만에 번아웃으로 폭사했을 것이다. 대신 나는 전략을 바꿨다. “하루에 딱 한 가지 움직임만 격리해서 만든다.”

길고 완벽한 영상 대신, 단 하나의 모션 로직을 컴포넌트로 분리해 구현하고, 왜 프레임이 튀는지, 왜 브라우저 렌더링과 비디오 익스포트의 타이밍이 어긋나는지 그 실패 원인을 집요하게 기록했다.

Day1Remotion

Day2Remotion

Day3Remotion

Day4Sketch

Day6Motion

Day7Remotion

Day7Sketch

Day11

Day12Motion

Day13Motion

Day14Motion

Day15Remotion

Day17Motion

Day18Motion

Day19Motion

Day20Motion

Day23

Day21Remotion

Day22Remotion

Day24Motion

Day26Remotion

Day28Sketch

SketchDay29

Day30Sketch

Day34Remotion

Day37Motion

Day40Remotion

Day41Motion

Day 51

Day54Remotion

Day55Remotion

Day62Remotion

Day68Remotion

Day71Sketch

Day72Sketch

Day73Sketch

Day75Sketch

Day78Sketch

Day79Sketch (Need to de-bug)

이 반복은 단순한 100일 챌린지가 아니었다. 같은 문제를 작은 크기로 계속 만져보며, 어떤 로직이 재사용되고 어떤 로직이 특정 장면에만 묶이는지 확인하는 리서치였다. 수십 개의 스케치를 매일 빌드하고 깨뜨리면서, “어떤 모션 로직이 재사용 가능한 범용 시스템(Core System)이 되고, 어떤 로직이 특정 장면에만 묶이는 일회성 쓰레기인가?” 를 철저히 분류하는 기술 리서치이자 R&D 과정.

2. 작업별 기술 방식과 아키텍처 (Technical Anatomy)

매일 쌓아 올린 실험들은 점차 구조화된 파이프라인과 모션 라이브러리로 승화되었다.

1) Chaotic Typography: 무질서 속의 질서 계산

텍스트 문자열을 AST(추상 구문 트리)처럼 다루어 커스텀 splitText() 유틸리티로 분해했다. 각 글자에 난수 시드(Seed) 기반의 3D 진입 궤적(X, Y, Z 회전 및 Translate), 스태거 지연 시간, 스프링 댐핑 값을 부여했다.

GSAP: 초기 아이디어 검증 및 브라우저 내 빠른 인터랙션 튜닝.
Remotion: useCurrentFrame()과 interpolate(), spring()을 활용하여 비디오 렌더링 엔진에 최적화된 프레임 결정론적(Deterministic) 수식으로 이식.

2) Remotion 기반 데이터 구동형 타이포그래피 파이프라인

타임라인 하드코딩을 완전히 걷어냈다. 자막 데이터(SRT / JSON)를 파싱하여 컴포지션 내부에서 현재 프레임 위치에 따라 능동적으로 렌더링되도록 설계했다.

Remotion의 Composition 안에서 자막 구간을 데이터로 읽고, 시작 프레임과 종료 프레임 사이의 진행률을 계산했다. useRef는 자막 인덱스가 바뀔 때 애니메이션 시작점을 기억하는 데 사용했다.

SRT / text data
  -> parseSrt()
  -> subtitle object
  -> splitText()
  -> motion variant
  -> frame interpolation
  -> Remotion Composition

[ Raw Data Layer ]
SRT / VTT / JSON Text Stream
        │
        ▼ (parseSrt / Data Normalizer)
[ Subtitle Object Tree ]
{ id, startFrame, endFrame, text, stylePreset }
        │
        ▼ (splitText & Tokenizer)
[ Character / Word Tokens ]
        │
        ▼ (Motion Variant Engine)
useCurrentFrame() ──► interpolate() / spring() Math
        │
        ▼ (Layout & Skin Engine)
React Flex/Grid + CSS Custom Properties (Tokens)
        │
        ▼ (Renderer)
Remotion Composition (60 FPS Deterministic Output)

useRef를 영리하게 활용하여 자막 인덱스가 변경되는 순간의 프레임 스탬프를 캡처하고, 이전 모션의 잔상이 남지 않도록 완벽한 스테이트 클린업을 보장했다.

3) 모션 샘플 카탈로그 (The Motion Catalog)

수개월간의 프로토타이핑을 거쳐 언제든 프로덕션 레벨로 꺼내 쓸 수 있는 13가지 핵심 모션 패턴이 구축되었다.

AnimatedList: 데이터 리스트의 유기적 슬라이드 인/아웃.
BounceText: 바운스 물리를 적용한 글자별 탄성 등장.
BubblePopText: 스케일 오버슈트(Overshoot) 기반 팝업.
CardFlip: 3D Perspective를 이용한 카드 뒤집기 타이포.
FloatingBubbleText: 부유하는 노이즈 벡터 필드 타이포그래피.
GeometricPatterns: 기하학적 도형과 결합된 마스킹 모션.
GlitchText: RGB 채널 분리와 난수 슬라이스 글리치.
LiquidWave: 사인파(Sine Wave)를 타고 흐르는 유기적 웨이브.
MatrixRain: 수직 스트림 텍스트 디스플레이.
ParticleExplosion: 글자가 입자로 폭발하며 흩어지는 물리 시뮬레이션.
PulsingText: 오디오 엔벨로프에 반응하는 맥박 모션.
SlideText: 방향 제어형 스태거 슬라이드.
TypewriterSubtitle: 한글 음소 분리 및 커서 블링크 자막.

AnimatedList / BounceText / BubblePopText / CardFlip / FloatingBubbleText / GeometricPatterns

LiquidWave / MatrixRain

ParticleExplosion

PulsingText

SlideText

TypewriterSubtitle

3. 실패 로그가 아키텍처가 되다: Browser rAF vs Deterministic Frame Math

처음에는 GSAP과 Remotion을 한 파일 안에서 같이 돌렸다. 브라우저의 requestAnimationFrame과 Remotion의 프레임 렌더링은 타이밍 모델이 달랐고, 프리뷰에서는 맞는 것처럼 보여도 최종 렌더링에서 어긋났다.

결과는 처참했다. 프리뷰 화면(브라우저의 requestAnimationFrame)에서는 물 흐르듯 부드럽던 모션이, Remotion의 헤드리스 크로미움(Puppeteer) 기반 프레임 바이 프레임 렌더링을 거치면 싱크가 2~3프레임씩 밀리거나 글자가 공중에서 찢어지는 대환장 사태가(브라우저 rAF의 가변 프레임레이트를 맹신한 내 탓이 크지) 발생했다.

그래서 **모션의 책임을 계층별로 완전히 분리(Decoupling)**했다.

레이어	역할	핵심 기술
Input	SRT, VTT, JSON, 메타데이터, 오디오 파형 관리	Pure JSON, TypeScript Interfaces
Parser	타임코드 동기화 및 문자열 토큰화 (`splitText`)	Custom Lexer, Hangul Disassembler
Motion	Frame 기반 수학 계산 (`interpolate`, `spring`)	Remotion Native Math / GSAP (for Web preview only)
Layout	반응형 글자 배치, Auto Layout 변환, 오버레이	React JSX, Flex/Grid, CSS Variables
Render	결정론적 60FPS 버퍼 출력 및 인코딩	Remotion Headless Renderer, FFMPEG

GSAP은 빠른 아이디어 검증과 브라우저 기반 프로토타이핑에 남겼고, 영상 출력이 필요한 로직은 Remotion-native 코드로 옮겼다. (한 번에 다 갈아엎었다가 같이 폭사하는 것보다는 레이어를 나누는 게 낫다.)

[!IMPORTANT] 브라우저의 모션과 비디오 렌더러의 모션은 완전히 다른다. 웹은 가변 프레임레이트(Delta Time) 위에서 눈속임을 하지만, 비디오 익스포트는 절대적인 정수 프레임 번호(frame: number) 여야 한다.

4. Kinetic Motion에서 Type Mix로: 실험을 ‘시스템’과 ‘제품’으로 진화

수십 개의 스케치를 쌓다 보니 극심한 현타가 찾아왔다. “언제까지 VS Code 열고 자간 수치 12px을 14px로 바꾸고, durationInFrames를 30에서 45로 고치며 빌드 버튼을 누르고 앉아 있을 것인가?”

개발자로서 매번 코드를 복사하고 숫자만 바꾸는 노가다를 반복하는 것은 견딜 수 없는 낭비였다.

키네틱 실험을 반복하다 보니 매번 코드를 복사하고 숫자만 바꾸는 일이 너무 신물이 났다. 글자 분해 방식, 등장 방향, 자간, 속도, 컬러, 블렌딩 모드를 GUI에서 조정하고, 그 값을 props와 schema로 연결하면 어떨까?

글자 분해 모드 (글자별 / 단어별 / 음절별)
모션 프리셋 (Bounce, Glitch, Liquid, Slide)
자간, 이징 곡선, 물리 댐핑, 컬러 팔레트, 블렌딩 모드

이 모든 것을 Figma의 디자인 시스템처럼 직관적인 GUI 인터페이스로 조작하고, 그 결과가 실시간으로 React Props와 JSON Schema로 컴파일되어 Remotion을 구동하게 만들 수 없을까?

이 질문이 바로 나의 자체 프로덕션 툴인 Type Mix의 출발점이었다.

피그마에서 만든 레이아웃과 타이포그래피 사례를 먼저 나열하고, 공통 속성은 GUI 컨트롤로 묶었다. 공통되지 않는 실험값은 텍스트 입력으로 props를 전달하는 구조를 구상했다. Figma에서 모션 케이스 스터디와 인터랙션 상태(Default, Hover, Active, Ghost)를 Variant 매트릭스로 정리했다. 디자인 시스템의 토큰 구조(Primitive -> Semantic -> Component)를 모션 파라미터에 그대로 적용했다.

Texture Mix에서 구현하던 키네틱 랩을 타이포그래피 쪽으로 확장했다. 목표는 하나의 거대한 애니메이션을 자동 생성하는 것이 아니라, 여러 variant를 조립해 나만의 모션을 빠르게 큐레이션하는 것이었다.

Texture Mix의 셰이더/텍스처 랩에서 검증했던 노하우를 타이포그래피 영역으로 이식했다. 나의 목표는 상투적인 AI 자동 생성 툴 따위가 아니었다. 디렉터인 내가 설계한 정교한 Variant들을 마치 신디사이저의 노브를 돌리듯 조립하여 최적의 모션을 큐레이션하는 도구 를 만들고자 함이다.

Photoshop, After Effects, Cavalry의 직관적인 조작 방식을 참고하되, 내부 결과는 TypeScript props와 Remotion 컴포넌트로 연결했다. After Effects의 타임라인 조작감, Cavalry의 모션 그래픽 절차적(Procedural) 접근, Jitter의 깔끔한 웹 GUI를 벤치마킹하여 나만의 컨트롤 패널을 구축했다.

공통 props를 GUI로 조정하고, 섹션별로 다른 애니메이션을 지정하는 방식이다.

공통 Props는 전역 GUI 컨트롤러로 통제하고, 트랙별 세부 애니메이션은 슬롯 형태로 주입하는 구조. 이 시스템은 아직 개발중이지만 추후 완성된다면 모션 제작 속도는 기존의 코드 하드코딩 대비 몇 배 이상 단축되지 않을가 기대한다.

Type Mix 시스템 구축의 상세 아키텍처:
KR-my-own-production-tool-type-mix

5. 프로덕션 스케일로의 확장: Lyrics MV Projects와 MV 시스템으로

2025년의 Kinetic Motion 실험은 독립적인 스케치 모음으로 끝나지 않았다. TypewriterSubtitle은 Lyrics MV의 자막 컴포넌트가 되었고, splitText와 Stagger 로직은 가사 한 줄을 글자별로 움직이는 기반이 되었다.

TypewriterSubtitle과 ChaoticTypo 로직은 고해상도 타이포그래피 뮤직비디오 프로젝트의 핵심 자막 엔진이 되었다.
splitText와 Stagger 알고리즘은 가사 한 줄의 감정선에 맞춰 글자가 호흡하도록 만드는 다이내믹 가사 렌더러로 진화했다.
Remotion의 Frame Math는 WebGL GLSL 셰이더의 시간 변수(u_time), 오디오 DSP 분석을 통해 추출한 RMS/BPM 데이터와 한 타임라인 위에서 맞물렸다.

Remotion의 frame 기반 계산은 SRT 타임코드와 결합했고, 이후 WebGL 텍스처와 오디오 이벤트까지 같은 타임라인에 얹혔다. 이렇게 키네틱 타이포그래피는 Chroma Drift와 Niji의 화면 언어로 확장되었다.

이 모든 실험적 자산들이 한데 엮이며 Chroma Drift와 Niji 같은 풀스케일 뮤직비디오 프로덕션의 시각적 언어로 폭발했다.

KR-Lyrics-MV-Projects

더 넓은 전체 실험의 흐름은 KR-All-experiments-combined-into-making-MVs로 이어진다.

에필로그: 코드는 글자에 시간을 부여한다

수많은 밤을 지새우며 코드로 글자를 흔들고 쪼개면서 내가 깨달은 것은 단순한 CSS 트릭이나 Remotion API 사용법이 아니었다. 어떤 값이 반복되는지, 어떤 변형이 의미 있는지, 어느 지점에서 GUI가 필요하고 어느 지점에서 직접 코드를 써야 하는지를 배웠다.

곡의 박자와 가사의 정서를 관객의 망막에 어떻게 꽂아 넣을 것인가에 대한 명확한 디렉팅 의도, 그리고 그 의도를 한 치의 오차도 없는 데이터 구조와 프레임 계산으로 번역해 내는 단단한 코드 아키텍처의 결합에서 나온다.

어떤 모션 파라미터가 감정의 고조를 만들고,
어떤 타이밍의 지연(Delay)이 시청자의 시선을 붙잡으며,
어느 지점까지를 GUI 툴로 추상화하고, 어느 지점부터 디렉터가 코드레벨로 직접 개입해야 하는가에 대한 ‘경계의 감각’

결국 좋은 모션 시스템은 화려한 효과의 모음이 아니다. 관객에게 어떤 리듬과 감정을 전달할지 먼저 정하고, 그 의도를 파일 구조와 데이터, 프레임 계산으로 번역하는 아키텍처다.

자동화는 버튼 하나로 끝나지 않는다. 현장의 제약 조건을 이해하고 맥락을 통제하는 도메인 전문가, 즉 인간 디렉터가 있어야 비로소 코드가 제대로 춤을 춘다.

키네틱 모션이 실제 뮤직비디오로 구현된 기록:
KR-Lyrics-MV-Projects

음악, 코드, 텍스처, 3D가 결합된 전체 파이프라인의 총체:
KR-All-experiments-combined-into-making-MVs

Kinetic Motion In Codes: 2025년, 글자가 움직이기 시작한 기록

Kinetic Motion In Codes: 2025년, 글자가 움직이기 시작한 기록

출발점: 웹 애니메이션의 감각을 다시 깨우기

1. 짧은 실험을 반복하는 방식

2. 작업별 기술 방식과 아키텍처 (Technical Anatomy)

1) Chaotic Typography: 무질서 속의 질서 계산

2) Remotion 기반 데이터 구동형 타이포그래피 파이프라인

3) 모션 샘플 카탈로그 (The Motion Catalog)

3. 실패 로그가 아키텍처가 되다: Browser rAF vs Deterministic Frame Math

4. Kinetic Motion에서 Type Mix로: 실험을 ‘시스템’과 ‘제품’으로 진화

5. 프로덕션 스케일로의 확장: Lyrics MV Projects와 MV 시스템으로

에필로그: 코드는 글자에 시간을 부여한다

Related Articles