Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
스톡 에셋 판매 파이프라인의 자동화 한계를 분석하며, 기술적 프로세스는 완벽하게 자동화할 수 있지만 '판단'과 '감각(Taste)' 영역은 인간의 개입이 필수적임을 강조합니다. 특히 키워드 과부하 검토나 최종 상품 가치 판단 등은 스크립트가 대체할 수 없는 영역입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기지난달에 스티커 팩 40개를 파이프라인을 통해 처리했는데, 그중 하나가 "Untitled Asset 27 Copy"라는 제목으로 출고되었습니다. 저보다 먼저 구매자가 이를 발견했습니다. 그때 저는 전체 과정이 무인으로 돌아갈 수 있다는 척하는 것을 멈췄습니다. 왜냐하면 그럴 수 없기 때문이고, 할 수 없는 부분이 바로 리뷰어들이 실제로 보는 부분이기 때문입니다.
제가 작성한 스크립트가 하는 일과 제가 직접 눈으로 확인해야 하는 것 사이의 경계는 여기에 있습니다.
make_metadata.py는 세 플랫폼이 요구하는 정확한 헤더(Adobe의 5개 열 형식, Vecteezy의 4개 열 형식, Dreamstime의 15개 열 형식)를 작성합니다. 헤더 하나만 잘못해도 업로드가 즉시 거부되므로, 이 부분을 자동화하는 것은 시간당 가치가 있었습니다. 스크립트는 헤더에 대해서는 절대 실패하지 않습니다.
하지만 쓰레기로 가득 찬 유효한 CSV도 결국 거부됩니다. 다만 속도가 느릴 뿐입니다. 스크립트는 파일명을 타이틀 케이스(title-case)로 만들 수 있고, 파일명은 괜찮은 첫 번째 검사이지만, 저는 제출하기 전에 이를 수정합니다. 스톡 플랫폼의 리뷰어들은 키워드 과부하(keyword stuffing), 마치 키워드 목록처럼 보이는 제목, 이미지와 일치하지 않는 설명에 대해 거부합니다. 제가 아무리 작성해도 신뢰성 있게 판단할 수 있는 스크립트는 없습니다. 따라서 워크플로우는 다음과 같습니다: 스크립트가 CSV를 만들고, 저는 모든 행을 읽습니다. 40개 팩이라면 아마 90분 정도 걸릴 것입니다. 이것이 전체 과정에서 가장 가치 있는 90분입니다.
upload_tracker.py는 제가 이미 게시한 목록을 기록하여, 재실행 시 절대 중복으로 게시되지 않게 합니다. 이는 어떤 스톡 플랫폼에서 계정이 플래그(flagged)가 될 수 있는 가장 빠른 방법이 동일한 에셋을 두 번 제출하는 것이기 때문에 중요합니다. 이 장부는 그 부분을 처리합니다.
하지만 이것이 처리할 수 없는 것은, 해당 에셋을 아예 게시할 가치가 있는지에 대한 판단입니다. 저는 직접 보고 전체 묶음(batch)들을 삭제하기도 했습니다. 트래커는 제가 무엇을 했는지 기억할 뿐, 제가 했어야 할 일인지 아닌지는 알지 못합니다.
pack_product.py는 Pillow를 사용하여 1280×720 크기의 커버와 600×600 크기의 썸네일을 렌더링하며, 매번 동일한 방식으로 작동합니다. 제 1 vCPU, 2 GB 서버에서는 이 렌더링 단계가 파일당 개별 프로세스(subprocess)로 실행되므로 메모리가 OS로 돌아가고, 평균값에 의존하기보다 resource.getrusage(RUSAGE_SELF).ru_maxrss를 사용하여 최대 RSS(Resident Set Size)를 측정합니다. 이러한 규율 덕분에 전체 파이프라인은 GPU가 없는 박스에서 39개 제품, 856 MB의 결과물을 패키징할 수 있었습니다.
하지만 기술적으로 정확한 커버와 누군가의 클릭을 유도하는 커버는 다른 문제입니다. 저는 모든 커버를 실제로 표시될 썸네일 크기에 맞춰 검토합니다. 만약 제목이 600×600에서 읽기 어려우면, 그 렌더링은 낭비된 것입니다. 이 확인 과정은 제가 매번 직접 합니다.
RAM 사용 습관은 일반적입니다: 한 번에 하나의 프로세스를 단일 코어에서 실행하고, 각 에셋 처리 후 gc.collect()를 수행하며, 필요한 해상도에서 렌더링합니다 (60 dpi로 미리보기를 검사하는 것이 300 dpi보다 낫습니다). 이러한 규칙들은 300페이지가 넘는 연구와 수많은 실패한 실행 과정에서 나왔으며, 이제 스크립트에 코딩되어 있습니다.
코딩되지 않은 것은 무엇일까요: 제가 생성한 이미지 중 어떤 것이 좋은지입니다. AI 이미지 생성은 이미지당 실제 비용이 들고, 제 성공률은 5~6개 생성물 중 겨우 하나가 쓸만합니다. 스크립트는 그러한 판단을 내릴 수 없습니다. 저는 배치로 생성한 다음 앉아서 고릅니다. 이것이 파이프라인에서 가장 느린 인간의 단계이며, 저는 자동화하려는 시도를 그만두었습니다. 왜냐하면 모든 시도는 거절되거나, 더 나쁘게는 한 번 팔리고 환불된 '아슬아슬한' 카탈로그를 만들어냈기 때문입니다.
수동 단계를 돕는 것이었던 한 가지는 고정된 레이아웃이었습니다.
project/
assets/ 원시 출력물
output/ 제출 준비 파일 + metadata.csv
...
research/ 폴더를 영구적으로 유지하는 것은 어떤 제목과 키워드가 승인되었는지에 대한 제 메모가 다음 배치 작업을 할 때 남아있다는 의미입니다. 저는 한 번
그래서 제 파이프라인의 실제 업무 분담은 이렇습니다. 스크립트들이 처리하는 부분은 다음과 같습니다: 정확한 플랫폼 헤더를 가진 메타데이터 CSV, 중복 게시 방지, reportlab을 이용한 Markdown을 스타일화된 PDF로 변환, 커버와 썸네일과 함께 패키징이며, 이 모든 것이 총 두 개의 서드파티 패키지(Pillow 및 reportlab)만을 사용하여 1 vCPU와 2 GB RAM에서 실행됩니다. 메타데이터와 트래커 스크립트는 표준 라이브러리만 필요합니다.
제가 처리하는 부분은 다음과 같습니다: 모든 타이틀을 읽고, 모든 키워드 목록을 이미지와 대조하며, 모든 커버를 썸네일 크기로 확인하고, 여러 세대(generation) 중에서 보존할 것을 선택하는 것입니다. 배치당 약 40개 항목에 90분이 걸립니다. 이것이 줄일 수 없는 인간의 노동력이며, 저는 이 사실을 받아들였습니다.
제가 그 업무 분담, 스크립트, RAM 규칙, 폴더 레이아웃, 플랫폼 헤더 형식 등을 구축하면서 배운 모든 것이 ai sticker factory playbook에 담겼습니다. 이것은 이 작업에 대한 설명이 아니라, 이 작업으로 만들어진 도구입니다. 자동화가 판단을 제외한 모든 것을 처리하기를 원한다면—어차피 멈춰야 할 곳이 바로 그 판단 지점이니까요—그것이 여기에 있습니다.
ai sticker factory playbook 받기
디지털 제품을 만들고 계신가요? 디지털 제품 판매자를 위한 무료 가이드 및 키트.