Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
Claude Code를 활용한 자동 콘텐츠 발행 시스템이 16일 동안 정상 작동 알림을 보냈으나, 실제로는 기사 내용물이 전혀 증가하지 않았습니다. 작성자는 프로세스 실행 여부와 실제 결과물 증가는 별개임을 깨달았으며, 자동화된 감시 장치에만 의존하는 것의 한계를 지적했습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기홈페이지 기사가 10월 2일부터 16일 동안 단 한 개도 늘지 않았습니다. 매주 금요일에 자동으로 2개의 글을 작성하여 공개하는 시스템을 가동하고 있었는데, 이 시스템은 매번 '끝났습니다'라고 응답했습니다.
k베이(神戸)에서 중고 컴퓨터를 수리하여 대여하고 있습니다. 기사를 쓸 시간이 부족해서, 주 2회 업데이트는 Claude Code가 담당하고 있습니다.
먼저 말씀드립니다. '프로세스가 실행되었는지'를 확인하는 점검은 '실제 내용물이 늘었는지'를 단 한 번도 확인하지 못했습니다.
나중에 계산해 본 결과가 이렇습니다.
| 언제 | 시스템 응답 | 실제로 증가한 기사 수 |
|---|---|---|
| 10월 2일 | 끝났습니다 | 2개 |
| ... | 0개 |
가장 좋지 않았던 기록은 10월 17일의 기록이었습니다. 종료 알림에는 다음과 같이 적혀 있었습니다.
✅ 기사를 작성하여 공개까지 완료되었습니다
그리고 같은 기록 속에는, 공개 도구가 반환한 한 줄도 남아있었습니다.
No updated asset files
업로드할 것이 없다고 쓰여 있습니다. '끝났다'는 알림과 '올릴 것이 없다'는 기록이 같은 주기 안에 나란히 놓여 있었습니다.
0개의 주가 이어졌는데도, 어디에서도 아무런 알림이 오지 않았습니다. 확인하는 시스템은 세 가지가 있었습니다.
글 개수 점검. 목표 숫자를 정리한 JSON에 주간 예상 글 개수가 적혀 있습니다.
시스템 건강 진단. 정해진 자동 약속이 19가지 있는데, 매번 작동 여부를 대조합니다.
금요일 프로세스 자체의 종료 알림. 끝까지 도달하면 결과를 한마디로 알려줍니다.
첫 번째는 조금 전에 예상치를 수평으로 수정했습니다. 늘지 않아도 지연이 되지 않도록 하는 방식입니다. 이것은 제가 직접 했습니다. 지연 표시가 사라져서, 고쳐진 것처럼 착각했던 것입니다.
두 번째는 로그 파일이 존재하는지 확인하고 있었습니다. 프로세스는 실행됩니다. 로그는 매주 생성됩니다. 그래서 문제없다고 응답했습니다.
세 번째는 마지막 줄까지 도달했는지 보고 있었습니다. 중간에 멈추지 않기 때문에, 도달합니다.
감시 장치들은 3가지 모두, 각자의 담당 범위 내에서는 올바르게 작동하고 있었습니다. 아무도 거짓말을 하지 않았는데, 전체적으로는 거짓이 되어 있었습니다. 여기가 가장 기분 나쁜 부분이었습니다.
숫자가 많을수록 안심된다고 생각했지만, 그 반대였습니다. 감시 장치가 하나라면, 그것이 무엇을 보고 있는지 기억합니다. 3개로 늘어나면, '어딘가에서 지켜보고 있을 것'이라는 심리가 생깁니다. 실제로는 세 가지 모두 같은 측면(실행 여부)만 보고 있었고, 반대편(증가 여부)에는 아무도 서 있지 않았습니다. 겹치는 부분을 그대로 늘렸기 때문에, 보지 못하는 범위는 처음부터 끝까지 크기가 같았습니다.
매주 결과는 스마트폰으로 한 통씩 도착하도록 했습니다. 16일 동안 그 알림은 매번 '끝났습니다'였습니다.
저는 그것을 건너뛰었습니다. 나쁜 소식이라면 눈에 띄지만, 예정대로라는 소식은 읽지 않고 지우는 것이 습관이 되어 있었기 때문입니다. 알림의 가치는 내용물이 아니라 '평소와 다른가'로 결정됩니다. 매번 같은 문구가 오는 알림은 세 번째부터 알림이 아니게 됩니다.
결국, 깨달은 것은 직접 사이트를 열어 기사 목록을 봤을 때였습니다. 나열된 가장 최신 기사의 날짜가 반 달 전 그대로였습니다. 자동화 감시를 사람이 눈으로 검수하여 발견한 것이라서 순서가 역전되었습니다. 그것으로 괜찮다면, 감시는 필요 없습니다.
원인 자체는 기술적인 이야기가 아니었습니다.
기사 주제를 나열한 예정표가 있었는데, 쓸 수 있는 줄이 다 소진된 것입니다. 남아있는 줄들은 '시세를 재조정한 후에', '해가 밝은 후에'와 같은 날짜 대기물들뿐이라 그 주에는 쓸 수 없습니다.
그것을 읽은 쪽에서는 올바르게 판단했습니다. 쓸 수 없는 것은 쓰지 않습니다. 그리고 아무것도 쓰지 않고, 남은 프로세스를 전부 통과시킨 것입니다. 정리하고, 점검하고, 공개하고, 끝났습니다라고 응답합니다. 어떤 프로세스도 입력이 0개일 때 어떻게 할지 결정하지 못했습니다.
0을 받으면, 0을 올바르게 처리하여 정상 종료하는 것. 이것은 도구로서는 올바른 동작입니다.
그래서 여기서 고칠 대상을 잘못하면 시간을 낭비합니다. 저는 처음에는 기사를 작성하는 쪽의 지시문을 의심했습니다. 쓸 수 없었으니, 작성 방식이 나쁜 것이 아닐까 하고요. 다시 읽어봐도 이상한 곳은 없습니다. 쓸 수 없는 이유까지 제대로 기록으로 남아 있었습니다.
즉, 고장 난 것은 글을 쓰는 쪽이 아니라, 끝났다고 알리는 쪽이었습니다. 0개라는 사실은 애초부터 기록 안에 있었습니다. 그것을 가져와서 외부에 보여주는 메커니즘만 어디에도 없었던 것입니다.
수정 방법은 한 군데입니다. 글을 쓰기 전과 공개 직전에, 기사 폴더의 개수를 세었습니다.
# 쓰기 전에 카운트하기
$blogDir = Join-Path (Join-Path $root "website") "blog"
$script:blogBefore = @(Get-ChildItem -Path $blogDir -Directory -ErrorAction SilentlyContinue).Count
...
공개 직전에 다시 카운트하여 비교합니다.
$blogAfter = @(Get-ChildItem -Path $blogDir -Directory -ErrorAction SilentlyContinue).Count
if ($blogAfter -le $script:blogBefore) {
Finish $true ("⚠️ 공개까지 통과했지만, 홈페이지의 새 기사는 0개입니다({0}개 그대로입니다). 기사 캘린더에 적을 수 있는 행이 있는지 확인해 주세요" -f $blogAfter)
...
마지막 줄의 숫자가 핵심입니다. 알림이 '18개 → 20개'와 같은 형태가 되었기 때문에, 0개의 주에는 알림 문구 자체가 바뀝니다. (원문에서 인 표시 부분은 실제로는 이모지가 들어갑니다.)
건강 검진 쪽도 수정했습니다. 기사의 신선도를 보는 것을 중단하고, '공정이 실행되었는지'만 담당하도록 했습니다. 같은 내용을 두 곳에서 보면, 어느 쪽이 상대방을 감시하는 것처럼 느껴지기 때문입니다. 신선도는 본수 확인이 한 곳에서 맡습니다.
일정표 쪽에도 한 줄을 추가했습니다. 적을 수 있는 행이 2개 부족할 때는, 다음 교체가 오기를 기다리지 않고, 회사 자체 사례에서 행을 추가하여 작성합니다. 이것이 없으면, 다음 달에 또 같은 주가 옵니다.
수정은 10월 18일에 이루어졌습니다. 그다음 금요일인 10월 23일 회차에 기사는 18개에서 20개가 되었고, 알림 끝부분에도 그 숫자가 들어갔습니다.
아직 수정되지 않은 부분을 먼저 말씀드리겠습니다. 일정표가 바닥나는 근본적인 원인은 아직 남아 있습니다. 주제를 생각하는 것은 사람의 영역이라, 자동으로 늘어나는 메커니즘은 없습니다. 지금은 '바닥나면 사례에서 채운다'는 규칙으로 버티고 있는 상태입니다.
또 하나 더. 본수 확인 기준을 저는 언제든지 수정할 수 있습니다. 수평을 맞추면, 다시 🔴 표시는 사라집니다. 사라지게 할 것을 사라지지 않게 하는 방법은 아직 찾지 못했습니다.
Claude Code에 매일 업무를 맡기고 있다면, 같은 구멍이 뚫렸는지 여부는 그 자리에서 확인할 수 있습니다. 질문은 하나입니다.
지금, 그 메커니즘의 종료 알림이 '실행되었다'고 말하고 있습니까? 아니면 '몇 개가 만들어졌다'고 말하고 있습니까?
단순히 실행되었다는 알림은 입력이 0일 때 침묵합니다. 숫자로 말하는 알림은, 0일 때 저절로 눈에 띕니다. 수정 방법은 어떤 언어에서도 같은 형태가 됩니다.
위험한 것은 도중에 에러를 내지 않는 업무입니다. 매일 아침 기사 초안을 만들게 하거나, 받은 문의를 정리하게 하거나, 회의록에서 숙제를 뽑아내게 하는 것 모두 마찬가지입니다. 재료가 0건일 때 깔끔하게 0건으로 처리하고 끝납니다. 에러로 다운되는 업무 쪽이 훨씬 안전합니다.
before=$(ls -1 out/ | wc -l)
# …자동화 본체…
after=$(ls -1 out/ | wc -l)
...
3줄입니다. 이것을 넣어두면, 16일간의 침묵은 막을 수 있습니다.
숫자를 내보내는 알림에는 추가적인 장점이 붙습니다. 늘어난 숫자를 매번 받게 되면, '이번 주는 1개였다' 같은 약한 이상에도 알아챌 수 있습니다. 0 아니면 1로 끝내는 메커니즘보다, 숫자로 말하게 하는 것이 나중에 읽고 도움이 되었습니다.
다음으로는, 메커니즘이 이상을 감지하고 있었는데 그 알림을 아무도 열어보지 않는 곳에 적었던 회차를 쓰겠습니다.
감시를 늘릴 것인지, 알림 문구를 바꿀 것인지. 어느 쪽을 선택했는지에 대한 판단 이야기는 note에 올렸습니다.
실행되었냐가 아니라, 몇 개가 만들어졌느냐. 알림 문구만 바꿔도, 다음 주 자신의 인지 범위가 넓어집니다. 고장 난 쪽의 기록은 기술적인 이야기만 여기에 남기겠습니다. 팔로우해 주시면, 다음 1개가 도착합니다.
