From Fragments to Total Artwork: 흩어진 실험들이 하나의 작업이 되기까지

– ArtXTech

From Fragments to Total Artwork

흩어진 실험들이 하나의 작업이 되기까지

스무 살의 나에게 지금의 작업을 설명한다면 아마 이렇게 말했을 것이다.

고장 난 드럼을 고치고, MIDI 신호를 분석하고, Python으로 소리를 분류하고, React와 WebGL로 화면을 만들고, 결국 네 목소리로 커버곡을 녹음해 코드로 뮤직비디오를 만들게 될 거야.

아마 믿지 않았을 것이다. 나는 처음부터 종합예술을 만들겠다는 목표가 없었다. 그냥 집에서 드럼을 치고 싶었고, 좋아하는 곡을 리듬게임에서 연주하고 싶었고, 마음에 드는 화면을 직접 구현해 보고 싶었다.

그런데 각각의 작업은 끝나지 않고 다음 작업의 재료가 되었다.

  • 드럼 수리는 신호와 입력을 이해하게 했다.
  • MIDI는 소리를 이벤트의 집합으로 보게 했다.
  • DAW는 레이어와 시간축을 가르쳤다.
  • 오디오 분석은 감각을 수치와 시각화로 번역하게 했다.
  • 대학원 프로젝트는 데이터와 모델의 한계를 확인하게 했다.
  • GSAP과 100DaysOfUI는 움직임을 컴포넌트로 분해하게 했다.
  • WebGL은 픽셀과 질감을 조작하는 방법을 열었다.
  • Remotion은 이 모든 것을 프레임 기반 장면으로 묶었다.
  • 보컬 커버와 리믹스는 소리와 서사를 직접 조율하게 했다.

지나고 나서야 이 경험들이 하나의 방향을 향하고 있었다는 사실이 보였다. 그 방향의 결과가 Lyrics MV이고, 더 넓게 말하면 데이터·코드·소리·이미지·서사를 한 사람이 통제 가능한 시스템으로 엮는 총체예술적 제작 방식이다.

1. 먼저 결론부터: 이것은 프로젝트 목록이 아니다

이 글은 그동안 작성한 아티클을 다시 나열하는 목록이 아니다. 개별 프로젝트가 무엇이었는지보다, 각 프로젝트에서 얻은 것이 어떻게 다음 프로젝트의 입력값으로 변환되었는지를 설명하는 최종 연결 서사다.

경험
  ↓
실패와 제약
  ↓
작업 방식의 발견
  ↓
재사용 가능한 자산
  ↓
다른 도메인으로의 번역
  ↓
새로운 결과물

나에게 작업의 단위는 완성된 파일 하나가 아니다. 다음 작업에 가져갈 수 있는 다음과 같은 과정자산이다.

  • 신호를 확인하는 방법
  • 데이터를 정리하는 방법
  • 실패 조건을 기록하는 방법
  • 반복되는 패턴을 컴포넌트로 만드는 방법
  • 시각·청각적 의도를 파라미터로 표현하는 방법
  • 사람의 판단이 필요한 지점을 남기는 방법

그래서 이 여정은 직선이 아니라 순환에 가깝다.

graph TD
    A[Physical input: drum / voice / camera] --> B[Signal and media data]
    B --> C[Analysis and feature extraction]
    C --> D[Component / model / timeline]
    D --> E[Creative output]
    E --> F[Human review and reflection]
    F --> A

2. 출발점: 50달러짜리 드럼과 고장 난 입력

2021년, 팬데믹과 락다운으로 집 안에 머무는 시간이 길어졌다. 그때 50달러에 고장 난 전자드럼을 구입했다. 하이햇 컨트롤러가 없었고, 베이스 페달은 망가져 있었다.

처음에는 연주만 하고 싶었다. 그러나 트리거가 작동하지 않았고, 피에조와 케이블과 잭을 차례로 의심해야 했다. 생전 처음 납땜을 하고, 회로를 읽고, 부품을 교체하고, 다시 신호를 확인했다.

Drum strike
    ↓
Vibration
    ↓
Piezo trigger
    ↓
Cable / jack / PCB
    ↓
MegaDrum controller
    ↓
MIDI event
    ↓
DAW / VST sound

