단 하나의 영상도 남기지 않고 저장된 영상을 처리하는 방법

DRIP을 만든 과정 — 미디어 라이브러리를 남기지 않으면서, 수년간 저장해온 북마크, 영상, 게시물들을 활용 가능한 문서로 변환해주는 로컬 우선 (local-first) 도구입니다.

저는 대부분의 사람들이 겪고 있지만 이름 붙이지 못한 문제를 가지고 있었습니다. 저는 강박적으로 저장하는 습관이 있습니다. YouTube의 "나중에 볼 동영상" 목록은 수백 개에 달합니다. 브라우저 북마크는 수년 전으로 거슬러 올라갑니다. 대여섯 개의 플랫폼에 걸쳐 저장된 게시물들도 있습니다. 이 모든 것들은 언젠가 다시 돌아와 보겠다는 조용한 약속과 함께 보관되었습니다.

하지만 저는 결코 다시 돌아오지 않았습니다. 거의 아무도 돌아오지 않죠. 저장은 읽기를 위한 전 단계가 아니라, 읽기를 대신하는 대체물이 되어버렸습니다.

그래서 저는 이 모든 것들을 실제로 활용할 수 있는 도구를 만들었습니다. 이 글은 제가 예상했던 것보다 더 중요하게 작용했던 결정들에 대한 기록입니다.

첫 번째 결정: 영상을 보관하지 않는다

저장된 영상을 처리하는 가장 뻔한 방법은 영상을 다운로드하여 무언가를 실행하는 것입니다. 이 분야의 대부분의 도구가 작동하는 방식이며, 여기에는 사람들이 과소평가하는 두 가지 비용이 따릅니다. 바로 저장 공간(수백 개의 저장된 영상을 다운로드하는 것은 결코 보지 않을 기가바이트 단위의 용량을 차지함)과 서비스 약관 (Terms-of-Service) 노출(전체 영상 파일을 가져오는 것은 대부분의 플랫폼 규칙에 위배됨)입니다.

저는 둘 다 원하지 않았습니다. 그리고 저는 영상이 전혀 필요하지 않다는 사실을 깨달았습니다. 여러분이 저장하는 거의 모든 것에서 가치는 픽셀(pixels)이 아니라 단어(words)에 있기 때문입니다. 튜토리얼, 레시피, 연구 강연 등에서 여러분이 실제로 원하는 것은 전사 데이터 (transcript)와 구조입니다.

그래서 규칙은 다음과 같았습니다: 미디어 라이브러리는 절대 만들지 않는다.

실제로 이는 두 가지 경로로 나뉩니다. 저장된 영상의 대다수는 이미 자막 (caption)이나 자막 트랙 (subtitle track)이 있습니다. DRIP은 이를 직접 읽으며, 어떤 미디어도 여러분의 드라이브에 닿지 않습니다. 자막이 없는 소수의 경우에는 오디오만 임시 파일로 다운로드하여 로컬에서 전사 (transcribe)한 뒤, 전사가 완료되는 즉시 파일을 삭제합니다. 영상은 절대 저장되지 않으며, 아무것도 남지 않습니다.

이것은 타협이 아닙니다. 이것이 올바른 아키텍처 (architecture)입니다. 일반적인 사례를 완전히 깔끔하게 유지하면서, 예외적인 사례를 존재하지 않는 척하는 대신 정직하게 처리하기 때문입니다.

두 번째 결정: 로컬(Local)에 유지하되, 사용자에게 선택권을 부여함

일단 텍스트 문제로 전환되면, 처리가 어디서 일어날지를 결정해야 합니다. 처리 대상이 되는 것은 수년에 걸친 누군가의 관심사가 담긴 매우 개인적인 지도입니다. 그것은 제가 보유하고 싶은 데이터가 아니며, 대부분의 사람들도 업로드하고 싶어 하지 않는 데이터입니다.

따라서 DRIP는 로컬 우선(Local-first) 방식입니다. 기본적으로 Ollama 또는 LM Studio를 통해 로컬 모델(Local model)에서 실행되며, 사용자의 콘텐츠는 기기를 절대 떠나지 않습니다. 하지만 저는 독단적으로 결정하고 싶지 않았습니다. 만약 호스팅된 모델(Hosted model)을 사용하고 싶다면, 본인의 Claude, GPT 또는 Grok 키를 연결하여 실행당 비용을 지불하면 됩니다. 또한 로컬에서 먼저 시도하고 로컬 실행이 실패할 경우에만 클라우드(Cloud)로 전환하는 "자동(Auto)" 모드도 있습니다.

