예약해 둔 글 4편이 하나도 안 올라갔다 — 매번 '성공'이라던 자동 발행의 함정 (클로드 코드 사고 수습 일지 #1)

나는 개발자가 아니다. 그런데 이 블로그의 “예약 발행” 기능은 내가 클로드 코드(Claude Code)와 함께 만들었다. 글을 써 두고 공개 시각만 정해 두면, 그 시각에 알아서 블로그에 올라가는 기능이다.

그 기능이 사흘 동안 글을 한 편도 올리지 못했다. 더 황당한 건 따로 있었다. 그동안 자동 발행 프로그램의 실행 기록에는 매번 “성공”이 찍혀 있었다.

이 연재는 클로드 코드를 쓰다 생긴 사고를 하나씩 기록하고, 어떻게 고쳤는지 남기는 일지다. 첫 번째 사고부터 적는다.

사고 개요

항목	내용
언제	10월 6일(화) 아침 ~ 10월 9일(금) 오후
무엇이	예약해 둔 글 4편이 정해진 시각에 공개되지 않음
피해	4편 모두 최대 사흘 늦게 공개
발견	내가 블로그를 열어 보고 알았다. 자동 점검은 아무것도 알려 주지 않았다

이상한 점: 글이 없는데, 기록은 “성공”

트렌드 책을 한 편씩 읽는 연재를 쓰고 있었다. 화요일, 수요일, 목요일 아침 7시와 목요일 저녁 7시에 한 편씩 올라가도록 예약해 두었다.

금요일에 블로그를 열어 보니 연재가 첫 편에서 멈춰 있었다. 예약한 글의 주소를 직접 열어 보면 “페이지를 찾을 수 없습니다”가 떴다.

클로드 코드에게 확인을 부탁했다. 돌아온 답은 이랬다. 예약 발행 점검은 그동안 열네 번 실행됐고, 열네 번 모두 성공이었다. 고장 난 곳은 없었다. 그런데 글은 하나도 올라가지 않았다.

기록만 보면 아무 문제가 없었다. 성공을 뜻하는 초록 체크가 줄줄이 찍혀 있는데, 정작 해야 할 일은 하나도 안 된 상태였다.

원인: “정각 지나 75분 안”에만 우체통을 봤다

비유로 먼저 설명하면 이렇다.

우체통에 편지를 넣어 두면, 수거 기사가 매시간 들러 가져가기로 약속했다. 그리고 규칙을 하나 정했다. “수거 시각이 지난 지 75분 안에 들른 경우에만 편지를 가져간다.” 매시간 들르니 75분이면 넉넉하다고 생각한 것이다.

그런데 기사가 약속대로 오지 않았다. 매시간이 아니라 하루 너댓 번, 그것도 네 시간에서 길게는 여덟 시간 간격으로 왔다. 늦게 온 기사는 규칙대로 “75분이 지났네, 내 일 아님” 하고 빈손으로 돌아갔다. 그리고 수거 일지에는 “오늘 일 끝, 이상 없음”이라고 적었다.

실제 기록을 맞춰 보면 그대로다.

예약 시각	그다음 점검이 실제로 돈 시각	늦은 시간
화 07:00	화 09:45	2시간 45분
수 07:00	수 09:37	2시간 37분
목 07:00	목 10:51	3시간 51분
목 19:00	금 01:24	6시간 24분

모두 75분을 훌쩍 넘겼다. 점검은 매번 “지금 올릴 글 없음”이라고 판단했고, 그 판단을 정상적으로 마쳤으니 “성공”이었다.

조금만 기술적으로 말하면, 이 점검은 깃허브(GitHub)라는 서비스의 예약 실행 기능으로 돌린다. 매시간 돌도록 적어 두었지만, 깃허브는 사용자가 몰리는 시간에 예약 실행을 늦추거나 건너뛸 수 있다고 안내한다. 나는 “매시간”을 약속으로 믿었고, 실제로는 “되도록 매시간”이었다.

해결: “시간”이 아니라 “결과”를 보게 바꿨다

고친 것은 판단 기준 하나다.

• 전: 공개 시각이 지난 지 75분 안인 글이 있으면 → 블로그를 다시 만든다
• 후: 공개 시각이 지났는데 블로그에 실제로 없는 글이 있으면 → 블로그를 다시 만든다

우체통으로 말하면 “75분 안에 왔을 때만”이 아니라 “우체통에 편지가 남아 있으면 가져간다”로 바꾼 것이다. 이제 점검이 몇 시간 늦게 돌아도, 그다음 점검에서 빠진 글을 찾아 올린다.

고친 점검을 처음 돌리자 빠진 글 다섯 편(사고 기간 4편 + 그날 아침 예약분 1편)을 정확히 찾아냈고, 몇 분 뒤 모두 공개됐다. 글에 보이는 날짜는 원래 예약 시각 그대로 두었다.

재발 방지: 기록 말고 결과를 확인한다

이번 일로 바꾼 습관이 두 가지 있다.

1. “성공”을 믿지 말고 결과를 연다. 예약 기능을 처음 만들었을 때 나는 “블로그를 다시 만드는 신호가 잘 가는지”만 시험했다. 신호는 잘 갔다. 그런데 “예약한 글이 그 시각에 실제로 열리는지”는 시험하지 않았다. 이제 새 자동화를 만들면 마지막 결과물을 직접 열어 보는 것까지를 시험으로 친다.
2. 늦게 돌아도 괜찮게 만든다. 자동으로 도는 일은 언젠가 늦게 돈다. 그래서 “정해진 시각에 돌아야만 맞는” 규칙보다, “언제 돌든 지금 상태를 보고 할 일을 찾는” 규칙이 튼튼하다.

클로드에게 이렇게 말하면 된다

비슷한 자동화를 만들고 있다면 아래 문장을 그대로 써 봐도 좋다.

이 자동 작업이 정해진 시각보다 몇 시간 늦게 실행되거나 한 번 건너뛰어도 결과가 맞게 나오는지 확인해 줘. 시간 범위로 판단하는 부분이 있으면, 실제 결과(예: 페이지가 열리는지)를 확인하는 방식으로 바꿔 줘.

이 자동 작업이 “성공”이라고 끝났을 때, 실제로 해야 할 일을 했는지 확인할 방법을 하나 더 만들어 줘.

해 보니 알게 된 것

솔직히 말하면 지금 방식도 정시 발행은 아니다. 깃허브가 점검을 늦게 돌리면 글도 그만큼 늦게 올라간다. 다만 이제는 늦을 뿐 빠지지는 않는다. 정각에 꼭 올려야 하는 글이 생기면 다른 예약 방법을 붙여야 한다.

AI와 무언가를 만들면 “다 됐습니다”라는 말을 자주 듣는다. 그 말이 틀린 건 아니었다. 시킨 대로 다 됐다. 문제는 내가 시킨 것과 내가 바란 것이 조금 달랐다는 데 있었다. 나는 “정각 근처에 신호를 보내라”고 시켰고, 바란 것은 “예약한 글이 빠짐없이 올라가는 것”이었다. 앞으로는 바라는 결과를 말하고, 그 결과를 확인하는 방법까지 같이 정하기로 했다.

다음 사고 일지에서는 같은 날 발견한 또 하나의 작은 사고, 굵은 글씨가 깨져 별표(**)가 그대로 보이던 일을 적는다.