자동화했는데 사람이 더 빨랐다
자동화가 오히려 짐이 된 세 가지 실패 사례와 그 뒤 바꾼 것
자동화를 믿었던 시절
처음 몇 년은 반복 작업이 보이면 반사적으로 스크립트를 짰다. 당연한 거라 생각했다. 엔지니어니까. 그런데 어느 순간부터 자동화 코드가 쌓이는 속도보다 그걸 고치는 속도가 더 빨라지기 시작했다.
대표적인 실패 하나. 배포 후 슬랙 알림을 자동으로 보내는 봇을 만들었다. PR 머지 → CI 완료 → 채널 알림. 딱 봐도 쓸모 있어 보였다. 막상 운영해보니 알림이 너무 자주 와서 다들 무시하기 시작했다. 노이즈가 되는 데 2주도 안 걸렸다. 결국 누군가 중요한 배포 때 직접 메시지를 보냈고, 그게 더 읽혔다. 자동화된 알림은 끄는 게 낫다는 결론이 났다.
또 하나. 고객사 요청 티켓을 키워드로 분류해서 담당자에게 자동 할당하는 걸 만들었다. 분류 정확도가 처음엔 80%를 넘었다. 근데 그 20% 오분류가 하필 급한 건들이었다. 고객은 이미 A팀에 가 있는데 B팀이 받아서 “제가 담당이 아닌데요”하고 다시 넘기는 상황이 반복됐다. 매뉴얼로 할 때는 접수 담당자가 맥락을 보고 직접 판단했다. 그 사람은 틀리는 일이 드물었다. 결국 자동화는 없애고 접수 담당자 1명 시간을 거기 쓰는 게 낫다는 결론이 났다.
세 번째. 주간 지표 리포트 이메일 자동 발송. 매주 월요일 아침 8시에 나갔다. 반년 지나서 확인해보니 오픈율이 12%였다. 나머지 88%는 열지도 않았다. 차라리 매주 한 줄짜리 슬랙 메시지로 핵심 수치 하나만 보내는 게 반응이 훨씬 좋았다. 자동화된 리포트는 작성하는 사람도 별로 안 보게 된다.
뭘 잘못 본 건가
공통점을 뽑으면 이렇다.
- 반복이 보이면 자동화가 맞다고 전제했다. 근데 반복이 항상 자동화 대상은 아니다. 반복이라도 맥락 판단이 포함된 작업은 사람이 훨씬 잘 한다.
- 자동화 비용을 너무 낮게 쳤다. 스크립트 짜는 시간만 따졌다. 유지보수, 예외 처리, 오작동 대응까지 넣으면 본전도 못 뽑는 경우가 많았다.
- “일단 만들고 보자”에서 한 번도 멈추지 않았다. 6개월 뒤 여전히 쓰고 있는지 체크하는 루틴이 없었다. 아무도 안 쓰는 자동화가 서버에서 혼자 돌아가고 있었다.
막상 되돌아보면 잘 돌아간 자동화들은 판단이 없는 것들이었다. cron으로 DB 백업, S3 오래된 로그 삭제, 모니터링 알림 임계값 초과 시 PagerDuty 호출. 입력이 일정하고 출력도 단순한 것. 맥락을 읽어야 하는 것들은 거의 다 실패했다.
그러고 보면 자동화를 판단하는 기준이 “반복되냐”가 아니라 “판단이 빠지냐” 여야 했다.
지금 기준
지금은 자동화를 만들기 전에 세 가지만 확인한다.
- 이 작업에서 사람의 판단이 빠져도 되나? 아니면 그냥 사람이 하는 게 낫다.
- 6개월 뒤 이게 안 돌아가면 누가 발견하나? 발견하는 사람이 없으면 만들지 않는다.
- 지금 수작업으로 걸리는 시간이 실제로 얼마나 되나? 주 10분이면 자동화할 이유가 없다.
이 세 개 통과 못하면 그냥 사람이 한다. 더 빠르고, 더 정확하고, 나중에 고칠 것도 없다.
다음 한 가지
지금 돌아가는 자동화 목록을 하나 꺼내서, “6개월 안에 아무도 안 건드렸으면 삭제한다”는 규칙을 이번 주 안에 붙인다.
🛒 이 글과 어울리는 추천 상품
위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.