2021년 MacBook에서 Gemma4-31B로 1년치 영상을 로컬 색인하기(50GB 스왑)

영상 아카이브의 병목은 편집 도구보다 검색 불가능성이었고, 라벨 없는 클립을 영어로 질의 가능한 인덱스로 바꾸는 데 초점을 맞춤

로컬 우선 설계로 각 클립 옆에 .description.md사이드카 파일을 만들고, rating·조명·위치·전사·키워드·산문 설명을 한 번의 비전 호출에서 추출함

파이프라인은 ffprobe, exiftool, Nominatim, ffmpeg, WhisperX, insightface, 비전 모델을 묶어 메타데이터·GPS·프레임·전사·얼굴 임베딩을 생성함

2021년 16인치 MacBook Pro M1 Max 64GB가 LM Studio에서 Gemma 4 31B Q4를 실행했고, 대량 처리 중 스왑은 최고 50.89GB까지 올라감

구조화 스키마와 enum 제약은 환각을 줄였고, 대량 색인은 로컬 31B로 처리한 뒤 어려운 10~20%만 클라우드 모델로 재평가하는 구성이 가능했음

문제의 출발점: 편집보다 검색

Maasai Mara에서 반년 가까이 머무는 동안 iPhone, DJI Pocket, 드론, Nikon Z8, Ray-Ban Meta로 촬영한 영상이 계속 쌓였지만, 대부분 다시 열어보지 못한 채 남아 있었음

Mara Hilltop의 소셜 채널은 콘텐츠 부족이 아니라 편집 시간 부족 때문에 3개월 동안 멈춰 있었음

Claude Code와 Opus 4.5/4.6으로 개발 작업은 장시간 에이전트 실행과 병렬 작업이 가능해졌고, KaribuKit의 첫 유료 숙소 출시와 겹치면서 영상 편집 시간은 더 줄어듦

처음 떠올린 해법은 Eddie AI, Higgsfield MCP, Submagic, Buffer를 조합한 월 $140 SaaS 스택이었지만, 실제 병목과 맞지 않았음

생성형 AI 영상은 실제 여행 브랜드와 맞지 않았고, 투숙객이 실제 장소를 기대하는 상황에서 잘못 표시된 AI 장면은 신뢰를 해칠 수 있었음

현실적인 게시 빈도는 주 35개가 아니라 주 23개에 가까워, 초기 계획은 두 번째 주부터 실패할 가능성이 컸음

이미 보유한 DaVinci Resolve Studio와 Resolve 21의 IntelliSearch, Smart Bins, Voice to Subtitle은 Eddie가 제공하는 기능의 약 70%를 커버함

남은 구성은 Claude Code가 오픈소스 DaVinci Resolve MCP로 Resolve를 제어하고, 정보성 클립에 한해 ElevenLabs로 보이스오버를 처리하는 구조였으며, 비용은 월 $22로 줄어듦

진짜 병목: AI 편집기보다 먼저 필요한 인덱스

시중 AI 영상 편집기는 영상이 이미 라벨링되어 있다고 가정하지만, 실제 아카이브는 IMG_.mov, DJI_.mp4, Mara june 2024 backup final FINAL 같은 이름으로 흩어져 있었음

Eddie는 전사 검색은 가능하지만, 라벨 없는 아카이브에서 “황금빛 시간대 언덕 위 코끼리” 같은 장면을 찾을 수 없었음

파일명, 부모 폴더, GPS 좌표, 전사 텍스트만으로는 “프레임 안에 기린이 있는 일출 와이드샷” 같은 시각적 내용을 알 수 없음

실제 지렛대는 편집기 위가 아니라 그 앞단에 있었고, 먼저 아카이브를 영어로 질의 가능한 형태로 만드는 인덱스가 필요했음

로컬 우선 인덱서 설계

전체 구조는 SimbaStack에서 클라이언트용으로 만드는 AI 네이티브 빌드와 비슷했지만, 직접 클라이언트이자 엔지니어였기 때문에 의사결정이 빨랐음

네 가지 제약

로컬 우선이어야 했음

Mara Hilltop 아카이브는 물리 SSD에 있고 개인 영상은 노트북에 있었으며, 수천 개의 멀티 GB 클립을 클라우드에 올리는 것은 비용과 프라이버시 양쪽에서 맞지 않았음

중앙 DB보다 사이드카 파일을 원했음

각 클립 옆에 .description.md를 두고 일반 텍스트로 grep 가능하게 만듦

인덱서가 나중에 망가져도 파일은 남고, 드라이브 사이를 이동해도 데이터와 함께 이동함

비전 호출 한 번에 필요한 정보를 모두 뽑아야 했음

추출 프레임에 대한 비전 패스가 비싼 작업이므로, 나중에 알고 싶은 정보까지 첫 호출에서 얻도록 스키마를 처음부터 넓게 잡았음

포함 항목은 rating, technical quality, lighting, time of day, color palette, audio quality, people count, keywords, faces, location, transcript, prose description 등이었음

