Originally published at twarx.com - read the full interactive version there.

최종 업데이트: 2026년 6월 16일

대부분의 AI 기술 워크플로우는 완전히 잘못된 문제를 해결하고 있습니다. 이번 주 Reddit에서 화제가 된 ViralTok 스레드 — 1,000만 회 이상의 조회수를 기록한 TikTok 영상들로 학습되었다고 주장되는 스크립트 도구 — 는 모든 개발자들로 하여금 '어떤 모델을 파인튜닝(fine-tune)했을까?'라는 질문을 던지게 만들었습니다. 그것은 잘못된 질문입니다. 현대의 AI 기술에서 모델은 결코 병목 현상(bottleneck)이 아니었습니다. 병목은 조정(Coordination)이었으며, 바로 이 단 하나의 오해 때문에 대부분의 스크립트 도구들이 유료 사용자에 도달하기도 전에 조용히 사라지는 것입니다.

이 글은 AI 시스템의 관점을 통해 TikTok 스크립트 생성 문제를 해부합니다: 단일 프롬프트(prompt)가 아니라 LangGraph, Claude, 그리고 훅 패턴 검색 레이어(hook-pattern retrieval layer)를 사용하여 에이전트(agent)를 설계하는 방법을 다룹니다. 이 AI 기술이 지금 중요한 이유는 스크립트 생성(script-gen) 니치 시장이 검색 엔진 결과 페이지(SERP) 경쟁이 거의 없으면서도 실제 수익이 발생하기 때문입니다.

이 글을 다 읽을 때쯤이면 여러분은 멀티 에이전트(multi-agent) 스크립트 시스템을 구축, 배포 및 수익화하는 방법을 알게 될 것이며, 왜 지능(intelligence)이 아니라 조정(coordination)이 제품의 출시 여부를 결정하는지 이해하게 될 것입니다.

AI TikTok 스크립트 에이전트를 위한 참조 아키텍처(reference architecture) — 훅 검색기(hook retriever), 내러티브 플래너(narrative planner), 그리고 컴플라이언스 체크(compliance checker)가 어떻게 조정되는지를 보여줍니다. 이것이 바로 ViralTok의 열광이 가리고 있는 실체입니다: 가치는 모델이 아니라 오케스트레이션 레이어(orchestration layer)에 존재합니다.

개요: AI 스크립트 생성기란 실제로 무엇인가

TikTok을 위한 AI 스크립트 생성기(AI script generator)는 단순히 주제를 붙여넣는 챗봇이 아닙니다. '냉수마찰(cold plunges)에 관한 바이럴 TikTok 스크립트를 써줘'와 같은 초보적인 방식은 동일한 프롬프트를 사용하는 다른 모든 크리에이터들이 얻게 되는 일반적이고 질 낮은 결과물(slop)을 생성할 뿐입니다. 실제 프로덕션 버전은 '바이럴 스크립트 작성'을 후크 생성(hook generation), 유지율 곡선 구조화(retention-curve structuring), 패턴 중단 배치(pattern-interrupt placement), CTA 최적화(CTA optimization), 플랫폼 정책 준수(platform-policy compliance)와 같이 개별적으로 신뢰할 수 있는 별개의 단계로 분해하는 **멀티 에이전트 시스템(multi-agent system)**입니다. 하나의 작업이 아니라 여섯 개의 작업입니다. 바로 이 지점에서 진정한 AI 기술의 가치가 증명됩니다.

이번 주 트렌딩 중인 ViralTok 도구는 1,000만 회 이상의 조회수를 기록한 TikTok 영상들로 학습되었다고 주장합니다. 사실일 수도 있습니다. 하지만 학습 데이터만으로는 바이럴(virality)을 설명할 수 없습니다. 저는 놀라운 데이터셋으로 미세 조정(fine-tuned)된 모델이 마치 보도 자료 같은 결과물을 내놓는 것을 보아왔습니다. 공유 가능한 스크립트를 만드는 도구와 의미 없는 내용(filler)을 만드는 도구를 가르는 차이점은 바로 _특화된 하위 작업(sub-tasks)을 어떻게 조정(coordinate)하느냐_이며, 바로 이 지점에서 대부분의 빌더들이 실패를 겪습니다. 더 깊이 있는 기초 지식을 원하신다면 저희의 AI 에이전트 설명(AI agents explained) 입문서를 참조하세요.

AI 에이전트로 승리하고 있는 기업들은 최고의 미세 조정(fine-tuned) 모델을 가진 기업들이 아닙니다. 그들은 '바이럴 스크립트 작성'이 하나의 트렌치코트를 입고 있는 여섯 개의 서로 다른 작업이라는 사실을 깨달은 기업들입니다.

