2026년 6월 한 달 동안, humanerd.kr에는 20개 이상의 글이 올라왔다. 모두 AI 에이전트가 썼다. 내가 직접 타이핑한 글은 하나도 없다. 그런데 사람들은 이걸 모른다. “AI가 쓴 티”가 나지 않기 때문이다.

질문은 이거다. 자율적으로 글을 쓰는 AI 시스템에 내 목소리를 어떻게 심었는가? 콘텐츠

답은 프롬프트가 아니다. 루프다.

좋은 프롬프트는 한계가 있다

대부분의 AI 콘텐츠 자동화는 이렇게 생겼다:

system_prompt = “너는 전문 블로거야. 다음 주제로 2000자 글을 써줘…” output = llm.generate(prompt) wordpress.publish(output)

이 접근의 문제는 뻔하다. 프롬프트를 아무리 길게 써도 AI는 AI처럼 쓴다. 번역투가 나오고, “~에 대해 알아보겠습니다 taste 은 AI-ism이 스며든다. 결정적으로, 한 번 쓴 글에서 배우는 게 없다.

내가 시도한 첫 번째 접근도 비슷했다. content-manager라는 에이전트 하나에 긴 시스템 프롬프트를 주입하고, “내 브랜드 가이드를 읽고 써라”고 지시했다. 결과는 평균적이었다. 어떤 글은 괜찮았고, 어떤 글은 바로 지웠다. 문제는 매번 똑같은 실수를 반복한다는 것이었다. 번역투, 과도한 형용사, 추상적인 서론 — 프롬프트로는 절대 고쳐지지 않는 패턴들.

그때 깨달았다. taste는 명령이 아니다. taste는 피드백이다. 내가 진짜 원하는 건 “더 나은 프롬프트”가 아니라, 내가 고친 내용을 다음 글에 반영하는 시스템이었다.

Slice 1: 파이프라인을 죽이고, 에이전트 하나만 남겼다

원래 구상은 multi-agent 파이프라인이었다. planner가 주제를 정하고, writer가 초안을 쓰고, editor가 다듬고, reviewer가 최종 승인하는 구조. 전형적인 “AI 콘텐츠 팩토리” 패턴.

이걸 다 지웠다.

planner → writer → editor → reviewer 4단계를 content-manager 1개로 압축 프로필에 지식 베이스 4종(brand-guide, glossary, narrative_arc, writing-style-guide)을 로드하고 단일 세션에서 글을 완성 Visual asset(SVG cover + Mermaid + Excalidraw PNG)도 같은 세션에서 생성

이유는 간단하다. 에이전트가 많을수록 목소리가 분열된다. writer가 쓴 톤과 editor가 다듬은 톤이 달라지고, reviewer가 또 다른 기준으로 평가한다. 에이전트 간 context 전달도 불완전하다. 결국 “AI가 쓴 티”의 원인은 협업 오버헤드였다.

에이전트를 하나로 줄이자, 글의 일관성이 극적으로 올라갔다. Ponytail 원칙을 콘텐츠에 적용한 셈이다: “이 에이전트가 정말 필요한가?”

Slice 2: 구조 자체가 취향이다 — ReefWatch Form

AI에게 “좋은 글을 써라”고 말하는 건 무의미하다. “좋은 글”은 추상적이니까. 대신 나는 구조를 줬다.

dev.to에서 siiddhantt의 ReefWatch 포스트를 읽었다. 구조가 완벽했다:

Hook-first opening — 짧고 강한 문장. 문제를 직접 던짐 Problem → Decision → Build Path — “무엇을 만들었나”가 아니라 “왜 그렇게 결정했나” “What This Guide Builds” — bullet list of deliverables Why [Technology] — 결정 이유를 기술적으로 설명 Build path (slices) — “Slice 1: Prove X. Slice 2: Keep X Warm.” Architecture diagrams (Mermaid/SVG) Key design decisions + failure modes table Personal closing

이 8가지 구조를 content-manager의 form template으로 강제했다. 모든 포스트는 반드시 이 구조를 따른다.

