filmcraft 딥다이브
— 한 번의 자르기 뒤에 숨은 영상 편집 시스템

1프로젝트 한줄 요약

FilmCraft는 여러 영상·음성·자막을 타임라인에 배치하고, 편집·합성한 결과를 영상 파일로 내보내는 Rust 기반 비선형 편집기입니다. 핵심 로직은 crates/engine에 있고, 화면은 crates/ui-egui라는 별도 부품입니다. 같은 편집 명령을 사람이 화면에서 누르거나 자동화 도구가 호출해도, 공통 엔진이 처리하도록 설계했습니다.

1-1. 영상 파일 하나가 결과물이 되기까지

1. 가져오기: 컨테이너에서 영상·음성 스트림과 시간 정보를 읽습니다.
2. 문서 구성: Project 안에 미디어와 Sequence를 등록합니다.
3. 편집: TrackItem의 시작 시각·원본 시작점·길이를 바꿉니다.
4. 재생: 현재 시각에 보일 프레임을 디코딩하고 효과와 합성을 적용합니다.
5. 내보내기: 렌더링한 프레임을 인코딩한 뒤 컨테이너에 기록합니다.

crates/project/src/lib.rs의 MediaRef::File은 경로를 저장하고, crates/edit/src/lib.rs의 split_track_at()은 클립 문서를 나눕니다. 이 함수를 실행한다고 원본 동영상의 바이트를 두 파일로 잘라 저장하는 것은 아닙니다.

2왜 주목받는가

TrendShift Monthly #17 선정작이며, 2026-10-23 GitHub 기준 스타 15,809개와 포크 6,630개를 기록했습니다. 생성일은 2026-09-30입니다. 짧은 공개 기간에 관심이 모인 점은 확인할 수 있지만, 스타 증가의 원인이나 실제 사용자 수를 이 숫자만으로 알 수는 없습니다. 다음은 소스와 README에서 읽히는 관심 요인에 대한 해석입니다.

2-1. 화면 아래의 코덱까지 읽을 수 있다

README는 주요 코덱을 공개 명세에서 직접 구현했다고 설명합니다. 실제로 crates/h264, crates/hevc, crates/av1, crates/aac와 MP4/MOV를 담당하는 crates/isobmff가 분리되어 있습니다. 입문자가 곧바로 H.264를 구현하기는 어렵지만, “파일을 읽는다”는 한 줄 아래에 어떤 계층이 있는지 보기에는 좋은 표본입니다.

2-2. 자동화를 제품의 입구로 둔다

crates/engine/src/commands.rs는 명령 식별자, 표시 이름, 매개변수 설명, 실행 가능 조건과 실행 함수를 함께 등록합니다. crates/automation/src/server.rs의 FilmcraftMcp::run()은 창 없는 세션에서는 Session::execute()를 호출하고, 연결 모드에서는 실행 중인 앱으로 전달합니다. “AI 기능”이라는 이름보다 외부 프로그램이 안정적인 동작 단위에 접근한다는 점이 학습상 중요합니다.

2-3. 경쟁 제품과 비교할 때 볼 축

프로젝트가 비교 목표로 삼는 제품은 Adobe Premiere Pro입니다. 아래 표는 docs/target-app-parity.md와 docs/gaps.md가 제시한 목표를 바탕으로, FilmCraft의 장점과 아직 남은 차이를 정리한 것입니다. 독립적인 기능 점수나 속도 순위는 아닙니다.

이 저장소의 뚜렷한 학습상 장점은, 편집 화면의 동작을 파일 해석과 프레임 계산까지 거슬러 올라가 볼 수 있다는 점입니다.

3기술 스택 전체 지도

이 앱에서 “백엔드”는 원격 HTTP 서버보다 창 없이 동작하는 로컬 엔진을 뜻합니다. 프론트엔드는 egui이고, 데스크톱 호스트가 운영체제의 창·오디오·파일 대화상자를 연결합니다. 일반 편집에 데이터베이스나 웹 서버 배포를 전제로 한 구조는 아닙니다.

3-1. 백엔드: 문서·편집·미디어 엔진

표의 왼쪽 버전은 각 Cargo.toml의 허용 범위이고, 오른쪽은 Cargo.lock에 기록된 선택 버전입니다. 예를 들어 "0.25"와 0.25.10은 서로 모순되지 않습니다. 선언과 실제 해석 결과를 구별하는 연습이 됩니다.

