만약 여러분이 단일 채팅 완료(chat completion) 호출을 감싸는 시스템 프롬프트(system prompt)에 불과한 '콘텐츠 에이전트(content agent)'를 구축했다면, 이 글은 여러분을 위한 것입니다. 이것은 프레임워크 홍보가 아닙니다. 제가 매주 콘텐츠 운영을 위해 실제 운영 환경(production)에서 실행하고 있는 실제 파이프라인 아키텍처(pipeline architecture)이며, 광범위한 단일 에이전트 대신 세 개의 좁은 범위의 에이전트를 사용했을 때 나타난 구체적인 실패 모드(failure modes)와 이를 해결한 검토 게이트(review gate)에 관한 내용입니다.

몇 달 동안 저의 콘텐츠 파이프라인은 하나의 에이전트, 하나의 시스템 프롬프트, 작업당 하나의 호출로 구성되었습니다. 주제 조사, 초안 작성, 각 플랫폼에 맞춘 재형식화(reformat)가 모두 로그가 남지 않는 단 한 번의 과정으로 이루어졌습니다. 구조는 다음과 같았습니다:

prompt = f"{topic}에 대해 내 말투로 전체 기사를 조사하고 작성한 다음, LinkedIn 게시물, X 스레드, Substack 노트를 만들어줘."
response = model.generate(prompt)

이 방식은 결과물을 빠르게 만들어낸다는 점에서는 작동했습니다. 하지만 몇 주 지나지 않아 브랜드 정체성에서 벗어났고, 출처가 불분명한 통계 수치를 최소 두 개 이상 언급했으며, 매주 거의 전체를 다시 써야 하는 상황이 발생했습니다. 해당 파이프라인에는 "모델이 실제 주장을 찾아냈는가"와 "모델이 좋은 산문을 작성했는가"와 "모델이 플랫폼에 맞게 올바르게 형식을 맞추었는가"를 구분하는 것이 전혀 없었습니다. 즉, 세 가지 서로 다른 작업이 검토되지 않은 단 한 번의 호출로 압축되어 있었던 것입니다.

해결책: 각 에이전트의 범위를 좁히고, 인수인계(handoff)를 기록하라

이제 파이프라인은 각각 단일 작업과 구조화된 인수인계(handoff)를 가진 세 개의 순차적인 에이전트로 구성됩니다:

주제 / 소스 목록 (Topic / Source List)
      ↓
에이전트 1: 리서치 수집가 (Agent 1: Research Collector)
...

초안 작성자(Draft Writer)가 반드시 따라야 하는 최소한의 요약 스키마(digest schema)는 다음과 같습니다:

{
  "claims": [
    {
...

초안 작성자의 시스템 프롬프트에는 강력한 제약 조건이 포함되어 있습니다: 모든 사실적 문장은 반드시 claims 항목에 매핑되어야 합니다. 만약 매핑할 수 없다면, 조용히 넘어가는 것이 아니라 플래그(flag)가 지정됩니다.

환각(hallucinations)을 실제로 잡아내는 검토 게이트

프롬프트 엔지니어링 (prompt engineering) 그 무엇보다 중요했던 단 하나의 규칙은 다음과 같습니다: 특정하고, 날짜가 명시되며, 이름이 밝혀진 출처로 추적되지 않는 어떠한 주장도 초안 (draft) 단계로 넘어갈 수 없다. "연구에 따르면"이나 "보고서에 따르면" 같은 모호한 표현은 안 됩니다. 항상 이름과 날짜가 있어야 합니다. 이 하나의 제약 조건이 그 어떤 수동 교정 (manual proofreading)보다 제 초안에서 조작된 통계들을 더 많이 잡아냈습니다.

검토 (Review)는 초안의 내용에만 국한되지 않습니다. 검토는 한 단계 위, 즉 애초에 어떤 모델이 초안 작성자 (Draft Writer)를 실행할지를 결정하는 주장 단계에도 적용되어야 합니다. 2026년 7월 16일~20일 주간에 세 곳의 연구소 (Moonshot, Alibaba, 그리고 GPT-5.6을 인용하며 익명으로 게시한 작성자)는 각각 검증이 누락되었거나, 유예되었거나, 혹은 은폐된 성능 주장 (capability claim)을 내놓았습니다. 독립적인 재현 (reproduction)이 없는 리더보드 데뷔, 벤치마크 테이블이 없는 "프런티어 모델 다음가는"이라는 주장, 그리고 프롬프트 (prompt)를 비공개로 유지한 수학적 돌파구 주장 등이 그것입니다. 방법론을 확인하지 않은 채 그런 헤드라인만 믿고 프로덕션 모델 (production model)을 교체하는 것은, 모든 후속 초안을 결정짓는 바로 그 결정 단계에서 검토 (Review) 없이 에이전트 (Agent)를 실행하는 것과 같습니다.

메모리 (Memory): 오류율을 실제로 시간이 지남에 따라 감소시키는 요소

각 에이전트는 작업을 시작하기 전에 실행 중인 수정 파일 (corrections file)을 로드합니다:

2026-05-12: "leverage" 사용 금지 — 이번 주 플래그(flag)가 지정된 초안에서 3회 나타남
2026-06-02: "TechRumorBlog" 소스 가중치 하향 — 검증 불가능한 주장 2건 생성
2026-06-19: 초안 작성자 (Draft Writer)가 계속 "오늘날 급변하는 AI 세상에서"로 시작함 — 금지된 도입구(banned-opener) 목록에 추가

이 파일을 시작했을 당시에는 네 줄뿐이었습니다. 지금은 백 줄이 넘습니다. 동일한 기반 모델을 사용함에도 불구하고, 3개월 전과 비교했을 때 1차 초안 (first-pass drafts)에 필요한 수정 사항이 눈에 띄게 줄어들었습니다. 지속되는 수정 파일 (persisted corrections file)이 없다면, 각 세션은 제로(zero)에서 시작하여 동일한 실수를 무한히 반복하게 됩니다. 이것이 모델의 품질과 상관없이, 대부분의 단일 세션 "AI 콘텐츠 에이전트" 설정이 구조적으로 결여하고 있는 부분입니다.

아직 자동화하지 않은 것들

Research Collector(리서치 수집가)와 Repurposer(재가공자)는 현재 정기적인 일정에 따라 작동하며, 약 2개월간의 수동 Review(검토) 과정을 거친 결과 검증되지 않은 주장이 단 하나도 누락되지 않았습니다. Draft Writer(초안 작성자)의 출력물은 재가공 단계에 도달하기 전, 매번 반드시 완전한 인간의 Review(검토) 과정을 거칩니다. 그 이유는 다음과 같습니다: 소스를 잘못 읽은 Research Collector(리서치 수집가)는 결함이 있는 요약본을 생성하지만, 이는 초안이 작성되기 전에 Review(검토) 단계에서 잡아낼 수 있습니다. 포맷을 잘못 구성한 Repurposer(재가공자)는 보기 흉한 게시물을 생성하며, 이는 제가 삭제하면 그만입니다. 하지만 Review(검토) 게이트가 잡아내지 못하는 상황에서, 깔끔하고 자신감 넘치는 문체로 잘못된 주장을 하는 Draft Writer(초안 작성자)는 제 이름이 걸린, 단순히 틀린 내용의 기사를 발행하게 만듭니다. 각 단계에서 발생하는 실패의 비용은 동일하지 않으므로, 자동화 결정 또한 이를 동일하게 취급해서는 안 됩니다.

전체 프레임워크 (Cowork Loop™, 6개 단계 전체, 엔드 투 엔드 적용): How To Build An AI Content Team