석 달 뒤에 확인해 보세요. 그 자동화, 아마 죽어 있습니다
자동화는 시끄럽게 고장 나지 않습니다. 조용히 멈추고, 아무도 모릅니다. 죽는 경로 세 가지와 살려 두는 비용 이야기.
자동화를 한 번 맡겨 본 회사 대표들에게 물어보면 대답이 비슷합니다.
"처음엔 잘 됐어요. 그런데 어느 날부터 안 되더라고요."
언제부터인지는 대체로 모릅니다. 그럴 수밖에 없습니다. 자동화는 시끄럽게 고장 나지 않습니다. 에러 창이 뜨지도 않고, 누가 항의하지도 않습니다. 그냥 어느 날부터 아무 일도 일어나지 않습니다.
죽는 경로는 대개 셋입니다
하나, 연동한 쪽이 바뀝니다. 쓰던 서비스가 API 스펙을 바꾸거나, 로그인 방식을 바꾸거나, 화면 구조를 바꿉니다. 예고가 오는 경우도 있지만 대개는 그 메일을 아무도 안 봅니다.
둘, 우리 업무가 바뀝니다. 결재선이 하나 늘고, 양식에 칸이 하나 생기고, 담당자가 바뀝니다. 회사는 앞으로 갔는데 자동화는 작년 업무를 하고 있습니다. 이 경우가 제일 흔합니다.
셋, 예외가 쌓입니다. 처음엔 100건 중 1건이던 예외가 어느새 10건이 됩니다. 담당자는 그 10건을 손으로 처리하다가, 어느 순간 "그냥 전부 손으로 하는 게 빠르다"에 도달합니다. 자동화는 살아 있지만 아무도 안 씁니다.
진짜 무서운 건 죽은 걸 모른다는 것
리마인드가 안 나가고 있어도, 리포트 숫자가 틀려 있어도, 누군가 우연히 발견할 때까지 회사는 그 일이 되고 있다고 믿습니다.
죽은 자동화는 없는 것보다 나쁩니다. 믿고 있으니까요. 없으면 사람이 확인이라도 하는데, 있다고 믿으면 아무도 안 봅니다.
그래서 견적서를 볼 때 물어보실 것
자동화의 실제 비용은 만드는 값이 아니라 살려 두는 값입니다. 그런데 견적서에는 만드는 값만 적혀 있습니다.
개발사를 고르실 때 "얼마에 만들어 주시나요?"보다 이 질문이 낫습니다.
"만든 다음엔 누가 지키나요? 죽으면 누가 먼저 압니까?"
답이 "문제 생기면 연락 주세요"면, 그건 문제가 생긴 걸 대표님이 먼저 발견해야 한다는 뜻입니다. 위에 적은 세 가지 경로 중 어느 것도 대표님이 먼저 발견할 수 있는 종류가 아닙니다.
이미 죽어 있다면
자동화를 시도했다가 흐지부지된 경험이 있으시면, 새로 만드는 것보다 그것부터 살펴보는 게 순서인 경우가 많습니다. 이미 업무에 맞게 설계돼 있고, 대개 한두 군데만 어긋나 있습니다.
물론 아닐 수도 있습니다. 오래 방치된 자동화는 복구가 신규 구축과 비슷해지기도 하는데, 그때는 그렇게 말씀드립니다.
이 주제를 실제로 어떻게 다루는지
글에서 말한 판단은 전부 판단 기준 3원칙에서 나옵니다. 회사 상황에 대입해 보시려면 5분 진단이 가장 빠릅니다.