자동화는 몇 번째 반복부터 이득인가

자동화를 언제 해야 하는지 물어보면 “반복되면”이라고 답한다. 그런데 막상 해보면 그 기준이 얼마나 모호한지 금방 드러난다.

자동화 비용을 제대로 계산한 적이 없었다

처음에는 “스크립트 짜는 데 두 시간이면 되겠지” 하고 시작한다. 그 두 시간이 여섯 시간이 되고, 테스트·문서화·예외처리까지 합치면 이틀이 된다. 직접 경험한 사례가 있다. 배포 후 슬랙에 릴리즈 노트를 붙여넣는 작업이었는데, 매번 3분 걸리는 일이었다.

자동화 작업 총 투입: 약 6시간 — GitHub Actions 트리거 세팅, 슬랙 Webhook 포맷 맞추기, 브랜치 필터 예외처리까지. “금방 끝날 줄”이 늘 거짓말인 이유는 예외 케이스가 반드시 한 개씩 더 나오기 때문이다.
손익분기 계산: 6시간 ÷ 3분 = 120회. 즉 배포가 120번은 일어나야 본전이다. 월 평균 배포 횟수가 15~20회였으니 6개월이 지나야 본전이었다.
결국 그 자동화는 4개월차에 슬랙 앱 권한 변경으로 깨졌다. 고치는 데 또 한 시간을 썼다. 손익분기가 다시 뒤로 밀렸다.

유지보수 비용을 초기 계산에 넣는 습관이 그때 생겼다.

XKCD 5년 공식을 실제로 써봤다

유명한 XKCD ‘Is It Worth the Time?’ 표가 있다. 하루에 몇 번, 얼마나 단축되는지로 5년치 절약 시간을 보여준다. 처음엔 그냥 재미있는 그림으로 봤다.

팀에서 스테이징 DB를 주 3회 리셋하는 작업이 있었다. 한 번에 20분짜리. 주 60분, 연간 52주 기준 3,120분. 5년이면 15,600분, 260시간이다.
자동화 투입이 하루였다. 8시간. 260시간 절약이면 계산이 된다 — 단, 그 자동화가 5년 내내 살아남는다는 가정 하에.
실제로 그 스크립트는 18개월 후 DB 엔진 버전 업그레이드 때 절반이 다시 쓰였다. “5년 가정”이 얼마나 낙관적인지가 거기서 드러났다.

그래서 나는 지금 5년 공식을 1.5년으로 잘라서 쓴다. 스크립트 수명을 넉넉하게 잡아봐야 18개월이다.

자동화가 오히려 손해였던 경우

막상 해보면 자동화가 독이 되는 상황이 있다. 작업 자체보다 자동화 코드를 이해하는 사람이 더 없어지는 경우다.

인프라 프로비저닝 스크립트를 혼자 짰다. Terraform + 사내 래퍼 스크립트. 이걸 알고 있는 사람이 나 하나였는데, 내가 팀을 이동한 뒤 후임이 오류를 만났을 때 전체 절차를 손으로 다시 밟아야 했다. 자동화 이전보다 오히려 느렸다.
로그 파싱 자동화도 비슷했다. awk 파이프 네 단계짜리 스크립트가 있었는데, 여섯 달 뒤 로그 포맷이 바뀌고 아무도 고치지 못해 그냥 손으로 다시 파싱했다. 자동화가 없었을 때보다 상황 파악이 더 늦었다.
규칙이 하나 생겼다: 자동화 작성자가 자리를 비울 때 다른 사람이 30분 안에 고칠 수 없으면, 그 자동화는 자산이 아니라 부채다.

그래서 지금 쓰는 기준

복잡한 공식 말고 현실에서 빠르게 판단할 체크리스트가 필요했다. 두 가지로 줄였다.

“앞으로 4주 안에 10번 이상 할 것인가” — 그렇지 않으면 손대지 않는다. 배포 스크립트, DB 백업 검증, 헬스체크 이런 것들은 해당이 된다. 반기마다 한 번 하는 감사 리포트 추출은 해당이 안 된다. 지금은 그냥 손으로 한다.
“내가 없어도 동료가 오류를 읽고 고칠 수 있는가” — 이 기준을 넣은 뒤로 README 없는 자동화 스크립트를 커밋하지 않게 됐다. 사실 처음엔 귀찮아서 넣지 않았는데, 인프라 이동 사건 이후로는 습관이 됐다.

10번 기준은 XKCD 표보다 훨씬 보수적이다. 고의로 그렇게 잡았다. 자동화 욕구를 억누르는 게 목적이다.

반복 횟수보다 중요한 것

손익분기를 계산할 때 반복 횟수만 보다가 놓치는 게 있다. 그 작업을 언제 하냐는 맥락이다.

새벽 2시에 온콜 중에 손으로 해야 하는 작업이 있다고 하자. 월 2회다. XKCD 기준으로는 자동화할 이유가 없다. 그런데 새벽 2시에 졸린 눈으로 DB 플래그 하나를 잘못 보면 그 한 번의 실수가 모든 계산을 무너뜨린다. 실제로 2026년 초에 그런 일이 한 번 있었다. 커맨드를 잘못 복사해서 스테이징이 아닌 프로덕션에 붙여넣었고, 롤백하는 데 40분이 걸렸다.

그 이후로 기준에 “실수 비용”을 항목으로 추가했다. 횟수가 적어도 실수 한 번의 파급이 크면 자동화 우선순위가 높아진다. 반대로 횟수가 많아도 실수가 즉각 눈에 띄고 영향이 없으면 낮춘다.

다음 한 가지

다음 분기에 짠 자동화 스크립트 하나를 골라서, 지금까지 실제로 몇 번 실행됐는지 로그로 세고 처음 계산과 비교해본다.

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

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