성공률 100%인 자동화가, 실은 아무 일도 안 하고 있었습니다
식품을 수입해 유통하는 작은 회사를 운영합니다. 직원은 몇 명 되지 않고 사무 업무는 대부분 제 손을 거칩니다. 사람을 더 뽑는 대신 회사 일을 하나씩 자동으로 돌려왔고, 지금 정해진 시각에 스스로 도는 일이 쉰한 개입니다.
아침은 대략 이렇게 지나갑니다.
- 새벽 세 시, 백업이 돕니다
- 다섯 시 십오 분, 수입 서류가 갱신됩니다
- 다섯 시 이십 분, 전날 남긴 메모에서 날짜가 잡힌 할 일을 뽑아 오늘 목록에 얹습니다
- 여덟 시, 이번 달 매출과 매입이 폰에 옵니다. 같은 시각에 전날 있었던 일도 한 통으로 묶여 옵니다
- 여덟 시 십오 분부터 사십 분까지, 서류·시스템·결과값 점검이 차례로 돕니다
- 아홉 시 십 분, 판매 채널 재고와 실적이 옵니다
여기까지만 보면 잘 굴러가는 것처럼 보입니다. 실제로 저도 한동안 그렇게 생각했습니다.
이 글은 그 생각이 틀렸다는 걸 알게 된 과정입니다. 만드는 건 어렵지 않았습니다. 만든 게 계속 살아 있는지 확인하는 쪽이 훨씬 어려웠고, 저는 그걸 세 번에 걸쳐 배웠습니다.
첫 번째: 실패를 적어두는 자동화가 백 개 중 다섯 개뿐이었다
어느 날 "요즘 뭐가 자꾸 실패하지?"를 확인해 봤습니다. 목록이 거의 비어 있었습니다.
다 잘 돌고 있어서가 아니었습니다. 세어보니 그때까지 만든 자동화 백마흔여섯 개 중에 실패를 기록하도록 만들어 둔 건 다섯 개였습니다. 나머지는 실패해도 아무 데도 안 적혔습니다. 기록이 비어 있던 게 아니라 애초에 적히지 않고 있었던 겁니다.
원인은 게으름이 아니라 순서였습니다. 새로 뭔가를 만들 때 사람은 "무슨 일을 하게 할까"부터 생각합니다. 기록이나 안전장치는 다 만든 다음에 붙이는 것인데, 다 만들고 나면 이미 동작하니까 붙일 이유가 사라집니다. 다음 걸 만들러 갑니다.
매번 따로 챙겨야 하는 안전장치는 결국 안 챙겨집니다. 의지의 문제가 아니라 구조의 문제입니다.
그래서 방식을 바꿨습니다. 새 자동화를 빈 파일에서 시작하지 않게 했습니다. 기록·알림·실패 처리·중단이 이미 붙어 있는 틀에서 시작하고, 만드는 사람은 가운데의 "무슨 일을 할지"만 채웁니다. 빼먹을 수 있는 자리 자체를 없앤 겁니다.
두 번째: 제대로 일한 기록이 실패로 쌓이고 있었다
창고 온도를 두 시간마다 확인하는 게 있습니다. 온도가 기준을 벗어나면 알림이 오는데, 이때 프로그램이 "정상 종료가 아님"에 해당하는 신호를 냅니다. 저는 그 신호를 실패로 기록하게 해뒀습니다.
지금 최근 한 달 기록을 열어보면 실패가 쉰일곱 건입니다. 그중 열다섯 건이 이 온도 감시이고, 실패 순위 1위입니다.
그런데 그 열다섯 건은 전부 정상 동작이었습니다. 온도가 올라갔고, 감시가 그걸 제대로 잡아 알렸고, "이상 있음"이라고 신호를 낸 겁니다. 일을 제대로 한 기록이 실패로 쌓여 있었습니다.
이게 왜 문제냐면, 그 목록은 제가 "뭘 고칠까"를 정할 때 보는 목록이기 때문입니다. 1위를 보고 멀쩡한 걸 손보러 가게 되고, 진짜 고장 난 건 그 열다섯 건 아래에 묻힙니다. 잘못 적힌 기록은 없는 기록보다 나쁩니다. 없으면 모른다는 걸 알기라도 하는데, 잘못 적혀 있으면 안다고 착각합니다.
세 번째: 성공률 100%가 아무것도 안 하는 걸 가려주고 있었다
기록이 쌓이자 성공률이 보이기 시작했습니다. 대부분 100%였습니다. 한동안 그 숫자를 보고 안심했습니다.
그러다 이상한 걸 깨달았습니다. 성공률이란 건 "프로그램이 오류 없이 끝났는가"만 재는 숫자입니다. 그런데 제가 돌리는 것 중 상당수는 감시입니다. 그리고 감시는 평소에 아무것도 안 잡는 게 정상입니다.
그러면 이렇게 됩니다. 감시가 고장 나서 아무것도 못 잡는 상태와, 잘 돌면서 잡을 게 없는 상태가 성적표에서 똑같이 100%로 보입니다. 둘을 구별할 방법이 없습니다. 저는 몇 달 동안 100%를 보면서 안심하고 있었는데, 그 숫자는 제가 알고 싶은 것에 대해 아무 말도 하지 않고 있었습니다.
실제로 이런 일이 있었습니다. 폰으로 결과를 보내주는 부분이 어느 날부터 답을 안 했습니다. 그런데 실행 기록을 열어보니 정상 종료였습니다. 오류도 없고, 성공률도 그대로 100%였습니다.
원인은 엉뚱한 데 있었습니다. 어떤 하위 작업이 밖으로 메시지를 보내지 못하게 막는 설정이 있었는데, 그게 상위 프로그램까지 딸려 들어가 있었던 겁니다. 프로그램 입장에서는 시킨 일을 다 하고 정상적으로 끝난 게 맞습니다. 다만 보내는 동작만 조용히 무시되고 있었습니다.
이건 성공률로는 절대 안 잡힙니다. 오류가 난 게 아니기 때문입니다. "메시지가 실제로 나갔는가"를 따로 보지 않으면, 몇 달이 지나도 100%만 보고 있게 됩니다.
그래서 자동화마다 "값을 냈다고 볼 신호"를 따로 정했습니다. 보고가 실제로 발송됐는지, 검색 결과가 몇 건 나왔는지 같은 것들입니다. 그리고 종류를 갈랐습니다. 평소에 아무것도 안 잡는 게 정상인 것과, 아무것도 안 잡으면 이상한 것은 다르게 봐야 합니다. 앞의 것은 보험이고 뒤의 것은 고장입니다. 이걸 안 가르면 멀쩡한 보험을 쓸모없다고 지우게 됩니다.
한 가지 더 뒀습니다. 판정하지 않는 칸입니다. 신호를 정해두지 않은 자동화는 "판단 못 함"으로 남깁니다. 모르는 걸 정상으로도 고장으로도 세지 않는 자리가 하나 있어야, 나중에 잘못된 확신으로 뭔가를 지우지 않습니다.
그래서 지금은 이렇게 확인합니다
거창한 도구가 필요한 건 아닙니다. 보는 각도의 문제입니다.
하나. 성공률 말고 마지막으로 성공한 시각을 본다. 성공률 100%는 지난주에 마지막으로 돈 것도 100%입니다. 자동화가 죽는 흔한 방식은 실패가 아니라 아예 실행되지 않는 것이라, 실패 목록만 들여다보면 영영 안 보입니다.
둘. 최근에 무언가를 잡아낸 적이 있는지 본다. 앞에서 말한 대로, 조용한 게 정상인 것과 조용하면 이상한 것을 먼저 갈라놓아야 이 질문이 뜻을 가집니다.
셋. 실패로 적힌 것을 열어서 진짜 실패인지 본다. 온도 감시 같은 경우가 여기서 걸립니다. 목록이 오염되면 그 목록을 근거로 한 판단이 전부 어긋납니다.
넷. 같은 게 두 번 도는 걸 막아뒀는지 본다. 돈이 걸린 일에서 특히 그렇습니다. 결제나 발주처럼 되돌릴 수 없는 일은, 실패한 줄 알고 다시 시도했는데 사실은 먼저 것이 성공했던 경우가 제일 무섭습니다. 실패해도 재시도하지 않게 만들고, 이미 한 일인지 먼저 확인하게 만드는 편이 낫습니다.
덧붙이면, 이 네 가지는 도구를 새로 사는 이야기가 아닙니다. 저는 실행 기록을 파일 하나에 한 줄씩 쌓는 것부터 시작했습니다. 언제 돌았고 어떻게 끝났는지만 적어도, 위의 첫 번째 질문("마지막으로 성공한 게 언제인가")에는 바로 답할 수 있게 됩니다. 나머지는 그 위에 하나씩 얹으면 됩니다.
정리하면
지난 몇 달 동안 제가 쓴 시간의 대부분은 새 자동화를 만드는 데 쓰지 않았습니다.
- 죽었을 때 시끄럽게 만들기
- 기록을 정확하게 적기 (정상 동작을 실패로 적지 않기)
- 성공률 말고 결과가 나왔는지 보기
- 안전장치를 빼먹을 수 없는 자리에 두기
만드는 건 요즘 도구로 하면 정말 빠릅니다. 그런데 만든 게 반년 뒤에도 살아 있는 건 전혀 다른 일이고, 이쪽을 이야기하는 사람은 잘 못 봤습니다. 강의도 글도 대개 "이렇게 만들었습니다"에서 끝납니다.
제가 겪은 바로는 자동화는 요란하게 고장 나지 않습니다. 그냥 어느 날부터 조용히 안 옵니다. 그리고 안 온다는 건 알림이 없다는 뜻이라서, 잘 도는 것과 구별이 안 됩니다.
혹시 비슷한 걸 굴리고 계신다면 오늘 하나만 확인해 보시길 권합니다. 그게 죽으면 내가 언제 알게 되는지. 답이 "모르겠는데요"라면, 저도 거기서 시작했습니다.
이 글의 자료 조사와 초안 작성도 위에 나온 도구들이 했습니다. 화면은 실제 출력이고, 회사·거래처·금액은 지운 뒤 다시 그렸습니다. 본문의 숫자(자동화 51개, 146개 중 5개, 최근 한 달 실패 57건 중 15건)는 전부 실제 기록에서 뽑은 값입니다.