editonny 딥다이브
— 대화 한 줄을 검증 가능한 영상 편집으로 바꾸는 법

1프로젝트 한줄 요약

editonny는 Claude Code·Codex 같은 코딩 에이전트에 설치하는 영상 편집 스킬입니다. 사용자가 영상 폴더와 목표를 알려 주면, 에이전트가 스킬의 절차에 따라 원본을 조사하고 컷 편집·자막·오디오 처리·시각 장면·내보내기를 연결합니다. 이 저장소의 핵심은 “AI가 편집한다”는 구호를 실제 파일과 검증 절차로 구체화한 데 있습니다.

사용자가 보는 세 단계

1. 요청: 선택한 영상, 목표 길이, 자막 여부, 보존할 구간을 알려 줍니다.
2. 설정 확인: 원본 조사 결과와 제안 설정을 보고 후속 답변으로 확인합니다.
3. 편집과 전달: 샘플을 검토하고, 검사 결과와 함께 새 MP4를 받습니다.

# 에이전트에 전달할 요청 예시
$editonny
선택한 강의 영상의 긴 침묵과 말실수를 정리해 줘.
말의 의미와 의도적인 쉼은 보존하고, 원어 자막을 붙여 줘.
음악과 효과음은 추가하지 마.
먼저 설정을 보여 주고, 확인 후 8~15초 샘플을 준비해 줘.

공개 웹사이트의 역할은 별개입니다. web/src/features/request/prompt.ts의 createPrompt()는 양식 값을 요청문 문자열로 조합합니다. 영상을 업로드해 편집하는 API 호출은 이 함수에 없습니다. 사이트의 카탈로그와 예시는 요청을 구체화하는 보조 수단입니다.

2왜 주목받는가

2026-10-23 GitHub 기준 생성일은 2026-10-19, 스타는 339개, 포크는 31개입니다. TrendShift Daily #26 선정은 이 글의 출발점입니다. 아래 이유는 README와 구현을 바탕으로 한 관심 요인 해석입니다.

2-1. 이미 쓰는 에이전트가 새로운 작업을 맡는다

저장소는 영상 편집 전용 대화 서비스를 새로 운영하는 대신, 기존 에이전트에 도구와 절차를 전달합니다. 정식 실행 경로는 루트 editonny.py에서 skills/editonny/scripts/editonny.py로 이어집니다. 이 CLI는 inspect, workspace, helper, scene 같은 명령으로 일을 나눕니다.

자연어 인터페이스의 매력은 유지하면서, 편집의 근거를 읽을 수 있는 코드와 데이터로 남기는 구성이 눈에 띕니다. 예를 들어 “역동적으로”라는 말이 음악 추가까지 허용하는지 최신 커밋에서 명확히 분리했습니다. 시각 장면·전환 요청과 추가 오디오 요청은 같은 설정이 아닙니다.

2-2. 기존 편집 방식과의 위치

아래 표는 제품별 성능 순위가 아니라 작업 방식 비교입니다. FFmpeg 직접 사용은 명령 구성 자유도가 높고, 타임라인 중심 편집은 사람이 장면을 직접 다듬기 쉽습니다. editonny의 장점은 반복적인 처리와 요청의 구조화를 연결하는 데 있습니다.

2-3. “화려한 결과”보다 흥미로운 안전한 기본값

skills/editonny/engine/helpers/intake.py의 propose_settings()는 원본 크기·프레임률·색 해석을 기본으로 보존합니다. 음악·효과음·장면·카메라 움직임은 기본 비활성입니다. 원어 전사와 원어 자막을 구분해 기록하며, 대화 언어로 영상의 언어를 추측하지 않습니다.

2-4. 풍부한 재료와 짧은 공개 이력

skills/editonny/visuals/catalog.json의 scenes는 145개, skills/editonny/visuals/media.json의 videos는 79개입니다. 각 영상 항목에는 경로·바이트 수·SHA-256이 있습니다. 단순히 템플릿이 많다는 소개를 넘어, 배포한 리소스의 정체를 확인하는 방식까지 배울 수 있습니다.