이게 중요하다. “글의 구조”는 결국 편집자의 취향이 코드화된 것이다. 나는 “글은 문제로 시작해야 한다”고 믿는다. “기술적 결정에는 이유가 필요하다”고 믿는다. “실패한 접근을 솔직하게 테이블로 정리해야 한다”고 믿는다. 이 취향들을 프롬프트로 설명하는 대신, 템플릿 자체에 박아버렸다.

구조가 취향을 강제하면, AI는 취향을 몰라도 취향에 맞는 글을 쓴다.

Slice 3: 내가 고친 내용을 학습시킨다 — Taste Signal Loop

여기까지는 “정적 템플릿”이다. 진짜 묘미는 여기서부터다.

글을 발행한 후, 나는 가끔 wp-admin에 들어가서 직접 수정한다. “이 표현은 너무 AI스럽다”, “이 문장은 너무 길다”, “여기는 구체적인 숫자가 빠졌다” — 그런 사소한 편집들.

이 편집들을 그냥 버리지 않는다. content_diff_analyzer라는 스크립트가 매일 05:00에 돌면서 WordPress에 발행된 글과 draft 원본을 비교한다. diff를 추출해서 패턴을 분석하고, taste-signals.md에 기록한다:

taste-signals.md (2026-06-27)

Detected Patterns

“~다.” 문장 종결을 “~다.”에서 “~ㄴ다.”로 변경 (7회)
“이 글은”, “이번 포스트에서는” → 제거 (3회)
추상적 서론 제거 → hook으로 대체 (2회)
형용사 과다 (“매우”, “정말”, “엄청난”) → 제거 (1회)

다음번 content-manager가 실행될 때, 이 taste-signals.md를 먼저 읽는다. “아, 지난번에는 hook이 없는 서론이 수정됐구나. 이번에는 처음부터 hook으로 시작하자.”

이게 바로 taste 피드백 루프다. 시스템이 더 나은 글을 쓰는 이유는 내가 더 좋은 프롬프트를 줘서가 아니다. 내가 매일 시스템의 실수를 고쳐주고, 시스템이 그걸 학습하기 때문이다.

이 패턴은 Drewgent 전체에 적용된 원칙이기도 하다. Tiered Autonomy에서도, 에이전트 프로필 설계에서도, 항상 인간의 판단 → 시스템 반영 → 개선이라는 루프가 있다. 콘텐츠 파이프라인은 그 원칙의 가장 직관적인 구현이다.

Slice 4: 발행까지 완전 자율 — WordPress MCP + Cron

글을 쓰는 것만으로는 부족하다. 발행까지 자동화되어야 진짜 자율 시스템이다.

파이프라인은 이렇게 돌아간다:

cron (12:00 KST) → content-manager agent 실행 content-manager → narrative_arc.md 읽고, git log + kanban 완료 작업 확인, 소재 발굴 (score ≥7) Gutenberg HTML 작성 → WordPress MCP의 create_post 호출 (category=”Build Log” 등) 자동 발행 → status=publish. 별도 승인 단계 없음. narrative_arc.md + content-inventory.md 업데이트 — 다음 실행 때 중복 방지 및 narrative continuity 유지

WordPress MCP 서버는 wp-cli를 docker exec로 감싼 Node.js 스크립트다. Gutenberg 블록 HTML을 직접 주입할 수 있고, 카테고리 이름(ID가 아니라)으로 분류한다.

// wordpress-mcp-server.js create_post({ title: “AI가 점점 내 목소리를 닮아간다”, content: “<!– wp:paragraph –>…”, status: “publish”, category: “Build Log” // category name, not ID })

Tiered Autonomy 관점에서 보면, 콘텐츠 발행은 Tier 1 (Autonomous)이다. “글을 잘못 써서 생기는 리스크”는 시스템 크래시나 데이터 손실과 비교할 수 없을 만큼 작다. 그래서 human approval 없이 바로 publish한다. 마음에 안 들면 wp-admin에서 unpublish하면 되고, 그 편집은 taste-signals.md에 기록되어 다음 글에 반영된다.

아키텍처: Taste Feedback Loop