이 시기에 얻은 자산

  • 입력과 출력 사이에는 여러 실패 지점이 있다는 감각
  • 문제가 발생한 위치를 층별로 분리하는 습관
  • 장비가 작동하지 않을 때 감정이 아니라 신호를 먼저 확인하는 태도
  • 수리 과정과 실패 사진을 기록하는 아카이브 습관

이후 오디오와 영상 작업에서 문제가 생겼을 때도 같은 질문을 반복했다.

데이터가 없는 것인가, 데이터는 있는데 변환이 실패한 것인가, 아니면 출력 단계에서 문제가 생긴 것인가?

이것이 나의 첫 번째 시스템 사고였다.

관련 기록:

3. 드럼을 치려다 MIDI와 DAW를 배웠다

MegaDrum은 그 자체로 소리를 내는 악기가 아니라 MIDI 컨트롤러였다. 입력을 확인하려면 DAW와 VST가 필요했다. GarageBand에서 시작해 Ableton Live와 Logic Pro로 이동했고, MIDI routing과 mapping을 익혔다.

처음에는 킥을 누르면 킥 소리가 나는 정도가 목표였지만, 곧 소리를 이벤트의 집합으로 듣기 시작했다.

  • 어느 순간에 킥이 들어오는가?
  • 스네어의 attack은 얼마나 빠른가?
  • 하이햇의 velocity는 어떻게 변하는가?
  • 드럼과 베이스가 같은 공간을 차지하는가?
  • 이 이벤트를 MIDI나 타임코드로 옮길 수 있는가?
Musical performance
    ↓
MIDI note / velocity / duration
    ↓
DAW timeline
    ↓
Audio playback

여기서 오디오와 데이터가 연결되었다

연주를 듣는 일은 곧 이벤트의 순서와 밀도를 관찰하는 일이 되었다. 훗날 Reaper에서 파형을 보며 에너지 피크를 표시하고, 그 marker를 CSV나 MIDI 이벤트로 내보내고, 다시 영상의 전환에 사용하는 방식은 이때의 감각에서 출발했다.

음악을 데이터로 바라보는 것은 음악성을 제거하는 일이 아니었다. 오히려 “내가 무엇을 듣고 있는가?”를 더 정확하게 질문할 수 있게 했다.

4. 자동 드럼 차트: 첫 번째 실패한 자동화

좋아하는 곡을 Clone Hero용 드럼 차트로 만들고 싶었다. 그래서 음원에서 킥과 스네어를 분리하고, onset을 검출하고, BPM을 추정해 MIDI와 chart 파일로 바꾸는 파이프라인을 구상했다.

import librosa

def separate_drums(file_path):
    y, sr = librosa.load(file_path)
    harmonic, percussive = librosa.effects.hpss(y)
    onset_frames = librosa.onset.onset_detect(
        y=percussive,
        sr=sr
    )
    onset_times = librosa.frames_to_time(onset_frames, sr=sr)
    return onset_times, percussive

구상한 파이프라인

graph LR
    A[Song audio] --> B[Stem separation]
    B --> C[Percussive signal]
    C --> D[Onset detection]
    D --> E[BPM / timing correction]
    E --> F[Drum note mapping]
    F --> G[MIDI / chart]
    G --> H[Manual listening QA]
    H --> I[Correction]
    I --> G

현실에서 부딪힌 것

  • BPM 추정이 실제 곡과 달라짐
  • 라이브 연주와 전자음이 섞여 onset이 불분명함
  • CUDA와 Conda 의존성 문제
  • macOS와 Windows 중심 툴체인의 차이
  • Demucs와 Keras를 붙이는 과정의 환경 문제
  • 자동 결과를 실제로 연주 가능한 chart로 변환하는 추가 노동

며칠 동안 코드를 고쳐도 수작업으로 다섯 시간에 끝낼 일을 해결하지 못하는 순간이 있었다. 이때 얻은 결론은 냉정했다.

어떤 문제에서는 인건비가 기계보다 싸다.

그러나 실패가 사라지지는 않았다. 대신 다음과 같은 자산이 남았다.

  • 신호 분리
  • 이벤트 검출
  • BPM과 timestamp
  • 입력 데이터의 품질 검증
  • 자동 결과의 수동 보정
  • “완전 자동화” 대신 “검수 가능한 반자동화”를 설계하는 감각

