대부분의 스티커 판매자들이 놓치는 '래스터 클린업(Raster Cleanup)' 단계

지난 3월에 저는 흰색 테두리 때문에 배치 출력 작업 전체 주말을 날렸습니다. 제 작은 1 vCPU, 2 GB 서버에서 하룻밤 사이에 60개의 스티커 디자인을 렌더링했습니다. 테스트 배치를 저의 주문형 인쇄(print-on-demand) 상점에 업로드하고 샘플을 한 개 주문했는데, 스티커들이 모든 모양 주변에 얇은 흰색 후광과 함께 돌아왔습니다. 흰색 배경 위에 안티앨리어싱된 가장자리였습니다. 이 60개의 파일 각각이 다시 렌더링되어야 했습니다. 그 과정에서 하나의 파일을 렌더링하고 정리하는 데 약 90초가 걸렸기 때문에, 그 실수로 인해 컴퓨팅 시간으로만 대략 한 시간 반과 재확인 시간이 소요되었습니다. 그때 저는 '래스터 클린업'을 선택 사항으로 취급하는 것을 멈췄습니다.

이후 제가 배운 것들과 이제는 assets/ 폴더에서 어떤 파일이 나가기 전에 하는 작업들은 다음과 같습니다.

이 테두리 문제는 미학이 아니라 수학이다

흰색 배경 위에서 디자인을 렌더링한 다음 잘라낼 때, 가장자리를 따라 있는 픽셀들은 모양과 배경의 혼합물입니다. 100% 확대에서는 볼 수 없습니다. 하지만 인쇄 크기나 어두운 티셔츠 위에서는 후광이 생깁니다. 해결책은 처음부터 실제 알파 채널(alpha channel)을 사용하여 렌더링하는 것입니다. 만약 합성(composite)해야 한다면, 알파-매트(alpha-matte) 패스를 수행합니다. 즉, 모든 가장자리 픽셀에 대해 그 알파 값은 모양이 실제로 얼마나 많이 덮고 있는지를 반영해야 하며, 단순히 켜짐/꺼짐의 이진값(binary)이어서는 안 됩니다. Pillow는 임계값(threshold)과 마스크에 작은 알파 블러를 추가하여 이를 수행할 수 있지만, 중요한 부분은 고객이 불평하기 전에 내보내기(export) 전에 처리하는 것입니다.

또한 저는 풀 해상도에서 검사하는 것을 멈췄습니다. 키트 설명서에 잘 나와 있듯이, 60 dpi에서 미리 보기(preview)를 검사하는 것이 300 dpi에서 렌더링하는 것보다 낫습니다. 먼저 저해상도 목업(proof)을 렌더링하여 가장자리를 확인한 다음 최종 패스를 진행합니다. 이는 파일당 최대 40MB와 최대 400MB 사이의 차이를 만드는 2 GB 서버에서는 큰 차이입니다.

흰색은 투명함을 의미하지 않는다

제가 다른 판매자들의 파일에서 보는 가장 흔한 클린업 실수는 누군가가 '흰색'을 삭제하는 경우입니다. 모양 안에 흰색 텍스트나 흰색 하이라이트를 채우고, 배경의 흰색을 삭제하면 이제 당신의 하이라이트가 구멍(hole)처럼 됩니다. 안전한 작업 순서는 다음과 같습니다:

1. 아트에 사용하지 않는 단색 마젠타 또는 녹색 배경 위에서 렌더링합니다.
2. 순수한 흰색이 아닌 해당 배경 색상을 기준으로 허용 오차(tolerance)를 사용하여 알파 마스크를 만듭니다.
3. 단순히 허용 오차만으로는 흰색 테두리 대신 색상이 있는 가장자리 줄무늬가 남기 때문에, 이 배경 색상을 엣지 픽셀에서 제거하는 디컨태미네이션 패스(decontamination pass)를 실행합니다.

이 마지막 단계가 바로 사람들이 건너뛰는 부분입니다. 어두운 후드티에 생긴 녹색 테두리 줄무늬는 흰색 줄무늬보다 더 보기 싫습니다.

트리밍, 블리딩 및 다이컷 라인

