자동화

자동화란?

자동화를 넣는 순간 실제로 바뀌는 것은 작업량이 아니라 책임의 위치입니다. 예전에는 담당자가 기억하고 챙기고, 빠뜨리면 사과하던 일이 이제는 규칙과 실행 로그가 보증하는 일이 됩니다. 그래서 자동화가 자리 잡은 조직에서는 사고가 났을 때 '누가 빠뜨렸나'라는 질문이 '어느 조건이 빠졌나'로 바뀝니다. 사람의 성실함에 기대던 품질을 설계로 옮기는 일이 본질이고, 절약된 시간은 오히려 부수 효과에 가깝습니다.

무엇을 자동화할지는 감이 아니라 세 가지 값으로 걸러집니다. 빈도가 월 20회 이상인가, 건당 10분 이상 걸리는가, 규칙에서 벗어나는 예외가 10% 미만인가입니다. 세 조건을 다 넘기면 개발과 유지보수 공수를 대개 반년 안에 회수합니다. 유형은 정해진 순서를 그대로 재생하는 규칙형(스크립트·RPA), 특정 사건이 발생하면 다음 단계를 호출하는 이벤트형(웹훅·워크플로), 판단의 일부를 모델에 맡기는 지능형으로 나뉩니다. 여기서 API 연동과 RPA는 급이 다릅니다 — RPA는 화면을 대신 클릭하는 우회로여서 상대 시스템 화면이 바뀌면 그날로 멈춥니다. 연동이 가능한 구간을 굳이 로봇으로 덮는 건 빚을 지는 선택입니다.

현장에서 가장 흔한 사고는 엉킨 프로세스를 그대로 자동화하는 것입니다. 결재 단계가 다섯 개인 이유를 아무도 모르는 채 자동화하면 불량을 더 빠르고 더 많이 찍어내는 기계가 됩니다. 두 번째는 조용한 실패입니다. 사람이 하면 '어, 이거 좀 이상한데요' 소리가 나오지만, 스크립트는 아무 말 없이 빈 값을 넘기고 두세 주 뒤 정산이 어긋나서야 드러납니다. 실패 알림과 미처리 건 대시보드가 자동화 본체만큼 중요한 이유입니다. 세 번째는 만든 사람 한 명만 아는 블랙박스 문제입니다. 그가 퇴사하면 아무도 손대지 못한 채 매일 혼자 도는 코드가 남고, 결국 누군가는 그 결과를 다시 손으로 검산하게 됩니다.