AI 에이전트에게 매일 확인을 10일 맡기다 — '없음'과 '확인하지 않음'이 같은 인쇄였던 3건

본문에 달린 첫 두 명의 댓글에 답장하는 데 각각 22.8시간과 11.1시간이 걸렸습니다 (2026-09-18). 찾아보는 것을 잊으셨을 뿐입니다.

그날, AI 에이전트(Claude Code)에게 '매일 확인만' 시키는 도구를 만들었습니다. 기사 반응, 수신함, 열람 횟수, 마감일, 본 사이트의 생존 여부, 정기 태스크, 백업 등 모든 것을 하나의 커맨드로 보고 인쇄합니다.

8일째(09-25)에 note 확인 기능을 도구에 추가했습니다. note 기사 목록 API는 1페이지당 6개씩 반환하는데, 추가한 기능은 1페이지 분량만 읽고 있었습니다. 총 19개 중 6개만 보고 '6개・댓글 합계 N'이라고 인쇄했고, 나머지 13개의 댓글은 확인하지 못했던 것입니다. 도구는 그 6개가 전부라고 생각했습니다. 이를 깨닫고 수정한 것은 추가한 지 약 2시간 반 후였습니다.

10일 동안 도구를 수정하며 발견한 문제는 총 14건이었습니다. 그중 이런 종류의 간과가 3건 있었습니다. 세 건 모두 같은 형태였습니다.

본 기사의 위치 설정

• 새롭게 제시하는 것: 매일 확인 기능을 10일간 돌리며 수정한 내용을 커밋(commit) 단위가 아닌 문제 단위로 나누어 기록한 점과, 간과된 3건에 공통적으로 나타난 형태.
• 적용 범위: 저 개인의 운영 사례・하나의 도구・10일 (2026-09-18~27, 확인 8회)입니다. 분류는 같은 사람이 2회입니다. 탐색적인 기록입니다.

숫자의 원본 데이터와 재현 절차는 검증 기록(Lab)에 정리했습니다.

| 간과된 부분 | 인쇄된 내용 | 실제 상황 | :--- |
| note API의 1페이지 분량만 읽음 | 6개・댓글 합계 N | 총 19개 중 6개만 확인함 |
| ... | | |
세 건 모두 '없음(0・전체)'과 '확인하지 않음'이 같은 인쇄가 되고 있었습니다. 도구는 고장나지 않았습니다. 빨간색도 나타나지 않았고, 조용히 0을 출력하고 있었습니다.

수정한 도구는 페이지별 합계 행・API 총 개수와의 대조・404 오류 시 빨간색을 표시하도록 변경되었습니다. 이를 하나의 규칙으로 정리하면, 페이지마다 매번 출력되는 7개 항목이 됩니다 (저의 도구는 아직 이 이름으로는 출력하지 않습니다. 아래는 형태의 예시이며, 값은 설명을 위한 것입니다).

note checked_at=2026-09-27 07:10 source=기사 목록 API pages_read=4(끝까지) items_seen=19 items_new=0 error=없음 evidence=totalCount 19 와 일치
Zenn checked_at=2026-09-27 07:10 source=댓글 API pages_read=-
...

'신규 0'이 아니라 '4 페이지・19건을 확인하여 신규 0'과 같이 출력합니다. 404의 경우 0이라고 쓰지 않고 404라고 씁니다. 이렇게 하면 세 건 모두, 인쇄된 내용을 보는 시점에서 읽었어야 했습니다 (이 형태는 아직 도구에 넣지 않아 확실하게 검증하지 못했습니다).

pages_read

은 마지막 페이지까지 읽어서 API가 반환하는 총 개수(totalCount)와 숫자가 일치할 때만 '끝까지'라고 씁니다. 일부러 1페이지에서 멈추면 빨간색이 나타나는 것을 확인했습니다.

도구의 오류 4건: 건수를 기억하는 파일이 손상되면 다운됨 / 다운되었을 때 이유가 남지 않음('exit 1'만) / 비공개 댓글이 user={}로 반환되어 KeyError 발생 / 태스크 이름의 일본어 문자 깨짐으로 '태스크 없음'이라는 가짜 빨간색 2건 -
확인할 곳을 추가한 5건: 열람 횟수의 일별・하테나의 공개 상태・관리 점검(백업・정기 태스크・본 배포물）・반응의 주간 및 월간 분석・공개 리포트 누락점 검사 -
효율성 개선 2건: 처음 위치를 인쇄함 (매번 파일을 찾고 있었음) / 미답변 본문을 댓글 단위로 작성

'간과된 부분 수정이 절반 이상일 것'이라고 예측했지만, 틀렸습니다. 가장 많았던 것은 확인할 곳을 추가한 수정입니다. 추가한 날에 발견된 것도 있었습니다. 백업 로그를 보게 된 09-25에는, 2개월 분의 일별 백업이 67회 모두 ERROR였고, 태스크 결과는 성공(0)이었다는 것을 알았습니다.

• 3가지 도구와 관련된 커밋은 총 14개였습니다. 도구를 만든 2개를 제외한 나머지 12개를 각각 하나씩 읽었습니다.

• 하나의 커밋에 다른 문제가 3개가 들어있다면 3건, 같은 문제를 추적하여 수정한 것은 1건이었습니다. 커밋의 수는 자르는 방식에 따라 달라지므로, 단위는 문제로 했습니다.

• 묶음과 분류 기준은 세기 전에 정하고 기록했습니다. 09-28에 날짜를 바꿔서 다시 나누었을 때, 바뀐 숫자는 0이었습니다 (같은 사람이 했으므로, 이는 변동의 하한선입니다).

• 도구 외부에서 수정한 누락 사항이 2건 있습니다. 받은 편지함의 정해진 단어에 없는 알림 누락과, 문의 메일을 읽는 권한이 잘못되어 3일 동안 읽을 수 없었던 건입니다. 이는 절차서 수정에 해당하므로 14건에는 포함하지 않았습니다.

• 회신 지연이 줄었는지 측정하지 못했습니다. 같은 시기에 운영 방식도 변경했기 때문에, 도구만의 효과라고는 할 수 없습니다.

• 도구 호출의 왕복은 09-19 하루치(71회 왕복)만 기록했습니다。

이 기사의 원본(8개의 표・14건의 분류・셈법 고정)은 Sumitsuke Lab → AI 에이전트의 '하루 한 번 확인'을 10일 동안 8번 (검증 기록 포함)입니다.

확인을 진행한 것도, 도구를 수정한 것도, 이 기사의 초안을 작성한 것도 AI(Claude Code)입니다. 분류 규칙과 공개 여부는 사람이 했습니다. 거래 중인 건에 관련된 수신은 건수만 적었을 뿐, 내용은 쓰지 않았습니다.

Sumitsuke는 AI나 외주를 통해 만든 것의 점검 및 수리, 업무 자동화, 검증을 위탁받고 있습니다. 매일 확인을 '본 증거'와 함께 진행하는 시스템은 → https://sumitsuke.jp/works/automation/*이 기사는 Zenn에도 같은 내용을 게재하고 있습니다.