자동화가 오히려 느렸던 세 번의 기억
자동화가 항상 빠른 건 아니다. 막상 해보면 사람이 더 빠른 경우가 있다.
자동화를 믿었다가
올해 초, 신규 파트너사 온보딩 스크립트를 짰다. 계정 생성 → 권한 부여 → 슬랙 알림 → 위키 페이지 생성. 총 4단계, 코드 약 300줄.
막상 돌려보니:
- 파트너사마다 계정 형식이 미묘하게 달라 예외 분기가 7개 붙었다
- 위키 API 응답이 불안정해서 재시도 로직 추가
- 슬랙 채널 이름 규칙이 팀마다 달라 수동 확인 단계 삽입
- 결국 운영자가 스크립트 실행 전후로 각각 5분씩 붙어 있어야 했다
예전 방식: 운영자가 체크리스트 보고 직접 처리. 걸리는 시간 12분. 자동화 후: 스크립트 실행 + 모니터링 + 예외 처리. 실질 시간 19분.
자동화가 느려지는 패턴
겪어보니 공통점이 있었다.
입력 데이터가 정규화되지 않은 경우. 사람은 “아, 이건 이렇게 해석하면 되지” 가 되는데, 스크립트는 모든 케이스를 코드로 써줘야 한다. 예외가 30% 이상이면 자동화 유지비가 사람 인건비를 넘긴다.
빈도가 낮은 작업. 월 1~2회짜리를 자동화했다가 6개월 뒤 API 스펙 바뀌어서 스크립트가 조용히 죽어있는 경우. 발견 비용이 자동화 이익을 잡아먹는다.
“자동화됐다” 는 착각이 안전 불감증을 만드는 경우. 사람이 직접 하면 이상한 냄새를 맡는다. 스크립트는 이상한 냄새를 모른다. 에러 없이 틀린 결과를 낸다.
2026년 기준으로 LLM 을 자동화 파이프라인에 끼워넣는 시도를 종종 보는데, 이 패턴이 더 심해진다. 비결정적 출력 + 낮은 빈도 작업 조합은 특히 위험하다.
다음 한 가지
자동화 후보를 검토할 때 “월 몇 회, 예외율 몇 %” 를 먼저 적어두고, 예외율 25% 넘으면 자동화 보류를 기본값으로 삼기로.
🛒 이 글과 어울리는 추천 상품
위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.