자동화가 느렸던 날들

자동화를 결정하는 순간, 거의 항상 과소 평가하는 게 하나 있다. 셋업 비용이 아니라 예외 처리 비용이다.

6주짜리 파이프라인, 결국 수동으로

올해 초 사내 정산 데이터를 정리하는 작업이 있었다. 매달 약 1,200개 행, 형식은 크게 두 가지인데 파트너사마다 컬럼 이름이 미묘하게 달랐다. 당연히 자동화 대상이라고 생각했다.

Python 스크립트 + pandas 로 정규화 파이프라인을 짰다. 처음엔 커버리지 80% 정도였고, 나머지 20%가 문제였다. 파트너사가 컬럼명을 아무 공지 없이 바꾸는 경우가 분기에 한두 번씩 있었고, 그때마다 스크립트가 조용히 틀린 값을 냈다.
결국 검증 로직을 추가하다 보니 예외 분기가 11개까지 늘었다. 코드 줄 수는 340줄. 원래 사람이 엑셀로 처리하던 시간은 월 2.5시간이었는데, 파이프라인 유지보수에 월 평균 1.8시간이 더 들었다. 절감분이 0.7시간.
6주 셋업 공수를 회수하려면 3.5년이 걸리는 구조였다. 담당자가 퇴사하면서 파이프라인 맥락도 같이 사라졌고, 다음 담당자는 그냥 수동으로 돌아갔다.

숫자로 보면 명백한 실패인데, 결정할 때는 그게 안 보였다.

자동화가 빛나는 조건, 막상 확인 안 한다

나중에 복기해 보면 패턴이 있었다. 자동화가 실제로 이득이 되려면 세 조건이 동시에 맞아야 한다.

입력 형식이 통제 가능해야 한다. 외부에서 오는 파일, 사람 손을 탄 엑셀, 파트너가 “비슷하게” 맞춰 주는 포맷 — 이쪽은 예외가 무한 생성된다. 월 1회 실행인데 입력이 매번 조금씩 다른 경우, 파이프라인은 버그 추적기가 된다.
실행 빈도가 충분히 높아야 셋업 비용을 회수한다. 하루 수백 번이면 의심 없이 자동화. 월 1~2회면 진지하게 계산해야 한다. 직접 해보니 “월 1회짜리”는 체감 반환점이 2년을 넘는 경우가 많았다.
실패 시 복구 비용이 낮아야 한다. 자동화 스크립트가 틀린 값을 조용히 내면, 사람이 검토하던 때보다 오류 발견이 늦다. 정산 같은 도메인에서 한 달치 오류를 뒤늦게 잡으면 수정 공수가 원래 수동 작업보다 훨씬 크다.

Slack 봇이 죽은 이유

비슷한 시기에 Slack 봇으로 배포 알림을 자동화했다. 기존에는 배포 완료 후 채널에 담당자가 직접 메시지를 올렸다. 30초짜리 일이었다.

봇 셋업에 사흘 걸렸다. webhook 연결, 메시지 템플릿, 실패 알림 분기. 처음 두 달은 잘 돌아갔다. 세 번째 달에 Slack API 스펙이 바뀌었고, 봇이 아무 메시지도 안 보내면서 에러도 안 냈다. 배포 완료 여부를 아무도 모르는 상태가 40분간 지속됐다.

그 40분 동안 실제로는 배포가 정상 완료됐는데, 팀이 “배포됐나?” 라고 서로 확인하느라 Slack 스레드가 15개 쌓였다. 오히려 더 시끄러웠다.
담당자가 직접 올리는 방식은 “사람이 확인했다”는 신호도 같이 담겨 있었다. 봇 메시지에는 그 신호가 없었다. 받는 사람 입장에서 봇 메시지는 절반쯤 신뢰하게 된다는 걸 뒤늦게 깨달았다.
결국 봇은 그대로 두되, 배포 완료 메시지는 담당자가 직접 올리는 방식으로 돌아갔다. 봇은 실패 알림 전용으로만 살아남았다.

자동화를 정당화하는 편향

솔직히 말하면, 자동화를 결정할 때 ROI 계산을 제대로 한 적이 많지 않다. “반복 작업이니까 자동화해야지” 라는 반사가 먼저 나온다. 엔지니어링 본능이기도 하고, 자동화 자체가 주는 성취감도 있다.

문제는 그 성취감이 결과물이 아니라 과정에서 나온다는 거다. 파이프라인이 돌아가는 순간, 실제로 절감되는 시간과 상관없이 뭔가 해결한 느낌이 든다. 그 느낌이 냉정한 판단을 흐린다.

작년에 팀 내에서 “자동화 결정 전 5분 체크리스트”를 만들어 봤다. 입력 형식 통제 가능 여부, 월 실행 횟수, 셋업 공수를 회수하는 시점, 실패 시 오류 탐지 방법 — 이 네 항목을 채우면 꽤 많은 경우에 “그냥 수동으로 하자”는 결론이 나왔다. 팀 반응은 절반은 동의, 절반은 “그래도 자동화는 해야지”였다.

여전히 자동화하는 것들

실패 경험이 쌓인다고 자동화를 안 하게 되는 건 아니다. 오히려 어디에 써야 하는지가 더 선명해진다.

하루 50회 이상 실행하는 것: 테스트 파이프라인, lint, 빌드. 여기는 의심 없이 자동화. 입력도 통제되고 실패가 즉시 표면에 뜬다.
형식이 내부에서 완전히 통제되는 것: 내부 DB 백업, 인프라 스냅샷. 외부 입력 없이 시스템이 스스로 만드는 데이터라 예외 분기가 거의 없다.
오류가 즉시 보이는 것: 알림 누락보다 오탐이 나을 때가 많다. 조용한 실패가 제일 비싸다.

반대로 외부에서 오는 파일, 사람이 만든 문서, 분기별 1회 실행 같은 케이스는 이제 수동 먼저 검토한다.

다음 한 가지

자동화 결정 전 셋업 공수 회수 시점을 숫자로 적는 습관 — 올해 안에 팀 위키 템플릿에 한 줄 박아 넣는다.

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

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