자동화를 만들었더니 자동화를 돌보게 됐다

자동화를 구축하면 손이 자유로워질 거라고 생각했어요. 그런데 어느 날 보니, 저는 자동화를 '운영'하고 있었어요.

해방됐다고 착각했던 순간

편의점 1+1 행사 앱을 출시하고 나서 가장 먼저 손댄 게 자동화였어요. 새 행사 데이터를 수집하고, 가공하고, DB에 밀어 넣는 흐름을 파이프라인으로 묶었죠. 처음 돌아가는 걸 보고 “이제 됐다” 싶었어요. 뭔가 영리한 기계를 만들어놓은 느낌.

그 착각은 한 2주 갔어요.

파이프라인은 살아있는 게 아니었다

문제는 조용히 왔어요. 어느 날 보니 최신 행사 데이터가 안 들어와 있었어요. 파이프라인은 에러도 없이 ‘성공’으로 찍혀 있었고요. 원인을 파보니 데이터 소스 쪽 구조가 살짝 바뀌어 있었어요. 제가 파싱하던 필드명이 달라진 거예요. 파이프라인은 멀쩡히 돌았지만, 빈 값만 열심히 수집하고 있었던 거죠.

자동화는 세상이 변해도 자기가 바뀌지 않는다.

그 다음엔 스케줄러가 슬그머니 멈춰 있었어요. 호스팅 플랜을 한 번 조정했는데, 그게 크론 설정에 영향을 줄 거라고는 생각을 못 했어요. 역시 조용히, 아무 알림 없이.

자동화 위에 자동화를 쌓기 시작했다

그래서 모니터링을 붙였어요. 파이프라인이 제대로 도는지 확인하는 감시자를요. 그런데 이 감시자도 가끔 오탐을 냈어요. “실패”라고 알람이 오는데 실제로는 정상인 경우가 생겼어요. 알람에 둔감해지기 시작했고, 진짜 실패를 놓칠 뻔한 적도 있었어요.

자동화를 관리하려고 자동화를 추가하고, 그걸 또 봐야 하는 상황. 어느 순간 저는 앱 기능 개선보다 파이프라인 상태 확인에 더 많은 시간을 쓰고 있었어요.

파이프라인도 결국 내가 주기적으로 들여다봐야 하는 무언가가 된다.

자동화의 무게

자동화는 분명히 도움이 돼요. 반복 작업을 없애준 건 맞아요. 근데 ‘한 번 만들면 끝’이라는 건 환상이었어요. 자동화는 세팅 비용이 아니라 유지 비용으로 나한테 청구됐어요. 외부 의존성이 많을수록, 파이프라인이 길수록 그 청구서는 두꺼워졌고요.

지금은 자동화를 새로 만들기 전에 스스로한테 한 번 물어보게 됐어요. “이거 망가지면 내가 얼마나 빨리 알 수 있지? 고치는 데 얼마나 걸리지?” 그 답이 흐릿하면 일단 손으로 하는 쪽을 택해요.

복잡한 자동화보다 단순한 루틴이 오래 살아남더라고요.

1인 빌더한테 자동화는 레버리지이기도 하지만, 동시에 부채이기도 해요. 저는 그걸 좀 늦게 알았어요.