아키텍처

intro에서 두 게이트와 두 트랙을 짚었습니다. 여기서는 그 구조가 에이전트 팀과 Phase 흐름으로 어떻게 구현됐는지, 산출물이 어디에 저장되는지를 봅니다. 눈여겨볼 점은 두 가지입니다. 에이전트끼리 본문을 대화로 주고받지 않고 _workspace/ 파일로 인계한다는 점, 그리고 발행 직전에 두 게이트가 차례로 놓여 있다는 점입니다.

Phase 0~5 흐름

자연어 요청이 들어오면 blog-orchestrator가 Phase를 배정합니다. “발행까지 해줘”는 Phase 0부터 5까지 전부 돌고, “검수까지만”은 Phase 0부터 4까지 돌고, “번역만”은 Phase 0과 Production의 번역 부분만 도는 식입니다.

graph TB
  start[자연어 트리거 - 이 주제로 글 써줘]
  p0[Phase 0 Orientation - 로컬 상태 확인, slug 충돌 검사]
  p1[Phase 1 Strategy - brief 생성]
  p2[Phase 2 Production - 리서치, 집필, 편집, 번역]
  p3[Phase 3 Quality - AdSense, SEO, E-E-A-T, 한영 정합]
  p4[Phase 4 AI Pattern Gate - 14 카테고리 점수]
  p5[Phase 5 Publish - Blogger 업로드]

  start --> p0 --> p1 --> p2 --> p3 --> p4
  p4 -->|합격 30 미만| p5
  p4 -->|불합격 60 초과| p2
  p3 -->|FAIL| stop[발행 중단]

Phase 3과 Phase 4는 둘 다 게이트입니다. Phase 3의 품질 판정이 FAIL이면 발행 전에 멈추고, NEEDS_REVIEW이면 Phase 2 산출물을 고쳐 다시 돕니다. Phase 4의 AI-smell 점수가 불합격이면 Phase 2로 되돌아가 다시 쓰고, 최대 2회까지 돌다가 그래도 안 되면 사용자에게 넘깁니다. 두 게이트를 모두 통과한 글만 Phase 5의 Blogger 업로드에 닿습니다.

에이전트 팀

여섯 에이전트가 Phase와 트랙에 대응합니다. 각 에이전트의 책임과 읽는 스킬은 AI_AUTOMATION.md의 Module Source Map에 한 줄씩 적혀 있습니다.

에이전트	트랙	책임
strategy-agent	집필	Phase 1을 맡습니다. 제목 후보와 slug, 카테고리, 목표 독자, 키워드, 검색 의도, 아웃라인, 차별화 각도를 정합니다
production-agent	집필	Phase 2를 맡습니다. 리서치와 본문 집필, 편집, 한영 번역을 진행합니다
quality-agent	집필	Phase 3을 맡습니다. AdSense와 검색 대응, E-E-A-T, 한영 정합을 판정합니다
content-lead	마케팅	발행 후 배포 문안을 작성하고 편집합니다
seo-discovery-lead	마케팅	키워드를 발굴하고 AI-SEO 각도를 잡습니다
marketing-director	마케팅	발행 후 배포를 배정합니다. X와 Reddit, Hacker News, AI-SEO를 다룹니다

집필 트랙 셋(strategy, production, quality)은 Phase 1부터 3까지를 채우고, 마케팅 트랙 셋(marketing-director, content-lead, seo-discovery-lead)은 발행 후 배포를 채웁니다. AI Pattern Gate(Phase 4)는 에이전트가 아니라 ai-pattern-check 스킬이 직접 실행합니다.

집필과 마케팅, 두 트랙

같은 저장소에서 두 트랙이 함께 돕니다. 진입점만 갈라지고, 발행물이라는 공유 자산에서 다시 만납니다.

