자동화는 한 번 만들어 놓으면 조용히 일해 주는 줄 알았다. 김부장인 내가 보기에는 “입고 알림이 오면 시스템이 알아서 입고예정으로 잡아 주는 기능” 정도였다. 그런데 어느 날 저녁에 들어온 알림이 다음 날 화면에 보이지 않았다. 오류 메시지가 크게 뜬 것도 아니고 서버가 죽은 것도 아니었다. 그래서 더 헷갈렸다. 멈춘 게 아니라, 아무 일도 없었던 것처럼 지나가 버린 것이다.
조용히 빠진 저녁 알림
처음에는 알림방이 바뀌었나, 브랜드 라벨이 잘못됐나, 창고 매핑이 틀렸나를 먼저 의심했다. 업무 자동화에서 가장 무서운 문제는 “실패했다”가 아니라 “성공한 척 조용히 빠지는 것”이라는 걸 이때 다시 느꼈다.
AI와 함께 로그를 살펴보니 한 가지 문제가 아니라 여러 시간 조건이 겹쳐 있었다. 각각은 안전하게 운영하려고 넣은 장치였지만, 실제 업무 시간과 맞지 않으면서 저녁 알림을 놓치는 원인이 됐다.
시간 조건 세 가지가 겹쳤다
첫 번째는 실행 시간대 제한이었다. 자동화가 평일 특정 시간대에만 돌도록 되어 있었지만, 실제 업무 알림은 그 시간 밖에도 들어왔다. 저녁에 온 알림은 그 순간 처리되지 못하고 다음 실행을 기다렸다.
두 번째는 14시간 컷오프였다. 오래된 알림을 다시 처리하지 않으려고 둔 안전장치였는데, 저녁 알림이 밤을 지나 다음 날로 넘어가면 이 기준을 넘길 수 있었다. 중복 처리를 막으려고 만든 기준이 새 알림까지 “너무 오래됐다”고 판단하는 구조였다.
세 번째는 스케줄러 자체였다. 로그에는 missed execution 경고가 반복되어 있었다. 개발자가 아닌 내 눈에는 영어 경고 한 줄이었지만, AI가 짚어 준 뜻은 분명했다. 정해진 시각에 실행돼야 할 작업이 CPU나 입출력 때문에 제때 돌지 못했다는 신호였다.
화려하지 않았던 해결
해결은 화려하지 않았다. 실행 시간대 제한을 풀고, 컷오프를 14시간에서 48시간으로 늘렸다. 스케줄러도 정해진 시각을 기다리는 방식 대신 일정 간격으로 직접 확인하는 구조로 바꿨다.
라벨은 특정 브랜드명이 들어간 표현 대신 더 일반적인 “입고예정”으로 바꿨다. 화면에서도 브랜드별로 뭉뚱그리지 않고 전표 단위로 확인할 수 있게 했다.
처음에는 기존 시스템을 오가며 전표번호를 복원하려 했지만, 실제 데이터로 검증해 보니 그 방식은 실패했다. 결국 생성 시점에 필요한 값을 따로 기록하는 전용 테이블을 두는 쪽으로 방향을 바꿨다.
자동화가 하지 않기로 한 이유를 묻기
이번에 배운 점은 단순하다. 자동화에는 “언제까지 기다릴 것인가”라는 기준이 꼭 들어가는데, 그 기준은 생각보다 위험하다. 중복을 막는 시간 제한, 오래된 데이터를 버리는 컷오프, 특정 시간대에만 도는 스케줄은 모두 좋은 의도로 들어간다. 하지만 실제 업무 시간이 그 가정과 다르면 자동화는 틀렸다는 표시도 없이 너무 얌전하게 빠진다.
비개발자인 나는 코드를 다 이해하지 못해도 질문은 할 수 있다. “왜 안 됐지?”보다 “어느 기준 때문에 하지 않기로 판단했지?”라고 물어보는 것이다. 이번에도 AI와 함께 로그, 시간 조건, 컷오프, 실제 처리 결과를 나눠 보니 원인이 조금씩 좁혀졌다.
다음 편에서는 자동화가 처리한 결과를 “화면에 보인다” 수준이 아니라, 실제 기록 테이블과 처리 단위까지 확인해야 했던 이야기를 이어가 보려고 한다.