자동화, 언제 손에 잡아야 하나

자동화는 항상 옳다는 분위기가 있다. 엔지니어라면 반복 작업을 스크립트로 대체해야 한다는 암묵적 압박. 그런데 막상 해보면, 스크립트 짜는 데 4시간 썼는데 그 작업이 두 번 다시 안 오는 경우가 꽤 있다.

자동화의 진짜 비용

자동화를 결정할 때 대부분 ‘한 번 실행에 걸리는 시간’만 계산한다. 틀렸다. 실제 비용은 훨씬 넓다.

스크립트 작성 시간: 단순 CSV 변환 하나를 범용적으로 짜려다 예외 처리, 로그, 슬랙 알림까지 붙이고 나면 반나절이 사라진다. 내가 올해 초에 실제로 겪었다. 30분짜리 수작업을 자동화한다고 시작했는데, ‘어차피 짜는 거 제대로 짜자’는 마음이 생기면서 결국 6시간을 썼다. 그 작업은 그 이후로 딱 한 번 더 돌아갔다.
유지보수 비용: 스크립트는 살아있는 환경 위에서 돌아간다. 의존하는 API 버전이 바뀌고, 컬럼 이름이 달라지고, 인증 방식이 교체된다. 처음 만들 때는 없던 비용이 3개월 뒤에 갑자기 청구서처럼 날아온다.
문서화 비용: 나 혼자 쓰는 스크립트면 그나마 낫다. 팀에서 쓰는 순간, 누군가 설명을 요청하고, README가 필요해지고, 온보딩이 생긴다. 이 비용은 처음 추산에 절대 포함 안 된다.

손익분기점 계산식, 간단하게

XKCD 1205 «Is It Worth the Time?» 이 유명하다. 하지만 저 표는 ‘자동화가 완성된 후 유지비 0’을 가정한다. 현실은 다르다.

실전에서 내가 쓰는 공식은 단순하다.

이득 = (수작업 1회 시간 × 예상 반복 횟수) - (자동화 구축 시간 + 유지보수 시간)

이 값이 양수가 되는 시점이 손익분기. 단, ‘예상 반복 횟수’를 낙관적으로 잡는 게 가장 흔한 실수다. 나는 보수적으로 잡은 수치에서 다시 50%를 더 깎는다. 그렇게 해도 양수면 자동화한다.

예를 들어 올해 3월에 배포 전 헬스체크 목록을 매번 수동으로 확인하는 작업이 있었다. 1회 15분, 주 3회 정도였다. 연간으로 잡으면 약 36시간. 자동화에 드는 시간을 4시간으로 잡고, 분기마다 30분 유지보수를 계산하면 2시간. 총 비용 6시간 대 이득 36시간. 이건 해야 한다.

‘한 번만 쓸 것’의 반란

막상 보면 ‘이건 딱 한 번’이라고 생각한 작업이 팀에서 반복되는 경우가 있다. 반대도 있다. 분명 매달 있을 거라 믿었는데 프로젝트가 갑자기 방향을 틀면서 스크립트가 사장된다.

내가 제일 아깝다고 느낀 건 2026년 초, 클라이언트 데이터를 특정 포맷으로 변환하는 파이프라인을 이틀 동안 짠 일이다. 클라이언트 측에서 포맷을 바꾸겠다는 공지가 내가 배포하기 이틀 전에 왔다. 그 파이프라인은 한 번도 프로덕션에서 안 돌았다.

이 경험 이후로 ‘언제 처음 쓸지 모르는 자동화’는 최소 MVP 수준으로만 짠다. 예외 처리를 얇게, 로그는 최소한, 범용성은 나중에. 실제로 두 번 이상 쓰이는 게 확인되면 그때 고도화한다.

자동화를 미루는 게 맞는 경우

자동화를 ‘나중에’로 미루는 결정이 합리적인 상황이 있다. 아직 작업 자체가 안정화되지 않은 경우가 대표적이다.

프로세스가 계속 바뀌는 상황에서 자동화를 서두르면, 코드가 프로세스 변화를 따라가다 결국 누더기가 된다. 나는 한 서비스의 데이터 집계 방식이 분기마다 바뀌던 시절에 억지로 자동화했다가, 6개월 동안 세 번 전면 재작성을 했다. 수작업으로 버텼으면 오히려 더 빨랐을 수도 있다.

프로세스가 안정화됐는지 먼저 확인한다. 최소 2~3사이클을 수작업으로 돌려보고, 그 흐름이 바뀌지 않는다는 확신이 생길 때 자동화를 시작한다.
팀원 중 유일하게 이해하는 사람이 나뿐인 영역은 자동화보다 문서화가 먼저다. 블랙박스 스크립트를 만들면 나중에 내가 자리를 비울 때 팀이 아무것도 못 한다.
스크립트가 틀려도 바로 티가 나는 구조인지 확인한다. 조용히 잘못된 결과를 내는 자동화는 수작업 실수보다 훨씬 위험하다. 지난해 배치 잡이 조건 분기 하나를 잘못 탔는데, 아무 알림 없이 3주를 돌다가 리포트 이상함을 사람이 발견한 적 있다.

자동화 이후가 더 중요하다

자동화를 배포하고 나면 끝난 것처럼 느껴진다. 착각이다. 스크립트가 프로덕션에서 돌기 시작한 순간부터 관리 대상이 하나 더 생긴 거다.

내가 지금 운영하는 자동화 중 제일 오래된 건 약 1년 반 됐는데, 그동안 크고 작은 수정이 일곱 번 있었다. 처음 만들 때 예상한 유지보수의 세 배다. 그래도 이건 이득 쪽이다. 월 4~5시간씩 아끼는 작업이라 여전히 양수.

문제는 이득이 이미 마이너스로 돌아선 스크립트를 계속 붙들고 있는 경우다. 팀에 ‘이거 자동화돼 있으니까 괜찮아’는 안도감이 생기면, 실제로 얼마나 작동하고 있는지 검증을 안 한다. 정기적으로, 최소 분기에 한 번은 ‘이 자동화가 지금도 이득인가’를 다시 계산해야 한다.

다음 한 가지

지금 팀에서 돌고 있는 자동화 목록을 꺼내서, 각각 마지막으로 손익 계산을 언제 했는지 날짜를 적어보는 것부터 시작한다.

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

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