My Own Production Tools for My MVs: Lyrics MV를 위한 개인 제작툴의 진화

My Own Production Tools for My MVs

Lyrics MV를 만들기 위해 툴부터 만들게 된 이유

처음부터 나만의 영상 제작툴을 만들 생각은 없었다. 그냥 Lyrics MV를 만들고 싶었다. 노래의 한 구절이 나타나고, 글자가 박자에 맞춰 흔들리고, 이미지와 배경 텍스처가 보컬의 감정선에 따라 바뀌는 영상을 만들고 싶었다.

그런데 실제 작업은 곧 다음과 같은 반복으로 변했다.

1. Figma에서 장면과 타이포그래피를 설계한다.
2. Jitter나 Cavalry에서 움직임을 대략 확인한다.
3. Remotion과 TypeScript로 컴포넌트를 만든다.
4. WebGL이나 GLSL로 질감을 얹는다.
5. 프리뷰에서 확인한다.
6. 마음에 들지 않으면 코드를 다시 수정한다.
7. 다시 렌더링한다.
8. 다른 자막과 다른 이미지에도 같은 과정을 반복한다.

한두 장면이면 괜찮다. 하지만 가사 한 곡에 수십 개의 자막 구간과 여러 개의 전환, 이미지, 텍스처, 타이포그래피 패턴이 들어가면 이야기가 달라진다. 매번 props를 직접 수정하고, shader를 다시 컴파일하고, 레이아웃을 다시 잡고, Remotion 프리뷰를 다시 확인하는 작업은 창작보다 관리에 가까워졌다.

그래서 질문이 바뀌었다.

“어떻게 효과를 만들까?”에서 “어떻게 효과를 탐색하고, 저장하고, 다시 영상에 주입할까?”로.

이 질문에서 Kinetic Type Mix, Texture Mix, Background Mix가 시작되었다. 이 도구들은 일반 사용자를 위한 범용 편집앱이 아니다. 내가 Lyrics MV의 스토리보드를 만들고, 효과를 비교하고, 최종적으로 Remotion Composition에 옮기기 위해 만든 개인 제작 환경이다.

먼저 구분해야 할 것: 완성된 제품이 아니라 제작 시스템의 축적

이 문서에는 실제 구현, 프로토타입, 후대의 아키텍처 설계가 함께 들어 있다. 따라서 각 작업의 상태를 다음처럼 구분한다.

특히 세 도구의 문서 메타데이터는 모두 2025-05-20으로 남아 있지만, 현재 첨부된 화면과 세부 기능 정의 중 일부는 2026년의 회고와 R&D 문서에서 보강되었다. 그러므로 2025년에 이미 완성된 제품이 있었다고 쓰기보다는, 2025년에 필요성이 생겼고 이후 설계가 구체화되었다고 기록하는 편이 정확하다.

시간순 발전 과정

이 흐름에서 중요한 것은 도구가 갑자기 등장했다는 점이 아니다. 같은 문제를 여러 MV와 여러 그래픽스 실험에서 반복해서 만지다가, 문제 자체가 도구의 기능 목록으로 바뀌었다는 점이다.

1. Kinetic Type Mix

가사를 움직임의 입력 데이터로 바꾸기

Lyrics MV에서 텍스트는 자막이면서 동시에 주연 배우다. 단순히 SRT를 읽어 화면 아래에 출력하는 것만으로는 내가 원하는 영상을 만들 수 없었다. 한 문장은 글자별로 나뉘고, 단어별로 stagger가 들어가며, 때로는 여러 줄로 분리되고, 어떤 문장은 marquee처럼 이동하거나 stacking된 상태로 파동을 만들어야 했다.

초기 구조는 다음과 같았다.

SRT
 └─ parseSrt()
     └─ SrtSubtitle[]
         └─ useSubtitleKineticGrid()
             ├─ TypewriterSubtitle
             ├─ KineticGrid
             └─ motion timing
                 └─ Remotion Composition

시작 목적

