자동화의 손익분기점: 얼마나 반복돼야 이득인가

자동화가 손해인 경우가 있다. 오래 걸렸던 거라 말하기 부끄럽지만 몇 번 직접 겪고 나서야 체감했다.

공식을 먼저 꺼내면

막상 해보면 복잡한데, 어림셈은 단순하다. 자동화 비용 < 반복 횟수 × 회당 소요 시간이면 이득. 단, ‘자동화 비용’에는 구현 시간만 넣으면 안 된다.

유지보수 비용을 꼭 포함해야 한다. 최근 S3 버킷 이름 규칙이 바뀌면서 6개월 전에 짜둔 스크립트 세 개가 동시에 죽었다. 당시 스크립트 하나 짜는 데 2시간, 수정하는 데도 결국 합쳐서 5시간 들었다. 그 작업 자체는 월 1회, 회당 10분짜리였으니 ROI가 마이너스였다.
‘언젠가 또 쓰겠지’ 예측 실패율이 생각보다 높다. 팀 내 비공식 통계를 내봤더니 자동화해두고 6개월 안에 다시 쓴 케이스가 40% 정도였다. 나머지는 방치 또는 삭제.
실제로 반복 횟수를 세고 나서 결정하면 판단이 달라진다. 직접 해보니 ‘자주 하는 것 같다’는 느낌은 실제보다 두 배쯤 과장돼 있었다.

내가 틀렸던 사례

작년 말쯤 배포 후 Slack 알림을 자동화했다. 명분은 그럴듯했다. 팀원이 배포 완료를 수동으로 알려주다 놓치는 경우가 있었으니까.

구현에 반나절 걸렸고 운영하면서 두 번 더 수정했다. 처음엔 스테이징·프로덕션 구분 없이 알림이 와서 소음이 됐고, 그다음엔 특정 repo가 빠져 있어서 또 손댔다. 총 투입 시간이 거의 하루.
놓쳐서 생기는 실제 손해를 냉정하게 측정했어야 했다. 배포 완료 공지를 수동으로 하면 5분 안에 누군가 Slack 메시지 하나 보냈다. 그걸 놓친 빈도는 한 달에 두세 번이었고, 그로 인한 실제 대기 시간은 10분을 넘지 않았다.
자동화가 ‘편리함’이 아니라 ‘노이즈 감소’를 목표로 했어야 했는데, 목표가 흐릿하니 구현이 헛방이었다. 결국 이 자동화는 석 달 뒤 reverted.

손익분기점이 빨라지는 조건

반대로 ‘이건 진짜 해야 해’가 명확했던 경우도 있다. 기준은 세 가지가 겹칠 때였다.

실수 비용이 반복 비용보다 클 때. 매주 수동으로 RDS 스냅샷 확인을 하던 루틴이 있었다. 한 번 빼먹은 주에 스냅샷이 실패 상태로 방치됐고, 그 다음 주에야 발견했다. 복구 절차에 3시간 들었다. 그 다음 날 바로 자동화했고 한 번도 후회 없음.
실행자가 바뀌어도 같은 결과가 나와야 할 때. 온콜 담당자가 바뀔 때마다 절차가 미묘하게 달랐다. 체크리스트를 자동화 스크립트로 바꿨더니 편차가 사라졌다. 자동화 비용보다 편차를 교정하는 커뮤니케이션 비용이 훨씬 컸다.
측정 자체가 자동화의 부산물로 따라올 때. 스크립트가 실행 로그를 남기면 ‘얼마나 자주 돌았나’를 나중에 볼 수 있다. 수동 작업은 기록이 없어서 ROI 판단 자체가 불가능하다.

‘일단 자동화’ 문화의 함정

팀에 자동화를 좋아하는 엔지니어가 들어오면 종종 생기는 패턴이 있다. 좋게 말하면 생산성 투자, 솔직하게 말하면 코드 놀이.

보통은 자동화 스크립트가 하나둘 늘어나는데, 소유자가 퇴사하거나 팀을 옮기면 아무도 손대지 못하는 블랙박스가 된다. 올해 초에 정리해보니 레포에 cron 잡이 23개 있었고, 그중 실제로 동작 중인 게 몇 개인지 당장 확인 가능한 게 14개였다. 나머지 9개는 IAM 키가 교체되거나 대상 리소스가 삭제돼서 조용히 실패 중이었는데 알림이 없었다.

자동화를 만들 때 ‘이게 실패하면 누가 아나’를 먼저 물어야 한다. 알림도 없이 조용히 죽는 자동화는 없는 것보다 나쁠 수 있다. 정상이라고 착각하게 만드니까.
소유자를 명시해두지 않은 스크립트는 6개월 뒤 고아가 된다. README 첫 줄에 “만든 사람 / 받을 사람 / 안 돌면 누구한테”를 적어두는 게 그래서 생긴 습관이다.

판단 기준을 숫자로 고정한 뒤

지금은 새 자동화 아이디어가 나오면 아래 세 가지를 먼저 채운다. 팀 위키 템플릿으로 박아뒀다.

월 반복 횟수: ___회
회당 소요 시간: ___분
구현 + 유지보수 예상: ___시간
손익분기 월: ___(자동화비용 / (회당시간 × 월반복))

손익분기가 12개월을 넘으면 일단 보류. 3개월 뒤에 수동으로 계속 하고 있으면 그때 다시 꺼내본다. 막상 3개월 지나면 절반쯤은 그 작업 자체가 사라져 있다.

직접 이 기준을 써보니 처음엔 팀원들이 ‘너무 냉정하다’고 했다. 한 번은 ‘이거 자동화하면 개발자답지 않냐’는 얘기도 들었다. 그런데 고아 스크립트를 정리하면서 3일을 날리고 나서는 별말 없어졌다.

다음 한 가지

자동화를 만들 때마다 손익분기 월을 위키에 기록하고, 반년 뒤 실제 숫자와 비교하는 걸 습관으로 굳힌다.

🛒 이 글과 어울리는 추천 상품

위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.