카톡봇 너의 능력을 보여줘! 유튜브 요약을 좀 더 상세하게 해봐~

소개

안녕하세요. 17기 카톡봇뉴스레터 스터디장 김현우입니다.

유튜브는 다양한 지식의 보고이죠. 저는 카톡봇을 시작할 때 사이트와 유튜브 요약부터 시작했습니다. 제가 카톡봇을 시작했던 동기였던만큼 유튜브와 사이트 요약은 바쁜 현대인인 저에게 매력적이었습니다.

기존 유튜브 요약봇

그런데 제 유튜브 요약봇이 스크립트를 잘 못 읽어 오기도 했고, 대신에 영상의 메타 데이터만을 바탕으로 요약하는 경우가 많았어요. 그리고 어떤 유튜브 영상은 요약 말고, 전문을 읽고 싶은 니즈가 있었습니다.

그리고 국내 콘텐츠 제작자의 경우 외국에서 제작한 영상을 자료 확보 차원에서 활용하고자 하는 분들도 많다고 느꼈어요.

그래서 유익한 유튜브 영상을 3줄 요약이 아닌 전문과 함께 콘텐츠 제작자들에게 줄만한 인사이트를 정리하여 제공하는 유튜브봇으로 업그레이드 하였습니다.

진행 방법

🔑 유튜브 스크립트 추출 방식 재검토

기존 유튜브봇의 유튜브 추출 방식의 문제점을 찾으려고 했어요.

기존 방식은 바이브 코딩으로 했으니, 제 의도와 상관없이 엄청 화려했어요. 그러나 Youtube가 제 서버의 IP를 차단하고 있다는 것은 서버의 로그를 다시 열어보면서 인지했어요.

기존에도 우회를 위해 Oxylabs의 프록시를 운용중이었는데, 제가 프록시를 yt-dlp에만 적용하고 정작 youtube-transcript-api에는 적용을 안하고 있었던 거에요.

🤔 여기서 잠깐! 유튜브 자막 추출 방식 함께 살펴 봐요

1. youtube-transcript-api 방식

👉 비공식 파이썬 라이브러리로 제작된 툴로 영상 ID → 웹 엔드포인트로 자막 JSON 획득 → 파이썬 데이터로 가공, 필요시 포맷 변환 및 저장

2. yt-dlp 방식

👉 오픈 소스 명령줄 툴로,유튜브 영상의 "메타 정보"를 분석해 자막 파일의 실제 다운로드 URL을 얻고, 네트워크 요청으로 해당 파일을 저장

3. Playwright/Selenium 방식

👉 브라우저 자동화 프레임워크. 이들을 활용하면 실제 브라우저에서 사람이 직접 행동하듯 유튜브 웹사이트를 탐색하고, 자막(스크립트)을 추출

✓ 메타데이터 받을 땐 YouTube Data API v3 방식도 있어요!

👉 Google의 공식 API를 발급받아 정식으로 요청 / 자막 데이터 제공은 안함.

😎 추출방식의 순서 최적화

추출 방식의 신뢰성이 100%인 방식은 없어요. 보통 70~80% 정도인 거 같아요. 그건 유튜브 사에서 봇인 것을 인지하면 차단하기도 하고, 유튜브 자체 업데이트 과정에서 기존에 효과가 있던 명령어가 먹통이 되기 때문이에요.

저는 기존에 yt-dlp 방식 우선으로 했는데, 제가 리팩토링 하는 과정에서 youtube-transcript-api 방식의 성공 확률이 좀 더 높다고 느껴서 추출 방식 중 성공 확률이 높아 보이는 youtube-transcript-api을 1순위로 놓았어요!

🌈 카톡이 말풍선 하나에서 소화할 수 있는 스크립트 크기

카톡에서 글이 길어지면 하단에 자세히 보기 화살표와 함께 "전체보기"가 뜨잖아요.

전체보기로 전환되는 기준은 500자에요. 500자가 넘으면 '전체보기'로 전환이 된답니다.

