제품은 유통 그 자체: 완벽한 스토어가 아무것도 팔지 못하는 이유

지난 3월 주말 동안 제 스토어 페이지를 완벽하게 만들었습니다. 새로운 배너, 재작성된 설명, 일관된 가격 책정까지 했습니다. 그러고 나서 숫자를 확인했는데, 일주일 만에 조회수 14회, 판매는 '0'이었습니다. 한편, 보기 싫고 자동화된 목록으로 스톡 마켓플레이스에 올려둔 같은 자산들은 그 주에 이미 매출을 올리고 있었습니다. 바로 그때 저에게 깨달음이 왔습니다. 저는 실제 제품은 고객에게 가는 경로를 두고 선반만 윤이 나게 다듬고 있었던 겁니다.

실제 수치와 그 배경 규칙과 함께 제가 배운 점들을 공유합니다.

마켓플레이스는 이미 트래픽을 가지고 있으며, CSV 헤더로 이를 강제한다

Adobe Stock, Vecteezy, Dreamstime 모두 메타데이터 CSV를 통해 대량 업로드(bulk uploads)를 허용합니다. 문제는 각각 다른 열 개수를 요구하며, 검토 후가 아니라 업로드 단계에서 잘못된 헤더를 감지하여 거부한다는 점입니다. Adobe는 5개 열을 원하고, Vecteezy는 4개, Dreamstime은 15개를 원합니다. 대략적인 수치가 아닙니다. 만약 헤더 행이 한 열이라도 틀리면, 사람이 작업물을 보기 전에 배치(batch) 자체가 실패해 버립니다.

이것이 바로 아름다운 스토어 페이지가 아무것도 해줄 수 없는 이유입니다. 스토어 페이지는 여러분이 가지고 있지 않은 관심을 두고 경쟁합니다. 올바르게 형식화된 CSV는 여러분의 작업물을 이미 월간 방문자 수가 수백만 명인 플랫폼에서 검색하고 있는 사람들의 눈앞에 놓아줍니다. 제 스토어는 일주일에 조회수 14회를 기록했습니다. 하지만 제가 손대지 않았는데도, 마켓플레이스 목록들은 플랫폼의 검색 기능이 유통을 담당했기 때문에 발견되었습니다.

지루하고 화려하지 않은 움직임은 하나의 스크립트를 작성하여 각 플랫폼이 요구하는 정확한 헤더를 같은 폴더의 파일들로부터 출력하게 하는 것입니다. 동일한 자산, 세 가지 결과물, 세 개의 채널. 이것이야말로 제품으로서의 유통(distribution as a product decision)입니다.

더블 포스팅은 배치뿐만 아니라 계정을 잃게 만드는 방법이다

초기에 저는 첫 번째 실행이 끝났는지 확신하지 못해서 배치 스크립트를 두 번 재실행한 적이 있습니다. 그 두 번째 실행은 이미 검토 중인 파일 세트를 다시 업로드했습니다. 이것이야말로 스톡 플랫폼에서 플래그(flagged)를 받을 수 있는 가장 빠른 방법입니다. 제출물 전반에 걸쳐 중복된 콘텐츠는 스팸이나 권리 문제처럼 보이기 때문입니다.

해결책은 '조심하라'가 아닙니다. 해결책은 원장(ledger)입니다. 제 것은 pending, done, status 세 가지 명령어를 가진 단순한 텍스트 추적기입니다. 업로드하기 전에 파이프라인은 이 원장에게 아직 게시되지 않은 것이 무엇인지 물어봅니다. 재실행을 해도 두 번 중복으로 게시하지 않는데, 그 이유는 추적기가 기억하고 있기 때문입니다. 파이썬 표준 라이브러리만 사용하므로 설치할 것도, 고장 낼 것도 없습니다.

이 교훈은 일반화됩니다: 배포(distribution)는 상태 문제(state problem)입니다. 무엇이 어디로 갔는지 확실하게 알아야 합니다. 완벽한 스토어 페이지는 아무것도 모릅니다.

패키징은 파일과 제품의 차이를 만듭니다