이 구조는 훗날 Lyrics MV의 audio → event → scene → frame 파이프라인으로 되돌아왔다.

5. 대학원: 감각을 분석 가능한 문제로 바꾸기

2024년 대학원 데이터 사이언스 프로젝트를 진행하며 질문의 형태가 바뀌었다.

이전에는 “왜 자동으로 드럼 차트를 만들 수 없지?”라고 물었다면, 이제는 이렇게 물었다.

  • 어떤 조건에서 자동화가 실패하는가?
  • 소리를 어떤 특징으로 설명할 수 있는가?
  • 작은 데이터셋에 어떤 모델이 적합한가?
  • 수치상 좋은 결과가 실제 사용성도 보장하는가?
  • 사람이 검수할 지점은 어디인가?

5.1 이미지 분석: 줄노트의 선과 그림 분리하기

줄노트 스캔 이미지에는 수평선, 드로잉, 텍스트, 그림자와 노이즈가 함께 들어 있었다. Canny edge detection과 Hough Line Transform으로 반복적인 수평선을 감지하고, mask와 inpainting으로 선을 제거하는 작업을 진행했다.

Notebook scan
    ↓ grayscale / denoise
    ↓ edge detection
    ↓ line candidates
    ↓ angle / length filtering
    ↓ ruled-line mask
    ↓ inpainting
Cleaned image

이후 contour의 길이, 방향, bounding box, aspect ratio를 분석해 선과 드로잉의 차이를 관찰했다. CNN과 U-Net 접근도 탐색했지만, 데이터와 mask가 충분하지 않으면 모델이 문제의 본질보다 배경의 특성을 외울 수 있다는 점을 확인했다.

5.2 오디오 분석: 드럼 소리를 feature로 설명하기

드럼 원샷 샘플을 Cymbal, Kick, Snare, Tom으로 분류했다. 파형을 그대로 입력하는 대신 시간 영역, 주파수 영역, 지각적 음색 영역으로 feature를 나누었다.

Drum sample
    ├── Time domain
    │   ├── RMS
    │   └── Zero-crossing rate
    ├── Frequency domain
    │   ├── Spectral centroid
    │   ├── Bandwidth
    │   └── Spectral contrast
    └── Timbral / perceptual
        ├── MFCC
        └── Chroma

Feature Engineering 기반 SVM과 Random Forest, Mel Spectrogram 기반 CNN을 비교했다. 당시의 작은 데이터셋에서는 사람이 설계한 feature를 사용한 모델이 더 안정적인 성능을 보였다.

이 결과는 “전통 모델이 언제나 딥러닝보다 낫다”는 주장이 아니다. 데이터 규모와 문제 정의에 맞는 도구를 선택해야 한다는 뜻이다.

5.3 이미지와 오디오의 공통 구조

단계 이미지 오디오
원본 픽셀 배열 waveform 샘플
전처리 grayscale, denoise, threshold trim, normalise, resample
구조 추출 edge, line, contour onset, spectrum, energy
특징 방향, 길이, 밀도 MFCC, RMS, ZCR, centroid
모델 rule-based, CNN/U-Net SVM, RF, CNN
시각화 mask, contour, prediction spectrogram, PCA, confusion matrix
검수 이미지 복원 품질 청취와 사용 가능성

이 비교를 통해 “이미지 분석”과 “오디오 분석”은 서로 다른 기술이면서도 같은 연구 루프를 가진다는 것을 배웠다.

Raw media
    ↓
Representation
    ↓
Feature
    ↓
Model
    ↓
Evaluation
    ↓
Human interpretation

관련 기록:

6. 분석에서 리믹스와 믹스·마스터링으로

분석 결과는 대학원 리포트 안에만 머물지 않았다. 소리의 밝기, 밀도, transient, 공간감을 feature로 바라본 경험은 Logic Pro에서 리믹스할 때 다시 사용되었다.

K-Pop Live Band Rework

원곡의 stem을 분리하고, 기타·베이스·신스·드럼의 관계를 다시 조정했다. 목표는 단순히 음량을 높이는 것이 아니라 스트리밍 음원 안에 묻혀 있던 라이브 세션의 질감을 복원하는 것이었다.

Original song
    ↓ stem split