• 자막을 글자·단어·줄 단위의 모션 데이터로 바꾸기
• 동일한 텍스트 애니메이션을 여러 곡에서 재사용하기
• Figma에서 만든 비주얼 방향을 실제 props로 번역하기
• 타이포그래피 샘플을 한 화면에서 비교하고 스토리보드에 선택하기
• 매번 새로운 TSX 컴포넌트를 하드코딩하는 일을 줄이기

2025년의 초기 작업에서는 TypewriterSubtitle, KineticGrid, HalftoneShader, parseSrt, subtitleHelpers, useSubtitleKineticGrid 같은 부품을 만들었다. 자막 애니메이션이 다음 구간에서 다시 시작되지 않는 문제는 subtitleIndex, React key, useRef를 이용해 컴포넌트 생명주기를 제어하는 방식으로 해결했다.

const getTileKey = (row: number, col: number) => {
  return `${row}-${col}-${currentSubtitle?.index ?? 'empty'}`;
};

자막이 바뀌면 key도 바뀌고, React는 이전 자막의 상태를 그대로 재사용하지 않고 새 컴포넌트를 만든다. 별것 아닌 것처럼 보여도, 프레임 기반 타이포그래피에서는 이 작은 상태 관리가 전체 애니메이션의 시작점을 결정한다.

Type Mix의 UI 방향

Type Mix는 포토샵, After Effects, Cavalry 같은 기존 툴의 직관적인 타이포그래피 작업 방식을 참고하되, 최종 결과를 코드와 연결하는 방향으로 설계했다.

Figma에서 만든 디자인 샘플을 먼저 나열하고, 각 샘플이 어떤 컴포넌트와 props 조합으로 변환될 수 있는지 기록한다. 여기서 Figma는 단순한 시각 레퍼런스가 아니라 모션 컴포넌트의 명세를 합의하는 보드가 된다.

Type Mix 내부에는 다음과 같은 기능 그룹이 필요했다.

초기 UI에서는 Stack과 Marquee가 서로 종속되어 있거나, Sequence가 한 레이어를 덮어쓰는 방식으로 동작하는 문제가 있었다. 2026년 3월의 기록에서는 다음을 별도의 요구사항으로 다시 정리했다.

• Stack은 한 줄 복제가 아니라 사용자가 지정한 row × column 구조를 지원해야 한다.
• Marquee는 Stack과 독립적인 옵션이어야 한다.
• Sequence는 새로운 레이어를 덮는 기능이 아니라 장면 안에서 여러 텍스트 이벤트를 이어 붙이는 기능이어야 한다.
• \n은 문자열로 출력되지 않고 실제 줄바꿈 규칙으로 처리되어야 한다.
• x, y 위치는 고정 픽셀뿐 아니라 퍼센트와 비율로 지정할 수 있어야 한다.
• 텍스트뿐 아니라 이미지, SVG, div, HTML element도 동일한 모션 매개체로 받을 수 있어야 한다.

이 요구사항은 단순한 UI 개선이 아니다. 디자이너가 생각하는 “한 장면의 구성”을 개발자가 실행할 수 있는 데이터 구조로 번역하는 작업이다.

Type Mix의 아키텍처

graph TD
    A[Text / Image / SVG / HTML Element] --> B[Input Normalizer]
    B --> C[Token and Line Splitter]
    C --> D[Motion Variant Engine]
    D --> E[Stack / Marquee / Sequence]
    E --> F[Frame Timing]
    F --> G[Preview Catalog]
    F --> H[Remotion Export Schema]

작업별 기술 방식과 도입 방식

이미지·아이템 목록

• Figma 타이포그래피 보드
• Kinetic Lab UI
• Stack Grid Preview
• Marquee Preview
• Sequence Timeline
• TypewriterSubtitle
• KineticGrid
• BackgroundClipText
• CyberGlitch
• ChaoticFlyIn
• AnimatedList
• BounceText
• BubblePopText
• CardFlip
• LiquidWave
• MatrixRain
• ParticleExplosion
• PulsingText
• SlideText

