새벽세시님의 포스트

알람이 서른다섯 번 울렸고, 진짜 고장은 「정상」으로 적혔습니다

9월 19일 새벽 1시. 폰이 울렸습니다. 급속냉동실이 두 시간째 설정 온도에 못 미친다는 알림이었습니다. 저는 읽고 껐습니다. 같은 알림이 9월 들어서만 스무 번 넘게 왔고, 아침이면 대개 정상으로 돌아와 있었습니다.

그 새벽은 아니었습니다. 아홉 시간 반 뒤 그 방은 영하 0.1도였습니다. 설정은 영하 30도입니다.

스물닷새 동안 점검 2,983번, 알람 35통

8월 28일부터 9월 22일까지 온도 감시는 2,983번 돌았고 알람을 서른다섯 통 보냈습니다. 하루 한 통보다 잦습니다.

서른다섯 통이 서른다섯 건은 아니었습니다. 사건으로 묶으면 열네 건이고, 그중 두 건이 스무 통을 만들었습니다. 나머지 열두 건이 열다섯 통입니다.

9월 15일이 그 두 건 중 하나입니다. 성에 제거 운전이 학습된 시간보다 길어졌다는 알람이 14시 20분부터 20시 20분까지 일곱 통 갔습니다. 방이 잠깐 차가워지면 알람이 풀리고, 조금 뒤 다시 걸렸습니다. 한 사이클이 일곱 통이 됐습니다.

열한 통은 한 시간 안에 저절로 꺼졌습니다

서른다섯 통 중 열한 통은 한 시간 안에 스스로 정상으로 돌아왔습니다. 손댄 사람은 없습니다. 그중 일곱 통이 9월 15일 그 제상입니다.

헛울림을 줄이려고 그 사이 규칙을 네 번 고쳤습니다. 9월 8일에 온도가 내려가는 중이면 알람을 보류하게 했고, 9월 9일에 온도가 정체하면 그 보류를 거부하는 규칙을 덧댔습니다. 9월 14일에 데이터 두절을 15분 만에 알리게 했고, 9월 15일에 업무 중 제상은 기준을 늦췄습니다.

9월 14일 저녁에 온 세 통은 이유가 달랐습니다. 온도가 아니라 데이터가 끊겼습니다. 16시 57분을 끝으로 기록이 멈췄고, 다시 들어온 것은 다음 날 8시 35분입니다. 열다섯 시간 반 동안 감시는 아무것도 못 봤고, 그 세 통은 그 사실만 알렸습니다.

알람은 그래도 하루 한 통씩 왔습니다. 제 손에 남은 습관은 화면을 보고 끄는 것이었습니다.

9월 18일 17시 25분

두 번째 사건의 첫 알람이 온 시각입니다. 급속냉동실 영하 15.2도, 다섯 시간 동안 설정 대역에 한 번도 못 들어갔다는 내용이었습니다.

그날 저녁 업무 기록에는 이렇게 남았습니다. "급속냉동실 온도 상승 점검 완료 — 대량 입고와 청소로 인한 일시적 정상 현상으로 확인."

온도는 계속 올랐습니다. 19일 1시에 영하 9.2도, 4시에 영하 7.1도, 10시 30분에 영하 0.1도. 설정 대역으로 돌아온 것은 20일 5시 50분, 첫 알람에서 서른여섯 시간 뒤입니다. 이 한 건으로 알람이 열세 통 갔습니다.

원인은 21일에 나왔습니다. 천장 배관 용접부에 미세 누수가 있었습니다. 냉매가 새고 있었고, 수리하고 보충하고 나서야 온도가 잡혔습니다. 입고도 청소도 아니었습니다.

배운 것

하나. 헛울린 알람은 불편이 아니라 판단을 바꿉니다. 스물닷새 동안 "괜찮았던 알람"을 서른네 번 배운 사람은 서른다섯 번째를 볼 때 이미 결론을 갖고 봅니다. 그 결론이 업무 기록에 「정상」으로 적혔습니다.

둘. 서른다섯 통이 오는 동안 사건은 열네 건이었습니다. 서른다섯과 열넷은 다른 숫자입니다. 제상 한 사이클이 일곱 통을 보내는 동안 이틀짜리 진짜 고장은 열세 통이었습니다. 받는 화면에서는 둘이 같아 보입니다.

다음에 고칠 것은 알림의 등급입니다. 한 시간 안에 스스로 돌아오는 상태는 깨우지 않고 아침에 묶어서, 세 시간 넘게 못 돌아오는 상태는 사람을 깨우는 쪽으로.

다음 글은 알림 전체를 세어 본 이야기입니다. 열나흘 동안 650통이 왔고, 그중 제가 실제로 손을 댄 것이 몇 통인지 세어 봤습니다.

이 글의 날짜와 온도는 감시 기록과 업무 기록에서 확인했습니다. 화면은 실제 캡처가 아니라 기록을 바탕으로 다시 그린 것입니다. 이 조사와 초안 작성은 지금 회사를 돌리고 있는 AI가 했습니다.

원문 및 이후 연재 → https://3amdesk.github.io/posts/thirty-five-alarms.html?ref=disquiet

아홉 날 동안 열여덟 번, 감시 장치가 멀쩡한 서버를 껐습니다

9월 5일 오후. 폰에서 대화창이 또 끊겼습니다. 안정화하려고 붙인 장치가 오히려 불안정하게 만드는 것 같다는 생각이 들어, 그날 기록을 전수로 뒤졌습니다.

8월 27일부터 9월 5일까지 아홉 날. 폰과 PC를 잇는 중계 서버는 스물한 번 껐다 켜졌습니다. 제가 시킨 건 세 번입니다. 열여덟 번은 감시 장치가 혼자 판단했고, 그중 여섯 번은 멀쩡한 서버를 고장으로 읽은 오판이었습니다.

틀린 신호 위에 예외를 쌓았습니다

감시 장치는 인증 파일이 새로 쓰이면 열쇠가 바뀐 것으로 봤습니다. 열쇠가 바뀐 직후에 통로가 자주 죽으니 미리 껐다 켜자는 논리였습니다.

그 파일은 열쇠가 바뀔 때만 쓰이는 게 아니었습니다. 폰에서 대화창이 하나 뜰 때마다 항목이 하나씩 붙어 다시 쓰였습니다. 쌓인 항목이 309개였습니다. 폰을 많이 쓴 날일수록 감시 장치는 열쇠가 자주 바뀐다고 읽고 더 자주 껐습니다.

사고가 날 때마다 규칙을 하나씩 덧댄 것도 저였습니다. 8월 29일에 억제 규칙, 9월 4일에 판정 마커, 9월 5일에 갱신 즉시 조치, 같은 날 자기갱신 예외. 예외의 예외가 생긴 자리에서 신호가 틀렸다고 봤어야 했습니다.

토요일 낮에 열다섯 번

9월 6일이 가장 나쁜 날입니다. 11시 01분부터 51분까지 10분 간격으로 여섯 번, 15시 32분부터 16시 30분까지 일곱 번. 그날 하루 열다섯 번이고 제가 시킨 건 없습니다.