Vocals / drums / bass / guitar / synth
    ↓
EQ and gain staging
    ↓
Recorded instruments / MIDI riffs
    ↓
Amp / saturation / compression
    ↓
Reverb / delay / bus glue
    ↓
Mastering and A-B listening

분석 지식이 믹스에 준 영향

  • RMS는 음량이지 음색 전체가 아니라는 점
  • spectral centroid가 밝기와 공격성을 설명하는 단서라는 점
  • ZCR이 거칠기와 노이즈성의 단서가 될 수 있다는 점
  • MFCC가 음색 비교의 출발점이 된다는 점
  • 수치와 reference listening을 함께 봐야 한다는 점

이 지식은 EQ와 saturation을 “멋있어 보이는 효과”가 아니라 문제 해결 도구로 바라보게 했다.

  • EQ: 주파수 충돌을 줄이고 공간을 만든다.
  • Compression: dynamic range와 레이어 관계를 조절한다.
  • Saturation: 배음과 밀도를 추가한다.
  • Reverb: 음원을 특정 공간에 배치한다.
  • Delay: 반복과 잔상을 만든다.
  • Side-chain: 주인공이 지나갈 자리를 만든다.
  • Limiter: 피크를 통제하지만 좋은 믹스를 대신하지는 않는다.

관련 기록:

7. 보컬 커버: 나의 목소리를 편집 가능한 재료로 보기

보컬을 직접 녹음하면서 또 다른 벽을 만났다. 방음이 완벽하지 않은 환경의 노이즈, 레이턴시, 피치 이탈, timing gap, 배경음과의 부자연스러운 결합이 한꺼번에 드러났다.

처음에는 한 번의 완벽한 take를 만들고 싶었다. 하지만 실제로는 여러 take에서 좋은 부분을 골라 연결하는 편이 더 현실적이었다.

Raw vocal takes
    ↓
Noise cleanup
    ↓
Pitch / timing inspection
    ↓
Phrase segmentation
    ↓
Manual cut and cross-fade
    ↓
Double / harmony / chorus
    ↓
EQ / compression / reverb
    ↓
Side-chain with instrumental
    ↓
Bounce and review

Vocalign과 합성 기반 정렬을 시도했지만, 일부 구간에서는 timing을 맞추는 대신 피치와 질감이 무너지고 기계적인 artifact가 생겼다. 이 경험은 자동 보정의 한계를 분명히 했다.

결국 나는 보컬을 정체성의 원본이 아니라, 곡 안에서 조립할 수 있는 음향 재료로 보기 시작했다.

  • 메인 보컬
  • 더블링
  • 코러스
  • 노이즈 텍스처
  • pitch-corrected phrase
  • 변환된 음색
  • 짧은 숨과 자음 샘플

이 시선은 이후 RVC 실험과 Lyrics MV의 보컬·가사·화면 설계에 영향을 주었다.

8. RVC: 음색과 인간 디렉팅 사이

2026년 초에는 RVC를 실험했다. TTS는 스크립트와 연기 톤을 반복적으로 지정해야 했고, 원하는 감정과 발화의 일관성을 확보하기 어려웠다. 그래서 직접 준비한 음성 데이터로 음색 변환을 실험했다.

Voice recordings
    ↓
Cut and normalise
    ↓
Feature extraction
    ↓
F0 / RMVPE analysis
    ↓
Training
    ↓
Checkpoint + index
    ↓
Inference
    ↓
Human listening review

RVC에서 배운 것

  • macOS multiprocessing과 Windows 예제는 다르게 작동한다.
  • feature extraction이 실패하면 학습 단계가 정상처럼 보여도 결과는 사용할 수 없다.
  • checkpoint가 생성되었다고 음질이 보장되는 것은 아니다.
  • 실시간 변환은 latency 문제가 있고, offline rendering이 더 적합할 수 있다.
  • 모델은 음색 후보를 만들 뿐, 감정·연기·음악적 표현을 최종 결정하지 않는다.

RVC는 보컬을 대신하는 도구가 아니었다. 음색을 여러 방향으로 변형해 보고, 원본과 변환 결과의 차이를 듣고, 어떤 결과가 곡의 장면에 어울리는지 판단하는 실험 공간이었다.