3-2. 프론트엔드: Rust UI와 GPU

React나 Tauri가 중심인 앱이 아닙니다. 핵심 UI 의존성은 egui/eframe입니다. 웹 앱도 별도의 TypeScript 화면을 다시 만드는 대신 같은 엔진과 UI를 wasm32-unknown-unknown으로 컴파일합니다. 다만 브라우저의 파일·오디오·디코더에는 web-sys와 JavaScript 연결 코드가 필요합니다.

3-3. 자동화·인프라·빌드

빌드의 중심 파일은 Cargo.toml과 Cargo.lock입니다. 추적 파일 목록에는 package.json, pyproject.toml, go.mod, Dockerfile이 없습니다. 웹 대상이 있다고 해서 Node.js 설치나 컨테이너 서버가 필수인 것은 아닙니다.

의존성 목록을 읽을 때는 이름만 외우기보다, 어느 계층이 그 라이브러리를 가져오는지 함께 확인하세요. 특히 cpal은 데스크톱 호스트에, rmcp는 자동화에 두어 편집 규칙과 분리합니다.

4아키텍처 심화 분석

4-1. 전체 시스템 구조도

아래는 주요 호출과 데이터 흐름을 단순화한 그림입니다. 위쪽은 사용자의 요청을 받는 부분, 가운데는 편집 상태를 바꾸는 부분, 아래쪽은 영상과 음성을 실제로 계산하는 부분입니다. 모든 의존성 선을 나열한 그래프는 아닙니다.

계층 표는 xtask/src/main.rs의 LAYERS에 있습니다. layers()는 상위 계층으로 향하는 내부 의존성을 거부하고, L5 아래에서 egui·eframe·cpal 같은 UI·OS 부품을 참조하지 못하게 검사합니다. L1 이상에서 같은 계층 간 연결도 SAME_LAYER에 허용된 경우만 통과합니다.

4-2. 패턴 ① 명령 레지스트리: 버튼과 API가 같은 규칙을 만난다

crates/engine/src/commands.rs::CommandSpec에는 id, label, menu, shortcut, params, enabled, run, journal이 있습니다. 표시할 정보와 실제 동작이 한 항목에 모여 있으므로 메뉴, 명령 검색, 자동화가 같은 목록을 참고할 수 있습니다.

// CommandSpec의 일부 필드: 원본 선언에서 발췌
pub id: &'static str,
pub params: &'static str,
pub enabled: Enabled,
pub run: Run,
pub journal: bool,

// 실제 타입 별칭
type Run = fn(&mut Session, &Value) -> Result<Value>;
type Enabled = fn(&Session) -> std::result::Result<(), String>;

params 자체는 설명 문자열이고, 호출 시 매개변수는 serde_json::Value입니다. 따라서 “등록만 하면 모든 명령의 입력 타입이 컴파일 시점에 검증된다”고 이해하면 안 됩니다. 각 핸들러의 파싱과 유효성 검사가 실제 경계입니다.

1. crates/ui-egui/src/menus.rs::invoke()가 엔진 명령을 Session::execute()로 전달합니다.
2. execute()가 commands::find()로 명령을 찾고 enabled_for()로 실행 조건을 확인합니다.
3. spec.run이 편집 함수를 호출합니다. 성공한 변경 명령은 저널에도 남습니다.
4. MCP의 FilmcraftMcp::run()도 같은 엔진 입구를 사용합니다. 창 없는 모드에서는 Mutex로 세션 접근을 조정합니다.

예를 들어 timeline.razor는 트랙이나 클립을 고른 뒤 Session::edit_sequence() 안에서 edit::razor() 또는 edit::razor_items()를 호출합니다. 클립을 지정하고 연결 선택이 켜져 있으면 with_links()가 연결된 영상·음성 클립까지 처리 대상을 확장합니다.

// CLI 일괄 명령의 한 줄: 활성 시퀀스의 V1, 3초 지점
{"id": "timeline.razor", "params": {"track": "V1", "time": 762048000000}}

