어도비와 작별을 고한 개발자의 리모션 삽질기

Last updated December 26, 2025 – ArtXTech

어도비와의 불편한 관계: 구독 모델의 함정

어도비의 구독 모델은 정말 터무니없다. 매달 꾸준히 빠져나가는 금액을 보면서 문득 생각한다.

“내가 이 기능들을 전부 다 쓰고 있나?” 아니, 전혀 그렇지 않다. 그저 영상 몇 개 편집하고 간단한 모션 그래픽 작업하는데 이 무거운 프로그램들이 과연 필요한가 하는 의문이 들기 시작했다.

시장은 어도비로 완전히 포화 상태다. 쓸만한 튜토리얼이나 템플릿을 찾아보면 99%가 애프터 이펙트 기반이다. 마치 “어도비 없이는 창작할 수 없다”는 메시지를 은근히 강요받는 느낌이랄까. 프리미어 프로의 경우는 그나마 캡컷이나 파이널컷 프로로 대체가 가능하다. 솔직히 기본적인 컷 편집과 자막 삽입 정도라면 이 정도 툴로도 충분하다.

graph TB
    subgraph "🎬 영상 편집 도구 비교"
        direction TB
        
        subgraph A["컷 편집, 기본 자막"]
            A1["대안: CapCut, Final Cut Pro"]
            A2["어도비: 오버스펙 + 오버프라이스"]
        end
        
        subgraph B["✨ 모션 그래픽, 이펙트"]
            B1["❓ 대안: ???"]
            B2["어도비: 사실상 독점 (불편한 진실)"]
        end
        
        subgraph C["💰 가격"]
            C1["대안: 합리적/일회성 구매"]
            C2["어도비: 끝없는 구독료의 늪"]
        end
    end

    classDef good fill:#e1f5fe,stroke:#01579b,stroke-width:2px
    classDef bad fill:#ffebee,stroke:#c62828,stroke-width:2px
    classDef neutral fill:#f3e5f5,stroke:#4a148c,stroke-width:2px
    
    class A1,C1 good
    class A2,B2,C2 bad
    class B1 neutral

내가 당장 필요한 건 화려한 3D 효과나 복잡한 파티클 시스템이 아니다. 단지 정확한 타이밍에 컴포넌트들을 배치하고, 비트에 맞춰 컷을 전환하는 기능이면 충분하다. 웹 개발자로서 GSAP로 15초짜리 애니메이션은 이미 만들어본 경험이 있는데, 이걸 영상으로 옮기려니 갑자기 애프터 이펙트 전문가가 되어야 한다고? 뭔가 잘못된 접근 방식이 아닐까?

자동화의 가능성: 파이썬의 유혹과 한계

문득 이런 생각이 들었다. 영상 편집 작업도 결국은 패턴이 있고, 그렇다면 프로그래밍으로 자동화할 수 있지 않을까? 우연히 한 유튜버가 파이썬과 위스퍼 AI를 활용한 영상 제작 파이프라인을 소개하는 것을 보았다. 대략 이런 흐름이었다.

간단한 플로우차트

flowchart TD
    A["📝 스크립트<br/>(텍스트)"]
    B["🎤 위스퍼<br/>(STT)"]
    C["📄 자막생성<br/>(JSON/SRT)"]
    D["🐍 파이썬 스크립트"]
    E["🎬 영상<br/>(MP4)"]
    
    A --> B --> C --> D --> E
    
    subgraph processing ["파이썬 처리 과정"]
        D1["무음 구간 컷"]
        D2["이미지 생성"]
        D3["편집 자동화"]
    end
    
    D --- processing
    
    %% 스타일링
    classDef main fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
    classDef sub fill:#fff8e1,stroke:#f57c00,stroke-width:1px
    
    class A,B,C,D,E main
    class D1,D2,D3 sub

자동화의 가능성이 처음에는 정말 매력적으로 느껴졌다. 파이썬 스크립트로 영상을 자동 생성한다니, 이게 바로 개발자의 사고방식 아닌가? MoviePy 같은 라이브러리를 살펴보면서 희망을 품었다.

하지만 막상 파고들기 시작하니 문제점이 하나둘 드러났다. 가장 큰 건 재미가 없다는 것이다. 코드로 이미지를 조합하고 기계적으로 모션을 계산하는 과정은 생각보다 무미건조했다. 데이터 분석에는 파이썬이 적합할지 몰라도, 창의적인 시각 작업에는 뭔가 부족함이 느껴졌다.

더 근본적인 문제는 직관성의 부재였다. 그래픽 툴을 사용할 때의 가장 큰 장점은 즉각적인 피드백이다. 화면을 보면서 “이 요소를 여기로 옮기고, 저 색상을 조금 더 진하게” 하는 식의 즉각적인 조정이 가능하다. 하지만 코드 기반 접근법에서는 모든 변경사항을 코드로 작성하고, 렌더링을 기다려야만 결과를 확인할 수 있다. 이런 작업 방식은 직관적인 디자인 과정과는 거리가 멀었다.

클래스 다이어그램 스타일 - 구조적 표현

