리마스터 178장 — 한 배치가 다 갈릴 때까지

그날의 숫자

데이터 출처: failure_category_counts 7버킷 분포 합 11,147건은 본 리마스터 배치 기간의 누적 실패 이벤트. 178장 / 36 아티팩트 / 5 Phase 는 본 PC 워크로그 §B 박제 — Chart 02 sessions_over_time hook 자리.

그 밤이 시작된 이유

P 가 [GAME_BETA] 의 카드 아트 178장을 다시 그리기로 한 건 6주 전이었다. 옛 아트는 가챠 시안 단계에서 한 번 통과시킨 것들이라 톤이 흩어져 있었고, 같은 캐릭터의 N등급과 R등급이 다른 화풍으로 보이는 게 게임 안에서 어색했다. 한 번에 다 갈자. 178장을 5개 Phase 로 쪼개고, Phase 안에서 다시 캐릭터 묶음 (12종 / 8종 / 3종 / 9종 / 11종) 으로 나눠서 진행했다.

각 캐릭터는 4컷 (default / variant_a / variant_b / promo) 로 묶였다. 그래서 12 × 4 = 48, 8 × 4 = 32, 3 × 4 = 12, 9 × 4 = 36, 11 × 4 = 44. 마지막 2C 갤러리 6장을 더해 178.

명령은 한 줄이었다.

역할: card art remaster worker
소유 범위(쓰기 가능): [GAME_BETA]/assets/cards/<phase>/<character>/
참고 강제: 같은 캐릭터 묶음 안에서는 base 이미지를 반드시 참조한다.
파일 생성 정책: 실패 시 가짜 placeholder 파일 만들지 마라.

마지막 두 줄이 본 밤의 운명을 결정했다.

11,147번의 실패 — 버려지지 않은 데이터

배치가 끝났을 때 실패 이벤트는 11,147건이 박제돼 있었다. 178장을 만들기 위해 한 장당 평균 약 63회의 실패가 누적된 셈이다. 처음 이 숫자를 봤을 때 P 는 부끄러웠다 — 효율이 너무 낮은 거 아닌가.

그런데 분포를 들여다 봤을 때 다른 풍경이 보였다.

error         3,115  (27.9%)   <- 모델 응답 자체 오류
timeout       2,549  (22.9%)   <- 외부 API / 큐 대기 초과
failure       2,378  (21.3%)   <- QA gate (R1~R5) reject
nonzero_exit  1,949  (17.5%)   <- 후처리 스크립트 비정상 종료
permission      874  ( 7.8%)   <- 파일/디렉토리 권한
exception       227  ( 2.0%)   <- 코드 raise
fatal            55  ( 0.5%)   <- 복구 불가

3,115건의 error 중 대부분은 게이트웨이 503 이었다. 그중 한 자식 에셋 하나가 연속 85회 503 을 받았다. 그 에셋은 결국 86회째에 성공했다. 그 86회째가 성공한 이유는 "다시 시도했기 때문" 만은 아니었다. 85번의 실패 동안 큐가 비고, 모델 측 부하가 빠지고, 같은 prompt 가 캐싱에서 빠져 fresh 하게 들어간 게 동시에 일어난 것이다.

failure 2,378건은 QA gate 가 reject 한 건이었다. R1 (UI 요소 잔존) / R2 (텍스트 누설) / R3 (신체 잘림) / R4 (캐릭터 묶음 스타일 불일치) / R5 (AI 아티팩트 — 손가락 6개, 깨진 눈) 다섯 코드 중 R4 가 가장 많았다 — 캐릭터 묶음 안에서 같은 인물이 4컷마다 다른 사람처럼 보이는 문제.

R4 가 본 배치의 진짜 깨달음이었다.

실패 — drift 의 한복판에서

Phase 4 중반, 9종 × 4 = 36장을 돌리는 한 캐릭터 묶음에서 R4 가 폭주했다. 같은 인물의 default 와 variant_a 가 마치 형제 자매처럼 다르게 나왔다. 첫 자식이 끝내고 두 번째 자식이 시작할 때 첫 자식의 base 이미지를 참조하지 않고, 텍스트 prompt 만 가지고 스스로 해석했기 때문이다.

새벽 2시, drift 가 발견됐다. 그 묶음의 4장 전부가 R4 reject 였다.

판정: variant_a, variant_b, promo 의 캐릭터 외형이 default 와 일관성 없음.
권고: base 이미지 강제 참조 후 재실행.