이 JSON 한 줄은 CLI의 run 하위 명령이 읽는 JSONL 항목입니다. TCP 제어 채널에서는 engine.execute라는 메서드와 인증 토큰을 담은 별도 요청 형식이 필요합니다. 전송 방식이 달라도 명령 식별자와 편집 규칙은 공유합니다.

4-3. 패턴 ② 스냅샷과 트랜잭션: 실패한 편집은 현재 문서를 바꾸지 않는다

crates/engine/src/lib.rs::Session::edit()는 먼저 프로젝트와 편집 상태를 복제하고, 복제본에 변경을 적용한 뒤 성공했을 때만 현재 프로젝트를 교체합니다. 시퀀스 중첩에 새 순환 참조가 생기지 않는지도 refuse_self_nesting()으로 확인합니다.

// Session::edit()에서 핵심 순서를 발췌
let mut p = (*self.project).clone();
let mut st = self.state.clone();
let r = f(&mut p, &mut st)?;
self.refuse_self_nesting(&p)?;
let old = std::mem::replace(&mut self.project, Arc::new(p));
self.history.undo.push((label.to_string(), old));

?는 오류가 나면 즉시 반환합니다. 위 코드에서 오류가 생기면 교체 단계에 도달하지 않으므로, 이 편집 경로의 현재 프로젝트와 상태가 유지됩니다. edit_sequence_as()는 여기에 Sequence::check() 검사도 더합니다. 여러 편집을 묶는 edit_group()에는 실패 시 이력과 문서를 되돌리는 처리도 있습니다.

History의 두 스택은 Vec<(String, Arc<Project>)>입니다. undo()는 이전 프로젝트를 꺼내 현재 것과 교환하고, 현재 것을 redo 스택에 넣습니다. edit_merged()는 다른 편집 없이 같은 키·라벨로 이어지는 슬라이더 드래그를 한 번의 실행 취소 단계로 합칩니다.

비용도 구별해야 합니다. Arc::clone()으로 기존 스냅샷을 공유하는 일은 가볍지만, 위 Project::clone()은 프로젝트 데이터를 복제하는 경로입니다. 모든 편집이 상수 시간이라는 뜻도, 모든 하위 자료구조가 영속 자료구조라는 뜻도 아닙니다. 또 Session::new()는 History { limit: 200, ... }으로 초기화합니다. README의 “무제한 undo”보다 실제 기본 설정이 구체적입니다.

4-4. 패턴 ③ 정확한 시간 모델: 초 대신 정수 Tick으로 편집한다

crates/time/src/lib.rs는 Tick(pub i64)와 초당 254_016_000_000 Tick을 정의합니다. 프레임률은 실수 하나가 아니라 FrameRate { num, den }으로 저장합니다. 흔히 29.97이라고 부르는 규격은 여기서 정확히 30000 / 1001입니다.

// 학습용 계산 예시: crates/time의 공개 API
use filmcraft_time::{FrameRate, Tick};

let rate = FrameRate::FPS_29_97;
let first_frame = rate.frame_duration();
let sample = Tick::from_units(1, 48_000);
// first_frame.0 = 8_475_667_200
// sample.0 = 5_292_000

FrameRate::frame_duration()은 중간 계산에 i128을 사용하고, sane()은 분자나 분모가 0 이하인 프레임률을 기본값으로 바꿉니다. TimeRange는 [start, end)인 반열린 구간이므로, 맞닿은 두 클립의 경계 시각이 양쪽에 동시에 포함되지 않습니다.

정확성의 범위도 있습니다. 흔한 방송 프레임률은 정수로 표현되지만, 임의의 특이한 비율은 나눗셈에서 버림이 생길 수 있습니다. Tick::from_seconds_f64()는 경계 입력을 반올림하고, edit::split_track_at()의 배속 계산에는 f64가 사용됩니다. 따라서 “코드 전체에서 실수를 전혀 쓰지 않는다”보다 편집 시각의 기준을 정수로 통일한다가 정확합니다.

4-5. 패턴 ④ CPU 기준 구현과 GPU 가속 경로

crates/render/src/lib.rs::render_sequence()는 시각·크기·소스를 받아 선형광 이미지로 렌더링합니다. crates/render/src/plan.rs::plan_frame()은 GPU가 처리할 수 있는 레이어를 계획으로 표현합니다. FramePlan은 Layers, Composite, Image 세 경우를 구별합니다.

