Adobe 거절 사유를 모두 읽어보니, 대부분은 하나의 규칙 때문이었다

저는 아직도 다른 탭에 그 거절 이메일을 열어두고 있습니다. 60개의 벡터 배치 작업, 3주간의 생성 작업이 있었는데, Adobe에서 거의 모든 것에 대해 거절 통보가 왔습니다. 처음에는 이유들이 무작위로 보였습니다. '제목 품질', '키워드', '유사 콘텐츠'. 저는 주말을 보내며 지금까지 받은 모든 거절 사유를 하나하나 읽고 스프레드시트에 정리했고, 짜증 나는 것을 발견했습니다. 대부분은 아트워크에 관한 것이 아니라 메타데이터에 관한 하나의 규칙으로 거슬러 올라간다는 것입니다.

거절 사유는 한 가지 범주로 묶인다

실제로 계산해 보니, 거절 사유들은 소수의 그룹으로 나뉘었습니다. 이미지 자체의 품질 문제였던 것은 실제로 존재했고 제가 받을 만한 것이었습니다. 하지만 대다수는 다른 모습으로 위장한 메타데이터 문제입니다. 키워드 목록을 그대로 읽는 제목. 이미지에 눈에 보이는 내용과 일치하지 않는 키워드. 내가 교체하지 않은 파일 이름이 자동으로 제목으로 승격된 경우.

마지막 경우는 제 잘못이었고, 제가 보는 다른 제작자들이 하는 가장 흔한 실수입니다. 제 파이프라인은 파일 이름을 제목처럼 대문자로 변환하여 그것을 제목이라고 간주했습니다. 'Blue Geometric Pattern 042'는 제목이 아니라 공백이 있는 파일 이름일 뿐입니다. Adobe의 검토자들은 하루에 수백 개를 보며, 올바르게 거절합니다.

해결책은 지루했습니다. 저는 파이프라인이 임의로 제목을 만들도록 두는 것을 멈췄습니다. 이제 titles.json 파일이 있으며, 에셋당 실제 제목 하나와 실제 키워드 세트가 포함되어 있고, 이 내용은 이미지를 본 사람이 작성합니다. CSV 빌더는 해당 파일이 존재하면 그것을 읽습니다. 만약 존재하지 않으면 파일 이름 대체(fallback) 기능이 여전히 실행되지만, 저는 그것을 첫 번째 시도일 뿐이며 절대 제출용으로는 사용하지 않습니다.

모든 플랫폼은 헤더가 있으며, 그 헤더는 같지 않다

거절 사유 스프레드시트가 가르쳐준 두 번째 교훈은 다음과 같습니다. '파일 형식 오류' 거절의 상당 부분은 단순히 잘못된 CSV 헤더 때문입니다. Adobe는 5개 열의 헤더를 원합니다. Vecteezy는 4개 열을 원하고, Dreamstime은 15개를 원합니다. Adobe용 형식을 Vecteezy에 제출하면 사람이 작업물을 보기 전에 실패합니다.

이전에는 세 개의 스프레드시트를 사용하고 그 사이의 열을 수동으로 복사했습니다. 이 때문에 중복 게시물과 불일치하는 행들이 발생했습니다. 그래서 저는 파일 폴더를 받아 각 플랫폼이 요구하는 정확한 헤더만 출력하는 스크립트, make_metadata.py를 작성했습니다. 하나의 폴더, 세 개의 명령어, 그리고 세 개의 올바른 CSV 파일을 사용하는 방식입니다:

python make_metadata.py ./my-assets --platform adobe      --out metadata.csv   --ext .jpg
python make_metadata.py ./my-assets --platform vecteezy   --out vecteezy.csv   --ext .jpg
python make_metadata.py ./my-assets --platform dreamstime --out dreamstime.csv --ext .jpg

이 헤더는 의도적으로 구성할 수 없습니다. 만약 플랫폼의 형식이 변경되면, 제가 스크립트를 수정합니다. 만약 제가 CSV에 추가 열을 넣으려고 '개선'한다면, 저는 즉시 거절당하는 상황으로 돌아갑니다.

아무도 경고해주지 않는 거절 사유: 배치 작업을 두 번 실행하기

이것 때문에 실제 검토 신뢰도를 잃었습니다. 부분적으로 실패한 후 업로드 배치를 다시 실행하면서, 어떤 항목들이 이미 처리되었는지 잊었고 카탈로그의 일부를 중복 게시했습니다. 중복 제출은 제가 아는 가장 빠른 계정 플래그링 방법이며, CSV가 완벽하더라도 이 메타데이터 스크립트로는 막을 수 없습니다. 문제가 있는 것은 사용자 자신입니다.

