gisto 로고 영상을 선물로 받으세요
다른 개인 프로젝트를 진행하다가 문득 YouTube 요약 서비스에 대해서 생각하게 되었습니다. 바이브코딩을 시작하면서 첫 번째로 진행하고 접었던 프로젝트(ShortV)가 유튜브 영상 분석 서비스였는데, 당시 공식 라이브러리나 API가 없어서 정상 서비스가 불가능하다고 판단해서 접었습니다. “지금은 지원하지 않을까?” 라는 생각이 문득 들어 리서치를 해봤습니다.
1. 다시 시작된 계기
하던 작업이 대략 마감되면서 머리도 식힐 겸 리서치를 시작했습니다. 몇 개월 전과 다르게 바로 결과를 알 수 있었습니다. Gemini API(V1beta)가 유튜브 분석을 제공한다고 합니다. 6개월 전에는 1시간 동안 리서치 해서 얻은 결과가 “결론적으로 불가능합니다” 였는데 한 번에 된다고 하니 묘한 기분 이었습니다. 그래도 yt-dlp 없이 가능하니 정말 좋은세상 입니다.
바로 Google AI Studio에 접속해서 간단한 테스트를 해보니 결과가 꽤 괜찮았습니다.
혹시나 독립배포 하면 Gemini API가 거부할 수도 있다는 불신감에 100% 확신은 하 지 않았습니다. (세상엔 예상밖의 상황이 많으니까요)
빠르게 작업을 진행해보기 전에 개발과 관계없는 두 가지 큰 이슈를 먼저 검증해야 했습니다.
2. 검증해야 할 두 가지 이슈
+ 이슈 1: 상품화 가능성
YouTube는 기본적으로 영상을 대체하는 목적의 서비스를 불허한다는 스탠스를 가지고 있습니다. 하지만 좀 더 리서치해보니 생각보다 크게 관여하지는 않는다는 점, 타임스탬프 처럼 영상을 보조하는 관점으로 접근해서 사용자가 영상에 직접 접근할 수 있게 하면 어느 정도 우회가 가능하다는 피드백을 얻었습니다. 생각해보니 다른 YouTube 요약 서비스들도 멀쩡히 돈 받고 서비스하고 있다는 점을 상기했습니다.
따라서 단순 영상 요약이 아닌 타임스탬프 제공을 통해 사용자가 원하는 지점에 바로 영상 플레이가 되도록 기획을 수정했습니다.
타겟 사용자는 이전과 동일하게:
YouTube 사이트에서 원하지 않는 영상을 보는 것이 싫거나
정보성 영상을 주로 소비하는 사용자
+ 이슈 2: 비용 문제
AI Studio에서 “gemini-2.5-flash”로 테스트했는데 막상 비용을 고려하니 만만치 않았습니다. 그래도 운영비를 충당할 수 있는지 검증해보기로 했습니다.
기준은 Google AdSense. Gemini에게 보수적인 광고 예상 수익을 기준으로 gemini-2.5-flash의 토큰사용량의 발생비용을 계산을 요청했습니다. 결과적으로 아주 높은 확률로 적자가 예상된다는 피드백을 받았습니다. 영상 하나 정리해주는 데 발생하는 비용(API, 서버 등 운영비) 대비 광고 조회 수익은 너무나도 빈약했습니다…
광고 수익 모델을 고려하면 영상 분석 외에 사용자가 조회하고 머무를 수 있는 페이지를 통해 부족한 광고 수익을 올려야 하는 문제가 발생했습니다. “자선 프로젝트로 가야 하나?” 라는 생각을 뒤로 하고 좀 더 검증을 진행했습니다.
3. 추가 테스트와 발견
+ 더 나은 모델 찾기
우선 비용절감과 산출물 퀄리티 비교를 위해 LLM 모델을 낮춰봤습니다. 다른 모델들을 테스트해보니 “gemini-2.5-flash-lite” 모델로도 결과물이 나쁘지 않았고, “gemini-2.0-flash”도 비슷했습니다. “gemini-2.0-flash-lite”는 뭔가 아쉬운 결과. 그래도 “2.0-flash-lite”만 사용하던 나에게 토큰 비용 압박이 발생하긴 했지만 말이다. 비용은 동일하니 “gemini-2.5-flash-lite”를 기준점으로 결정했습니다.
+ 기술적 가능성
기존과 다르게 Gemini에게 영상을 통으로 전달해서 분석을 수행하니 Gemini가 영상에 대한 모든 정보를 분석할 수 있는 것 같습니다. 차후에 다양한 분석을 제공하면 유료화 플랜을 제공할 수 있다고 판단하고 긍정적인 마인드로 자체세뇌 후 작업을 시작했습니다.
4. 개발 환경 구축
+ AI 코딩 도구 선택
Google AI Studio의 코드를 GitHub에 동기화한 후 Antigravity로 개발 환경을 이동했습니다.
Antigravity는 출시된 지 얼마 안 되어서 불안하지만 Gemini 3.0, Claude Sonnet 4.5를 무료로 사용할 수 있다는 엄청난 경제적 이점이 있어서 선택했습니다. 그래도 완전 무제한은 아니라 막히면 Zed로 가서 개발을 이어서 진행했습니다. Zed는 기본 Gemini CLI로 계정을 연동해서 사용 중(Gemini는 유료 사용중)이라 백업개발환경으로 적절합니다.
출시하자마자 털린 Antigravity.. (신중한 선택이 필요합니다.)
+ 배포 환경
기본적으로 서버리스 구성을 생각해서 바로 Vercel에 배포해서 개발 환경 설정을 마무리했습니다.
5. 본격 개발 시작
+ 간단한 구조
새로운 기획을 하기보다 기존 ShortV의 구조를 참고해서 Home, Channel 2개 페이지로 구성하고, Google Login 시에만 채널을 관리할 수 있도록 간단한 구조로 개발했습다.
+ 데이터베이스 설정
DB는 Supabase Hobby Plan을 사용해서(최대 2개) 프로젝트를 생성했습니다. 테이블 구조는 Gemini와 논의해서 스키마를 생성한 후, Antigravity에 Gemini와의 대화 결과를 제공해서 최종 스키마를 생성하고, Supabase SQL Editor로 테이블을 생성했다. RLS 설정은 Antigravity의 제안으로 바로 수정 완료했다.
Antigravity 안에서 질의응답을 해도 되지만 토큰도 아끼고 동시진행을 위해 기능에 대한 토론은 gemini를 통해 대부분 진행했습니다. 이후 대화결과를 Antigravity에 제시해서 계획을 세운 후 개발을 진행하도록 했습니다.
+ 최신 모델의 장점
Gemini 3.0, Claude Sonnet 4.5의 장점은 이전 모델보다 자잘한 실수가 거의 없다는 점입니다. 이 부분이 개발 노가다 시 매우 중요한데, 실제로 이전 개발보다 시간이 50% 이상 줄었습니다. 그러다 보니 오랜 시간 작업 시 발생하던 무한 수정, 헛소리 등을 체험하기 전에 하루의 작업을 완료할 수 있었습니다.
Gemini API, Google Login 설정, YouTube API 등 다양한 키 설정을 마무리하고 기본 서비스 구성을 완료하는데 하루면 충분했습니다.
최신 모델을 사용하니 서비스를 개발할 때 하드 코어한 기술력이 필요하거나, 완전 새로운 로직을 구현하지 않는 이상 대부분의 핵심 기능을 쉽게 구현할 수 있다고 생각되었습니다. 지금도 진행형이지만 앞으로 더 돈을 사용하는 사람이 시간과 완성도를 획득할 수 있는 구조가 될 것이라고 예상됩니다.
6. 핵심 기능 구현과 문제 해결
이제 기능 최적화와 세부 이슈를 수정하는 단계입니다. 역시나 몇 가지 큰 이슈를 발견했고 수정을 진행했습니다. 천천히 작업해서 대략 2~3일이 소요되었습니다.
+ 문제 1: 긴 영상 분석 실패
20~30분 정도 길이의 영상까지는 큰 문제가 없었는데 긴 영상에서 문제가 발생했다. 40분 정도가 넘어가면 뒷부분에 산출물 퀄리티가 떨어지는 현상이 나타났는데, 요약이 이상하다던가 아예 실패하는 경우가 많았다. Gemini와 여러 추론을 해보니 그냥 큰 콘텍스트에 대한 실패로 결론 지었다.
“ 최대 100만 토큰을 지원하지만 다 넣는다고 정상이라고는 안했다… “
+ 해결: Context Caching
기술적 대안이 필요했는데 Antigravity의 Gemini가 콘텍스트 캐싱을 제안해줬습니다. 바로 리서치 시작.
Context Caching을 리서치해보니 “gemini-2.5” 이상에서 암시적으로 기본 제공된다는 것을 알게 되었다. 명시적 캐싱은 추가 개발이 필요하고 일을 만들기 싫어서 암시적 캐싱을 믿어보기로 했다.
암시적 캐싱 (Implicit Caching): Gemini 2.5 모델 이상에서 기본적으로 제공됩니다.
명시적 캐싱 (Explicit Caching): 개발자가 수동으로 설정하며 비용 절감을 보장합니다.
이를 위해 영상을 10분 단위로 분리해서 처리하도록 수정. 60분 영상을 분할해서 처리하면 동일한 영상 정보를 6번 input 해야되고 중복 비용이 발생하기 때문에 콘텍스트 캐싱이 암시적으로 input을 1회로 처리하고 6번의 output으로 처리해 줍니다. 하지만 비용은 발생합니다…
+ 문제 2: 서버의 필요성
대략 진행된 코드를 Vercel로 배포하고 테스트를 진행하니 사용성 문제를 파악했습니다.
하나의 영상을 분석하는 도중에 화면 이동을 할 수 없으니 대기 시간이 너무 길게 느껴진다는 점는데, 영상분석 자체가 기술적으로는 예전에 비해 매우 빨라졌지만 서비스 관점에서는 용납하기 힘든 시간입니다. 따라서 분석을 요청하면 백엔드에서 별도로 분석을 수행하고 완료되면 알림을 주는 구조로 변경해야 했습니다.
+ 해결: 백엔드 서버 구축
백엔드 개발 경험이 전무했지만 Antigravity에게 요청하니 한 번에 해결해줬습니다. 별도 서버를 돌리고 영상 분석 작업만 해결해주는 구조로 수정했습니다.
“이제 사용자에게 페이지 이동의 자유가 생겼다! ”
다시 Vercel에 배포해서 영상 분석을 요청하니... 시작도 안 했습니다. 당연하게도 Vercel은 서버리스 환경인데 dev에서 서버구조로 변경 후에 배포하니 문제가 생긴것입니다.
‘이렇게 멍청할 수가.. ’
Gemini가 현재와 같은 서버 운영 방안, 서버리스 환경으로 해결하는 방안 2가지 제안을 해줬지만 서버를 돌리는 게 제정신이면 맞다고 생각되어 서버 운영 플랫폼을 검색했습니다.
몇 가지 후보가 있었지만 Render로 결정하고 설정을 시작했습니다. 첫 서버 플랫폼 설정이지만 AI의 인도에 따라 진행하면 금방 완료됩니다.
다양한 가격 유형을 보여주는 표
문제는 또 다른 운영비가 발생한다는 점이지만 무료 플랜이 있으니 시작은 할 수 있었다. 무료 플랜의 유일한 문제는 요청이 일정 시간 없으면 슬립 모드로 전환돼서 깨워줘야 한다는 점이었다. (아오..)
"결국 나중에 영상 분석 요청 시 서버 깨우기 로직을 추가했다."
다시 느끼지만 돈만 쓰면 정말 편하고 빠르게 서비스를 구축할 수 있는 세상이다.
+ 문제 3: 서버와 프론트 사이의 상태 동기화
앞선 이슈들의 연장선으로 영상 분석 완료 후 프론트에서 완료된 것을 확인할 수가 없어 리프레시를 10번 정도는 하게 되는 나를 보았다. 역시 UX 문제였다.
“사용자에게 페이지 이동의 자유를 주었으니 알림을 줘야 알지..”
영상 분석을 요청한 후 완료, 실패 시 상태 알림을 전달해서 실시간으로 프론트 정보가 갱신되도록 수정해야 했습니다.
+ 해결: Supabase Polling
상태 정보를 표시하는 배지를 추가하고 상태값을 출력했다. 이 상태값이 서버 작업 상태에 따라 실시간으로 갱신되기 위해 Supabase Polling을 사용했다. 사실 진행 상태를 DB의 값을 기준으로 표시하기 때문이다.
일련의 비디오가 검은 화면에 표시됩니다
polling 확인이 제대로 안되거나 다른 메뉴페이지에서 추적이 안되는 등 우여곡절이 있었지만 각 사용자별 polling 구현을 완료하고 토스트로 알림도 출력되도록 개선했다.
로고가 있는 검은색 화면
7. 마무리 작업과 현재
이후 UI 스타일 수정(Jules 참조), 모바일 뷰 대응, 도메인 연결, SEO 설정 등 오픈 테스트를 위한 작업을 진행했습니다.
+ 해결해야 할 문제들
여러 명이 영상 분석을 요청할 때 테스트가 부족하지만 3~5개 동시 처리는 큰 문제 없을 듯하다. (자체적으로 3개 웹브라우저에서 동시요청 했을 때 정상동작 했지만 불안한건 사실)
종종 Render가 슬립 모드일 때 요청 시작 시 실패가 발생하거나 내용과 관계없는 분석을 하기도 한다. 이 부분은 유료 플랜을 결제하던가 슬립에서 깨어날 때를 체크해서 로직을 개선하도록 해야할 거 같습니다. 1시간이 넘는 영상도 아직 분석을 제공하지 않습니다.(최대 콘텍스트 크기를 넘어감;)
+ 결과물 공유
현재까지 결과물은 아래 링크에서 사용해보실 수 있습니다. 영상분석 시간은 영상길이 10분 기준으로 대략 40~60초가 필요한데 AI상태에 따라 차이가 발생합니다. (30분이면 대략 3분)
사용자 반응을 보면서 가능성이 있다면 영상분석 방향으로 고도화 해볼까 합니다. 다양한 언어도 지원해보고 싶구요.