AI는 결과를 만들 수 있지만, 어떤 결과를 채택할지 결정하는 것은 여전히 디렉터의 일이다.

관련 기록:

  • [[ RVC preprocess multiprocessing macOS fix ]]
  • [[ 2026-02-19 ]]

9. 웹 애니메이션: 소리를 화면으로 번역하기

오디오를 데이터로 보고, UI를 컴포넌트로 보고, GSAP을 시간축으로 사용하면서 소리와 화면 사이의 번역이 가능해졌다.

9.1 GSAP과 타임라인

GSAP은 단순한 움직임 라이브러리가 아니라, 요소 간의 관계와 순서를 명시하는 장치였다.

Audio event / user input
    ↓
Time or progress value
    ↓
GSAP timeline
    ↓
position / scale / opacity / rotation
    ↓
Visual feedback

광고 배너에서는 CTA와 제품 이미지의 등장 순서를 조절했고, 랜딩 페이지에서는 스크롤 progress를 장면 진행률로 사용했다. 100DaysOfUI에서는 글리치, 픽셀, 텍스트, 갤러리, 카드 스택을 반복적으로 실험했다.

9.2 100DaysOfUI에서 수집한 모션 어휘

  • 글리치와 distortion
  • 이미지 블록 분해
  • ScrollTrigger와 parallax
  • Circular Text와 Falling Text
  • Infinite Scroll
  • Image Trail
  • Decrypted Text
  • Pixel Transition
  • Variable Proximity
  • Scroll Velocity
  • Silk와 흐르는 텍스처
  • Card Swap
  • Text Video Mask

이 작업들은 각자 독립적인 컴포넌트였지만, 반복되는 패턴은 Primitive와 Semantic Motion으로 다시 분류되었다.

Primitive
  ├── opacity
  ├── transform
  ├── delay / duration
  ├── grid cell
  └── text unit

Semantic motion
  ├── glitch reveal
  ├── pixel transition
  ├── image trail
  ├── card swap
  └── text mask

관련 기록:

10. 이미지 분석에서 로토스코핑과 VFX로

이미지 분석 프로젝트에서 다룬 edge, contour, mask, bounding box, centroid는 영상에서도 다시 등장했다. 차이는 이제 이미지 한 장이 아니라 시간에 따라 변화하는 프레임을 처리한다는 점이었다.

Video frame sequence
    ↓
Pose / object detection
    ↓
Tracking points
    ↓
Interpolation and smoothing
    ↓
SVG path / mask
    ↓
Text / VFX layer
    ↓
Remotion render

피사체의 움직임과 윤곽을 데이터로 만들면, 그 데이터를 따라가는 텍스트나 피격 지점에 반응하는 VFX를 구성할 수 있다.

로토스코핑에서 수집한 과정자산

  • frame-by-frame keyframe
  • tracking point
  • confidence value
  • bounding box
  • centroid
  • SVG path
  • Bézier interpolation
  • motion data와 VFX trigger의 연결
graph LR
    A[Image / video] --> B[Detection]
    B --> C[Tracking data]
    C --> D[Path / mask]
    C --> E[Motion event]
    D --> F[Text flow]
    E --> G[VFX trigger]
    F --> H[Composition]
    G --> H

이것은 대학원 이미지 분석이 시각 효과로 번역된 사례다. 분석은 창작의 반대편이 아니라, 창작을 조율할 수 있는 보이지 않는 뼈대가 되었다.

관련 기록:

  • [[ 2025-07-14-rotoscoping-motion ]]

11. Remotion: 모든 시간축을 하나의 프레임 시스템으로

Remotion을 만난 뒤 지금까지의 경험들이 한곳에서 조합되기 시작했다. React 컴포넌트는 영상 장면이 되었고, TypeScript props는 씬의 계약이 되었고, MIDI·SRT·CSV는 타임라인 입력이 되었다.

통합 파이프라인

graph TD
    A[Audio / MIDI / SRT / video / image] --> B[Parser and normaliser]
    B --> C[Event model]
    C --> D[SceneTimelineManager]
    D --> E[SceneSequencePlayer]
    E --> F[Typography]
    E --> G[Media layer]
    E --> H[Background shader]
    E --> I[Transition]
    E --> J[Audio spectrum]
    F --> K[Remotion frame]
    G --> K
    H --> K
    I --> K
    J --> K
    K --> L[Rendered MV / Shorts]

