Hermes Blog Skill 실험 — 에이전트 글쓰기와 Human-in-the-loop

블로그를 오래 운영하려면 글을 쓰는 일만 남지 않는다. 후보를 고르고, 초안을 정리하고, 이미지를 붙이고, frontmatter를 맞추고, 빌드와 배포를 확인하고, 발행된 글이 실제로 보이는지 점검해야 한다. 글쓰기보다 그 주변의 운영 작업이 더 자주 반복된다.

이번 실험에서 Hermes Blog Skill은 그 반복 구간을 에이전트에게 맡겨보기 위한 장치였다. 목표는 “사람 없이 블로그를 자동 운영한다”가 아니었다. 오히려 반대에 가깝다. 어디까지는 에이전트가 잘하고, 어디부터는 사람이 개입해야 하는지 확인하는 것이 실험의 핵심이었다.

왜 블로그 운영을 에이전트에게 맡겨보는가

에이전트가 잘하는 일은 명확하다. 규칙이 있고, 반복되며, 결과를 기계적으로 검증할 수 있는 작업이다.

블로그 운영에도 그런 작업이 많다.

1. Obsidian 노트에서 발행 후보를 찾는다.
2. 글에 필요한 기본 메타데이터를 채운다.
3. tags, categories, slug, cover 같은 frontmatter를 정리한다.
4. Hexo가 읽을 수 있는 Markdown으로 옮긴다.
5. 빌드하고 GitHub Pages에 배포한다.
6. 홈, 카테고리, RSS, 개별 글 URL을 확인한다.

이 일들은 창의적인 글쓰기라기보다 운영 절차에 가깝다. 사람에게는 지루하고, 에이전트에게는 비교적 잘 맞는다. 특히 같은 절차가 반복될수록 Skill의 가치가 커진다. 한 번 정해진 규칙을 문서화해두면, 다음 실행에서는 사람이 같은 설명을 길게 반복하지 않아도 된다.

자동화가 실제로 줄여준 것

가장 먼저 줄어든 것은 “기억해야 하는 절차”였다.

예전에는 글 하나를 올릴 때마다 이런 것들을 사람이 떠올려야 했다.

• 이 글의 카테고리는 어디인가
• 썸네일 경로는 어떤 규칙을 따르는가
• ReadyToPublish와 Published 폴더 이동은 언제 하는가
• Hexo 빌드 후 어떤 파일을 확인해야 하는가
• main과 gh-pages 중 어느 브랜치를 만져야 하는가

Hermes Skill은 이 절차를 한 곳에 모아둔다. 그래서 사람은 매번 “어떤 명령부터 쳐야 하지?”를 다시 생각하기보다, 글의 방향과 품질을 보는 데 시간을 쓸 수 있다.

두 번째로 줄어든 것은 형식 오류다. 블로그 글은 본문만으로 발행되지 않는다. YAML frontmatter가 깨지면 글이 빌드에서 빠질 수 있고, 이미지 경로가 틀리면 홈 카드가 어색해진다. 에이전트에게 frontmatter 규칙과 배포 체크리스트를 명시하면, 적어도 같은 종류의 실수를 반복할 확률은 줄어든다.

하지만 여기서 중요한 점이 있다. “줄어든다”는 말은 “사라진다”는 뜻이 아니다.

사람이 반드시 봐야 하는 지점

이번 실험에서 가장 분명해진 것은 자동화의 한계였다. 에이전트는 절차를 빠르게 실행하지만, 그 결과가 독자에게 어떤 인상을 주는지는 자동으로 잘 판단하지 못한다.

사람이 봐야 하는 첫 번째 지점은 글의 관점이다.

에이전트는 내부 시스템을 설명하는 글을 쉽게 쓴다. 어떤 파일이 있고, 어떤 명령을 쓰고, 어떤 구조로 돌아가는지를 정리하는 데 강하다. 하지만 공개 블로그의 독자는 내부 운영 매뉴얼을 보러 오는 것이 아니다. 독자가 얻어야 하는 것은 “이 실험이 무엇을 의미하는가”다.

따라서 사람은 질문을 바꿔야 한다.

이 자동화가 어떻게 동작하는가?

보다 중요한 질문은 이것이다.

이 자동화를 통해 무엇을 배웠는가?
어디까지 에이전트에게 맡길 수 있고,
어디서 사람이 다시 판단해야 하는가?

두 번째 지점은 성공 기준이다.

명령이 성공했다고 해서 글이 성공적으로 발행된 것은 아니다. 빌드 명령이 끝났고, GitHub Pages가 응답하고, 홈이 200을 반환하더라도 방금 만든 글이 실제로 보이지 않을 수 있다. 그래서 성공 기준은 더 구체적이어야 한다.

• 개별 글 URL이 200을 반환하는가
• 해당 HTML에 제목과 slug가 실제로 들어 있는가
• 홈 카드에 노출되는가
• 카테고리 페이지와 RSS에도 들어갔는가
• 썸네일과 댓글 영역이 깨지지 않았는가

이런 검증은 사람이 매번 손으로 할 필요는 없다. 하지만 무엇을 검증해야 하는지는 사람이 설계해야 한다.

세 번째 지점은 독자 경험이다.

자동화 도구의 이름, 내부 파일명, 복구 과정이 그대로 제목과 썸네일에 올라오면 독자는 글의 의미를 오해할 수 있다. 내부 디버깅 기록으로는 정확한 표현도 공개 글에서는 불안한 인상을 줄 수 있다. 같은 사건도 “에이전트 글쓰기에서 사람이 검증해야 할 지점”으로 재구성하면 실험의 의미가 살아난다.

Human-in-the-loop는 마지막 승인 버튼이 아니다

Human-in-the-loop를 단순히 “마지막에 사람이 승인한다”로 이해하면 부족하다. 이 실험에서 사람의 역할은 더 앞쪽과 중간에 있었다.

사람은 다음을 정한다.

1. 어떤 글감이 블로그에 올릴 가치가 있는지
2. 글이 내부 운영 기록인지, 독자를 위한 해석인지
3. 어떤 검증 기준을 통과해야 발행 완료로 볼지
4. 자동화 실패를 다음 Skill 규칙으로 어떻게 바꿀지

즉, 사람은 버튼을 누르는 승인자가 아니라 판단 기준을 설계하는 사람이다. 에이전트는 그 기준을 실행하고, 실패하면 수정할 후보를 가져온다. 좋은 자동화는 사람을 제거하는 것이 아니라, 사람이 개입해야 할 지점을 더 선명하게 만든다.

이번 실험의 결론

Hermes Blog Skill 실험의 의미는 “블로그를 완전 자동화했다”가 아니다. 더 정확히는 다음에 가깝다.

반복 운영은 에이전트에게 맡길 수 있다.
하지만 글의 관점, 독자 인상, 검증 기준은 사람이 설계해야 한다.

에이전트 글쓰기는 초안을 빠르게 만들고, 운영 절차를 안정화하고, 발행 루프를 짧게 만든다. 대신 사람이 할 일은 사라지지 않는다. 사람의 일은 문장을 직접 다듬는 것에서, 기준을 세우고 결과를 검토하고 실패를 규칙으로 바꾸는 쪽으로 이동한다.

이 블로그에서 계속 실험하려는 것도 바로 그 지점이다. AI agent를 단순한 글쓰기 도구로 쓰는 것이 아니라, 지식 작업의 반복 루프를 어디까지 맡길 수 있는지, 그리고 어디서 사람의 판단이 필요한지 기록하는 것. Hermes Blog Skill은 그 실험의 한 단계다.