SerpApi와 DeepSeek를 사용하여 Dan Koe의 콘텐츠 전략 분석하기

Dan Koe는 항상 적절한 시기에 적절한 말을 하는 것처럼 보이는 크리에이터 중 한 명입니다. 그의 영상은 생산성 (productivity), 목적 (purpose), 자기 교육 (self-education), 그리고 의미 있는 삶을 구축하는 것에 대해 지속적으로 공감을 불러일으킵니다.

어느 시점에 저는 궁금해지기 시작했습니다. 그의 콘텐츠 뒤에는 반복 가능한 패턴이 있을까? 아니면 대부분 직관에 의한 것일까?

더 중요한 것은, 크리에이터의 콘텐츠 전략을 실제로 체계적이고 재현 가능한 무언가로 분해할 수 있는가 하는 점입니다.

그래서 저는 작은 실험을 진행했습니다.

Repository: https://github.com/magentaqin/creator-lens

SerpApi를 사용하여 Dan Koe의 YouTube 채널(상위 100개 영상)에서 메타데이터 (metadata), 영상 상세 정보, 그리고 스크립트 (transcripts)를 수집했습니다. 그 다음 DeepSeek를 사용하여 콘텐츠 뒤에 숨겨진 패턴을 분석했습니다.

단순히 영상을 시청하는 대신, 저는 콘텐츠 테마 (content themes), 제목 패턴 (title patterns), 게시 주기 (publishing cadence), 그리고 반복되는 핵심 신념 (recurring core beliefs)이라는 네 가지 차원에서 그의 전략을 역공학 (reverse-engineer) 해보려 시도했습니다.

제가 발견한 것은 예상했던 것보다 훨씬 더 구조적이었고, 훨씬 더 많은 것을 드러내 주었습니다.

엔지니어링 접근 방식 (The Engineering Approach)

이 아이디어를 테스트하기 위해, 저는 CreatorLens라는 작은 내부 도구를 구축했습니다. 워크플로우 (workflow)는 의도적으로 단순하게 설계되었습니다:

SerpApi를 사용하여 YouTube 데이터 수집
데이터 정규화 (Normalize)
구조화된 페이로드 (payload)를 DeepSeek로 전송
AI 분석을 통해 전략적 통찰력 (insights) 생성
대시보드 (dashboard)에 결과 시각화

저는 이 실험을 위해 데이터베이스 (database)를 사용하지 않았습니다. 대신, API와 구조화된 프롬프트 (structured prompts)를 중심으로 구축된 가볍고 상태가 없는 (stateless) 파이프라인 (pipeline)으로 어디까지 도달할 수 있는지 확인하고 싶었습니다.

스택 (stack)은 다음과 같습니다:

사용자 입력 (User Input)
↓
SerpApi YouTube Search API
...

높은 수준 (high level)에서 보면, SerpApi는 데이터 계층 (data layer) — 즉, 비디오 검색, 메타데이터 (metadata) 가져오기, 자막 (transcripts) 추출 — 을 담당했습니다. 그리고 DeepSeek는 추론 계층 (reasoning layer) — 반복되는 테마 식별, 제목 패턴 추출, 시청자 페인 포인트 (pain points) 클러스터링, 핵심 신념 요약, 전략 프레임워크 (strategy frameworks) 생성 — 을 담당했습니다.

CreatorLens architecture: SerpApi handles data collection and normalization, while DeepSeek performs reasoning and strategy analysis.

흥미로운 점은 단순히 데이터를 수집하는 것이 아니었습니다. 비정형 (unstructured) YouTube 콘텐츠를 분석 가능한 무언가로 바꾸는 것이었습니다.

SerpApi를 사용한 YouTube 데이터 수집

저에게 첫 번째 과제는 YouTube 채널을 구조화되고 분석 가능한 데이터로 변환하는 것이었습니다.

비디오를 하나씩 수동으로 여는 대신, 저는 SerpApi의 YouTube API를 사용하여 가벼운 데이터 파이프라인 (data pipeline)을 구축했습니다. 앞서 언급했듯이, 워크플로 (workflow)는 다음과 같았습니다:

YouTube Search API
→ 비디오 가져오기 (fetch videos)

...

구현 자체를 단순하고 상태가 없는 (stateless) 방식으로 유지하고 싶었기에, 전체 흐름을 조율하는 Next.js의 단일 API 라우트 (API route)를 구축했습니다:

비디오 검색 (Search videos)
→ 메타데이터 가져오기 (fetch metadata)
→ 자막 가져오기 (fetch transcripts)
...

구현을 깔끔하게 유지하기 위해, SerpApi JavaScript SDK를 작고 재사용 가능한 헬퍼 (helper)로 감쌌습니다:

import { getJson } from "serpapi";