Type Mix는 현재 완전히 범용적인 편집툴로 안정화된 제품이라기보다, 키네틱 타이포그래피를 어떻게 선언적 설정으로 바꿀지 검증하는 제작 실험실에 가깝다. 특히 Sequence, Stack, Marquee, Separator의 의미를 명확하게 분리하는 것이 다음 단계다.

관련 기록: KR-my-own-production-tool-type-mix
관련 기록: [[ 2026-03-18-note ]]

2. Texture Mix

WebGL 기반 질감 레이어를 조합하는 도구

Texture Mix는 이미지와 비디오에 CRT, VHS, Noise, Dithering, Halftone, Glitch 같은 질감을 적용하고, 그 결과를 실시간으로 비교하기 위한 도구다.

Remotion 프리뷰에서 코드를 직접 수정하며 결과를 확인하는 방식은 너무 느렸다. 특히 WebGL shader는 작은 uniform 값 하나만 바꿔도 화면의 인상이 완전히 달라진다. intensity, speed, distortion, rgbOffset, dotSize, seed를 매번 코드에 직접 입력하는 방식은 작업 속도와 큐레이션 감각을 모두 떨어뜨렸다.

시작 목적

• CRT 모니터와 VHS 질감을 빠르게 비교하기
• 여러 micro-fragment effect를 레이어처럼 조합하기
• 이미지와 비디오를 같은 텍스처 입력으로 테스트하기
• 효과의 파라미터를 schema로 저장하기
• 선택한 설정을 Remotion Composition에 다시 주입하기
• 매번 export하지 않고 한 화면에서 여러 결과를 비교하기

직접 그린 팬아트를 Texture Mix에 넣고, 서로 다른 파라미터를 적용해 질감을 비교하는 방식이다.

여기서 중요한 것은 Texture Mix가 최종 영상을 직접 만드는 완성형 편집기가 아니라는 점이다. 기존의 효과 앱은 GUI에서 값을 조정한 뒤 하나의 영상 파일을 export한다. 하지만 내 MV 작업에서는 같은 효과라도 음악의 구간과 비트, 자막, 장면의 감정선에 따라 프레임마다 강도가 달라져야 한다.

따라서 필요한 것은 다음과 같은 흐름이다.

Image / Video
    ↓
Texture Mix Preview
    ↓
Shader Layer Combination
    ↓
Parameter Schema
    ↓
Remotion Props / Uniforms
    ↓
Frame-based Rendering

Texture Mix의 기술적 구조

graph TD
    A[Image or Video Input] --> B[Texture Loader]
    B --> C[Universal Shader Wrapper]
    D[Shader Library] --> C
    E[Parameter Schema] --> C
    C --> F[Micro Fragment Layers]
    F --> G[Blend and Composite]
    G --> H[Preview Grid]
    G --> I[Remotion Video Output]

후대의 R&D 문서에서는 이 구조가 UniversalShaderWrapper, shaders.ts, schemas.ts, Showcase.tsx로 더욱 구체화된다.

ShaderToy에서 가져온 것과 다시 만든 것

ShaderToy의 효과를 참고할 때는 mainImage, fragCoord, iTime, iChannel0를 그대로 붙여 넣지 않았다. Remotion과 Three.js/R3F 환경에 맞게 다음과 같이 변환했다.

Texture Mix에 필요한 효과 아이템은 다음처럼 분류할 수 있다.

헤이세이 VHS 필터처럼 특정 시대의 화면 질감을 만들기 위해 ShaderToy와 WebGL 예시에서 프로세싱 패턴을 참고했다. 중요한 것은 소스를 그대로 소유한다고 주장하는 것이 아니라, 공개된 시각적·기술적 패턴을 학습하고 내 Remotion 파이프라인의 제약에 맞게 다시 조립하는 것이다.

Texture Mix의 핵심 아키텍처 원칙