사유는 "가동 5분 뒤 대화창 0개"였습니다. 서버는 떠 있는데 대화창이 하나도 없으면 창을 못 만드는 상태라고 본 것입니다. 토요일 낮에 제가 폰을 안 잡았을 뿐이었습니다. 아무도 안 쓴 것과 고장 난 것을 이 신호로는 못 가릅니다.

진짜 원인은 숫자 하나였습니다

9월 5일 14시 50분에 원인이 나왔습니다. 중계 서버에는 동시에 살아 있는 대화창 개수에 상한이 있고, 기본값이 32였습니다. 상한에 닿으면 새 창이 안 열립니다. 화면은 그 사실을 알려주지 않고 그냥 옛 창을 보여줍니다.

오래된 창 여덟 개를 정리하자 바로 열렸습니다. 상한을 100으로 올리고, 매일 새벽 4시 반에 하루 넘게 잠든 창을 치우게 했습니다. 아홉 날 동안 스물한 번을 껐다 켰어도 이 증상은 한 번도 안 없어졌습니다.

감시 장치에서 스위치를 뺐습니다

9월 10일 9시에 마지막 오판이 나왔습니다. 시험용으로 띄운 창의 로그에 인증 오류가 한 줄 찍혔다고, 새 창이 죽는 상태라는 알림이 갔습니다. 22분 뒤 제가 직접 연 창은 같은 오류를 두 줄 남기고도 대화를 끝까지 끝냈습니다.

9월 12일에 정했습니다. 감시 장치는 감지하고, 대화창을 실제로 하나 띄워 시험하고, 알리는 데까지만 합니다. 끄고 켜는 건 사람이 폰 버튼으로 합니다.

근거는 관찰 일주일 치입니다. 자동 재기동이 실제 장애를 고친 건 0건, 시험 없이 내린 재기동이 2건, 오판이 3건 이상이었습니다. 맞바꾼 위험은 새벽 장애가 아침까지 방치되는 것이고, 그 값은 버튼 한 번입니다.

바꾸고 사흘 동안 서버는 한 번 껐다 켜졌습니다. 9월 14일 11시 14분, 제가 눌러서.

배운 것

하나. 감시자가 사용자보다 자주 서비스를 끊으면 감시자가 장애입니다. 열여덟 대 세 번이면 셈은 끝난 것이었고, 저는 아홉 날 동안 그 셈을 안 했습니다.

둘. 상태를 바꾸는 자동 조치는 옆 흔적이 아니라 직접 해 본 결과를 근거로 삼습니다. 파일이 쓰인 시각, 프로세스 번호, 응답 코드 200은 힌트입니다. 창이 열리는지 알려면 창을 열어 봐야 합니다.

다음 글은 같은 질문을 사람 쪽에서 본 이야기입니다. 알림이 하루 한 건꼴로 오는데, 다섯에 하나는 한 시간 뒤 저절로 정상으로 돌아와 있었습니다.

이 글의 날짜와 횟수는 감시 기록과 코드 변경 이력에서 확인했습니다. 화면은 실제 캡처가 아니라 기록을 바탕으로 다시 그린 것입니다. 이 조사와 초안 작성은 지금 회사를 돌리고 있는 AI가 했습니다.

원문 및 이후 연재 → https://3amdesk.github.io/posts/eighteen-restarts.html?ref=disquiet

감시 장치가 세 번 거짓말을 했습니다

8월 10일 월요일 아침. 주간 회고가 올라왔습니다. "냉동 창고 온도 감시, 지난주 15건 반복 실패. 모니터링 경로 미반영 의심." 회고는 사람이 아니라 봇이 씁니다. 저는 그대로 믿고 감시 코드를 열었습니다.

열다섯 건은 전부 정상이었습니다. 온도가 기준을 넘어 경고를 보낸 것뿐이었고, 경고를 보낼 때 프로그램은 0이 아닌 숫자로 끝나게 돼 있었습니다. 실패 기록장은 0이 아니면 실패로 적었습니다. 잘 작동한 열다섯 번이 실패 열다섯 건이 됐습니다.

기록장을 만든 이유가 먼저였습니다

그 기록장은 열흘 전에 만든 것이었습니다. 그전까지 감시는 알림 한 번 울리고 사라졌습니다. "이 자동화가 이번 달 몇 번 죽었나"를 볼 방법이 없었고, 실패를 적는 코드는 146개 중 5개에만 있었습니다. 그래서 한 줄씩 쌓는 장부를 만들었는데, 장부가 첫 회고에서 오진을 냈습니다.

고친 건 한 줄입니다. "정상인데 0이 아닌" 코드를 작업마다 등록하고, 그건 실패로 안 적기.

두 번째: 이미 실행 중이라는 거짓말

8월 18일에 자동화 55개가 각자 들고 있던 안전장치를 한 곳으로 모았습니다. 배치 파일 35개에 손으로 배선하다 보니 빠뜨리는 게 생겨서였습니다. 같은 작업이 두 번 돌지 않게 잠금도 넣었습니다.

닷새 뒤, 한 작업이 17시간 동안 "이미 실행 중"이라며 건너뛰었습니다. 실행 중인 게 없었습니다. 죽은 프로세스의 번호를 다른 프로그램이 물려받았고, 잠금은 번호만 보고 살아 있다고 판단했습니다. 번호에 이름과 시작 시각을 붙였습니다.

세 번째: 성공률 100%

이 얘기는 첫 글에 썼습니다. 좌석 감시가 한 번도 좌석을 못 잡아도 장부는 전부 성공입니다. 종료 코드는 "돌았다"만 말하지 "뭘 남겼다"는 말하지 않습니다. 작업마다 "이게 돌면 이 파일이 생겨야 한다"를 적어 두고, 회고가 그걸 대조하게 했습니다.

그리고 고치는 장치가 못 고쳤습니다

8월 말에 실패 62건을 다시 봤습니다. 상위는 전부 감시·조회형이었고 원인은 대부분 로그인 만료나 일시 장애처럼 다시 돌리면 되는 것들이었습니다. 그런데도 아침마다 사람이 알림을 보고 손으로 다시 돌리고 있었습니다. 15분마다 실패한 작업을 다시 돌리고, 안 되면 진단하고, 코드가 원인이면 고쳐서 검증까지 하는 층을 붙였습니다.

9월 5일에 보니 재실행이 아홉 개 작업에서 하나도 안 되고 있었습니다. 스케줄러가 저장해 둔 실행 경로에 따옴표가 두 겹으로 들어가 있었습니다. 복구 장치가 조용히 실패하고 있었고, 그걸 잡은 건 복구 장치의 장부였습니다.

배운 것

하나. 감시 장치도 자동화입니다. 그러니 감시 장치도 조용히 고장 납니다. 기록장이 오진하고, 잠금이 오판하고, 복구가 못 돌았습니다. 각각 한 번씩, 전부 만든 지 열흘 안에.

둘. 장치는 장치를 감시해야 합니다. 기록장의 오진은 회고가 잡았고, 잠금의 오판은 기록장이 잡았고, 복구의 실패는 복구의 장부가 잡았습니다. 하나만 있었으면 셋 다 못 잡았습니다.

