깨진 이미지를 통과시키는 텍스트 채점자, 비전 모델 1회로 막기

이미지 자동 생성 워크플로우를 돌리다가 이상한 걸 발견한 적 없나요? 로그는 전부 성공인데, 정작 올라간 이미지는 텍스트가 잘려 있거나 아예 회색 빈 화면인 경우요.

혼자 운영하면서 홍보 이미지 생성을 자동화해 직접 돌려 보니, 원인은 채점자가 이미지를 한 번도 안 본다는 데 있었어요. 텍스트 기반 LLM 채점자는 이미지 파일 자체를 못 읽어요. 대신 주변 신호만 봅니다. HTTP 200 응답, 파일 경로 존재 여부, 생성 프롬프트 내용 같은 것들이요. 그래서 파일 크기가 0KB인 깨진 이미지도 "프롬프트가 요구사항과 일치합니다"라며 통과시켜요.

테스트해 보면 이 허점이 생각보다 자주 뚫립니다. 폰트 로딩 실패로 글자가 네모로 깨진 경우, 텍스트가 캔버스 밖으로 넘친 경우, 배경만 생성되고 본문이 빠진 경우. 셋 다 파일은 정상적으로 저장되니까 텍스트 채점자 기준으로는 멀쩡한 산출물이에요.

이미지 생성→텍스트 채점(메타데이터만)→비전 모델 채점(픽셀 확인)→게시

해결은 단순했어요. 게시 직전에 비전 모델 채점을 딱 1회 끼워 넣는 거예요. 생성된 이미지를 멀티모달 모델에 실제로 보여주고 3가지만 묻습니다. 텍스트가 잘리지 않고 다 보이는지, 빈 화면이나 깨진 렌더링이 아닌지, 요청한 내용이 실제로 담겼는지. 하나라도 아니오면 재생성으로 돌려보내요.

플랜비(plan-b) 농구 동호회 앱의 안내 이미지를 만들 때 이 구조를 적용해 봤더니, 텍스트 채점만으로는 걸러지지 않던 오버플로 이미지가 비전 단계에서 잡히기 시작했어요. 채점 프롬프트를 붙이는 작업 자체는 10분 정도면 끝납니다. 노드 하나 추가하는 수준이에요.

비용이 걱정될 수 있는데, 채점은 생성보다 훨씬 싸요. 이미지 1장을 판정하는 입력은 보통 수백 토큰 단위라, 생성 호출 대비 부담이 작습니다. 깨진 이미지가 공개 채널에 올라가서 지우고 다시 올리는 비용과 비교하면 더 그렇고요.

• ✓텍스트 채점자는 픽셀을 못 본다
• ✓게시 전 비전 채점 1회
• ✓아니오 하나면 재생성

정리하면 원칙은 하나예요. 산출물의 매체와 채점자의 매체를 맞출 것. 글은 텍스트 채점자가, 이미지는 비전 채점자가 봐야 해요. 자동화 파이프라인에서 성공 로그는 실제 결과물이 멀쩡하다는 뜻이 아니더라고요. 여러분의 워크플로우에도 이미지가 흐르고 있다면, 게시 노드 앞에 비전 채점 1회부터 넣어 보세요.