벡터를 담은 단순한 zip 파일을 Gumroad나 자체 결제 시스템에서 판매하면 잘 팔리지 않습니다. 하지만 실제 커버 이미지와 함께 제공되는 동일한 파일들은 눈에 띄게 더 잘 팔리며, 여기서 말하는 커버는 zip 안의 첫 번째 파일을 의미하지 않습니다. 제 패키저는 모든 제품에 대해 1280x720 크기의 커버와 600x600 크기의 썸네일을 렌더링합니다. 이 두 가지 크기는 제품이 표시되는 곳들을 커버하며, 렌더링은 Pillow 호출 한 번으로 끝나고 디자인 도구나 수동 내보내기가 필요 없습니다.

같은 논리가 문서에도 적용됩니다. 저는 연구 폴더에 유용한 Markdown 노트들을 가지고 있었지만 아무 역할도 하지 못하고 있었습니다. 이 중 하나를 제목, 표, 링크가 포함된 스타일리시한 PDF로 변환하는 과정은 '노트'를 '제품'으로 바꿨습니다. 내부적으로 reportlab을 사용하는 단 하나의 명령어가 그렇게 만들었습니다. 그 단일 변환이 연구 폴더를 판매 가능한 결과물로 만든 것입니다.

프로젝트 전체에 걸쳐 이 패키징 계층(packaging layer)은 하나의 프롬프트 엔진을 39개의 완성된 제품, 총 856 MB의 결과물로 만들었습니다. 그 어떤 제품도 제 초기 시도들보다 더 나은 예술 작품은 아니었습니다. 단지 배포가 더 잘 된 것뿐입니다.

거대한 서버가 필요하지 않습니다. 기억(memory)에 대한 규율이 필요합니다

저는 1 vCPU, 2 GB RAM, GPU 없이 전체 파이프라인을 실행합니다. 이것은 하드웨어 때문이 아니라 습관 덕분에 작동하는 것입니다:

• 한 번에 하나의 이미지 작업만 처리하세요. 단일 코어에서 렌더링을 병렬로 수행하지 마세요.
• 각 에셋(asset) 사용 후 gc.collect()를 호출하세요.
• 평균 사용량 대신 resource.getrusage(RUSAGE_SELF).ru_maxrss를 사용하여 최대 RSS(Resident Set Size)를 측정하세요. 평균은 거짓말을 하고, 최고치가 당신의 실제 한계치입니다.
• 무거운 렌더링 작업은 서브프로세스당 하나의 파일로 실행하여 메모리가 OS로 반환되게 하세요.
• 300dpi에서 렌더링하는 대신 60dpi에서 미리보기를 검사하세요. 최종 파일에 필요한 것은 전체 해상도뿐입니다.

이 모든 것은 네 개의 Python 스크립트와 두 개의 서드파티 패키지, Pillow 및 reportlab으로 구성되어 있습니다. 메타데이터 및 트래커 스크립트는 Python만 있으면 됩니다. 만약 당신의 파이프라인이 2GB 사양의 컴퓨터에서 실행되지 않는다면, 문제는 보통 컴퓨터가 아니라 파이프라인 자체에 있는 것입니다.

연구 폴더는 영원히 보존하세요

제가 저지른 구조적인 실수 중 하나는 '정리'하기 위해 연구 폴더를 삭제한 것이었습니다. 그 노트와 스크랩 로그들이 나중에 나온 세 가지 제품의 원자재였습니다. 이제 레이아웃은 고정되었습니다: 에셋(assets), 출력물(output), 팩(packs), 연구(research), 스크립트(scripts). 연구 자료는 절대 삭제되지 않습니다. 유통(Distribution)은 당신이 가진 것을 증폭시키지만, 오직 당신이 가진 것이 여전히 존재할 때만 그렇습니다.

이 프로젝트가 시작된 계기

위에 언급된 모든 것은 파이프라인 스타터 키트(Pipeline Starter Kit)에 내장되어 있습니다. 이 키트는 그 39개 제품을 패키징했던 것과 동일한 네 개의 스크립트를 사용하며, 정확히 Adobe 5열, Vecteezy 4열, Dreamstime 15열 헤더, 업로드 장부(upload ledger), PDF 변환기, 그리고 패키저를 포함합니다. 이 키트는 무료 스택(오케스트레이션용 Hermes Agent, 로컬 LLM 접근용 9Router) 아래에 위치하며, 제가 설명했던 것과 동일한 1 vCPU / 2 GB RAM 장비에서 검증되었습니다. 이것은 강좌가 아니라, 완벽한 스토어가 아무것도 팔지 못했기 때문에 제가 직접 만든 도구입니다.

벡터 프롬프트 팩 받기

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