3기술 스택 전체 지도

3-1. 백엔드에 해당하는 로컬 처리 계층

핵심 처리는 상시 실행하는 범용 웹 API 서버보다 명령마다 실행되는 Python 프로그램에 가깝습니다. 미리보기에는 Python 표준 라이브러리 기반 HTTP 서버가 따로 있습니다. 엔진 선언은 skills/editonny/engine/pyproject.toml, 조건별로 고정된 버전은 skills/editonny/engine/uv.lock에 있습니다.

잠금 파일의 복수 버전은 모두 동시에 설치된다는 뜻이 아닙니다. NumPy는 Python 3.10에서 2.2.6, 3.11에서 2.4.6, 3.12~3.13에서 2.5.4로 분기합니다. Pillow는 Python 3.10에서 12.3.0, 그 이상에서 13.0.0으로 나뉩니다. MLX 의존성 조건에는 macOS·arm64·Darwin 23 이상이 명시되어 있습니다.

3-2. 프론트엔드는 두 종류다

web/next.config.ts에는 reactCompiler, cacheComponents, typedRoutes, partialPrefetching이 활성화되어 있습니다. transpilePackages에 디자인 시스템을 넣고, 빌드의 파일 추적 기준을 저장소 루트로 잡아 스킬의 카탈로그도 읽습니다.

영상용 HTML 장면과 Next.js 화면은 역할이 다릅니다. 전자는 프레임을 렌더링할 재료이고, 후자는 사용자에게 요청문과 목록을 보여 주는 제품 UI입니다. 같은 저장소에 있다고 해서 안내 사이트가 렌더링 엔진을 호스팅하는 것은 아닙니다.

3-3. 인프라·빌드·검사

CI의 일반 검사 행렬은 Node 22.13.0·24, Python 3.11입니다. 엔진 작업은 FFmpeg와 Tesseract를 설치하고 uv==0.13.0을 사용합니다. npm run check에는 lint 규칙·lint·타입 검사·Python/Node/Vitest 검사·아이콘 검사가 연결되어 있습니다. 저장소에는 컨테이너 배포용 Dockerfile이 없습니다.

라이브러리 이름을 외우기보다, 각 도구가 어느 입력을 받아 어떤 파일을 만드는지 연결해서 읽어 보세요. 다음 절에서는 그 연결을 실제 함수와 작업 파일로 따라갑니다.

4아키텍처 심화 분석

4-1. 전체 시스템 구조

다음은 소스의 역할을 묶어 그린 구조도입니다. 화살표는 하나의 네트워크 연결만 뜻하지 않습니다. 요청문 복사, 프로세스 호출, JSON 파일 읽기·쓰기까지 포함합니다. 외부 생성 서비스는 선택적인 연동이며 기본 편집 경로의 필수 구성품이 아닙니다.

4-2. 패턴 ① 얇은 진입점과 실행 어댑터

skills/editonny/scripts/editonny.py의 main()은 명령을 분배합니다. helper 분기는 이름을 정규식 [a-z][a-z0-9_]*으로 검사하고 실제 파일 존재도 확인합니다. 그런 다음 헬퍼를 잠긴 Python 환경에서 별도 프로세스로 실행합니다.

# main()의 헬퍼 실행 부분 발췌. ENGINE은 스킬 내부 엔진 경로.
return run([
    uv, 'run', '--locked', '--project', ENGINE,
    'python', ENGINE / 'helpers' / f'{name}.py', *argv[2:]
])

run()은 각 인자를 문자열로 바꾸어 subprocess.call()에 목록으로 넘기고, EDITONNY_ENGINE_DIR 환경변수를 설정합니다. 호출자의 현재 디렉토리를 유지하므로 사용자가 준 상대 영상 경로의 의미도 유지합니다. CLI 전체가 하나의 거대한 영상 처리 함수가 되지 않게 책임을 나눈 사례입니다.