1. Configuration over Code: 효과마다 새로운 컴포넌트를 만드는 대신 설정으로 선택한다.
2. Deterministic Time: requestAnimationFrame 대신 Remotion의 frame을 시간 기준으로 사용한다.
3. Schema Validation: uniform과 props의 범위를 검증하고 clamp한다.
4. Preview First: 실제 렌더링 전에 여러 조합을 시각적으로 비교한다.
5. Single Source of Truth: GLSL 자산, 파라미터, 프리셋의 위치를 분리한다.
6. Render Environment Awareness: 브라우저와 headless Remotion 렌더링의 차이를 고려한다.

관련 기록: KR-my-own-production-tool-texture-mix
관련 기술 문서: remotion-vfx-shader-patterns.md
관련 기술 문서: MoShaderRnD-technicalGuide.md

3. Background Mix

Shader 기반 Background Maker

Background Mix 또는 Background Maker는 특정 이미지에 효과를 입히는 Texture Mix와 달리, 처음부터 영상의 배경이 될 수 있는 procedural shader background를 만들기 위한 도구다.

Lyrics MV의 배경은 단순한 색상판이 아니다. 인물이 등장하기 전의 분위기를 만들고, 자막이 올라갈 빈 공간을 확보하고, 다음 장면으로 넘어갈 때 시각적 속도를 조절해야 한다. 그래서 배경은 다음의 조합으로 설계된다.

• procedural gradient
• noise field
• displacement
• chromatic aberration
• grid and geometric pattern
• neon glow
• VHS grain
• dithering palette
• horizontal or vertical movement

시작 목적

• Figma 스토리보드에 넣을 배경 후보를 빠르게 만들기
• WebGL shader background를 여러 설정으로 비교하기
• 정적인 이미지가 아니라 시간에 따라 변화하는 배경 만들기
• 선택한 파라미터를 Remotion schema로 옮기기
• Lyrics MV의 장면별 배경과 자막 레이어를 분리하기

Background Maker의 기본 사용 흐름은 다음과 같다.

Background Preset
    ↓
GUI Parameter Preview
    ↓
Shader Uniform Selection
    ↓
Storyboard Still / Preview
    ↓
Remotion Schema
    ↓
Scene Background Layer

이 도구는 특히 스토리보드 제작에서 유용하다. 먼저 1920×1080 프리뷰를 여러 장 뽑고, Figma에서 타이포그래피와 이미지 애셋을 배치한다. 그 다음 “이 배경이 가사의 어느 구간에 맞는가?”를 확인한다.

즉 Background Mix의 결과는 단순한 shader 캔버스가 아니다. 배경 후보와 장면의 감정적 역할을 함께 큐레이션하는 보드다.

작업별 기술 방식과 도입 방식

2026년의 후대 R&D에서는 DPR mismatch, ThreeCanvas, preserveDrawingBuffer, useLayoutEffect, uniform mutation 같은 렌더링 안정화 규칙이 추가되었다. 이는 Background Mix가 단순한 브라우저 데모가 아니라 최종 영상에 들어갈 수 있어야 한다는 요구에서 나온 보강이다.

4. 세 도구를 연결하는 전체 제작 아키텍처

세 도구는 각각 다른 UI를 갖지만, 최종적으로는 같은 데이터 흐름에 연결된다.

graph TB
    A[Audio / Vocal / Beat Events] --> B[SRT and Timeline Data]
    B --> C[Lyrics Scene Schema]
    C --> D[Kinetic Type Mix]
    C --> E[Texture Mix]
    C --> F[Background Mix]
    D --> G[Preview Catalog]
    E --> G
    F --> G
    G --> H[Figma Storyboard]
    H --> I[Approved Scene Config]
    I --> J[Remotion Composition]
    J --> K[WebGL / GLSL / CSS / SVG]
    K --> L[Frame Accurate MV]

공통 데이터 계약