세 가지 비전 백엔드를 선택할 수 있게 했음

기본값은 Claude Max 구독의 CLI로, 한계 비용이 없었음

속도가 필요할 때는 Anthropic API를 사용함

대량 처리에는 LM Studio를 향한 로컬 백엔드를 사용했고, 이 로컬 백엔드가 핵심이었음

업데이트: 급하게 이 저장소를 만들었음 - https://github.com/Simbastack-hq/framedex
라이선스는 MIT이고, 범용화한 뒤 제대로 테스트하지는 못했음. 곧 제대로 훑어보고 업데이트를 더 추가할 예정임
TODO의 큰 두 가지는, 1) 이 색인과 Claude의 도움을 활용해 DaVinci Resolve에서 영상 편집을 더 빠르게 하는 것, 2) 지금은 영상만 처리했지만 카메라에 있는 수천 장의 정지 이미지도 이해할 수 있게 확장하는 것임

왜 그렇게 많은 스와핑이 필요한지 잘 모르겠음. 필요한 메모리 대역폭을 생각하면 SSD 수명을 꽤 빨리 줄일 수 있음
Gemma 4 31B의 4비트 양자화 모델은 28.4GiB가 아니라 대략 19GiB 정도여야 함 [1]. 이미지를 자주 넣어보진 않아서 문맥에 넣을 때 메모리가 얼마나 더 필요한지는 모르지만, 10GiB를 넘을 것 같지는 않음
활동 모니터를 보면 모델을 로드한 것으로 보이는 Handy와 Claude Code용 가상 머신 위에 여러 Electron 앱도 떠 있어서, 실제 원인은 그쪽 같음. 노트북이 디스크를 심하게 긁기 시작하면 그런 앱들은 멈춰버릴 테니 쓸모가 없을 듯함
[1] https://huggingface.co/mlx-community/gemma-4-31b-it-4bit

맞음. 스크린샷을 찍을 때 노트북으로 다른 작업도 하고 있어서 정리할 수는 있었음
그래도 약간 버벅이긴 했지만, Brave 브라우저에 탭을 많이 열어둔 상태에서도 다른 일을 계속할 수 있었다는 점이 인상적이었음

멋짐. 로컬 모델을 돌릴 만큼 램이 있었으면 좋겠음. 지난 몇 주 동안 아주 비슷한 걸 만들었는데, 나는 Whisper, ffmpeg를 쓰는 로컬 Electron 앱으로 만들고 영상과 대화하기 위한 의미 검색과 임베딩을 추가했음
시각 분석, 태깅, 영상 채팅은 Claude와 통신함. 이 프로젝트는 이미지 하나만 보내는 방식인지 궁금함. 나는 맞춤형 장면 감지 알고리즘으로 영상마다 서로 다른 여러 이미지를 찾고, 자막과 함께 한 번의 요청으로 Claude에 보냄. 확실히 비용이 가장 많이 드는 부분임. 분석에는 Sonnet 4.6, 태깅에는 Haiku를 쓰면 1시간 분량 영상에 약 1달러가 들고, 로컬에서는 느릴 것 같음

이미지 하나가 아니라 클립당 5프레임을 자막 일부와 함께 한 번의 요청으로 보냄. 그래서 여러 프레임과 자막을 한 번에 넣는 부분은 같은 방식임
다만 프레임을 고르는 방식이 약점임. 장면 감지는 확실히 도움이 될 것이고, 로드맵 1순위임. 장면 감지에서 프레임을 어떻게 고르는지 공유해줄 수 있는지 궁금함
벡터 검색은 넣지 않고, 더 이식성 높은 일반 Markdown 파일로 단순하게 유지하는 쪽을 택했음. SSD를 옮겨도 지식이 파일과 함께 이동하고, 동기화할 색인이 없으며, 도구보다 오래 살아남는 일반 텍스트라는 장점이 있음. 다만 네가 말한 다른 방향도 탐색해볼 만함

비용을 줄이고 싶다면 OpenRouter의 모델들을 써보면 좋음. Gemma 4 31B는 입력 100만 토큰당 0.12달러, 출력 100만 토큰당 0.37달러인데, Haiku는 입력 100만 토큰당 1달러, 출력 100만 토큰당 5달러임
괜찮은 다른 선택지도 있음. Gemini 3.1 Flash Lite는 이런 작업에 아주 좋음. 다만 Gemini 3.5 Flash는 아님. 그건 가격이 별로임 https://openrouter.ai/google/gemma-4-31b-it

질문 두 가지가 있음

검색 색인은 무엇인지 궁금함

description.md 예시에 faces -> cluster_id 같은 항목이 있음. 이게 DaVinci Resolve의 얼굴 색인에서 온 것인지 궁금함. 사진 컬렉션에서는 얼굴+이름, 위치 같은 정보가 정말 중요한데, 일반 LLM은 이런 걸 잘 다루지 못함

