자동화를 다 만들면 끝일까, 점검하는 자동화가 따로 필요했다
자동화는 요란하게 안 죽더라. 어느 날부터 그냥 조용히 안 돌 뿐이다.
클로드코드 자동화 점검이라는 말, 만들 땐 생각도 안 했다. 자동화를 하나둘 붙여놓고 나면 머릿속에서 그 일은 끝난 걸로 처리된다. 아침에 메시지 오고, 노트 정리되고, 표가 만들어지니까. 근데 그게 진짜로 돌고 있는지 확인해본 적은 없었다. 확인 안 해도 티가 안 나니까 그렇다. 이 글은 자동화를 만드는 얘기가 아니라, 만들어둔 게 살아 있는지 보는 장치를 따로 만든 얘기다.
📑 목차
- 1. 다 만들어놓고, 돌아가는 줄 알았다
- 2. 자동화가 죽는 세 가지 방식
- 3. 점검을 사람이 하면 결국 안 하게 된다
- 4. 내가 붙인 점검 3층: 살았나, 왔나, 말이 되나
- 5. 점검기가 죽으면 아무도 안 알려준다
- 6. 손은 얼마나 드나, 그리고 안 해도 되는 사람
- 7. 정리
1. 다 만들어놓고, 돌아가는 줄 알았다
작년부터 붙여둔 자동화가 여러 개다. 아침에 텔레그램으로 오는 브리핑, 새로 들어온 노트만 골라 분류하는 옵시디언 정리, 쌓인 노트를 요약하고 태그 붙이는 것, 흩어진 엑셀 취합, 그리고 노트끼리 서로 링크로 엮는 위키 작업까지.
여기까지가 자랑이고, 지금부터가 사고다.
노트 파일 이름을 대량으로 정리하면서 경로가 한꺼번에 바뀐 적이 있다. 그때 본문 안에 걸려 있던 출처 링크 48개가 통째로 끊겼다. 문제는 그게 끊긴 걸 4일 뒤에 알았다는 거다. 그 4일 동안 자동화는 멀쩡히 돌았다. 아침 메시지도 왔고, 새 노트도 정리됐고, 주간 정리본도 나왔다. 겉보기엔 아무 일도 없었다. 링크만 죽어 있었을 뿐이지.
고장이 났는데 화면이 그대로면, 고장 안 난 거랑 구분이 안 된다..
그때 알았다. 나는 자동화를 만든 게 아니라, 자동화가 만들어낸 결과물을 안 보고 있었던 거다.
2. 자동화가 죽는 세 가지 방식
사고 뒤에 그동안 겪은 걸 되짚어보니 죽는 방식이 딱 세 갈래로 갈리더라.
첫째, 아예 안 돈다. 맥이 잠들어 있었다거나, 스케줄 등록이 풀렸다거나, 프로그램 업데이트하면서 경로가 바뀐 경우. 이건 그나마 착한 고장이다. 결과물이 아예 안 오니까 며칠 안에 눈치챈다.
둘째, 돌긴 도는데 빈손이다. 읽어올 폴더가 비어 있거나 이름이 바뀌었는데, 프로그램 입장에선 "읽을 게 없었다, 정상 종료"다. 에러가 아니니 아무 소리도 안 난다. 이걸 무음 실패라고 부르는데, 성공했다는 신호와 아무 일도 안 했다는 신호가 똑같이 생겼다는 게 핵심이다. 요즘 내가 제일 경계하는 게 이거다.
셋째, 돌고 결과도 나오는데 내용이 틀렸다. 위의 링크 48개 사고가 여기다. 파일은 제 시간에 만들어졌고, 크기도 정상이고, 열면 글이 있다. 안쪽 값만 틀렸다. 무섭다는 표현이 과장이 아니고, 이건 사람이 안 읽으면 영원히 안 걸린다.
▲ 자동화 실패 유형 3가지와 각각의 발각 난이도 비교 (자체 제작 이미지)
셋 중에 첫 번째만 저절로 들킨다. 나머지 둘은 누가 봐주지 않으면 안 들킨다. 그래서 점검이 필요한 거였다.
3. 점검을 사람이 하면 결국 안 하게 된다
처음엔 단순하게 갔다. 아침에 커피 마시면서 결과 폴더 한 번 열어보기. 사흘 갔다ㅋ 나흘째부터는 폴더를 열긴 여는데 눈이 안 읽는다. 파일이 있다는 것만 확인하고 닫는 거지.
이게 당연한 거라고 본다. 매일 아무 문제 없는 걸 확인하는 일은 지루하고, 지루한 일은 사람이 못 지킨다. 자동화를 왜 만들었는지 생각하면 앞뒤가 안 맞기도 하고. 반복이 싫어서 자동화를 만들어놓고, 그걸 감시하는 반복을 새로 만든 셈이니까.
그래서 방향을 뒤집었다. 잘 돌 때는 나한테 아무것도 보내지 마라. 대신 이상하면 시끄럽게 울려라. 이 순서를 반대로 하면 망한다. 매일 "정상입니다" 알림이 오면 일주일 만에 그 알림을 안 읽게 되고, 안 읽는 알림은 없는 알림이다.
시킬 때 검증 방법까지 같이 붙이는 습관은 프롬프트 편에서 이미 다뤘으니 여기선 넘어간다. 거기까진 "한 번 시킬 때 잘 시키는 법"이고, 지금 얘기는 "한 달 뒤에도 도는지 보는 법"이라 결이 좀 다르다.
4. 내가 붙인 점검 3층: 살았나, 왔나, 말이 되나
결국 점검 스크립트를 따로 짰다. 짰다고 하면 거창한데, 클로드코드한테 한국어로 시킨 거다. 층이 셋이다.
1층, 살았나. 정해진 시각에 실행되게 등록해둔 게 아직 등록돼 있는지 본다. 맥은 launchd라는 기본 스케줄러로 정해진 시각에 프로그램을 깨우는데, 이 등록이 조용히 풀려 있는 걸 두 번 겪었다. 그래서 목록에 이름이 있는지, 마지막 종료 코드가 0(정상)인지만 확인한다.
2층, 왔나. 결과물 파일이 오늘 날짜로 만들어졌는지, 크기가 0바이트는 아닌지 본다. 여기서 위의 두 번째 유형(빈손 종료)이 대부분 걸린다. 파일은 있는데 어제 날짜면 그건 안 돈 거다.
3층, 말이 되나. 여기가 제일 중요하고 제일 대충 만들어도 된다. 어제 12건이었는데 오늘 0건이면 이상하다. 링크가 어제 480개였는데 오늘 432개면 뭔가 끊긴 거다. 정교한 검사 필요 없다. 어제랑 비교해서 숫자가 튀면 알려달라, 딱 이 정도가 8할을 잡는다.
▲ 자동화 점검 3단계와 각 단계에서 잡히는 실패 유형 (자체 제작 이미지)
세 층 다 실패하면 텔레그램으로 한 줄 온다. 어느 자동화가, 몇 층에서, 무슨 값 때문에 걸렸는지. 원인까지 안 적히면 알림을 받고도 뭘 봐야 할지 몰라서 그냥 넘기게 되더라.
여기서 한 가지. 점검 스크립트가 파일을 지우거나 고치게 두면 안 된다. 점검은 읽기만 하고 알리기만 한다. 고치는 건 내가 본 다음에 시킨다. 어디까지 자동으로 풀어주고 어디서 물어보게 할지는 권한 세팅 편에 정리해뒀다.
5. 점검기가 죽으면 아무도 안 알려준다
여기서 구멍이 하나 남는다. 잘 돌 때 조용하기로 했으니, 조용한 게 정상이다. 그런데 점검기 자체가 죽어도 조용하다. 두 상태가 화면상 완전히 똑같다ㅠㅠ
그래서 두 개를 더 붙였다.
하나는 주 1회 생존 신호다. 월요일 아침에만 "지난주 점검 7회 전부 통과" 같은 한 줄이 온다. 이게 안 오면 점검기가 죽은 거다. 원래 이런 걸 데드맨 스위치라고 부른다더라. 기관사가 손을 놓으면 열차가 스스로 서는 장치 이름인데, 신호가 오는 걸 확인하는 게 아니라 신호가 끊긴 걸 확인한다는 게 요지다.
다른 하나는 일부러 고장 내보기. 한 달에 한 번쯤 입력 폴더 이름을 잠깐 바꿔놓고 알림이 오는지 본다. 안 오면 점검이 고장 난 거고, 오면 안심하고 폴더 이름을 되돌린다. 소방훈련이랑 똑같다. 이거 처음 해봤을 때 세 개 중 하나가 알림을 안 보내고 있었다. 만들어놓고 한 번도 안 울려서 잘 되는 줄 알았던 거지.
클로드코드에는 특정 작업 전후에 내 스크립트를 자동으로 끼워 넣는 훅이라는 기능도 있다. 정해진 시각 실행 말고, 특정 동작이 일어날 때마다 점검을 붙이고 싶으면 이쪽이 편하다. 설정 파일 위치는 공식 문서에 정리돼 있고, 나는 아직 이건 얕게만 써봤다.
6. 손은 얼마나 드나, 그리고 안 해도 되는 사람
솔직히 말하면 자동화 하나당 20~30분쯤 들었다. 만드는 데 두 시간 걸린 자동화에 30분을 더 얹는 셈인데, 처음엔 아깝게 느껴졌다. 지금은 생각이 바뀌었다. 점검이 없는 자동화는 자산이 아니라 언젠가 터질 빚이다. 링크 48개를 되살리는 데 든 시간이 점검 붙이는 시간보다 훨씬 길었으니까.
그래도 다 붙일 필요는 없다. 안 붙여도 되는 쪽부터 말하면,
- 내가 매일 눈으로 보는 것. 아침 브리핑은 안 오면 그날 바로 안다. 점검이 이미 내 눈이다.
- 한 번 쓰고 버리는 일회성 작업. 경비 보고서처럼 만들고 바로 확인하는 건 필요 없다.
- 틀려도 손해가 없는 것.
붙이는 게 나은 쪽은 이렇다.
- 결과를 며칠 뒤에 열어보는 것. 조용히 썩어도 모른다.
- 남에게 나가는 것. 메일이든 보고서든, 틀린 채로 나가면 회수가 안 된다.
- 다른 자동화의 입력이 되는 것. 이게 제일 위험하다. 하나가 빈손으로 끝나면 뒤에 줄줄이 달린 것들이 다 빈손인데, 각각은 전부 "정상 종료"로 찍힌다. 크롤링으로 자료를 모아 표로 넘기는 식으로 여러 단계를 이어붙였다면 무조건 붙이는 게 맞다.
▲ 점검 자동화 도입 전후의 고장 발견 시간 비교 (자체 제작 이미지)
참고로 코워크처럼 정기 리포트를 받아보는 방식은 리포트 자체가 도착 여부를 알려주는 구조라 결이 좀 다르다. 그쪽 세팅은 /schedule 편에 따로 써뒀고, 도구를 뭘 고를지 아직 안 정했다면 3가지 비교부터 보는 게 순서다.
7. 정리
자동화를 만드는 재미는 만들 때 끝난다. 그 뒤로는 관리다. 이게 시시한 얘기 같지만, 나처럼 여러 개를 붙여두는 사람일수록 어느 순간부터 뭐가 돌고 뭐가 멈췄는지 스스로도 파악이 안 된다. 개수가 다섯 개를 넘어가면 확실히 그렇더라.
거창하게 갈 필요는 없다고 본다. 어제랑 오늘 숫자를 비교해서 튀면 알려달라, 이 한 줄짜리 점검만 붙여도 무음 실패는 거의 다 걸린다. 나머지는 겪으면서 붙이면 된다. 나도 로컬 모델 실측이나 권한 오류 삽질처럼 한 번 데이고 나서 하나씩 늘린 거지, 설계해서 만든 게 아니다.
잘 알지도 못하면서 주절거린 것 같긴 한데, 4일 날린 값은 했다고 본다.
3줄 요약 - 자동화는 에러 내면서 안 죽는다. 돌긴 도는데 빈손이거나 값이 틀린 채로 조용히 산다. - 점검은 사람이 못 지키니 자동화한다. 잘 돌 땐 조용히, 이상할 때만 시끄럽게. - 살았나·왔나·말이 되나 3층이면 충분하고, 점검기 자체의 생존 신호를 주 1회 따로 받는다.
자동화 여러 개 굴리는데 마지막으로 결과물 열어본 게 언제인지 기억 안 나면, 오늘 한 번만 열어보자. 나처럼 4일 뒤에 알지 말고. 화이팅!
이 글은 정보 제공 목적이고, 작성 시점(2026년 8월) 기준이다. 도구의 기능·설정 위치·요금은 공식 페이지에서 바뀔 수 있으니 적용 전에 원문을 한 번 확인하는 걸 권한다. 본문의 사고 사례와 소요 시간은 내 환경(맥, 개인 볼트)에서 겪은 것이라 그대로 재현되지 않을 수 있다. 특정 제품 사용을 권유하거나 결과를 보장하지 않는다.
참고한 공식 자료 - 클로드코드 개요: code.claude.com/docs - 설치·설정: code.claude.com/docs/setup - 설정 파일(settings) 위치와 항목: code.claude.com/docs/settings - 훅(특정 작업 전후 자동 실행): code.claude.com/docs/hooks - 맥 정기 실행(launchd) 공식 문서: Apple Developer, Creating Launch Daemons and Agents