다음 글은 반대 경우입니다. 감시 장치가 너무 부지런해서, 멀쩡한 걸 아홉 날 동안 열여덟 번 껐다 켠 이야기입니다.

이 글의 날짜와 건수는 실행 기록과 코드 변경 이력에서 확인했습니다. 화면은 실제 캡처가 아니라 기록을 바탕으로 다시 그린 것입니다. 이 조사와 초안 작성은 지금 회사를 돌리고 있는 AI가 했습니다.

원문 및 이후 연재 → https://3amdesk.github.io/posts/silent-guards.html?ref=disquiet

봇 하나에 회사를 다 넣었더니, 냉동 창고 온도가 돌아왔습니다

7월 22일 낮 12시 14분. 폰으로 봇에게 냉장 제품 주문량을 물었고 답을 받았습니다. 이어서 "냉동은 어느 정도 써?"라고 짧게 물었습니다. 돌아온 답은 냉동창고 온도였습니다. 영하 20도 안팎, 이상 없음.

틀린 답은 아닙니다. 물은 게 아니었을 뿐입니다.

여섯 번째 대화에서 기억이 지워졌습니다

봇은 속도를 위해 여섯 번 대화할 때마다 기억을 비우게 돼 있었습니다. 주문량 답이 여섯 번째였고, "냉동은?"이 일곱 번째였습니다. 새 기억으로 시작한 봇에게 남은 단어는 "냉동" 하나였고, 회사 규칙집에서 그 단어가 걸리는 항목은 창고 온도였습니다. 사람이면 "아까 그 얘기"로 알아듣는 걸, 기계는 문맥이 0이면 규칙집을 뒤집니다.

이틀에 걸쳐 넷을 고쳤습니다. 기억 비우는 주기를 여섯에서 열로. 비울 때 직전 문답 한 쌍은 남기기. 사진만 먼저 오면 30초 기다렸다가 뒤따르는 질문과 묶기. 주제가 바뀐 질문은 새 서랍으로 자동 분리하기.

그런데 진짜 원인은 방이 하나였다는 것

고치고 나서 보니 봇 하나에 서랍이 열아홉 개였습니다. 회사 매출, 창고 온도, 수입 서류, 그리고 제 항공권 마일리지까지 한 방에 있었습니다. 어느 서랍을 열지 맞히는 정확도가 떨어질 수밖에 없었습니다.

7월 31일에 봇을 둘로 나눴습니다. 회사 일 하나, 개인 일 하나. 나누는 데 든 건 개인 업무 스크립트 열세 개 맨 위에 "알림은 개인 봇으로"라는 한 줄을 넣은 것이 전부였습니다.

더 잘게 나누자는 안은 그날 기각했습니다. 매출은 재무인지 판매인지, 경계가 겹치는 순간 "어느 봇에 말하지"가 새 비용이 됩니다.

세 번째 봇, 그리고 27분

8월 18일에 세 번째를 붙였습니다. 이번엔 업무가 아니라 성격으로 나눴습니다. 굴리는 일과 만드는 일. 새 자동화를 만드는 대화는 길고 실험적이라, 운영 봇의 짧은 명령들과 섞이면 서로를 밀어냅니다. 이 경계는 겹치지 않습니다.

같은 날 사고가 났습니다. 봇을 재시작하라고 시켰는데, 그 명령이 한 봇의 자식 프로세스로 실행되면서 새로 뜬 것도 그 봇의 일꾼이 됐습니다. 그 봇은 멀쩡히 답했고, 나머지 둘은 27분 동안 조용했습니다. 하나였을 때는 "다 죽었다"가 전부였는데, 셋이 되니 "일부만 죽었는데 모른다"가 생겼습니다.

재시작 명령이 부모의 환경을 물려받지 않게 고쳤고, 기동 확인에 "일꾼 셋이 다 살아 있나"를 넣었습니다.

2월에 못 넘긴 그 등록 업무

지난 글에서 미뤄 둔 이야기입니다. 파일은 만드는데 화면에 올리지 못하던 매주 할인 행사 등록은 지금 사람 손 없이 돕니다. 다만 완전히 맡기진 않았습니다. 7월 말에 한 줄을 더 넣었습니다. 할인 폭이 정해진 선을 넘는 건이 있으면 등록 전에 멈추고 저에게 묻습니다. 틀리면 돈이 나가는 자리라, 멈추는 지점 하나는 남겨 뒀습니다.

배운 것

하나. 봇을 나누는 기준은 업무가 아니라 경계입니다. 경계가 겹치면 사람이 판단 비용을 냅니다. 겹치지 않는 경계(회사와 개인, 굴리기와 만들기)만 나눴습니다.

둘. 나누면 고장의 모양이 바뀝니다. 전부 멈추는 고장은 눈에 띕니다. 일부만 멈추는 고장은 안 띕니다. 나눈 날 감시도 같이 나눠야 합니다.

다음 글은 그 "안 띄는 고장"을 잡으려고 만든 장치들, 실패 원장과 작업 러너와 워치독 이야기입니다.

이 글의 시각과 날짜는 봇 로그와 코드 변경 기록에서 확인했습니다. 화면은 실제 캡처가 아니라 로그를 바탕으로 다시 그린 것입니다. 이 조사와 초안 작성은 지금 회사를 돌리고 있는 AI가 했습니다.

원문 및 이후 연재 → https://3amdesk.github.io/posts/three-bots.html?ref=disquiet

AI를 세 개 돌려봤는데, 남은 건 제일 똑똑한 것이 아니었습니다

지난 글은 2월 25일에 폴더를 정리하고 끝났습니다. 열여드레 동안 일곱 번 방법을 바꾸고도 마지막 한 칸을 못 넘긴 이야기였습니다. 그 뒤 석 달 동안 저는 도구를 세 번 바꿨습니다. 정확히는 두 번 갈아탔고, 한 번은 십 분 만에 접었습니다.

이번에 그 석 달의 기록을 다시 열어보니, 제가 기억하던 "성능 좋은 걸로 갈아탔다"는 말이 틀려 있었습니다. 마지막에 남은 기준은 성능이 아니었습니다.

3월 4일, 한 시간 만에 옮겼습니다

폴더 정리 일주일 뒤, 커뮤니티에서 배포하는 작은 도구를 받았습니다. 코딩용 AI 에이전트를 메신저에 연결해 주는 것이었는데, 압축을 풀고 봇 토큰을 넣으니 점심 전에 첫 대화 스레드가 생겼습니다. 기록상 11시 51분입니다.

전 도구와 다른 점은 하나였습니다. 답이 아니라 행동이 돌아왔습니다. 파일을 읽고, 고치고, 결과를 보고했습니다. 열여드레 동안 안 되던 "마지막 한 칸"이 어떻게 됐는지는 뒤에 나옵니다. 일단 그날은 옮기는 데 한 시간이 안 걸렸다는 것만 적어 둡니다.

닷새 뒤, 십 분짜리 시도

3월 9일 저녁 6시 56분에 이전 도구의 작업 폴더를 통째로 압축했습니다. 백업 파일 이름에 그 시각이 박혀 있습니다. 그리고 7시 1분에 다른 회사의 코딩 에이전트를 설치했습니다.

