Claude Code에 한 달간 운영을 맡기고, 멈춘 지점들을 모두 기록하다

AI (Claude Code)에게 블로그의 운영 자체를 1개월 동안 맡겼습니다. 글을 쓰고, 숫자를 측정하고, 사이트를 고치고, 주기적 실행(定期実行)을 설정합니다. 코드를 작성하게 하는 것이 아니라, 작업이 돌아가게 하는 방식입니다.

결과적으로, 멈춰 있는 지점들이 편중되어 있음을 알게 되었습니다. 코드 오류로는 거의 멈추지 않습니다. 멈추는 것은 항상 그 직전이나 바깥쪽입니다.

이 글은 1개월 동안 실제로 멈췄던 지점들의 지도입니다. 재현 절차와 제가 얻었던 모든 수치를 공개합니다. 깔끔한 결론은 나오지 않았습니다. 알지 못하는 것은, 알지 못한다고 적겠습니다.

전제: 무엇을 맡겼는가

1. 가장 많은 것은 '성공으로 보고되었으나 실제로는 되어 있지 않음'

이것이 가장 많았고, 가장 알아차리기 어려웠습니다.

사례: 8일 동안 멈춰 있다는 것을 깨닫지 못했다

매일 1회 주기적 실행을 launchd로 설정했습니다. 8일 동안 한 번도 작동하지 않았습니다.

• 오류 알림: 0
• 로그 파일: 0바이트

launchctl list
: 제대로 올라와 있음 손으로 shell에서 실행하면 성공함

원인은 스크립트의 위치였습니다. iCloud Drive 안에 두었기 때문에, 실체가 클라우드에만 있는 상태에서는 launchd로 시작할 수 없습니다. 손으로 실행하면 Finder가 실체를 내려주므로 성공합니다. 테스트로는 절대 알아차릴 수 없는 형태였습니다.

사례: 배포(deploy)는 성공했으나 공개되지 않음

배포 명령어는 성공으로 끝나고, AI도 '공개했습니다'라고 보고했습니다. 공개 URL을 열어보니, 예전 내용 그대로였습니다.

사례: 이미지를 '설정했다'고 했지만 실제로는 없음

기사 제목 이미지를 설정하게 했습니다. 보고는 성공이었습니다. API로 기사를 다시 가져오니, 이미지 항목이 비어 있었습니다. 삽입 작업은 했으나, 마지막 '저장'을 누르지 않았습니다.

공통점

모두 AI가 거짓말을 한 것은 아닙니다. 작업은 실행되었습니다. 다만, 작업의 완료와 결과 반영이 일치하지 않았습니다.

AI는 '자신이 실행한 것'은 알고 있지만, '실행 결과가 어떻게 되었는지'는 직접 보지 않으면 알 수 없습니다. 그리고 가서 확인하라고 지시받지도 않았습니다.

효과적 대책: 보고 대신 실물을 내놓게 하기

지시의 끝에 이 문장을 추가했습니다.

설정/공개/게시를 했다면, 그 보고 대신,
실물(공개된 데이터, 게시 목록, 성과물의 개수)을 다시 가져와서,
이전과 이후의 숫자를 나란히 비교하여 보고해 주세요.

이것만으로 위 3가지 사례는 방지할 수 있게 되었습니다. 보고는 '성공'이었습니다. 실물은 달랐습니다. 확인 대상을, 보고에서 실물로 옮기는 것만으로 충분했습니다.

2. 세는 법을 잘못 알기 (같은 실수에 4번 빠짐)

API에서 데이터를 가져와 집계하는 처리 과정에서, 똑같은 실수를 4번 했습니다. 전부 '페이지가 나뉘어 있는 API를 첫 페이지만 읽음'이었습니다.

| 회 | 1페이지의 건수 | 발생한 일 |
|---|---|
| 1 | 6 | 기사 수를 적게 계산함 |
| ... | |
4번째는, 3번째의 반성을 작성한 후에 빠졌습니다. 같은 함정이라는 것을 알아도, 다른 서비스에서는 깨닫지 못합니다.

왜 알아차리기 어려운가

오류가 발생하지 않기 때문입니다. 돌아오는 JSON은 정상이고, 배열에도 데이터가 들어 있습니다. 부족한 것만 알 수 없습니다.

게다가 더 나쁜 것은, 많은 API는 순서가 PV(페이지뷰) 내림차순이라는 것입니다. 떨어지는 것은 반드시 '숫자가 작은 기사'입니다. 합계에 미치는 영향이 작기 때문에, 총합계를 봐도 이상하게 보이지 않습니다. 3번째 때는 총 PV가 183으로 나왔는데, 실제는 189였습니다. 6의 차이는 알아차리기 어렵습니다.

