[블로그 포스팅 자동화 구축기 #3] Control/Data Plane 분산 아키텍처와 Skill/Rule 체계 전면 개편

Antigravity 기반 블로그 자동화 파이프라인의 v3.0 대규모 개편기입니다. Control Plane과 Data Plane의 완전한 분산 아키텍처, 5대 Native Skill과 전역 Rule 체계, 여러 사건·사고와 하네스 가이드라인 정립 과정을 솔직하게 기록
Antigravity 블로그 자동화 v3.0 분산 아키텍처 다이어그램 — Control Plane, Data Plane, Dynamic CDN Layer

지난 1편에서는 구글 NotebookLM의 한계를 짚고 Antigravity 에이전트 단독 루프로 전환한 배경을 다루었고, 2편에서는 4대 지시서 체계와 Median UI 하네스, jsDelivr CDN 이미지 동기화 파이프라인의 실전 시행착오를 정리한 바 있습니다.

2편을 작성하고 하루 동안 집중하여 BlogDocs 자동화 시스템의 아키텍처를 크게 수정했습니다. 기존 시스템이 '하나의 레포지토리 안에서 프롬프트 지시서로 에이전트를 조율하던 구조'였다면, 이번 3세대(v3.0) 전환은 Control Plane(지능/규칙)과 Data Plane(콘텐츠/데이터)을 물리적으로 분리하는 분산 아키텍처를 구축하고, Antigravity 2.0 네이티브 Skill & Rule 시스템으로 전면 재편한 것이 핵심입니다.

이번 글에서는 단순한 기능 업데이트를 넘어, 시스템을 운영하며 겪었던 여러 가지 사건·사고들과 그 과정에서 수정된 하네스 가이드라인, 그리고 완전히 새로워진 v3.0 자동화 워크플로우를 가감 없이 공유하고자 합니다.

1. 왜 단일 레포지토리를 쪼개야 했는가 — Control Plane vs Data Plane

초기 BlogDocs 프로젝트는 단일 Git 레포지토리 안에 모든 것을 담고 있었습니다. 에이전트가 읽어야 할 지시서(Instructions)와 페르소나 설정은 물론, 수집된 기술 지식 베이스(Knowledge), 발행된 HTML 원본, CDN 배포용 이미지 파일까지 한곳에 적재되었습니다.

애초에 BlogDocs를 구상할 때의 본래 목적은 '여러 블로그를 중앙에서 일관되게 관리하고 포스팅을 자동 생산하는 범용 제어 시스템'이었습니다. 기존에도 블로그별로 폴더를 나누어 생성하는 구조였기에 데이터가 직접 엉키지는 않았지만, 단일 레포지토리 안에 여러 블로그의 지식, 포스팅, 대용량 이미지가 계속 쌓이다 보니 프로젝트 전체 용량이 무거워지고 블로그별 독립적인 버전 관리와 배포가 까다로워지는 한계가 있었습니다.

이를 해결하기 위해 시스템의 책임을 명확히 이원화하는 완전 분산형 아키텍처(Decoupled Architecture)를 도입했습니다.

구분 레포지토리 핵심 역할 및 보관 자산 특징
Control Plane BlogDocs • 에이전트 네이티브 스킬 (.agents/skills/)
• 전역 상시 가드레일 룰 (.agents/rules/)
• 블로그 페르소나 메타 설정 (Instructions/Personas/)
순수 자동화 엔진 및 컨트롤 타워 (무거운 데이터 일절 배제)
Data Plane Blog_Core-Archive
Blog_NewProject 등
• 지식 베이스 아카이브 (Knowledge/)
• 발행 HTML 원본 (Blog_Posts/)
• jsDelivr CDN 연동 이미지 (images/)
• 정적 페이지 4종 (Pages/)
각 블로그별 독립 Git 레포지토리 (데이터 물리적 격리)
BlogDocs Control Plane과 독립된 Data Plane 레포지토리 간의 분산 아키텍처 다이어그램

에이전트는 Control Plane의 페르소나 파일에 정의된 TargetDir: ../Blog_Core-Archive 속성을 동적으로 참조합니다. 이를 통해 중앙의 에이전트 지능은 가볍게 유지하면서도, 물리적으로 분리된 여러 Data Plane 레포지토리를 자유자재로 넘나들며 지식 수집과 HTML 작성을 수행할 수 있게 되었습니다.

2. 프롬프트 지시서에서 Native Skill & Rule 시스템으로 전환

2세대 파이프라인의 가장 큰 불안 요소는 '자연어 오발동(False-trigger)'이었습니다. 4개의 긴 지시서 파일(01_Knowledge_Manager.md ~ 04_Static_Pages.md)을 컨텍스트에 상시 주입해두고 @주제, @피드백 같은 텍스트 멘션에 의존하다 보니, 에이전트와 "다음 편 주제 뭐로 할까?" 같은 가벼운 일상 대화를 나누는 도중에도 지시서 프롬프트를 명령어로 오인하여 수천 줄의 코드를 쏟아내고 문서를 덮어써버리는 문제가 빈번했습니다.

또한 가이드라인을 꼼꼼히 챙기겠다고 blog-harness-rules.md에 모든 CSS 클래스와 HTML 마크업 예시를 빼곡히 적어두었더니, 글쓰기와 무관한 모든 대화 세션에서도 매 턴마다 수천 토큰이 낭비되어 컨텍스트 창이 조기에 꽉 차버리는 토큰 누수 문제가 발생했습니다.

v3.0에서는 이러한 프롬프트 기반 지시서를 전면 폐기하고, Antigravity 2.0의 모듈형 Native Skill과 전역 Rule 시스템으로 전면 개편했습니다.

  1. 슬래시 커맨드 기반 5대 독립 스킬과 일원화 (.agents/skills/): /1_주제(리서치 및 수집), /2_피드백(실전 검증 및 병합), /3_게시글(HTML 포스팅 및 이미지 생성), /4_발행완료(발행 상태 동기화), /5_블로그추가(새 블로그 인프라 셋업)로 역할을 완벽히 모듈화했습니다. 초기에는 5번 스킬이 뒤늦게 추가되며 네이밍이 어긋나는 혼선이 있었으나, 디렉토리명과 Frontmatter name을 1_주제/ ~ 5_블로그추가/로 100% 일치시켜 슬래시(/)로 명시 호출할 때만 격리 실행되도록 오발동을 원천 차단했습니다.
  2. Rules 경량화와 온디맨드(On-demand) 스펙 분리: 상시 규칙(blog-harness-rules.md, trigger: always_on)에서는 방대한 마크업 예시를 걷어내고, 3대 필수 가이드라인(경험 우선 글쓰기, 순수 HTML 원칙, De-AI 이미지 규칙)만 초경량으로 유지했습니다. 상세 컴포넌트 마크업 스펙은 실제 글을 생성하는 3_게시글/SKILL.md 내부로 온디맨드 이전하여 모든 대화 세션의 컨텍스트 토큰을 대폭 절감했습니다.
  3. 미완성 구상 메모 방치 금지와 미래 예측 필드 추방: 과거에는 동작 검증도 안 된 '구상' 메모를 문서에 방치했다가, AI가 지시하지도 않은 다음 편 링크(Next Slug)를 제멋대로 상상해서 작성하는 바람에 모든 글이 404 에러로 터져 과거 글 전체를 수동 수정해야 했습니다. 이를 방지하기 위해 미완성 구상은 프롬프트에서 즉시 배제하고, 미래 예측 필드(Next Slug, series_total) 작성을 엄격히 금지하도록 룰을 정립했습니다.
  4. /5_블로그추가를 통한 멀티 블로그 원클릭 확장: 새로운 블로그를 개설할 때 번거로운 초기 세팅을 자동화했습니다. 식별자와 도메인만 입력하면 페르소나 마크다운 생성, 4대 필수 정적 페이지(About, Privacy Policy, Contact, Terms of Service)의 테마 중립적 자동 렌더링, GitHub 레포지토리 초기화까지 원클릭으로 완결됩니다.
Antigravity IDE 슬래시 커맨드 팔레트와 5대 모듈형 Skill UI

3. 디자인과 UI의 진화 — 위젯 통합과 동적 탭 네비게이션

블로그의 시각적 완성도와 UI 측면에서도 중요한 전환점이 있었습니다. 단순히 테마 XML 코드를 수정하는 데 그치지 않고, Blogger 관리자의 '레이아웃(Layout)' GUI 위젯 설정과 Median UI의 동적 컴포넌트들을 유기적으로 결합했습니다.

하이브리드 UI 커스터마이징 주요 내역:

  • 사이드바 계층 메뉴 위젯: 블로그 페르소나에 맞춘 카테고리 트리(게임개발, 홈 서버, AI 도구 등)를 사이드바 계층형 링크 리스트 위젯과 연동하여 정렬 일관성을 확보했습니다.
  • 상단 공지 슬라이더 위젯 (slider-notice-widget): 홈 화면 최상단에 주요 공지사항이나 최신 기획 연재를 슬라이드 배너 형태로 동적 노출하는 sliderNoticeSec 섹션을 활성화했습니다.
  • Blogger Label 정렬 패치: Blogger 코어가 라벨을 알파벳 순으로 강제 정렬하여 카드 UI의 in {라벨}에 세부 태그가 먼저 노출되던 문제를 테마 렌더링 로직 수정을 통해 메타데이터의 1번째(메인 카테고리) 및 2번째 라벨이 항상 우선 노출되도록 개선했습니다.

특히 가장 큰 기술적 진보는 시리즈 네비게이션 UI의 동적 탭 분리입니다. 기존에는 본문 하단에 '이전 글 / 다음 글' 링크 박스를 HTML로 하드코딩하거나 구상 단계의 메모에 의존했습니다. 이로 인해 시리즈 중간에 새 글이 추가되면 과거 모든 글의 링크를 수작업으로 수정해야 했고, AI가 존재하지도 않는 링크를 지어내는 문제가 발생했습니다.

<nav class="series-nav" data-series="antigravity-blog-automation" data-series-title="Antigravity 블로그 포스팅 자동화 구축기" data-current-slug="antigravity-blog-automation-workflow-v3"></nav>

v3.0에서는 본문 HTML 내 일체의 정적 링크 삽입을 금지하고 데이터 속성을 가진 컨테이너만 선언하도록 하네스를 확립했습니다.

이제 블로그스팟 테마의 클라이언트 자바스크립트가 Blogger Label 피드를 비동기 조회하여 '시리즈 목록' 탭(이전/다음 글 네비게이션 카드 + 접이식 전체 목차)과 '관심이 있을 만한 글' 탭을 실시간으로 렌더링합니다. 미래 예측 필드는 시스템에서 영구 추방되었고, 오직 과거 글을 가리키는 Prev Slug만 기록하게 함으로써 링크 정합성을 완벽하게 보장하게 되었습니다.

Blogger 테마에서 실시간으로 렌더링된 동적 시리즈 목록 탭과 네비게이션 카드 UI

한편, Control/Data Plane 분리 작업 중 유료 테마(Median-UI 1.7.xml)가 public CDN 배포 레포의 .gitignore에 들어가 있어 Git 추적이 안 되던 탓에 테마와 위젯 설정이 통째로 날아가는 아찔한 사고도 있었습니다. 커밋 롤백이 불가능해 백업본과 기억을 더듬어 새벽 내내 수동 복구해야 했습니다. 이 일을 계기로 커스텀 테마 XML을 안전하게 형상 관리하고, /5_블로그추가 스킬 내에 테마 중립적 정적 페이지 생성 로직을 완전히 내재화했습니다.

또한 AI가 <img> 태그에 습관적으로 style="width: 100%; border-radius: 8px;" 같은 인라인 스타일을 끼워 넣어 테마 자체의 다크 모드 테두리와 반응형 미디어 쿼리가 파괴되던 문제도, 인라인 style="" 속성 삽입을 전면 금지하고 테마 글로벌 CSS에 레이아웃을 전적으로 위임하도록 가이드라인을 확립하여 깔끔하게 해결했습니다.

4. 아직 남아있는 문제들과 다음 개선점

v3.0 분산 아키텍처를 통해 상당한 안정성을 확보했지만, 앞으로 개선해야 할 부분들도 명확히 존재합니다.

  1. 테마 XML 내부 레거시/하드코딩 요소 대청소: 저작권 보호를 위해 비공개 레포지토리(BlogDocs/Instructions/Personas/)로 안전하게 이관한 커스텀 XML 파일 내부에 남아있는 구버전 데모용 더미 링크와 미사용 인라인 스크립트를 전면 정리하여 렌더링 속도와 코드 가독성을 끌어올릴 계획입니다.
  2. /5_블로그추가 스킬의 실전 엔드투엔드 테스트: 스펙 구현 후 아직 실제 신규 블로그 개설에 적용해보지 않았으므로, 실제 2호 블로그 개설을 통해 페르소나 생성부터 정적 페이지 4종 자동 렌더링, 깃 연동까지 전 과정을 테스트할 예정입니다.
  3. 독립형 댓글 시스템(Waline/Giscus 등) 재도입 검토: 구글 계정 로그인이 강제되고, 댓글 삭제 시 잔여 문구가 남아 디자인을 해치며, 댓글 수정이 불가능한 구글 Blogger 기본 댓글의 한계를 극복하기 위해 테마와 조화로운 모던 댓글 시스템의 재도입을 단계적으로 고민하고 있습니다.
  4. 가이드라인의 지속적인 업데이트: AI 모델의 버전 변화나 새로운 위젯 및 글쓰기 패턴이 추가됨에 따라 하네스 규칙과 가이드라인을 지속적으로 보강해 나갈 예정입니다.

마무리하며

이번 v3.0 구축 과정은 처음 생각했던 설계의 적용을 위한 가다듬기와 여러 가지 문제점들을 한 번에 수정하는 시간이었습니다. AI에게 막연한 자유도를 부여하는 대신, Control/Data Plane 분리를 통해 데이터의 물리적 경계를 세우고, Native Skill과 경량화된 Rule을 통해 에이전트의 행동 반경을 정밀하게 제어할 때 비로소 신뢰할 수 있는 자동화 파이프라인이 완성된다는 것을 깊이 체감했습니다.

AI 코딩 어시스턴트나 에이전트를 활용해 블로그 및 문서화 파이프라인을 구축하면서 겪은 여러 문제점이나, 이를 통제하기 위해 도입했던 유용한 가이드라인 팁이 있으신가요? 댓글을 통해 자유롭게 경험과 의견을 나눠주시면 감사하겠습니다.