Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
자동화 파이프라인만으로는 포착할 수 없는 '판단' 영역의 품질 관리 중요성을 강조합니다. 규칙 기반 자동 점검은 기계적 오류를 잡지만, 제목이나 키워드의 적절성 등 미묘한 부분은 사람이 배치 단위로 검토하는 것이 효과적입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기지난 3월에 저는 Adobe Stock용 벡터 40개를 준비했습니다. 메타데이터 CSV는 제 파이프라인으로 생성했고, 업로드는 제가 잠든 새벽 2시에 나갔습니다. 그리고 저는 자신이 천재가 된 기분으로 일어났죠. 정오쯤 되니 40개 중 11개가 거절되었습니다. CSV 헤더 때문이 아니었습니다. 헤더는 맞았거든요. 파이프라인이 볼 수 없는 것들 때문에요: 기술적으로 정확했지만 파일 이름처럼 보이는 제목, 기술적으로 유효했지만 이미지의 아무것도 설명하지 못하는 키워드, 그리고 내보내기 과정에서 레이어 그룹이 평탄화되면서 눈에 띄는 이음매가 남은 하나의 파일. 제 자동화 시스템은 자신의 임무를 완벽하게 수행했습니다. 다만 그 임무 자체가 너무 작았던 거죠.
그 거절 메일은 제가 파이프라인에는 두 개의 품질 계층이 있으며, 저는 단지 하나만 구축했다는 것을 깨달은 순간이었습니다.
첫 번째 계층은 스크립트가 잘하는 것입니다. 제 make_metadata.py는 각 플랫폼이 요구하는 정확한 열 개수(column count)를 작성합니다: Adobe는 5개, Vecteezy는 4개, Dreamstime은 15개를 원하죠. 헤더만 잘못해도 사람이 보기 전에 업로드가 즉시 실패합니다. 이것은 규칙의 문제이며 스크립트가 완전히 해결할 수 있습니다. 더블 포스팅(double-posting)도 마찬가지입니다: upload_tracker.py는 이미 제출된 목록을 기록하여, 배치 작업을 두 번 실행하는 것이 계정이 플래그 지정되는 가장 빠른 방법 중 하나이기 때문입니다. 코드에 의해 강제되는 규칙이며 예외는 없습니다.
하지만 11개의 거절은 규칙 위반이 아니었습니다. Adobe의 검토자는
저는 시도해 봤습니다. 제 상위 파이프라인은 약 19,000줄의 Python으로 구성되어 있으며, 초기의 의미 있는 코드 일부가 에셋을 자동 판단하려고 했습니다. 솔직한 결과는 이렇습니다. LLM은 명백한 실패(빈 출력, 잘린 렌더링, 중복된 키워드 목록)를 플래그할 수는 있지만, 스티커 디자인이 스티커 크기에서 보기 좋은지, 또는 템플릿의 간격이 어색하게 느껴지는지를 신뢰성 있게 알려주진 못합니다. 이러한 점검도 대규모로 할 때는 실제 비용이 발생합니다. 이미지에 대한 모든 AI 지원 검토 과정은 API 크레딧을 소모하며, 수백 개의 에셋을 생성하는 파이프라인에서 '모델에게 모든 것을 보게 하라'는 것은 빠르게 누적됩니다.
대신 효과적인 것은 하이브리드 방식이며, 그 분할은 대략 이렇습니다:
체크리스트는 짧고 구체적입니다. 제목이 평범한 단어로 주제를 설명하는지, 키워드가 이미지에서 실제로 보이는 것인지, 100% 확대 시 눈에 띄는 아티팩트가 있는지, 파일이 깨끗하게 열리는지 여부입니다. 그게 전부입니다. 네 가지 질문으로, 이들은 모든 11건의 반려 사유를 포착했을 것입니다.
사람의 점검이 효과적인 이유는 그것이 업로드 후에 하나씩 하는 것이 아니라, 전체 배치를 대상으로 업로드 전에 이루어지기 때문입니다. 반려 과정은 며칠이 걸립니다. Adobe 검토 처리 시간은 즉각적이지 않으며, 반려된 모든 에셋은 그 주기 동안 수익을 창출하지 못한 배치 속의 슬롯입니다. 10분간의 검토로 11개의 나쁜 에셋을 포착하는 것은 업로드 자동화 어떤 것보다 가치가 있습니다. 왜냐하면 병목 현상은 업로드가 아니었기 때문입니다. 판단력이었습니다.
실질적으로 제 폴더 레이아웃이 이를 강제합니다. 원본 출력물은 assets/로 가고, 검토 및 수정된 파일은 output/로 가며, 메타데이터 CSV는 절대로 assets/가 아닌 output/에서 생성됩니다. 파이프라인은 검토 단계를 거치지 않은 에셋을 패키징할 수 없습니다. 왜냐하면 파일을 폴더를 이동시키는 곳 자체가 바로 그 검토 단계이기 때문입니다. 이는 코드 대신 디렉터리 구조로 만들어진 게이트이며, 제가 작성했던 어떤 유효성 검사 스크립트보다도 더 잘 버텨주었습니다.
두 번째 계층이 승인하면, 자동화가 완전히 인계받아 훌륭하게 수행합니다. 검토된 제품을 패키징하는 것은 이미 해결된 문제입니다. 파일들을 zip하고, Pillow를 사용해 1280x720 커버와 600x600 썸네일을 렌더링하며, reportlab으로 스타일이 적용된 PDF를 작성합니다. 제 pack_product.py가 이 모든 것을 하나의 명령어로 처리하며, md2pdf.py는 문서를 판매 가능한 PDF로 변환합니다. 이 모든 것이 단일 1 vCPU, 2 GB RAM 서버에서 한 번에 하나의 프로세스로 실행되었고, 항목 사이에 gc.collect()를 사용했으며, 추측 대신 ru_maxrss로 최대 RSS를 측정했습니다. 전체 실행을 통해 몇 달에 몇 달러 비용의 하드웨어에서 약 856 MB의 출력물과 39개의 완성된 제품이 생성되었습니다.
11번의 거절로부터 얻은 교훈은 '자동화를 덜 하는 것'이 아닙니다. 그것은 '올바른 계층을 자동화하는 것'입니다. 규칙 및 패키징: 완전한 자동화, 후회 제로. 시각적 및 의미론적 판단: 폴더 구조에 의해 통제되는 저렴하고 배치 처리된 인간의 체크리스트. 판단을 코드에 넣으려고 했던 것이 제가 일주일과 11개의 에셋을 잃었던 곳이며, 수정 비용은 배치당 10분이었습니다.
위의 모든 과정은 Pipeline Starter Kit에 담겨 있습니다: 네 개의 스크립트(make_metadata.py는 정확한 Adobe 5열, Vecteezy 4열 및 Dreamstime 15열 헤더를 포함하고, upload_tracker.py, md2pdf.py, pack_product.py), 검토 게이트 역할을 하는 폴더 구조, 그리고 모든 것을 1 vCPU / 2 GB 사양의 박스에서 실행하는 방법에 대한 메모입니다. 총 두 가지 의존성만 필요하며, 메타데이터 및 추적 스크립트는 Python만 있으면 됩니다. 이것은 그 39개 제품들 뒤에 있는 패키징 계층이며, 두 번째 품질 계층은 제자리에 남아 있습니다: 바로 당신의 손안에서, 배치당 10분입니다.
디지털 제품을 제작하시나요? 디지털 제품 판매자를 위한 무료 가이드 및 킷.