classDiagram
    class `Approach A: Python (MoviePy)` {
        +advantages
        ✓ 자동화 가능
        ✓ 데이터 기반 처리
        +disadvantages  
        ✗ 창의적 과정 단절
        ✗ 직관적 피드백 부재
    }
    
    class `Approach B: Graphic Tools (AE, FCP)` {
        +advantages
        ✓ 직관적 인터페이스
        ✓ 즉각적 피드백
        +disadvantages
        ✗ 비용 부담
        ✗ 툴 의존성
        ✗ 반복 작업 지루함
    }
    
    class `Approach C: Frontend (Remotion)` {
        +advantages
        ✓ 기존 스킬 활용
        ✓ 코드 기반 제어
        +disadvantages
        ✗ 학습 곡선
        ✗ 직관성 부족
        ✗ 시각적 피드백 지연
    }
    
    `Approach A: Python (MoviePy)` : 자동화 중심
    `Approach B: Graphic Tools (AE, FCP)` : 직관성 중심  
    `Approach C: Frontend (Remotion)` : 코드 중심

그래서 다시 원점으로 돌아왔다. 내 프론트엔드 지식을 활용하면서도 영상을 만들 수 있는 방법은 없을까? 그렇게 검색의 바다를 헤매다 발견한 것이 바로 리모션(Remotion)이었다.

리액트로 영상 만들기: 새로운 관점의 발견

리모션은 리액트 컴포넌트로 비디오를 제작하는 라이브러리다. 처음 이 개념을 접했을 때는 약간 의아했다. 웹 개발에 쓰던 기술로 영상을 만든다고? 하지만 설명을 읽어보니 흥미로운 접근법이었다.

import { Composition, Sequence, useCurrentFrame, useVideoConfig } from 'remotion';
import { MyComponent } from './MyComponent';
import { AnotherComponent } from './AnotherComponent';

export const MyVideo = () => {
  const frame = useCurrentFrame();
  const { durationInFrames, fps } = useVideoConfig();

  // 프레임 기반으로 애니메이션 로직 구현
  const opacity = Math.min(1, frame / 60);
  const scale = 1 + (frame / durationInFrames) * 0.2;

  return (
    <div style={{ flex: 1, backgroundColor: 'white' }}>
      {/* Sequence: 특정 구간에만 컴포넌트 렌더링 */}
      <Sequence from={0} durationInFrames={120}>
        <MyComponent title="Hello World!" style={{ opacity }} />
      </Sequence>
      <Sequence from={60} durationInFrames={Infinity}>
        {/* CSS 애니메이션이나 JS 로직으로 움직임 제어 */}
        <AnotherComponent style={{ transform: `scale(${scale})` }} />
      </Sequence>
    </div>
  );
};

Video.jsx

개념적으로는 꽤 명료하다. 리액트 컴포넌트를 생성하고, Sequence로 특정 시간대에 표시되게 하며, useCurrentFrame 같은 훅으로 현재 프레임 정보를 활용해 애니메이션을 제어한다. CSS와 자바스크립트로 움직임을 표현하는 것은 웹 개발자인 내게는 익숙한 영역이다. 마침내 내 기술 스택을 영상 제작에 활용할 수 있는 가능성이 보였다.

그러나 실제로 작업을 시작하니 현실은 생각보다 복잡했다.

리액트를 다루는 데 익숙하다고 해서 리모션을 쉽게 다룰 수 있을 거라는 건 오만한 생각이었다. 리모션 자체의 API와 개념을 익히는 것도 시간이 필요했고, 더 근본적으로는 웹 애니메이션과 비디오 타임라인 사이의 개념적 차이를 극복하는 게 쉽지 않았다. 프레임 단위로 생각하고, 값을 보간하는 방식으로 애니메이션을 구현하는 것은 생각보다 직관적이지 않았다.

그래픽 툴의 장점인 직관성 문제도 여전했다. 타임라인 위에서 요소를 드래그하며 위치를 조정하는 것과 달리, 모든 움직임과 타이밍을 코드로 계산해야 했다. 미리보기 기능이 있긴 하지만, 애프터 이펙트처럼 실시간으로 타임라인을 스크러빙하며 미세 조정하는 경험과는 거리가 멀었다.

상태 다이어그램

graph LR
    subgraph 컨셉구상
        A[머릿속아이디어] --> B[스케치작업]
    end

    subgraph 코드작성
        C[RemotionAPI] --> D[구현완료]
    end

    subgraph 렌더링확인
        E[렌더링실행] --> F[결과검토]
        F --> G[피드백분석]
    end

    컨셉구상 -- 아이디어 확정 --> 코드작성
    코드작성 -- 코드 완성 --> 렌더링확인

    렌더링확인 -- 디버깅 & 수정<br/>(인내의 순환) --> 컨셉구상
    렌더링확인 -- 완성 --> Z[*]

    %% Note for 렌더링확인 - placed separately
    subgraph Notes
        N1[피드백 지연으로 인한<br/>반복 작업 구간]
    end
    렌더링확인 --- N1

그럼에도 리모션을 고집하는 이유