효과적 대책: 건수를 다른 정보원과 교차 확인하기

루프를 고치는 것보다 이쪽이 더 효과적이었습니다.

통계 API가 반환한 건수(22) vs 공개 기사 수(22) → 일치

공개 기사 수는 인증이 필요 없는 다른 API에서 가져올 수 있습니다. 같은 API 안에서만 완결시키지 않는 것이 포인트입니다. 첫 페이지만 읽고 있으면, 이 비교에서 반드시 걸립니다.

종료 조건이 API마다 다른 것도 실수하기 쉬운 이유였습니다.

3. 「변하지 않는 것」을, 고장 난 지표로 확인하고 있었다

작업 전후로 본문이 망가지지 않았는지, 글자 수로 확인했습니다.

어느 날 기사를 업데이트했더니 본문의 길이가 21,101 → 20,095로 줄었습니다. 1,006자가 사라졌다고 판단하고 복구 작업에 들어갔습니다.

사라지지 않았습니다. 이 서비스는 저장할 때마다 각 블록의 name와 id를 재설정합니다. 속성의 글자 수가 바뀌기 때문에, 본문의 길이는 내용이 같아도 변동합니다. 실제로 다음 저장에서 21,101로 돌아왔습니다.

효과가 있었던 대책: 변하지 않는 숫자로 확인하기

작업 결과를 확인할 때는, 저장할 때마다 변하는 숫자를 사용하지 마십시오.
문자수만, 제목의 수, 목차 유무, 링크 목록의 4가지를,
작업 전과 후로 가져와 나란히 놓으세요.

확인에 사용하는 숫자는, 변해서는 안 되는 것만으로 합니다. 변하는 숫자를 주시하다 보면 익숙해져서 보지 않게 됩니다.

4. 권한을 전부 열어도 멈추는 작업이 있다

권한 모드를 「모두 허용」으로 하고, 허가 규칙도 100건 넣은 상태에서도 거부되는 작업이 있었습니다.

Permission for this action was denied by the auto mode classifier.
Reason: Blocked by classifier.

권한 설정 이야기라고 생각하고 반나절을 조사했습니다. 오답이었습니다.

| 무엇을 볼 것인가 | 설정으로 바꿀 수 있는가 | |
|---|---|
| 권한 모드・허가 규칙 | 어떤 도구를 사용할 수 있는지 | 바꿀 수 있음 |
| 자동 모드의 안전 점검 | 그 작업이 무엇을 하려고 하는지 | 바꿀 수 없음 |

설정 파일을 아무리 봐도 원인은 나오지 않습니다. 거부 메시지에 classifier라고 쓰여 있었고, 그곳이 답이었습니다. 에러 문구를 읽기보다 먼저 설정을 의심했던 것이 늦은 이유입니다.

중단한 것들

처음에 생각했던 회피책은 두 가지가 있었고, 둘 다 포기했습니다.

• 페이지 측의 확인 대화 상자를 교체하여, 확인 자체를 없애는 것
• 다른 세션에 같은 작업을 맡기는 것

1번은, 거부되는 작업의 내용은 바꾸지 않고, 멈추게 하는 메커니즘만 제거하는 행위입니다. 2번은, 거부된 작업을 다른 실행 주체로 옮길 뿐, **권한의 런더링(laundering)**에 해당합니다.

자동화를 진행하다 보면, 멈춘 것을 통과시키는 것 자체가 목적이 되기 쉽습니다. 여기는 분리해서 생각해야 할 부분이었습니다.

대신 적용한 규칙

작업이 거부되면 우회하지 않는다. ok=0으로 기록하고 다음으로 진행한다.

중요한 것은 후반부입니다. 거부된 사실을 기록으로 남기는 것. 이것을 하지 않으면, 다음 날 또 같은 곳에서 멈춥니다. 기록을 시작하기 전에는, 3일 연속 같은 곳에서 멈추고 있었습니다.

5. 매뉴얼이 너무 자라나서 실행이 진행되지 않게 되었다

매일 아침의 작업 절차를 적은 파일이, 30,474자까지 자랐습니다. 지나온 실패와 그 회피책을, 좋다고 생각해서 계속 추가한 결과입니다.

3일 연속으로, 태스크가 시작 기록조차 남기지 않고 끝나는 일이 생겼습니다. 에러는 발생하지 않습니다.

원인을 권한 설정이라고 생각하고, 거기서 하루를 썼습니다. 이것도 오답이었습니다. 설정을 보니, 이미 전 허용이고, 허가 규칙이 100건 들어 있었습니다.

5,503자까지 줄이니, 같은 태스크가 17분 만에 끝까지 돌아갔습니다.

