API 호출 한 번으로 영상 검색 파이프라인 전체를 대체할 수 있게 됐다—실제 비용은 얼마일까

석 달 전, 저는 한 미디어 기업의 영상 검색 인프라 감사를 도운 적이 있습니다. 기술 스택은 이렇게 구성되어 있었습니다. 프레임 추출에 FFmpeg, 음성 전사에 Whisper, 텍스트 벡터화에 임베딩 모델, 검색에 벡터 데이터베이스, 그리고 이 모든 것을 하나로 엮는 커스텀 오케스트레이션 레이어. 서비스가 일곱 개. 컴퓨팅 프로파일이 네 가지. 월 비용은 약 800시간 분량의 인덱싱된 영상 기준으로 12,000달러를 훌쩍 넘었습니다.

지난주, 한 개발자가 Hacker News에 단일 API 호출 — Gemini의 새로운 네이티브 영상 임베딩 — 만으로 구현한 1초 미만의 영상 검색을 올렸습니다. 프레임 추출 없음. 전사 단계 없음. 중간 텍스트 표현 자체가 없습니다. 이 게시물은 프론트 페이지에 올랐고, 무언가가 진정으로 판도를 바꿀 때만 일어나는 류의 토론을 촉발했습니다.

지난 2년간 다섯여섯 개의 개별 도구를 조심스럽게 조립해 구축해온 멀티모달 검색 스택이 코드 한 줄로 무너져 내린 것입니다.

Google이 조용히 출시한 것 — 그리고 왜 이것이 차원이 다른 이야기인지

Google은 별다른 홍보 없이 Gemini API에 네이티브 영상 임베딩 기능을 추가했습니다. 문서에 따르면, 이제 영상을 임베딩 엔드포인트에 직접 전달하면 전체 클립의 벡터 표현을 돌려받을 수 있습니다. 전사본이 아닙니다. 추출된 키프레임도 아닙니다. 오디오와 비주얼이 함께 담긴 실제 영상 콘텐츠가 하나의 임베딩 벡터로 인코딩되는 것입니다.

이것은 우리가 기존에 해오던 방식과 근본적으로 다릅니다. 기존 접근법은 영상을 다른 모달리티들의 컨테이너로 취급했습니다. 컨테이너를 열고, 오디오를 꺼내고, 대표 프레임을 꺼내고, 모든 것을 텍스트로 변환한 다음, 그 텍스트를 임베딩하는 식이었죠. 매 단계마다 지연 시간, 비용, 정보 손실이 발생했습니다. 제가 AWS에서 일하던 팀에서 돌던 농담이 있었는데, 요리 영상을 전체 파이프라인에 돌리고 나면 지글거리는 소리는 사라지고 레시피만 남는다는 거였습니다.

Gemini의 접근법은 이 모든 과정을 건너뜁니다. 영상이 들어가면 벡터가 나옵니다.

API 호출 한 번이 서비스 다섯 개를 대체하다

Hacker News의 Show HN 섹션에 올라온 이 개발자의 데모는 영상 컬렉션을 인덱싱하고 이를 대상으로 시맨틱 검색을 수행합니다. 자연어 쿼리를 입력하면 관련 영상 구간이 반환됩니다. 보고된 검색 지연 시간은 1초 미만이었습니다. 참고로, 앞서 설명한 전통적인 파이프라인은 인덱싱 오버헤드를 제외하고 검색만으로도 보통 3~8초가 걸립니다.

커뮤니티의 주목을 끈 것은 단순히 속도만이 아니라 단순함이었습니다. 전체 검색 시스템은 이것으로 요약됩니다. 인덱싱 시 각 영상에 대해 Gemini 임베딩 API를 호출하고, 벡터를 저장한 다음, 쿼리 시 검색 텍스트를 임베딩하고 최근접 이웃 탐색을 실행합니다. 그게 전부입니다. Whisper 없음. FFmpeg 없음. 프레임 샘플링 휴리스틱 없음. 2초마다 샘플링할지 5초마다 할지 고민할 필요 없음.

Hacker News 스레드는 이 데모가 선택사항으로 만들어버린 바로 그 다단계 파이프라인을 구축하는 데 몇 달을 보낸 엔지니어들의 댓글로 가득 찼습니다. 한 댓글 작성자는 이를 "지난 세 번의 스프린트가 배포되기도 전에 기술 부채가 되어버렸음을 깨달은 순간"이라고 표현했습니다.

비용 계산: 월 1,300달러에서 500달러로

여기서부터 흥미로워지는데, 비용 차이가 적지 않기 때문입니다.

현실적인 시나리오를 가정해 봅시다. 월 1,000시간 분량의 영상 콘텐츠를 인덱싱하는 경우입니다. 중간 규모의 미디어 라이브러리, 기업 교육 카탈로그, 또는 영상 감시 아카이브 정도의 규모입니다.

전통적인 파이프라인