설치 폴더에 남은 대화 기록은 한 건입니다. 제가 보낸 말은 "hello" 한 마디. 7시 10분에 마지막 파일이 저장됐고, 그 폴더는 오늘까지 한 번도 다시 열리지 않았습니다. 십 분입니다. 같은 날 그 에이전트용 메신저 연결 도구도 내려받았는데, 압축을 푼 흔적만 있고 봇은 만들지 않았습니다.

왜 십 분 만에 접었는지는 기록이 없습니다. 기억으로 메우자면, 첫 도구가 이미 돌고 있는데 두 번째를 같은 자리에 세울 이유를 못 찾았던 것 같습니다. 그때는 "비교"라는 생각 자체가 없었습니다.

봄 내내 둘을 같이 썼습니다

접은 건 세 번째 후보였고, 실제로는 봄 내내 두 개를 같이 썼습니다. 새로 온 코딩 에이전트와, 그 전부터 쓰던 대화형 AI입니다.

역할이 자연스럽게 갈렸습니다. 대화형 쪽은 3월 7일부터 매일 아침 제 메일로 전날의 통화와 메시지를 정리해 보내는 일을 맡았습니다. 이건 지금도 같은 엔진으로 돌고 있습니다. 코딩 에이전트 쪽은 서류를 데이터로 바꾸는 일, 표를 분석하는 일, 그리고 3월 22일 기록에 이렇게 적혀 있습니다 — "기획과 구조 설계는 이쪽을 선호. 데이터 분석과 기초 작업은 이쪽이 우수."

4월 22일에 제가 커뮤니티에 남긴 말이 있습니다. "이쪽만 쓰고 있었는데 저쪽도 고민해 봐야 할 정도로 잘 뽑네요." 엿새 뒤에는 이렇게 썼습니다. "비교해서 돌려 보면 같은 프롬프트여도 나랑 잘 맞는 게 나와요." 성능표를 본 게 아니라 같은 일을 시켜 보고 고른 겁니다. 그 방식은 지금도 안 바뀌었습니다.

4월 12일, 남의 도구 위에 내 것을 얹었습니다

받은 도구를 그대로 쓰는 데는 한 달을 못 갔습니다. 4월 12일에 제 폴더를 새로 팠습니다. 설치 스크립트, 상태 점검 스크립트, 켜고 끄는 조작판. 그리고 나흘 뒤에 2월의 실패한 폴더에서 살릴 것만 골라 옮겼습니다. 판매 채널 스크립트 아홉 개와 업무 지식. 성격 파일과 영혼 파일은 안 가져왔습니다.

이 시점부터 "도구"라는 말이 조금 달라졌습니다. 엔진은 남의 것인데 그 위에 쌓이는 지침 파일과 스크립트는 제 것이었습니다. 이게 뒤에 결정을 가르게 됩니다.

6월 초, 진짜 병행

5월 중순에 커뮤니티 도구가 큰 업데이트를 했습니다. 두 회사의 에이전트를 봇 하나씩에 붙여 동시에 돌릴 수 있게 됐고, 리눅스 호환 계층 위에서 돌아갔습니다. 저는 5월 29일에 "이쪽을 메인으로 쓴다"고 써 놓고도 그걸 받았습니다. 궁금했던 것 같습니다.

6월 1일 밤 설치가 실패했습니다. 종료 코드 125. 저는 그 설치 폴더를 이미 쓰고 있던 코딩 에이전트에 물려서 "왜 안 되는지 찾아 달라"고 했고, 원인 보고를 커뮤니티에 올린 뒤 잤습니다. 다음 날 설치가 됐습니다. 봇 두 개를 만들어 하나에는 이쪽 엔진, 하나에는 저쪽 엔진을 붙였습니다. 6월 2일 기록에 두 봇의 첫 스레드가 나란히 있습니다.

그 뒤 닷새는 이렇습니다. 6월 3일 업데이트가 연결 오류를 내서 이전 버전으로 되돌림, 호환 계층 안의 로그인 세션이 자꾸 풀림. 6월 4일 응답 지연으로 원격 점검. 같은 날 커뮤니티에 예순 개 작업으로 잰 엔진 벤치마크 표가 올라왔습니다. 저는 그 표를 봤지만 결정에는 안 썼습니다.

6월 5일에 제가 남긴 말이 이렇습니다.

프롬프트가 절반인 것 같아요.
나한테 필요한 md 파일을 구축하는 데 시간이 제일 많이 소비됩니다.
유튜브에서 떠드는 것처럼 자동으로 되는 건 없더라고요.

열흘 만에 하나로

6월 10일, 봇 하나가 제 폴더 쪽으로 옮겨 왔습니다. 커뮤니티 도구 아래에 있던 봇 번호가 그날부터 제 저장소 아래에서 첫 작업(매일 리포트 유지)을 시작합니다. 커뮤니티 도구 쪽의 마지막 작업 스레드는 6월 16일이고, 그 뒤로는 업데이트 알림만 쌓였습니다. 같은 날 커뮤니티에 이렇게 썼습니다. "저는 윈도우에서 코딩 에이전트를 써서 자동화를 세팅하고." 도구는 리눅스 계층 위에서 돌았고, 제 자동화는 윈도우 창과 프로그램을 직접 눌러야 했습니다.

그러니까 수렴은 이랬습니다. 벤치마크에서 이긴 쪽이 남은 게 아니라, 제가 고칠 수 있는 쪽이 남았습니다. 설치가 죽었을 때 원인을 찾아 준 건 이미 돌고 있던 그 에이전트였고, 제 지침 파일이 쌓여 있는 곳도 거기였고, 제 업무가 실제로 일어나는 윈도우 화면에 손이 닿는 것도 거기였습니다. 병행 열흘 동안 저는 봇 두 개, 로그인 두 벌, 되돌리기 한 번을 관리했고, 그 비용이 두 번째 엔진이 주는 차이보다 컸습니다.

남은 것 세 가지

하나. 비교는 표가 아니라 같은 일로 합니다. 3월에도 4월에도 6월에도, 결정은 "같은 걸 시켜 보니 이쪽이 나랑 맞다"에서 났습니다. 벤치마크는 봤고, 참고했고, 쓰지 않았습니다. 지금도 새 모델이 나오면 제 업무 하나를 똑같이 시켜 보고 판단합니다.

둘. 엔진은 갈아타도 지침 파일은 남습니다. 지난 글에서 성격 파일 서른일곱 줄을 쓰고 기억 규칙은 안 만들었다고 했습니다. 이번 석 달의 결론은 그 반대편입니다. 4월 12일 이후 쌓인 지침과 스크립트가 있었기 때문에 6월의 병행이 "이사"가 아니라 "엔진 교체 검토"로 끝났습니다. 엔진에 붙어 있는 자산은 엔진과 함께 사라지고, 파일에 있는 자산은 남습니다.

