알아서 돌아가면 편할 줄 알았다
내 환경에서는 Hermes의 예약 실행과 메신저 보고를 사용했다. 반복해서 확인하고 정리하는 일을 여기에 맡겼다. 내가 매번 말을 걸지 않아도 알아서 결과를 가져오길 바랐다.
6월에 Ubuntu 미니 PC에 Hermes를 설치했다. 모니터링 프로필도 그쪽으로 옮기고, 같은 작업이 두 번 돌지 않게 Mac 쪽은 껐다.
보고는 늘었는데 다 읽지 않았다
처음엔 프로필이 잘 도는지만 봤다. 프로필이 늘면서 보고도 늘었다. 그런데 나는 보고를 다 읽지 않았고, 읽은 것 중에서도 실제로 쓴 건 일부였다. 보고가 쌓이니 오히려 뭘 볼지 고르는 일이 생겼다.
6월에 프로필마다 무슨 일을 맡길지 다시 정리했다. 몇 가지 운영 방식을 검토했지만, 계속 쓸 만한 것만 남겼다. 5월 말에 살펴본 작업 관리 도구도 이때까지 보류해 뒀다.
AI가 판단할 필요 없는 일
서비스 상태 확인은 절차가 분명했다. 같은 주소에 요청하고 응답을 비교하면 됐다. 매번 AI가 판단할 일이 아니었다.
그래서 상태 점검은 규칙대로 도는 스크립트로 바꾸고, 상태가 달라질 때만 알리게 했다. 8월 말에 정상 점검을, 9월 초에 장애·복구 알림을 만들었다. 알림을 보내는 기준은 문제없을 때는 조용한 모니터에 적었다.
계속 맡길 일을 정할 때 쓰는 순서를 그림으로 옮겼다. 이 분류 자체를 자동으로 하지는 않는다.
무엇을 읽고 무엇을 바꿀 수 있나
구현이 빨리 끝나도 확인할 게 남았다. 어떤 파일을 읽고 고칠 수 있는지, 결과를 어디에 올리는지, 실패하면 뭐가 남는지.
블로그 통계를 갱신할 때는 올릴 파일 하나만 읽고 쓸 수 있는 계정을 썼다. 이건 Hermes 기능이 아니다. 자동화 도구에 일을 맡기려고 내가 따로 좁혀둔 권한이다. 실제 흐름은 컴퓨터를 꺼도 통계가 갱신되도록에 있다.
예약 시각에 실행할 일, 결과를 알릴 조건, 그 결과를 보고 바꿀 일은 나눠 볼 수 있었다. 모니터가 장애를 알리는 것과 원인을 판단해 운영을 수정하는 것은 다른 일이다. 위 도식도 실제 설치된 모든 자동화의 현황표가 아니라 작업을 나눌 때 쓴 생각의 순서다.
계속 쓸까
당시에는 작업이 끝났다는 알림을 받은 뒤 그 결과를 실제로 쓰는지도 살폈다. 현재 남아 있는 예약 작업 전체를 이번 글에서 다시 점검한 것은 아니다. 절차가 정해진 일은 스크립트로 돌리고, 판단이 필요한 일은 AI와 함께 보되 중요한 변경은 직접 확인한다.
효과를 숫자로 비교하지는 못했다. 실제로 쓴 결과, 다시 확인하는 데 든 시간, 실패했을 때 한 일을 적어볼 생각이다.