function serpapi(params: Record<string, string>) {
...

그다음, 데이터 수집 로직을 세 가지 집중된 함수로 나누었습니다:

searchYouTubeVideos()
fetchVideoDetails()
fetchTranscript()

각 함수는 YouTube 데이터셋의 서로 다른 계층을 처리했습니다.

비디오 검색

첫 번째 함수인 searchYouTubeVideos()는 SerpApi의 YouTube Search API를 사용하여 크리에이터의 비디오를 검색합니다.

const data = await serpapi({
  engine: "youtube",
  search_query: creatorName,
...

응답으로부터 분석에 필요한 필드를 추출했습니다:

video ID
title
thumbnail
view count
publish date
duration

return results
  .slice(0, maxVideos)
  .map((v) => ({
...

또한 다음과 같은 값들을 정규화하기 위해 작은 parseViews() 헬퍼를 추가했습니다:

"1.2M views"
"842K views"

비디오 상세 정보 가져오기 (Fetching Video Details)

하지만 각 비디오의 필드만으로는 분석하기에 충분하지 않았기 때문에, 두 번째 함수인 fetchVideoDetails()를 추가했습니다. SerpApi의 YouTube Video API를 통해 추가 메타데이터를 얻을 수 있습니다.

const data = await serpapi({
  engine: "youtube_video",
  v: videoId,
...

이를 통해 다음과 같은 더 상세한 정보를 얻을 수 있습니다:

description
likes
더 정확한 view count

return {
  description: (vr.description as string) ?? "",
  views: parseViews(vr.views),
...

또한, 단일 요청이 실패할 경우 파이프라인이 우아하게 실패할 수 있도록 의도적으로 함수를 try/catch로 감쌌습니다.

자막 가져오기 (Fetching Transcripts)

파이프라인에서 가장 중요한 부분은 자막 검색(transcript retrieval)이었습니다.

SerpApi의 YouTube Transcript API를 사용했습니다:

const data = await serpapi({
  engine: "youtube_video_transcript",
  v: videoId,
...

저는 자막 스니펫을 추출하여 일반 텍스트로 결합했습니다:

return snippets
  .map((s) => s.text)
  .join(" ");

이것은 프로젝트가 단순한 분석에서 실제 전략 분석으로 전환된 지점입니다.

제목과 메트릭은 무엇이 성과를 냈는지 알려줍니다.

자막은 다음을 드러냅니다:

**-- 반복되는 언어 및 설득 패턴

사고 모델(mental models) 및 감정적 프레이밍
청중 포지셔닝

세 가지 검색 함수를 하나의 오케스트레이션 계층으로 구성하기 (Composing Three Fetch Functions Into One Orchestration Layer)

마침내, 저는 세 가지 함수를 하나의 오케스트레이션 계층 (orchestration layer)으로 통합했습니다.

이 함수의 목표는 간단합니다. 크리에이터 이름을 입력받아, DeepSeek가 분석에 필요로 하는 모든 정보를 포함한 정규화된 비디오 목록을 반환하는 것입니다.

export async function fetchVideosWithDetails(
  creatorName: string,
  maxVideos = 10
...

내부적으로 파이프라인은 세 가지 작업을 수행합니다:

크리에이터 이름
→ 관련 YouTube 비디오 검색
→ 비디오 메타데이터 (metadata) 가져오기
...

각 비디오에 대해 메타데이터와 스크립트 (transcript)는 병렬로 가져옵니다:

const [details, transcript] = await Promise.all([
  fetchVideoDetails(v.videoId),
  fetchTranscript(v.videoId),
...

이는 불필요한 순차적 API 호출을 방지합니다. 스크립트는 메타데이터 응답에 의존하지 않으므로, 두 요청을 동시에 실행할 수 있습니다.

최종 출력물은 구조화된 VideoData[] 배열이며, 각 항목에는 비디오 제목, URL, 메타데이터 및 스크립트가 포함됩니다. 이를 통해 DeepSeek가 흩어진 API 응답을 바탕으로 추론하도록 강제하는 대신, 깔끔한 입력 형식을 제공할 수 있습니다.

높은 수준(high level)에서 보면, SerpApi가 전체 데이터 계층을 처리했습니다:

크리에이터 이름
→ YouTube 검색 결과
→ 비디오 메타데이터
...

이 데이터셋이 준비되면, 데이터 수집 단계에서 분석 계층으로 넘어갈 수 있습니다.

DeepSeek를 사용하여 크리에이터 전략 분석하기

YouTube 데이터가 구조화된 데이터셋으로 정규화되면, 다음 과제는 가공되지 않은 비디오 콘텐츠를 크리에이터 수준의 전략적 통찰 (strategy insights)로 전환하는 것이었습니다.

저의 첫 번째 시도는 당연하게도 각 스크립트를 잘라내어(truncate) DeepSeek에 직접 보내는 것이었습니다.

처음에는 이것이 놀라울 정도로 잘 작동했습니다. 하지만 더 긴 비디오들을 테스트한 후, 중요한 한계점을 발견하기 시작했습니다. 중요한 논거, 스토리텔링 구조, 그리고 반복되는 아이디어들은 종종 비디오의 후반부에 등장한다는 점입니다. 스크립트를 공격적으로 잘라냄으로써, 분석이 콘텐츠의 앞부분에만 편향되는 결과가 나타났습니다.

예를 들어, 핵심 통찰(insight)이 중간쯤에 나타날 수도 있고, 논증의 결론이 완전히 누락될 수도 있으며, 감정적 프레이밍(emotional framing)이 전체 스크립트에 걸쳐 점진적으로 전개될 수도 있습니다.

그래서 저는 반대의 접근 방식을 시도했습니다. 즉, 여러 개의 전체 스크립트를 단일 DeepSeek 프롬프트(prompt)로 보내는 것이었습니다.

const payload = videos.map((v) => ({
  title: v.title,
  views: v.views,
...

그 방식은 다른 문제들에 부딪혔습니다. 여러 개의 긴 스크립트를 보내는 것은 지연 시간(latency)과 컨텍스트(context) 사용량을 크게 증가시켰으며, 반복되는 문구, 스폰서 세그먼트, 추임새(filler words)와 같은 노이즈가 섞인 구어체 콘텐츠를 유입시켰습니다. 비디오의 수가 늘어날수록 너무 많은 무관한 컨텍스트가 주의력(attention)을 분산시켜 추론(reasoning) 품질이 저하되었습니다.

어떤 방식이든, 저는 동일한 벽에 부딪히고 있었습니다. 바로 컨텍스트 압축(context compression) 문제였습니다. 내용을 자르면 신호(signal)를 잃고, 합치면 노이즈(noise)가 추가됩니다.

The context compression problem. Naively truncating transcripts or combining multiple long transcripts into a single prompt either loses critical information or overwhelms the model, resulting in degraded reasoning quality and unreliable analysis.

2단계 분석 파이프라인(Two-Step Analysis Pipeline)으로 전환

그래서 저는 워크플로(workflow)를 계층적 파이프라인(hierarchical pipeline)으로 재설계했습니다. 정보를 이해하기 전에 압축하는 대신, DeepSeek가 먼저 각 비디오를 독립적으로 이해한 다음, 그 요약본들을 바탕으로 패턴 분석(pattern analysis)을 수행하도록 만든 것입니다.

Step 1
Full transcript
→ DeepSeek
...

이 아키텍처(architecture)는 분석 품질을 크게 향상시켰는데, 그 이유는 DeepSeek가 각 개별 비디오를 완전히 이해한 후에 의미론적 압축(semantic compression)이 이루어졌기 때문입니다.

The two-step analysis pipeline. Instead of truncating transcripts or analyzing hundreds of videos in a single prompt, CreatorLens first converts each full transcript into a structured VideoBrief, then performs cross-video analysis on the compressed summaries to identify recurring themes, title patterns, audience pain points, and creator strategy frameworks.

첫 번째 단계에서는 각 스크립트로부터 구조화된 통찰(structured insights)을 독립적으로 추출했습니다.

두 번째 단계에서는 원문 텍스트 대신 의미론적으로 밀도가 높은 요약본(semantically dense summaries)을 사용하여 채널 전체에 걸쳐 반복되는 전략적 패턴을 분석했습니다.

또한 비디오별 요약(per-video summarization)을 병렬로 실행할 수 있었기 때문에 파이프라인의 확장(scale)이 더 쉬워졌습니다.

구조화된 AI 계약(Structured AI Contracts) 설계

개발 과정에서의 한 가지 중요한 깨달음은 프롬프트 엔지니어링(prompt engineering)이 단순히 "더 나은 질문을 하는 것"이 아니라, 신뢰할 수 있는 AI 인터페이스를 설계하는 것에 더 가깝다는 점이었습니다.

DeepSeek를 챗봇(chatbot)처럼 다루는 대신, 엄격한 입력 및 출력 계약(contracts)을 가진 구조화된 분석 엔진(structured analysis engine)으로 취급했습니다.

프롬프트는 결과적으로 파이프라인의 서로 다른 단계 사이를 잇는 스키마 기반 인터페이스(schema-driven interfaces)가 되었습니다.

1단계 프롬프트: 비디오별 의미론적 압축(Per-Video Semantic Compression)

첫 번째 프롬프트는 전체 YouTube 비디오를 구조화된 의미론적 표현(semantic representation)으로 압축하는 데 집중했습니다.

export function buildVideoSummaryPrompt(
  video: VideoData
): string {
...

대화형 요약(conversational summaries)을 생성하는 대신, 모델은 다음과 같은 구조화된 전략적 신호(strategic signals)를 추출하도록 강제되었습니다: