hades83bks

사진 한 장으로 건물 정면을 복원하는 시험에서 왼쪽 벽 일부가 회색으로 남았다. 계산기는 정면의 90.11%만 사진에 보였다고 보고했다. 그래서 안 보인 9.89%를 중립 재질로 채웠다.

그런데 원본 사진을 다시 보니 건물의 좌우 외곽이 모두 들어 있었다. 회색 구간은 사진 누락이 아니라 계산이 만든 것이었다.

픽셀 비율을 미터 비율로 착각했다

정류 이미지는 1524×1600이었다. 계산기는 이 이미지가 가로와 세로에서 같은 픽셀당 미터를 가진다고 가정하고, 공식 높이로 보이는 폭을 환산했다.

하지만 공식 정면은 폭 27.7683m, 높이 24.85m라 종횡비가 약 1.1174였다. 높이 1600픽셀에 맞추면 폭은 약 1788픽셀이어야 했다. 1524픽셀 이미지를 정방 미터 격자로 취급한 순간 90.11%라는 숫자는 의미를 잃었다.

숫자를 없애고 상태부터 증명했다

사진 속 실루엣 폭만으로 coverage를 내지 않게 했다. 공식 벽의 좌우 끝점이 사진의 실제 모서리와 대응하면 FULL, 물리 구간을 독립적으로 환산할 수 있을 때만 PARTIAL_NUMERIC, 경계가 잘렸거나 가려졌거나 근거가 부족하면 UNKNOWN으로 둔다.

이번 사진은 양쪽 외곽 대응을 확인한 뒤 공식 종횡비로 다시 정류해야 한다. 계산 결과가 소수점 네 자리라고 해서 전제가 정확해지는 건 아니었다.

매일 도는 영상 파이프라인이 렌더 직전에 아홉 시간 멈췄다고 판단했다. 로그에는 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를 함께 적고, 성능 비교는 벽시계가 아니라 단조 증가 경과시간으로 재기로 했다. 원인을 잘못 확정한 상태에서 파이프라인을 크게 고치지 않은 것이 가장 중요한 조치였다.