4-3. 패턴 ② 설정 계약과 오래된 확인의 무효화

intake.inspect_sources()는 원본을 조사하기 전후에 내용 해시를 비교합니다. 조사 중 파일이 바뀌면 그 관찰을 사용할 수 없기 때문입니다. 이어 propose_settings()가 관찰값·사용자 요청·제안 기본값을 나누어 설정과 요약을 만듭니다.

project_contract.validate_contract()는 스키마 버전 1, 선택한 원본 ID, 영상 크기, 언어, 색 처리, 오디오, 전달 경로 등을 검증합니다. 예를 들어 영상 너비·높이는 16~16384 사이의 짝수 정수여야 하며, 프레임률은 Fraction으로 처리합니다.

# validate_confirmation()의 핵심 조건을 줄여 쓴 의사코드
if confirmation['settingsHash'] != settings_hash(config):
    raise ValueError('설정이 바뀌었으므로 다시 확인해야 함')
if confirmation['sourceIdentityHash'] != identity:
    raise ValueError('선택한 원본이 바뀌었으므로 다시 확인해야 함')
if summaryMessageId == responseMessageId:
    raise ValueError('최초 요청을 후속 확인으로 재사용할 수 없음')

실제 함수는 표시한 요약, 사용자의 답변, 두 메시지의 식별자, 시간대가 있는 시각, 답변이 요약보다 나중인지도 검사합니다. settings_hash()와 artifact_dependencies()는 역할이 다릅니다. 후자는 전체 구성·원본·자산·도구의 해시까지 묶어 렌더링 증거의 유효성을 판단합니다.

사용자가 확인한 설정과 실제 처리에 쓴 설정이 같은지 검사하는 것이 대화형 자동화의 중요한 연결 고리입니다. 다만 기록 필드 검사는 암호학적인 사용자 서명이 아닙니다. 잘못된 기록을 만들지 말라는 스킬 지침과 코드의 일관성 검사가 함께 작동하는 설계입니다.

자막만 수정하라는 요청이 전체 재편집으로 번지지 않게

managed_config(edit, operation='cut')은 범위가 full 또는 intervals일 때만 새 컷을 허용합니다. validate_edl_scope()는 선택하지 않은 원본의 사용을 막습니다. 구간 수정에서는 부모 EDL과 비교해 요청 구간 밖의 원본 구간·순서·크롭·게인·대체 영상 소스가 보존되는지도 검사합니다.

4-4. 패턴 ③ 시간 좌표 변환과 내용 기반 캐시

skills/editonny/engine/helpers/transcribe.py의 transcribe_one()은 오디오를 16 kHz 단일 채널로 읽고, 긴 침묵을 줄인 뒤 음성 인식을 수행합니다. 기본 모델은 large-v3-turbo, 기본 프롬프트는 빈 문자열이며 호출 전 None으로 정리합니다. condition_on_previous_text=False와 단어별 시각을 사용합니다.

핵심 문제는 침묵을 줄인 오디오에서 얻은 단어 시각이 원본 영상의 시각과 다르다는 것입니다. TimeMap.to_orig()와 span_to_orig()가 이 차이를 복원합니다. 단어가 이어 붙인 경계를 가로지르면 더 많이 겹치는 원본 조각을 선택하는 처리도 있습니다.

plan_chunks()는 보통 최대 28초 안에서 조용한 지점을 골라 나눕니다. 상수 설명만 읽으면 놓치기 쉽지만, 끝 조각이 3초 미만이면 직전 조각과 합쳐 30초까지 허용하는 예외가 있습니다. 실제 구현을 따라 읽어야 설정값의 정확한 의미가 보입니다.