interface MotionAssetConfig {
  id: string;
  type: 'text' | 'image' | 'svg' | 'video' | 'background';
  startFrame: number;
  endFrame: number;
  position?: {
    x: number | string;
    y: number | string;
    width?: number | string;
    height?: number | string;
  };
  motion?: {
    variant?: string;
    stagger?: number;
    easing?: string;
  };
  effects?: {
    shaderType?: string;
    intensity?: number;
    blendMode?: string;
  };
}

실제 구현은 프로젝트마다 다르지만, 도구들의 방향은 이와 같은 입력 → 설정 → 프리뷰 → 승인 → 렌더링 구조를 향한다.

역할 분담

5. 왜 기존 편집툴만으로 끝내지 않았나

After Effects, DaVinci Resolve, Cavalry는 각각의 장점이 있다. 한 장면을 빠르게 다듬거나, 수동으로 키프레임을 조정하거나, 완성된 footage를 편집하는 데는 전문 편집툴이 훨씬 효율적이다.

내가 개인 제작툴을 만든 이유는 편집툴이 부족해서가 아니다. 내 작업의 반복 단위가 편집툴의 프로젝트 파일과 달랐기 때문이다.

내가 반복해서 처리해야 했던 것은 다음과 같았다.

• SRT에 있는 여러 자막 구간
• 곡마다 달라지는 텍스트 길이
• 보컬과 비트의 프레임 위치
• 같은 shader의 구간별 intensity 변화
• 한 scene 안의 여러 layout variant
• 2×2 또는 4×3 프리뷰 비교
• Figma에서 결정한 장면의 시각적 순서
• 동일한 컴포넌트를 다른 MV에서 재사용하는 일

일반 편집툴에서 이 작업을 매번 수동으로 반복하면, 효과를 찾는 시간보다 export와 재조합에 더 많은 시간을 쓰게 된다. 반대로 코드만으로 모든 것을 해결하려고 하면, 작은 시각적 조정마다 개발 루프를 다시 돌아야 한다.

그래서 나에게 필요한 방식은 하이브리드였다.

Figma       = 시각적 방향과 스토리보드
Jitter      = 빠른 모션 스케치
Cavalry     = 레이아웃·모션 프로토타이핑
TouchDesigner = 효과와 footage 실험
Type Mix    = 키네틱 타이포그래피 프리뷰
Texture Mix = WebGL 질감 프리뷰
Background Mix = procedural 배경 프리뷰
Remotion    = 데이터 기반 최종 컴포지션
Video Editor = 최종 편집과 필요한 수동 마감

이 구조는 “모든 것을 코드로 만들겠다”는 선언이 아니다. 오히려 각 도구가 잘하는 일을 구분하고, 그 사이의 변환 비용을 줄이려는 설계다.

6. Labs — Personal Production Tools로 이어지는 다음 단계

세 도구의 공통 목표는 하나다.

내가 만든 시각적 아이디어를 다시 사용할 수 있는 형태로 저장하는 것.

Texture Mix는 shader를 preset과 schema로 바꾸고, Type Mix는 타이포그래피 모션을 variant와 sequence로 바꾸며, Background Mix는 procedural background를 scene asset으로 바꾼다.

이것이 다음 아티클인 [Labs — Personal Production Tools]로 이어진다.

반복되는 장면 작업
      ↓
공통 패턴 추출
      ↓
컴포넌트 분리
      ↓
파라미터 노출
      ↓
GUI 프리뷰
      ↓
Schema / Preset 저장
      ↓
Remotion에 재주입

후대의 R&D 문서에서는 이 방향이 다음 구조로 더 구체화된다.

• UniversalShaderWrapper: WebGL lifecycle을 감추는 공통 래퍼
• schemas.ts: shader type과 parameter의 데이터 계약
• shaders.ts: GLSL 자산의 중앙 레지스트리
• Showcase.tsx: 4×3 또는 4×4 Mega Grid 프리뷰
• TextureLab: 프레임 정확한 WebGL 재생과 shader 실험
• ShaderFormulator: 파라미터와 셰이더 조합을 구성하는 방향
• LyricsMV Design Bridge: 가사, 장면, 컴포넌트, 승인, export를 연결하는 방향