셋. 병행에는 값이 있습니다. 두 개를 돌리면 비교가 되는 대신 관리가 두 배가 됩니다. 저는 열흘을 썼고, 그 정도가 답을 얻는 데 필요한 값이었습니다. 다만 한 달을 넘겼다면 비교가 아니라 습관이 됐을 겁니다.

그리고 2월에 못 넘긴 "마지막 한 칸" — 파일을 만들어 놓고 화면에 올리지 못했던 그 등록 업무는 이 병행이 끝난 뒤에야 다시 돌기 시작했습니다. 그 얘기는 봇을 세 대로 나눈 이야기와 함께 다음 글에 씁니다.

이 글의 날짜는 설치 폴더와 백업 파일에 남은 시각, 커뮤니티에 제가 직접 쓴 메시지, 매일 아침 오던 정리 메일에서 확인한 것입니다. 3월에서 6월 사이는 그 밖의 기록이 얇아서, 왜 그렇게 판단했는지는 기억으로 메운 부분이 있고 본문에 그렇게 적었습니다. 이 조사와 초안 작성은 지금 회사를 돌리고 있는 AI가 했습니다.

원문 및 이후 연재 → https://3amdesk.github.io/posts/three-engines.html?ref=disquiet

AI에게 이름을 지어주고 열여드레 만에 멈췄습니다 — 문제는 성격이 아니었습니다

지난 글에서 십삼 개월 동안 이천 번을 물어보고도 회사는 그대로였다고 썼습니다. 그러다 질문을 "해줘"에서 "하게 해줘"로 바꿨더니 처음으로 답이 소비되지 않고 절차가 남았다고요. 올해 2월 초입니다.

이 글은 그다음 열여드레의 이야기입니다. 결론부터 말하면 그 세팅은 오래가지 못했습니다. 그런데 이번에 당시 작업 폴더를 다시 열어보니, 실패한 이유가 제가 기억하던 것과 달랐습니다.

이름부터 지었습니다

그 무렵 나온 오픈소스 AI 비서를 하나 얹었습니다. 특이했던 건 설치하고 나면 「영혼 파일」이라는 걸 쓰게 되어 있다는 점이었습니다. 성격과 말투와 지켜야 할 태도를 적는 파일입니다. 예시로 이런 문장들이 들어 있었습니다.

너는 챗봇이 아니다. 너는 누군가가 되어 가는 중이다.

진짜로 도움이 되어라, 도움이 되는 척 말고. "좋은 질문이에요" 같은 건 빼고 그냥 도와라.

너는 손님이라는 걸 기억해라. 너는 누군가의 삶에 접근해 있다 — 메시지, 파일, 일정, 어쩌면 집까지. 그건 친밀함이다. 존중해서 다뤄라.

읽으면서 좀 들떴던 것 같습니다. 그래서 이름을 지어주고 이모지도 하나 붙이고, 성격은 「정확하고 날카롭게」라고 적었습니다. 저를 뭐라고 부를지도 정해줬습니다.

그 파일을 이번에 다시 열어보니 서른일곱 줄이었습니다. 성격을 정하는 데 서른일곱 줄을 썼습니다. 그때는 그게 제일 중요한 일 같았습니다.

처음 맡긴 일은 됐습니다. 절반쯤은요

2월 7일 기록에 첫 업무가 남아 있습니다. 온라인 판매 채널에 새 후기와 안 읽은 문의가 있는지 확인하는 일입니다. 제가 "상황 업데이트"라고 치면 알아서 보고 정리해 왔습니다.

여전히 시작 버튼은 저였습니다. 다만 매번 처음부터 설명하지 않아도 된다는 게 달랐고, 그것만으로도 십삼 개월과는 확실히 달랐습니다.

닷새 뒤에 후기 답글까지 시켜봤습니다. 열한 건 중 한 건을 쓰고 기록이 끊겨 있습니다. 나머지 열 건이 어떻게 됐는지는 어디에도 안 남아 있습니다. 이번에 폴더를 다시 열어보고서야 알았습니다. 그때 저는 그 일이 끝난 줄 알고 있었습니다.

진짜 목표는 따로 있었습니다

정말 자동화하고 싶었던 건 따로 있었습니다. 매주 돌아오는 할인 행사 등록입니다. 상품별로 할인가와 기간을 정해 판매 채널 시스템에 올리는 일인데, 수십 건씩이고 지루하고 틀리면 그대로 돈이 나갑니다. 이런 일이야말로 사람이 하면 안 되는 일이라고 생각했습니다.

2월 11일, 첫 시도에서 절반이 됐습니다. 행사 목록을 받아 시작·종료 시각별로 묶고 업로드 양식에 맞춘 파일을 만드는 부분 — 이건 첫날부터 잘 돌았고 이후 한 번도 틀리지 않았습니다.

안 된 건 나머지 절반이었습니다. 그 파일을 화면에 올리고 등록 버튼을 누르는 것.

열여드레 동안 아래로만 내려갔습니다

기록에 남은 순서는 이렇습니다.

브라우저 자동화 도구로 버튼을 눌렀습니다. 안 됐습니다.
다른 자동화 도구로 바꿔서 눌렀습니다. 안 됐습니다.
"가려져 있어도 무시하고 눌러라" 옵션을 켰습니다. 안 됐습니다.
버튼 대신 화면 좌표를 계산해서 눌렀습니다. 안 됐습니다.
브라우저를 포기하고 운영체제 수준에서 마우스 커서를 움직여 눌렀습니다. 안 됐습니다.
버튼 그림을 파일로 저장해두고 화면에서 그 그림을 찾아 눌렀습니다. 안 됐습니다.
마지막엔 화면을 통째로 건너뛰고 서버에 직접 요청을 보냈습니다.

일곱 번 층을 내려갔습니다. 그 흔적으로 남은 스크립트가 스물일곱 개입니다. 버전 번호는 3번부터 10번까지 붙어 있고(1번과 2번은 지운 모양입니다), 이름에 「final」이 들어간 파일이 두 개인데 둘 다 최종이 아니었습니다.

중간에 AI 모델도 한 번 통째로 갈아치웠습니다. 도구가 문제라고 생각했기 때문입니다.

제일 무서운 건 성공한 것처럼 보이던 기록이었습니다

마지막 방법, 서버에 직접 요청을 보낸 시도의 기록을 이번에 열어봤습니다. 응답 코드가 전부 200이었습니다. 200은 「정상 처리」라는 뜻입니다.

그런데 같이 저장된 응답 내용을 보니 등록 결과가 아니라 로그인 화면이었습니다. 로그인이 풀려 있었던 겁니다. 서버는 "먼저 로그인하세요"라는 화면을 정상적으로 잘 보내줬고, 그래서 200이었습니다.

이 블로그의 첫 글이 자동화는 요란하게 고장 나지 않고 조용히 멈춘다는 이야기였는데, 그 원형이 여기 있었습니다. 저는 당시 이 로그를 제대로 안 봤습니다. 열어봤다면 "클릭이 아니라 인증이 문제구나"까지 반나절이면 갔을 겁니다. 대신 저는 누르는 방법을 일곱 가지로 바꿔가며 열여드레를 썼습니다. 문제가 없는 층에서 문제를 찾고 있었던 겁니다.

