← ~/blog
2026. 04. 04. Creative Engine

AI가 콘텐츠 공급망을 운영한다

AI로 글을 한 번 뽑는 것과, 기획·작성·검증·발행을 멀티에이전트로 매일 운영하는 것은 다르다. 지금 읽는 이 글이 그 시스템의 산출물이다 — 검증 게이트와 사람 승인을 둔 이유.

AI가 콘텐츠 공급망을 운영한다

지금 읽는 이 글은, 사람이 단독으로 쓴 글이 아니다

AI로 블로그 글 한 편을 뽑는 일은 이제 누구나 한다. 주제를 던지고, 모델을 한 번 호출하고, 다듬어서 올린다. 하루면 된다. 어려운 건 그다음이다 — 매주, 같은 톤으로, 사실을 틀리지 않고, 기밀을 흘리지 않으면서, 그 일이 반복해서 일어나도록 만드는 것.

한 번의 생성과 하나의 공급망은 다른 문제다. 단발 생성은 운이 좋으면 한 편이 잘 나온다. 공급망은 열 편째에도 첫 편과 같은 품질·같은 안전 기준이 보장돼야 한다. 그 차이를 우리는 자체 제품을 운영하며 배웠고, 이번에는 그 교훈을 콘텐츠 그 자체에 적용했다. 지금 읽는 이 글은 사람이 처음부터 끝까지 손으로 쓴 글이 아니다. 역할을 나눈 에이전트들이 기획하고, 쓰고, 검증하고, 사람의 승인을 받아 예약발행한 결과다.

콘텐츠를 파이프라인으로 — 기획·작성·검증·발행

우리는 한 번의 LLM 호출 대신, 역할을 분업한 파이프라인을 택했다. 글 한 편은 네 개의 손을 거친다.

기획 에이전트  → brief        (무엇을·어디까지 쓸지, 공개 경계 사전 표시)
작성 에이전트  → draft        (brief를 받아 본문 작성, 자체 검열 1차)
검증 에이전트  → report       (공개정책·톤·사실 정확성 PASS/FAIL)
   └ FAIL이면 라인 단위 수정 지시로 작성 에이전트에 반송
사람 승인 게이트 → approve     (통과해야만 다음 단계)
발행          → 예약발행으로 내보냄

핵심은 각 단계가 파일로 상태를 넘긴다는 점이다. 기획은 brief 파일을, 작성은 본문 파일을, 검증은 리포트 파일을 남긴다. 다음 에이전트는 앞 단계의 결과물(아티팩트)만 읽고 자기 일을 한다. 컨텍스트 윈도우나 휘발성 메모리에 상태를 담지 않는다 — 모든 단계가 파일로 남아 재현·검사 가능하다. “파일이 곧 상태”라는 이 설계는 우리가 내부 시스템 전반에서 공유하는 공통 철학이다. 크래시가 나도, 중간에 사람이 끼어들어도, 어디까지 진행됐고 무엇이 근거였는지 그대로 추적된다.

왜 단일 호출을 버리고 검증 게이트를 넣었나

단일 LLM 생성은 빠르다. 그런데 운영해 보면 세 가지가 무너진다.

첫째, 톤이 표류한다. 한 호출은 그날의 프롬프트 기분을 탄다. 회차가 쌓일수록 같은 회사가 쓴 글로 보이지 않게 된다. 둘째, 그럴듯한 허구가 섞인다. 모델은 빈칸을 자신 있게 메운다 — 존재하지 않은 수치, 일어나지 않은 사건. 셋째, 가장 위험한 것, 기밀이 새어 나갈 수 있다. 클라이언트, 개인정보, 내부 식별자, 아직 공개하지 않은 방법론의 구현 디테일. 한 번 색인되면 회수가 안 된다.

그래서 우리는 생성과 검증을 분리했다. 쓰는 손과 거르는 손을 같은 호출에 두지 않는다. 검증 에이전트는 본문을 줄 단위로 훑어, 공개정책(클라이언트·PII·인프라 식별자·경쟁 moat 구현 차단)과 사실 정확성을 PASS/FAIL로 판정한다. FAIL이면 발행되지 않고, 라인을 지정한 수정 지시와 함께 되돌아간다. 여기에 사람 승인 게이트를 하나 더 둔다 — 파괴적이거나 되돌릴 수 없는 행위는 명시적 confirm 전까지 차단한다는, 우리 시스템들이 공유하는 원리 그대로다.

속도를 약간 내주고 신뢰를 얻는 트레이드오프다. 그리고 콘텐츠에서는 그 거래가 거의 항상 옳다. 잘 쓴 글 한 편보다, 새지 않는 발행 백 편이 회사에는 더 중요하다.

운영하며 배운 것 — 생성보다 게이트가 어렵다

값비싼 교훈은 초기에 왔다. 우리는 자체 제품(밥비서, 결정론 알고리즘으로 식단을 짜는 주간 식단 서비스)을 한 회차에서 사실과 다르게 묘사할 뻔했다 — LLM 없이 도는 결정론 엔진을 “AI가 생성한다”는 식으로. 작은 표현 차이지만, 자기 제품의 작동 방식을 틀리게 적는 글은 신뢰를 무너뜨린다.

이 오류는 더 똑똑한 작성 모델이 아니라 게이트가 잡았다. 우리는 제품의 사실을 단일 진실원 문서로 묶고, 검증 단계에서 본문의 주장을 그 진실원과 대조하게 했다. 깨달음은 분명했다 — 어려운 건 생성이 아니라 검증이다. 무엇을 쓸지는 모델이 잘한다. 무엇을 쓰면 안 되는지, 어디서 사실이 어긋났는지를 강제하는 일이 진짜 시스템이다. 사람 승인을 끝까지 남긴 이유도 같다. 자동화가 빨라질수록, 마지막에 “정말 내보낼 것인가”를 사람이 한 번 멈춰 보는 게이트의 값은 올라간다.

콘텐츠는 시작일 뿐이다

이 패턴에서 콘텐츠는 예시에 불과하다. 역할을 분업하고, 검증 게이트를 강제하고, 사람 승인으로 안전을 보장하고, 모든 단계를 파일로 감사 가능하게 만드는 구조는 반복 가능한 어떤 지식 워크스트림에도 이식된다 — 내부 문서, 리서치 정리, 운영 리포트, 고객 응대 초안. 한 번의 좋은 출력이 아니라, 매번 같은 기준으로 도는 공급망이 필요한 곳이라면 어디든.

그리고 우리가 보는 다음 지평은 더 나아간다. 에이전트가 단계를 실행하는 것을 넘어, 워크스트림 자체를 소유하는 단계 — 그 이야기는 곧 이어 적겠다. 같은 엔진을 당신의 운영 아래로 옮기는 이야기가 궁금하다면, partners@creativengine.ai.

#engineering #thesis #agents #content-ops #multi-agent
← 목록으로