중단한 AI 이미지 배치가 계속 쓴 크레딧

백그라운드 배치를 중단한 뒤에도 새 PNG가 계속 생겼습니다.

크레딧 잔액도 계속 줄었습니다.

중단 명령은 작업이 취소됐다고 보고했습니다. 그래서 배치를 실행한 인터페이스에서는 이미 종료된 것처럼 보였습니다. 하지만 Windows에서 그 결과가 전체 프로세스 트리의 중단을 뜻하지는 않았습니다.

bash.exe 프로세스 2개가 여전히 생성 배치를 실행하고 있었습니다. 하나는 30분 전에 제가 “중단한” GPT 실행의 프로세스였습니다. 다른 하나는 nano 실행의 프로세스였습니다. 그 아래에서는 생성 명령을 실행하는 프로세스들이 계속 살아 있었습니다.

sh.exe → node.exe → hf.exe

래퍼는 멈췄습니다. 자식 프로세스들은 멈추지 않았습니다.

부모 프로세스를 취소하는 것만으로는 부족했습니다

배치는 Windows의 Git Bash를 통해 백그라운드에서 실행됐습니다. 내부에는 처리할 항목을 계속 읽어 Higgsfield 생성 명령을 실행하는 루프가 있었습니다.

백그라운드 작업을 중단하자 해당 작업의 래퍼는 종료됐습니다. 하지만 종료가 자식 프로세스 트리까지 전파되지는 않았습니다. 자식 bash.exe는 부모를 잃은 고아 프로세스로 계속 실행됐고, 그 안의 while read 루프는 배치의 다음 항목을 계속 처리했습니다.

그래서 인터페이스와 출력 폴더가 서로 다른 상황을 보여줬습니다.

인터페이스는 작업이 중단됐다고 했습니다. 하지만 실제 생성 프로세스의 하위 프로세스들이 살아 있었기 때문에 폴더에는 이미지가 계속 들어왔습니다. Higgsfield에도 요청이 계속 전달돼 크레딧이 소모됐습니다.

프로세스 이름만으로는 해당 트리를 식별할 수 없었습니다. Windows에서는 셸, Node, 명령줄 프로세스가 동시에 여러 개 열려 있을 수 있습니다. 흔한 실행 파일 이름만 보고 같은 이름의 프로세스를 전부 종료하는 것은 정확한 방법이 아닙니다.

식별에 도움이 된 것은 명령줄이었습니다.

명령줄로 실행 중인 프로세스를 살펴봤습니다

검증에 사용한 조회 방식은 Win32_Process였습니다.

Get-CimInstance Win32_Process |
  Where-Object { $_.CommandLine -match 'generate-faces|higgsfield' }

이 명령으로 명령줄에 배치나 Higgsfield 생성 관련 문자열이 포함된 프로세스를 찾았습니다.

조회 결과 살아남은 bash.exe 프로세스 2개와 그 아래의 자식 프로세스들이 확인됐습니다. 백그라운드 작업 인터페이스가 이들을 기억하고 있는지에 의존하지 않았습니다. Windows에 무엇이 아직 실행 중인지 직접 물었습니다.

무엇이든 중단하기 전에 검색 결과부터 검토했습니다. 명령줄을 통해 각 PID가 비용이 발생하는 생성 작업에 속하는지 확인했습니다. bash.exe만 따로 찾는 것보다 안전하고 유용합니다. bash.exe라는 이름은 어떤 실행 파일이 실행 중인지만 알려줍니다. 그 파일이 무슨 일을 하고 있는지는 알려주지 않습니다.

정확한 PID를 식별한 뒤 생성 트리의 각 프로세스에 Stop-Process -Force를 사용했습니다.

중요한 것은 강제 종료 옵션 자체가 아니었습니다. 그 전에 PID를 골라낸 과정이었습니다. 종료 대상은 모두 명령줄을 통해 해당 배치에 속한다는 것을 확인한 상태였습니다.

중단만큼 중요한 것은 재확인이었습니다

저는 중단 명령을 작업이 끝났다는 증거로 보지 않았습니다. 이미 한 번 틀린 가정이었습니다.

일치하는 PID를 중단한 뒤 ps aux | grep으로 프로세스 목록을 다시 확인했습니다. 같은 배치 및 Higgsfield 관련 문자열을 검색했습니다. 관련 프로세스가 하나도 남지 않았을 때만 배치가 중단됐다고 판단했습니다.

이 마지막 확인이 종료 명령을 내리는 것과 실제 효과를 확인하는 것 사이의 빈틈을 메웁니다.

일반적인 로컬 배치라면 고아 셸은 번거로운 문제에 그칠 수 있습니다. 유료 생성 배치에서는 계속 발생하는 지출입니다. 저는 실행을 취소했다고 믿고 있어도, 루프가 돌 때마다 새 작업이 만들어질 수 있습니다.

출력 폴더도 또 다른 경고를 줍니다. 새 파일이 계속 생긴다면 래퍼가 무엇을 보고하든 배치는 중단되지 않은 것입니다. 크레딧 잔액도 과금 측면에서 같은 경고를 줍니다.

하지만 둘 다 주된 확인 수단이 되어서는 안 됩니다. 다음 이미지가 나타나거나 잔액이 바뀔 때는 이미 또 다른 요청이 전송됐을 수 있습니다. 직접 확인해야 할 대상은 프로세스 트리입니다.

배치가 기록하는 정보를 바꿨습니다

비용이 발생하는 배치 스크립트는 자신의 PID를 기록해야 합니다.

실행을 중단해야 할 때 정확한 출발점이 생깁니다. 기록된 프로세스를 식별하고 하위 프로세스를 살펴본 뒤, 어떤 명령줄이 배치에 속하는지 확인할 수 있습니다.

PID가 있다고 Windows에서 자식 프로세스를 확인할 필요가 없어지는 것은 아닙니다. 확인이 빨라지고, 여러 셸이 실행 중일 때 모호함이 줄어듭니다.

이제 전체 중단 절차는 실행 후의 긴급 정리가 아니라 배치 운영 자체에 포함됩니다.

배치를 시작하고 PID를 기록합니다. 취소할 때는 의도한 작업을 중단합니다. Win32_Process에서 일치하는 명령줄을 찾습니다. 생성 트리에 속한다고 확인된 프로세스를 모두 중단합니다. 관련 프로세스가 하나도 남지 않을 때까지 다시 확인합니다.

그때야 배치가 중단된 것입니다.

지금 제가 지키는 원칙

취소 성공 메시지는 Windows의 유료 배치가 끝났다는 증거가 아닙니다.

증거는 해당 배치와 생성 명령을 검색했을 때 프로세스가 하나도 나오지 않는 것입니다. 일치하는 명령줄에 연결된 bash.exe, sh.exe, node.exe, hf.exe가 남아 있다면 작업은 계속될 수 있습니다.

Windows에서 비용이 발생하는 AI 배치를 실행한다면 오늘 PID 기록을 추가해 보세요. 다음에 배치를 취소할 때는 명령줄을 기준으로 Win32_Process를 조회하고, 전체 트리가 사라진 것을 확인한 뒤 중단됐다고 판단하세요.

---

이 글의 해결책은 모두 제가 먼저 실수의 대가를 치르고 얻은 것입니다. 여러분의 브랜드보다 제 영화에서 겪는 편이 낫습니다.