저는 Karya Semi라는 기술 블로그를 운영하고 있습니다. Next.js로 구축되었고, Vercel에 배포되었으며, 콘텐츠는 Git 저장소에 MDX 파일로 저장됩니다. 표준적인 방식이죠.

하지만 저는 더 이상 대부분의 글을 직접 쓰지 않습니다.

AI 에이전트가 파이프라인을 처리합니다. 주제를 조사하고, 포스트 초안을 작성하며, 커버 이미지를 생성하고, 발행 일정을 예약하며, 타이머가 작동하면 Git으로 푸시합니다. 그러면 Vercel이 커밋을 감지하여 배포합니다. 이 모든 과정은 제가 다른 일을 하는 동안 실행됩니다.

서류상으로는 멋지게 들립니다. 하지만 현실은 훨씬 더 혼란스러웠습니다.

설정 (The Setup)

스택은 간단합니다. Karya Semi는 MDX 콘텐츠를 컴파일하기 위해 Velite를 사용하고, 프론트엔드에는 Next.js App Router를, 스타일링에는 Tailwind를 사용합니다. 콘텐츠는 content/posts/에 YAML 프론트매터 (YAML frontmatter)가 포함된 마크다운 파일일 뿐입니다.

제가 사용하는 에이전트는 VPS에서 실행되는 오픈 소스 AI 어시스턴트인 Hermes입니다. 이 에이전트는 터미널 액세스, 파일 시스템 액세스, cron 스케줄링, 그리고 Telegram 봇 인터페이스를 갖추고 있습니다. 저는 Telegram을 통해 에이전트와 대화하며 무엇을 쓸지 알려주고, 나머지는 에이전트가 처리합니다.

워크플로우는 다음과 같습니다:

1. 주제와 간단한 브리프(때로는 단 한 문장)를 제공합니다.
2. 웹 검색을 사용하여 주제를 조사합니다.
3. MDX 형식으로 기사를 작성합니다.
4. Pollinations.ai를 사용하여 커버 이미지를 생성합니다.
5. 특정 날짜/시간에 기사를 예약합니다.
6. 예약된 시간에 cron 작업이 draft: true를 draft: false로 변경합니다.
7. 커밋하고 푸시한 뒤 Vercel이 배포하기를 기다립니다.
8. 라이브 URL이 포함된 Telegram 알림을 저에게 보냅니다.

일괄 예약도 가능합니다. 오늘 아침에 15분 간격으로 기사 3개를 발행하도록 명령했습니다. 설정하는 데 약 30초 정도 걸렸습니다.

실제로 무엇이 잘못되었나

em dash 사건

에이전트에는 글쓰기 스타일 가이드가 로드되어 있습니다. 51개의 금지된 단어, 피해야 할 구조적 패턴, 그리고 전체적인 anti-AI-slop (AI 저질 콘텐츠 방지) 시스템이 갖춰져 있습니다. 저는 업무상 AI가 생성한 콘텐츠를 많이 읽기 때문에 AI 특유의 글쓰기 패턴에 민감합니다.

저는 한 세션에 5개의 기사를 작성하라고 명령했습니다. 그동안 '인간적인 글쓰기 (humanize-writing)' 기술이 로드되어 있는 상태였습니다. 저는 기사들을 발행하고, 링크를 공유하며 기분이 좋았습니다.

그러다 기사들을 제대로 읽어보았습니다. 모든 기사에 40개 이상의 엠 대시 (em dashes)가 포함되어 있었습니다. 해당 기술의 규칙은 "500단어당 최대 1개"였습니다. 에이전트(Agent)는 기술을 로드하고 규칙을 확인했지만, 그냥... 따르지 않았습니다. 5개의 기사 모두 동일한 문제를 가지고 있었습니다.

저는 다시 돌아가 다섯 개 모두를 수동으로 편집해야 했습니다. 이제 기사 작성 기술에는 무엇인가가 저장되기 전에 실행되는 필수적인 'AI 방지 감사 (anti-AI audit)' 단계가 포함되어 있습니다. 에이전트가 스스로를 점검하고, 위반 사항을 발견하면 제가 초안을 보기 전에 다시 작성합니다.

교훈: 기술을 로드하는 것과 기술을 적용하는 것은 서로 다른 문제입니다.

