프롬프트부터 39개 제품까지: 스톡 셀러를 위한 메타데이터 및 업로드 추적 파이프라인
요약
스톡 셀러를 위한 효율적인 메타데이터 및 업로드 추적 파이프라인 구축 방법을 소개합니다. 이 시스템은 여러 플랫폼의 상이한 CSV 헤더 요구사항과 중복 게시 방지 문제를 해결하며, 단일 Python 스크립트와 표준 라이브러리만으로 39개 제품을 처리할 수 있게 합니다.
핵심 포인트
- 플랫폼별 맞춤형 메타데이터 스크립트로 업로드 오류를 방지합니다.
- 원장(ledger) 시스템을 구축하여 중복 게시로 인한 계정 정지를 막습니다.
- 단일 엔진으로 여러 제품을 만들고, 표준 라이브러리만 사용해 저사양 환경에서도 구동 가능합니다.
- 작업 효율성을 위해 단일 프로세스 실행 및 메모리 관리가 중요합니다.
아직도 거절 이메일을 탭으로 열어두고 있습니다. Adobe는 제 CSV 헤더가 다섯 개가 아닌 여섯 개의 열을 가지고 있어서 벡터 14개를 한 번에 처리하지 못했습니다. Vecteezy는 네 개를 원했습니다. 저는 하나의 스프레드시트를 작성했고 모든 곳에서 작동할 것이라고 가정했습니다. 그렇지 않았습니다. 그 오후 때문에 저는 2주간의 대기 시간을 잃었고, 대기 시간은 솔로 셀러가 되찾을 수 없는 유일한 것입니다.
이 실패 경험 덕분에 제가 지금 운영하는 파이프라인은 프롬프트가 아니라 메타데이터와 추적부터 시작합니다. 제 자체 기록에 있는 숫자로 실제로 작동하는 방식은 다음과 같습니다.
하나의 프롬프트 엔진으로 여러 제품을 만들지만, 병목 지점은 아트워크 자체가 아니다
제가 구축한 프롬프트 엔진은 꾸준히 벡터 에셋 스트림을 만들어냈습니다. 아트를 만드는 것은 쉬운 부분이었습니다. 저를 계속해서 멈추게 했던 것은 네 가지 평범한 것들이었습니다: 각 플랫폼의 정확한 형식으로 업로드 CSV 작성, 이미 제출한 것을 기억하기, 문서를 판매 가능한 PDF로 변환하기, 그리고 사후 작업처럼 보이지 않는 커버가 있는 zip 파일 패키징.
이 네 단계를 스크립트화하자, 하나의 엔진은 39개의 완성된 제품, 856 MB의 출력으로 바뀌었고, 1 vCPU, 2 GB RAM, GPU 없이 서버에서 실행되었습니다. 클라우드 계정도, 프레임워크도 없었습니다. 총 네 개의 독립적인 Python 스크립트와 두 개의 서드파티 패키지만 사용했습니다: 커버용 Pillow, PDF용 reportlab. 메타데이터 및 추적 스크립트는 표준 라이브러리만 사용합니다.
CSV 헤더는 협상할 수 없다
Adobe의 일괄 업로드 템플릿은 5개의 열을 가지고 있습니다. Vecteezy는 4개입니다. Dreamstime은 15개입니다. 이 세 곳 모두 당신의 아트를 아무도 보기 전에 잘못된 헤더를 즉시 거절합니다. 부분 점수나 경고 같은 것은 없으며, 단지 실패한 배치와 어떤 열이 틀렸는지 알아내지 못하면 지원 티켓만 있을 뿐입니다.
메타데이터 스크립트는 각 플랫폼이 요구하는 헤더만 작성하고 그 외는 아무것도 하지 않습니다. 이 스크립트는 파일 폴더를 순회하며 파일명을 제목 형식(title-case)으로 변환하여 제목을 만들고 CSV 파일을 출력합니다. 만약 실제 제목과 키워드가 담긴 titles.json 파일을 전달하면, 그것들을 대신 사용합니다. 파일명 대체 방식은 첫 번째 시도에는 괜찮지만, 저는 제출하기 전에 항상 이를 교체합니다. 왜냐하면 'asset_0041_final' 같은 제목은 검토자나 구매자에게 스팸처럼 보이기 때문입니다.
중복 게시가 계정 정지 사유가 되는 가장 빠른 방법
이것 때문에 저도 초기에 어려움을 겪었습니다. 배치 스크립트를 다시 실행했는데, 이미 절반의 대기 목록을 제출했다는 사실을 깜빡하고 중복 파일을 올렸습니다. 플랫폼은 이를 품질 문제로 간주하며, 반복되는 중복 게시물은 계정 정지 사유가 될 수 있습니다. 해결책은 간단했지만 효과적이었습니다: 원장(ledger)입니다.
이 추적기는 세 가지 명령어로 구성된 평면 파일입니다. pending items.txt는 아직 완료되지 않은 항목을 보여주고, `done
제가 가장 강력하게 지지하는 것은 '연구(research)'입니다. 저는 한때 '정리'하려고 스크랩 로그와 메모를 삭제한 적이 있습니다. 하지만 그 메모들이 다음 세 가지 제품의 원자재였습니다. 그것들은 영원히 보관하세요.
작은 사양의 장비에서 실행하기 위한 참고 사항
저처럼 저렴한 VPS(Virtual Private Server)에서 작업하는 경우, vCPU 1개와 RAM 2GB면 충분하지만, 규율을 지켜야 합니다:
- 한 번에 하나의 프로세스만 실행하세요. 단일 코어에서 이미지 작업을 절대 병렬로 분산하지 마세요.
- 각 에셋 처리 후
gc.collect()를 호출하여 항목 간 메모리를 확보하세요. - 평균 RSS가 아닌 최대(peak) RSS를 측정하세요.
resource.getrusage(RUSAGE_SELF).ru_maxrss는 실제 한계치를 알려주며, 이 실제 한계치가 OOM(Out Of Memory)-킬을 유발합니다. - 무거운 렌더링 단계는 서브프로세스당 하나의 파일로 실행하여 메모리가 OS로 반환되게 하세요.
- 필요한 해상도로 렌더링하세요. 300dpi 대신 60dpi에서 미리보기를 검사하는 것이 다른 어떤 단일 변경보다도 더 많은 메모리를 절약해 주었습니다.
이 스크립트들 뒤에 숨겨진 전체 파이프라인은 약 19,000줄이며, 이 스크립트들이 적용하는 규칙들 뒤에는 300페이지가 넘는 연구 자료가 있습니다. 여기서 소개된 네 가지 도구는 단지 패키징 계층일 뿐이지만, 제가 파일 폴더에서 실제로 목록화할 수 있는 39개 제품까지 나아갈 수 있게 해준 바로 그 계층입니다.
저는 이 39개 제품을 만들어낸 정확한 스크립트들을 벡터 프롬프트 팩(vector prompt pack)에 담았습니다. 이것은 '이렇게 하는 방법'에서 끝나는 튜토리얼이 아닙니다. 그것은 실제로 작동하는 도구이며, 동일한 vCPU 1개, RAM 2GB 사양의 장비에서 검증되었을 뿐만 아니라 그 배경 연구 자료까지 포함하고 있습니다. 만약 이 내용 중 여러분이 부딪히고 있던 벽과 일치하는 부분이 있다면, 제가 잃었던 2주를 절약해 줄 것입니다.
디지털 제품을 제작하시나요? 디지털 제품 판매자를 위한 무료 가이드 및 키트.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기