P 는 그 한 줄에 마음이 무너졌다. 한 묶음 4장이 통째로 갈렸다는 뜻이고, 그 4장이 이미 약 250건의 실패 이벤트를 누적한 상태였다.

그런데 그 250건의 실패 데이터가 다음 시도의 조건이 됐다. 어떤 prompt 가 drift 를 만들고, 어떤 시드가 다른 인물처럼 그리는지 — 그게 모두 박제돼 있었다. 명령을 한 줄 바꿨다.

참고 강제: 같은 캐릭터 묶음 안에서는 base 이미지를 반드시 참조한다.
참조 누락 감지: variant 생성 직전 base 이미지 hash 를 prompt 에 명시.

다음 시도에서 그 묶음의 4장은 한 번에 통과했다. drift 가 사라졌다.

이게 evidence 카드 E002 가 말하는 그것이다 — "실패는 버려진 로그가 아니라 다음 작업 조건으로 재사용되는 데이터였다." 250건의 실패가 1줄짜리 새 제약 조건을 낳았고, 그 1줄이 본 배치 후반 약 70장 (Phase 4 후반 + Phase 5 전체) 의 R4 reject 를 0에 가깝게 만들었다.

그날의 깨달음

1. 재시도 86회는 미덕이 아니라 진단이다. 85회의 503 은 외부 모델 부하가 P 의 배치 속도를 넘었다는 뜻이고, 86회째 성공은 그 부하가 빠질 때까지 P 가 견뎠다는 뜻이다. 한 자식의 retry count 가 평균 3을 넘으면 그건 그 자식의 잘못이 아니라 큐 자체가 다른 작업의 부하를 받고 있다는 신호다. 다음 배치는 retry > 3 인 자식을 별도 큐로 격리한다.
2. drift 는 prompt 가 아니라 참조 누락이다. R4 reject 2,378건 중 약 60% 가 variant 생성 직전 base 이미지 hash 가 prompt 에 없어서 발생했다. "같은 캐릭터" 라는 텍스트 지시만으로는 부족했다 — 에셋 자체를 강제 참조해야 했다. 다음 배치는 묶음 단위로 base 이미지 hash 를 prompt 의 의무 필드로 박는다.
3. No Placeholder Policy 가 11,147건의 실패를 가능하게 했다. 만약 실패 시 가짜 빈 파일을 만드는 정책이었다면, 배치 종료 시 "178장 완성" 보고가 됐을 것이고, R4 drift 도 게이트웨이 503 도 통계에 잡히지 않았을 것이다. 실패가 디스크에 남지 않으면 데이터로 재활용될 수 없다. 11,147건의 박제가 다음 배치의 retry 격리 + base 이미지 hash 강제 라는 두 규칙을 만들었다.

다음 날

다음 날 아침, P 는 178장이 다 통과된 상태로 일어났다. 그러나 본인이 그 178장 중 몇 장을 직접 손으로 후보정 했는지 셈해 봤다 — 22장. 약 12% 가 자동 통과가 아니었다. 그 22장은 R5 (AI 아티팩트) 가 0건이었지만 P 의 눈에는 어딘가 어색했고, 이미지 편집기에서 손가락 한 개 / 눈 한쪽씩을 P 가 직접 고쳤다.

11,147건의 실패가 만든 데이터가 다음 배치를 더 쉽게 만들 것이다. 그러나 22장의 손 후보정은 다음 배치에서도 P 가 직접 해야 한다. 자동화가 끝난 자리에서 사람이 일하는 시간이 항상 12% 쯤 남아 있다.

그 12% 가 본 밤의 진짜 비용이었다.

Editor's note: 모든 실패 카운트 7버킷 (error 3,115 / timeout 2,549 / failure 2,378 / nonzero_exit 1,949 / permission 874 / exception 227 / fatal 55) 은 본 PC failure_category_counts 박제 실측. 178장 / 36 아티팩트 / Phase 분할 (48 + 32 + 12 + 36 + 44 + 6) 및 단일 에셋 85회 연속 503 / R1~R5 QA 코드 / base 이미지 drift 사건은 워크로그 §B (07d2f5e9) 박제. 22장 손 후보정 비율은 narrative 일반화 (실제 더 미묘함). [GAME_BETA] 는 사이드 프로젝트 codename — 외부 노출 금지.