프레임 추출 (EC2/GCE 위의 FFmpeg): 효율적인 처리를 위해 GPU 인스턴스가 필요합니다. AWS의 g5.xlarge는 시간당 약 $1.006입니다. 대략 실시간의 2배 속도로 처리한다고 가정하면 500 컴퓨팅 시간이 필요합니다. 비용: 월 ~$503.

전사 (Whisper API 또는 자체 호스팅): OpenAI의 Whisper API는 분당 $0.006을 청구합니다. 1,000시간 = 60,000분. 비용: 월 $360. 자체 호스팅은 대규모에서 더 저렴하지만 운영 오버헤드가 추가됩니다.

텍스트 임베딩: OpenAI의 text-embedding-3-large 기준으로 백만 토큰당 약 $0.13입니다. 1,000시간 분량의 전사된 오디오는 상당한 양의 토큰을 생성합니다. 대략 콘텐츠 밀도에 따라 월 $80~$150 수준입니다.

벡터 데이터베이스: Pinecone 스탠다드 티어 또는 동급 서비스. 이 볼륨 기준으로 월 $70~$200 범위를 예상하세요.

오케스트레이션 및 글루 코드: Lambda 함수, SQS 큐, 에러 핸들링, 재시도 로직. 컴퓨팅 비용만 월 $50~$100 정도이고, 이 모든 것을 유지보수하는 엔지니어링 시간은 별도입니다.

합계: 인프라 비용만 월 약 $1,100~$1,300. 파이프라인을 구축하고 유지보수하고 디버깅하는 엔지니어링 시간은 포함하지 않은 수치입니다. 이런 시스템을 감사한 제 경험상, 인건비는 인프라 비용의 2~3배에 달합니다.

Gemini 네이티브 임베딩 접근법

Google의 Gemini API 임베딩 가격은 텍스트 임베딩 모델과 비교해 경쟁력이 있습니다. Google이 영상 임베딩에 대한 최종 분당 가격을 아직 공식 발표하지는 않았지만, 현재 요금표와 HN 스레드에서 개발자들이 보고한 내용을 종합하면 처리 비용은 분당 대략 $0.002~$0.005 범위에 해당합니다.

1,000시간 기준: 60,000분 × $0.005/분 (높은 추정치 적용) = 월 $300.

벡터 데이터베이스 추가: 월 $70~$200.

합계: 월 약 $370~$500. 영상당 API 호출 한 번. 오케스트레이션 레이어 없음. 프레임 추출 컴퓨팅 없음. 전사 서비스 없음.

인프라 비용이 60~70% 절감되는 셈입니다. 엔지니어링 시간 절감까지 감안하면 — 파이프라인 유지보수 제로, 배경 음악이 있는 영상에서 Whisper가 타임스탬프를 환각하는 이유를 디버깅할 필요 없음 — 실질적인 절감 효과는 훨씬 더 커집니다.

포기해야 하는 것들

트레이드오프를 다루지 않으면 불성실한 글이 될 것입니다. 트레이드오프는 분명히 존재합니다.

투명성. 전통적인 파이프라인은 중간 산출물을 제공합니다. 전사본이 있고, 키프레임이 있습니다. 각 단계를 독립적으로 검사하고, 디버깅하고, 재사용할 수 있습니다. 단일 API 접근법은 블랙박스입니다. 영상이 들어가고, 벡터가 나오며, 모델이 중요한 것을 잘 포착했으리라 믿어야 합니다.

벤더 종속. 현재 이것은 Google만의 기능입니다. Gemini 영상 임베딩으로 검색 시스템을 구축하면 한 곳에 묶이게 됩니다. OpenAI, Anthropic, 또는 오픈소스 생태계에는 아직 동등한 기능이 없습니다. 저는 ML 파이프라인에서 단일 벤더 의존성이 어떻게 비용 리스크를 복합적으로 증가시키는지에 대해 많은 글을 써왔습니다. Google의 가격 정책은 오늘 우호적입니다. 하지만 항상 그렇지는 않을 것입니다.

세분화 제어. 전통적인 파이프라인에서는 영상을 어떻게 분할할지 직접 결정할 수 있습니다. 30초 단위? 장면 경계? 챕터 마커? 네이티브 영상 임베딩에서는 모델이 그 결정을 내립니다. 법률 문서 발견(legal discovery)이나 의료 영상 리뷰 같은 유스 케이스에서는 이러한 제어 부재가 결정적인 단점입니다.

엣지 케이스 품질. HN 데모는 일반적인 영상 검색에서 훌륭해 보였습니다. 하지만 시각적 콘텐츠가 거의 없는 영상 — 팟캐스트 녹화본 — 은 어떨까요? 또는 핵심 정보가 화면 위의 텍스트에 있는 영상 — 코딩 튜토리얼 — 은요? 전통적인 파이프라인은 각 단계를 튜닝할 수 있습니다. 네이티브 접근법은 모델이 모든 모달리티를 동등하게 잘 처리한다고 믿어야 합니다.