| 줄이기 전 | 줄인 후 | |
|---|---|
| 글자 수 | 30,474 | 5,503 |
| ... |
줄인 것은 '경위'와 '근거'입니다. 왜 그 절차가 되었는지를, 다른 파일에 전부 옮겼습니다. 매뉴얼에 남긴 것은, 매번 반드시 읽어야 할 것만(판단의 분기・순서・금지 사항)입니다.

정보를 지운 것이 아닙니다. 읽는 타이밍을 바꾼 것일 뿐입니다.

6. 주기적 실행 자체가 조용히 멈춘다

이것은 아직 고쳐지지 않았습니다. 현상만 적겠습니다.

매일 아침 태스크가, 어느 날부터 완주하지 않게 되었습니다. 분리 분석 결과는 두 가지로 나뉘었습니다.

(1) 시간이 되어도 작동하지 않는 것이 있다

⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.

유효한 상태인데도 불구하고, 다음 실행 시간이 과거로 남아있고 기록이 하나도 없습니다.

(2) 구동된 것은 첫 번째 도구 호출에서 멈춘다

네 번째는 브라우저를 전혀 사용하지 않는 절차서로 수정한 후였습니다. 특정 도구의 문제가 아닙니다.

멈춘 실행은 몇십 시간 동안 '실행 중' 상태로 남아 다음 예정된 실행을 막습니다. 멈추면 다음 날 아침부터 움직이기 시작합니다.

알고 있는 것・모르는 것

• 슬립(Sleep)이 아니다 (uptime는 연속 가동이며, 해당 시각의 로그 파일이 있다) - 이 프로젝트에만 국한된 것이 아니다 (다른 프로젝트의 정기 실행도 같은 시기에 멈춰있다)
  왜 첫 번째 도구 호출에서 멈추는지까지는 알지 못합니다

현재 알고 있는 대처법은 '멈춘 실행을 수동으로 중단하는 것'뿐입니다. 근본적인 원인은 추적하지 못하고 있습니다.

7. '멈춤'에 알아차리게 하기 위해 넣은 것

지금까지의 실패에서 공통되는 점은, 멈췄다는 사실이 통지되지 않는다는 것입니다. 실패는 '실패'로 처리되지 않고, '아직 실행 중'이나 '성공'으로 조용히 남아 있습니다.

넣은 것은 단 두 가지입니다.

시작과 종료를 모두 기록하게 하기

INSERT INTO daily_actions (done_on, action, result, ok)
VALUES ('2026-09-25', '일일 작업 시작', '시작', 1);

종료 시에도 똑같이 한 줄을 기록합니다. 이렇게 하면 세 가지 상태를 구분할 수 있습니다.

실패도 반드시 기록하게 하기

작업이 거부되면, ok=0으로 기록하고 다음으로 진행한다.

성공만 기록하면, 기록은 거짓말을 하게 됩니다. 거부된 것도, 얻지 못한 숫자도 같은 무게로 기록해야 합니다. 이것을 멈추는 순간, 나중에 아무것도 판단할 수 없게 됩니다.

8. 한 달간의 수치

솔직하게 말씀드립니다.

움직이고 있었습니다. 확인하는 방법이 부족했을 뿐입니다. 이것이 한 달간의 결론입니다.

코드 품질을 높이는 이야기는 지난 한 달 동안 거의 나올 기회가 없었습니다. 효과가 있었던 것은 전부, 실행 외부에 있는 확인과 기록이었습니다.

맺음말

다시 한번, 효과가 있었던 것들만 나열합니다.

보고 대신 실물을 내놓게 하기 (다시 가져와서 앞뒤 숫자를 배열하기) -
건수를 다른 정보원과 대조하기 (같은 API 안에서 완결시키지 않기) -
확인에는 움직이지 않는 숫자 사용하기 (저장할 때마다 바뀌는 것을 감시하지 않기) 거부되면 우회하지 않고 기록하기****절차서는 성장한다는 전제하에, 주기적으로 깎아내리기-
시작과 종료를 모두 기록하게 하기 (멈춘 장소를 알 수 있는 것은 이것뿐)

이것들 중 어느 것도 영리한 시스템은 아닙니다. 전부, 확인하는 방법에 대한 이야기입니다.

AI에게 작업을 맡기면, 못 하는 것보다 '했다고 들었는데 실제로는 안 되어있는 것'의 경우가 훨씬 많다는 것이 한 달간의 체감이었습니다.

AI (Claude Code)에게 개발과 운영을 맡긴 기록을 비용 0원으로 계속하고 있습니다. 읽는 방법 안내는 note의 요약에 두고 있습니다.

Discussion