저는 헤르메스 에이전트로 원고를 정리하고, WordPress 초안까지 발행하는 흐름을 사용하고 있습니다. 그런데 글을 다 쓴 뒤 발행하려고 하면 늘 같은 문제가 남았습니다. 예전에 쓴 글 가운데 지금 원고와 연결할 만한 글이 있어도, 제목이 바로 떠오르지 않거나 검색에서 잘 보이지 않아 본문에 넣지 못하는 경우입니다.
이 문제를 AI에게 글을 한 편 더 써 달라고 하는 방식만으로 풀기는 어렵습니다. 완성된 원고를 발행할 때 필요한 것은, 과거 글 전체를 다시 읽는 일이 아니라 지금 글과 실제로 이어질 만한 글을 찾는 일입니다.
이 작업을 한 세 가지 이유
- 완성된 글의 본문을 더 충실하게 만들기 위해서입니다. 헤르메스 에이전트로 작성한 원고를 WordPress에 발행할 때, 지금 설명에 꼭 필요한 기존 글이 있다면 본문 문맥 안에 자연스럽게 넣고 싶었습니다.
- 이미 쓴 글을 다시 읽는 흐름으로 연결하기 위해서입니다. 새 글에서 이전 글을 연결하면 독자는 자신의 문제에 맞는 다음 자료로 이동할 수 있고, 오래된 글도 다시 읽힐 이유가 생깁니다.
- 매번 전체 블로그를 다시 검색하지 않기 위해서입니다. 필요한 후보만 빠르게 찾아 읽으면 되므로, 발행 과정에서 같은 탐색을 반복하지 않아도 됩니다.
그래서 이번에 헤르메스 에이전트에게 가장 먼저 맡긴 일은 원고 작성이 아니었습니다. 기존 블로그를 다음 글이 다시 찾을 수 있는 자료로 만드는 일이었습니다.
먼저 해야 할 일은 글쓰기보다 블로그를 읽을 수 있게 만드는 일입니다
현재 공개된 sshong.com 글 483개를 읽기 전용으로 수집했습니다. 제목, 실제 URL, 카테고리와 태그, 본문, 기존 내부 링크를 따로 저장했습니다. 여기서 중요한 것은 URL을 추측하지 않고 WordPress가 실제로 반환하는 주소를 그대로 정본으로 삼았다는 점입니다.
그다음 헤르메스 에이전트는 세 가지 검색 준비를 했습니다. 제목과 고유명사를 정확히 찾는 단어 검색, 표현이 달라도 비슷한 주제를 찾는 의미 검색, 그리고 이미 어느 글이 어느 글을 가리키는지 보는 내부 링크 지도입니다.
마지막으로 공개 글 수와 데이터베이스 글 수가 같은지, 빈 본문이나 중복 URL은 없는지, 검색 후보가 자기 자신을 가리키지는 않는지 검증했습니다. 이번 동기화에서는 483개 글의 기존 검색 데이터를 그대로 재사용할 수 있었습니다. 새 글이나 수정 글만 다시 처리하면 되기 때문입니다.
즉, 이 방식은 프롬프트 하나를 길게 만든 결과가 아닙니다. 자료를 모으고, 찾을 기준을 만들고, 다시 써도 되는지 검증하는 선행 작업이 있었기 때문에 가능한 흐름입니다.
처음 구축은 SQLite 기반으로 시작하는 것을 가장 추천합니다
처음에는 SQLite 기반으로 시작하는 것을 가장 추천합니다. 이 작업도 SQLite로 구축했습니다. SQLite는 하나의 로컬 파일에 글 정보, 단어 검색용 색인, 의미 검색용 데이터, 기존 내부 링크 관계를 함께 보관할 수 있습니다. 별도 서버를 계속 관리하지 않아도 되고, 파일 하나를 백업하면 기본 데이터를 함께 보존할 수 있습니다. 글이 약 2,000개 수준으로 늘어나도 이 출발점은 충분히 실용적입니다.
이 로컬 데이터베이스는 WordPress를 대신하지 않습니다. WordPress는 실제 원문과 공개 URL의 정본이고, SQLite는 새 글과 연결할 후보를 빠르게 찾는 읽기 전용 검색 사본입니다. 원문을 수정하지 않은 채 검색과 비교에만 쓰므로 역할이 섞이지 않습니다.
헤르메스 에이전트에서는 이 SQLite 파일을 로컬에 저장해 둡니다. WordPress 발행을 요청받으면 블로그 발행 스킬이 원고를 바로 쓰기 전에 이 파일을 먼저 사용합니다. 새 글과 수정 글만 동기화한 뒤, 저장된 단어 검색과 의미 검색 결과에서 후보를 좁히는 방식입니다. 그래서 매번 블로그 전체 내용을 프롬프트에 넣을 필요가 없습니다.
사용 전에 먼저 확인할 다섯 가지가 있습니다
| 확인할 것 | 왜 필요한가 |
|---|---|
| 공개 글의 범위 | 현재 데이터베이스에는 WordPress 공개 글만 들어갑니다. 비공개 글·임시저장 글·삭제 글은 별도 인증이나 백업이 없으면 찾을 수 없습니다. |
| 실제 URL | 과거 규칙으로 주소를 만들어 쓰지 않습니다. WordPress의 실제 link 값을 저장해야 잘못된 링크를 막을 수 있습니다. |
| 읽기 전용 수집 | 처음에는 기존 글을 수정하지 않고 수집·색인만 합니다. 링크를 한꺼번에 자동 삽입하면 오래된 정보나 중복 글까지 연결될 수 있습니다. |
| 증분 동기화 | 새 글을 쓰기 전에는 새 글·수정 글만 반영합니다. 매번 전체 글을 다시 읽거나 모든 임베딩을 다시 만들 필요가 없습니다. |
| 사람의 최종 판단 | 검색 결과는 후보입니다. 문맥, 최신성, 독자가 다음에 읽을 이유는 사람이 마지막으로 확인합니다. |
옵시디언을 코워크와 헤르메스 에이전트가 함께 사용하면 좋은 점 세 가지에서 설명한 것처럼, 작업 결과가 한곳에 남아 있어야 다음 작업이 그 위에서 시작할 수 있습니다. 블로그 글도 마찬가지입니다. 발행된 글을 단순한 과거 기록으로 두지 않고, 다음 글이 찾을 수 있는 자료로 바꾸는 일입니다.
완성된 글을 발행할 때, 관련 글을 본문에 연결합니다
실제 사용 순서는 단순합니다.
- 헤르메스 에이전트로 새 원고의 제목과 본문을 완성합니다.
- 블로그 발행 스킬이 로컬 SQLite 데이터베이스를 증분 동기화합니다.
- 완성된 원고를 기준으로 관련 글 후보를 찾습니다.
- 그중 실제로 연결할 가능성이 있는 글만 본문까지 읽습니다.
- 지금 문장을 이해하는 데 필요한 기존 글은 본문 문맥 링크로 넣고, 본문에서 쓰지 않은 글만 하단 관련 자료로 검토합니다.
- WordPress 초안에서 제목·메타 설명·카테고리·태그·대표 이미지와 링크 중복을 다시 확인합니다.
단어가 같은 글만 찾는 것은 아닙니다. 예를 들어 ‘AI 에이전트’, ‘블로그 발행’, ‘내부 링크’처럼 표현이 달라도 작업 흐름과 독자 문제가 비슷한 글을 함께 살핍니다. 반대로 오래된 글이라고 해서 무조건 다시 연결하지도 않습니다. 내용이 낡았거나 새 글과 검색 의도가 거의 같다면, 링크를 더하는 대신 두 글의 역할부터 다시 봐야 합니다.
이전에는 글쓰기, 이미지 만들기, 발행 준비가 각각 따로 움직였습니다. 클로드 코드로 블로그 자동화 워크플로우를 만들었습니다에서 다뤘던 것처럼, 여러 단계를 연결하면 작업은 한 번의 요청에서 이어질 수 있습니다. 이번에는 그 흐름에 ‘과거 글 찾기와 연결’ 단계를 추가했습니다.
오래된 글은 검색 순위가 아니라 읽는 흐름 속에서 다시 살아납니다
블로그에 글이 쌓이면 오래된 글은 검색 결과에서 밀릴 수 있습니다. 그렇다고 가치가 사라지는 것은 아닙니다. 새 글에서 그 글이 필요한 이유를 만들어 주면, 독자는 검색이 아니라 읽는 흐름을 따라 과거 글로 이동합니다.
이번에 만든 데이터베이스에서는 다른 글에서 한 번도 연결되지 않은 글도 따로 살펴볼 수 있습니다. 다만 이 목록은 ‘지금 당장 링크해야 할 글’이 아닙니다. 새 글과 실제로 이어질 때만 다시 연결합니다.
블로그를 계속 운영한다는 것은 새 글의 수를 늘리는 일만은 아닙니다. 이미 쓴 글이 다음 글과 어떤 관계를 맺는지 계속 정리하는 일에 가깝습니다. 이제는 AI 에이전트에게 글 한 편을 맡길 때, 원고 작성과 발행 준비뿐 아니라 이전 글을 찾고 연결하는 일까지 함께 맡길 수 있습니다.
함께 보면 좋은 자료
함께 읽으면 좋은 글
- AI 블로그 원고 프롬프트, 실전용 템플릿 공개 — 원고를 만드는 프롬프트에서 한 걸음 더 나아가, 발행 뒤의 검색과 연결까지 생각해 볼 수 있습니다.
책 추천
- 팔리는 블로그 & SNS 글쓰기 with 챗GPT — 원고 작성에서 발행과 채널 운영까지 이어지는 기준을 더 살펴보고 싶은 독자에게 연결되는 책입니다.
강의 추천
- 옵시디언 + 코워크(초급+) — 내 AI 작업 환경 구축 — 옵시디언에 기록을 남기고 코워크를 연결해, 자료·글·강의 결과가 다시 쓰이는 작업 환경을 직접 만드는 워크숍입니다.
