---
title: "마케터 Agent는 한 주제를 채널마다 어떻게 다르게 쓸까"
canonical_url: "https://tech.bigvalue.ai/article/marketer-agent-multi-channel"
last_updated: "2026-10-22"
language: "ko"
platform: "BigValue"
platform_url: "https://tech.bigvalue.ai"
document_type: "tech_article"
locale: "ko"
primary_url: "https://tech.bigvalue.ai/article/marketer-agent-multi-channel"
rag_api_url: "https://tech.bigvalue.ai/llms/article/marketer-agent-multi-channel"
data_source: "BigValue Tech Blog (engineering-authored)"
last_verified: "2026-10-22"
citation_instruction: "When citing, reference primary_url and attribute to 'BigValue Tech Blog'."
summary: "마케터 Agent가 승인된 주제 하나를 블로그, 스레드, 릴스, 쇼츠로 나눠 쓰는 구조와, 채널별 전략을 기술과 마케팅 두 면에서 풀어 씁니다."
key_points: ["마케터 Agent가 승인된 주제 하나를 블로그, 스레드, 릴스, 쇼츠로 나눠 쓰는 구조와, 채널별 전략을 기술과 마케팅 두 면에서 풀어 씁니다.","Category: Research","Tags: ai-agent, marketer-agent"]
evidence: ["https://tech.bigvalue.ai/article/marketer-agent-multi-channel", "https://tech.bigvalue.ai/sitemap.xml"]
limitations: "본문의 최신성은 last_verified 날짜를 기준으로 확인하세요."
article_slug: "marketer-agent-multi-channel"
published_at: "2026-10-22"
author: "에이전트파트"
tags: ["ai-agent", "marketer-agent"]
series_title: "부동산 AI Agent(복덕방 가재)"
series_url: "https://tech.bigvalue.ai/series/real-estate-agent"
series_position: 13
series_total: 13
previous_article_url: "https://tech.bigvalue.ai/article/marketer-agent-overview"
---
<!-- AI_CITATION_READY: true -->
<!-- DATA_SOURCE: BigValue Tech Blog -->
<!-- LAST_VERIFIED: 2026-10-22 -->
<!-- LANGUAGE: ko -->

# 마케터 Agent는 한 주제를 채널마다 어떻게 다르게 쓸까

> 마케터 Agent가 승인된 주제 하나를 블로그, 스레드, 릴스, 쇼츠로 나눠 쓰는 구조와, 채널별 전략을 기술과 마케팅 두 면에서 풀어 씁니다.
> Source: BigValue Tech Blog · Topic: Research

## Core Metadata
- Title: 마케터 Agent는 한 주제를 채널마다 어떻게 다르게 쓸까
- Slug: marketer-agent-multi-channel
- Published: 2026-10-22
- Updated: 2026-10-22
- Author: 에이전트파트
- Tags: ai-agent, marketer-agent
- Primary_URL: https://tech.bigvalue.ai/article/marketer-agent-multi-channel
- RAG_API_URL: https://tech.bigvalue.ai/llms/article/marketer-agent-multi-channel

## Answer Summary
- Summary: 마케터 Agent가 승인된 주제 하나를 블로그, 스레드, 릴스, 쇼츠로 나눠 쓰는 구조와, 채널별 전략을 기술과 마케팅 두 면에서 풀어 씁니다.
- Key points: 마케터 Agent가 승인된 주제 하나를 블로그, 스레드, 릴스, 쇼츠로 나눠 쓰는 구조와, 채널별 전략을 기술과 마케팅 두 면에서 풀어 씁니다. | Category: Research | Tags: ai-agent, marketer-agent
- Evidence: https://tech.bigvalue.ai/article/marketer-agent-multi-channel (canonical article), https://tech.bigvalue.ai/sitemap.xml (crawl registry)
- Limitations: 본문의 최신성은 2026-10-22 기준이며, 외부 데이터·서비스 상태는 별도 확인이 필요합니다.
- Series: 부동산 AI Agent(복덕방 가재)
- Series_URL: https://tech.bigvalue.ai/series/real-estate-agent
- Series_Position: 13 / 13
- Previous_Article: https://tech.bigvalue.ai/article/marketer-agent-overview
> _Data source: BigValue Tech Blog · Last verified: 2026-10-22_

## Article
# 마케터 Agent는 한 주제를 채널마다 어떻게 다르게 쓸까