그러면 그 전체보기는 글자가 얼마나 들어가는지 아세요? 최대 65,536자(2의 16승)로 제한되어 있어요.

생각보다 엄청 크지 않나요?🤣

아무래도 영상 전체 스크립트를 가져오다 보면 이 부분을 걱정할 수 있는데, 사실상 65,536자를 넘으려면 영상의 길이가 2시간 정도는 되어야 합니다.

저는 그런 영상은 요약할 일이 별로 없지만, 그래도 65,000자를 넘으면 다른 말풍선으로 결과를 내주도록 했어요.

영상 전체 스크립트를 정리해? 아니면 말아?

또 하나의 고민은 영상 스크립트를 그냥 그대로 가져오면 사실 그냥 긴 줄 글이에요. 이건 어디서 어떤 의미로 단락이 바뀌는지조차 알 수 없다구요.

그래서 재미있게 읽기 위해서는 간단한 소제목과 편집이 필요해요. 결국 LLM의 도움을 받게 되는데, 긴 입력과 출력은 많은 토큰을 소모하게 됩니다.

Gemini Flash-Lite 문자수·토큰·비용 계산

1. 입력/출력 글자수별 토큰 및 비용

아래 표는 입력/출력 글자수가 같을 때 Gemini Flash-Lite에서 각각의 입력·출력에 대해 나가는 토큰 수와 예산 비용(USD, 미국달러)을 산정한 것이에요.
(기준: 1토큰=4자, 입력 100만 토큰당 $0.10, 출력 100만 토큰당 $0.40).

문자수 (자)

토큰 수

입력비용($)

출력비용($)

10,000

2,500

0.00025

0.001

20,000

5,000

0.0005

0.002

30,000

7,500

0.00075

0.003

40,000

10,000

0.001

0.004

50,000

12,500

0.00125

0.005

60,000

15,000

0.0015

0.006

2. 유튜브 영상 길이별 대략적인 스크립트 글자수

일반적으로 “1분 ≈ 150단어(평균)”로 계산하며, 한글 기준 단어당 약 5자,
즉 ‘1분 ≈ 750자’로 추정합니다. 주요 영상 길이별로 예상 스크립트 자수는 다음과 같아요!

영상 길이

예상 단어수

예상 문자수

토큰수

입력+출력비용 (USD)

30분

4,500

22,500

5,625

0.0005625 + 0.00225 = 0.00281

1시간

9,000

45,000

11,250

0.001125 + 0.0045 = 0.00563

1.5시간

13,500

67,500

16,875

0.0016875 + 0.00675 = 0.00844

2시간

18,000

90,000

22,500

0.00225 + 0.009 = 0.01125

아무튼 비용은 나중에 걱정해도 되겠다 싶어서, 우선 저는 5만자 이하는 정리를 하도록, 5만자 이상은 LLM 자체에 넣지 않고 원문을 반환하도록 분기를 시켰어요!ㅋㅋ

👍 API 응답 형식을 확인하고 코딩하라구~!

가끔 코딩을 하다보면 이미 힌트를 다 주었는데 혼자 추정하는 경우가 있어요. 이번에 리팩토링할 때도 youtube/full_transcript 라는 엔드포인트를 새로 만들었는데요.

클로드가 자바스크립트 수정하면서 서버 응답 구조를 확인 안하고, 코딩했다가 저에게 혼나고 다시 했어요!

서버 응답 구조
success: 성공 여부
full_transcript: 전체 텍스트 (주로 사용)
message_parts: 서버에서 분할한 메시지 배열 (있으면 우선 사용)
is_split: 분할 여부
processing_method: 처리 방식 (raw/llm)

아무래도 앞에서 말한대로 5만자 이상에 대비한 분할 메시지인 경우 배열로 보내야 해서 분할 여부와 함께 담는 그릇을 구분하였는데, 이렇게 고려요소가 늘어나면 응답구조가 복잡해 지는 게 싫은 1인입니다.

세상 사는 것도 이것저것 고려할 땐 고려해도 때론 고려하지 말고 단순하게 사는게 장땡~!! 😂