DCode

CinevStudio

프로젝트 개요

항목 내용
기간 2022.11 — 2024.10, 2024.12 — 2026.03 (3년 5개월, 중간 2개월 이직 및 재입사)
역할 클라이언트 개발 시니어 프로그래머
제품 CINEV 서비스의 내부 3D 영상 콘텐츠 제작 소프트웨어
기술스택 C++, Unreal Engine 4/5, LLM Function Calling, Git
링크 CINEV 서비스, 유튜브 @studioCINEV, Steam CINEV Studio

프로젝트 배경

이 소프트웨어는 시나몬(Cinnamon)이 개발한 CINEV 서비스의 내부 응용 소프트웨어이다. CINEV는 AI 기반 3D 애니메이션 플랫폼으로, 사용자가 텍스트 프롬프트로 3D 영상 콘텐츠를 제작할 수 있는 서비스이다. 이 소프트웨어는 CINEV 서비스의 핵심 제작 엔진으로, Unreal Engine을 기반으로 카메라 연출, 시퀀스 편집, AI 모델 연동, 렌더링 파이프라인을 처리한다.

CINEV 서비스의 전체 흐름은 다음과 같다.

사용자 프롬프트
    → LLM: 장면 정의 생성 (Shot 구성, 캐릭터 위치, 카메라, 대사 등)
    → 3D Scene 생성 (Unreal Engine 기반)
    → 렌더링 (MovieRenderQueue)
    → Web 사용자에게 결과 전달

CINEV 서비스

캐릭터와 배경의 일관성 유지, 컨텍스트 유지, 재현성, 정밀한 편집, 카메라 및 연출 의도의 정확한 제어를 위해, LLM을 이용해 장면에 대한 구조화된 정의를 생성하고 이를 기반으로 3D Scene을 구성하는 방식이 채택되었다. 이 소프트웨어는 이 파이프라인 중 LLM 출력을 3D Scene으로 변환하고 렌더링하는 핵심 엔진 역할을 담당했다.

3D 영상 콘텐츠 제작은 일반적으로 전문가용 DCC 도구와 후반보정 파이프라인을 통해 이루어진다. 그러나 실시간 엔진 기반으로 제작 흐름을 단축하고, 비전문가도 사용할 수 있는 수준의 제작도구가 필요했다. CINEV는 Unreal Engine을 코어로 삼아, 영상 콘텐츠 제작에 필요한 촬영 구성, 편집, 렌더링, AI 기능을 하나의 도구로 통합하는 것을 목표로 했다.

개발 기간 중 Unreal Engine 4에서 5로의 메이저 엔진 업데이트가 있었고, 이로 인한 SequencePlayer 동작 방식 변경이 프로젝트 전반에 영향을 주었다.

2024년 10월 이직으로 인해 프로젝트에서 일시 이탈했다가, 2024년 12월 재입사하여 기존 프로젝트에 복귀했다. 2개월의 공백을 제외하면 전체 3년 5개월 동안 해당 제품 개발에 참여했다.

주요 제약은 다음과 같았다.

담당 범위

서비스 전체 아키텍처 결정은 팀 내 논의를 통해 이루어졌고, 시니어 개발자로서 의견 제시와 검토에 참여했다. 실제로 주도적으로 작업한 영역은 세부 기능 설계 및 구현이며, 특히 Camera Direction System은 전반적인 책임을 가지고 설계부터 검증까지 전담했다.

주요 기능

Camera Direction System

영상 콘텐츠 제작에서 카메라 워크는 내러티브의 중요한 요소다. 이 시스템은 사용자가 카메라의 경로, 속도, 시점을 시퀀스 내에서 조절할 수 있도록 했다.

Shot 정의와 AutoCamera. 시스템은 실제 영상물 분석을 기반으로 Shot 매개변수를 정의했다. 영화 촬영 이론에서 사용되는 구도, 카메라 앵글, 움직임의 유형을 파라미터화하여 Shot 단위로 표현했다. AutoCamera는 이 Shot 정의를 바탕으로 장면의 맥락에 따라 적절한 카메라 방향을 자동으로 결정하는 시스템이다.

Sequence 기반 콘텐츠 편집

콘텐츠 제작의 기본 단위를 Sequence로 정의하고, 복수의 Sequence를 조합하여 완성된 영상을 구성하는 구조.

LLM 및 AI 모델 연동