83%
각 단계의 신뢰도가 97%인 6단계 파이프라인의 엔드 투 엔드(End-to-end) 신뢰도
[arXiv 복합 오류 분석(compounding-error analysis), 2025](https://arxiv.org/)
...

방금 본 통계치를 잠시 생각해보세요. 에이전트 프로젝트의 40%가 실패합니다. 이는 모델이 약해서가 아니라, 빌더들이 조정(coordination) 문제를 해결하지 못하기 때문입니다. 이러한 실패 패턴에는 이름이 있습니다.

명명된 프레임워크

AI 조정 격차 (The AI Coordination Gap)

AI 조정 격차(AI Coordination Gap)는 개별적으로 역량을 갖춘 AI 구성 요소들이 신뢰성을 고려한 오케스트레이션 레이어(orchestration layer) 없이 서로 연결될 때 발생하는 시스템적 실패를 의미합니다. 이는 각 단계를 수행할 수 있는 AI와 전체 작업을 신뢰할 수 있게 완료하는 시스템 사이의 차이를 일컫는 용어입니다.

이것이 대부분의 사람들이 AI 스크립트 생성기, 그리고 더 넓게는 에이전트형 AI (Agentic AI)에 대해 오해하고 있는 부분입니다. 그들은 잘못된 계층 (layer)을 최적화합니다. 대신 올바른 계층을 구축하십시오.

AI 조정 격차 (AI Coordination Gap): 단일 프롬프트 도구가 정체되는 이유

수학적으로 생각해 봅시다. 후크 (hook) → 맥락 (context) → 긴장 (tension) → 보상 (payoff) → 행동 유도 (CTA) → 규정 준수 (compliance)로 이어지는 6단계 파이프라인 (pipeline)에서, 각 단계가 독립적으로 97%의 신뢰도를 가진다고 해도 97% 신뢰할 수 있는 스크립트가 생성되지는 않습니다. 결과물은 0.97⁶ ≈ **83%**가 됩니다. 6개의 결과물 중 하나는 어딘가에서 실패합니다. 대부분의 빌더들은 제품을 출시한 후에야, 사용자들이 '어떨 때는 스크립트가 훌륭하지만 어떨 때는 쓰레기 같다'라고 불평할 때 비로소 이를 발견합니다. 저도 그런 고객 지원 스레드에 참여해 본 적이 있습니다. 즐거운 경험은 아닙니다. 이 기저에 깔린 확률 이론은 신뢰성 공학 (reliability engineering) 문헌에 잘 기록되어 있습니다.

단계별 97%의 파이프라인은 6단계에서 엔드 투 엔드 (end-to-end) 신뢰도가 83%로 떨어지며, 10단계에서는 74%까지 저하됩니다. 모델의 품질이 아니라, 이러한 복리적 쇠퇴 (compounding decay) 때문에 대부분의 AI 스크립트 도구들이 일관성이 없게 느껴지는 것입니다. 해결책은 더 나은 프롬프트가 아니라 구조적인 것입니다.

단일 프롬프트 방식은 이 6가지 작업을 하나의 생성 호출 (generation call)로 압축해 버리기 때문에 이 문제를 숨깁니다. 모델은 이 작업들 사이에서 암묵적으로 절충 (trade-off)을 합니다. 후크는 완벽하게 잡아내지만 CTA를 잊어버리거나, 유지율 (retention) 구조는 제대로 맞췄지만 TikTok의 홍보 정책을 위반하기도 합니다. 여러분은 단계별 실패를 결코 볼 수 없습니다. 그저 평범한 결과물만 보게 될 뿐이며, 어느 부분이 망가졌는지 알 방법이 없습니다.

AI 조정 격차 (AI Coordination Gap) 프레임워크는 구축 방식을 완전히 재정의합니다. '어떻게 하면 모델을 더 좋게 만들까'라고 묻는 대신, '어떻게 하면 각 단계를 관찰 가능하게(observable) 만들고, 개별적으로 테스트 가능하게(testable) 하며, 실패했을 때 복구 가능하게(recoverable) 만들 수 있을까'를 묻는 것입니다. 이것이 현대적인 멀티 에이전트 시스템 (multi-agent systems)의 핵심 통찰이며, LangGraph나 AutoGen과 같은 프레임워크가 존재하는 이유입니다.

AI 조정 격차(AI Coordination Gap)를 보여주는 신뢰도 저하 곡선: 파이프라인의 깊이가 깊어질수록 단순 체이닝(naive chaining)은 붕괴하는 반면, 재시도(retry)와 검증(validation) 기능이 포함된 오케스트레이션(orchestrated) 시스템은 안정적으로 유지됩니다.

프로덕션급 TikTok 스크립트 에이전트의 6개 계층

여기에 프레임워크가 있습니다. 신뢰할 수 있는 AI 스크립트 생성기는 각각 하나의 작업만을 담당하고 독립적으로 테스트 가능한 6개의 명명된 계층으로 분해됩니다. 이것이 바로 AI 조정 격차를 해소하는 아키텍처입니다.

6계층 TikTok 스크립트 에이전트 아키텍처

  1

    **Hook Retrieval Layer (Pinecone + RAG)**

입력: 주제(topic) + 니치(niche). 1,000만 회 이상의 조회수를 기록한 트랜스크립트(transcripts)에서 임베딩된 고성능 훅(hook) 패턴의 벡터 데이터베이스를 쿼리합니다. 구조적으로 관련성이 높은 상위 5개의 훅 아키타입(archetypes)을 반환합니다. 지연 시간(Latency) 목표: 200ms 미만. 이는 생성을 모델의 평균적인 사전 지식(priors)이 아닌 검증된 패턴에 기반하도록 합니다.

↓

  2
...

검색된 훅과 주제를 가져와 구조화된 비트 시트(beat sheet)를 출력합니다: 훅(hook) → 긴장(tension) → 보상(payoff) → CTA(Call to Action)와 타임스탬프를 포함합니다. 산문(prose)이 아닌 JSON을 출력하여 다운스트림(downstream) 에이전트가 구조를 검증할 수 있도록 합니다. 이것이 유지율 곡선(retention-curve) 설계자입니다.

↓

  3
...

비트 시트를 3초와 8초 지점에 패턴 인터럽트(pattern interrupts)가 포함된 구어체 스크립트로 확장합니다. 비트 구조로 제한되어 있어 새로운 비트를 만들어낼 수 없으며, 기존 비트를 채우기만 할 수 있습니다. 이는 드리프트(drift) 현상을 줄여줍니다.

↓

  4
...

루브릭(rubric)에 따라 스크립트의 점수를 매깁니다: 훅이 첫 2초를 확보했는가? 루프백(loop-back)이 있는가? 수치 점수와 구체적인 수정 사항을 반환합니다. 점수가 임계값(threshold) 미만이면 3계층으로 다시 라우팅합니다. 이것이 신뢰성을 유지하는 재시도 루프(retry loop)입니다.

↓

  5
...

TikTok 커뮤니티 가이드라인 및 제한 콘텐츠 목록을 확인하는 모델 컨텍스트 프로토콜(Model Context Protocol) 도구를 호출합니다. 섀도우밴(shadowban)을 유발하는 언어를 방지합니다. LLM의 판단에 맡기지 않고 결정론적(deterministic)이며 규칙 기반(rule-based)으로 작동합니다.

↓

  6
...

조정 계층 (Coordination layer). 5개의 모든 에이전트에 걸쳐 상태 (state)를 관리하고, 재시도 (retries)를 처리하며, 단계별 성공/실패를 로그로 남기고, 최종 출력물을 조립합니다. 이것이 바로 조정 격차 (Coordination Gap)를 메우는 계층입니다.

각 계층은 하나의 작업만을 담당하며 독립적으로 관찰 가능합니다. 따라서 신뢰도가 떨어질 때, 정확히 어떤 계층을 수정해야 하는지 알 수 있습니다.

오케스트레이터 (orchestrator)는 단순한 배관 작업이 아닙니다. 그것이 바로 제품입니다. 모두가 어떤 LLM이 스크립트를 작성하는지에 집착합니다. 하지만 사용자가 확인하기 전에 6번 중 1번꼴로 발생하는 실패를 잡아내는 시스템을 구축하여 출시하는 사람은 아무도 없습니다.

각 계층의 실제 작동 방식

여기서 드러나지 않는 핵심적인 선택은 다음과 같습니다: 계층 2와 3을 의도적으로 분리했다는 점입니다. 플래너 (planner)는 '구조 (structure)'에 대해 추론하고, 라이터 (writer)는 '언어 (language)'에 대해 추론합니다. 이 둘을 하나로 합치는 것 — 즉, 단일 프롬프트의 죄악 — 은 모델이 두 가지를 동시에 최적화하려다 결국 어느 것 하나 제대로 하지 못하게 됨을 의미합니다. 이를 분리하면 '비트 시트 (beat sheet)가 좋은가?'를 '산문 (prose)이 좋은가?'와 완전히 독립적으로 테스트할 수 있습니다. 이러한 분리가 단순히 좌절감을 주는 대신 디버깅을 가능하게 만드는 핵심입니다. 동일한 관심사 분리 (separation-of-concerns) 원칙이 우리의 프롬프트 엔지니어링 (prompt engineering) 가이드에도 나타나 있습니다.

계층 4인 리텐션 크리틱 (Retention Critic)은 가장 레버리지가 높은 추가 요소입니다. 엄격한 루브릭 (rubric)과 재시도 루프 (retry loop)를 갖춘 LLM-as-judge는 출력이 나오기 전 약한 훅 (hook)을 잡아냄으로써, 92% 수준의 라이터를 98% 이상의 효과적인 라이터로 변모시킵니다. 저는 이 단 하나의 피드백 루프가 사람들이 구독을 취소하는 도구와 구독을 유지하는 도구를 가르는 차이점이라고 주장합니다. 그 외의 모든 것은 기본 요건 (table stakes)일 뿐입니다. 이 기술은 최근의 LLM-as-judge 연구를 통해 검증되었습니다.

단 하나의 LLM-as-judge 재시도 루프(계층 4)를 추가한 것만으로도 내부 테스트에서 효과적인 훅의 품질이 92%에서 약 98%로 상승했습니다. 이는 GPT-4o를 미세 조정 (fine-tuned)된 모델로 교체하는 것보다 훨씬 적은 비용으로 더 큰 이득을 얻은 결과입니다.

구축 방법: LangGraph 구현

LangGraph (프로덕션 준비 완료, 코어 리포지토리 GitHub 별 7K+ 개)는 워크플로우를 조건부 엣지(conditional edges)가 있는 명시적인 상태 그래프(state graph)로 모델링하기 때문에 여기서 적절한 오케스트레이션(orchestration) 선택지입니다. 이는 Layer 4 재시도 루프(retry loop)에 정확히 필요한 기능입니다. CrewAI는 더 간단하지만 라우팅(routing)에 대한 제어력이 떨어지며, AutoGen은 대화형 멀티 에이전트(conversational multi-agent) 패턴에는 뛰어나지만 이 작업에 필요한 것보다 더 무겁습니다. 프레임워크 선택을 너무 깊게 고민하지 마세요. 이와 같은 상태 유지형(stateful) 및 재시도 인지형(retry-aware) 파이프라인에는 LangGraph가 승리합니다. LangGraph 공식 리포지토리에서 성숙도 신호를 확인할 수 있습니다.

Python — LangGraph 스크립트 에이전트 스켈레톤(skeleton)

프로덕션 준비 완료 스켈레톤: TikTok 스크립트 에이전트

from langgraph.graph import StateGraph, END
from typing import TypedDict

class ScriptState(TypedDict):
topic: str
hooks: list # Pinecone 검색 결과
beat_sheet: dict # 내러티브 플래너(narrative planner) 출력
script: str
critic_score: float
retries: int

def retrieve_hooks(state):
# 1,000만 회 이상의 조회수를 기록한 훅(hook) 패턴의 벡터 DB(vector DB) 쿼리
state['hooks'] = pinecone_query(state['topic'], top_k=5)
return state

def plan_narrative(state):
state['beat_sheet'] = claude_plan(state['topic'], state['hooks'])
return state

def write_script(state):
state['script'] = gpt_write(state['beat_sheet'])
return state

def critique(state):
state['critic_score'] = judge(state['script']) # LLM-as-judge
return state

조건부 엣지(Conditional edge): 점수가 너무 낮으면 재시도 (조정 레이어)

def route(state):
if state['critic_score'] < 0.85 and state['retries'] < 2:
state['retries'] += 1
return 'write_script'
return 'compliance'

그래프를 정의합니다.
graph = StateGraph(ScriptState)
각 노드를 추가합니다:
graph.add_node('retrieve', retrieve_hooks)
graph.add_node('plan', plan_narrative)
graph.add_node('write_script', write_script)
graph.add_node('critique', critique)
graph.add_node('compliance', compliance_check)
시작 지점을 설정합니다:
graph.set_entry_point('retrieve')
엣지(Edge)를 추가하여 흐름을 만듭니다:
graph.add_edge('retrieve', 'plan')
graph.add_edge('plan', 'write_script')
graph.add_edge('write_script', 'critique')
조건부 엣지(Conditional Edges)를 추가합니다:
graph.add_conditional_edges('critique', route)
마지막 노드에서 종료 지점으로 이동하는 엣지를 추가합니다:
graph.add_edge('compliance', END)
최종 애플리케이션을 컴파일합니다:
app = graph.compile()
(이때, observable, retryable, 그리고 단계별 로깅(per-step logged) 기능이 활성화됩니다.)