오너클랜 API로 위탁판매 자동화 직접 만들어본 기록

인스타 릴스에서 “이제는 알아야 하는 AI 사업”이라는 영상을 봤습니다. 상품 리서치 툴에서 잘 팔리는 상품 찾고, 쇼피파이에 스토어 만들고, 원가보다 높게 가격 걸고, 영상 그대로 릴스에 올리면 끝이라는 내용이었어요. 6단계로 요약되는 걸 보고 든 생각은 하나였습니다. 이게 6단계로 정리될 수 있으면 이미 수만 명이 똑같이 하고 있다는 뜻 아닌가. 그래서 그 모델 말고, 국내 위탁판매를 개발자가 할 수 있는 방식으로 다시 설계해서 위탁판매 자동화 파이프라인을 직접 만들어봤습니다.

결론부터 말하면 오너클랜 판매사 API는 상품 조회부터 주문 생성까지 전부 열려 있어서 무인에 가까운 구조가 실제로 만들어집니다. 다만 문서만 믿고 짜면 틀리는 지점이 여러 군데 있었고, 그중 하나는 돈이 나가는 쪽이었어요. 그 얘기를 순서대로 풀어보겠습니다.

상용 툴을 안 쓰고 판매사 API를 직접 붙인 이유

오너클랜에는 이미 자동화 도구가 있습니다. 오너클랜 AI셀러봇 안내 페이지를 보면, 네이버 커머스 API 계정 정보만 입력하면 상품 관리를 셀러봇이 대신 해준다고 돼 있어요. 마진은 상품 가격구간대별로 설정할 수 있고, 가격비교 페이지 상단 노출 효과가 있는 ‘오늘출발’ 기능도 자동으로 적용해서 등록됩니다. 다팔자라는 대량등록 프로그램은 더 오래됐고, 11번가에 이어 롯데ON까지 지원 마켓을 넓혀왔습니다.

솔직히 처음엔 그냥 셀러봇 쓸까 했습니다. 세팅 30분이면 끝나니까요. 그런데 같은 페이지 FAQ에 적힌 구분을 보고 생각이 바뀌었어요. 오너클랜은 주업으로 위탁판매를 하면 다팔자, 부업이면 AI셀러봇을 권하고 있습니다. 바꿔 말하면 이 판에 있는 셀러 대부분이 둘 중 하나를 쓰고 있다는 겁니다.

같은 도매 상품을, 같은 툴이, 같은 로직으로 상품명을 만들어서 올리면 어떻게 될까요. 노출 경쟁에서 서로 구분이 안 됩니다. 2026년 10월 4일 기준 오너클랜이 제공하는 상품은 1,092만 개인데, 이 재고를 수만 명이 공유합니다. 재고가 같으면 차별화는 가공 단계에서만 나올 수 있어요.

그래서 기준을 정했습니다. 상용 툴이 안 해주는 걸 하나라도 할 수 있으면 직접 짜고, 아니면 돈 내고 쓰자. 그 하나가 상품명 생성 로직을 내가 통제하고, 유입 데이터를 받아서 그 로직을 고치는 루프였습니다. 셀러봇은 등록까지만 해주고 그다음을 안 돌려주거든요.

오너클랜 API 센터에서 신청할 때 판매사 API와 파트너사 API 두 개가 뜹니다. 상품을 받아다 파는 쪽이니 판매사 API를 신청했어요. 파트너사 API는 매뉴얼을 읽어보니 다른 오너클랜 사용자를 대신해 API 권한 취득을 대행하는 용도라, 내 스토어를 돌리는 데는 쓸 일이 없었습니다. 나중에 이걸 솔루션으로 팔게 되면 그때 필요한 물건이더라고요.

받은 매뉴얼은 GraphQL 기반이었습니다. 아이디와 비밀번호를 인증 엔드포인트로 보내서 JWT를 받고, 조회는 GET에 쿼리를 실어 보내고 생성·수정은 POST로 보내는 구조예요. 프로덕션과 샌드박스 환경이 따로 있고, API 엔드포인트를 브라우저로 그냥 열면 GraphQL Playground가 떠서 스키마를 통째로 볼 수 있습니다.

제일 먼저 확인한 건 주문 생성이 되느냐였습니다. 상품만 조회되고 발주를 손으로 해야 한다면 위탁판매 자동화는 성립하지 않아요. 주문 하루 10건이면 한 시간, 50건이면 세 시간이 그냥 날아갑니다. 다행히 createOrder가 있었고, 거기에 더해 simulateCreateOrder로 실제 등록 전에 예상 상품 금액과 배송비를 미리 받아볼 수 있었습니다. 주문 취소와 반품·교환 신청도 쿼리로 열려 있고요.

