AI 활용기: 작업자는 끝났는데 운영자는 계속 busy였다 — 완료 감지와 우선순위의 빈틈

먼저 답하면

AI 작업이 늦어진 것처럼 보여도 작업 자체가 오래 걸린 것인지, 끝난 결과를 운영자가 늦게 읽은 것인지 먼저 나눠 봐야 한다. 10월 3일 개인 제작 공장의 오후 영상 작업을 조사하면서 두 번째 문제가 실제로 드러났다.

실제 기록에서 확인한 두 지연

이 공장은 한 번에 한 작업만 맡긴다. 작업자가 결과 파일을 쓰고 보고해도, 그 사실만으로 운영자의 새 턴이 시작되는 경로가 없었다. 완료된 작업이 실행 중 기록에 남고, 운영자가 다음 예약이나 사용자 메시지에서 다시 움직일 때까지 다음 작업도 대기했다. 기록의 경과 시간에는 그 대기까지 섞였다. 이 숫자를 AI의 실제 제작 시간으로 읽으면 원인을 잘못 고치게 된다.

선택 순서에도 별도 문제가 있었다. 종류와 관계없이 가장 오래된 예약부터 골라 밀린 점검·감사가 오후 생산보다 앞섰다. 전날 오후 영상은 예정 시각을 넘겨 17:03에 맡겨졌고, 이날 오후에는 오전에 밀린 점검부터 선택됐다. 기록과 선택 코드를 대조해 확인한 사례이며, 정확한 작업 식별자나 운영 계정은 공개하지 않는다.

완료 감지와 다음 실행을 분리했다

수정한 감시는 1분마다 결과 파일 또는 실제 시작 기준 시간 상한을 확인한다. 조건이 되면 등록된 운영자에게 알림만 보낸다. 감시가 스스로 완료 처리하거나 다음 작업을 실행하는 구조는 아니다. 운영자가 작업자 보고와 결과 계약을 대조한 뒤 상태를 닫는다.

같은 실행·같은 사건의 중복 알림을 막고 전송 실패는 다시 시도하도록 했다. 운영자 교체·일시정지 조건도 확인한다. 결과 파일이 일부만 쓰인 상태와 알림 실패를 회귀 시험에 포함했다. 다만 1분 주기는 즉시 실행 보장이 아니다. 기기의 절전이나 운영자 처리 지연은 별도로 남는다.

온라인 문서와 비교하면

Celery의 감시 문서는 작업 수신·시작·성공·실패 사건과 작업자의 heartbeat를 구분한다. 작업자가 살아 있다는 사실과 특정 작업이 끝났다는 사실을 같은 신호로 취급하지 않는 비교 사례다. 이번 공장이 Celery를 도입했다는 뜻은 아니다.

Python의 큐 문서는 FIFO와 우선순위 큐의 선택 기준이 다르다고 설명한다. 이번에는 시간이 된 생산을 점검보다 먼저 선택하되, 같은 종류 안에서는 기존 예약 순서를 유지했다. 미래 생산을 미리 실행하거나 현재 작업을 끊지는 않는다. 라이브러리를 바꾸는 문제보다 어떤 순서를 원했는지 정의하는 문제였다.

다음에는 세 시각을 본다

완료 파일 작성, 운영자의 종료 기록, 다음 작업 배정 시각을 분리해서 본다. 첫 구간이 길면 제작을, 두 번째가 길면 알림·감시를, 세 번째가 길면 우선순위와 게이트를 조사할 수 있다. 오늘 수정은 불필요한 완료 대기와 밀린 점검의 선점을 줄이는 장치이지, 모든 작업을 정시에 시작시킨다는 보장은 아니다. 예약 자체가 밀린 이전 사례와도 구분해야 한다.