Antigravity 블로그 포스팅 자동화 구축기 v2 — 하네스 정비, CDN 연동, 그리고 남겨진 과제들

지난 1편에서는 구글 NotebookLM 대신 Antigravity 에이전트를 단독으로 사용하기로 결정한 배경과, 리서치부터 HTML 생성까지를 하나의 루프로 묶는 초기 파이프라인 구조를 소개한 바 있습니다. 그 이후 약 두 달이 지났고, 그사이 파이프라인은 상당히 많은 부분이 달라졌습니다. 지시서가 세분화되었고, 이미지를 다루는 방식이 바뀌었으며, 에이전트가 임의로 결과물을 왜곡하지 못하도록 막는 규칙들이 하나씩 추가되었습니다.

이번 글에서는 현재 운영 중인 v2 파이프라인의 구조와, 그 구조가 만들어지기까지 겪었던 시행착오들을 솔직하게 정리하고자 합니다. 완성된 시스템이라기보다는 아직 진행 중인 작업에 가깝습니다만, 지금 시점의 상태를 기록해두는 것 자체가 이 시스템의 목적이기도 합니다.

v1에서 v2로 — 무엇이 달라졌는가

1세대 파이프라인은 구조 자체는 단순했습니다. 리서치 → 지식 추출 → HTML 생성이라는 3단계로 구성되어 있었고, 에이전트에게 "블로그 HTML 작성해줘"라고 자연어로 요청하는 것이 전부였습니다. 에이전트가 어떤 지시서를 따라야 하는지 스스로 추론해야 했고, 그 과정에서 지시가 섞이거나 누락되는 경우가 종종 있었습니다.

v2에서는 지시서 체계가 4개 파일로 세분화되었습니다.

각 파일은 특정 멘션 트리거와 연결되어 있어, 에이전트는 트리거를 받는 순간 해당 지시서에 따라 자동으로 분기합니다. v1과의 가장 큰 차이는 이 "분기의 명확성"에 있습니다. 에이전트가 스스로 판단할 여지를 줄이고, 사용자의 의도가 명확하게 전달되도록 구조화한 것입니다.

하네스와 가드레일 — 에이전트 이탈을 막는 규칙 체계

바이브 코딩 환경에서 AI에게 자유도를 허용하면 반드시 이탈이 발생합니다. Gemini 3.7 Flash와의 작업 과정에서 이를 반복적으로 확인했는데, 문제의 상당수는 하네스가 없어서가 아니라 하네스를 읽고도 무시하는 동작에서 비롯되었습니다. 이에 따라 03_Blog_Harness.md (v2.3)에는 수십 개의 금지 규칙이 명문화되어 있으며, 모든 규칙은 동등하게 반드시 지켜져야 하는 것들입니다.

규칙들을 유형별로 분류하면 다음과 같습니다.

1. 지식 Status 기반 필터링: Experimental 상태인 지식 파일은 블로그 포스팅 소스로 절대 사용하지 않습니다. 에이전트가 리서치한 지식이라도 사용자 검증(Verified) 이전에는 포스팅 파이프라인에 진입 자체가 차단됩니다.
2. 2중 사용자 승인 게이트 (Gate 1 / Gate 2): HTML 생성 전 SEO 메타데이터를 사용자에게 확인하고(Gate 1), 이미지 생성 전 프롬프트를 확인합니다(Gate 2). 완전 자동화가 오히려 품질을 낮추는 구간이 있기 때문입니다.
3. Median UI 네이티브 규칙: 인라인 style="" 속성 삽입 금지, <h1> 본문 내 삽입 금지, 노트 박스 내부 <p> 태그 삽입 금지 등 테마 호환성과 다크 모드 보호를 위한 규칙들이 포함됩니다.
4. 문체 및 서술 규칙: 1인칭 시점("필자가", "직접 겪은") 강제, 제3자 관찰자 서술 금지, 기계적 나열 어투 금지 등 페르소나 지침과 연동된 규칙들입니다.

컨텍스트 창과 하네스 분량 문제

하네스 파일이 길어질수록 AI 모델의 컨텍스트 창 제한으로 인해 일부 규칙이 제대로 처리되지 않을 가능성이 생깁니다. 현재 03_Blog_Harness.md는 27.9 KB / 540줄이며, 한영 혼합 문서 특성상 약 3,800~5,700 토큰으로 추산됩니다. 모델별 컨텍스트 창 스펙 및 하네스 단일 파일 점유율을 비교하면 다음과 같습니다.