• 직접 처리: 지원하는 효과와 변환은 원본 프레임·행렬·불투명도를 GPU에 전달합니다.
• 혼합 처리: 지원하지 않는 효과 등은 CPU에서 해당 레이어를 계산할 수 있습니다.
• 전체 대체: 필요한 경우 CPU에서 만든 최종 이미지를 FramePlan::Image로 전달합니다.

crates/gpu/src/export_renderer.rs::ExportRenderer::render()에도 GPU 내보내기 경로가 있습니다. 다만 FramePlan::Composite는 None을 반환해 CPU 처리로 넘깁니다. README의 “내보내기 렌더링은 CPU”라는 상태 설명만으로는 이 구현을 다 설명하지 못합니다.

crates/gpu/src/tests.rs::yuv_code_range_gpu_matches_cpu()는 8·10·12·16비트 입력을 CPU와 GPU로 처리해 비교합니다. 해당 테스트는 8비트 RGBA 출력에서 채널별 최대 오차를 1로 허용합니다. 그러므로 “같은 결과를 목표로 한다”와 “모든 경로의 모든 바이트가 항상 같다”도 구분해야 합니다.

빠른 구현을 만들 때는, 먼저 비교할 수 있는 기준 구현을 두고 지원하지 않는 경우 돌아갈 길까지 설계해야 합니다.

5디렉토리 구조 해부

추적 중인 파일은 1,393개이며, crates/ 아래 패키지 50개, apps/ 아래 패키지 3개, 그리고 xtask가 있습니다. 아래 트리는 핵심 부분만 발췌한 것으로, 모든 폴더의 목록은 아닙니다.

5-1. 질문으로 고르는 읽기 순서

5-2. 코드 규모는 이렇게 읽는다

커밋 abf44fd의 Git 추적 파일을 확장자별로 센 값입니다. 빈 줄·주석·테스트·소스에 들어 있는 표 데이터도 포함하며, 의존성 다운로드와 빌드 산출물은 포함하지 않습니다. 따라서 실행 로직만 센 순수 코드 줄 수와는 다릅니다.

Rust 가운데 crates/ui-egui는 75,495줄, crates/engine은 57,323줄, crates/render는 23,281줄입니다. 시간 계산만 떼면 crates/time은 922줄입니다. 큰 제품 안에서도 학습 단위를 작게 고를 수 있습니다.

6학습 포인트 (기술별)

6-1. Rust: 실패를 반환값으로 표현하기

커밋 abf44fd의 색상 입력 검증은 입문하기 좋은 예제입니다. crates/color/src/lib.rs::parse_hex()는 앞뒤 공백을 정리하고 선택적인 # 하나를 뺀 뒤, 모든 바이트가 ASCII 16진수 문자인지 검사합니다. 길이가 6이면 RGB, 8이면 RGBA로 처리하고 나머지는 None을 반환합니다.

// parse_hex()의 입력 검증 부분
let s = s.trim();
let s = s.strip_prefix('#').unwrap_or(s);
if !s.bytes().all(|b| b.is_ascii_hexdigit()) {
    return None;
}

unwrap_or(s)는 값이 없을 때 원래 문자열을 쓰는 대체 처리입니다. 값이 없으면 중단되는 unwrap()과 다릅니다. 이어지는 s.get(i..i + 2)?는 잘못된 문자열 구간도 실패로 표현합니다. 문자열 길이뿐 아니라 허용된 문자도 검사해야 유효한 색상인지 판단할 수 있습니다.

실습 아이디어: parse_hex_rejects_signs()를 읽고 #+f+f+f, ##0f0f0f, #0f0f0f가 각각 어느 조건에서 갈리는지 표로 적어 보세요. 성공값만 확인하는 테스트보다 잘못된 입력의 종류를 분류하는 테스트를 배울 수 있습니다.

6-2. 타입 설계: 숫자가 같아도 의미가 다르면 구별하기

crates/project/src/lib.rs의 id_type! 매크로는 ItemId, TrackId, ClipId 등을 각각 u64를 감싼 별도 타입으로 만듭니다. 같은 숫자 12라도 “원본 아이템 12”와 “타임라인 클립 12”는 다른 의미입니다.

