자동화의 무력화 — 사람 손이 다시 들어가는 신호

자동화를 도입하면 처음에는 만족스럽다. 반복되는 작업이 사라지고, 사람이 개입하지 않아도 일이 굴러가는 느낌이 든다. 그런데 어느 순간 이상한 일이 생긴다. 파이프라인은 녹색인데 결과가 이상하다. 알림은 오는데 아무도 보지 않는다. 자동화가 맞는 방향으로 가고 있는지 아무도 확신하지 못한다.

우리 팀도 이 상황을 겪었다. 그리고 그 경험을 통해 “자동화가 사람 손을 다시 요구하는 신호”가 무엇인지 조금씩 파악하게 됐다.

신호 1 — 아무도 로그를 보지 않을 때

자동화 초기에는 로그를 자주 확인한다. 정상적으로 돌아가는지 불안하기 때문이다. 그러다 시간이 지나면 로그 확인이 줄어든다. 여기까지는 자연스러운 흐름이다.

문제는 “아무도 보지 않기 때문에 아무도 모르는 상태”가 지속될 때다. 파이프라인이 매일 실패하고 있었는데 3주 뒤에야 알게 되는 경우가 실제로 있었다. 알림은 설정했지만 채널에 묻혀버렸고, 아무도 그 채널을 챙기지 않았다.

이때 자동화를 고치는 것보다 먼저 해야 할 일은 “누가 이 자동화의 상태를 책임지는가”를 명확히 하는 것이다. 책임자가 없는 자동화는 서서히 방치된다.

신호 2 — 예외 처리가 점점 커질 때

처음에는 자동화가 커버하는 범위가 80%였다. 나머지 20%는 수동으로 처리했다. 그런데 몇 달이 지나면 수동 처리 비중이 35%, 40%로 늘어나는 경우가 있다. 도메인이 바뀌었거나 입력 데이터의 형태가 달라졌거나 예외 케이스가 누적된 것이다.

이 상태를 방치하면 자동화가 오히려 짐이 된다. 자동화 결과를 신뢰하지 못하게 되고, 그 결과를 검증하기 위해 사람이 또 일을 한다. 자동화가 없을 때보다 일이 늘어나는 역설이 생긴다.

이 시점에 해야 할 것은 예외 케이스를 다시 분류하고, 자동화 범위를 현실에 맞게 재정의하는 것이다. 자동화를 확장하는 방향이 아니라 범위를 줄여 신뢰성을 높이는 쪽이 나을 때도 있다.

신호 3 — 팀원이 자동화 결과를 직접 고칠 때

자동화가 만들어낸 결과물을 팀원이 직접 수정하기 시작하면, 그 자동화는 이미 반쯤 무너진 것이다. 자동화된 보고서를 받아서 수치를 손으로 고치고, 자동 배포된 파일을 받아서 일부를 다시 덮어쓰는 상황이 반복된다면 자동화가 사람의 판단을 보조하는 것이 아니라 사람이 자동화의 오류를 수정하는 구조가 된 것이다.

이럴 때 우리 팀은 해당 자동화를 일시 중단하고 처음부터 다시 설계 기준을 검토했다. 고통스럽지만, 그냥 두는 것보다는 훨씬 빠르게 상황이 개선됐다.

자동화는 한 번 만들면 끝이 아니다

자동화도 코드처럼 유지보수가 필요하다. 도메인이 바뀌고, 팀이 바뀌고, 인풋이 바뀐다. 자동화가 처음 설계된 환경이 그대로 유지되는 경우는 드물다. 우리가 배운 것은 자동화를 “완성된 시스템”이 아니라 “관리 대상 컴포넌트”로 취급해야 한다는 것이다.

사람 손이 다시 들어가는 것은 실패가 아니다. 그것은 자동화가 현재 상태와 맞지 않는다는 신호이고, 재조정이 필요하다는 피드백이다. 그 신호를 무시하지 않는 것이 중요하다.

— by slecs