선재고 없이, 광고비 없이 스마트스토어를 열었습니다. 목표는 매출이 아니라 "팔릴 가능성을 싸게 검증하는 구조" 였습니다. 도매 공급처(오너클랜) 상품을 크롤해서 후보를 뽑고, 규칙으로 상품 데이터를 만들고, API로 등록하고, 판매개시 상태까지 확인하는 파이프라인입니다. 하루 만에 124개가 SALE / ON이 됐습니다.
그런데 이 작업에서 코드로 가장 시간을 많이 먹은 곳은 등록 API가 아니었습니다.
질문 하나. 당신의 자동화가 잘못된 입력을 100배 빠르게 처리하면 어떻게 됩니까? 상품 등록 자동화에서 그 답은 "속도가 빨라진다"가 아니라 "사고가 커진다"입니다.
파이프라인 구조
두 단계로 나눴습니다.
- 후보 수집기 — 공급처 상세 페이지 파싱, 관련 상품 링크를 따라가며 확장. 상품명·공급가·배송비·반품비·옵션·이미지·리뷰 수 추출, 리스크 단어 탐지, 카테고리 추론, 점수 계산 후 JSON 저장.
- 대량 등록기 — 후보 JSON 로드, 기등록 제외, 리스크 필터, 카테고리 재분류, 상품명 생성, 묶음 수량·판매가 계산, 옵션·고시정보 생성, 대표 이미지 업로드, 상품 생성 API 호출, 결과 저장,
SALE / ON검증.
1,200개 페이지를 파싱해 보수적 조건으로 후보 62개, 상세 이미지가 없어도 텍스트 상세로 보완 가능한 것까지 포함해 100개 이상을 확보했습니다.
먼저 8개만 손에 가깝게 등록해 흐름을 검증하고, 그다음 대량으로 확장했습니다. 처음부터 100개를 던졌으면 실패 원인이 상품성인지 형식인지 구분이 안 됐을 겁니다.
필터가 본체였다
자동화해도 되는 것과 하면 안 되는 것을 먼저 갈랐습니다.
자동화해도 되는 것: 후보 수집, 가격 계산, 이미지 업로드, 상품명·옵션·재고 입력, 등록 후 상태 검증.
자동화하면 안 되는 것: 원산지·제조사·인증(KC) 여부·A/S 정보를 추측해서 채우는 것. 공급처 데이터에 없는 값은 지어내지 않고, 애매하면 상품을 버렸습니다. 지어낸 고시정보는 나중에 고객 문의나 정책 이슈로 정확히 되돌아옵니다.
즉시 제외 카테고리도 코드로 박았습니다 — 전기/배터리, 식품/건강, 화장품류, 어린이용, 캐릭터·IP, 브랜드 정품 표현, 화학성 방충/제습, 고반품 의류. 이건 잘 팔릴 상품을 고르는 필터가 아니라, 사고 확률을 낮추는 필터입니다.
함정 1 — 리스크 필터가 글로벌 메뉴를 읽었다
처음엔 페이지 전체 텍스트에서 리스크 단어를 찾았습니다. 그랬더니 멀쩡한 생활용품이 계속 탈락했습니다.
원인은 공급처 페이지의 글로벌 내비게이션 메뉴였습니다. 상단 카테고리 목록에 식품, 의료, 화장품이 늘 들어 있으니, 모든 페이지가 모든 금지어를 갖고 있었던 겁니다. 필터가 아니라 전멸기였죠.
고친 방법은 단순합니다. 탐색 범위를 상품 상세 영역(DOM 서브트리)으로 좁혔습니다. 크롤러에서 문자열 매칭을 할 땐, 매칭할 문자열보다 매칭할 범위를 먼저 정해야 합니다.
함정 2 — 카테고리 자동 추론의 조용한 오분류
상품명 키워드로 네이버 카테고리를 추론했습니다(세탁망 → 세탁망, 도어가드/문콕/몰딩 → 차량 몰딩 식으로). 대체로 맞았지만 조용히 틀리는 것들이 있었습니다. 비누받침이 소품걸이로, 명함꽂이가 일반 수납함으로.
카테고리가 틀리면 두 가지가 같이 틀어집니다. 검색 노출과, 카테고리에 따라 달라지는 필수 고시/인증 항목. 그래서 자동 추론 뒤에 등록 직전 재분류 규칙을 한 겹 더 뒀습니다.
함정 3 — 형식 실패는 상품성 실패가 아니다
대량 등록 중 API가 뱉은 에러:
모델명 항목은 50자보다 작게 입력해 주세요.
품명 항목은 50자보다 작게 입력해 주세요.모델명과 고시정보의 itemName을 50자로 자르고 실패분만 재시도해서 끝났습니다. 별것 아닌 수정이지만, 여기서 얻은 규칙이 더 중요합니다. 실패를 "상품성 실패"와 "형식 실패"로 나눠 기록할 것. 형식 실패를 상품 탈락으로 처리하면, 멀쩡한 상품을 코드 버그 때문에 영구히 버리게 됩니다.
함정 4 — 유령 상품
대량 등록을 중간에 멈춘 적이 있습니다. 그때 한 건이 생성 API POST는 성공했는데 결과 파일에 기록되기 전 상태로 남았습니다. 스크립트 입장에선 등록되지 않은 상품, 플랫폼 입장에선 이미 존재하는 상품.
당신이라면 어떻게 하시겠습니까? 그냥 다시 돌리면 중복 등록이 나고, 후보에서 빼면 멀쩡한 상품 하나를 잃습니다. 저는 채널상품번호 대역을 조회해 판매자 상품코드로 실제 생성 여부를 확인하고 결과 JSON을 수동 보강했습니다.
여기서 나온 운영 규칙:
성공 기록은 API 호출 직후에 남긴다. 그리고 다음 실행은 반드시 그 기록(+ 판매자 상품코드)으로 중복을 막는다.
배치 등록기에 멱등성이 없으면, 중단은 곧 데이터 오염입니다.
저장 성공은 등록 완료가 아니다
등록기의 마지막 단계는 API 응답 200이 아니라, 조회 API로 판매상태 SALE + 전시상태 ON 을 확인하는 것으로 잡았습니다. 판매자센터에 저장됐다고 고객이 살 수 있는 게 아니니까요. 완료와 게시는 다르다는 걸 다른 파이프라인에서도 똑같이 겪었습니다.
최종: 원칙 통과 후보 116개 → 등록 성공 116개 → API 전수 검증 116개 SALE / ON. 먼저 올린 8개까지 총 124개.
중간에 "50개만 채우자"에서 기준을 한 번 바꿨습니다. 목표 수량은 최소치일 뿐이고, 원칙을 통과한 후보를 개수 맞추려고 임의로 버리는 건 그 원칙을 부정하는 짓이라서요.
자가진단 3줄
크롤러로 외부 데이터를 받아 자동 등록·자동 생성하는 파이프라인을 돌린다면:
- 문자열 필터가 콘텐츠 영역만 보고 있습니까, 페이지 전체(메뉴·푸터 포함)를 보고 있습니까?
- 배치가 중간에 죽었을 때, 다음 실행이 이미 만든 것을 다시 만들지 않는다고 증명할 수 있습니까?
- 소스에 없는 값을 모델이나 규칙이 채워 넣고 있지는 않습니까? (원산지·인증 같은 건 추측이 곧 리스크입니다)
솔직한 부분
이 글은 성공담이 아닙니다. 124개가 살아 있다는 건 팔린다는 뜻이 아니라 팔 수 있는 상태라는 뜻뿐입니다. 매출은 0원이고, 노출·클릭·찜 데이터는 이제 모이기 시작합니다. 지표가 붙기 전에 광고비를 태우면 나쁜 데이터를 비싸게 사게 되고, 그건 노출만 있고 수익은 0인 상태를 이미 다른 자산에서 겪어봤습니다.
지금 확실히 말할 수 있는 건 하나뿐입니다. 대량 등록 자동화의 가치는 등록 속도가 아니라 버리는 규칙의 정확도에 있습니다.
주문이 들어온 다음이 진짜 운영인데, 그건 브라우저 세션 자동화를 공식 커머스API로 갈아탄 이야기에서 이어집니다.
혹시 외부 소스를 긁어 무언가를 자동 생성하고 계신가요? 오늘 딱 하나만 확인해 보세요. 그 파이프라인이 중간에 죽어도 안전한지.