문서에 적힌 날짜는 2020년 10월이었습니다. 6년 전 문서예요. 그래서 코드를 쓰기 전에 introspection으로 현재 스키마를 전부 덤프하고 문서와 대조하는 작업부터 했습니다. 이걸 건너뛰고 바로 짰으면 없어진 필드 붙잡고 반나절 날렸을 겁니다.

query { __schema { types { name fields { name } } } }

상품 하나를 다섯 개로 늘리는 게 전부였다

파이프라인은 수집, 점수화, 가공, 등록 네 단계로 짰습니다. 이 중 실제로 승부가 나는 건 가공 단계예요.

수집은 allItems를 커서 페이지네이션으로 돌리면 됩니다. 한 번에 최대 1,000개씩 가져올 수 있고, 수정일 기준으로 증분 수집이 가능해요. 매뉴얼에 before와 last는 정상 동작하지 않을 수 있다고 적혀 있어서 after와 first만 썼습니다. 이런 건 문서를 끝까지 읽어야 알 수 있는 함정이에요.

점수화는 결정론적 규칙으로 처리했습니다. 가격대, 배송 타입, 반품 가능 여부, 옵션 재고, 안전배송일을 가중치로 묶어 점수를 매기고 커트라인 아래는 버리는 방식이에요. 여기에 오너클랜이 자체적으로 운영하는 공급사 등급을 섞었습니다. 오너클랜은 공급사의 상품 품질과 운영 패턴을 종합해 1등급부터 17등급까지, 그리고 신규·주의·BAD로 등급을 매기고 매월 1일 갱신합니다. 상품 응답의 메타데이터로 이 등급이 그대로 넘어와요. ‘BAD’는 상품 공급 정책 위반이 누적된 공급사라고 안내돼 있으니, 점수 계산에서 아예 빼버리면 뒤에서 터질 사고를 미리 줄일 수 있습니다.

가공이 핵심입니다. 공급사가 올려둔 원본 상품명을 그대로 쓰면 수백 명이 똑같은 페이지를 만들게 돼요. 그래서 상품 응답에 들어 있는 searchKeywords 배열과 카테고리 전체 이름, 옵션 속성을 재료로 넣고, 주요키워드와 세부속성과 사용상황과 타겟을 조합해 서로 다른 상품명 다섯 개를 만들게 했습니다. LLM은 이 언어 판단 구간에만 배치로 붙였어요. 가격 계산이나 등록 요청까지 LLM에 맡기면 디버깅이 지옥이 되고 비용도 터집니다.

생성된 이름은 코드로 다시 검증했습니다. 길이 제한, 최상급 표현 같은 금지어, 그리고 다섯 개 변형끼리 너무 비슷하지 않은지를 유사도로 체크해서 걸러냈어요. 상품 하나를 다섯 개 롱테일 키워드로 쪼개 올리면 노출 면적이 다섯 배가 됩니다. 손으로는 못 하고 코드로만 되는 지점이고, 위탁판매 자동화에서 개발자가 가질 수 있는 거의 유일한 비대칭이었습니다.

위탁판매 자동화를 막는 문서 속 함정들

여기부터가 삽질 구간입니다.

첫 번째는 옵션 가격이었어요. 오너클랜 웹사이트에서는 옵션을 고르면 “+1,000원” 식으로 추가 금액이 뜹니다. 그런데 API는 차액이 아니라 추가금액이 반영된 최종 금액을 돌려줍니다. 상품 기준가가 1만 원이고 옵션 A가 1,000원 추가라면 API 응답의 옵션 가격은 11,000원이에요. 이걸 차액으로 알고 마진을 계산하면 전 상품 가격이 어긋납니다. 매뉴얼에 명시돼 있지만 무심코 지나치기 딱 좋은 자리예요.

두 번째는 배송비입니다. 대부분 2,500원이지만 상품마다 다를 수 있고, 묶음배송 수량에 따라 계산식이 따로 있어요. 구매 수량을 a, 묶음배송 가능 수량을 b라고 하면 (a-1)을 b로 나눈 몫 + 1만큼 배송비가 곱해집니다. 여러 상품을 함께 주문하면 각 상품의 배송비를 계산한 뒤 그중 최댓값이 최종 배송비가 되고요.