웹 UI에서 영상 씬으로의 변환

웹에서의 단위 영상에서의 단위
Component Scene component
Props Scene configuration
Hover / click Frame or audio trigger
Scroll progress Timeline progress
CSS transition Frame interpolation
Image card Media layer
Text mask Lyric reveal
Background effect Shader scene
UI state Scene state

이 변환은 기존 UI를 그대로 영상에 복사하는 일이 아니었다. UI가 가진 구조와 상태 변화, 시각적 위계를 추출해 시간축 위에 다시 배치하는 일이었다.

12. Lyrics MV: 누적자산의 총집합

Lyrics MV는 이전 경험들이 가장 많이 겹치는 작업이다. 하나의 영상 안에서 다음 요소들이 동시에 움직인다.

  • 오디오 구조
  • 보컬과 가사
  • MIDI와 beat
  • 타이포그래피
  • 이미지와 비디오
  • 텍스처와 셰이더
  • 마스크와 전환
  • 서사와 장면 순서
  • 렌더링 환경과 해상도

MV 제작의 현재 흐름

  1. 곡을 선택하고 감정적·서사적 방향을 정한다.
  2. 원곡 또는 보컬의 구조를 분석한다.
  3. beat, pitch, energy, section, lyric timing을 추출한다.
  4. Figma에서 이미지·타이포그래피·레이아웃을 설계한다.
  5. 필요한 모션을 작은 컴포넌트와 프리셋으로 분해한다.
  6. Remotion의 씬과 Sequence로 조립한다.
  7. GSAP, CSS, Canvas, WebGL을 필요한 장면에 적용한다.
  8. 오디오 이벤트를 시각 이벤트로 연결한다.
  9. 프레임 단위로 렌더링하고, 귀와 눈으로 검수한다.
  10. 실패한 장면을 다시 데이터·컴포넌트·타이밍의 문제로 분해한다.
Research
    ↓
Audio analysis
    ↓
Narrative / storyboard
    ↓
Visual system
    ↓
Scene architecture
    ↓
Motion composition
    ↓
Render
    ↓
Audio + visual QA
    ↓
Revision

Chroma Drift와 Niji

Chroma Drift는 보컬과 화면의 관계, 믹스와 씬의 관계를 다시 확인하는 과정이었다. 이후 Niji에서는 오디오 분석, 보컬 처리, Remotion, 셰이더, 서브컬처 서사와 1인 디렉팅이 한 화면 안에서 오케스트레이션되었다.

중요한 것은 Niji가 갑자기 나타난 완성작이 아니라는 점이다. 드럼 수리에서 시작해, 오디오 분석과 실패한 자동화, 리믹스와 보컬 커버, UI와 WebGL 실험을 거친 뒤에야 가능한 결과였다.

관련 기록:

13. 총체예술 시스템의 아키텍처

내가 만드는 종합적인 창작 시스템은 특정 툴 하나가 중심이 아니다. 각 도메인이 서로 다른 역할을 맡는다.

graph TD
    A[Creative intention] --> B[Research and reference]
    B --> C[Data extraction]
    C --> D[Normalised event model]
    D --> E[Design system]
    E --> F[Scene composition]
    F --> G[Rendering]
    G --> H[Human review]
    H --> I[Archive and reusable assets]
    I --> C

계층별 역할

계층 역할 주요 자산
Research 레퍼런스와 맥락을 수집 moodboard, notes, reference archive
Input 원본 미디어 확보 audio, voice, MIDI, image, video
Analysis 구조와 특징 추출 features, markers, contours, SRT
Middleware 데이터를 공통 형식으로 변환 event model, schema, metadata
Design 시각 언어와 규칙 정의 tokens, storyboard, style guide
Runtime 컴포넌트와 씬을 실행 React, GSAP, WebGL, Remotion
Review 결과를 사람의 감각으로 검증 A-B test, listening, frame QA
Archive 다음 작업에 남김 presets, logs, assets, recipes

이 구조가 있기 때문에 하나의 프로젝트가 끝나도 다음 프로젝트의 시작점이 사라지지 않는다.

14. 누적자산을 재사용 가능한 블록으로 분류하기