실습 아이디어: 서점의 BookId와 MemberId를 만들어 같은 숫자 타입을 직접 쓰는 경우와 비교하세요. “메모리 표현이 같다”와 “업무상 같은 값이다”를 분리하는 연습입니다.

6-3. trait와 의존성 역전: 사용할 기능을 약속으로 받기

crates/media/src/lib.rs의 MediaSource는 프레임·오디오를 얻는 소스의 공통 약속입니다. 파일, 정지 이미지, 이미지 시퀀스, 합성 데모가 같은 인터페이스에 들어갑니다. crates/render/src/lib.rs::SourceProvider는 아이템 ID를 소스에 연결하는 방법을 추상화합니다.

또 crates/codecs/src/video.rs::VideoDecoder에는 decode(), flush(), reset() 등이 있습니다. register_video_decoder()는 새 디코더 팩토리를 목록 앞에 넣습니다. 운영체제 디코더를 먼저 시도하고, 지원 범위에 따라 소프트웨어 구현으로 돌아갈 수 있는 연결점입니다.

// VideoDecoder의 핵심 인터페이스 발췌
pub trait VideoDecoder: Send {
    fn decode(&mut self, sample: &[u8], pts: i64)
        -> Result<Vec<DecodedFrame>>;
    fn flush(&mut self) -> Vec<DecodedFrame>;
    fn reset(&mut self);
    // 원본에는 이름·랜덤 접근·초안 모드 등의 메서드도 있음
}

실습 아이디어: 렌더러가 실제 파일 대신 단색 소스를 받는 과정을 그리세요. 테스트를 위해 큰 동영상을 준비하는 대신, 재현 가능한 가짜 입력을 넣을 수 있는 이유가 드러납니다.

6-4. 동시성: 공유 읽기와 변경 요청을 구별하기

Arc<Project>는 변경되지 않는 스냅샷을 여러 읽기 작업이 함께 소유하게 합니다. 반면 MCP의 창 없는 Backend::Headless는 Arc<Mutex<Session>>입니다. 전자는 문서를 읽는 쪽의 수명 문제, 후자는 명령이 세션 상태를 바꾸는 순서 문제를 풉니다.

실습 아이디어: “재생이 문서 A를 읽는 중에 편집으로 문서 B가 생겼다”는 상황을 시간순으로 그려 보세요. A를 읽는 작업이 끝나기 전에 메모리가 해제되지 않는 이유와, 공유 문서를 직접 수정하지 않는 이유를 설명해 보세요.

6-5. 그래픽스: 좌표·색·투명도를 따로 생각하기

PlanLayer는 프레임과 좌표 변환 행렬, 불투명도, 혼합 모드를 함께 보관합니다. crates/geom의 변환과 crates/color의 색 변환은 서로 다른 문제입니다. 위치가 맞는데 색이 틀리는 오류와, 색은 맞는데 위치가 어긋나는 오류를 분리해 볼 수 있습니다.

실습 아이디어: 단색 사각형 두 개로 시작해 위치 이동, 반투명 겹치기, 색 공간 변환을 한 번에 하나씩 추가하세요. 차이를 설명할 수 있는 작은 입력이 복잡한 실제 영상보다 디버깅에 유리합니다.

6-6. 시스템 프로그래밍: 빠른 계산보다 메모리의 생애가 먼저다

crates/media/src/cache.rs::FrameCache는 프레임 개수가 아니라 바이트 예산을 기준으로 캐시를 관리합니다. 예산을 넘으면 오래 사용하지 않은 항목부터 내보내 목표 사용량을 예산의 90%로 낮춥니다. 서로 크기가 다른 프레임을 모두 “한 장”으로 세면 메모리 사용을 통제하기 어렵기 때문입니다.

실습 아이디어: 같은 10장의 프레임이라도 360p와 4K의 메모리가 얼마나 다른지 계산하고, “최대 10장” 캐시와 “최대 64 MiB” 캐시의 차이를 비교하세요. 문서에 성능 수치가 있더라도 입력 크기·동시 작업 수·캐시 조건을 함께 읽어야 합니다.

6-7. 검증과 저장: 규칙을 자동으로 확인하는 코드

