작업 기간: 2026.10.30–10.30
블로그 글감 브리핑을 매일 05:30에 만들고 07:00에 텔레그램으로 받는 자동화를 AI와 함께 만들어 쓰고 있어요. 10월 23일 아침에는 브리핑 대신 오늘 05:30 생성 기록이 없다는 안내가 왔어요. 10월 30일에 AI에게 점검을 맡겼고, 저는 원인 설명을 듣고 무엇을 고칠지 정했어요.
이 글은 그럴듯한 원인을 내려놓고 시작 시각과 파일 시각을 다시 맞춰 본 기록이에요. AI가 처음 내놓은 원인을 무엇으로 다시 확인했는지, 그리고 멈춘 곳의 직접 증거가 없을 때 무엇부터 고치면 되는지에 답해 보려고 해요.
10월 23일에는 브리핑 대신 생성 기록 없음 안내가 갔어요
10월 30일, 저는 AI에게 브리핑과 자동 실행이 제대로 돌았는지 보고해 달라고 했어요. AI는 10월 22일부터 10월 30일까지 9일을 날짜별 표로 정리했어요. AI는 9일 중 8일이 정상이라고 정리했어요. 다만 10월 22일은 첫날이라 직접 돌린 실행이었고, 표에도 수동 실행 · 08:04 시험 발송으로 적혀 있었어요.
어긋난 날은 10월 23일 하루였어요. 07:00 발송 기록에는 오늘 05:30 생성 기록이 없다는 안내가 남아 있었고, 생성은 11:15에야 끝났어요. 그날 브리핑 파일은 만들어졌지만 텔레그램으로는 가지 않았어요.
AI가 근거로 본 기록은 세 가지였어요. 날짜별 생성 결과 파일과 Mac의 예약 실행 기록, 그리고 발송 로그예요. 생성 결과는 9일 모두 성공으로 남았고, 10월 23일 결과 파일에도 성공 표시가 있었어요.
발송 로그도 9일 모두 전달 성공이었어요. 10월 23일에 잘 전달된 것은 브리핑이 아닌 생성 기록 없음 안내였어요. 그날이 늦었다는 사실은 결과 파일의 끝난 시각 11:15와 07:00 안내 문구에만 있었어요.
첫 설명은 잠자기였고, 그날 Mac 상태는 확인하지 않았어요
AI는 보고의 문제 1로 10월 23일을 적고 원인 설명을 붙였어요. Mac이 잠자기였을 때 05:30 예약이 깨어난 뒤로 밀리는 현상으로 보인다는 설명이었어요. 같은 자리에 그날 Mac이 언제 잠들고 깼는지는 확인하지 못했다는 단서도 있었어요.
권유도 함께 왔어요. 다시 일어나지 않게 하려면 05:25에 Mac을 깨우는 예약을 걸 수 있다고 했어요. 시스템 설정을 바꾸는 일이라 원하면 제가 직접 해야 한다는 말도 붙었어요.
저는 같은 보고의 문제 2였던 블로그 폴더 경로부터 고치게 했어요. 그런데 경로 수정을 마쳤다는 보고 끝에, Mac이 잠들어 있으면 05:30 생성이 밀릴 수 있다는 위험이 아직 그대로라는 문장이 다시 붙었어요. 확인하지 못했다던 추측이 보고 한 번을 지나자 남은 위험처럼 적혀 있었어요.
실행은 05:30:05에 제때 시작됐어요
저는 "맥이 잠자지 않는데?"라고 물었어요. 제가 아는 한 이 Mac은 잠들지 않는 상태였어요. AI는 기록을 다시 열었고, 잠자기가 원인이라고 한 건 자기 추측이었고 틀렸다고 바로 답했어요.
AI가 다시 맞춘 첫 시각은 실행 결과 파일의 시작 시각이었어요. 10월 23일 실행은 05:30:05에 시작돼 있었어요. 잠자기 때문에 예약이 밀렸다면 시작 시각부터 늦었어야 하는데, 시작은 제때였어요.
잠자기 설정도 확인했어요. 지금 이 Mac의 잠자기 값은 0이라 잠자기가 꺼져 있었어요. 다만 Mac의 전원 기록이 10월 23일 12:56부터만 남아 있어서, 그날 새벽 상태는 확인할 수 없었어요.
재료를 모으는 단계에서 5시간 40분이 비어 있었어요
다음은 파일 시각이었어요. 브리핑은 그날의 재료를 모아 재료 파일 하나로 묶고, 그 파일을 AI에게 넘겨 글을 쓰게 하는 순서로 돌아요. 10월 23일 재료 파일은 11:11에, 글쓰기 결과는 11:15에 만들어졌어요.
05:30:05에 시작해 11:11에 재료 파일이 나왔으니, 재료를 모으는 단계에서 5시간 40분이 비어 있었어요. 글쓰기는 4분 만에 끝났어요. 늦어진 곳은 글을 쓰는 단계보다 앞이었어요.
이 글을 쓰며 다른 날의 실행 결과 파일도 견줘 봤어요. 10월 24일부터 11월 3일까지 11번의 실행은 모두 05:30에 시작해 7분 안에 끝났어요. 10월 23일 하루만 시작부터 끝까지 5시간 45분이 걸렸어요.
오류 기록이 비어 있어, 멈춘 곳은 끝내 특정하지 못했어요
재료를 모으는 단계 안에서 정확히 어디서 멈췄는지는 알 수 없었어요. 그날 오류 기록 파일은 비어 있었어요. 멈춘 동안 무엇을 기다렸는지 남긴 줄이 하나도 없었어요.
그래서 AI는 찾는 방향을 바꿨어요. 멈춘 곳을 맞히는 대신, 코드에서 끝없이 기다릴 수 있는 자리를 찾았어요. 재료를 모을 때 이 Mac의 환경을 확인하려고 부르는 외부 명령 4개에 시간 제한이 없었어요.
원격 접속 도구인 Tailscale의 버전과 설정을 읽는 명령 2개, 그리고 Claude Code와 Codex의 버전을 묻는 명령 2개예요. 이 중 하나라도 응답하지 않으면 실행 전체가 그 자리에서 계속 기다리는 구조였어요. 뉴스 수집에는 이미 요청마다 10~20초 제한이 걸려 있었어요.
이 명령 4개가 10월 23일에 멈춘 곳이라는 증거는 없어요. AI도 원인으로 보이는 후보라고만 적었어요. 그래서 이 수정은 원인을 고친 것이라기보다, 같은 일이 다시 생겨도 실행이 끝없이 기다리지 않게 막는 수정이에요.
끝없이 기다릴 수 있는 명령 4개에 30초 제한을 걸었어요
AI는 시간 제한을 걸지 저에게 물었고, 추천은 거는 쪽이었어요. 저는 그날 이어서 맡긴 작업의 범위에 이 수정을 넣었고, 그 작업 카드를 그대로 시작했어요. 고칠 곳은 실행 스크립트 한 파일이었어요.
바꾼 동작은 단순해요. 환경 확인 명령마다 30초 제한을 두고, 30초 안에 끝나지 않거나 실패하면 그 줄만 빈칸으로 두고 다음 단계로 넘어가요. 코드 주석에는 10월 23일에 5시간 넘게 멈춘 일 때문이라고 적었어요.
자동화의 기준 문서에도 같은 문장을 넣었어요. 설치된 도구와 버전을 읽을 때 확인 명령마다 30초 제한을 두고, 넘으면 그 줄만 빼고 계속한다는 문장이에요. 동작을 바꾸려면 기준 문서를 먼저 고친다는 이 자동화의 규칙을 따랐어요.
버린 선택지는 05:25에 Mac을 깨우는 예약이에요. 잠자기는 이미 꺼져 있었고, 예약을 걸려면 시스템 설정을 바꿔야 했어요. 원인이 아닐 수 있는 것을 막으려고 설정을 하나 더 늘리는 셈이라 걸지 않았어요.
남은 확인도 있어요. 수정 뒤 10월 31일부터 11월 3일까지 네 번은 모두 05:34에서 05:36 사이에 끝났어요. 하지만 수정 전인 10월 24일부터 10월 30일까지도 정상이었으니, 이 기록만으로 수정이 효과를 냈다고 말할 수는 없어요.
제가 정한 것과 AI가 한 것
제가 한 일은 질문 하나와 결정 하나였어요. 맥이 잠자지 않는다는 질문으로 잠자기 가설을 다시 보게 했고, 시간 제한 수정을 작업 범위에 넣었어요. Mac을 깨우는 예약은 걸지 않았어요.
AI는 기록 시각을 하나씩 맞췄어요. 시작 시각과 재료 파일, 글쓰기 결과의 시각을 대조했고, 잠자기 설정과 전원 기록도 확인했어요. 자기 첫 설명이 추측이었다고 바로잡았고, 시간 제한 없는 명령을 찾아 고친 뒤 기준 문서에 적었어요.
첫 보고에도 확인하지 못했다는 단서는 분명히 있었어요. 다만 그 단서는 권유와 같은 자리에 있었고, 다음 보고에서는 남은 위험이라는 말로 바뀌었어요. 질문하지 않았다면 저는 추측을 바탕으로 Mac 설정을 바꿨을 수도 있어요.
처음 질문으로 돌아가면
AI가 내놓은 원인은 시작 시각 하나로 다시 확인할 수 있었어요. 잠자기라면 시작이 늦어야 했는데, 시작은 제때였어요. 그럴듯한 설명일수록 그 설명이 맞다면 어느 기록이 달라야 하는지부터 봐요.
멈춘 곳의 직접 증거가 없을 때는 원인을 맞히는 데 매달리지 않았어요. 끝없이 기다릴 수 있는 자리를 찾아, 기다림에 끝을 정했어요.
원인을 못 찾았으면, 끝없이 기다릴 수 있는 자리부터 막아요.