더 큰 패턴: 파이프라인을 삼키는 파운데이션 모델

여기서 더 큰 이야기는 영상에 관한 것이 아닙니다. 파운데이션 모델이 전체 처리 파이프라인을 흡수할 때 어떤 일이 벌어지는가에 관한 것입니다.

2년 전, RAG 시스템을 구축하려면 청킹 전략을 선택하고, 임베딩 모델을 고르고, 벡터 데이터베이스를 정하고, 검색 로직을 작성하고, 리랭킹을 구현해야 했습니다. 오늘날, 주요 모델 제공업체들은 이러한 단계들을 하나로 합치고 있습니다. Gemini의 영상 임베딩은 같은 패턴이 멀티모달 콘텐츠에 적용된 것입니다.

우리는 이런 것을 클라우드 인프라에서 이미 목격한 적 있습니다. 로드 밸런싱, SSL 종료, DDoS 방어, CDN에 각각 별도의 서비스가 필요하던 시절을 기억하시나요? 그러다 Cloudflare와 AWS CloudFront가 이 모든 것을 단일 제품으로 흡수했습니다. 전문 서비스가 하루아침에 사라진 것은 아니지만, 기본 아키텍처가 바뀌었습니다. "충분히 괜찮은" 수준의 기준선이 극적으로 올라간 것입니다.

멀티모달 검색에서 지금 일어나고 있는 일이 바로 그것입니다. 커스텀 파이프라인이 죽은 것은 아닙니다 — 규칙이 아닌 예외가 되어가고 있을 뿐입니다. 영상 처리에 대해 외과적 수준의 제어가 필요하다면 여전히 다단계 시스템을 구축할 것입니다. 하지만 "예산 초과에 대해 이야기하는 클립을 찾아줘"가 요구사항인 80%의 유스 케이스에서는 API 호출 한 번이면 충분합니다.

"상황에 따라 다릅니다"가 아닌 의사결정 프레임워크

"상황에 따라 다릅니다"라고만 말하고 판단 기준은 주지 않는 일은 하지 않겠다고 약속드렸습니다. 제 프레임워크는 이렇습니다.

Gemini 네이티브 영상 임베딩을 사용하세요: 유스 케이스가 일반적인 영상 검색이나 추천인 경우, 월 10,000시간 미만을 처리하는 경우, 전사본이나 키프레임 같은 중간 산출물이 다른 용도로 필요하지 않은 경우, 그리고 벤더 종속을 감수할 수 있는 경우.

다단계 파이프라인을 유지하세요: 전사본이 독립적인 결과물로 필요한 경우 — 자막, 컴플라이언스 기록 — 또는 청킹과 검색 세분화에 대한 정밀한 제어가 필요한 경우, 모든 처리 단계가 설명 가능해야 하는 규제 산업에 있는 경우, 또는 개별 구성 요소에 대한 협상된 엔터프라이즈 가격이 API 가격보다 유리한 규모인 경우.

하이브리드 접근법을 고려하세요: 전사본과 영상 검색 모두 필요한 경우. 전사본은 Whisper로 처리하고 — 어차피 필요하니까 — 비주얼 및 멀티모달 검색 레이어에는 Gemini 임베딩을 사용합니다. 이렇게 하면 다른 시스템이 의존하는 텍스트 산출물을 유지하면서 최고의 검색 품질을 얻을 수 있습니다.

앞으로 벌어질 일

OpenAI와 오픈소스 커뮤니티가 가만히 있지는 않을 것입니다. 저는 6개월 이내에, 아마 더 빨리 OpenAI에서 네이티브 영상 임베딩이 나올 것으로 예상합니다. Meta도 멀티모달 모델에 대한 투자를 고려하면 오픈소스 동등 기능을 개발하고 있을 가능성이 높습니다. 그때가 오면 벤더 종속 우려는 사라지고 Google에 대한 가격 압박은 심해질 것입니다.

지금 당장, 새로운 영상 검색 시스템을 구축하고 있거나 — 유지보수 부담이 되어버린 시스템을 운영하고 있다면 — 이것은 진지한 개념 증명을 해볼 가치가 있습니다. 영상 라이브러리에서 대표 샘플을 추출하고, Gemini 임베딩 API에 돌려보고, 기존 파이프라인과 검색 품질을 비교해 보세요. 품질이 유지된다면, 비용 계산을 해보세요.

제가 지금까지 본 수치로 판단하건대, 대부분의 팀에게 이것은 고민할 여지가 없는 선택입니다. 60% 비용 절감, 파이프라인 유지보수 제로, 1초 미만의 지연 시간. 다단계 영상 검색 파이프라인은 우리에게 잘 봉사해 왔습니다. 하지만 많은 팀에게 있어, 그 시대는 끝나가고 있습니다.