graph LR
  user[사용자 발화]
  user -->|이 주제로 글 써줘| bo[blog-orchestrator]
  user -->|이 글 퍼뜨려줘| md[marketing-director]

  bo --> post[발행된 글 - Blogger]
  post --> md
  md --> x[X 스레드]
  md --> reddit[Reddit]
  md --> hn[Hacker News]
  md --> aiseo[AI-SEO - LLM 인용 최적화]

집필 트랙이 글을 발행하면, 그 발행물이 마케팅 트랙의 입력이 됩니다. 글을 쓰지 않고 이미 발행된 글의 배포만 실행하려면 마케팅 트랙을 직접 호출합니다. 두 트랙을 한 오케스트레이터에 묶지 않은 이유는 집필과 배포의 주기가 다르기 때문입니다. 글 한 편을 쓰는 동안 배포는 여러 번 일어나고, 배포만 다시 실행하고 싶은 경우가 잦습니다.

디렉터리 계약

모든 에이전트 산출물은 _workspace/ 한 폴더 안에 격리됩니다. _workspace/ 바깥의 scripts/, .claude/, AI_AUTOMATION.md, CLAUDE.md는 사람의 승인 없이 수정하거나 삭제하지 않습니다. 이것이 보안 기준선 S2입니다.

_workspace/
├── briefs/
│   ├── {slug}-brief.md           Phase 1 전략
│   ├── {slug}-research.md         Phase 2 리서치
│   ├── {slug}-edit-notes.md       Phase 2 편집 노트
│   ├── {slug}-quality.md          Phase 3 품질 보고서
│   └── {slug}-ai-check.md         Phase 4 AI-smell 보고서
├── posts/
│   ├── new/{ko,en}/{category}/{slug}.md    발행 대기 (staging)
│   ├── {ko,en}/{category}/{slug}.md        발행 후 archive
│   └── images/                              임베드 이미지
└── pages/{ko,en}/*.md             Blogger 정적 페이지 (about, privacy 등)

발행 대기 폴더와 보관 폴더가 어디서 갈리는지가 핵심입니다. 글은 posts/new/ 아래에서 작성되고, 발행 스크립트가 업로드에 성공한 다음 같은 상대 경로를 유지한 채 posts/ 아래로 옮깁니다. blogger_post_id와 blogger_url은 발행 대기 파일에 적지 않습니다. 업로드에 성공한 뒤에 스크립트가 채웁니다.

카테고리가 분명하지 않으면 도구나 플랫폼 분석은 ai로 두고, 의견이나 작업 흐름을 다룬 에세이는 thoughts로 둡니다.

frontmatter 계약

한글본과 영문본을 묶는 것은 frontmatter입니다.

title: "..."
slug: "{slug}"
date: "YYYY-MM-DD"
description: "..."
keywords:
  - "..."
lang: "ko"
hreflang_en: "/posts/en/{category}/{slug}"

영문본은 lang: "en"과 hreflang_ko로 반대편을 가리킵니다. 두 본문이 서로를 hreflang으로 가리키기 때문에, 한쪽만 발행되거나 경로가 어긋나면 검색 엔진이 두 글을 짝으로 인식하지 못합니다. 경로 연결 규칙이 정해져 있어서 사람이 매번 맞출 필요는 없습니다.

자동화 진입점은 한 곳을 가리킵니다

.claude/agents/와 .claude/skills/는 Claude Code용 저장 위치이고, AGENTS.md는 Codex용 진입점입니다. 둘 다 AI_AUTOMATION.md를 읽습니다. Phase 정의와 Module Source Map, 디렉터리 계약, 게이트 기준값이 그 한 파일에 모여 있어서, 어느 실행 환경에서 작업하든 Phase와 산출물 계약이 같습니다.

다음

다음 섹션은 verification입니다. Phase 3의 quality-check가 네 축으로 무엇을 판정하는지, Phase 4의 ai-pattern-check가 14개 항목을 어떻게 점수화하는지, 그리고 보안 기준선 S1~S8이 어디서 강제되는지를 봅니다.