과도한 requirements.txt가 구매자를 잃게 만든다: 대신 네 개의 스크립트와 두 개의 패키지를 배포하라

지난 3월, 저는 eleven 패키지가 포함된 requirements.txt를 가진 제품을 출시할 뻔했습니다. Requests, beautifulsoup4, YAML 라이브러리, PDF 라이브러리 2개, 이미지 툴킷 등 제가 솔직히 설명할 수 없는 몇 가지 것들이었습니다. 한 구매자가 출시 전에 이슈를 제기했습니다: “저는 단순히 CSV 파일만 만들고 싶은데, 왜 웹 스크래퍼까지 설치해야 하나요?” 이 댓글은 맞았기에 저에게 큰 충격이었습니다. 저는 전체 파이프라인의 의존성들을 하나의 파일에 묶어놓고 그것을 제품이라고 생각했던 것입니다.

저는 그 주 동안 모든 것을 다시 작성했습니다. 결과물은 독립적인 네 개의 스크립트와 정확히 두 줄로 이루어진 requirements.txt입니다. 제가 무엇을 어떻게 바꿨는지, 그리고 다른 제작자들에게 도구를 판매하는 경우 왜 이것이 중요한지 알려드리겠습니다.

구매자는 README보다 requirements.txt를 먼저 읽는다

누군가 스크립트 번들에 9달러를 지불할 때, 설치 과정은 첫 번째 신뢰 테스트입니다. eleven 패키지는 “이건 난장판이니 행운을 빌어요”라는 메시지를 전달합니다. 두 개의 패키지는 “저는 이게 무엇을 하는지 압니다”라는 메시지를 전달합니다. Pillow는 커버 렌더링에, reportlab은 PDF 출력을 위해 사용됩니다. 그게 전부입니다. 네 개의 스크립트 중 두 개(메타데이터 빌더와 업로드 트래커)는 파이썬 표준 라이브러리만을 사용합니다. 설치가 전혀 필요 없습니다. 만약 구매자가 Adobe와 Vecteezy의 CSV 파일만 원한다면, 베어한 Python 3.9 설치 환경에서 스크립트를 실행하면 작동합니다.

이 분리는 상업적으로 중요합니다. 메타데이터 도구를 구매하는 사람들은 종종 청중 중에서 가장 기술적이지 않은 판매자들입니다. pip install 과정은 그들이 포기할 수 있는 지점일 수 있습니다.

CSV 헤더가 진짜 제품이다

이것은 제가 몇 달 동안 잘못 알고 있던 부분입니다. Adobe Stock은 5개 열의 업로드 CSV를 원합니다. Vecteezy는 4개의 열을 원하고, Dreamstime은 15개를 원합니다. 헤더 하나만 틀려도 플랫폼은 전체 파일을 즉시 거부하며, 그 이유에 대해서는 아무것도 배우지 못하게 됩니다. 저는 지난 2월에 단 하나의 열 이름이 잘못되었다는 이유로 40개 자산 배치(asset batch)를 세 번이나 재제출하느라 오후 시간을 허비했습니다.

따라서 make_metadata.py는 세 플랫폼 모두에 대한 정확한 헤더를 하드코딩하고 그 외에는 아무것도 작성하지 않습니다. 설정 파일도, 템플릿 편집도 필요 없습니다. JPG 폴더를 지정하고 --platform adobe를 전달하면 첫 번째 검토 단계를 통과하는 CSV 파일을 얻을 수 있습니다. 파일 이름은 제목 대문자(title cased)가 되는데, 이는 초기 단계에는 괜찮지만, 이 스크립트는 titles.json을 받아 제출 전에 실제 제목과 키워드를 공급할 수 있게 해줍니다. 플랫폼들은 메타데이터 품질을 판단하며, asset_041_final.jpg와 같은 파일 이름을 제목으로 사용하는 것은 도움이 되지 않습니다.

더블 포스팅(Double-posting)은 플래그를 받기 가장 빠른 방법