여기서 의문이 들 수 있다. 이렇게 비효율적이고 직관성이 떨어진다면, 왜 계속 리모션을 사용하려고 하는가? 그냥 어도비 제품을 쓰거나 다른 대안을 찾는 게 더 합리적이지 않을까?

몇 가지 고려할 점이 있다:

시간 투자의 관점: 솔직히 말해서, 애프터 이펙트나 프리미어 프로를 새로 배우는 시간과 리모션으로 코딩하며 해결책을 찾는 시간은 크게 다르지 않다. 어차피 학습 곡선을 감수해야 한다면, 내게 더 친숙한 도메인(코딩)에서 그 고통을 겪는 편이 낫다. 무엇보다 매달 구독료를 지불하지 않아도 된다는 건 큰 장점이다.
확장성: 이것이 가장 중요한 부분이다. 코드로 영상을 만든다는 건 단순히 영상 하나를 편집하는 차원을 넘어선다. 데이터와의 연동, API 호출, 사용자 입력에 기반한 맞춤형 영상 생성 등 무한한 가능성이 열린다. 예를 들어, 특정 데이터셋을 기반으로 자동화된 시각 자료를 생성하거나, 사용자 선택에 따라 다른 내용을 보여주는 인터랙티브 영상을 구현할 수 있다.
지적 호기심과 성취감: 솔직히 말하자면, 이것은 일종의 도전이다. “과연 이 방식으로 만족스러운 결과물을 만들어낼 수 있을까?“라는 의문에 대한 답을 찾고 싶은 마음이 크다. 어려움을 극복하고 무언가를 완성했을 때의 성취감은 그 과정의 고통을 잊게 한다. 개발자로서의 호기심과 문제 해결에 대한 욕구가 이 여정을 계속하게 만든다.

WBS (Work Breakdown Structure) - 작업 분해 구조

flowchart TD
    Root["리모션의 유용성"]
    
    Root --- Level1A["시간 투자의 효율성<br/>프론트엔더라 코드가 익숙)"]
    Root --- Level1B["확장성과 자동화 가능<br/>Scalability & Automation"]
    Root --- Level1C["프론트엔드 경험 활용해<br/>영상 감각도 동시 습득"]
    
    Level1A --- Level2A1["새 도메인 학습<br/>"]
    Level1A --- Level2A2["익숙한 영역에서의<br/>도전"]
    
    Level1B --- Level2B1["데이터 연동<br/>Data Integration"]
    Level1B --- Level2B2["정규 가이드를<br/> 줄 수 있는 콘텐츠 제작"]
    Level1B --- Level2B3["스케일링<br/>Scaling"]
    
    Level1C --- Level2C1["문제 해결 과정에서<br/>오는 성취도"]
    
    %% 스타일링
    classDef level0 fill:#1a237e,color:#fff,stroke:#000,stroke-width:3px
    classDef level1 fill:#283593,color:#fff,stroke:#000,stroke-width:2px
    classDef level2 fill:#3949ab,color:#fff,stroke:#000,stroke-width:1px
    
    class Root level0
    class Level1A,Level1B,Level1C level1
    class Level2A1,Level2A2,Level2B1,Level2B2,Level2B3,Level2C1 level2

결론: 불편함 속에서 찾는 가능성

리모션으로 영상을 만드는 과정은 분명 비효율적이다. 시간도 많이 소요되고, 직관적인 작업이 어려우며, 때로는 정말 답답함을 느낀다. 하지만 어도비의 터무니없는 구독 모델에서 벗어나 내 기술 스택을 활용해 새로운 가능성을 모색한다는 점에서 의미가 있다.

언젠가 이 실험이 성공적으로 끝날지, 아니면 결국 어도비로 돌아가게 될지는 모르겠다. 하지만 적어도 “영상 제작은 어도비 없이는 불가능하다”는 관념에 도전하고 있다는 사실만으로도 가치가 있다고 생각한다.

사실 이 모든 과정은 새로운 문제에 접근하는 방식을 반영한다. 기존 솔루션의 한계를 인식하고, 대안을 탐색하며, 때로는 비효율적으로 보이는 길을 택하더라도 실무 작업자로서 장기적으로 더 나은 해결책을 찾아가는 여정이다.

어쩌면 언젠가 리액트로 고품질 영상을 만드는 날이 올지도 모른다. 혹은 완전히 새로운 접근법을 발견할 수도 있다. 중요한 건 작업자로서의 창의성과 문제 해결 능력을 믿고 나아가는 것이다.

다른 리모션 포스팅을 보고 싶다면

2025-01-16-implementing-canvas-animation-to-remotion-kr
2025-03-18-making-my-own-video-editor-in-progress
KR-remotion-gsap
KR-making-chart-data-journalism-storytelling-motion-setup-with-remotion
KR-figma-to-jitter-and-remotion
KR-converting-bodymovin-animation-to-remotion-template
KR-how-i-make-a-youtube-series-with-remotion-dynamic-srt-script-setup-exp-likejennie
KR-how-i-made-podcast-interview-with-ai-virtual-idol
KR-remotion-and-shader
KR-thepain-of-animation-debugging