96) 17분짜리 작업을 9시간 정지로 계산했다

매일 도는 영상 파이프라인이 렌더 직전에 아홉 시간 멈췄다고 판단했다. 로그에는 2026-08-24T19:30:06.573Z가 찍혀 있었고, 다음 진행 화면은 새벽 4시 41분이었다. 숫자만 이어 붙이면 정말 아홉 시간처럼 보였다.

그래서 3.52GB짜리 공개 자산 폴더 복사와 디스크, 백신을 용의자로 올렸다.

로그 끝의 Z를 놓쳤다

타임스탬프 끝의 Z는 UTC였다. 19시 30분 UTC는 한국 시각으로 다음 날 04시 30분이다. 나는 UTC 시작 시각과 KST 진행 시각을 같은 시계처럼 빼고 있었다.

같은 시간대로 맞추자 전체 실행은 17.3분이었다. 롱폼은 04:46:34, 쇼츠는 04:47:11에 끝났다. 아홉 시간 정체는 없었다.

진짜 비효율과 가짜 장애를 분리했다

공개 폴더 3.52GB를 윈도우에서 렌더마다 복사하는 구조 자체는 실제였다. 하지만 그 복사가 아홉 시간 걸렸다는 증거는 아니었다. 긴급 장애와 앞으로 커질 비효율은 다른 문제였다.

기존 실행도 20.4분과 25.4분 안에 끝난 기록이 있었다. 같은 계열 작업의 평소 범위와 비교했어도 아홉 시간이라는 결론이 먼저 이상치로 보였어야 했다.

단계 로그에는 UTC와 KST를 함께 적고, 성능 비교는 벽시계가 아니라 단조 증가 경과시간으로 재기로 했다. 원인을 잘못 확정한 상태에서 파이프라인을 크게 고치지 않은 것이 가장 중요한 조치였다.