성공 로그 820건이 고유 작업 805건인 이유

생성 로그에는 ok: true로 표시된 항목이 820개 있었지만, 서로 다른 job_id 값은 805개뿐이었습니다.

두 숫자 모두 정확합니다. 어느 쪽도 제가 현재 이미지를 몇 장 가지고 있는지는 알려주지 않습니다.

제작 집계가 어긋나기 시작하는 지점이 바로 이 간격입니다. 성공한 로그 항목이라고 하면 완성된 자산처럼 들립니다. 고유 작업이라고 하면 더 깔끔해 보입니다. 하지만 고유 작업에도 재시도와 나중에 교체된 출력물이 포함된다는 사실을 확인했습니다.

이 중 어느 수치든 “완성된 이미지” 수로 사용하면 예산을 붙이기도 전에 작업량을 부풀리게 됩니다.

성공한 로그 한 줄이 보존된 이미지 한 장은 아닙니다

가장 명확한 예는 Copycat입니다.

로그에는 성공 항목 278개와 서로 다른 작업 ID 263개가 있습니다. 즉, 성공 횟수를 그대로 세면 일부 작업이 중복됩니다. job_id 기준으로 중복을 제거하면 그 부분의 집계는 바로잡을 수 있습니다.

Borrowed Wounds에는 같은 불일치가 없습니다. 성공 항목 332개에 서로 다른 작업 ID도 332개입니다. Everybody Sleeps at Nine은 66과 66입니다. Low Water는 45와 45입니다. What Darkness Keeps는 99와 99입니다.

그렇다고 고유 작업 총수가 최종 자산 총수가 되는 것은 아닙니다. 같은 작업에 대한 반복 항목만 제거한 것입니다.

로그 5개를 합치면 성공 항목 820개가 서로 다른 작업 805개로 줄어듭니다. 이 805개에는 여전히 재시도와 더 이상 현재 선택본이 아닌 출력물이 포함됩니다. 중복 제거는 동일한 작업이 중복되는 문제를 해결합니다. 제작 상태 문제까지 해결하지는 않습니다.

재시도도 실제 작업일 수 있으므로 이 구분은 중요합니다. 교체된 출력물도 실제 작업의 결과일 수 있습니다. 생성은 실제로 일어났습니다. 제가 그 작업을 실행한 것도 사실입니다. 하지만 어느 사실도 그 출력물이 현재 라이브러리에 남아 있다는 뜻은 아닙니다.

숫자를 선택하기 전에 제가 어떤 질문에 답하고 있는지 알아야 합니다.

로그에 기록된 활동을 점검한다면 성공 항목 820개가 맞습니다.

서로 다른 기록 작업을 센다면 805개가 맞습니다.

현재 명세서의 출력물을 센다면 근거를 댈 수 있는 총수는 713개입니다.

서로 별개의 답입니다.

폴더에서는 또 다른, 틀려 보이는 답이 나왔습니다

원본 이미지 디렉터리 5개에는 이미지 파일이 843개 있습니다.

현재 출력물 713개보다 많은 이유는 명세서에서 더 이상 다루지 않는 버전과 잔여 파일도 폴더에 남아 있기 때문입니다. 파일 시스템 집계는 디렉터리에 살아남은 모든 것을 셉니다. 어떤 파일이 현재 유효한지는 모릅니다.

저는 보수적인 자산 목록을 만들 때 명세서를 사용합니다. 프로젝트 전체의 명세서에는 작성된 이미지 프롬프트 1,078개와 현재 출력물 713개가 있습니다.

출력물 713개는 캐릭터 이미지 196장, 장소 이미지 88장, 소품 이미지 74장, 의상 이미지 59장, 스토리보드 이미지 296장으로 나뉩니다.

이 분류는 현재 자료를 설명합니다. 모든 생성 활동을 재구성하는 것은 아닙니다. 고유 작업 805개는 제작의 다른 층위를 설명합니다.

그래서 폴더를 열어 파일을 센 다음 그 결과를 자산 총수라고 부를 수 없습니다. 폴더는 이력을 보존합니다. 명세서는 현재 상태를 추적합니다. 생성 로그는 활동을 추적합니다.

셋 다 유용합니다. 서로 대체할 수는 없습니다.

누락된 로그도 총수를 왜곡합니다

The Lord Is With Thee에는 현재 출력물이 64개 있지만 생성 로그는 없습니다.

이 이미지들은 현재 출력물 집계에 들어가야 합니다. 생성 로그가 없으므로 로그에 기록된 작업 집계에는 더할 수 없습니다.

불편하지만 필요한 한계가 생깁니다. 고유 작업 805개가 프로젝트 전체의 모든 현재 이미지를 빠짐없이 집계한 수치는 아닙니다. 존재하는 로그 5개에서 확인할 수 있는 서로 다른 작업들입니다.

저는 출력물 64개를 근거도 없이 작업 총수에 억지로 넣기보다 그 경계를 드러내 두겠습니다.

각 프로젝트를 서로 다른 방식으로 측정했는데도 모든 프로젝트를 같은 보고 열에 맞추려 하면 제작 집계의 신뢰도가 떨어집니다. 증거가 없다는 것은 활동이 없었다는 뜻이 아닙니다. 활동을 알 수 없다는 뜻입니다.

집계 오류 다음에 예산 오류가 발생합니다

생성 예산에는 단위가 필요합니다. “만든 이미지”라는 표현은 너무 모호합니다.

성공한 로그 행을 뜻합니까? 서로 다른 작업입니까? 원본 디렉터리에 저장된 파일입니까? 현재 명세서의 출력물입니까? 작성된 프롬프트입니까?

저는 그 서로 다른 질문에 대해 820, 805, 843, 713, 1,078을 셌습니다. 가장 큰 숫자를 선택한다고 더 안전한 추정이 되는 것은 아닙니다. 가장 작은 숫자를 선택한다고 보수적인 추정이 되는 것도 아닙니다. 올바른 숫자는 그 숫자에 연결된 비용 또는 제작상의 질문에 따라 달라집니다.

예산 항목이 실행한 작업에 관한 것이라면 서로 다른 작업 ID가 필요하고, 재시도와 교체된 작업이 포함되어 있음을 밝혀야 합니다.

현재 라이브러리에 관한 항목이라면 명세서의 출력물이 필요합니다.

계획한 작업을 측정하려면 현재 출력물이 없는 것까지 포함해 작성된 프롬프트가 필요합니다.

오류는 산술이 아닙니다. 이름을 바꿔 붙이는 데 있습니다.

“성공”, “고유”, “현재”, “작성”은 서로 다른 상태를 설명합니다. 이 표기가 사라지면 스프레드시트는 정밀해 보여도 일관된 질문에 답하지 못할 수 있습니다.

오늘은 생성 로그 하나에서 서로 다른 job_id 값을 세어보세요. 그다음 해당 명세서의 현재 출력 경로 수와 비교하세요. 두 숫자를 모두 남기고 각각 다른 이름을 붙이세요. 실제로 입증할 수 없다면 어느 쪽도 “최종 이미지”라고 부르지 마세요.

---

사용한 크레딧, 시도 횟수, 측정한 결과를 기록합니다. 제가 숫자를 믿는 이유는 누구에게도 아첨하지 않기 때문입니다. 특히 저에게는 더 그렇습니다.