이후에는 단순한 “효과 선택”을 넘어, 다음과 같은 프로젝트 export가 필요해진다.

{
  "projectName": "Chroma Drift",
  "globalSettings": {
    "fps": 30,
    "totalFrames": 602
  },
  "scenes": [
    {
      "sceneId": "verse-01",
      "startFrame": 0,
      "endFrame": 180,
      "lyricsEntries": [
        {
          "text": "...",
          "componentId": "Typography/KineticWord",
          "motionLayers": [
            {
              "motionFnId": "typewriter",
              "params": { "duration": 18 }
            }
          ],
          "texture": {
            "shaderType": "vhs",
            "intensity": 0.42
          },
          "approvalState": "approved"
        }
      ]
    }
  ]
}

이런 데이터 구조가 있어야 Type Mix에서 고른 타이포그래피와 Texture Mix에서 고른 질감, Background Mix에서 고른 배경을 하나의 MV 장면에 연결할 수 있다.

관련 기록:

• KR-my-own-production-tool-type-mix
• KR-my-own-production-tool-texture-mix
• KR-my-own-production-tool-bg-maker
• LyricsMV_DesignBridge_Tool_Plan.md
• MoShader-Showcase-Evolution.md
• shader_integration_strategy.md

7. Lyrics MV Projects로 이어지는 실제 적용

개인 제작툴의 가치는 툴 자체의 기능 목록보다, 실제 MV에서 어떤 문제를 줄였는가로 판단해야 한다.

첫 번째 Lyrics Visualiser

• SRT를 자막 객체로 변환
• Typewriter 효과 적용
• 기본적인 SVG Filter와 CSS3 레이어 실험
• Remotion 30fps Composition으로 출력

Chroma Drift

• 직접 녹음한 보컬과 MR의 믹스
• 가사와 타이포그래피의 프레임 동기화
• WebGL background, glitch, VHS, halftone 실험
• Mondrian Grid, Bento Grid, Hero Scroll, Stagger 패턴 적용
• Texture Layer와 Kinetic Type의 분리

Niji

• 오디오, 자막, 이미지, 셰이더, 서사를 하나의 씬 구조로 오케스트레이션
• 에너지 피크와 SRT를 프레임 이벤트로 변환
• 키네틱 타이포그래피와 WebGL 텍스처를 같은 시간축에 배치
• 후대의 TextureMix, WebGLBackground, KineticTypography 컴포넌트 구조로 확장

이후의 확장

• Biiip, BTTF, Bye My Monster에 반복 모션을 재사용
• Video Stagger와 Freeze Frame 구조 확장
• 알파 비디오와 CSS mask를 이용한 장면 전환
• MIDI 기반 transition timing 검토
• 오디오 spectrum과 beat event를 모션 트리거로 활용

이 과정에서 제작툴은 최종 MV와 분리된 외부 제품이 아니라, MV 안에서 반복되는 패턴을 먼저 실험하는 개인 R&D 레이어가 된다.

관련 기록: KR-Lyrics-MV-Projects
관련 기록: KR-Lyrics-MV-Project-Compound-Convergent-Directing-Retrospective
관련 기록: KR-the-complete-lyrics-visualiser-mv-niji

8. All Experiments Combined into Making MVs

이 여정은 WebGL만의 이야기가 아니다.

드럼을 개조하며 MIDI 신호를 배웠고, DAW를 사용하며 오디오 레이어와 타이밍을 배웠고, Python과 머신러닝 실험을 통해 자동화의 한계를 배웠다. Figma와 UX 디자인 시스템을 통해 컴포넌트와 토큰을 배웠고, React와 TypeScript를 통해 그것을 코드 구조로 옮겼다.

그 경험들이 개인 제작툴 안에서 다시 만난다.

결국 세 도구는 각각 다른 것을 만드는 것처럼 보여도, 실제로는 하나의 변환 시스템이다.

