핵심 요약: 코드가 버전 관리되는 것은 명시적이기 때문입니다. 편집 노하우는 그렇지 않습니다. 암묵적이고, 한 편집자의 손에 갇혀 있습니다. YouViCo의 시도는, 암묵적인 편집 노하우에 Git을 안전하게 만드는 세 가지 속성—diff할 수 있고, 테스트할 수 있고, 되돌릴 수 있는—을 부여할 수 있다는 것입니다. 그렇게 하는 순간, 팀의 편집 기술은 누군가 떠날 때 함께 사라지는 것이 아니라 공유되고 발전하는 자산이 됩니다. 그 설계를 소개합니다.
문제: 편집 기술은 확장되지 않는다
숙련된 편집자는 손안에 수백 개의 작은 판단을 지니고 있습니다. 대사를 얼마나 타이트하게 자를지. 언제 한 박자를 숨 쉬게 둘지. 보이스오버 아래 음악을 어떻게 균형 잡을지. 그 어느 것도 적혀 있지 않습니다. 직관으로 존재하고, 편집자가 떠나면 함께 떠납니다.
코드에는 이런 문제가 없습니다. 코드는 명시적입니다. 적혀 있고, diff할 수 있고, 리뷰할 수 있고, 되돌릴 수 있습니다. Git이 작동하는 이유의 전부입니다. 무엇이 바뀌었는지 볼 수 있고, 그 변경이 좋은지 테스트할 수 있고, 아니면 되돌릴 수 있습니다.
그래서 우리는 단도직입적으로 물었습니다. 편집 노하우에 그와 똑같은 속성을 부여하려면 무엇이 필요할까요?
핵심 아이디어: Skill
우리는 그 단위를 Skill이라고 부릅니다. 한 편집자의 노하우를 AI가 함수처럼 호출할 수 있는 형태로 포착한 것입니다. Skill은 트리거(언제 적용되는지), 전제조건, 수행하는 동작, 그리고 올바른 결과를 보여주는 예시를 하나로 묶습니다.
Skill은 두 가지 방식으로 생성됩니다.
- 완성된 작업물에서. 시스템이 완성된 프로젝트 파일을 읽어 편집자가 실제로 사용한 패턴을 추출합니다.
- 녹화에서. 캡처 기능이 플러그인 안에서 작업 흐름을 녹화해 Skill로 변환하거나, 기존 Skill을 갱신합니다.
생성된 Skill은 YouViCo 워크스페이스에 GitHub 방식으로 저장됩니다. 한 사람의 편집 방법이, 나머지 팀이 사용하고 개선하고 키울 수 있는 것이 됩니다.
자동 업데이트를 안전하게 만드는 세 가지 속성
AI가 노하우를 자동으로 덮어쓰도록 그냥 둘 수 없는 이유는 신뢰 때문입니다. 그래서 이 설계는 모든 Skill에 Git과 같은 세 가지 속성을 부여하는 데 기반합니다.
diff 가능성
Skill은 구조—트리거, 전제조건, 동작, 예시—를 가지므로, 제안된 변경이 불투명한 덩어리가 아니라 읽을 수 있는 diff가 됩니다. AI가 무엇을 바꾸려는지 정확히 볼 수 있습니다.
테스트 가능성
변경된 Skill은 머지되기 전에 자신의 레퍼런스 예시를 모두 통과해야 합니다. 이것이 회귀(regression) 게이트입니다. “개선”이 검증된 예시를 깨뜨리면 배포되지 않습니다. CI의 콘텐츠 패리티 검사와 같은 발상을 편집 노하우에 적용한 것입니다.
되돌림 가능성
모든 변경이 커밋이므로, 되돌리기는 한 줄짜리 revert입니다. 자동 머지된 변경이 잘못된 것으로 드러나면, 잘못된 코드 릴리즈를 되돌리듯 그대로 롤백합니다.
이 셋이 합쳐지면 자동 업데이트가 “덮어쓰고 기도하기”에서 “증거를 쌓고 검증하기”로 바뀝니다.
덮어쓰기가 아니라 증거로 업데이트한다
한 번의 관측은 신호일 뿐 사실이 아닙니다. 그래서 업데이트 정책은 의도적으로 보수적입니다.
- 증거 임계치. 새 기법은 기본적으로 variant나 예시로 추가됩니다. 같은 의도가 여러 번 일관되게 관측된 후에야 시스템이 canonical Skill의 변경을 제안합니다.
- 회귀 게이트. 변경된 Skill은 머지하려면 레퍼런스 예시를 통과해야 합니다.
- 2단계 권한. candidate Skill(개인)은 충분한 확신과 함께 CI를 통과하면 자동 머지됩니다. canonical Skill(조직과 공유)은 사람의 리뷰가 필수입니다. 사실상 branch protection입니다.
- 가역성. 모든 변경은 한 줄 revert가 가능한 커밋입니다.
직관적이지 않은 부분: Skill은 항상 머지되지는 않습니다. 때로는 **분화(speciate)**합니다. 두 편집자가 같은 작업을 다르게, 그리고 둘 다 옳게 할 수 있습니다. 억지 머지는 정보를 파괴합니다. 대신 우리는 둘 다 variant로 두고, 오케스트레이터가 맥락—빠른 컷 대 잔잔한 브이로그—에 따라 고르게 합니다. 하나의 Skill이 “맥락 → 구현” 분기의 묶음으로 진화합니다. Git의 코드가 자연스럽게 하지 못하는 일이고, YouViCo만의 강점입니다.
생애주기 루프
종합하면 시스템은 하나의 루프로 돌아갑니다.
- 캡처 — 녹화와 완성된 프로젝트 파일.
- 추출 — AI가 구조화된 Skill 델타를 제안.
- 제안 — 변경이 Skill 풀 리퀘스트로 자동으로 열림.
- 검증 — 예시가 회귀 게이트를 통해 replay됨.
- 머지 — 원클릭, 또는 확신 있는 candidate는 자동 머지.
- 릴리즈 — 버전과 히스토리 기록.
- 관측 — 어떤 Skill이 채택되거나 override되는지에 대한 텔레메트리.
- 다시 캡처로, 새로운 신호가 다음 라운드로 환류됩니다.
비전이 아니라 만들 수 있는 이유
정직한 엔지니어링의 관점은, 가장 어려운 구성 요소가 이미 우리 스택에 존재한다는 것입니다. 풀 리퀘스트를 자동 생성하는 헤드리스 AI가 돌고 있습니다. 머지를 막는 콘텐츠 CI 게이트가 이미 불변식을 강제합니다. 커밋 로그 데이터베이스가 모든 릴리즈를 추적합니다. 구조화된 편집 명령 어휘—razor, ripple, 색 조정, 키프레임, 리프레이밍—이 가동 중입니다.
진짜로 새로운 리스크는 두 곳에 응축되며, 우리는 둘 다 솔직하게 봅니다. 추출 품질—암묵적인 작업을 구조화된 Skill로 신뢰성 있게 바꾸는 일—은 인프라가 아니라 머신러닝 문제이고, 도그푸딩으로 측정합니다. 그리고 replay 판정—편집 호스트는 헤드리스로 돌릴 수 없어, action-trace 레벨에서 검증하고 “동등한 결과”가 무엇인지 설계해야 합니다. 자동 머지까지는 기존 자산을 많이 재활용합니다.
지금까지 배운 것
명시성이 게임의 전부입니다. 노하우가 구조를 갖는 순간, Git의 나머지 장치—diff, test, revert—를 그것에 쓸 수 있게 됩니다.
덮어쓰기 전에 덧붙이세요. 새 기법을 기본적으로 variant로 다루고 강한 증거가 있을 때만 canonical로 승격하면, 나쁜 신호가 좋은 Skill을 오염시키는 것을 막을 수 있습니다.
분화해야 할 때 억지로 머지하지 마세요. 같은 작업에 대한 두 가지 옳은 접근은 충돌이 아니라 정보입니다. 둘 다 보존하고 맥락으로 고르세요.
재활용이 백지 출발보다 낫습니다. 이것이 현실적인 이유는 어려운 인프라 대부분이 다른 이유로 이미 만들어져 있었기 때문입니다. 새로운 야심이 기존 레일 위를 달렸습니다.
다음은
가까운 시점의 초점은 추출 품질과 replay 하니스, 즉 두 개의 진짜 미지수입니다. 더 멀리는, 워크스페이스가 팀의 버전 관리된 편집 기술 라이브러리가 되어, 한 편집자의 직관이 조직 전체가 그 위에 쌓아 올릴 수 있는 것이 됩니다.
자주 묻는 질문
매크로나 액션 녹화와 같은 건가요?
아닙니다. 매크로는 고정된 단계를 재생합니다. Skill은 트리거, 전제조건, 예시를 가진 구조화된 노하우로, AI가 맥락에 따라 선택하고 적응하며, 코드처럼 테스트하고 되돌릴 수 있습니다.
자동 업데이트는 AI가 묻지도 않고 내 작업을 바꾼다는 뜻인가요?
아닙니다. 새 기법은 기본적으로 variant로 추가되고, 공유 Skill의 canonical 변경은 사람의 리뷰가 필요하며, 모든 변경은 한 줄 revert입니다. 이 설계는 덮어쓰기가 아니라 증거 누적입니다.
왜 모두의 편집 스타일을 하나의 Skill로 머지하지 않나요?
두 편집자가 서로 다른 방식으로 옳을 수 있기 때문입니다. 억지 머지는 정보를 잃습니다. variant가 오케스트레이터에게 맥락에 맞는 접근을 고르게 해줍니다.
함께 읽기
- Premiere Pro 안에 사는 AI 어시스턴트를 만든 방법 — 이것이 돌아가는 패널
- AI 영상 편집 어시스턴트란? — 비개발자를 위한 개념