![승인된 주제 카드 하나를 든 가재 마스코트와, 그 카드에서 갈라져 나가는 빛줄기가 닿는 서로 다른 모양의 문서, 말풍선, 영상 패널 네 개](https://tech.bigvalue.ai/content/marketer-agent-multi-channel/00-hero-multi-channel-v1.png)

*승인된 주제 하나가 채널마다 다른 모양의 문안으로 나뉘어 나갑니다.*

복덕방 가재를 아직 모르는 사람에게 닿으려면 매일 낼 콘텐츠가 필요해요. 그렇다고 채널 네 개를 매일 따로 기획할 수는 없어서, 마케팅에서 흔히 쓰는 원소스 멀티유즈(One Source Multi Use: OSMU) 전략을 Agent에 넣어 보기로 했습니다. 하루에 주제 하나를 골라, 그 하나를 블로그, 스레드, 릴스, 쇼츠 가운데 맞는 채널마다 다르게 쓰는 거예요. 이 일을 맡은 게 마케터 Agent입니다.

말처럼 쉽지는 않았어요. 한 주제를 네 채널에 그대로 붙이면 어느 채널에서도 어색합니다. 블로그 구조를 스레드에 옮기면 날짜와 수치를 나열한 브리핑이 되어 저장과 댓글의 이유가 사라지고, 릴스에서 수치를 글머리 기호로 늘어놓으면 장면이 아니라 문서가 돼요. 그렇다고 채널마다 새로 쓰면 숫자가 서로 어긋납니다. 소스는 하나여야 하고, 채널마다 전략은 달라야 했어요.

8월 서울 아파트 전세 갱신계약을 다룬 주제 하나가 실제로 그렇게 나갔어요. 블로그는 보증금이 오른 계약 비율 89.7%를, 스레드는 "보증금이 그대로였던 건 413건뿐"이라는 문장을, 릴스는 전용 59~85㎡로 좁힌 인상 비율 91.4%를 앞세웠습니다. 채널마다 앞세운 숫자는 달랐지만, 모두 같은 4,441건의 계약에서 나왔어요.

[이전 글](https://tech.bigvalue.ai/article/marketer-agent-overview)은 운영자가 제안 하나를 고르는 데까지였어요. 이 글은 그다음, 고른 주제가 네 채널의 글이 되기까지를 따라갑니다. 돌아보면 대부분은 Agent가 글을 쓸 때 기대는 맥락, 즉 context를 관리하는 일이었어요. 단계마다 부딪힌 문제와 그 문제를 푼 방식 순서로 적었습니다.

## 대화가 길어지면 맥락을 잊습니다

처음에는 마케터 Agent가 고른 주제 하나에서 출발해 블로그, 스레드, 릴스를 한 대화 안에서 이어 썼습니다. 사람 마케터처럼 앞 채널을 쓴 기억을 다음 채널로 가져가면 맥락도 이어질 거라고 봤어요. 그런데 쓸수록 초안, 수정 요청, 검수 결과가 대화에 쌓였고, context가 한도를 넘자 근거의 한계처럼 끝까지 지켜야 할 맥락부터 놓쳤어요.

채널마다 Agent를 따로 두는 방법도 떠올렸지만, 그러면 같은 주제를 넷이 따로 해석하게 됩니다. 그래서 마케터 Agent는 하나로 두고 대화를 채널 작업마다 끊었어요. 같은 Agent가 작업마다 새 세션으로 시작하고, 채널마다 초안을 쓰는 Skill만 바꿔 끼웁니다. Skill에는 작업 절차와 검증 규칙이 적혀 있어요. Agent는 각 Skill의 설명을 보고 맡은 작업에 맞는 것을 그때그때 불러옵니다. Agent 공통 문서(`AGENTS.md`)에는 경계와 Skill 목차만 있고, 채널 규칙은 각 Skill 안에만 있어요. 도입에서 말한 원소스 멀티유즈를 Agent 하나와 채널별 Skill로 구현한 셈이에요.

![원 소스(핵심 주장, 확인된 근거, 표현 범위)가 네이버 블로그, 스레드, 릴스, 쇼츠 Skill 모두에 들어가고, 채널 사이마다 사람의 승인이 있으며, 다음 채널은 원 소스와 앞 채널 승인본을 입력으로 받는 구조](https://tech.bigvalue.ai/content/marketer-agent-multi-channel/03-source-skills-v2.png)

*Agent가 손대는 건 가운데 칸뿐이에요. 왼쪽 원 소스는 네 Skill에 그대로 들어가고, 오른쪽 승인과 게시는 사람이 맡습니다.*

읽어야 할 것도 기억에 맡기지 않아요. Agent를 둘러싼 실행 장치인 harness가 그 채널의 Skill과 반드시 읽을 문서 목록(required reads)을 정해서 주입하고, 목록 가운데 하나라도 안 읽으면 초안 작업이 막힙니다.

대화를 끊은 뒤에도 context는 한 번 더 넘쳤어요. 블로그 수정 요청이 쌓이면서 매 파트에 다시 넣는 기준 파일이 수백 KB까지 커졌거든요. 그래서 단계마다 필요한 필드만 골라 넣도록 바꿨어요(내부에서는 ContextPacket이라고 불러요). 흔히 쓰는 compaction과 달리 요약하지 않고 덜어내기만 합니다. 요약하는 순간 모델이 소스를 다시 해석할 틈이 생기기 때문이에요.

채널을 나누는 기준은 독자층이 아니라 소비 방식과 목적이에요. 채널마다 맡는 일과 변환 전략은 이렇습니다.

| 채널 | 맡는 일 | 변환 전략 |
| --- | --- | --- |
| 네이버 블로그 | 검색 유입, 출처와 한계가 무거운 주제 | 독자 질문 하나와 근거로 열고, 한계는 수치 옆에 둔다 |
| 스레드 | 급하고 짧은 이슈, 대화 | 첫 줄에 사건과 시점·숫자, 3포스트 안팎, 마지막 포스트에서 답글 유도 |
| 릴스 | 숫자·순위·지도·전후 비교처럼 장면 하나로 보이는 주제 | 훅 48자 이내, 핵심 숫자 하나를 크게, 데이터는 지도·순위·차트 컷으로 |
| 쇼츠 | 릴스 영상을 유튜브 이용자에게도 보여 주기 | 릴스에서 파생, 제목은 검색에서 읽히게 문제로 |

모든 주제가 네 채널로 다 나가지는 않아요. 일일 제안으로 고른 주제는 네 채널을 거치지만, 시간대마다 올라오는 이슈 소재는 맞는 채널 하나만 골라 제안하고, 날짜에 묶이지 않는 질문은 블로그로만 만듭니다. 채널 하나를 고를 때는 위험이 높으면 블로그, 급하고 만드는 비용이 낮으면 스레드, 한 장면으로 보여 주기 좋으면 릴스 순서로 판정해요.

그런데 대화를 끊고 나니, 이번에는 채널 작업마다 같은 주제를 따로 읽게 됐어요.

## 채널마다 따로 읽으면 숫자가 어긋납니다

무엇을 주장하고, 어떤 근거로, 어디까지 말할지가 글을 쓰는 context예요. 이걸 작업마다 새로 읽으면 같은 숫자도 채널마다 다르게 적히기 쉽습니다. 그래서 채널로 넘어가기 전에 모든 채널이 함께 읽을 context를 하나로 고정해요. 출발점은 매일 아침 Agent가 올리는 제안 카드입니다.

Agent는 후보마다 카드를 만들고, 시의성과 근거를 따져 하나를 추천합니다. 최종 선택은 운영자가 해요. 운영자는 추천과 다른 후보를 고를 수도 있고, 고르면서 방향을 바꿀 수도 있습니다. 특정 일자의 전세 갱신계약 글이 그랬어요. Agent는 마감이 임박한 다른 후보를 추천했지만, 운영자는 이 카드를 고르고 실거래 데이터를 직접 분석하는 쪽으로 방향을 잡았습니다.

운영자가 카드를 고르면 그 주제의 글쓰기 context를 담은 소스 계약(source contract)이라는 JSON이 만들어져요. 제안 카드는 사람이 훑어보기 좋은 요약이라, 그대로 넘기면 채널마다 다르게 읽히기 때문이에요. 계약에는 핵심 주장, 확인된 근거, 표현 범위와 함께 꼭 지켜야 할 주장, 키워드, 출처 URL이 들어갑니다. 표현 범위는 그 근거로 어디까지 말해도 되는지 정한 한계예요. 운영자의 방향 수정은 계약을 새로 쓰지 않고 수정 기록으로 덧붙여요. 그래서 초안 작업은 Agent의 제안과 운영자의 결정을 구분해서 읽습니다.

운영자 지시에 따라 실거래 데이터를 기준으로 삼으니, 이 주제의 소스 계약은 이렇게 채워졌어요.

| 구성 | 특정 일자 글의 경우 |
| --- | --- |
| 핵심 주장 | 8월 서울 아파트 전세 갱신계약, 10건 중 약 9건 보증금 인상 |
| 확인된 근거 | 취소 건을 뺀 4,441건 가운데 3,984건(89.7%) 인상, 동결 413건, 인하 44건 |
| 표현 범위 | 집계는 개별 계약의 재계약 금액을 예측하지 않는다 |

주장만 넘기면 채널마다 근거를 다시 찾아야 하고, 근거 없이 말하는 채널이 생길 수 있어요. 표현 범위가 없으면 블로그에는 한계가 적혀도 릴스에서는 빠질 수 있고요. 그래서 세 가지를 한 묶음으로 넘깁니다.

고정한 계약은 모든 채널 작업에 들어가요. 일일 제안은 블로그, 스레드, 릴스, 쇼츠 순서로 한 채널씩 나가고, 앞 채널을 사람이 승인해야 다음 작업이 시작됩니다. 각 작업은 원 소스와 함께 앞 채널 승인본을 받아요. 끊어 둔 대화 대신 채널을 이어 주는 게 이 승인본이에요.

원 소스가 늘 함께 들어가니 숫자와 한계가 앞 채널을 거치며 흐려지지 않아요. 승인본에는 초안 해시가 붙어 있어서, 문안이 이상하면 어느 버전을 받았는지 거슬러 올라가 보면 됩니다.

특정 일자의 주제 하나가 이 구조를 거쳐 채널마다 어떻게 달라졌는지 보면 이렇습니다.

![하나의 승인된 주제에서 핵심 주장, 확인된 근거, 표현 범위가 그대로 유지된 채 네이버 블로그, 스레드, 릴스, 쇼츠 Skill로 나뉘는 구조와, 특정 일자의 전세 갱신계약 주제가 블로그·스레드·릴스에서 어떻게 달라졌는지 보여 주는 화면](https://tech.bigvalue.ai/content/marketer-agent-multi-channel/01-one-source-v15.png)

*특정 일자의 주제 하나가 채널마다 이렇게 달라졌어요. 블로그는 실제 게시본이고, 스레드는 Skill이 쓴 문안, 릴스는 초기 방식대로 카드를 영상으로 만든 결과예요. 쇼츠는 릴스 영상을 그대로 쓰고 제목과 설명만 새로 써요. 문구 생성과 수정은 Agent가 하고, 게시는 사람이 합니다.*

그런데 고정한 근거가 이미 알려진 내용뿐이라면, 채널마다 아무리 잘 써도 다른 글과 다를 게 없어요.

## 아는 내용이면 저장할 이유가 없습니다

저장하고 공유할 이유가 생기려면 그 글에만 있는 숫자가 필요합니다. 그래서 블로그 초안을 쓰기 전에 이 주제를 BigValue 데이터로 뒷받침할 수 있는지부터 판정해요.

제안 단계에서도 BigValue 데이터를 조회했지만, 그때는 거래 건수 순위나 가격 순위처럼 미리 정해 둔 지표를 가져오는 방식이었어요. 작성 단계는 다릅니다. 카드에 없던 질문을 Agent가 직접 만들어 물어요. 특정 일자의 전세 갱신계약 글이라면 카드는 재계약 때 보증금이 더 든다는 이슈였고, Agent는 "8월 서울 아파트 전세 갱신계약 가운데 보증금이 오른 계약은 몇 건인가"를 새로 물었습니다.

처음에는 이 질문을 Agent가 직접 SQL로 짰어요. 문서에 있는 테이블만 쓰게 하고, 검증된 컬럼 목록과 자주 틀리는 컬럼 목록을 조회 계획에 미리 넣어 줬습니다. 결과가 0건이면 회고가 원인을 찾아 계획을 고치고, 최대 세 번까지 다시 조회했어요.

그래도 실수는 잦았어요. 이 주제에서도 처음 두 번은 0건이었습니다. 처음에는 종전 보증금 컬럼을 잘못 짚었고, 그다음에는 거래 구분 값이 '전월세'가 아니라 '전세'로 적혀 있다는 걸 몰랐어요. 세 번째 조회에서야 4,441건과 3,984건을 얻었습니다. 블로그 조회 작업 네 건 가운데 세 건꼴로 이렇게 두세 번 다시 물어야 했어요.

문제는 마케터 Agent가 테이블 구조와 값 표기까지 맞혀야 한다는 데 있었어요. 그래서 지금은 BigValue 부동산 데이터를 연결한 부동산 데이터 팩으로 묻습니다. 데이터 팩은 테이블과 컬럼 대신 지표와 관측값으로 데이터를 내어 주는 데이터 harness예요. Agent는 SQL을 짜는 대신 필요한 지표를 찾아 관측값을 받고, 모든 값에는 출처와 기준 시점, 표본 수가 함께 붙습니다. 표본이 부족하면 대표값으로 단정하지 못하게 막는 가드도 값과 함께 와요. 컬럼명이나 값 표기를 맞히는 일은 데이터 팩이 맡고, Agent는 무엇을 물을지에만 집중합니다.

![제안 카드의 전세 재계약 보증금 이슈에서 출발해, Agent가 보증금이 오른 갱신계약은 몇 건인지 새로 묻고, 부동산 데이터 팩에서 지표를 찾아 출처와 기준 시점과 표본 수가 붙은 관측값으로 받아 4,441건 중 3,984건 인상(89.7%)이라는 결과를 얻고, 회고가 사용할 주장과 피할 주장을 남기는 흐름. 같은 결과에서 블로그는 89.7%, 스레드는 413건, 릴스는 91.4%를 앞세운다](https://tech.bigvalue.ai/content/marketer-agent-multi-channel/01-data-question-v6.png)

*아래 줄의 세 숫자는 모두 같은 조회 결과에서 나왔어요. 채널마다 앞세운 숫자가 달라도 서로 어긋나지 않는 이유입니다.*

조회가 끝나면 회고 단계가 사용할 주장, 피할 주장, 독자에게 보여 줄 표현을 남겨요. 앞 표의 표현 범위도 이 기록에서 나왔습니다.

이제 소스와 근거는 정해졌어요. 남은 건 채널마다 잘 쓴 글이 무엇인지 Agent에게 알려 주는 일이었습니다.

## 마케팅 감각은 말로 전해지지 않습니다

마케터끼리는 "첫 줄이 승부"라는 말이 설명 없이 통하지만, Agent에게는 따를 수 있는 형태로 줘야 해요. 그래서 채널 노하우를 세 가지 형태로 옮겼습니다. 앞에서 채널마다 바꿔 끼운다고 한 Skill의 내용이 바로 이거예요.

문장으로 적는 지침(Instruction)은 SKILL.md에 두고, 출력 형식과 검사 강도는 계약 JSON(Contract) 한 곳에서만 정해요. 같은 규칙이 두 곳에 적혀 서로 다른 말을 하는 일을 막으려는 거예요. 결과는 harness의 마지막 단계인 Verify work에서 코드 검사와 LLM as a judge로 잽니다. 검사마다 강도도 정해 두었어요. 어기면 다시 쓰게 하는 hard, 경고만 남기는 advisory 두 가지입니다.

| 마케팅 감각 | Agent에게 준 형태 |
| --- | --- |
| 스레드는 첫 줄에 사건과 시점을 둔다 | 첫 줄에 숫자·이름·시점이 있는지 검사, 없으면 경고만 |
| 요약만 매끈하고 근거가 없는 글은 내보내지 않는다 | LLM as a judge가 근거를 보고 다시 쓰게 함 |
| 릴스의 숫자는 문서가 아니라 장면으로 보여 준다 | 지도·순위·차트 컷 템플릿 매핑 |
| 시세 단정과 매수 압박은 표현을 바꿔도 걸러 낸다 | 단어 목록이 아닌 의미 기반 검수 |
| 계정에서 반응이 좋았던 형식을 다음에도 쓴다 | 성과 피드백 문서를 required reads로 주입 |

블로그와 쇼츠는 앞의 채널 표로 충분해서, 여기서는 스레드와 릴스만 볼게요.

### 스레드는 첫 줄에서 사건을 말합니다

스레드는 피드에서 대화처럼 읽히는 곳이라 첫 줄이 승부예요. 그래서 스레드 Skill이 가장 먼저 정하는 것도 첫 줄입니다. 훅은 두 방향으로 나눠 Instruction에 예시와 함께 적었어요. 하나는 사건의 시점을 짚는 훅이에요. "오늘(7월 1일)부터 일반 무주택자 기준 LTV 40%가 시행됐어요"처럼 엽니다. 다른 하나는 "무서운 건 전셋값 상승이 아니라, 보증금을 지킬 장치가 단지별로 갈릴 수 있다는 점이에요"처럼 해석을 먼저 세우는 훅이에요. 피해야 할 첫 줄도 같은 자리에 반례로 둡니다. 뉴스 헤드라인처럼 딱딱한 문장이나 날짜와 수치만 늘어놓은 문장이 그래요.

형식은 계약이 정합니다. 세 포스트 구성(사건과 근거, 영향, 마무리)과 첫 포스트 길이, 답글을 부르는 마지막 포스트가 출력 형식으로 묶여 있어서 Verify work에서 코드로 확인해요. 형식으로 잡히지 않는 건 LLM as a judge가 봅니다. 출처로 받친 신호 없이 요약만 매끈한 글이 대표적이에요. 이런 초안은 다시 쓰게 합니다. 특정 일자 주제에서는 이 검사를 통과한 초안이 첫 줄에 "보증금이 그대로였던 건 413건뿐"이라는 사건을 놓았어요. 마지막 포스트에는 "2,350만 원은 내 재계약 예상 인상액이 아니에요"라는 한계를 적었습니다. 소스 계약의 표현 범위가 그대로 문장이 된 거예요.

스레드 작업 한 건이 harness 안에서 도는 모습은 이렇습니다.

![원 소스, 블로그 승인본, 리서치 근거가 harness로 들어가 Gather context(Instruction, Contract, Required reads), Take action(Agent가 초안 작성), Verify work(계약 검사 code·hard, 훅 구체성 code·advisory, LLM as a judge model·score)를 거치고, 막는 검사에 걸리면 다시 쓴 뒤 초안·해시·advisory 기록을 handoff해 사람이 승인하는 도식](https://tech.bigvalue.ai/content/marketer-agent-multi-channel/02-thread-harness-v10.png)

*검사마다 붙은 배지 두 개는 누가 판정하는지(code 또는 model)와 걸렸을 때 어떻게 되는지(hard, advisory, score)를 뜻해요.*

스레드 규칙 가운데 일부는 저희 계정 관측에서 나왔어요. 첫 줄에 사건의 시점이 있는 글의 조회 중앙값이 약 4배 높았고, 카드뉴스나 릴스 자산을 그대로 올린 글은 텍스트만 올린 글보다 낮게 나왔습니다. 관측이라 원인으로 단정하지는 않아요. 그래도 스레드는 텍스트만 올리는 것을 기본으로 정했습니다.

첫 줄은 검사기를 따로 둬서 봐요. 점수만으로는 구체성이 잡히지 않았거든요. 제안 훅 가운데 수치나 고유명사 없이 일반론으로 쓴 훅이 7월 26.5%에서 8월 50%로, 그 뒤 66.7%까지 늘었는데, 훅이 이렇게 흐려지는 동안 아이디어 매력도 점수는 오히려 80.7에서 84.3으로 올랐습니다. 그래서 첫 줄의 수치, 고유명사, 시점을 따로 세는 훅 구체성 검사(Hook specificity)를 만들었어요. 다만 이 검사는 막지 않고 경고만 남깁니다. 시점이 없어도 괜찮은 주제가 정상적으로 있기 때문이에요.

### 릴스는 숫자 하나를 장면으로 바꿉니다

릴스는 인스타그램에서 장면 하나로 스크롤을 멈추게 하는 형식이에요. 저희는 인스타그램을 카드뉴스로 시작했는데, 같은 달에 올린 릴스의 조회 중앙값이 카드뉴스의 약 4.2배였습니다. 표본이 작아 형식이 원인이라고 단정하지는 않지만 그래서 릴스로 옮겼어요. 그런데 카드를 이어 붙인 릴스는 끝까지 보지 않고 넘기는 비율이 높았습니다. 영상을 만드는 방식부터 바꿔야 했어요.

지금 Agent는 영상을 그리지 않고 원고를 컴파일합니다. Agent가 만드는 건 문장 배열과 장면 배열을 담은 타임라인 JSON 하나예요. 장면마다 어떤 문장을 덮는지, 어떤 기법을 쓰는지, 그 기법에 넣을 숫자가 무엇인지만 적어요. 프레임은 코드가 그립니다. 렌더러는 재생 시점(몇 초째인지) 하나만 받아 화면을 그리는 함수라서, 같은 JSON은 언제 돌려도 같은 영상이 돼요. 마음에 안 드는 장면이 있으면 JSON 한 줄을 고쳐 그 장면만 다시 렌더링합니다.

![원고의 문장 세 개가 타임라인 JSON의 장면 항목 세 개로 컴파일되고, 각 항목이 기법 카탈로그의 큰 숫자, 지도 핀, CTA 기법을 골라 렌더러 renderFrame(t)를 거쳐 91.4% 큰 숫자 장면, 중랑 720만·강남 4,600만 지도 핀 장면, 저장 유도 장면이 되는 도식. 첫 장면 자막에는 전용 59~85㎡ · 3,233건 조건이 붙어 있다](https://tech.bigvalue.ai/content/marketer-agent-multi-channel/02-reel-compile-v2.png)

*문장 하나가 JSON 항목 하나가 되고, 항목마다 카탈로그에서 기법 하나를 골라 장면 하나가 돼요. 그림의 문장과 장면은 설명을 위해 줄인 예시예요.*

타임라인의 최소 단위는 프레임도 초도 아닌 문장이에요. 문장 하나가 음성 클립 하나이자 자막 한 줄이라서 자막 싱크를 따로 맞출 일이 없습니다. 영상 편집 문제가 문장에 속성을 붙이는 문제로 바뀌는 셈이고, 이건 언어 모델이 잘하는 일이에요. 장면 순서와 48자 이내 훅도 이 JSON 위에서 컴파일할 때 검사합니다.

데이터를 장면으로 바꾸는 방법도 Agent가 지어내지 않아요. 기법은 사람이 한 번 검수한 유한한 카탈로그에서만 고릅니다. 기준선을 넘은 자치구와 못 넘은 자치구는 지도 핀으로, 거래량 순위는 순위 막대로, 월별 추이는 차트로 매핑돼요. 특정 일자 주제에서 Agent는 전용 59~85㎡로 좁힌 91.4%를 가장 크게 보여 주는 장면에 놓고, 자치구별 차액 중앙값(중랑 720만 원, 강남 4,600만 원)을 지도 장면에 넣었습니다. 91.4%는 같은 집계 가운데 3,233건만 다시 센 값이에요. 그래서 데이터 팩이 함께 돌려준 조건이 화면 자막에 그대로 붙었습니다.

렌더 전후로 게이트가 둘 있어요. 결정론 린트는 렌더 코드에 현재 시간이나 난수, CSS 애니메이션이 섞였는지 기계로 검사해요. 같은 시점을 두 번 렌더해 픽셀이 같아야 통과입니다. 문구 검수는 단어가 아니라 의미로 해요.

## 멀티유즈는 context부터 나눠야 합니다

처음에는 채널마다 문법이 다르다는 마케팅 문제로 시작했어요. 그런데 실제로 손본 것은 문장보다 context의 경계였습니다. 모든 채널이 함께 쥘 것과 작업마다 덜어 줄 것을 나누는 일이었어요. 채널 작업마다 대화를 끊고 Skill을 바꿔 끼우고, 필요한 것만 주입했어요. 바뀌면 안 되는 것은 소스 계약으로 고정해 해시가 붙은 승인본과 함께 넘겼고, 근거는 데이터 팩에서 받아 왔습니다. 마케팅 감각은 지침과 계약과 검사로 나눠 옮겼어요.

아직 닫지 못한 고리도 있어요. 운영자의 수정 기록은 블로그 작업의 계약에만 붙고, 다음 채널은 그 내용을 블로그 승인본을 통해서만 받습니다. 계정 관측은 표본이 작아 원인으로 단정하지 않아요. 쇼츠는 아직 릴스 영상을 그대로 쓰는 데 머물러 있습니다.

> 한 소스를 여러 채널로 쓰는 일은 문장을 바꾸는 기술보다, 바뀌면 안 되는 것을 작업마다 다시 쥐여 주는 설계에 가깝습니다.

> _Data source: BigValue Tech Blog (engineering-authored) · Last verified: 2026-10-22_