14.1 오디오 블록

  • AudioAnalyzer
  • BPM과 beat parser
  • pitch contour
  • RMS와 energy calculation
  • MIDI timing parser
  • waveform marker
  • stem separation 결과
  • vocal cleanup과 mix chain
  • reference track과 A-B listening log

14.2 이미지·비디오 블록

  • grayscale preprocessing
  • edge와 contour extraction
  • mask와 inpainting
  • tracking point와 bounding box
  • SVG path와 Bézier interpolation
  • chroma key 설정
  • VFX asset manager
  • image sequence와 media slot

14.3 모션 블록

  • GSAP timeline
  • ScrollTrigger
  • stagger calculation
  • glitch reveal
  • pixel transition
  • text split과 type reveal
  • image trail
  • card swap
  • parallax layer
  • shader intensity

14.4 데이터·아키텍처 블록

  • Python batch processing
  • CSV·JSON metadata
  • TypeScript schema
  • React props contract
  • SceneTimelineManager
  • SceneSequencePlayer
  • useCurrentFrame() 기반 렌더링
  • human review state
  • source와 version 기록
Asset
    + Event
    + Style
    + Timing
    + Review state
    = Reusable creative block

이 블록들은 아직 완벽하게 패키징된 상용 SDK가 아니다. 하지만 반복되는 작업을 다시 처음부터 시작하지 않게 해주는 개인 제작 시스템의 재료다.

15. 왜 이것이 종합예술인가

“종합예술”이라는 표현은 여러 기술을 많이 사용한다는 뜻이 아니다. 서로 다른 매체가 하나의 의도 아래에서 서로의 결과를 입력값으로 사용하는 구조를 뜻한다.

  • 음악은 장면의 시간을 제공한다.
  • 데이터는 음악의 구조를 설명한다.
  • 디자인은 그 구조를 어떤 언어로 보여줄지 결정한다.
  • 코드는 반복과 변형을 통제한다.
  • 영상은 소리와 이미지와 텍스트를 동시에 운반한다.
  • 서사는 무엇을 보여주고 숨길지 결정한다.
  • 디렉팅은 이 모든 충돌을 하나의 결과로 조율한다.
Sound provides time
Data provides structure
Design provides meaning
Code provides control
Image provides form
Narrative provides direction
Human director provides judgement

단순히 오디오 분석을 하고, 단순히 예쁜 화면을 만들고, 단순히 AI로 음성을 변환하는 것만으로는 총체적인 작업이 되지 않는다. 각각의 결과가 다음 매체의 설계 조건으로 이어져야 한다.

16. 최종적으로 남은 교훈

1. 직선적인 성장 서사는 실제 작업을 설명하지 못한다

나는 드럼에서 데이터 사이언스로, 데이터에서 영상으로 한 번에 이동하지 않았다. 계속 이전 작업으로 돌아갔고, 실패한 방법을 다시 다른 맥락에서 사용했다.

2. 실패는 폐기물이 아니라 인터페이스다

MIDI 오류, BPM mismatch, CNN 과적합, U-Net mask 실패, RVC preprocessing 오류, 보컬 artifact, WebGL 렌더링 문제는 다음 시스템이 무엇을 입력받아야 하는지 알려주었다.

3. 데이터는 감각의 반대가 아니다

파형·스펙트럼·feature·marker는 음악을 차갑게 만드는 것이 아니라, 막연한 감각을 다시 설명할 수 있게 하는 언어다.

4. 자동화는 판단을 없애지 않는다

좋은 시스템은 사람을 제거하지 않는다. 반복적인 후보 생성과 정리를 맡기고, 사람에게 더 중요한 판단을 남긴다.

5. 모든 것을 코드로 만들 필요는 없다

코드 기반 제작은 항상 빠르거나 효율적인 것이 아니다. 내가 코드를 선택하는 이유는 속도보다 재사용성, 변형 가능성, 기록 가능성, 다른 도메인으로의 확장성에 있다.

6. 컴포넌트는 모양이 아니라 계약이다

컴포넌트가 무엇을 받고, 어느 상태를 가지며, 어떤 시간축에서 작동하고, 어떤 다른 요소와 결합할 수 있는지를 정의해야 한다.

7. 최종 결과물보다 과정자산이 오래 간다