xtask/src/main.rs::layers()는 아키텍처 규칙을 검사하고, crates/format/src/atomic.rs::atomic_write()는 같은 디렉토리의 임시 파일에 먼저 쓰고 동기화한 뒤 이름을 바꿉니다. 마지막 디렉토리 동기화는 최선 노력 방식으로 처리합니다. “저장 버튼을 만들었다”보다 더 깊은 데이터 보존 문제입니다.

좋은 학습 단위는 기능 이름이 아니라, 그 기능이 실패해도 지켜야 하는 불변식입니다. 색상은 유효한 형식이어야 하고, 자른 두 조각의 길이는 원래 길이를 보존해야 하며, 실패한 편집은 현재 문서를 망가뜨리지 않아야 합니다.

7하드웨어 / 시스템 요구사항

커밋 기준 문서에는 모든 편집 상황을 포괄하는 CPU·RAM·VRAM 최소 사양표가 없습니다. 따라서 특정 메모리 용량을 공식 최소 사양으로 제시할 수 없습니다. 대신 실행 대상과 빌드 조건은 다음 파일에서 확인할 수 있습니다.

macOS의 11.0은 배포 설정값이며 모든 기기에서의 실행 보증과는 다릅니다. 또 기여 문서의 Linux 안내에는 GTK 3가 나오지만, 현재 CI는 ALSA·X11·Wayland·폰트·Vulkan 관련 패키지를 설치합니다. 환경 구성에서는 설명 문서의 날짜와 실제 워크플로를 함께 보아야 합니다.

7-1. 메모리는 해상도와 표현 형식에 따라 달라진다

RGBA의 네 채널을 각각 32비트 실수로 저장한다면 한 픽셀은 16바이트입니다. 압축 파일의 크기와 디코딩·합성 중 메모리 크기는 같지 않습니다. 아래는 프레임 한 장의 산술 계산입니다.

# 부가 자료구조를 제외한 RGBA f32 픽셀 버퍼
1920 × 1080 × 4 × 4 =  33,177,600 바이트 ≈ 31.6 MiB
3840 × 2160 × 4 × 4 = 132,710,400 바이트 ≈ 126.6 MiB

# 가로·세로를 각각 절반으로 줄이면 픽셀 수는 1/4
960 × 540 × 4 × 4 = 8,294,400 바이트 ≈ 7.9 MiB

crates/render/src/lib.rs의 Canvas는 실제 합성이 필요할 때까지 이미지 할당을 미룹니다. 하지만 효과의 중간 버퍼, 여러 레이어, 디코더 참조 프레임, GPU 텍스처가 추가될 수 있습니다. 위 값은 앱 전체 RAM 사용량도, GPU 경로의 텍스처 용량도 아닙니다.

crates/export/src/job.rs는 겹쳐 처리하는 프레임 묶음에 IN_FLIGHT_BUDGET = 1 << 29, 즉 512 MiB를 설정합니다. overlap_batch()는 그 안에 들어갈 묶음 크기를 계산하되 최소 한 프레임은 허용합니다. 이 예산은 해당 버퍼 묶음의 계산 기준이며 프로세스 전체 메모리의 강제 상한은 아닙니다.

학습을 시작할 때는 작은 해상도와 짧은 클립으로 계산을 이해한 뒤, 해상도·레이어·동시 작업을 하나씩 늘리세요.

7-2. CPU 대체 경로와 브라우저 제약

FILMCRAFT_CPU_COMPOSITE=1은 데스크톱 미리보기의 GPU 합성을 끕니다. 내보내기의 GPU 사용은 별도 설정입니다. 창을 띄우는 그래픽 장치 초기화까지 없애는 설정은 아니므로 “GPU가 전혀 필요 없다”로 해석하면 안 됩니다. 창 없는 CLI와 창을 띄우는 데스크톱 앱도 요구 조건이 다릅니다.

docs/web.md 기준 웹 빌드는 단일 스레드입니다. 프레임 작업은 FrameServer::pump, 내보내기는 Session::pump_jobs를 통해 조금씩 진행하며, WebAudio와 OPFS가 각각 소리와 복구 저장을 맡습니다. 데스크톱 스레드를 그대로 브라우저에서 실행하는 구조는 아닙니다.

8직접 해볼 수 있는 실습 과제

