AI 자동화 ‘죽은 트리거’ 3개월째 조용히 실패 중 — 내가 감사 도구를 만든 이유
자동화를 열심히 쌓고 나서 한 번이라도 “이게 지금도 돌고 있나?” 점검해본 적 있는가. 없다면, 아마 지금 이 순간에도 실행 트리거는 살아있는데 실행할 스크립트는 이미 사라진 ‘좀비 자동화’가 조용히 실패를 반복하고 있을 가능성이 높다. 나는 직접 만든 32개짜리 자동화 저장소를 감사 도구로 돌려서, 3개월 넘게 아무도 몰랐던 죽은 트리거 하나를 찾아냈다.
문제는 ‘만든 것’이 아니라 ‘잊어버린 것’이었다
GitHub Actions로 개인 AI 파이프라인을 운영하다 보면 자동화는 자연스럽게 쌓인다. 배포 자동화, 자동 커밋 봇, 로컬 스케줄러, 정기 리포트 생성기…. 처음에는 10개, 나중엔 어느새 32개.
문제는 자동화를 *삭제*할 때 생겼다. 스크립트 파일은 지웠는데, 그 스크립트를 실행하는 GitHub Actions 워크플로 트리거는 그대로 남겨뒀다. Actions는 정직하게 매일 스케줄대로 실행을 시도하고, 정직하게 실패한다. 그러나 아무도 알림을 보지 않는다. 실패 로그는 쌓이고, 나는 모른다.
더 불편한 진실은 이것이다. GitHub Actions는 임시 러너가 생성한 파일을 커밋하지 않으면 모두 날린다. 아티팩트는 영구 저장이 아니다. 그리고 조용히 건너뛰는 코드는 몇 달간 아무도 눈치채지 못한다. 나는 이 세 가지를 직접 몸으로 겪은 뒤에야 “감사(audit)가 필요하다”는 결론에 이르렀다.
직접 만든 감사 도구: agent-automation-audit
감사 도구를 외부에서 찾으려 했지만, AI 에이전트가 만든 자동화의 ‘죽은 상태’를 구조적으로 점검하는 도구는 없었다. 그래서 Claude Code 스킬 형태로 직접 만들었다.
agent-automation-audit은 다음 세 가지를 찾아낸다.
1. 중복 실행: 같은 작업을 두 개 이상의 워크플로가 동시에 돌리는 경우 2. 죽은 트리거: 스크립트는 삭제됐는데 트리거(스케줄, push 이벤트 등)는 살아있는 경우 3. 검토 없는 자동 발행 경로: 사람이 개입하지 않고 콘텐츠나 코드가 배포되는 경로
이 도구를 내 저장소에 실제로 돌렸을 때, 정확히 세 번째 유형에서 죽은 트리거 하나가 걸렸다. 스크립트를 지운 날로부터 약 3개월 이 지나 있었고, 그동안 Actions는 하루도 빠지지 않고 실패 기록을 남기고 있었다.
이 도구가 ‘삭제’가 아닌 ‘비활성화+보관’을 원칙으로 삼은 이유
자동화 감사를 하다 보면 “이거 그냥 지우면 안 되나?”라는 생각이 든다. 하지만 지운 트리거나 워크플로가 어디선가 다른 것과 의존 관계를 맺고 있을 경우, 지우는 행위 자체가 새로운 문제를 만든다. 그래서 이 도구는 절대 자동 삭제를 하지 않는다. 발견한 것을 목록으로 보여주고, ‘비활성화 후 보관’ 경로만 제안한다. 실행은 사람이 직접 판단한다.
이 원칙은 어쩌면 안티프래질의 논리와 닿아있다. 시스템을 강하게 만드는 방법은 충격을 제거하는 것이 아니라, 충격에 대한 반응을 제어하는 것이다.
실전 전략: 죽은 트리거를 만들지 않는 3가지 습관
- 스크립트를 지울 때 트리거 파일을 함께 확인한다. 파일 삭제 PR을 올릴 때, 연결된
.github/workflows/폴더의 yml 파일도 같이 검색한다. grep 한 줄이면 충분하다. - 자동화 목록을 코드로 관리한다. README에 자동화 목록을 수동으로 적는 건 금방 구식이 된다. 워크플로 파일을 파싱해 자동으로 목록을 뽑는 스크립트를 하나 만들어두면, 현재 살아있는 자동화를 언제든 한눈에 볼 수 있다.
- 실패 알림을 ‘조용한 채널’에만 두지 않는다. GitHub Actions 실패 알림이 이메일로만 오고 그 이메일을 거의 안 본다면, 슬랙이나 디스코드 웹훅으로 한 줄 알림을 추가한다. 죽은 트리거는 조용한 채널 덕분에 3개월을 버텼다.
단계별로 이해하기: 자동화 감사를 처음 해본다면
1단계 — 현재 자동화 목록 뽑기
먼저 내가 운영 중인 자동화가 몇 개인지부터 파악한다. 터미널에서 .github/workflows/ 폴더 안의 파일 수만 세도 된다.
ls .github/workflows/ | wc -l30개가 넘는다면, 그중 몇 개는 이미 죽어있을 확률이 높다.
2단계 — 트리거 유형 분류
각 워크플로 파일의 on: 항목을 확인한다. schedule(정기 실행), push(코드 푸시 시), workflow_dispatch(수동 실행) 중 schedule 타입이 가장 위험하다. 아무 입력 없이 스스로 실행을 시도하기 때문이다.
3단계 — 트리거와 실제 실행 파일의 연결 확인
트리거가 실행하려는 파일(스크립트, 액션, 도커 이미지)이 실제로 저장소에 존재하는지 확인한다. agent-automation-audit을 사용하면 이 과정을 자동화할 수 있다. Claude Code 플러그인 마켓플레이스에서 설치 가능하고, 무료다.
4단계 — 죽은 것은 비활성화, 중복은 병합
죽은 트리거는 삭제하지 않고 .disabled 확장자를 붙이거나, 워크플로 파일 맨 위에 if: false를 추가해 비활성화한다. 기록은 남긴다.
5단계 — 주기적으로 반복
자동화는 계속 쌓인다. 감사는 한 번으로 끝나지 않는다. 분기에 한 번, 또는 자동화가 5개 이상 추가될 때마다 같은 과정을 반복하는 것이 현실적이다.
이 문제가 중요한 이유: ‘조용한 실패’의 비용
비용은 항상 명시적이지 않다. GitHub Actions 무료 한도는 월 2,000분(퍼블릭 저장소는 무제한)이지만, 프라이빗 저장소에서 죽은 트리거가 매일 실행을 시도하면 그만큼 한도가 소진된다.
더 큰 비용은 신뢰 손실이다. 자동화가 실패하고 있다는 사실을 모른 채 “이건 자동으로 되고 있겠지”라고 믿는 순간, 그 믿음에 기반한 의사결정도 함께 틀어진다. 3개월간 조용히 실패한 트리거 하나가 가르쳐준 건, 자동화 시스템도 정기적인 점검이 필요하다는 단순한 사실이었다.
GitHub Actions 공식 문서에 따르면, 60일간 실행 이벤트가 없는 저장소의 스케줄 워크플로는 자동으로 비활성화된다. 그러나 매일 조용히 실패하는 워크플로는 이 조건을 충족하지 못해 자동 비활성화가 되지 않는다. 실패도 ‘실행’으로 카운트되기 때문이다.
자주 묻는 질문
Q. 죽은 트리거가 있어도 실제로 문제가 생기나요? A. 퍼블릭 저장소라면 Actions 사용량 제한이 없어서 금전적 비용은 없지만, 프라이빗 저장소는 실패 실행도 무료 한도를 소진합니다. 더 중요한 건 ‘자동화가 정상 동작 중’이라는 잘못된 믿음이 쌓이는 것이며, 이는 나중에 더 큰 판단 오류로 이어질 수 있습니다.
Q. agent-automation-audit은 어떤 환경에서 쓸 수 있나요? A. Claude Code 플러그인 마켓플레이스에서 설치해 사용하는 방식이며, 무료로 공개되어 있습니다. GitHub 저장소의 워크플로 파일을 분석하는 구조라 Claude Code를 사용하는 환경이라면 별도 설정 없이 바로 돌릴 수 있습니다.
Q. 자동화가 5~10개 정도로 적으면 굳이 감사 도구가 필요한가요? A. 개수가 적을 때는 수동으로도 충분합니다. 다만 자동화는 예상보다 빠르게 늘어나기 때문에, 10개를 넘어서는 시점부터는 워크플로 파일 목록을 주기적으로 출력해서 확인하는 습관 자체를 들이는 것이 좋습니다.
자동화를 많이 만드는 것보다, 만든 자동화가 지금 살아있는지 한 번씩 확인하는 쪽이 더 어렵고 더 중요하다.