LLM과 학습 모델을 제작 파이프라인에 통합하여 텍스트 기반 콘텐츠 생성, 장면 구성 자동화, 스타일 전이 등을 지원.

Grouped Action System

캐릭터 애니메이션을 관리하는 Action System. 전체 프로젝트의 애니메이션을 캐릭터에 적용하기 위한 데이터 정의 모듈이다.

CLI 기반 렌더링 파이프라인

MovieRenderQueue를 CLI 환경에서 구동하고, Web API를 통해 LevelSequence 렌더링을 요청할 수 있는 파이프라인.

설계 및 구현

Camera Direction System의 시퀀스 통합

Camera Direction System을 단독 기능으로 구현하는 대신, 시퀀스 데이터 모델의 일부로 통합했다. 각 카메라 키프레임이 시퀀스 키프레임과 동일한 데이터 레이어에서 관리되도록 하여, 편집 UI에서 일관된 조작이 가능하게 했다.

Shot 정의와 영화 이론 기반 설계. 실제 영상물을 분석하여 Shot 매개변수를 정의했다. 단순히 카메라 위치와 회전만이 아니라, 구도, 앵글, 움직임 유형 등 영화 촬영 이론에서 사용하는 개념을 파라미터화했다. AutoCamera는 이 Shot 정의와 장면 맥락을 입력받아 적절한 카메라 방향을 결정하는 규칙 기반 시스템으로, LLM이 결정한 Shot 의도를 실제 카메라 움직임으로 변환하는 중간 계층 역할을 했다.

검토되었던 대안으로는 별도의 Camera Track을 Sequencer에 직접 추가하는 방식이 있었다. 이 방식은 구현은 빠르지만, 제품 고유의 데이터 모델과 엔진 데이터가 강하게 결합되어 Unreal Engine 업데이트 시 유지보수 부담이 컸을 것이다.

트레이드오프로 Camera 관련 연산의 일부를 엔진 기능에 의존하는 대신, 데이터 저장 및 편집 구조는 독립적인 레이어로 분리했다. 엔진 업데이트 시 Camera Actor의 API 변경은 대응해야 하지만, 데이터 모델 자체는 영향을 받지 않는 구조가 되었다.

LLM 연동을 위한 동기 HTTP 통신 처리

LLM과의 통신은 HTTP 요청을 통해 이루어졌다. Unreal Engine의 HTTP 모듈은 기본적으로 비동기 콜백 기반이지만, LLM 호출 후 그 결과를 기다렸다가 다음 처리로 이어져야 하는 제작 파이프라인의 특성상 동기(blocking) 방식의 HTTP 요청 처리가 필요했다.

비동기 HTTP 요청의 콜백에서 결과가 도착할 때까지 스레드를 대기시키는 방식으로 동기 호출을 구현했다. LLM 응답을 수신한 후 JSON 파싱 → Shot Sequence 생성으로 이어지는 일련의 처리를 순차적으로 수행할 수 있도록 했다.

AI 기능의 파이프라인 통합

LLM 및 학습 모델의 출력을 제작 데이터로 변환하는 과정에서 가장 중점을 둔 것은 “사람이 검토하고 수정할 수 있는 형태”로 만드는 것이었다. AI가 생성한 결과를 그대로 사용하는 것이 아니라, Sequence 데이터로 변환하여 편집 가능한 상태로 제공함으로써 사람의 판단을 중간에 넣을 수 있도록 했다.

LLM Function Calling은 AI 모델의 출력을 JSON 형태의 구조화된 명령으로 변환하는 데 사용했다. 이 명령을 Sequence 생성 명령어로 매핑하여, 텍스트 프롬프트에서 콘텐츠 제작까지의 흐름을 연결했다.

UE5 마이그레이션: MovieScene 갱신 방식 변경

Unreal Engine 4에서 5로 전환되면서 SequencePlayer의 동작 방식이 크게 변경되었다. 가장 큰 차이는 UE5에서 SequencePlayer의 업데이트 메커니즘이 거의 완전히 비동기화된 점이었다.

기존 UE4에서는 특정 시간대에 맞춰 계산이 필요할 때 ForceEvaluate를 사용하여 Scene을 강제로 갱신할 수 있었다. UE5에서는 이 함수가 더 이상 의도한 대로 동작하지 않았다. 문제 해결을 위해 Scene을 명시적으로 갱신하는 우회 구현을 찾아 적용했다.