원칙은 다음과 같습니다: 당신의 AI, 당신의 비용, 당신의 결정. 구독도 필요 없고, 시작하기 위해 키(Key)를 요구하지도 않습니다.

세 번째 결정: 항목당 하나의 문서, 유형별 라우팅(Routing)

저장된 콘텐츠는 균질하지 않기 때문에, 일반적인 "이것을 요약해줘" 식의 출력은 거의 쓸모가 없습니다. 레시피와 팟캐스트는 프로세서(Processor)로부터 완전히 다른 결과물을 원하기 때문입니다.

그래서 DRIP는 저장된 각 항목을 분류한 다음, 콘텐츠가 실제로 요구하는 형식에 맞춰 하나의 집중된 문서를 생성합니다:

• 레시피는 번호가 매겨진 조리법과 함께 재료 표(야드파운드법 + 미터법)가 됩니다.
• 운동 루틴은 세트(Sets), 반복 횟수(Reps), 휴식 시간(Rest)이 포함된 운동 표가 됩니다.
• 팟캐스트는 게스트, 호스트, 주요 주제, 인용구 및 핵심 요약(Takeaways)이 됩니다.
• 비즈니스/전략 자료는 실행 항목(Action items)과 출처 표기가 포함된 섹션으로 구성됩니다.
• 기술/학습 항목은 참조 문헌이 포함된 단계별 가이드가 됩니다.

항목당 하나의 PDF를 생성하고 주제별 폴더로 분류합니다. 즉, '운동(Workouts)' 파일은 서로 관련 없는 다섯 가지 내용이 한데 뒤섞인 것이 아니라, 하나의 운동에 관한 내용을 담게 됩니다. 각 PDF에는 일치하는 Markdown 파일이 함께 생성되며, 이는 Obsidian(옵시디언)이나 유사한 도구들에 아무런 마찰 없이 즉시 반영됩니다.

내가 예상치 못하게 구축하게 된 부분: 학습 루프 (learning loop)
분류기(Classifier)는 성능은 좋았지만 일반적이었습니다. 나의 패턴을 알지 못했죠. 그래서 Karpathy(카파시)의 '생성하고, 테스트하고, 효과가 있는 것을 유지한다'는 아이디어에서 느슨하게 영감을 얻어 피드백 루프(feedback loop)를 추가했습니다.

의도적으로 노력을 최소화했습니다: 실행이 끝난 후, 그날의 PDF들을 훑어보며 각 항목을 '유지(keep)'할지 '폐기(trash)'할지 표시하기만 하면 됩니다. 약 30초 정도 소요됩니다. 폐기된 모든 항목은 신호가 됩니다. 시스템은 그 실수로부터 한 줄짜리 규칙을 도출하여 로컬에 저장합니다. 향후 실행 시에는 이러한 학습된 규칙들이 예시로서 분류기에 주입됩니다. 또한 새로운 규칙을 생성하고, 사용자가 이미 검증한 예시들을 대상으로 테스트한 뒤, 승리한 규칙만을 커밋(commit)하는 실험 모드도 있습니다.

가벼운 피드백을 주고받은 몇 주 후, 시스템은 일반적인 프롬프트(prompt)가 했던 것보다 눈에 띄게 더 잘 내 콘텐츠를 분류하게 되었습니다. 왜냐하면 시스템이 실제로 내가 사물을 분류하는 방식을 보았기 때문입니다. 이 모든 학습 데이터는 로컬 폴더에 존재하며, 그 어떤 것도 업로드되지 않습니다.

현재 상태
Python(파이썬)으로 구축되었습니다. macOS, Windows, Linux에서 실행됩니다. YouTube(유튜브), X, Instagram(인스타그램), Facebook(페이스북), TikTok(틱톡), LinkedIn(링크드인), 그리고 브라우저 북마크로부터 데이터를 읽어옵니다. 처리는 기본적으로 로컬(local)에서 이루어지며, 선택에 따라 클라우드(cloud)를 사용할 수도 있습니다. 백그라운드 스케줄러(background scheduler)가 매일 아침 이를 실행하므로, 자고 일어나면 문서들이 준비되어 있습니다.

직접 시도해보고 싶다면 DRIP이라는 이름으로 패키징했습니다: thebvl.gumroad.com/l/rvwbcv — 일회성 결제이며 구독은 없습니다.

하지만 제가 주로 이 글을 쓰고 싶었던 이유는 '자막 우선(captions-first) / 일회용 오디오(throwaway-audio)' 접근 방식을 기록하기 위해서였습니다. 왜냐하면 이것이 제가 가장 만족하는 결정이며, 다른 사람들에게서는 본 적이 없는 방식이기 때문입니다.

무엇이든 질문해 주세요.