글쓴이: 작두뉴스 운영자 / 기록일: 2026년 8월 19일

기사 열 편에 들어갈 이미지를 한꺼번에 만들던 날이었다. 글마다 세 장씩 필요해서 결과는 모두 서른 장이어야 했다. 생성 명령을 실행하고 프로그램이 끝나기를 기다렸는데, 시간이 지나도 종료되지 않았다. 결국 첫 실행에서 기대한 서른 장을 제대로 확보하지 못했다.

처음에는 이미지 생성 자체가 실패한 것으로 생각했다. 하지만 작업 기록을 따라가 보니 생성 요청과 파일 저장, 실행 프로그램의 종료가 한 덩어리가 아니었다. 결과 파일이 만들어졌더라도 명령을 감싼 과정이 계속 살아 있을 수 있었다. 반대로 명령이 끝났다는 사실만으로 모든 파일이 정상이라는 보장도 없었다.

문제의 중심은 무엇을 기다렸느냐였다. 나는 프로그램의 종료 신호를 완료 기준으로 삼았다. 실제로 필요한 것은 지정한 위치에 기대한 파일이 생기는 일이었다. 둘이 항상 동시에 일어날 것이라고 가정한 것이 잘못이었다.

두 번째 실행부터는 기준을 바꿨다. 정해진 간격으로 결과 폴더를 확인하고, 예상한 파일명이 실제로 생겼는지 세었다. 각 글마다 표지, 중간, 끝 이미지가 모두 있는지 확인했다. 프로그램이 아직 살아 있어도 서른 장이 모두 생기면 다음 검증 단계로 넘어갈 수 있었다.

파일 수만 세는 것으로도 부족했다. 이름이 맞아도 크기가 0이거나 열리지 않는 파일이 있을 수 있다. 그래서 파일 존재, 크기, 이미지 해석 가능 여부를 따로 확인했다. 화면에서 직접 볼 대표 표본도 골랐다.

대량 작업에서는 결과물 이름을 미리 고정해 두는 것이 도움이 됐다. 글 슬러그 뒤에 역할을 붙이면 누락을 찾기 쉽다. 예를 들어 같은 글에 `_cover`, `_mid`, `_end`를 붙이면 세 장 중 어느 것이 없는지 바로 알 수 있다. 임의 번호만 쓰면 나중에 본문과 연결할 때 다시 대조해야 한다.

재시도할 때는 이미 만들어진 정상 파일을 덮어쓰지 않게 조심했다. 실패했다고 생각해 전체를 처음부터 다시 돌리면 비용과 시간이 두 배로 든다. 먼저 현재 폴더에서 완성된 파일과 누락된 파일을 나누고, 부족한 것만 다시 요청하는 편이 안전하다.

이번에는 첫 결과를 잃은 뒤 서른 장을 다시 만들었고, 두 번째 결과는 파일 기준으로 확인했다. 생성 프로그램이 종료됐다는 한 줄보다 '예상 파일 30개, 실제 파일 30개, 해석 실패 0개'라는 검증 기록이 더 명확했다.

비슷한 문제는 이미지뿐 아니라 영상 변환, 압축, 원격 전송에서도 생긴다. 명령이 성공 상태로 끝났지만 산출물이 빠질 수 있고, 화면에는 멈춘 것처럼 보여도 파일은 이미 만들어졌을 수 있다. 완료 조건은 도구의 상태가 아니라 내가 필요로 하는 결과에 맞춰야 한다.

기다림에도 제한이 필요하다. 무한히 확인만 반복하면 멈춘 작업을 알아차리지 못한다. 예상 파일 수, 최대 대기 시간, 마지막으로 새 파일이 생긴 시각을 함께 기록하면 진행 중인지 멈췄는지 구분하기 쉽다.

파일이 모두 생긴 뒤에도 기사에 들어갔다는 뜻은 아니다. 본문 자료와 파일명을 연결하고, 운영 서버에 올라갔는지 확인하고, 실제 기사 화면에서 불러오는지 봐야 한다. 생성 완료와 송출 완료는 별개의 단계다.

오늘 사고는 '프로그램이 언제 끝나는가'에만 시선을 둔 데서 시작했다. 작업의 목적은 프로그램을 종료시키는 것이 아니라 기사에 쓸 정상 이미지 서른 장을 얻는 것이었다. 목적을 완료 조건으로 다시 쓰자 검사 방법도 달라졌다.

앞으로 같은 작업에서는 먼저 예상 파일 목록을 만든다. 실행 중에는 실제 파일 수와 마지막 변경 시각을 확인한다. 끝난 뒤에는 크기와 해석 가능 여부를 검사한다. 마지막으로 기사 화면에서 연결까지 본다. 이 네 단계가 있어야 생성 도구의 침묵을 성공이나 실패로 성급하게 해석하지 않을 수 있다.