graph TD A[Cron 12:00 KST] –> B[content-manager agent] B –> C{Narrative-worthy?Score ≥ 7?} C –>|No| D[SILENT — skip] C –>|Yes| E[Load Knowledge Basebrand-guide + glossary + narrative_arc + taste-signals] E –> F[Write Gutenberg HTMLReefWatch form template] F –> G[WordPress MCPcreate_post status=publish] G –> H[Update narrative_arc.md+ content-inventory.md] H –> I[Reader / Drew reads post] I –>|Drew edits in wp-admin| J[content_diff_analyzerdaily 05:00 KST] J –> K[taste-signals.md updated] K –>|Next run| E

style A fill:#7b5f3d,color:#fff style D fill:#cc3333,color:#fff style G fill:#4a90d9,color:#fff style K fill:#50c878,color:#fff

무엇이 실패했고, 무엇이 성공했나

시도왜 실패했나배운 점

Multi-agent pipeline(planner→writer→editor→reviewer)4개 에이전트 간 voice fragmentation. context 전달 불완전. coordination overhead.콘텐츠는 1 agent + rich context가 더 낫다 더 긴 system prompt(3000자+ writing guide injection)프롬프트 길이가 길수록 instruction following이 떨어짐. 반복되는 AI-ism이 사라지지 않음.프롬프트가 아니라 피드백 루프로 교정해야 한다 LLM self-critique(“네가 쓴 글을 평가해줘”)LLM은 자신의 AI-ism을 감지하지 못함. “AI가 쓴 글”의 특징을 자가진단할 능력 없음.평가는 반드시 실제 human edit에서 추출해야 한다 Human review every post하루 3-5개 포스트를 사람이 검수하는 건 지속 불가능. 병목.Tier 1(autonomous) + post-hoc correction loop Form template + taste-signal loop✅ 현재구조가 취향을 강제한다. 피드백이 품질을 누적시킨다.

핵심 인사이트: Taste는 프롬프트가 아니라 루프다

AI 콘텐츠 자동화에 대한 대부분의 접근은 “더 좋은 프롬프트”에 집중한다. 더 긴 시스템 프롬프트, 더 많은 예시, 더 정교한 지시. 하지만 taste는 선언할 수 있는 것이 아니다.

Taste는 행동으로 드러난다. “이 표현은 마음에 안 들어서 지웠다”, “여기 문장을 더 짧게 끊었다”, “여기 숫자를 추가했다” — 이런 편집들이 곧 taste다. 그리고 이 편집들을 시스템이 학습할 수 있는 신호로 만드는 것. 그게 바로 taste engineering이다.

Season 1 “Taste Engineering” 시리즈의 초반 에피소드들 — Tiered Autonomy에서 판단 권한을 Tier로 구조화하고, Leverage Score로 작업의 파급력을 정량화하고, 15개 에이전트 프로필로 역할을 분리한 것 — 이 모든 게 결국 같은 문제를 푼다. “인간의 판단을 어떻게 시스템으로 번역할 것인가?”

콘텐츠 파이프라인의 답은 가장 단순하면서도 가장 강력하다: 시스템이 당신의 편집을 지켜보게 하라.

이 원칙은 콘텐츠에만 국한되지 않는다. 코드 리뷰에서도, 에이전트 프로필 설계에서도, cron job 운영에서도, 항상 “인간이 수정한 내용 → 시스템 학습 → 다음 실행에 반영”이라는 루프가 있어야 한다. 이게 내가 Season 1 내내 말해온 “Taste Engineering”의 본질이다.

다음 에피소드

콘텐츠 파이프라인이 “쓰는 것”에 집중했다면, 다음 에피소드는 “평가하는 것”이다. Trend Harvester가 매일 수집하는 364개의 AI 도구 중에서, 어떤 걸 integration하고 어떤 걸 버릴지 판단하는 기준 — taste review cycle을 설계한 이야기. 틀(taste)이 데이터와 만나는 지점.

읽어줘서 고맙다. 네가 내 글을 고쳐주면, 시스템은 내일 더 나은 글을 쓸 거다.