아래 과제는 읽기와 계산에서 시작해 작은 연습 모델로 확장합니다. 기존 코드를 통째로 실행하지 않아도 핵심 원리를 검증할 수 있습니다. 난이도보다 어떤 조건이 맞으면 성공인지를 먼저 정하고 진행하세요.

ticks_per_second = 254_016_000_000
numerator = ticks_per_second * 1001
assert numerator % 30000 == 0
frame_ticks = numerator // 30000
sample_ticks = ticks_per_second // 48000
assert sample_ticks * 48000 == ticks_per_second
print(frame_ticks, sample_ticks)

실습의 성공 기준을 “화면이 나왔다”에서 “어떤 입력에 어떤 상태와 결과가 남는지 설명할 수 있다”로 바꿔 보세요.

9관련 기술 심화 학습 로드맵

주차는 진도 배분의 예시입니다. 하루에 읽을 파일 수를 정하기보다, 그 주의 질문에 답하는 산출물을 하나씩 남기세요. 프로그래밍을 막 시작했다면 1~2주차를 더 길게 잡고 코덱 내부 수학은 뒤로 미뤄도 됩니다.

표에서 crates/color/부터 crates/automation/까지는 공통 기능을 나눈 crates/ 아래 라이브러리 패키지입니다. 매주 공식 문서에서 개념 하나를 읽고, 대응하는 함수와 테스트 하나를 찾아 연결하면 됩니다.

9-1. 관심 분야에 따라 갈라지는 다음 단계

• 앱 개발이 좋다면: crates/ui-egui에서 메뉴 호출, 패널 상태, 단축키가 엔진 명령과 연결되는 방식을 읽습니다.
• 저수준 처리가 좋다면: crates/bitstream의 비트 입출력에서 시작해 crates/isobmff의 컨테이너 경계로 이동합니다.
• 그래픽스가 좋다면: crates/geom의 변환, crates/render의 CPU 합성, crates/gpu의 WGSL 순서로 읽습니다.
• 자동화가 좋다면: CommandSpec, FilmcraftMcp, 제어 채널의 인증·길이 제한 순서로 연결합니다.

다음 단계로 넘어가는 기준은 파일을 다 읽었는지가 아니라, 작은 입력의 결과를 스스로 예측하고 근거 함수를 찾을 수 있는지입니다.

10핵심 키워드 사전

11참고 링크

11-1. 공식 저장소와 프로젝트 문서

• FilmCraft 공식 저장소 — 최신 코드·이슈·배포 입구.
• v0.12.0 릴리스 — 2026-10-23 기준 최신 릴리스.
• 분석 기준 커밋의 전체 트리 — 아래 소스 링크가 가리키는 기준.
• README — 기능 설명과 alpha 상태.
• 아키텍처 문서 — 계층·시간·문서·명령의 설계 의도.
• 개발 환경과 기여 안내 — 도구와 빌드 조건.
• 웹 앱 문서 — WASM·브라우저 파일·오디오·복구 제약.
• 테스트 설계 · 성능 문서 — 비교 도구와 측정 조건.
• 제어 프로토콜 · 자동화 안내 — 명령 호출과 인증.
• 부족한 영역 · 경쟁 목표와 평가 방법 — 제품 한계의 자체 평가.

11-2. 본문의 핵심 소스 바로가기

11-3. 관련 기술의 공식 학습 자료

• Rust 공식 책 — 소유권·오류 처리·trait·동시성의 기초.
• Cargo workspace 문서 — 여러 패키지의 공통 설정 읽기.
• egui API 문서 · eframe API 문서 — UI와 앱 호스트 구분.
• wgpu API 문서 · WGSL 명세 — GPU 작업 구성과 셰이더 언어.
• Serde 공식 문서 — Rust 데이터의 직렬화·역직렬화.
• Rayon API 문서 · Tokio 공식 입문 — CPU 병렬 작업과 비동기 입출력 구분.
• MCP 공식 문서 — 도구 호출을 연결하는 프로토콜.
• TrendShift — 저장소 탐색과 트렌드 참고.

외부 기술 문서의 기본 페이지는 최신 버전을 보여 줄 수 있습니다. 이 글의 API와 의존성 버전을 맞춰 읽으려면 Cargo.lock의 버전을 기준으로 선택하세요.

현재 상태 (2026-10-23 확인)