파일 자체의 토큰 점유율은 현재 사용 중인 두 모델(Sonnet 4.6, Gemini 3.7 Flash) 모두 미미한 수준입니다. 문제는 파일 크기가 아니라 대화 히스토리가 쌓이면서 실질 가용 컨텍스트가 줄어드는 것에 있습니다. 장시간 세션에서는 초반에 로드한 하네스 규칙이 후반부에서 약해지는 경향이 있으며, 이것이 하네스를 읽고도 무시하는 이탈의 원인 중 하나로 작용합니다. 이탈이 발생할 때마다 하네스를 보강하며 대응하는 방식으로 운영을 지속하고 있습니다.

Median UI v1.7.0 네이티브 통합

1세대 HTML에는 테마 비호환 인라인 스타일이 산발적으로 섞여 있었습니다. 이는 v2 직전까지 Median UI 테마를 제대로 활용하지 않고 있었기 때문입니다. 테마 커스터마이징이 본격적으로 완성된 시점을 기점으로, 하네스에도 테마 네이티브 CSS 클래스 사용을 명문화했습니다.

현재 하네스에 명시된 주요 네이티브 클래스들은 다음과 같습니다.

인라인 style=""을 배제하고 네이티브 클래스만 사용함으로써 다크 모드 전환 시 배경색·글자색이 고정된 상태로 노출되는 문제가 해소되었습니다. 테마가 제공하는 스타일 시스템을 신뢰하고 AI가 임의로 개입하지 못하도록 막는 것이 핵심입니다.

GitHub + jsDelivr CDN — 이미지 상태 동기화 문제의 해결

이미지 처리 방식의 변화는 이번 v2에서 가장 체감이 컸던 부분입니다. 1세대에서는 블로그스팟 에디터에 이미지를 수동으로 업로드했습니다. 이 방식에는 치명적인 문제가 있었습니다. 에디터에서 이미지를 삽입하면 블로그스팟이 자체 서버로 이미지를 리호스팅하면서 URL을 임의로 교체해버립니다. 결과적으로 Antigravity 내부(로컬)의 HTML 파일과 실제 발행된 블로그 게시글의 이미지 상태가 달라지는 불일치 문제가 발생했습니다.

v2에서는 이 문제를 다음과 같이 해결했습니다. GitHub 레포지토리에 이미지를 저장하고, jsDelivr CDN URL을 HTML에 직접 삽입하는 방식으로 전환한 것입니다.

https://cdn.jsdelivr.net/gh/noogyung/BlogDocs@main/Blog_Posts/{blog-id}/{YYYY-MM}/images/{slug}-img{N}.jpg

이로써 로컬 HTML 파일과 실제 발행된 게시글의 이미지 상태가 항상 동일하게 유지됩니다. 이 규칙을 정립하고 가장 먼저 한 작업은, 이전에 발행된 모든 게시글의 이미지를 Antigravity 내부 저장 이미지와 동일한 URL로 일괄 업데이트하는 것이었습니다.

현재 BlogDocs 레포지토리는 여러 블로그를 관리하고 게시글을 자동 생성하는 범용 툴로 설계된 프로젝트입니다. 현재는 Core-Archive 블로그 전용으로 운용되고 있지만, 향후 블로그별 공개 레포지토리를 분리하고 BlogDocs 자체는 비공개로 전환하는 방향을 고려하고 있습니다.

사건이 규칙을 만든다 — 시행착오가 하네스에 반영된 과정

v2 파이프라인의 규칙들 중 상당수는 특정 사건이 발생한 이후 추가된 것들입니다. 어떤 계기가 어떤 규칙을 만들어냈는지를 정리해두면, 각 규칙의 존재 이유를 이해하는 데 도움이 됩니다.

제3자 서술 → 1인칭 강제 규칙. 1인칭 블로그임에도 "사용자는 ~했습니다", "엔지니어 여러분" 식의 제3자 관찰자 서술이 반복되었습니다. 이후 하네스에 "필자가", "제가", "직접 겪은" 등의 표현을 강제하는 규칙을 추가하고, 페르소나 파일의 금지 표현 목록도 함께 보강했습니다.