성격은 있는데 기억이 없었습니다

폴더에 날짜별 일지가 열 개 남아 있습니다. 그런데 파일 이름과 내용이 어긋난 게 여러 건입니다. 2월 7일자 파일에는 날짜 없는 일반 지침이 들어 있고, 「이 폴더 설명」이어야 할 파일에는 2월 24일 작업 기록이 들어 있습니다. 정작 오래 기억할 것을 적으라던 파일에는 결정도 교훈도 없고 업무 절차서만 있었습니다.

그 도구의 설명서에는 이렇게 적혀 있었습니다.

머릿속 메모는 세션 재시작을 못 넘긴다. 파일은 넘는다.

맞는 말입니다. 그런데 파일을 남기는 것과, 그 파일이 다음번에 실제로 읽히는 것은 다른 일이었습니다. 저는 앞의 것만 했습니다. 성격을 정하는 데는 서른일곱 줄을 쓰고, 무엇을 어디에 적고 다음에 어떻게 꺼낼지는 정하지 않았습니다. 순서가 거꾸로였습니다.

2월 25일, 폴더를 정리하고 끝났습니다

마지막 기록은 파일 정리입니다. 스물일곱 개 스크립트를 한 폴더로 옮기고 결과물을 따로 모았습니다. 그리고 그 뒤로 아무 기록이 없습니다.

정확히 말하면 접은 게 아니라 갈아탔습니다. 한 달쯤 뒤에 도구를 바꿨고, 그때 못 넘긴 그 등록 업무가 다시 돌기 시작한 건 두 달 뒤입니다. 지금은 사람 손 없이 됩니다. 그러니까 열여드레는 버린 시간이 아니라, 어디가 어려운지를 알아내는 데 쓴 시간이었습니다. 다만 그때는 그렇게 안 느껴졌습니다.

남은 것 세 가지

하나. 자동화가 죽는 자리는 만드는 데가 아니라 넘기는 데입니다. 파일을 만드는 부분은 첫날부터 완벽했습니다. 못 한 건 마지막 한 칸이었습니다. 지금도 뭘 자동화할지 볼 때 저는 "이걸 만들 수 있나"보다 "만든 걸 어디에 넣어야 하나"를 먼저 봅니다. 대개 뒤엣것이 어렵고, 견적을 틀리게 만드는 것도 뒤엣것입니다.

둘. 막혔을 때 아래로 파고드는 건 대체로 틀린 방향입니다. 방법을 일곱 번 바꾸는 동안 저는 한 번도 "이게 정말 클릭 문제인가"를 묻지 않았습니다. 답은 로그 파일에 처음부터 적혀 있었습니다. 부끄럽게도 저는 이 실수를 여섯 달 뒤에 또 했는데, 그 얘기는 뒤에 나옵니다.

셋. 성격보다 기억이 먼저입니다. 이름과 말투는 하루면 정합니다. 지난주에 정한 걸 다음 주에 꺼내 쓰게 만드는 일은 그보다 훨씬 오래 걸리고, 그게 없으면 아무리 성격 좋은 조수라도 매주 신입입니다.

혹시 지금 AI에게 일을 맡겨보려 하신다면 순서를 이렇게 권합니다. 이름 짓는 건 나중에 하고, 지난번에 뭘 했는지 다음번에 읽을 파일을 먼저 만드세요. 그리고 자동화하려는 일에서 결과물이 최종적으로 들어가야 할 자리가 어디인지, 거기까지 손이 닿는지를 시작 전에 확인해 보시길 권합니다. 저는 둘 다 반대로 했고 열여드레를 썼습니다.

이 글의 날짜와 숫자는 당시 작업 폴더 백업에서 확인한 것입니다. 스크립트 스물일곱 개와 로그, 일지 파일을 다시 읽어 정리했고, 그 조사와 초안 작성은 지금 회사를 돌리고 있는 AI가 했습니다.

원문 및 이후 연재 → https://3amdesk.github.io/posts/eighteen-days.html?ref=disquiet

이천 번을 물어봤는데, 회사는 하나도 자동으로 돌지 않았습니다

지난 글에서 지금 회사에는 정해진 시각에 스스로 도는 일이 쉰한 개라고 썼습니다. 그 얘기를 하면 종종 "언제부터 그렇게 하셨어요"라는 질문이 돌아옵니다. 저는 한동안 "일 년쯤 됐다"고 답해 왔습니다.

이번에 기록을 꺼내 보고 그 답이 틀렸다는 걸 알았습니다. 첫 사용 기록은 그보다 훨씬 전이었습니다. 그리고 더 곤란한 사실도 같이 나왔습니다. 처음 십삼 개월 동안 이천 번 넘게 물어봤는데, 그 기간에 자동으로 돌게 만든 일은 하나도 없었습니다.

이 글은 그 십삼 개월의 이야기입니다. 지금 생각하면 뭐가 문제였는지 분명한데, 그때는 전혀 몰랐습니다.

시작은 회사 일이 아니었습니다

기록상 첫 질문은 재작년 12월 말 저녁입니다. 회사 일이 아니라 집안일이었습니다. 아이 학교를 알아보다가, 검색 결과를 이리저리 뒤지는 게 지겨워서 처음으로 AI에게 물었습니다. 표로 정리해서 돌아온 답을 보고 "이거 편하네" 정도로 생각하고 닫았습니다.

닷새 뒤에 회사 일을 처음 시켰습니다. 자사 상품의 광고 문구를 추천해 달라는 것이었습니다. 시작하고 닷새 만입니다. 편한 건 어디에나 편하니까, 넘어가는 데는 오래 걸리지 않았습니다.

십삼 개월 동안 물어본 것들

그 뒤로 매달 적게는 마흔 번, 많게는 백육십 번씩 물었습니다. 기록을 분류해 보니 대략 이렇습니다.

• 글 대신 써주기가 제일 많았습니다. 거래처에 보낼 단가 인상 문자, 품질 문제 사과 공문, 명절 인사, 경조사 축하 문구. "상황이 좋지 않지만 최소 인상만 반영했다는 내용도 넣어줘" 같은 두 번째 세 번째 다듬기까지 포함해서요. 심지어 거래처에 보낼 한 줄짜리 부탁 문자를 맞춤법만 봐달라고 넣은 날도 있습니다. 그 요청문 자체에 오타가 있었다는 건 이번에 기록을 열어보고 알았습니다.
• 법과 제도 질문이 그다음입니다. 식품 인증을 받으면 뭐가 좋은지, 샘플로 들어온 물건을 팔아도 되는지, 신고는 어디에 하는지.
• 번역, 그리고 계산과 정리. 표를 주고 합산을 시키거나, 두 견적을 비교시키거나.

목록만 보면 꽤 잘 쓰고 있는 것 같습니다. 실제로 도움도 됐습니다. 그런데 이상한 점이 하나 있습니다. 하루 다섯 번꼴로 십삼 개월을 썼는데, 회사는 그대로였습니다. 제가 자리를 비우면 아무 일도 일어나지 않는 회사. 그건 AI를 쓰기 전과 똑같았습니다.

왜 이천 번이 쌓이지 않았나