클립마다 영상 옆에 놓이는 단순한 일반 텍스트 .description.md사이드카 파일일 뿐임
나중에 Claude와 “롯지의 고급 객실 영상을 만들고 싶다”처럼 브레인스토밍할 때 질의할 수 있고, Claude가 파일들을 훑어 어떤 영상이 도움이 될지 알 수 있음
찾기 쉽게 텍스트 설명을 모아둔 폴더 루트 수준의 파일도 있음. 블로그에 예시 이미지를 붙여뒀음 - https://blog.simbastack.com/_media/gvcycx2n.png

DaVinci Resolve에서 가져온 것은 아님. Framedex는 독립 실행형 파이프라인이고 Resolve는 관여하지 않음
얼굴은 insightface에서 옴. 오픈소스 buffalo_l 팩의 RetinaFace로 감지하고, CPU에서 로컬로 실행함. 각 클립의 샘플 프레임에서 얼굴을 감지하고 임베딩한 뒤 ~/.framedex/faces.db에 행을 씀
솔직히 이 부분은 로컬 DB에 쌓이고 있다는 건 알지만, 얼마나 잘 되는지는 아직 제대로 테스트하지 못했음. 곧 제대로 확인해볼 예정임
더 넓게 보면 그래서 framedex는 의도적으로 LLM에 얼굴이나 위치 처리를 맡기지 않음. 얼굴은 insightface / ArcFace 임베딩으로 처리해서 클립 간 비교가 결정적으로 가능함. 시각 모델은 대략적인 사람 수만 제공하고, 누구인지 식별하려 하지 않음
위치는 exiftool을 통한 EXIF GPS와 Nominatim/OpenStreetMap 역지오코딩으로 처리함. 추측이 아니라 단단한 메타데이터임
LLM은 잘하는 일만 함. 장면 설명, 분위기, 샷 유형, 키워드, 보관/검토/폐기 평점 같은 것들임. 마지막 평점 부분은 논쟁의 여지가 있긴 함

2015년식 ThinkPad에서 비슷한 작업을 하려고 Gemma를 돌려봤음. 다행히 메모리를 업그레이드할 수 있었고, 아니었으면 꽤 고통스러웠을 것임
거짓말은 못 하겠는데, llama.cpp를 돌리니 팬이 최대 속도로 돌았음. 그래도 동작했고 작업은 끝냈음

“팬이 최대 속도로 돈다”는 표현이 늘 헷갈림. 계산을 가능한 한 빨리 끝내고 싶다면 결국 더 많은 열이 나고 배출해야 하는 것 아닌가 싶음
가끔은 “자원을 100% 사용한다”는 비유로 쓰는 것 같고, 여기서는 아마 그런 의미겠지만, 다른 맥락에서는 실제 불만으로 말하는 경우도 분명히 있었음

“생성형 AI 영상은 진짜 여행 브랜드에 설 자리가 없다”는 말에는 Airbnb 호스트 대다수가 동의하지 않을 것 같음
“TripAdvisor에서 십자가형”이라는 표현도, 가짜 숙소를 올리는 Airbnb 호스트들이 어떻게 살아남는지 정말 모르겠음

솔직히 나도 이 문제로 고민이 많음. 사파리 롯지를 운영하고 있지만 저품질 AI 영상 쪽으로 가고 싶지는 않음
반면 진짜 영상은 시간이 걸리고 전체 과정을 느리게 만듦

B2C AI 애플리케이션은 개인화된 맥락을 만들기 어렵다는 점 때문에 구조적으로 한계가 있다고 봄
유능한 로컬 모델이 대규모로 바닥부터 맥락 수집, 조사, 태깅 등을 해낼 수 있다면 여기서 큰 돌파구가 될 수 있음

AI 기반 문맥적 파일 이름 변경을 하는 완전 로컬 B2C AI 앱을 만들었고 무료임
스크린샷 여러 장을 넣으면 그 안의 내용을 바탕으로 똑똑하게 이름을 붙이려고 함. 영상, PDF 등도 마찬가지임
다만 네 말처럼, Apple이 그냥 기능으로 넣어버릴 것 같아서 돈을 받으려는 시도조차 하지 않았음 https://finalfinalreallyfinaluntitleddocumentv3.com/

완전히 동의함. 여기서는 나와 Claude가 같이 브레인스토밍하면서 그 조사와 시행착오를 해냈음
하지만 에이전트가 충분히 똑똑해져서 비기술자 친구들도 “이 폴더의 영상들을 이해할 수 있게 정리해줘”라고 말하기만 하면 그대로 해주는 건 시간문제라고 봄

정말 이걸 풀어주는 게 로컬 모델인지 궁금함. 상태를 저장하지 않는 모델 API도 같은 이점을 주지 않나? 로컬이 사용량에 따라 “더 저렴”할 수 있다는 건 알지만, 우리는 오래전부터 클라우드 저장소와 연산 자원을 프리미엄을 주고 빌려 써왔음