스티커 플랫폼은 잘린 선(cut line)이 일정한 여백을 두고 아트워크를 따라가기를 원합니다. 저는 모든 파일에 3mm의 블리드(bleed)와 아트워크와 커트 경로 사이에 2mm의 여백을 유지합니다. 만약 정리 단계에서 보이는 픽셀까지 트리밍한다면, 이미 여백을 깨뜨린 것입니다. 왜냐하면 안티앨리어싱된(anti-aliased) 가장자리 픽셀은 거의 보이지 않지만 여전히 계산에 포함되기 때문입니다. 그래서 제 트리밍 패스는 사람이 '보이는' 것을 기준으로 하는 것이 아니라 알파 마스크를 대상으로 하며, 알파 임계값(alpha threshold)을 8%로 설정합니다. 그런 다음 여백까지 다시 채웁니다. 이를 스크립트로 처리했기 때문에 제가 포장한 39개 제품 모두가 동일한 여백으로 나왔고, 이는 고객이 세 팩을 구매하여 일치하기를 기대할 때 중요합니다.

배치 작업 시 메모리 관리

정리는 파이프라인에서 가장 무거운 단계이므로, 여기서 2GB 제한에 부딪힙니다. 전체 실행 과정을 1 vCPU에서 유지하게 해주는 습관들은 다음과 같습니다:

• 한 번에 하나의 프로세스만 처리합니다. 단일 코어에서 이미지 작업을 병렬로 분산시키지 마세요. 그렇게 하면 단순히 벽 시간(wall time)을 스왑 메모리 고갈(swap death)로 교환할 뿐입니다.
• 각 에셋마다 gc.collect()를 호출합니다. 이것 없이는 60개 파일 실행 과정에서 최대 RSS가 계속 상승하다가, 40번째 파일에서 커널이 강제 종료시킵니다.
• top으로 눈대중을 하는 것이 아니라 resource.getrusage(RUSAGE_SELF).ru_maxrss로 최대치를 측정합니다. 평균 사용량은 천장치에 대해 아무것도 알려주지 않습니다.
• 무거운 렌더링 단계는 OS가 실제로 메모리를 되찾을 수 있도록 파일별 서브프로세스로 실행합니다.

이 네 가지 규칙 덕분에 제 정리 패스는 파일당 약 300MB의 피크를 기록했고, 전체 60개 파일 배치는 스왑 이벤트 없이 밤새 실행되었습니다.

그리고 지루한 부분, 실제로 파일들이 죽는 곳

클린 엣지(Clean edges)만으로는 업로드 시트 자체가 잘못되면 아무 소용이 없습니다. Adobe의 업로드 CSV는 5개 열 헤더를 요구하고, Vecteezy는 4개 열을, Dreamstime은 15개 열을 요구합니다. 이 세 곳 모두 잘못된 헤더가 들어오면 즉시 거부하며 부분 점수는 주지 않습니다. 클린업 패스(cleanup pass)를 한 후 저는 make_metadata.py를 출력 폴더에 실행하여 각 채널이 정확히 어떤 헤더를 요구하는지 파악하고, upload_tracker.py는 장부를 기록하여 배치(batch) 재실행 시 이중 게시(double-posts)가 발생하지 않도록 합니다. 이중 게시되는 것은 계정이 플래그 지정될 수 있는 가장 빠른 방법이며, 이는 클린업 실패 때문에 배치를 재실행하게 되면서 정확히 발생합니다. 이 두 단계는 연결되어 있습니다. 첫 번째 패스가 깨끗할수록 재실행 횟수가 적고, 트래커(tracker)를 건드릴 기회가 줄어듭니다.

이것이 된 도구들

위에 언급된 모든 것은 이제 스크립트로 작성되었으며 파이프라인 스타터 키트(Pipeline Starter Kit)에 있습니다. 이 키트는 약 19,000줄의 파이프라인 코드를 통해 39개 제품, 856 MB의 출력을 패키징한 바로 그 네 가지 스크립트로 구성되어 있으며, 모두 1 vCPU, 2 GB 메모리, GPU가 없는 환경에서 검증되었습니다. 이것은