AI 대화 기록으로 블로그 작성하기
AI 에이전트 생태계 구축기· 5 / 10
- 1 — 멋진 비서를 만들기 위한 뜬구름 시도 끝에, LLM Wiki부터 세웠다
- 2 — LLM Wiki를 지식 뇌로 쓰게 해주는 두 가지 자동화
- 3 — 지식 뇌와 연결한 첫 번째 비서 알림 기능
- 4 — 지식 뇌에 손발을 붙였다: LLM Wiki와 헤르메스 연결하기
- 5 — AI 대화 기록으로 블로그 작성하기
- 6 — AI 자동화와 사람의 판단을 잇는 우편함 만들기
- 7 — 텔레그램에서 슬랙으로 헤르메스 사무실 옮기기
- 8 — AI가 쓴 블로그에 필요한 이미지를 더한 방법
- 9 — 헤르메스로 자동화를 운영하며 접한 사소한 문제들
- 10 — AI 코딩 에이전트의 테스트 PASS를 그대로 믿을 수 있을까
블로그를 다시 쓰고 싶다는 마음은 늘 있었다. 다만 글 한 편을 제대로 쓰려면 생각보다 많은 시간과 공이 들었다. 매일 쓰겠다고 마음먹어도, 다른 일을 하며 그 시간을 계속 내기는 쉽지 않았다.
한편 나는 매일 같은 AI 에이전트와 대화하고 작업했다. 프로젝트를 만들고 문제를 고치고 결정을 내릴 때마다 당시의 맥락이 대화와 작업 기록 안에 남았지만, 세션이 끝나면 그대로 흘려보내기에는 아까웠다. 그 기록에서 맥락을 꺼내 블로그 글의 재료로 쓸 수 있다면, 내가 직접 처음부터 쓰지 않아도 내 작업을 계속 남길 수 있겠다고 생각했다.
그래서 한동안 거의 쓰지 않던 기존 블로그를 다시 정비하기로 했다. 예전 블로그를 그대로 되살리는 대신 지금 내가 쓰기 좋은 방식으로 리포지터리부터 새로 만들었다. 글의 분위기는 이어 가되, 앞으로 쌓일 기록을 관리하고 공개하기에 맞는 기술 구성과 규격을 다시 잡았다.
먼저 빈 블로그를 채워야 했다
새 블로그를 열 때 필요한 재료는 두 종류였다. 예전 글은 새 형식으로 옮기고, 이미 쌓여 있던 작업 기록은 첫 AI 작성 글의 재료로 썼다.
| 재료 | 내가 한 일 | 남긴 의미 |
|---|---|---|
| 예전 블로그 글 60여 편 | 본문 내용은 고치지 않고, 새 블로그의 제목·날짜·태그·목차 규격에 맞춰 옮겼다. | 비어 있던 새 블로그에 내가 써 온 기록을 다시 가져왔다. |
| Claude Code에 쌓인 프로젝트별 작업 기록 | 여러 프로젝트의 대화와 작업 기록을 한꺼번에 모아, 첫 AI 작성 글 여러 편의 재료로 삼았다. | 앞으로 어떤 기록에서 블로그 글이 나올지 처음으로 확인했다. |
여기서 AI에게 맡긴 일은 글을 멋대로 고치는 일이 아니었다. 예전 글을 옮길 때는 내용은 건드리지 않고 형식만 바꾼다는 범위를 먼저 정했다. 기준이 될 글 한 편을 직접 만든 뒤, 작은 묶음으로 시험하고, 그때 생긴 문제를 공통 지침에 반영한 다음 나머지 글로 넓혔다.
작업량이 많을수록 처음부터 전부 돌리는 것보다, 작은 결과를 먼저 보고 기준을 고치는 편이 나았다. 그래야 AI가 무엇을 해야 하는지뿐 아니라 무엇을 하지 말아야 하는지도 함께 정할 수 있었다.
형식이 맞아도 내 글처럼 읽히지는 않았다
예전 글을 옮긴 뒤, 작업 기록을 바탕으로 만든 첫 AI 초안 16편도 읽어 봤다. 형식은 맞았지만 어딘가 말이 길고, 코드가 많아 보였다. 이 느낌만으로 “산문을 줄이고 코드를 빼자”고 정하면 엉뚱한 곳을 고칠 수 있었다.
그래서 과거에 내가 직접 쓴 61편과 AI 초안을 비교했다. 코드 블록이 많아서 어색한 것이 아니라, 독자가 알 수 없는 내부 이름이 설명 없이 본문에 너무 많이 등장한 것이 문제였다.
| 편당 평균 | 과거에 직접 쓴 글 61편 | 첫 AI 초안 16편 |
|---|---|---|
| 목록으로 정리한 항목 | 9.6개 | 2.1개 |
| 설명 없이 등장한 내부 이름 | 10.8개 | 29.6개 |
예를 들어 내부 이름은 특정 함수나 변수처럼, 그 프로젝트를 열어 본 사람만 뜻을 아는 단어를 말한다. 코드 블록을 통째로 지우는 대신, 이런 이름은 역할을 말로 풀고 병렬 정보는 목록이나 표로 정리하는 쪽으로 글쓰기 기준을 고쳤다.
글이 많아지는 것과 내 글이 되는 것은 다른 일이었다. AI가 초안을 만들 수는 있어도, 어떤 글이 내가 읽고 싶은 방식인지까지는 별도로 확인해야 했다.
빌드가 끝난 뒤에야 실제로 블로그를 열 수 있었다
글과 사이트를 준비한 뒤에는 Cloudflare Pages에 새 블로그를 공개했다. Cloudflare Pages는 정적 사이트 파일을 인터넷에서 열 수 있게 배포하는 서비스다.
배포 중에는 26.4MB GIF 하나가 Cloudflare Pages의 파일당 제한인 25MiB를 넘어 전체 배포가 멈췄다. 해상도를 줄여 13MB로 낮춘 뒤 다시 올렸고, 사이트 화면이 기대한 결과와 맞는지 확인한 다음 공개를 확정했다.
처음에는 기록을 한꺼번에 꺼내 썼다
처음에는 Claude Code에 쌓여 있던 프로젝트별 기록을 한꺼번에 가져와 글을 만들었다. 이는 작업 맥락을 모아 필요할 때 다시 꺼내 쓰도록 만든 second의 기반을 블로그에도 적용한 사례였다. second는 작업하며 쌓인 맥락을 보관하고, 필요할 때 다시 꺼내 쓰려 만든 내 지식 뇌다.
내가 AI와 일하며 남긴 기록을 블로그로 바꿀 수 있다는 첫 방식을 여기서 확인했다. 블로그는 그 맥락을 다음 작업에만 쓰지 않고, 나중에 다시 읽을 글로도 꺼내 쓰는 곳이 됐다.
돌이켜보면 AI가 블로그를 다시 열어 준 것은 아니다. 반복되는 이관과 초안 작성은 AI가 빠르게 처리했지만, 무엇을 옮길지, 어떤 글이 내 글다운지, 실제로 공개됐는지는 내가 확인해야 했다. 그 구분을 처음 잡아 본 날이 이 글의 시작이었다.