Michael Johnson콘텐츠팀이 TikTok에서 새로운 주제를 알아차렸을 때는 경쟁사도 이미 그 이야기를 하고 있을 수 있습니다. 원인은 흔히 단순합니다. 검색을 수동으로, 불규칙하게 확인하고, 찾은 링크는 수집 날짜나 비교 가능한 지표가 담긴 공통 표 없이 채팅에만 남기기 때문입니다. 변화를 더 일찍 알아차리려면 검색을 반복 가능한 프로세스로 바꾸는 것이 좋습니다. 검색어를 기록하고, 찾은 동영상을 정기적으로 저장하며, 실제로 관찰한 결과끼리만 비교하는 것입니다.
아래에서는 TikTok Scraper API jsonscraper를 사용하는 Python 모니터링 방식을 살펴봅니다. 예를 들어 게시 일정표를 위해 몇 가지 주제별 검색어를 추적하는 에이전시나, 특정 주제의 공개 동영상 중 조회수와 반응이 두드러지는 동영상을 확인하려는 브랜드에 적합합니다. API는 동영상 설명, 작성자, 게시 날짜, 링크, 제공되는 카운터를 포함한 TikTok 검색 결과를 반환합니다. 스크립트는 각 응답을 보관하고 분석용 CSV 스냅샷을 만듭니다.
핵심 원칙은 추상적인 ‘트렌드’를 계산하는 것이 아니라 자체 관찰 기록에서 변화를 찾는 것입니다. 표본에 새로 등장한 동영상, 공개 카운터가 변한 기존 동영상, 설명에 반복되는 문구를 살펴봅니다. 이 방식은 콘텐츠팀이 수동으로 검토할 수 있는 주제 후보 목록을 만들고, 각 판단의 근거를 보존합니다.
수동 검색이 부실한 모니터링으로 이어지는 이유
검색 결과는 안정적인 게시물 목록이 아니라 계속 바뀌는 표본입니다. 오늘 어떤 단어로 동영상 열 개를 찾고 다음 주에 검색을 다시 열면 결과를 비교하기 어렵습니다. 이전 링크를 잃어버렸을 수도 있고, 검색 결과 구성이 달라질 수도 있으며, 카운터에는 새로운 값이 누적됩니다. 저장된 스냅샷이 없으면 특정 날짜에 팀이 무엇을 확인했는지 되짚을 수 없습니다.
간단한 일일 수집만으로도 이 문제의 일부를 해결할 수 있습니다. 실행할 때마다 관찰 날짜, 검색어, 동영상 ID, 작성자, 설명, 링크, 제공되는 지표를 저장합니다. 다음 실행에서는 동영상 ID로 레코드를 대조하고 두 버전에 해당 필드가 모두 있으면 카운터 값의 차이를 계산할 수 있습니다.
이 값은 API 응답에서 확인된 동영상의 공개 지표로 해석해야 합니다. TikTok 전체의 도달 범위나 완전한 인기 순위가 아닙니다. 검색 결과는 달라질 수 있고 일부 필드는 누락될 수 있으며, 지표는 수집 시점에 따라 달라집니다. 따라서 파이프라인의 목표는 재현 가능한 작업 표본을 만들고 검토할 후보를 찾는 것이지, 숫자 하나만으로 어떤 주제를 보편적인 트렌드라고 선언하는 것이 아닙니다.
솔루션 구성: 검색, 보관, 비교
파이프라인은 키워드 설정, API 요청, 변경하지 않은 JSON 원본 보관, 정규화된 레코드 계층, 변화 보고서의 다섯 부분으로 구성됩니다. 이렇게 나누면 각 단계를 개별적으로 점검할 수 있습니다. 응답 구조가 바뀌거나 일부 필드가 누락되어도 원본 JSON이 남아 있어 다시 처리할 수 있습니다.
- 검색어 목록을 정합니다. 제품, 업종 또는 고객의 과업과 관련된 구체적인 문구를 사용합니다. 예를 들어 주방 가전 브랜드는 ‘meal prep’, ‘air fryer recipes’, 특정 제품 카테고리명을 추적할 수 있습니다. 검색어 목록은 처리 로직에 직접 넣지 말고 설정 파일에 저장하세요.
- 수집 규칙을 정합니다. 실행 주기와 파일럿에 적합한 소규모 결과 수를 선택합니다. 날짜, 지역, 검색 매개변수를 기록하세요. 시간에 따른 비교에서는 한 번에 최대한 넓은 응답을 모으는 것보다 설정을 일관되게 반복하는 편이 중요합니다.
- 원본 응답을 보관합니다. 실행 시각 및 검색어와 함께 JSON을 기록합니다. 원본 보관본이 있으면 처음 받은 레코드를 복원하고 API를 다시 호출하지 않고도 정규화 로직을 수정할 수 있습니다.
- 확인된 필드만 정규화합니다. 응답에 존재하는 ID, 캡션, 게시 시각, 작성자, 링크, 제공되는 통계 값만 추출합니다. 값이 없으면 0으로 바꾸지 말고 빈칸으로 둡니다.
- 스냅샷을 비교합니다. 동영상 ID로 레코드를 대조하고 관찰 결과는 각각 별도로 보관합니다. 이를 바탕으로 보관본에 새로 등장한 게시물과 관찰된 지표 값의 차이를 구할 수 있습니다.
첫 테스트는 검색어 두세 개와 적은 수의 결과로 시작하세요. 설명과 작성자가 작업 목적에 부합하는지, 실제로 어떤 필드가 반환되는지, 같은 조건에서 결과 표본이 얼마나 반복되는지 확인합니다. 그다음에야 검색어를 늘리고 예약 실행으로 전환하는 것이 좋습니다.
TikTok Scraper API에서 요청할 수 있는 항목
jsonscraper TikTok API 엔드포인트 문서에 따르면 GET /searchVideo 경로는 키워드로 동영상을 검색합니다. 필수 매개변수는 keyword입니다. 문서에 기재된 선택 매개변수에는 count, cursor, date_posted, sort_by, region, cache_timeout이 있습니다. 문서는 date_posted에 this-week, this-month 같은 값을, sort_by에 relevance, most-liked, date-posted 같은 값을 설명합니다. 매개변수의 정확한 이름과 용도는 해당 문서에서 확인할 수 있습니다.
서비스의 기본 주소는 https://tiktok.evelode.com이며, 키는 license_key 쿼리 매개변수로 전달합니다. 아래 예시에서는 키를 환경 변수 JSONSCRAPER_TIKTOK_LICENSE_KEY에 저장합니다. 이렇게 하면 소스 코드에 비밀 키를 직접 넣거나 실행 로그에 출력하지 않을 수 있습니다.
응답은 중첩 구조를 고려해 파싱해야 합니다. 먼저 바깥쪽 status를 확인하고 tiktok 객체로 이동합니다. 검색 결과의 목록은 두 가지 형태일 수 있습니다. 동영상이 tiktok.aweme_list에 직접 들어 있거나, tiktok.search_item_list의 각 항목 안에 있는 aweme_info에 들어 있을 수 있습니다. 검색 응답에서 aweme_list가 비어 있어도 search_item_list에 동영상이 있을 수 있습니다. 아래 스크립트는 두 형태를 모두 처리합니다.
문서와 확인된 응답 예시에는 동영상 객체의 aweme_id, desc, create_time, share_url, 작성자 정보, statistics 객체 같은 필드가 나옵니다. 통계에는 조회수, 좋아요, 댓글, 공유 카운터가 포함될 수 있습니다. 실제 필드 구성과 의미는 응답마다 확인해야 하며, 코드는 누락된 필드를 빈칸으로 둡니다. 경로 예시와 문서에 기재된 매개변수는 TikTok Scraper API 설명에서도 확인할 수 있습니다.
Python 실습 예제
이 예제는 Python 3.8 이상을 대상으로 하며 requests 패키지를 사용합니다. python -m pip install requests 명령으로 설치하세요. 코드를 collect_tiktok.py 파일에 저장하고 환경 변수에 키를 설정한 뒤 검색어를 지정해 스크립트를 실행합니다. 스크립트는 data 디렉터리를 만들고 원본 JSON을 기록한 다음 정규화된 관찰 결과를 CSV에 추가합니다.
import csv
import json
import os
import sys
from datetime import datetime, timezone
from pathlib import Path
from urllib.parse import urlparse
import requests
BASE_URL = "https://tiktok.evelode.com"
ARCHIVE = Path("data/raw")
OUT_CSV = Path("data/observations.csv")
def get_videos(tiktok):
"""searchVideo 응답에서 확인된 형식의 동영상을 모읍니다."""
videos = []
aweme_list = tiktok.get("aweme_list") or []
if isinstance(aweme_list, list):
videos.extend(item for item in aweme_list if isinstance(item, dict))
search_items = tiktok.get("search_item_list") or []
if isinstance(search_items, list):
for item in search_items:
if not isinstance(item, dict):
continue
aweme_info = item.get("aweme_info")
if isinstance(aweme_info, dict):
videos.append(aweme_info)
# 순서를 유지하고 ID가 없는 레코드는 보존하면서 중복을 제거합니다.
result = []
seen = set()
for video in videos:
video_id = video.get("aweme_id")
if video_id and video_id in seen:
continue
if video_id:
seen.add(video_id)
result.append(video)
return result
def fetch(keyword, count=20, region="US"):
license_key = os.environ.get("JSONSCRAPER_TIKTOK_LICENSE_KEY")
if not license_key:
raise RuntimeError("환경 변수에 JSONSCRAPER_TIKTOK_LICENSE_KEY를 설정하세요")
params = {
"license_key": license_key,
"keyword": keyword,
"count": count,
"region": region,
"sort_by": "relevance",
}
response = requests.get(
f"{BASE_URL}/searchVideo", params=params, timeout=60
)
response.raise_for_status()
payload = response.json()
if payload.get("status") != "ok":
raise RuntimeError("TikTok API가 정상 상태가 아닌 값을 반환했습니다")
tiktok = payload.get("tiktok")
if not isinstance(tiktok, dict):
raise RuntimeError("응답에 TikTok 결과 객체가 없습니다")
return payload, tiktok
def write_rows(keyword, videos, collected_at):
OUT_CSV.parent.mkdir(parents=True, exist_ok=True)
fields = [
"collected_at", "keyword", "aweme_id", "create_time",
"author_id", "author_name", "author_username", "description",
"share_url", "play_count", "digg_count", "comment_count",
"share_count", "collect_count",
]
write_header = not OUT_CSV.exists()
with OUT_CSV.open("a", newline="", encoding="utf-8") as file:
writer = csv.DictWriter(file, fieldnames=fields)
if write_header:
writer.writeheader()
for video in videos:
author = video.get("author") or {}
stats = video.get("statistics") or {}
writer.writerow({
"collected_at": collected_at,
"keyword": keyword,
"aweme_id": video.get("aweme_id"),
"create_time": video.get("create_time"),
"author_id": author.get("uid"),
"author_name": author.get("nickname"),
"author_username": author.get("unique_id"),
"description": video.get("desc"),
"share_url": video.get("share_url"),
"play_count": stats.get("play_count"),
"digg_count": stats.get("digg_count"),
"comment_count": stats.get("comment_count"),
"share_count": stats.get("share_count"),
"collect_count": stats.get("collect_count"),
})
def main():
if len(sys.argv) 환경 변수를 통해 키를 전달하세요. Bash 셸에서는 현재 세션에 다음과 같이 설정할 수 있습니다.
export JSONSCRAPER_TIKTOK_LICENSE_KEY="your_key"
python collect_tiktok.py "meal prep"Windows PowerShell에서는 $env:JSONSCRAPER_TIKTOK_LICENSE_KEY="your_key" 명령으로 현재 프로세스에 변수를 설정한 다음 같은 Python 파일을 실행하면 됩니다. 키를 저장소, CSV, 응답 보관본 또는 오류 메시지에 넣지 마세요. API는 쿼리 매개변수로 키를 받으므로 전체 요청 URL이 HTTP 클라이언트나 인프라 로그에 기록될 수 있습니다. 비밀 정보가 제외되도록 로깅을 설정하세요.
코드를 읽고 결과를 확인하는 방법
fetch 함수는 문서에 기재된 매개변수를 전달하고 HTTP 상태, 바깥쪽 응답 상태, tiktok 객체의 존재 여부를 확인합니다. 올바른 JSON 본문이 왔다고 해서 무조건 성공으로 처리하지 않습니다. 형식이 예상과 다르면 이해하기 쉬운 오류와 함께 실행을 중단합니다. 이를 통해 빈 검색 결과와 접근 문제 또는 구조 변경을 구분하기 쉬워집니다.
get_videos 함수는 aweme_list의 직접 항목과 search_item_list[].aweme_info에 중첩된 레코드를 합칩니다. 그런 다음 aweme_id로 중복을 제거합니다. 동영상 하나가 두 컬렉션에 모두 나타날 수 있기 때문입니다. ID가 없다면 임의의 값을 넣지 않고 레코드를 보존해 원본 결과를 살펴볼 수 있게 합니다.
정규화에서는 중첩 객체를 안전하게 가져옵니다. 작성자 정보나 통계가 없을 수 있으므로 코드는 값을 읽기 전에 빈 객체를 대신 사용합니다. CSV의 해당 셀은 빈칸으로 남습니다. 이 차이는 중요합니다. 빈 셀은 관찰 결과에 값이 들어오지 않았다는 뜻이고, 0은 API가 실제로 반환한 숫자 값입니다.
보관본에는 요청마다 별도의 JSON 파일이 저장됩니다. 파일명에는 UTC 시각과 정리된 검색어가 포함됩니다. CSV에는 분석용 평면 레코드를 저장하고, 원본 JSON은 새 필드를 분석하거나 다시 처리할 때 기준 자료로 남깁니다. 이 이중 형식은 로컬 프로토타입뿐 아니라 향후 데이터베이스나 객체 스토리지로 이전할 때도 편리합니다.
첫 실행 결과를 확인하려면 JSON을 열어 status가 ok인지, 내부에 tiktok 객체가 있는지, 지원되는 컬렉션 중 하나 또는 둘 다에 항목이 들어 있는지 살펴보세요. 그런 다음 CSV의 값 몇 개를 원본 객체와 대조합니다. 특히 카운터가 잘못된 문자열로 변환되지 않았는지, 게시 날짜가 원래 값대로 저장되었는지, 링크가 같은 ID의 동영상을 가리키는지 확인하세요.
정상 응답에 동영상이 없다면 이를 코드 오류가 아니라 검색 실행 결과가 비어 있었던 것으로 기록하세요. 바깥쪽 상태나 HTTP 응답에 오류가 표시되면 분석 관찰 자료에 추가하지 마세요. 먼저 원인을 해결하고 다시 실행해야 합니다. 운영 환경에서는 키와 비밀이 포함된 전체 URL을 제외하고 HTTP 상태 코드, 검색어, 시각, 간단한 오류 메시지도 기록하는 것이 좋습니다.
페이지네이션과 수집의 반복 가능성
검색에서는 결과를 더 불러오기 위해 cursor 매개변수를 사용할 수 있습니다. 다음 페이지를 받아야 한다면 이전 응답에서 커서를 가져와 변환하지 않고 전달하세요. 커서는 API가 사용하는 불투명한 값입니다. 애플리케이션은 받은 그대로 저장하고 반환해야 하며, 행 수에서 계산하거나 페이지 번호로 해석해서는 안 됩니다.
초기 모니터링은 검색어별로 같은 count를 사용해 한 번만 요청해도 충분합니다. 이렇게 하면 각 실행이 제한된 검색 스냅샷을 저장한다는 점을 이해하기 쉽습니다. 페이지네이션을 추가한다면 각 페이지와 커서를 저장하고 실행당 페이지 수에 상한을 두세요. 예상하지 못한 응답으로 작업이 무한 반복되는 상황을 막을 수 있습니다.
date_posted 매개변수는 문서에 나열된 기간 중 하나로 검색을 제한하며, sort_by는 관련도, 게시 날짜 또는 좋아요 순 정렬을 선택할 수 있습니다. 시간에 따른 변화를 분석한다면 실행과 함께 이러한 설정을 기록하세요. 기간이나 정렬이 다른 검색을 비교하면 주제 자체의 변화가 아니라 검색 조건의 변화가 반영될 수 있습니다.
cache_timeout 매개변수는 응답 캐싱을 제어합니다. 문서에는 기본 캐시 기간이 3600초이며, 0을 설정하면 캐싱을 끌 수 있다고 나와 있습니다. 예약 모니터링에서는 설정을 신중하게 고르고 구성에 저장하세요. 작업을 한 시간보다 짧은 간격으로 실행하고 그 시간 안의 응답 차이를 구분해야 한다면, 반복된 결과를 변화가 없다는 뜻으로 해석하기 전에 캐싱 동작을 별도로 확인하세요.
일일 관찰 결과 비교
CSV에는 간단한 보고서 작성에 필요한 기본 정보가 이미 들어 있습니다. 검색어와 aweme_id별로 행을 묶고 collected_at 순으로 정렬한 다음, 양쪽에 지표 값이 모두 있는 관찰 쌍만 비교하세요. 예를 들어 조회수 차이는 가장 최근 관찰 값에서 이전 값을 빼서 계산할 수 있습니다. 결과를 제대로 해석하려면 절대 차이와 두 관찰 사이의 시간 모두 필요하므로 두 원래 지점을 보존하세요.
정해진 시간 간격을 명시하지 않고 이 차이를 조회수 증가 ‘속도’라고 부르지 마세요. 한 번은 아침에, 다음은 며칠 뒤에 실행했다면 그 값은 해당 기간에 누적된 변화입니다. 비교 가능한 속도를 구하려면 차이를 실제 관찰 간격으로 나눌 수 있지만, 그래도 결과는 두 스냅샷 사이의 평균 속도이지 연속 측정 데이터가 아닙니다.
두 종류의 신호를 따로 계산하세요. 첫째는 현재 검색 결과에 새로 나타난 ID입니다. 둘째는 이미 관찰한 동영상의 통계 변화입니다. 새 동영상은 현재 조회수가 어떻든 검토 후보가 될 수 있고, 기존 동영상의 증가는 게시물이 계속 반응을 얻고 있음을 보여줄 수 있습니다. 두 신호는 서로 다른 질문에 답하며 편집 일정의 서로 다른 시나리오에 유용합니다.
ID가 있는 행의 비율, 설명이 있는 행의 비율, 수집 날짜의 유무, 검색어별 고유 동영상 수, 통계가 누락된 행의 수처럼 간단한 데이터 품질 검사도 추가하세요. 이런 지표를 통해 팀이 불완전한 파일에 근거해 판단하기 전에 파이프라인이 익숙한 구조의 응답을 받지 못하기 시작했다는 사실을 알아차릴 수 있습니다. 어떤 검색어가 해당 업종에 유용한 표본을 제공하는지도 확인할 수 있습니다.
첫 보고서에는 용어, ID, 게시 날짜, 작성자, 설명, 링크, 현재 조회수, 이전 스냅샷의 조회수, 차이, 두 관찰 사이의 시간 열만 있어도 충분합니다. ‘보관본에 새로 등장’ 플래그와 편집 평가 필드를 추가하세요. 담당자는 브랜드 적합성, 형식의 활용 가능성, 타인의 아이디어를 베낄 위험성을 표시할 수 있습니다. API가 이런 평가를 대신해 주지는 않습니다.
동영상의 인기와 주제의 유용성을 혼동하지 않는 방법
조회수, 좋아요, 댓글, 공유 수는 특정 동영상에 대한 공개 반응을 설명하는 데 도움이 됩니다. 콘텐츠 계획에서는 질문의 표현, 시작 부분의 약속, 반복되는 설명 형식, 시연 유형 같은 텍스트 자체도 중요합니다. 따라서 지표만 전달하지 말고 링크와 설명도 함께 편집자에게 전달하세요. 숫자 하나만으로는 게시물이 잘된 이유를 설명하기 어렵습니다.
여러 동영상을 비교할 때 조회수와 상호작용 카운터가 모두 있으면 상호작용 비율을 계산할 수 있습니다. 예를 들어 좋아요, 댓글, 공유 수의 합계를 조회수로 나누면 관찰 가능한 반응 비율을 간단히 구할 수 있습니다. 계산식을 정해 두고 값이 누락된 동영상은 섞지 마세요. 그러지 않으면 결과를 서로 비교할 수 없습니다. 이 비율은 선택한 공개 카운터와 동영상에 한해서만 의미가 있습니다.
여러 스냅샷의 지표를 서로 독립적인 사건처럼 합산하지 마세요. 같은 동영상이 매일 다섯 번의 응답에 포함되었다면 각 행의 조회수는 하나의 카운터가 시간에 따라 변한 값이지 서로 다른 다섯 개의 시청자 집단이 아닙니다. 고유 게시물별 합계를 내려면 보고 기간의 마지막 스냅샷처럼 동영상당 일관된 관찰 시점을 사용하고, 선택 규칙을 저장하세요.
설명에서 반복되는 단어를 살펴보는 것도 유용합니다. 간단한 텍스트 분석으로 ‘레시피’, ‘리뷰’, ‘비포/애프터’, ‘실수’, ‘팁’처럼 미리 정한 단어 목록에 따라 게시물을 분류할 수 있습니다. 분류기나 언어 모델이 카테고리와 간단한 요약을 제안할 수도 있습니다. 다만 편집자가 실제 동영상으로 해석을 다시 확인할 수 있도록 표에 원본 설명과 URL을 보관하세요.
예약 실행 자동화
수동 실행을 확인한 뒤에는 자체 서버의 cron, GitHub Actions, n8n/Make 워크플로 같은 스케줄러로 수집을 옮기세요. 통합 작업은 검증된 스크립트를 실행하고, 비밀 정보 저장소에서 키를 전달하고, JSON을 보관한 뒤 성공적으로 완료된 경우에만 알림을 보내야 합니다. 스케줄러의 구체적인 구현은 인프라에 따라 달라지지만 API 호출과 처리 형식은 그대로 유지됩니다.
머신의 현지 시간 기준 매일 08:15에 실행하는 cron 예시입니다.
15 8 * * * cd /srv/tiktok-monitor && /usr/bin/python3 collect_tiktok.py "meal prep" >> logs/collector.log 2>&1이 줄을 사용하기 전에 cron이 실행되는 서비스나 셸에 환경 변수를 설정하고 호스트의 시간대를 올바르게 지정하세요. 검색어가 여러 개라면 목록을 파일에 저장하고 스크립트에는 각 검색어를 별도 실행으로 전달하는 편이 좋습니다. 그러면 한 검색어에서 오류가 발생해도 전체 작업을 취소할 필요가 없고, 보관본을 비교하기도 쉬워집니다.
검색어가 늘어나면 설정을 JSON이나 YAML로 분리하고 실행 상태, 수집한 동영상 수, 보관 경로를 기록하는 실행 로그를 추가하세요. 안정성을 위해 일시적인 네트워크 오류에 대한 제한된 재시도 횟수, 타임아웃, HTTP 오류별 처리를 마련하세요. 요청을 무한히 반복해서는 안 됩니다. 다음 실행이 문제를 가리지 않도록 작업은 눈에 보이는 상태와 함께 종료되어야 합니다.
결과를 Google Sheets, 데이터베이스, 내부 대시보드로 보내야 한다면 안정적인 원본 보관부터 추가한 뒤 연동을 구현하세요. 먼저 원본 응답을 저장하고 정규화된 행을 업로드합니다. 업로드가 실패해도 데이터를 다시 수집할 필요 없이 보관본에서 재시도할 수 있습니다. 동영상 ID와 수집 시각을 사용하면 중복을 방지하는 삽입을 구성하고 새 스냅샷과 이전 스냅샷을 구분하는 데 도움이 됩니다.
AI 추가: 출처를 대체하지 말고 분류를 돕게 하기
보관본에 설명이 많이 쌓이면 모델을 사용해 동영상을 주제별로 묶고, 자주 나오는 표현을 추리고, 편집자를 위한 짧은 설명을 만들 수 있습니다. 모델에는 검색어, 설명, 게시 날짜, 공개 카운터처럼 필요한 필드만 전달하세요. 데이터만으로는 알 수 없는 인기의 원인을 단정적으로 말하게 하기보다 구조화된 카테고리와 간단한 근거를 반환하도록 요청하세요.
모델 결과는 ai_topic, summary, review_status처럼 별도 열에 저장하세요. 원본 설명과 API 값을 덮어쓰지 마세요. 지침이나 모델이 바뀌면 저장된 레코드를 다시 처리할 수 있어야 합니다. 이를 위해 프롬프트 버전과 분류 날짜를 보관하면 유용합니다.
모델에 ‘짧은 레시피’, ‘기기 비교’, ‘초보자의 실수’ 같은 클러스터를 제안하게 하는 것이 실용적인 활용법입니다. 그런 다음 분석가가 각 클러스터에서 몇 가지 예시를 링크로 확인하고 분류 용어를 조정합니다. 사람의 검토가 포함된 이 과정은 AI를 자료를 탐색하는 도구로 활용하면서 검증 가능한 원본 관찰 자료를 보존합니다.
소규모 검색 표본만으로 형식과 도달 범위의 인과관계를 모델이 선언하게 하지 마세요. 그런 결론에는 사전에 정한 방법론, 비교 가능한 게시물, 추가 데이터가 필요합니다. 실제 편집 업무에서는 검토할 후보의 순위를 정하고 반복되는 소재에 대한 가설과 수동 검토용 링크 목록을 만드는 것으로 충분합니다.
표본 품질과 결론의 한계
파이프라인은 지정된 검색어와 매개변수로 받은 응답을 저장합니다. 이 관찰 결과를 비교하는 데는 도움이 되지만, 검색 범위는 특정 검색어, 수집 시점, 설정, 서비스 응답에 한정됩니다. 그러므로 결론을 정확하게 표현하세요. “이번 주 스냅샷에서 검색어 X의 결과 가운데 Y라는 주제가 더 자주 나타났다”라고 해야지, “지금 TikTok 전체에서 Y를 이야기하고 있다”라고 해서는 안 됩니다.
지역, 정렬 매개변수, 게시 기간, 요청 결과 수가 동일하게 설정된 시리즈끼리 비교하세요. 검색어 또는 필터를 바꾸면 새로운 시리즈로 표시합니다. 계절성이나 캠페인을 분석하려면 설정 버전을 보관하는 것이 좋습니다. 그렇지 않으면 입력 조건의 변화가 콘텐츠 자체의 변화처럼 보일 수 있습니다.
공개 지표는 스냅샷 사이에 갱신될 수 있고 게시물마다 누적된 기간이 다릅니다. 최근 게시된 동영상과 오래된 동영상은 반응이 쌓이는 단계가 다릅니다. 성과를 비교할 때는 게시 날짜와 관찰 간격을 고려하세요. 게시된 지 비슷한 동영상끼리 비교하거나, 같은 ID의 연속 스냅샷에서 나타난 변화를 분석하세요.
프로젝트가 경쟁사나 작성자와 관련된다면 작업에 필요한 범위와 최소한의 데이터만 수집하세요. 민감한 정보를 모으지 말고 공개 지표를 작성자 개인에 대한 평가로 사용하지 마세요. 마케팅팀 보고서에는 대체로 링크, 설명, 프로필 이름, 게시 시각, 집계 지표면 충분합니다. 자동화에 앞서 적용되는 플랫폼 약관, 조직의 요구 사항, 데이터 보관 규칙을 확인하세요.
실행 전 실무 체크리스트
- 어떤 주제, 형식, 게시물을 찾고 싶은지 비즈니스 질문을 정의합니다.
- 일관되게 사용할 검색어 몇 개로 시작하고 표기를 고정합니다.
- 문서에서
/searchVideo경로, 필수keyword, 나머지 매개변수를 확인합니다. - 키를 환경 변수에 보관하고 출력, 로그, 저장소에 노출되지 않도록 합니다.
- 응답의 바깥쪽 상태와
tiktok객체의 존재를 확인합니다. aweme_list와search_item_list[].aweme_info를 모두 처리합니다.- 정규화 전에 원본 JSON을 저장합니다.
- 누락된 필드는 빈칸으로 두고 0으로 바꾸지 않습니다.
aweme_id로 게시물을 대조하고 커서는 변환하지 않은 채 전달합니다.- 각 스냅샷의 수집 날짜와 검색 매개변수를 기록합니다.
- 결론을 내리거나 모델에 결과를 전달하기 전에 동영상 몇 개를 직접 확인합니다.
완성되는 결과
설정을 마치면 팀은 반복 가능한 프로세스를 갖게 됩니다. 검색어 목록이 예약 실행되고 각 응답은 원본 JSON으로 저장되며 정규화된 관찰 결과는 CSV에 추가됩니다. 분석가는 보관본에 새로 등장한 동영상을 확인하고 링크와 설명을 다시 살펴보며, 스냅샷 간에 제공된 공개 카운터를 비교하고 주제별 그룹을 만들 수 있습니다.
편집자에게 전달되는 것은 ‘가장 중요한 트렌드’라는 자동 판정이 아니라 검증 가능한 후보 목록입니다. 새 게시물, 지표 변화가 두드러지는 동영상, 반복되는 소재와 표현이 여기에 포함됩니다. 이를 통해 수동 검색에서 주제 논의까지 걸리는 시간을 줄이고, 콘텐츠 계획에 포함할지 판단할 때 확인 가능한 근거를 남길 수 있습니다.
검색어 하나, 매일 실행하는 로컬 작업, CSV 파일만으로 시작할 수 있습니다. 표본이 목적에 맞는다는 점을 확인한 뒤 스케줄러, 데이터베이스, 설명 분류 기능을 추가하세요. 문서에 기재된 매개변수와 경로는 TikTok API 문서에서 확인하고, 액세스 및 제품 정보는 TikTok Scraper API jsonscraper 페이지에서 살펴볼 수 있습니다.