is_cached()는 캐시 버전 2, 원본 SHA-256, 엔진·모델 이름, 요청 언어, 프롬프트를 비교합니다. 파일 이름이나 크기가 같다는 이유만으로 이전 전사를 재사용하지 않습니다. silence_guard()·loop_guard()·known_phrase_guard()는 무음 속 단어와 반복 등을 걸러내지만 인식 정확도를 보증하지는 않습니다.

4-5. 패턴 ④ 단계적 파일 게시와 완료 표식

workspace.publish_export()는 검사 통과 여부와 후보·설정·원본 해시를 먼저 확인하고, fidelity.verify_media()로 최종 검사를 다시 수행합니다. 복사할 임시 폴더를 목적지 안에 만들고 파일을 동기화한 뒤, os.link()로 새 이름을 게시합니다.

1. 이미 있는 완성본과 충돌하면 다음 번호를 선택합니다.
2. 후보 MP4와 요청한 자막을 임시 위치에서 준비하고 내용·의존성을 재확인합니다.
3. 영상·자막을 exports/에 게시한 뒤, 리비전의 edit/deliveries/에 전달 manifest를 마지막으로 게시합니다.
4. 게시 도중 실패하면 이 작업이 만든 링크만 되돌리고 임시 폴더를 정리합니다.

같은 리비전의 동시 작업은 revision_lock()이 .workflow.lock을 배타적으로 생성해 제한합니다. 이것은 분산 데이터베이스 트랜잭션과 동일한 보장이 아닙니다. 특히 목적지 파일시스템의 하드링크 지원이 필요하다는 운영 조건까지 함께 읽어야 합니다.

4-6. 같은 “미리보기”라도 공개 사이트와 로컬 서버는 다르다

skills/editonny/engine/helpers/preview_server.py는 기본 127.0.0.1:4830에서 동작하도록 되어 있습니다. 정적 파일 허용 목록, Host 검사, Origin 검사, 실행별 토큰을 사용합니다. skills/editonny/engine/preview/api.mjs의 postJson()은 X-Preview-Token 헤더로 저장 요청을 보냅니다.

검토 승인 시 파일 버전이 달라졌으면 서버는 409로 거부합니다. “방금 본 화면”이 “지금 저장된 영상”과 일치해야 한다는 원칙입니다. 로컬 서버도 파일을 변경하는 순간에는 요청 출처와 데이터의 최신성을 살펴야 한다는 학습 사례입니다.

5디렉토리 구조 해부

5-1. 먼저 읽으면 좋은 다섯 파일

위 표의 skills/editonny/engine/와 skills/editonny/scripts/ 경로는 저장소 루트 기준입니다. 웹 개발에 관심이 있다면 web/src/features/request/prompt.ts와 web/src/features/preferences/store.ts부터 읽어도 좋습니다. 하나의 입력이 어디로 흘러가는지 추적한 뒤 모듈을 넓혀 가세요.

5-2. 저장소 폴더와 사용자 프로젝트 폴더는 다르다

위 구조는 사용자 편집 프로젝트의 기본 배치입니다. workspace.revise_workspace()는 변경 가능한 데이터를 새 리비전으로 복사합니다. 원본 템플릿·이전 리비전·이전 완성본을 각각 보호할 이유가 다르다는 점이 중요합니다.

5-3. 코드 규모를 직접 세면 무엇이 보이는가

커밋 49714f2 기준이며, .git을 제외한 확장자별 물리적 줄 수입니다. 빈 줄·주석·테스트·생성물·번들 코드와 마지막 개행이 없는 줄도 포함하며, JSON·Markdown·미디어는 위 표에 포함되지 않습니다. JavaScript에는 Three.js 계열 상류 코드와 5,989줄짜리 디자인 참조 번들이 포함되어 저자 작성량으로 해석하면 안 됩니다.

처리 중심인 skills/editonny/engine/helpers/만 Python 79개 파일, 40,464줄입니다. 전체 체크아웃은 .git을 제외한 파일 2,561개, 합산 약 507 MiB입니다. 미디어·라이브러리를 함께 담은 저장소라 다운로드 크기와 직접 작성한 코드량도 별개입니다.

6학습 포인트 (기술별)

6-1. Python: 프로그램을 호출하는 프로그램

argparse로 CLI를 나누고 pathlib.Path로 경로를 다룹니다. 엔진의 여러 헬퍼는 subprocess.run()으로 FFmpeg를 호출합니다. 입력 검증, 종료 코드, 표준 오류, 시간 제한을 어떻게 전달하는지 읽으면 자동화 프로그램의 기본기를 익힐 수 있습니다.

6-2. 미디어 처리: 초 단위 숫자 뒤에 있는 시간 체계

project_contract.frame_rate()는 30000/1001 같은 유리수를 유지합니다. 일정한 간격의 프레임을 가진 CFR과, 간격이 달라질 수 있는 VFR은 다르게 처리합니다. skills/editonny/engine/helpers/render_cut.py와 skills/editonny/engine/helpers/render_vfr.py를 비교하면 “영상 1초”를 단순 정수 FPS로만 계산할 수 없는 이유를 볼 수 있습니다.

# 교육용 계산: 300프레임이 차지하는 정확한 시간
from fractions import Fraction

fps = Fraction('30000/1001')
duration = Fraction(300, 1) / fps
print(duration)          # 1001/100초
print(float(duration))   # 10.01초

실습 아이디어는 30 FPS라고 반올림했을 때의 10초와 비교하는 것입니다. 그 차이를 긴 영상에서 누적하면 자막·효과음의 동기화에 어떤 영향을 줄지 생각해 보세요. 단, VFR에는 모든 프레임에 같은 나눗셈을 적용할 수 없습니다.

6-3. 음성 인식: 모델 출력에 방어 로직 붙이기

skills/editonny/engine/helpers/transcribe.py는 모델을 호출한 뒤 끝나지 않습니다. 무음 안의 단어·반복 루프·알려진 오인식 문구를 검사하고, 단어의 시작·끝 시각을 발화 구간 쪽으로 조정합니다. notice_sparse_speech()는 측정한 발화량에 비해 단어가 지나치게 적은 상황도 알립니다.

이는 생성형 모델의 결과를 다음 단계에서 바로 믿지 않고 관측 가능한 신호와 대조하는 사례입니다. tests/integration/test_transcribe_cache.py에서 같은 크기의 다른 파일, 강제 언어와 자동 언어 요청, MLX 미설치 대체 경로를 각각 어떻게 표현하는지 읽어 보세요.

6-4. TypeScript·React: 문자열 생성과 화면 상태 분리

createPrompt()는 입력과 언어를 받아 문자열을 반환하는 순수 함수입니다. web/src/features/request/draft.ts의 parseDraft()는 저장된 값을 필드별로 검사하고, 잘못된 선택지는 기본값으로 되돌리며 자유 입력은 최대 4,000자로 자릅니다.

web/src/features/preferences/store.ts의 createStore()는 저장소 접근 실패를 잡아 메모리 값으로 동작합니다. 원시 저장 문자열을 기준으로 읽은 객체를 캐시하고, 탭 사이의 storage 이벤트도 처리합니다. useStore()는 useSyncExternalStore로 React에 연결합니다.

외부 데이터는 읽는 순간 검증하고, 화면에서 필요한 기능은 실패해도 계속 쓸 수 있게 분리하는 습관을 배워 보세요. 여기서 외부 데이터에는 API 응답뿐 아니라 사용자의 브라우저에 저장된 JSON도 포함됩니다.

6-5. HTML·3D: 현재 시각에서 상태를 계산하는 장면

skills/editonny/engine/project-template/compositions/scenes/3d/engine/time.mjs의 interval()은 현재 시각·시작 시각·길이에서 진행률을 계산하고 범위를 제한합니다. 프레임을 차례로 재생할 때만 맞는 누적 상태보다, 임의 시점 탐색에 유리한 형태입니다.

# interval()의 식을 설명하는 교육용 의사코드
progress = clamp((time - start) / duration, 0, 1)
value = curve(progress)

# 실제 JavaScript는 duration이 0 이하인 경우도 따로 처리한다.

실습 아이디어는 0초 → 2초 → 1초 → 2초 순서로 이동할 때 마지막 2초의 상태가 같은지 확인하는 것입니다. 또 word()의 정규화는 [^a-z0-9]를 제거합니다. 한국어 단어에 그대로 적용하면 정보가 사라질 수 있으므로, 이 특정 3D 단어 앵커가 한국어에서도 잘 작동한다고 단정할 수 없습니다.

6-6. 검사: “되는 경우”보다 “하면 안 되는 경우” 쓰기

표는 각 테스트가 검사하는 시나리오를 요약한 것입니다. 학습할 때는 함수명만 보고 넘어가지 말고 준비 데이터, 실행 단계, 기대 결과의 세 부분을 찾아 표시해 보세요.

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

7-1. 소스와 설치 문서에서 확인한 조건

7-2. GPU가 반드시 필요한가?

이 코드의 Faster Whisper 기본 경로는 device="cpu", compute_type="int8"입니다. CPU 스레드 수는 os.cpu_count() or 4로 지정합니다. 따라서 “음성 인식이 있으니 NVIDIA GPU 필수”라고 쓰는 것은 실제 구현과 맞지 않습니다.

Apple Silicon에서는 MLX Whisper가 설치되어 있으면 default_engine()이 그 경로를 선택합니다. MLX가 없으면 Faster Whisper를 선택하지만, 전사를 실행하려면 해당 패키지도 설치되어 있어야 합니다. Faster Whisper 공식 저장소의 GPU 지원 설명과, editonny가 기본으로 선택한 CPU 실행 설정은 구분해야 합니다.

7-3. 메모리·디스크·시간은 입력에 따라 달라진다

이 저장소에는 신뢰할 만한 공통 최소 RAM·VRAM·렌더링 속도 기준이 제시되어 있지 않습니다. 모델 크기, 영상 길이·해상도, 중간 파일, 장면 수에 따라 비용이 달라집니다. 체크아웃 자체의 약 507 MiB에는 이후 받을 Python 환경·음성 모델·브라우저·프로젝트 캐시가 포함되지 않습니다.

학습용으로는 짧은 SDR 영상 하나로 시작해 전사와 렌더링 시간을 따로 기록하는 편이 좋습니다. 예를 들어 20초 원본을 택한다는 것은 이 글의 실습 규모 제안이며 공식 최소 사양이 아닙니다. 원본 외에 컷·후보·샘플·완성본이 공존할 디스크 여유도 필요합니다.

7-4. “로컬”과 “처음부터 완전 오프라인”은 다르다

intake.detect_language_sample()은 캐시된 모델만 사용하고, 최대 세 원본에 대해 각각 최대 30초로 제한된 언어 샘플을 조사합니다. 반면 실제 전사 경로는 모델이 없으면 첫 다운로드가 일어날 수 있습니다. skills/editonny/engine/project-template/build.py의 prepare()도 고정 버전 GSAP을 내려받는 경로를 갖습니다.

도구·모델·브라우저·자산을 준비한 후의 로컬 처리와 초기 준비 단계의 네트워크 요구를 구분하세요. 호스트 에이전트의 대화 서비스와 선택적 외부 생성 서비스는 또 다른 경계입니다. 로컬 렌더링이라는 표현을 모든 정보가 어떤 상황에서도 기기 밖으로 나가지 않는다는 보장으로 확대하면 안 됩니다.

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

아래 다섯 과제는 읽기부터 구현·미디어 검사까지 순서대로 난도가 높아집니다. 실행이 필요한 과제는 필요한 도구를 별도로 준비한 환경에서 수행하세요. 원본 영상과 기준 코드를 보존하고, 합성한 짧은 샘플이나 직접 만든 영상을 사용하면 결과를 비교하기 쉽습니다.