이 과정에서 기존 코드에서 습관적으로 과다 사용되던 SetPlayPosition 호출을 제거하는 긍정적 부수 효과도 있었다. 다만 최종 애니메이션 업데이트 타이밍이 기대보다 늦게 적용되는 문제(PostEval 시점)가 있어 추가적인 처리가 필요했다.

Grouped Action System 설계

캐릭터 애니메이션을 적용하기 위한 기능 모듈로, 각 Action 그룹마다 서로 다른 매개변수와 실행 타이밍을 가진다. 단일 구조로 모든 Action을 지원하기 어려웠기 때문에, 각 Grouped Action을 콘텐츠를 정의하는 작은 Scene 단위로 접근했다.

Plugin 형태의 Asset Type으로 개발되었으며, 데이터 형식은 GameplayTags만으로 조작 가능하도록 설계했다. 이를 통해 Action이 다른 계산이나 커스텀 로직으로부터 독립적으로 동작할 수 있게 했다.

상세 기획 단계 이전에 POC를 담당하여 기획, 설계, 검증까지 완료했다. POC 성공 완료 후 프로젝트 팀에 이관하였으며, 전용 에디터 개발은 인계 후 진행될 예정이었다.

CLI 기반 렌더링 파이프라인

MovieRenderQueue를 CLI(Command Line Interface) 환경에서 구동하고, Web API를 통해 LevelSequence 렌더링을 요청할 수 있는 파이프라인을 구축했다.

이 과정에서 두 가지 문제가 있었다.

컷 전환 시점의 Motion Blur 문제. Shot Sequence에서 컷이 전환되는 시점에 Motion Blur가 의도치 않게 적용되어 다음 Shot의 첫 프레임이 번져 보이는 현상이 발생했다. 컷 전환 타이밍에 Motion Blur 설정을 일시적으로 비활성화하는 방식으로 처리되었다.

Lumen 조명이 적용된 Screen Snapshot. 제품 파이프라인에서 사용할 Snapshot 이미지에는 완전한 Lumen 조명이 적용된 상태여야 했다. 일반적인 Screen Capture로는 Lumen 최종 조명 결과를 얻을 수 없어, 렌더링 파이프라인 내에서 조명 계산이 완료된 시점을 캡처하도록 처리되었다.

개발 환경 및 운영

결과

회고

Unreal Engine을 제품의 코어로 사용하면서, 엔진 업데이트에 따른 영향을 최소화하는 구조를 유지하는 것이 가장 어려운 부분이었다. 특히 UE4에서 UE5로의 전환은 단순한 버전 업이 아니라 SequencePlayer의 동작 방식 자체가 바뀌는 근본적인 변화였고, 이에 대한 대응이 프로젝트 일정에 큰 영향을 주었다.

AI 기능 통합 부분에서는 모델의 출력 품질보다 “출력을 어떻게 제작 파이프라인에 통합할 것인가”에 더 중점을 두었다. 이 접근은 결과물을 사람이 편집하고 조정할 수 있게 하여, AI 생성 결과의 불완전성을 보완할 수 있는 구조가 되었다.

Grouped Action System은 POC까지 완료하고 이관했으나, 전용 에디터가 완성되지 않은 점은 아쉬움으로 남는다. GameplayTags 기반의 데이터 형식은 유연했지만, 시각적인 편집 도구가 없으면 실제 사용성이 크게 떨어지기 때문이다.

프로젝트 방향성은 LLM으로 장면(Scene)을 구성하고 실제 3D Asset을 기반으로 영상 소스를 생성하는 방식이었다. 당시 대부분의 영상 생성 서비스들이 LLM을 통해 직접 영상을 생성하는 방향과 비교하면 차별화되는 지점이었다. 이후 AI 영상 후보정 기술의 발전에 따라 프로젝트의 접근 방식이 점차 설득력을 얻었고, 수작업으로 제작되던 3D Asset은 외부 Resource import, 모션 및 배경 생성 단계로 진화하며 완전한 생성 서비스로 수렴하는 흐름을 보였다.

프로젝트는 주요 기능이 동작 가능한 단계까지 진행되었으나, 사업 환경 변화로 인해 서비스 안정화와 파이프라인 통합을 완료하기 전 마무리되었다. 이 경험을 통해 기술적 타당성과 제품화 단계의 리스크가 별도로 관리되어야 한다는 점을 체감했다.