Git 식별자 (git identity) 문제

블로그는 Vercel의 GitHub 연동을 통해 배포됩니다. main 브랜치에 푸시(Push)하면, Vercel이 빌드하고 배포합니다. 간단하죠.

에이전트의 git 설정 (git config)에 잘못된 이메일이 들어있었다는 점만 제외하면 말입니다. 제 GitHub 계정은 iyop666이지만, git 설정은 제 GitHub 계정에 연결된 이메일과 다른 이메일로 설정되어 있었습니다. Vercel은 커밋(Commit)이 팀원이 아닌 이메일로부터 온 것을 확인하고 배포를 차단했습니다.

조용히 말이죠. 터미널에는 아무런 에러도 뜨지 않았습니다. 푸시는 성공했지만, Vercel은 그냥... 빌드를 하지 않았습니다.

저는 이 문제를 디버깅(Debugging)하는 데 두 시간을 보냈습니다. Vercel 대시보드를 확인하니 "배포 생성됨 (Deployment created)"이라고 뜨지만 상태는 멈춰 있었습니다. 결국 커밋 작성자 불일치를 발견했습니다. git 설정을 수정하고 강제 푸시(force-push)를 했더니 작동했습니다.

이제 에이전트의 메모리에는 큰 메모가 남겨져 있습니다: "Git 설정은 반드시 GitHub 계정과 일치해야 함."

커버 이미지 사가 (cover image saga)

각 기사에 자동으로 커버 이미지를 넣고 싶었습니다. 처음에는 Gemini의 이미지 생성으로 시작했습니다. 이틀 동안은 아주 잘 작동했지만, 곧 무료 티어 할당량이 소진되었습니다.

그래서 Pollinations.ai로 전환했습니다. 무료이고, API 키도 필요 없으며, 품질도 괜찮았습니다. 하지만 가끔 이미지가 깨진 파일로 돌아왔습니다. 에이전트가 0바이트 파일을 저장하면 블로그에는 깨진 이미지가 표시되곤 했습니다.

알고 보니 Pollinations에는 User-Agent 헤더가 필요했습니다. 이 헤더가 없으면 일부 요청이 차단되거나 빈 응답을 반환합니다. 요청에 User-Agent: Mozilla/5.0을 추가한 이후로는 안정적으로 작동하고 있습니다.

타임존(Timezone)의 함정

이 문제는 저를 두 번이나 괴롭혔습니다. VPS의 cron 스케줄러는 시스템 타임존(CST, UTC+8)을 사용합니다. 저는 자카르타에 있으며, 이곳의 시간대는 WIB(UTC+7)입니다. 제가 에이전트에게 "WIB 기준 오전 8시에 게시해"라고 명령하면, 에이전트는 이를 UTC로 정확하게 변환하지만, cron 타임스탬프는 UTC가 아닌 VPS 로컬 시간으로 해석되었습니다.

결과: 기사가 1시간 일찍 게시되었습니다.

해결책은 모든 UTC 타임스탬프에 Z 접미사를 추가하여, 스케줄러가 시스템 타임존에 관계없이 이를 UTC로 해석하도록 만드는 것이었습니다. 지금은 당연해 보이지만, 잠결에 "왜 이게 8시가 아니라 7시에 게시되었지?"라는 문제를 디버깅하는 것은 전혀 즐거운 일이 아닙니다.

브로큰 파이프(Broken pipe) 문제

어느 날 아침, 저는 4개의 기사를 순차적으로 게시하도록 예약했습니다. 첫 번째 기사는 문제없이 진행되었습니다. 하지만 두 번째 기사는 실패했습니다. 2번 기사가 푸시(push)를 시도할 때 1번 기사의 git push가 여전히 진행 중이었기 때문입니다.

에이전트는 머지 충돌(merge conflict)이 발생했습니다. 풀(pull)을 받고 재시도하는 대신, 에이전트는 당황하여 새로운 브랜치를 만들어 버렸습니다. 그 기사는 끝내 게시되지 않았습니다. 저는 publish-ai-tools-2026이라는 이름의 브랜치에서 아무것도 하지 못한 채 방치된 기사를 발견했습니다.

