자동화를 했는데 일이 더 늘어난 것 같은 경우가 있습니다. 이건 착각이 아니라 실제로 그럴 수 있습니다.

자동화는 일을 없애는 게 아니라 옮깁니다. 실행하는 일이 줄고 확인하고 고치는 일이 늘어납니다. 그 교환이 손해가 되는 조건이 있습니다.

#확인 비용이 실행 비용보다 클 때

결과를 매번 사람이 전부 확인해야 한다면, 확인하는 시간이 직접 하는 시간과 비슷해집니다.

특히 틀렸는지 알려면 원본을 다시 봐야 하는 종류가 그렇습니다. 요약본을 검증하려고 원문을 읽는다면 요약의 의미가 없습니다.

그래서 자동화 대상은 결과만 보고 맞는지 알 수 있는 일이어야 합니다. 이 조건을 안 보면 도입할수록 느려집니다.

#예외가 많을 때

전체의 80%가 자동으로 처리되고 20%가 예외라면 괜찮아 보입니다. 그런데 실제로는 예외 20%를 처리하는 시간이 예전 100%보다 길어지는 경우가 있습니다.

흐름이 끊기기 때문입니다. 예전에는 쭉 처리했는데 이제는 자동 처리분과 예외를 오가며 맥락을 계속 다시 잡아야 합니다.

그래서 예외 비율이 높으면 차라리 전부 수작업이 빠릅니다. 자동화 도입 전에 예외가 몇 퍼센트인지 세어 보는 이유입니다.

#입력 형식이 자주 바뀔 때

거래처가 보내는 엑셀 양식이 매번 조금씩 다르면, 자동화는 바뀔 때마다 멈춥니다. 그리고 고치는 데 시간이 듭니다.

이때 손대야 할 것은 자동화가 아니라 입력 쪽입니다. 양식을 우리가 만들어 보내거나, 웹 폼으로 받으면 문제 자체가 사라집니다.

바꿀 수 없는 상대라면 그 거래처만 수작업으로 두는 편이 낫습니다. 모든 예외를 처리하려다 전체가 취약해지는 것보다 낫습니다.

#고장났을 때 아무도 모를 때

자동으로 도는 것은 멈춰도 조용합니다. 사람이 하던 일은 안 하면 티가 나는데, 자동화는 며칠 뒤에 발견됩니다.

그리고 그사이 잘못된 데이터가 쌓입니다. 수습 비용이 원래 아낀 시간을 넘는 일이 여기서 생깁니다.

그래서 자동화에는 반드시 「안 돌았을 때 알려주는 장치」가 함께 있어야 합니다. 성공 알림이 아니라 실패 알림이요. 이게 없으면 자동화가 아니라 시한폭탄입니다.

#한 사람만 이해하고 있을 때

자동화를 만든 사람만 구조를 압니다. 그 사람이 없으면 고칠 수도 끌 수도 없습니다.

이 상태에서는 아무도 손대지 못하므로, 조건이 바뀌어도 그대로 돕니다. 그리고 결과가 조금씩 어긋나기 시작합니다.

그래서 만들 때 「무엇이 어디서 어디로 가는가」를 한 장으로 남깁니다. 코드 주석이 아니라 사람이 읽는 그림이요. 이 한 장이 없으면 그 자동화는 언젠가 통째로 버려집니다.

#느려진 걸 어떻게 확인하는가

「자동화했으니 빨라졌을 것」이라고 가정하고 아무도 재지 않습니다. 그래서 느려져도 모릅니다.

그래서 도입 전에 주당 소요 시간을 재 두고, 도입 두 달 뒤에 다시 잽니다. 여기에 확인과 예외 처리 시간까지 포함해서요.

줄지 않았다면 원인은 위 네 가지 중 하나입니다. 그리고 대개 범위를 좁히면 해결됩니다. 전부 자동화하려던 것을 가장 규칙적인 절반만 남기는 식으로요.

#작게 만들었는지 크게 만들었는지

한 번에 여러 단계를 묶어 만든 자동화는 한 군데가 어긋나면 전부 멈춥니다. 그리고 어디서 멈췄는지 찾기 어렵습니다.

그래서 단계를 나눠 만들고 중간 결과를 저장해 둡니다. 그러면 실패한 단계부터 다시 돌릴 수 있고, 확인도 쉬워집니다.

이 구조는 처음 만들 때 조금 더 걸립니다. 대신 1년 뒤에도 살아 있을 확률이 확연히 다릅니다.

#되돌리는 것도 성과다

안 맞는 자동화를 끄는 결정은 잘 안 내려집니다. 들인 비용이 아깝고, 실패로 보이기 때문입니다.

그런데 이미 쓴 돈은 끄든 켜두든 돌아오지 않습니다. 판단 기준은 앞으로 드는 시간뿐입니다.

정리하면, 자동화가 느려지는 조건은 확인 비용, 예외 비율, 침묵하는 고장, 한 사람 의존 네 가지입니다. 도입 전에 이 넷을 확인하고 도입 후에 시간을 다시 재면, 대부분은 범위를 조정해 살릴 수 있습니다.

이어서 읽기 → 사람이 남아야 하는 지점