해결책은 단순한 원장(ledger)입니다. upload_tracker.py는 이미 게시된 내용을 기억하는 일반 파일입니다:

python upload_tracker.py pending items.txt
python upload_tracker.py done "asset-001.jpg"
python upload_tracker.py status

pending은 아직 나가지 않은 항목만 보여줍니다. 이제 재실행을 해도 물리적으로 중복 게시할 수 없습니다. 왜냐하면 트래커가 제 배치 목록과 업로드 큐 사이에 위치하기 때문입니다. 이것은 표준 라이브러리만을 사용하며, 설치가 필요 없고, 파이프라인의 다른 어떤 것보다도 많은 계정 손상을 막아주었습니다.

거절되기 전의 거절: 기계가 포기하는 경우

메타데이터 측을 수정하는 과정에서 생성(generation) 측도 살아남게 해야 했습니다. 초기 배치 작업의 절반이 실행 도중에 죽었기 때문입니다. 전체 시스템은 GPU 없이 1 vCPU와 2 GB RAM으로 작동하기 때문에, 이를 유지하는 규칙들이 매우 엄격합니다:

• 한 번에 하나의 프로세스만 처리합니다. 단일 코어에서 이미지 작업을 병렬로 수행(fan out)하지 마세요.
• 모든 에셋마다 gc.collect()를 호출합니다.
• 평균 메모리가 아닌, 피크 RSS(Peak RSS)를 resource.getrusage(RUSAGE_SELF).ru_maxrss로 측정해야 합니다. 왜냐하면 피크 값이 시스템을 다운시키기 때문입니다.
• 무거운 렌더링 단계는 각 서브프로세스별로 파일 하나씩 처리하여 메모리가 실제로 OS로 반환되게 해야 합니다.
• 구도를 확인하기 위해 300dpi로 렌더링하는 대신, 60dpi에서 미리보기(preview)를 검사합니다.

이전에는 에셋 30개에서 죽던 배치가 이제 끝까지 실행됩니다. 이 과정을 통과한 모든 에셋은 '서버 오류, 재제출' 사이클을 일으키지 않는 에셋입니다.

제가 그 수많은 이메일들로부터 실제로 배운 것들

쌓여 있는 상태로 읽으면 거절당했다는 느낌이 개인적인 것처럼 느껴졌습니다. 하지만 하나하나 읽어보니, 거의 모두 같은 교훈이었습니다. 플랫폼들은 예술 자체를 거절하는 것이 아니라, 예술 주변의 부실함(sloppiness)을 거절한다는 것입니다. 잘못된 헤더, 지어낸 제목, 중복 제출, 미완성 배치 작업 등입니다. 예술 자체는 제가 더 적고 좋은 프롬프트를 사용해서 충족시킬 수 있는 품질 기준만 통과하면 되었습니다.

메타데이터, 추적(tracking), 패키징 계층이 자동화되자, 혼란을 야기했던 동일한 프롬프트 엔진은 39개의 완성된 제품으로 변모했습니다. 이는 약 856 MB의 패키지 출력물이며, 대략 19,000줄의 파이프라인 코드와 300페이지 이상의 연구 노트(research notes)를 기반으로 구축되었습니다. 이 노트들은 제가 더는 삭제하지 않는 research/ 폴더에 보관되어 있습니다. '정리'하기 위해 스크랩 로그를 삭제하는 것은 제가 딱 한 번 저지른 실수였습니다.

이 네 가지 스크립트를 하나의 키트로 패키징했습니다. 이전에 2GB 박스에서 실행되었던 것과 같은 스크립트들입니다. 이것은 코스가 아니며, 예술 작품을 생성해주지도 않습니다. 이것은 패키징 레이어입니다: 세 플랫폼 모두를 위한 메타데이터 빌더, 업로드 트래커, Markdown-to-PDF 컨버터, 그리고 파일을 압축하고 1280x720 커버와 600x600 썸네일을 렌더링하는 제품 패키저입니다. 총 두 개의 의존성(dependency), Pillow와 reportlab이 필요하며, 메타데이터 및 트래킹 스크립트는 Python만 있으면 됩니다.

키트 보기

디지털 제품을 제작하시나요? 디지털 제품 판매자를 위한 무료 가이드 및 키트.