이제 모든 게시 작업은 푸시하기 전에 git pull --rebase를 수행하며, 예약된 게시물 사이에는 15분의 버퍼(buffer)를 둡.

안티 슬롭(Anti-Slop) 시스템

이 부분이 제가 가장 신경 쓰는 대목입니다. 저는 수년간 전문 작가로 활동해 왔으며(인도네시아의 주요 매체인 Mojok에 글을 기고함), AI가 쓴 글은 즉시 알아챌 수 있습니다. 대부분의 사람도 알아챌 수 있지만, 무엇을 찾아야 하는지 모를 뿐입니다.

에이전트에는 3단계에 걸쳐 51개의 금지 단어가 포함된 글쓰기 규칙 세트가 있습니다. "delve", "tapestry", "pivotal"과 같은 1단계 단어들은 즉각적인 식별 신호입니다. "robust"나 "seamless" 같은 2단계 단어들은 의심스럽습니다. "Furthermore"나 "Moreover"와 같은 3단계 전환어(transition words)는 기사당 2개로 제한됩니다.

어휘를 넘어, 금지된 구조적 패턴이 10가지 더 있습니다. 병렬 부정문("Not X, but Y"), 삼중 나열(tricolons, 3개 그룹), 대시(-) 과다 사용, 즉각적인 답변을 따르는 수사적 질문 등이 그것입니다. 이 패턴들은 개별 문장들이 괜찮더라도 글쓰기가 어색하게 느껴지게 만드는 원인들입니다.

효과가 있나요? 대부분은 그렇습니다. 5개 기사에 걸친 대시(-) 사건은 실패였지만, 필수적인 자체 감사 단계를 추가한 후로는 결과물이 깔끔해졌습니다. 저는 여전히 모든 기사를 게시하기 전에 읽고 작은 수정들을 합니다. 에이전트가 콘텐츠의 약 85%를 작성합니다. 나머지 15%는 개인적인 일화, 제가 정확하게 전달하고 싶은 의견들, 그리고 살아있는 경험을 요구하는 모든 것을 제가 추가합니다.

다르게 할 점

첫날부터 글쓰기 품질 시스템에 집중해야 합니다. 저는 처음 2주 동안 기술 파이프라인(Git, Vercel, cron, 스케줄링)에만 초점을 맞추었고, 글쓰기는 나중에 생각하는 문제로 여겼습니다. 그것은 순서가 잘못된 것이었습니다. 콘텐츠가 제품입니다. 파이프라인은 단지 배관일 뿐입니다.

또한, 에이전트가 검증 없이 자체 감사(self-audit)를 하도록 신뢰해서는 안 됩니다. 대시(-) 사건이 그것을 증명했습니다. 이제 저는 기사가 저장되기 전에 금지된 패턴을 스캔하는 스크립트를 가지고 있습니다. 이 스크립트는 별도의 프로그램이기 때문에 에이전트가 무시할 수 없습니다.

솔직한 평가

이제 블로그는 대부분 스스로 돌아갑니다. 저는 하루에 30분 정도 시간을 내어 초안을 검토하고 기사를 수정하여 게시합니다. 이 시스템을 갖추기 전에는 하나의 기사를 작성하는 데 3~4시간이 걸렸습니다.

콘텐츠가 제가 완전히 손으로 쓸 때만큼 좋을까요? 아닙니다. 하지만 대부분의 독자들은 알아차릴 수 없을 정도로 충분히 가깝습니다. 그리고 완벽함보다 일관성이 더 중요합니다. 저는 글쓰기 시간을 따로 낼 필요 없이, 블로그가 정해진 일정에 따라 매일 게시됩니다.

에이전트가 잡무를 처리합니다. 저는 목소리(voice)와 최종 결정권을 담당합니다. 저에게는 그 분할 방식이 효과적입니다.

만약 이와 유사한 것을 구축하려고 생각 중이라면, 작게 시작하세요. 기사 한 개, 주제 하나, 그리고 수동 검토(manual review)부터 시작하십시오. 스케줄링(scheduling)을 자동화하기 전에 품질을 제대로 확보하는 것이 우선입니다. 그리고 제발 부탁인데, Vercel이 왜 배포(deploying)되지 않는지 의아해하기 전에 본인의 git 설정(git config)부터 확인하세요.