graph LR
    A[Sound and Events] --> B[Time Schema]
    C[Visual References] --> D[Design Tokens]
    E[WebGL Experiments] --> F[Shader Presets]
    D --> G[Personal Production Tools]
    F --> G
    B --> G
    G --> H[Lyrics MV Scenes]
    H --> I[Remotion Render]

이것이 [All Experiments Combined Into Making MVs]로 이어지는 이유다. MV는 마지막에 갑자기 나타난 결과물이 아니라, 서로 다른 분야에서 축적한 작은 시스템들이 한 장면 안에서 함께 실행된 결과다.

관련 기록: KR-All-experiments-combined-into-making-MVs

9. 특별히 남겨두는 한계와 현실적인 결론

개인 제작툴을 만든다고 해서 작업이 자동으로 쉬워지는 것은 아니다. 오히려 처음에는 UI, schema, 프리뷰, export, 렌더링 검증까지 해야 하므로 일이 더 많아진다.

또한 모든 것을 GUI로 해결할 필요도 없다. Type Mix는 아직 Sequence와 Stack의 의미를 더 명확히 해야 하고, Texture Mix는 멀티패스와 메모리 관리, 브라우저와 headless 렌더링 차이를 계속 검증해야 하며, Background Mix는 다양한 장면에서 어떤 배경이 실제로 유용한지 더 많은 결과물이 필요하다.

그래서 현재의 결론은 타협에 가깝다.

• 반복되는 패턴은 도구로 만든다.
• 장면의 감정과 서사는 직접 디렉팅한다.
• shader는 라이브러리화하되, 무조건 모든 장면에 적용하지 않는다.
• GUI는 탐색을 빠르게 하지만, 최종 결과는 schema와 코드로 검증한다.
• AI는 boilerplate와 변환을 도울 수 있지만, 도구의 목적과 렌더링 조건을 대신 결정하지 못한다.
• 범용 제품을 만들기보다, 실제 제작에서 반복되는 friction을 먼저 줄인다.

결국 내가 만든 것은 “버튼을 누르면 MV가 나오는 자동화 앱”이 아니다. 그것보다 훨씬 작고, 동시에 훨씬 개인적인 것이다.

내가 반복해서 떠올린 이미지를 빠르게 실험하고, 비교하고, 기록하고, 다시 코드 기반 영상으로 가져오는 개인 제작 인프라.

에필로그: 툴을 만든다는 것은 내 작업 방식을 외부화하는 일

Kinetic Type Mix, Texture Mix, Background Mix를 만들며 알게 된 것은 내가 툴을 만드는 이유가 단순히 편해지고 싶어서가 아니라는 점이다.

나는 내 머릿속에 있는 모션의 규칙을 외부화하고 싶었다. 글자가 어떻게 흩어졌다가 모이는지, 질감이 어느 순간부터 과해지는지, 배경이 자막을 방해하지 않으면서도 장면의 감정을 어떻게 유지하는지. 이런 판단을 매번 처음부터 다시 하지 않기 위해 작은 도구와 schema를 만들었다.

2025년의 WebGL과 Remotion 실험이 렌더링의 조건을 알려주었다면, 이후의 개인 제작툴은 그 조건 위에서 창작 판단을 반복 가능한 시스템으로 바꾸는 작업이었다.

WebGL Experiments
      ↓
Reusable Components
      ↓
Preview Catalogs
      ↓
Personal Production Tools
      ↓
Lyrics MV Projects
      ↓
All Experiments Combined into Making MVs

다음 시리즈에서 다룰 것은 이 도구들이 실제로 어떤 파일 구조와 데이터 계약을 갖게 되었는지, 그리고 한 줄의 가사와 한 장의 이미지가 어떻게 하나의 MV scene으로 변환되는지다.

내가 만들고 싶은 것은 더 많은 기능이 아니다. 내가 이미 반복해서 만들고 있는 것들을, 다시 꺼내 쓸 수 있을 만큼 정확하게 정리하는 것이다.