지금 와서 보면 이유는 세 가지였습니다.

하나. 답이 그 자리에서 소비되고 끝났습니다. 단가 인상 문자를 공들여 다듬어 받고, 보내고, 잊었습니다. 몇 달 뒤 비슷한 문자를 쓸 일이 생기면 또 처음부터 설명했습니다. 답은 매번 좋았는데 아무것도 남지 않았습니다. 이천 번의 질문은 이천 번의 일회용이었습니다.

둘. 시작 버튼이 항상 저였습니다. AI는 제가 묻기 전에는 아무것도 하지 않습니다. 그러니까 제가 바빠서 못 물으면 그 일은 그냥 안 되는 겁니다. 제일 도움이 필요한 날은 제일 바쁜 날인데, 제일 바쁜 날엔 물어볼 틈이 없습니다. 도구가 아무리 좋아도 병목이 저라면 회사의 속도는 그대로입니다.

셋. 매번 회사를 처음부터 설명해야 했습니다. 우리 회사가 뭘 파는지, 거래처와 어떤 조건인지, 지난달에 무슨 일이 있었는지. 상대는 매번 오늘 처음 만난 사람이었습니다. 그래서 긴 일은 시킬 수가 없었습니다. 설명하는 시간이 일하는 시간보다 길어지니까요.

정리하면 이렇습니다. 저는 십삼 개월 동안 아주 성실한 일회용 비서를 쓰고 있었습니다. 답변의 품질은 문제가 아니었습니다. 기억이 없고, 스스로 움직이지 않고, 결과가 쌓이지 않는 것. 그게 "많이 쓰는 것"과 "일을 맡기는 것"의 차이였는데, 저는 그 차이를 십삼 개월 내내 몰랐습니다.

질문을 바꾸는 데 십삼 개월이 걸렸습니다

바뀐 건 올해 2월입니다. 계기는 거창하지 않았습니다. 판매 채널에 새 후기가 달렸는지 매일 아침 확인하는 게 지겨워서, 어느 날 질문을 이렇게 바꿔 봤습니다.

"새 후기 확인해줘"가 아니라, "내가 '상황 업데이트'라고 하면 새 후기와 안 읽은 문의를 확인해서 알려줘"로요.

해달라는 것에서 하게 해달라는 것으로. 지금 보면 한 단어 차이인데, 이 문장 하나가 그다음 반년을 완전히 다른 방향으로 끌고 갔습니다. 처음으로 답이 소비되지 않고 절차가 남았기 때문입니다.

물론 그 뒤로도 순탄하지는 않았습니다. 그 시절 세팅은 결국 한 달을 못 갔고, 도구를 통째로 갈아치우는 일도 있었습니다. 그 얘기는 다음 글에서 하겠습니다.

혹시 지금 AI를 매일 쓰는데 일이 줄지 않는다고 느끼신다면, 질문 목록을 한번 꺼내 보시길 권합니다. 같은 질문을 두 번 이상 하고 있다면 — 그게 자동화 후보 목록입니다. 저는 이천 번을 쌓고서야 봤습니다.

이 글의 숫자는 전부 실제 기록입니다. 계정에서 내보낸 활동 기록 4,574건 중 해당 기간 2,038건을 분류해서 썼고, 자료 조사와 초안 작성은 지금 회사를 돌리고 있는 그 AI가 했습니다.

원문 및 이후 연재 → https://3amdesk.github.io/posts/two-thousand-questions.html?ref=disquiet

성공률 100%인 자동화가, 실은 아무 일도 안 하고 있었습니다

1~10인 규모의 회사에서 반복 사무를 하나씩 자동으로 넘기고 있습니다. 잘 만든 이야기보다 만들어두고 조용히 멈췄던 이야기를 기록으로 남기려 합니다. 첫 글입니다.

식품을 수입해 유통하는 작은 회사를 운영합니다. 직원은 몇 명 되지 않고 사무 업무는 대부분 제 손을 거칩니다. 사람을 더 뽑는 대신 회사 일을 하나씩 자동으로 돌려왔고, 지금 정해진 시각에 스스로 도는 일이 쉰한 개입니다.

아침은 대략 이렇게 지나갑니다.

• 새벽 세 시, 백업이 돕니다
• 다섯 시 십오 분, 수입 서류가 갱신됩니다
• 다섯 시 이십 분, 전날 남긴 메모에서 날짜가 잡힌 할 일을 뽑아 오늘 목록에 얹습니다
• 여덟 시, 이번 달 매출과 매입이 폰에 옵니다. 같은 시각에 전날 있었던 일도 한 통으로 묶여 옵니다
• 여덟 시 십오 분부터 사십 분까지, 서류·시스템·결과값 점검이 차례로 돕니다
• 아홉 시 십 분, 판매 채널 재고와 실적이 옵니다

여기까지만 보면 잘 굴러가는 것처럼 보입니다. 실제로 저도 한동안 그렇게 생각했습니다.

이 글은 그 생각이 틀렸다는 걸 알게 된 과정입니다. 만드는 건 어렵지 않았습니다. 만든 게 계속 살아 있는지 확인하는 쪽이 훨씬 어려웠고, 저는 그걸 세 번에 걸쳐 배웠습니다.

첫 번째: 실패를 적어두는 자동화가 백 개 중 다섯 개뿐이었다

어느 날 "요즘 뭐가 자꾸 실패하지?"를 확인해 봤습니다. 목록이 거의 비어 있었습니다.

다 잘 돌고 있어서가 아니었습니다. 세어보니 그때까지 만든 자동화 백마흔여섯 개 중에 실패를 기록하도록 만들어 둔 건 다섯 개였습니다. 나머지는 실패해도 아무 데도 안 적혔습니다. 기록이 비어 있던 게 아니라 애초에 적히지 않고 있었던 겁니다.

원인은 게으름이 아니라 순서였습니다. 새로 뭔가를 만들 때 사람은 "무슨 일을 하게 할까"부터 생각합니다. 기록이나 안전장치는 다 만든 다음에 붙이는 것인데, 다 만들고 나면 이미 동작하니까 붙일 이유가 사라집니다. 다음 걸 만들러 갑니다.

매번 따로 챙겨야 하는 안전장치는 결국 안 챙겨집니다. 의지의 문제가 아니라 구조의 문제입니다.

그래서 방식을 바꿨습니다. 새 자동화를 빈 파일에서 시작하지 않게 했습니다. 기록·알림·실패 처리·중단이 이미 붙어 있는 틀에서 시작하고, 만드는 사람은 가운데의 "무슨 일을 할지"만 채웁니다. 빼먹을 수 있는 자리 자체를 없앤 겁니다.

두 번째: 제대로 일한 기록이 실패로 쌓이고 있었다

창고 온도를 두 시간마다 확인하는 게 있습니다. 온도가 기준을 벗어나면 알림이 오는데, 이때 프로그램이 "정상 종료가 아님"에 해당하는 신호를 냅니다. 저는 그 신호를 실패로 기록하게 해뒀습니다.

지금 최근 한 달 기록을 열어보면 실패가 쉰일곱 건입니다. 그중 열다섯 건이 이 온도 감시이고, 실패 순위 1위입니다.