각 과제의 결과물은 기능 추가 목록보다 “어떤 입력에서 어떤 결과를 기대하는가”를 설명하는 짧은 기록이면 충분합니다. 동작을 직접 실행했을 때는 사용한 커밋·OS·도구 버전·입력 특성도 함께 적어 두세요.

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

영상 처리를 처음 배우는 개발자를 위한 권장 순서입니다. 주차는 학습 계획의 단위이며 소요 시간을 보장하는 일정은 아닙니다. 모든 기능을 동시에 구현하기보다, “입력 한 개에서 검증 가능한 결과 한 개”를 만드는 흐름을 유지하세요.

분야별로 더 깊게 가고 싶다면

• 영상 엔진: CFR 컷 경로와 VFR 컷 경로의 프레임·오디오 경계를 비교하고, 재인코딩과 스트림 복사의 차이를 정리합니다.
• 프론트엔드: web/src/features/catalog/scenes.ts의 공개 필드 추출과 번역 대체값을 읽고, 서버 전용 데이터와 클라이언트 상태의 경계를 그립니다.
• 에이전트 설계: 스킬의 자연어 규칙마다 코드 검사가 있는지 대응표를 만듭니다. 지침만 있는 부분과 실행 경로에서 막는 부분을 구분합니다.
• 미디어 품질: 픽셀 형식·색 태그·원본 대응 프레임을 공부하고, “파일이 재생됨”과 “요청한 특성이 보존됨”의 차이를 설명합니다.

최종 목표는 이 저장소 전체를 외우는 것이 아니라, 새 자동화 도구에서도 입력·판단·실행·검증의 경계를 찾을 수 있게 되는 것입니다. 각 주차 마지막에는 실패 입력 하나를 골라 어디에서 멈춰야 하는지 표시해 보세요.

10핵심 키워드 사전

11참고 링크

11-1. 공식 저장소와 소스 읽기 지도

이 글의 파일 경로는 모두 49714f2 기준입니다. 아래 소스 링크도 해당 커밋에 고정했습니다. README는 사용 경험의 설명으로, 코드와 설정 파일은 구현 근거로, 검증 문서는 작성자가 남긴 특정 환경의 기록으로 읽으세요.

• 공식 저장소 · README · TrendShift
• 구조 설명 · 설치·복구 문서 · 검증 근거와 알려진 한계
• 에이전트용 절차 · 정식 CLI
• 원본 조사와 설정 제안 · 계약·확인·범위 검사
• 전사와 시간 변환 · 리비전과 완성본 게시
• 합성 프로젝트 빌더 · FFmpeg 합성 경로 · 로컬 검토 서버
• 프로젝트 자산 복사 · 웹 요청문 생성 · 저장 상태와 대체 동작
• 루트 의존성·명령 · 웹 의존성 · 엔진 선언 · 엔진 잠금 파일
• CI 설정 · 설정 제안 검사 · 전달 실패·보존 검사

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

• Python argparse · subprocess · fractions: 명령·프로세스·정확한 비율 계산.
• uv 잠금과 동기화: 선언·잠금 파일·실행 환경의 관계.
• FFmpeg 공식 문서 · ffprobe: 스트림 조사와 미디어 처리.
• Faster Whisper · MLX Whisper: 로컬 음성 인식의 두 실행 계열.
• React 외부 상태 연결 · Next.js App Router · next-intl: 안내 사이트의 구성 기술.
• Three.js · GSAP · Playwright: 장면·모션·브라우저 검사 심화.

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

저장소 메타데이터는 2026-10-23 GitHub API 기준이며, 버전·목록 개수·코드 규모는 커밋 49714f2 기준입니다. 외부 기술 문서는 개념 학습용이며, 의존성 버전은 저장소의 선언과 잠금 파일을 기준으로 읽으세요.

11-4. 소개 문구와 구현을 함께 읽을 때 생기는 차이