def shipping_fee(item, qty):
    if not item.box_quantity:
        return item.shipping_fee
    return item.shipping_fee * ((qty - 1) // item.box_quantity + 1)

세 번째는 등록하면 안 되는 상품입니다. 상품마다 openmarketSellable 값이 있는데, 이게 거짓인 상품을 오픈마켓에 등록하면 제재 등 불이익이 발생할 수 있다고 매뉴얼에 적혀 있어요. 속성 배열에 PROHIBIT이 붙으면 유통금지 상품이라 최대한 빨리 내려야 하고, 건강기능식품과 의료기기는 별도 취급 허가가 있어야 팔 수 있습니다. 이 네 가지는 점수 계산 이전에 하드 차단으로 걸었습니다.

네 번째가 제일 무섭습니다. 오너클랜 API는 품절이든 단종이든 판매 상태와 상관없이 모든 상품 정보를 돌려줍니다. 동기화를 안 하면 품절된 상품을 계속 팔게 되고, 그건 발송 지연으로 이어져서 스토어 페널티가 돼요. 매뉴얼은 변경 이력 조회로 증분 처리하거나 수정일 범위로 주기적으로 긁으라고 권하면서, 업데이트 주기가 1시간이면 최소 직전 2시간 변경분을 겹쳐서 쿼리하라고 안내합니다. 실패한 구간을 기록해뒀다가 다음 주기에 포함시키라는 것까지요. 그대로 따라서 1시간 주기 동기화를 systemd 타이머로 걸었습니다.

적립금이 떨어지면 아무 에러 없이 멈춘다

파이프라인을 다 짜고 나서야 깨달은 게 있습니다. 주문을 만들려면 오너클랜에 돈이 들어 있어야 한다는 것.

createOrder 입력을 아무리 봐도 결제 파라미터가 없어요. 대신 주문 조회 응답의 거래 내역 필드가 적립금 사용만 지원하고, 주문 상태는 미처리에서 입금완료로 넘어가는 구조입니다. 발주하는 순간 적립금에서 차감되고, 잔고가 없으면 주문이 미처리 상태에 멈춘다는 뜻이에요.

이게 왜 위험하냐면, 에러가 안 납니다. API는 200을 돌려주고 주문도 생성돼요. 그런데 공급사가 출고를 안 하고, 고객은 기다리고, 네이버는 발송 지연으로 판단합니다. 조용히 실패하는 게 제일 무서운 실패입니다.

그래서 감지를 세 겹으로 깔았습니다. 발주 전에 잔고와 배치 예상 금액을 비교하고, 발주 직후 주문 상태가 입금완료가 아니면 바로 알림을 띄우고, 15분마다 미처리 상태로 오래 머문 주문을 쓸어 담아 확인합니다. 그리고 매일 아침 현재 잔고를 최근 7일 일평균 발주액으로 나눠 며칠 버틸 수 있는지를 리포트로 받게 했어요.

여기서 위탁판매의 진짜 구조가 보입니다. 적립금은 비용이 아니라 운전자금이에요. 발주하면 돈이 즉시 빠지는데 네이버 정산은 구매확정 이후에 들어오니까, 그 사이 기간을 적립금으로 버텨야 합니다. 매출이 늘수록 묶이는 돈도 같이 늘어납니다. 참고로 오너클랜에는 이 공백을 노린 적립금 선충전 BNPL 서비스까지 붙어 있더군요. 그만큼 많은 셀러가 여기서 막힌다는 얘기겠죠.

쿠팡에도 똑같이 올리면 두 배가 된다는 오해

작업하면서 제일 크게 바로잡은 생각이 이겁니다. 처음엔 당연히 스마트스토어랑 쿠팡에 동시에 대량등록하면 노출이 두 배가 될 거라고 봤어요. 아니었습니다.

쿠팡 공식 안내에 따르면 쿠팡은 여러 선정 요소를 고려해 아이템 위너를 선택하고, 동일한 상품을 판매자 직접 배송이든 로켓배송이든 로켓그로스든 배송 타입과 관계없이 대표로 1개의 상품만 아이템 위너로 노출합니다. 단순히 최저가만 제시한다고 무조건 선정되는 건 아니라고 안내하면서도, 별도 안내에서는 가격 경쟁력 확보를 첫 번째 전략으로 꼽고 설정한 범위 안에서 가격을 자동 조정하는 기능까지 제공합니다.

위탁판매는 정의상 수백 명이 같은 공급사의 같은 상품을 팝니다. 그 상품들이 전부 하나의 페이지로 묶이고 그중 한 명만 노출돼요. 등록 개수를 아무리 늘려도 노출이 안 늘어난다는 뜻입니다. 심지어 가격 비중이 커서 100원씩 깎는 싸움이 되는데, 마진 15~25%짜리 위탁으로 버틸 수 있는 경쟁이 아니에요. 오너클랜이 쿠팡 아이템위너 대응 서비스를 따로 팔고 있는 것만 봐도 이게 실재하는 문제라는 게 보입니다.

반대로 스마트스토어는 상품마다 개별 페이지가 생깁니다. 1,000개 올리면 1,000개가 각자 롱테일 키워드로 검색에 걸려요. 물량이 곧 확률이고, 물량전은 코드로 이길 수 있습니다. 같은 위탁판매 자동화라도 채널의 노출 구조가 다르면 전략이 통째로 달라집니다. 그래서 쿠팡은 처음부터 밀어 넣지 않고, 스마트스토어에서 실제로 팔린 게 확인된 상품만 나중에 수동으로 얹는 쪽으로 설계를 바꿨습니다.

마지막 단계인 스마트스토어 등록은 네이버 커머스 API 센터를 씁니다. 여기서 알아둘 게 두 가지 있었어요.

하나는 이미지입니다. 상품 등록 요청에 이미지 URL을 그냥 넣으면 안 되고, 커머스API 기술지원 채널 답변에 따르면 상품 이미지 다건 등록 API를 먼저 호출해서 반환된 URL을 상품 이미지 필드에 넣어야 합니다. 상세 정보는 HTML 문자열을 그대로 넣으면 되지만 쓸 수 없는 태그가 있고요. 공급사 상세설명에는 외부 링크나 연락처가 섞여 있는 경우가 많아서, 그대로 올리면 제재 대상이 됩니다. 정제 로직을 따로 넣어야 했어요.

다른 하나는 이걸 나중에 서비스로 팔 생각이 있다면 알아둬야 할 내용입니다. 같은 채널의 다른 답변을 보면, 스마트스토어센터 외 제3자 솔루션에서 스토어 운영 관리 서비스를 제공하려면 커머스솔루션마켓에 등록되거나 API 대행사여야 한다고 돼 있습니다. 내 스토어 하나 돌리는 건 자유지만, 남의 스토어를 대신 관리하는 순간 절차가 생긴다는 거예요. 오너클랜 파트너사 API와 묶어서 솔루션화하는 그림을 그리고 있었는데, 그쪽은 생각보다 길이 복잡하다는 걸 미리 알게 된 셈입니다.

다 만들고 나서 든 생각

지금 파이프라인은 상품을 긁어오고, 점수를 매겨 추리고, 상품명 변형을 만들고, 상세 정보와 정보고시를 구성해서 스마트스토어에 올리는 데까지 한 번에 돌아갑니다. 주문이 들어오면 시뮬레이션으로 금액을 검증하고 발주까지 넘어가고요. 코드 자체는 생각보다 오래 안 걸렸어요. 시간이 걸린 건 매뉴얼을 읽고 함정을 찾아내는 쪽이었습니다.

다만 솔직하게 적어둘 게 있습니다. 파이프라인이 완성됐다는 건 운영이 자동화됐다는 뜻이지, 매출이 보장된다는 뜻이 아닙니다. 노출은 결국 네이버 알고리즘이 결정하고, 이 시스템이 하는 일은 그 확률 게임을 남들보다 싸고 빠르게 많이 돌리는 것뿐이에요. 상품명 조합이 실제로 먹히는지는 유입 데이터가 몇 주 쌓여야 알 수 있고, 그 데이터로 생성 프롬프트를 고치는 루프가 돌기 시작해야 비로소 상용 툴과 차이가 생깁니다. 거기까지 가기 전에는 그냥 느린 셀러봇이에요.

처음 봤던 그 릴스 6단계로 돌아가 보면, 그 방식이 틀린 이유도 같은 자리에 있습니다. 누구나 따라 할 수 있는 절차는 진입장벽이 없고, 진입장벽이 없으면 마진이 0으로 수렴해요. 위탁판매 자동화도 똑같습니다. 셀러봇을 켜는 것만으로는 아무 비대칭이 안 생깁니다. 내가 코드로 만들 수 있는 차이가 뭔지를 먼저 정하고, 그게 없으면 그냥 월 몇만 원 내고 상용 툴 쓰는 게 맞아요.

다음 글에서는 유입 키워드 데이터를 받아서 상품명 생성 로직을 고치는 부분을 다뤄보려고 합니다. 사실 이 데이터를 커머스 API로 받을 수 있는지가 아직 확실하지 않아서, 안 되면 비즈어드바이저에서 주 1회 내려받는 방식으로 우회할 생각입니다. 그 결과도 같이 적어둘게요.