완성된 MV 한 편은 언젠가 과거의 작업이 된다. 하지만 분석 스크립트, 모션 프리셋, 실패 로그, 데이터 모델, 검수 기준은 다음 작업의 시작점이 된다.

17. 앞으로의 방향: 창작용 MIR과 개인 프로덕션 생태계

앞으로 만들고 싶은 것은 하나의 거대한 AI 모델이 아니다. 다음 요소를 연결하는 개인 창작 생태계다.

graph TD
    A[Audio library] --> B[MIR analysis]
    B --> C[Search and tagging]
    B --> D[Mixing assistance]
    B --> E[Beat / pitch / lyric events]
    E --> F[Remotion scenes]
    F --> G[YouTube / Shorts / Lyrics MV]
    C --> H[Reusable asset library]
    D --> H
    G --> H
    H --> A

계획하는 시스템

  • 오디오 파일을 BPM, energy, timbre, mood, instrument로 검색
  • 드럼과 보컬의 특징을 시각화
  • raw vocal과 guide vocal의 pitch·timing 차이 표시
  • beat와 section boundary를 Remotion 씬에 전달
  • 오디오 feature에 따라 shader와 typography 강도 변경
  • 원곡·리믹스·마스터 버전의 A-B 비교 영상 생성
  • 분석 과정 자체를 YouTube 교육·다큐멘터리 콘텐츠로 제작
  • 각 asset에 source, licence, processing, model version 기록
  • 자동 후보와 인간 승인 상태를 분리

이것은 AI가 모든 것을 대신하는 구조가 아니다. 데이터를 통해 창작자가 더 많은 변형을 시도하고, 더 빠르게 실패하고, 더 명확하게 선택할 수 있도록 돕는 구조다.

에필로그: 점과 선과 면, 그리고 하나의 세계

처음의 나는 고장 난 드럼을 고치고 싶었다. 그다음에는 MIDI 신호를 이해하고 싶었다. 그다음에는 드럼 차트를 자동으로 만들고 싶었다. 대학원에서는 이미지와 오디오를 분석했고, 이후에는 곡을 다시 믹스하고 내 목소리를 녹음했다. GSAP과 React로 화면을 움직였고, WebGL로 픽셀과 질감을 조작했다. Remotion으로 그 모든 것을 영상의 시간축에 올렸다.

각 작업만 보면 산만해 보인다.

  • 왜 드럼을 고치다가 Python을 공부했는가?
  • 왜 오디오를 분석하다가 랜딩 페이지를 만들었는가?
  • 왜 UI 컴포넌트를 만들다가 Lyrics MV를 만들었는가?
  • 왜 실패한 자동화 프로젝트를 계속 기록했는가?

이제는 답할 수 있다.

각 작업은 서로 다른 결과물이었지만, 동일한 질문을 반복하고 있었다.

입력을 어떻게 이해하고, 구조화하고, 변환하고, 다시 사람이 경험할 수 있는 형태로 만들 것인가?

그 질문이 하드웨어에서는 신호가 되었고, 오디오에서는 파형과 feature가 되었고, 데이터 사이언스에서는 모델과 평가가 되었고, 웹에서는 컴포넌트와 timeline이 되었고, 영상에서는 scene과 frame이 되었다.

점: 각각의 실패와 실험
    ↓
선: 서로 다른 분야를 연결하는 방법론
    ↓
면: 재사용 가능한 제작 시스템
    ↓
세계: 소리·이미지·코드·서사가 함께 작동하는 총체예술

Lyrics MV는 이 여정의 끝이라기보다, 흩어진 경험들이 처음으로 하나의 결과 안에서 동시에 작동한 지점이다. 그리고 그 결과는 다시 새로운 오디오 분석, 새로운 모션 실험, 새로운 데이터셋, 새로운 영상의 시작점이 된다.

나는 이제 나의 작업을 “여러 가지를 조금씩 건드린 기록”이라고 부르지 않으려 한다. 그것은 하나의 도메인을 여러 매체로 탐구하며, 실패와 제약을 재사용 가능한 언어로 바꾸어 온 과정이었다.

결국 내가 만드는 것은 영상 한 편이 아니다.

소리에서 구조를 읽고, 구조에서 움직임을 만들고, 움직임에서 다시 하나의 세계를 조율하는 개인 창작 시스템이다.

Related Articles