python -m venv부터 첫 제품까지: 프레임워크가 없는 툴체인에서 온보딩 순간 감사하기
제가 이야기하고 싶은 순간은 화려하지 않습니다. 새 터미널 창이 열리고, venv가 "활성화"되었으며, 커서가 다음에 무엇이 올지 모르는 프롬프트 아래 깜빡이는 바로 그 순간입니다. 그것은 _"튜토리얼을 읽었다"_와 "팔 수 있는 제품이 있다" 사이의 간극입니다. 저는 이 간극을 너무 크게 느껴서 제가 바랐던 바로 그 도구들을 직접 만들게 되었고, 프레임워크를 모두 제거하고 순수하게 Python만 사용하여 이러한 온보딩 순간이 어떤 모습인지 설명하고자 합니다.
venv는 쉬운 부분이고, 규칙이 어려운 부분이다.
가상 환경(virtual environment)을 활성화하는 것은 두 줄이면 충분합니다. 하지만 Adobe, Vecteezy, Dreamstime 각각이 다른 CSV 헤더를 요구한다는 것, 그리고 사소한 편차라도 배치 작업 전체가 즉시 거부된다는 것을 배우는 것이 진정한 온보딩 비용입니다. 이것이 바로 make_metadata.py가 존재하는 이유입니다. 이 스크립트는 파일 폴더에서 정확히 5열의 Adobe 헤더, 4열의 Vecteezy 헤더, 그리고 15열의 Dreamstime 헤더를 구축하며, 그 외에는 아무것도 처리하지 않습니다. 단 하나의 명령어로 모든 것이 가능합니다:
python make_metadata.py ./my-assets --platform adobe --out metadata.csv --ext .jpg
Django도 없고, FastAPI도 없고, 클라우드 계정도 필요 없습니다. 전체 과정이 표준 라이브러리(standard library)로만 실행됩니다. 이 첫 한 시간을 감사(auditing)하며 얻은 교훈은 다음과 같습니다: 마찰(friction)은 결코 설치가 아닙니다. 그것은 플랫폼의 문서화되지 않은 형식 규칙이며, 모든 1인 제작자는 당신을 위해 헤더를 작성해주는 무언가를 발견할 때까지 똑같이 고통스러운 방식으로 이를 재발견하게 됩니다.
두 번째 시간의 함정은 중복 게시물이다
하루 만에 겪는 실패는 기술적인 문제가 아니라 운영상의 문제입니다. 배치 작업을 실행했는데 절반만 성공하고, 다시 실행했더니 같은 에셋을 두 번 게시한 상태가 됩니다. 스톡 플랫폼에서 이것은 계정이 플래그 지정될 수 있는 가장 빠른 길입니다. 해결책은 거의 놀라울 정도로 작습니다: 원장(ledger)입니다. upload_tracker.py는 이미 제출된 내용을 기억합니다.
python upload_tracker.py pending items.txt
python upload_tracker.py done "asset-001.jpg"
다시 말하지만: 표준 라이브러리만 사용합니다. 데이터베이스도, 설치 과정도 없습니다. 온보딩 감사(onboarding audit) 결과, 사람들을 막는 것은 파이프라인을 구축하는 것이 아니라, 재실행 시 사보타주를 하지 않을 것이라고 '신뢰'하는 것입니다. 텍스트 편집기에서 읽을 수 있는 원장(ledger)은 지루하지만 작동합니다.
두 개의 패키지, 오직 두 개만
체인에 있는 나머지 두 스크립트는 서로 정확히 두 개의 외부 의존성만을 필요로 합니다. 커버를 위한 Pillow와 PDF용 reportlab입니다. 끝입니다. pip install -r requirements.txt가 이 두 가지를 설치하며, 도구 체인의 나머지 절반은 의존성이 전혀 없는 상태로 계속 작동합니다.
메타데이터와 추적만 필요하다면, 설치 과정을 완전히 건너뛸 수 있습니다. 이것은 우연이 아니라 의도적인 온보딩 선택입니다. python -m venv .venv부터 첫 판매 가능한 아티팩트까지 패키지가 적을수록, 실제로 그 첫 번째 아티팩트를 완성할 가능성이 높아집니다. 나머지 파이프라인(Markdown-to-PDF 변환기, zip 파일과 1280x720 커버 및 600x600 썸네일을 생성하는 패키징 스크립트) 역시 의도적으로 같은 경량화된 정신을 유지합니다.
2 GB 박스에서 실행되면서 규칙이 바뀐 경우
이 전체 파이프라인은 1 vCPU, 2 GB RAM, GPU 없음 환경에서 39개의 완성된 제품과 856 MB의 출력을 만들어냈습니다. 이러한 제약 조건은 '작동한다'는 의미를 정의합니다. 한 번에 하나의 프로세스만 실행하고, 단일 코어에서 이미지 작업을 분산(fan out)시키지 마십시오. 에셋 간에는 gc.collect()를 호출하십시오. 평균값 대신 resource.getrusage(RUSAGE_SELF).ru_maxrss로 최대 RSS(Resident Set Size)를 측정해야 합니다. 왜냐하면 천장(ceiling, 즉 최고점)이 당신을 죽이기 때문입니다. 무거운 렌더링 단계의 경우, 메모리가 OS로 반환되도록 서브프로세스당 하나의 파일만 실행하십시오. 해상도가 정말 필요한 경우가 아니라면 미리보기는 300 dpi 대신 60 dpi에서 렌더링하십시오.
그것들 중 어느 것도 영리한 것은 아닙니다. 그것들은 단순히 하드웨어로 문제를 해결할 수 없을 때 습득하게 되는 습관일 뿐입니다. 이 전체 파이프라인(부모 프로젝트에서 대략 19,000줄의 코드에 달하며, 스크립트가 강제하는 규칙을 뒷받침하는 300페이지 이상의 연구 자료를 포함함)은 동일한 단일 코어 박스에서 검증되었습니다. 강력한 개발 장비를 전제로 하는 온보딩 조언은 그곳에 있는 수많은 독립 제작자들 중 절반을 조용히 배제하는 온보딩 조언입니다.
폴더 레이아웃이 도구보다 중요한 이유
감사 과정에서 밝혀진 마지막 점은 다음과 같습니다. 카탈로그는 순식간에 잡동사니 서랍(junk drawer)으로 변합니다. 이 키트가 가정하는 레이아웃(assets/, output/, packs/, research/, scripts/)은 미적인 문제가 아닙니다. 이것은 제품 40까지 확장할 수 있는 파이프라인과 제품 6에서 정체되는 파이프라인의 차이를 만듭니다. 그리고 특정한 습관 하나: 절대 research/ 폴더를 삭제하지 마십시오. 여러분의 스크랩 로그와 메모는 다음 제품을 위한 원자재입니다. 그것들을 '정리'하기 위해 지워버리는 것은, 딱 한 번 할 가치가 있는 실수이며, 이 프로젝트가 바로 그 실수를 저질렀습니다.
솔직한 결론
이 모든 것이 프레임워크는 아닙니다. 이것은 네 개의 독립형 Python 스크립트로 구성되어 있으며, 꾸미지 않은 부분들을 처리합니다: 세 가지 플랫폼에 대한 정확한 메타데이터 CSV 파일, 이중 게시를 방지하는 원장(ledger), Markdown-to-PDF 변환, 그리고 실제 표지와 썸네일을 포함한 패키징입니다. 이것이 바로 python -m venv부터 첫 제품까지의 전체 온보딩 스토리입니다: 움직이는 부분이 적고, 의존성이 적으며, 플랫폼 규칙들이 숙제처럼 남겨지는 것이 아니라 도구 자체에 내장되어 있습니다.
만약 여러분이 마주하고 있는 문제의 형태가 이와 같다면, 스크립트들은 디지털 자산 팩토리(digital asset factory) 키트로 함께 패키징되었습니다. 동일한 도구, 동일한 제약 조건이며 클라우드 계정이 필요하지 않습니다.
디지털 자산 팩토리 받기
디지털 제품을 제작하시나요? 디지털 제품 판매자를 위한 무료 가이드 및 키트.