아무도 경고하지 않는 실패 모드: 업로드 배치를 실행했는데, 17번째 행에서 시간이 초과되고, 이를 수정하고, 배치를 다시 실행합니다. 이제 1행부터 16행까지가 중복됩니다. 스톡 플랫폼들은 이를 스팸 행위로 간주하며 계정에 기록을 남깁니다.

upload_tracker.py는 단순한 원장(ledger)이며, 약 백 줄 분량이고 표준 라이브러리만 사용합니다. pending은 아직 완료되지 않은 항목을 보여주고, done은 에셋을 표시하며, status는 개수를 알려줍니다. 영리하지 않습니다. 이는 재실행이 안전한 것과 재실행이 계정 정지 위험이 되는 차이입니다. 파이프라인이 새벽 2시에 무인으로 실행될 때, 똑똑하기보다 단순하고 신뢰할 수 있는 것이 더 좋습니다.

패키징은 파일이 제품이 되는 곳

느슨한 파일들의 ZIP 아카이브는 실제 커버가 있는 ZIP과 같은 방식으로 판매되지 않습니다. pack_product.py는 하나의 명령으로 세 가지 작업을 수행합니다: 파일을 압축하고, 1280x720 크기의 커버를 렌더링하며, 600x600의 썸네일을 만듭니다. 서드파티 의존성인 Pillow 하나만 요구사항 파일에 포함하면 됩니다.

이 스크립트 하나만으로 저에게 39개의 제품을 패키징했고, 최종 출력물은 856 MB에 달했으며, GPU가 없는 1 vCPU와 2 GB RAM 사양의 서버에서 실행되었습니다. 작은 서버 제약 조건이 어떤 기능 요청보다도 코드를 더 많이 형성했습니다. 한 번에 하나의 프로세스만 처리하고, 에셋 간에는 gc.collect()를 사용하며, 검사만 할 때는 300dpi 대신 60dpi로 미리보기를 렌더링합니다. 만약 몇 센트 단위로 AI 이미지를 생성하여 배치 생산한다면, 메모리 관리가 $5짜리 VPS(가상 사설 서버)를 유지 가능하게 만드는 요소입니다.

폴더 레이아웃은 도구의 일부

모든 스크립트는 하나의 구조를 가정합니다: 원본 결과물용 assets/, 제출 준비 파일 및 CSV용 output/, 완성된 zip 파일 및 커버용 packs/, 메모용 research/, 그리고 도구용 scripts/. 제가 한 번 저지르고 다시는 반복하지 않을 실수는 정리하는 과정에서 research/ 폴더를 삭제했던 것입니다. 제 스크랩 로그와 메모는 나중에 나온 세 가지 제품의 원자재였습니다. 영원히 보관하세요, 비용이 들지 않습니다.

지난 3월의 저에게 해주고 싶은 말

슬림한 요구사항(requirements)은 우아함에 관한 것이 아니라 전환율(conversion)에 관한 것입니다. 제거하는 모든 의존성(dependency)은 작동하는 첫 번째 명령을 얻는 구매자 한 명입니다. 네 개의 스크립트, 두 개의 패키지, 가능한 경우 표준 라이브러리, 그리고 원격 실행으로 인해 계정 점수가 손상되지 않도록 하는 장부(ledger)가 필요합니다.

이 재작성은 더 큰 시스템의 포장 레이어가 되었습니다. 상위 프로젝트는 300페이지 이상의 연구를 기반으로 한 약 19,000줄의 파이프라인 코드이며, 지금까지 1,700개의 에셋을 생산했고, 그중 58개가 Adobe Stock에 라이브되었으며, 제가 전체 과정이 작동함을 증명하기 위해 스크린샷을 찍은 첫 판매액 $0.99가 있었습니다. 본문의 스크립트들은 다른 판매자들이 계속 요청했던 해당 시스템의 네 가지 도구이며, 디지털 에셋 팩토리(Digital Asset Factory)로 번들링되었습니다. 이것은 부자가 될 것이라는 약속이 아니라, 그저 작동하는 도구와 그들이 강제하는 규칙을 담은 정직한 버전입니다.

디지털 에셋 팩토리 받기

디지털 제품 제작 중이신가요? [디지털 제품 판매자를 위한 무료 가이드 및 키트]