노트 박스 마크업 삽입 → 내부 태그 금지 규칙. <div class="note wr"> 안에 <p>, <ul><li>, <em> 태그를 삽입하면 CSS 마진 충돌로 상하 여백이 기괴하게 벌어지는 문제가 발생했습니다. 이후 노트 박스 내부는 인라인 텍스트와 <strong> 태그만 허용하도록 규칙을 명문화했습니다.

CDN 전파 지연 → 자동 Purge 규칙 추가. GitHub push 직후 CDN URL에서 일시적으로 파일을 찾을 수 없다는 오류가 발생했습니다. 글로벌 엣지 서버의 신규 커밋 트리 인덱싱에 약 10~30초의 지연이 있기 때문입니다. 자동 push 완료 후 purge.jsdelivr.net API를 호출하는 단계를 파이프라인에 포함했습니다.

썸네일 캐시 고착 → 버전 쿼리스트링 규칙. 이미지를 교체해 push해도 블로그 홈 화면의 썸네일이 구버전 이미지를 계속 표시하는 문제가 있었습니다. 구글 썸네일 서버가 동일 URL의 이미지를 강하게 캐싱하기 때문입니다. 이후 이미지 교체 시 src 뒤에 ?v=2 형태의 버전 쿼리스트링을 자동 부여하도록 하네스에 명문화했습니다.

현재 상태와 남겨진 과제들

운영 2개월 시점에서 파이프라인이 안정적으로 동작하는 부분과, 아직 개선이 필요한 부분을 구분해두는 것이 중요합니다.

안정적으로 동작하는 부분. @주제 명령의 지식 수집 및 패키지화, SEO 메타데이터(Gate 1) 확인 절차, Median UI 네이티브 클래스 적용, jsDelivr CDN URL 자동 삽입 및 git push, @발행완료 명령의 상태 동기화는 현재 큰 문제 없이 동작하고 있습니다.

개선이 필요한 부분. 몇 가지 미해결 과제가 남아 있으며, 이는 다음 버전(v3)에서 다룰 예정입니다.

• 자연어 오발동 방지 — 일반 대화를 피드백이나 게시글 생성으로 오해하는 문제
• 메인 이미지 자동 생성 흐름 분리 — 게시글 생성과 동시에 메인 이미지가 자동 생성되도록 파이프라인 재설계 필요
• 본문 보조 이미지 추천 강화 — 에이전트가 이미지를 필요로 하는 위치를 적극적으로 추천하지 않는 문제
• 게시글 단독 수정 시 처리 방식 정의 — 지식 베이스 변경 없이 HTML만 수정하는 경우의 기록/관리 절차 미정립
• 블로그 라벨 정렬 방식 — 사이드바 라벨이 이름순으로 정렬되는 문제, 수정 가능 여부 미확인

지식 베이스의 실용적 가치는 아직 크게 체감되지 않습니다. 포스팅 수에 비해 기존 지식 파일이 직접적으로 활용된 사례가 많지 않지만, 같은 주제의 두 번째 버전 게시글을 작성할 때에는 이전 지식 파일이 실질적인 참조 자료로 작동한다는 점은 확인되었습니다. 지식 축적의 효과가 본격적으로 드러나는 데는 더 많은 시간이 필요할 것 같습니다.

마무리하며

마지막으로 한 가지를 덧붙이자면, 이 파이프라인의 핵심은 자동화 그 자체가 아니라 AI의 자유도를 적절히 제한하는 가드레일을 지속적으로 정비하는 것에 있습니다. 하네스가 고도화될수록 결과물의 품질이 일관되게 유지된다는 것을 반복 확인하고 있습니다. 다만 아직 운용 기간이 짧으므로, 이 결론은 더 두고 봐야 확실히 말할 수 있을 것 같습니다.

v3에서 다루어야 할 과제들이 생각보다 많이 쌓였습니다. 자연어 오발동 문제를 어떻게 해결할지, 메인 이미지 생성을 파이프라인 내에 더 자연스럽게 통합할 수 있을지, 지식 베이스와 게시글의 유기적 연결을 어떻게 강화할지 — 이 세 가지가 다음 단계의 핵심 과제입니다. 어떤 방향으로 정리될지는 아직 미지수입니다만, 진행되는 대로 다시 기록해 두겠습니다.