자동화가 사람보다 느렸던 날들

자동화를 믿었던 시절

자동화는 언제나 옳다고 믿던 시기가 있었다. 반복 작업이 눈에 보이면 일단 스크립트를 짰다. 그게 엔지니어다운 태도라고 생각했다.

막상 몇 년 지나고 보니, 자동화가 문제를 만든 경우가 자동화가 문제를 푼 경우만큼 많았다.

올해 초, 배포 후 헬스체크 결과를 Slack에 자동으로 올리는 봇을 만들었다. 서버 8대, 배포 채널 3개. 매번 수동으로 확인하기 귀찮아서였다.

구현에 이틀 걸렸다. Python + GitHub Actions 조합으로, 배포 완료 시점에 각 인스턴스의 /healthz 를 찍어서 결과를 채널에 붓는 방식이었다. 처음 나흘은 잘 돌았다.
문제는 다섯째 날 배포 때 터졌다. 스테이징 환경 한 대가 헬스체크를 늦게 응답했다. 봇은 타임아웃으로 실패 처리했고, Slack엔 DEPLOY FAILED 메시지가 떴다. 팀 전체가 롤백 준비를 시작했다. 실제로는 정상 배포였다.
그 소동을 수습하는 데 40분 걸렸다. 수동으로 했으면 8대 /healthz curl 때리는 데 3분이면 됐을 일이다. 봇 신뢰도는 그날 이후 회복되지 않았고, 결국 두 달 뒤 봇을 걷어냈다.

자동화가 신호를 만들어낸 게 아니라 노이즈를 만들어냈다.

팀 주간 리포트를 자동화하자는 아이디어는 그럴듯했다. Jira API 로 이슈를 긁어서 GPT로 요약해 Notion에 넣는 파이프라인. 구축에 사흘.

매주 월요일 오전 9시에 문서가 자동 생성됐다. 처음 두 주는 팀원들이 “오 신기하다” 했다. 세 번째 주부터 아무도 열지 않았다. 자동 생성 문서는 맥락이 없었다. 이슈 제목을 요약한 것뿐이라, 왜 그 일을 했는지가 빠져 있었다.
결정적으로, 리포트를 직접 쓰는 20분 동안 팀장이 그 주를 자연스럽게 복기했다. 자동화하면서 그 복기 시간이 사라졌다. 리포트의 주 소비자는 팀장 본인이었는데, 생산 과정을 없애버렸던 것이다.
파이프라인을 끄고 다시 직접 쓰기로 했다. 불릿 세 개, 10분. 훨씬 낫다.

자동화가 프로세스의 부산물까지 없애버린 경우였다.

외부 파트너사에서 넘어오는 CSV가 매주 형식이 조금씩 달랐다. 컬럼 순서, 인코딩, 빈 행 위치. 담당자가 매번 손으로 다듬고 있었다.

나는 pandas 스크립트를 만들어줬다. 케이스별로 분기해서 자동 정제하는 로직. 파일 하나에 110줄. 처음 한 달은 잘 돌았다.
문제는 파트너사가 형식을 또 바꿀 때마다 스크립트가 조용히 틀린 결과를 냈다는 것이다. 조용히. 에러를 내지 않고 그냥 잘못된 데이터를 통과시켰다. 담당자가 손으로 할 때는 눈으로 훑으면서 이상한 행을 잡아냈는데, 스크립트는 그 감각이 없었다.
두 달 차에 잘못된 데이터가 리포트에 섞여서 고객사에 발송됐다. 수습에 이틀. 스크립트가 절약해준 시간은 2개월 x 주 1회 x 약 15분 = 120분이었다. 사고 수습 비용은 훨씬 컸다.

지금은 스크립트 대신 검증 체크리스트를 만들었다. 담당자가 직접 보되, 확인할 항목을 명확히 했다. 이게 더 안정적이다.

실패한 사례들을 늘어놓고 보니 공통점이 있었다.

입력이 불안정한 작업. 외부 파트너 CSV처럼 형식이 자주 바뀌면, 스크립트는 따라가지 못하면서 에러도 안 낸다. 사람은 이상하면 멈춘다. 스크립트는 이상해도 그냥 간다. 이게 더 위험하다.
판단이 필요한 작업. 헬스체크 봇은 타임아웃이 실패인지 서비스 특성인지를 구별 못 했다. 그 판단에는 컨텍스트가 필요한데, 스크립트는 컨텍스트를 모른다.
프로세스 자체가 결과물인 작업. 주간 리포트처럼 쓰는 행위 자체가 가치를 만들 때, 자동화는 껍데기만 남긴다.

자동화가 효과적인 건 입력이 안정적이고, 판단이 필요 없고, 출력만 필요할 때다. 그 조건을 충족 못 하면 사람이 더 빠르고 안전하다.

새 자동화를 만들기 전에 딱 한 줄만 적는다: “이게 실패했을 때 조용히 실패하나, 시끄럽게 실패하나.” 조용히 실패하면 일단 멈춘다.

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

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