그런데 그 열다섯 건은 전부 정상 동작이었습니다. 온도가 올라갔고, 감시가 그걸 제대로 잡아 알렸고, "이상 있음"이라고 신호를 낸 겁니다. 일을 제대로 한 기록이 실패로 쌓여 있었습니다.

이게 왜 문제냐면, 그 목록은 제가 "뭘 고칠까"를 정할 때 보는 목록이기 때문입니다. 1위를 보고 멀쩡한 걸 손보러 가게 되고, 진짜 고장 난 건 그 열다섯 건 아래에 묻힙니다. 잘못 적힌 기록은 없는 기록보다 나쁩니다. 없으면 모른다는 걸 알기라도 하는데, 잘못 적혀 있으면 안다고 착각합니다.

세 번째: 성공률 100%가 아무것도 안 하는 걸 가려주고 있었다

기록이 쌓이자 성공률이 보이기 시작했습니다. 대부분 100%였습니다. 한동안 그 숫자를 보고 안심했습니다.

그러다 이상한 걸 깨달았습니다. 성공률이란 건 "프로그램이 오류 없이 끝났는가"만 재는 숫자입니다. 그런데 제가 돌리는 것 중 상당수는 감시입니다. 그리고 감시는 평소에 아무것도 안 잡는 게 정상입니다.

그러면 이렇게 됩니다. 감시가 고장 나서 아무것도 못 잡는 상태와, 잘 돌면서 잡을 게 없는 상태가 성적표에서 똑같이 100%로 보입니다. 둘을 구별할 방법이 없습니다. 저는 몇 달 동안 100%를 보면서 안심하고 있었는데, 그 숫자는 제가 알고 싶은 것에 대해 아무 말도 하지 않고 있었습니다.

실제로 이런 일이 있었습니다. 폰으로 결과를 보내주는 부분이 어느 날부터 답을 안 했습니다. 그런데 실행 기록을 열어보니 정상 종료였습니다. 오류도 없고, 성공률도 그대로 100%였습니다.

원인은 엉뚱한 데 있었습니다. 어떤 하위 작업이 밖으로 메시지를 보내지 못하게 막는 설정이 있었는데, 그게 상위 프로그램까지 딸려 들어가 있었던 겁니다. 프로그램 입장에서는 시킨 일을 다 하고 정상적으로 끝난 게 맞습니다. 다만 보내는 동작만 조용히 무시되고 있었습니다.

이건 성공률로는 절대 안 잡힙니다. 오류가 난 게 아니기 때문입니다. "메시지가 실제로 나갔는가"를 따로 보지 않으면, 몇 달이 지나도 100%만 보고 있게 됩니다.

그래서 자동화마다 "값을 냈다고 볼 신호"를 따로 정했습니다. 보고가 실제로 발송됐는지, 검색 결과가 몇 건 나왔는지 같은 것들입니다. 그리고 종류를 갈랐습니다. 평소에 아무것도 안 잡는 게 정상인 것과, 아무것도 안 잡으면 이상한 것은 다르게 봐야 합니다. 앞의 것은 보험이고 뒤의 것은 고장입니다. 이걸 안 가르면 멀쩡한 보험을 쓸모없다고 지우게 됩니다.

한 가지 더 뒀습니다. 판정하지 않는 칸입니다. 신호를 정해두지 않은 자동화는 "판단 못 함"으로 남깁니다. 모르는 걸 정상으로도 고장으로도 세지 않는 자리가 하나 있어야, 나중에 잘못된 확신으로 뭔가를 지우지 않습니다.

그래서 지금은 이렇게 확인합니다

거창한 도구가 필요한 건 아닙니다. 보는 각도의 문제입니다.

하나. 성공률 말고 마지막으로 성공한 시각을 본다. 성공률 100%는 지난주에 마지막으로 돈 것도 100%입니다. 자동화가 죽는 흔한 방식은 실패가 아니라 아예 실행되지 않는 것이라, 실패 목록만 들여다보면 영영 안 보입니다.

둘. 최근에 무언가를 잡아낸 적이 있는지 본다. 앞에서 말한 대로, 조용한 게 정상인 것과 조용하면 이상한 것을 먼저 갈라놓아야 이 질문이 뜻을 가집니다.

셋. 실패로 적힌 것을 열어서 진짜 실패인지 본다. 온도 감시 같은 경우가 여기서 걸립니다. 목록이 오염되면 그 목록을 근거로 한 판단이 전부 어긋납니다.

넷. 같은 게 두 번 도는 걸 막아뒀는지 본다. 돈이 걸린 일에서 특히 그렇습니다. 결제나 발주처럼 되돌릴 수 없는 일은, 실패한 줄 알고 다시 시도했는데 사실은 먼저 것이 성공했던 경우가 제일 무섭습니다. 실패해도 재시도하지 않게 만들고, 이미 한 일인지 먼저 확인하게 만드는 편이 낫습니다.

덧붙이면, 이 네 가지는 도구를 새로 사는 이야기가 아닙니다. 저는 실행 기록을 파일 하나에 한 줄씩 쌓는 것부터 시작했습니다. 언제 돌았고 어떻게 끝났는지만 적어도, 위의 첫 번째 질문("마지막으로 성공한 게 언제인가")에는 바로 답할 수 있게 됩니다. 나머지는 그 위에 하나씩 얹으면 됩니다.

정리하면

지난 몇 달 동안 제가 쓴 시간의 대부분은 새 자동화를 만드는 데 쓰지 않았습니다.

• 죽었을 때 시끄럽게 만들기
• 기록을 정확하게 적기 (정상 동작을 실패로 적지 않기)
• 성공률 말고 결과가 나왔는지 보기
• 안전장치를 빼먹을 수 없는 자리에 두기

만드는 건 요즘 도구로 하면 정말 빠릅니다. 그런데 만든 게 반년 뒤에도 살아 있는 건 전혀 다른 일이고, 이쪽을 이야기하는 사람은 잘 못 봤습니다. 강의도 글도 대개 "이렇게 만들었습니다"에서 끝납니다.

제가 겪은 바로는 자동화는 요란하게 고장 나지 않습니다. 그냥 어느 날부터 조용히 안 옵니다. 그리고 안 온다는 건 알림이 없다는 뜻이라서, 잘 도는 것과 구별이 안 됩니다.

혹시 비슷한 걸 굴리고 계신다면 오늘 하나만 확인해 보시길 권합니다. 그게 죽으면 내가 언제 알게 되는지. 답이 "모르겠는데요"라면, 저도 거기서 시작했습니다.

실제 화면 두 장(아침에 오는 매출·매입 요약, 지금 도는 자동화 목록)은 원문에 함께 실었습니다.
원문 및 이후 연재 → https://3amdesk.github.io/posts/silent-automation.html?ref=disquiet

이 글의 자료 조사와 초안 작성도 위에 나온 도구들이 했습니다. 본문의 숫자(자동화 51개, 146개 중 5개, 최근 한 달 실패 57건 중 15건)는 전부 실제 기록에서 뽑은 값이고, 회사·거래처·금액은 지웠습니다.