1. 개발 배경 및 문제 인식
Translator-Agent가 다국어 데이터를 안정적으로 생성하기 시작하면서, 다음 병목은 "상품 분류"였다. 약 25만 건의 상품이 번역되었지만, 카테고리 코드가 누락되거나 서로 다른 언어에서 다른 트리 노드로 매핑되는 문제가 있었다. 기존의 수동 분류는 국가별 기준이 달라 일관성을 유지하기 어려웠다. 이를 해결하기 위해, AI 기반 카테고리 자동 분류 엔진(Classifier-Agent)을 개발했다.
REINDEERS 플랫폼은 한국, 태국, 말레이시아, 중국 4개국에 걸쳐 4,300개 이상의 파트너사가 등록되어 있고, 25,000건 이상의 실거래 데이터가 축적되어 있다. 공급사 1,800개 이상이 각자의 카테고리 체계로 상품을 등록하기 때문에, 동일한 "알루미늄 프로파일"이 한국에서는 "금속 가공재", 태국에서는 "건축 자재", 중국에서는 "산업용 비철금속"으로 분류되는 일이 빈번했다. 바이어 2,500개 이상이 검색과 비교를 할 때 이 불일치가 직접적으로 전환율을 떨어뜨렸다.
목표는 다음과 같았다.
- 상품명·설명·스펙·브랜드를 이용한 자동 카테고리 예측
- 언어 중립적인 벡터 임베딩 기반 분류
- 분류 확신도(confidence score)에 따른 승인/보류 체계
- MQ 파이프라인 기반의 비동기 동작 및 자동 재매핑
2. 초기 구조 설계
Classifier-Agent는 Translator-Agent가 생성한 i18n 데이터를 입력으로 받는다.
product.normalized 이벤트를 수신하면 문장 임베딩을 생성하고,
카테고리 벡터 DB에서 가장 유사한 카테고리를 탐색한다.
SentenceTransformer("paraphrase-multilingual-mpnet-base-v2") 모델을 사용했으며,
Redis Vector Search를 기반으로 구현했다.
이 모델을 선택한 이유가 있다. paraphrase-multilingual-mpnet-base-v2는 50개 이상의 언어를 지원하면서도 768차원 벡터를 생성한다. REINDEERS가 다루는 한국어, 태국어, 중국어, 말레이어, 영어를 모두 단일 벡터 공간에서 처리할 수 있다는 점이 결정적이었다. 다른 후보였던 multilingual-e5-large는 정확도가 약간 높았지만, 추론 시간이 2.3배 길어서 실시간 파이프라인에는 적합하지 않았다.
def classify_product(evt):
pid = evt["product_id"]
text = db.get_product_i18n(pid, "en")
vec = encoder.encode(text)
result = redis.ft("idx:category").search(Query("*=>[KNN 1 @embedding $vec]")
.return_fields("code","name","score").dialect(2), query_params={"vec": vec})
top = result.docs[0]
db.update_category(pid, top.code, confidence=top.score)
publish("product.categorized", {"id": pid, "code": top.code, "score": top.score})Redis Vector Search를 선택한 것도 의도적이었다. 카테고리 벡터 DB에 저장된 레코드는 약 1,200개(전체 카테고리 트리 노드 수)로 비교적 소규모이고, KNN 검색 시 p99 응답시간이 8ms 이내였다. 별도의 Pinecone이나 Qdrant 같은 전문 벡터 DB를 운영하는 것보다 기존 Redis 인프라를 활용하는 것이 운영 비용 면에서 훨씬 합리적이었다.
첫 테스트에서 10만 건 중 86%가 올바른 카테고리로 매핑되었지만, 남은 14%는 혼동되는 문장 구조(예: "adapter", "socket", "charger")로 인해 분류가 흔들렸다. 특히 산업 자재 분야에서는 동일한 단어가 전기, 배관, 기계 분야에서 완전히 다른 의미로 쓰이는 경우가 많다. "socket"이 전기 소켓인지 렌치 소켓인지 벡터만으로는 구분이 어려웠다. 이를 해결하기 위해 AI 에이전트 간 "Self-Tuning Loop"를 추가했다.
3. Self-Tuning Loop 구축
Classifier-Agent는 분류 확신도가 0.75 이하인 항목을 자동으로 Translator-Agent에 다시 전달한다. Translator-Agent는 해당 상품 설명을 문맥 기반으로 재작성하고, 다시 MQ로 반환한다. 이 순환 구조는 사람이 개입하지 않아도 자동으로 품질을 보정하도록 설계되었다.
재작성 요청에는 단순히 "다시 번역해줘"가 아니라, 분류 실패의 원인 정보가 포함된다. 예를 들어 "socket"이 전기 분야와 공구 분야 양쪽에서 높은 유사도를 보였다면, Translator-Agent에게 "이 상품의 용도 맥락을 보강해 달라"는 메타데이터가 전달된다. Translator-Agent는 원본 상품 스펙에서 전압, 규격, 재질 등의 단서를 찾아 설명을 보강한다.
if confidence < 0.75:
publish("translator.rewrite.request", {
"product_id": pid,
"lang": "en",
"hint": {"ambiguous_categories": [top1.code, top2.code], "gap": top1.score - top2.score}
})
else:
db.mark_classified(pid, status="CONFIRMED")실제 운영에서 하루 약 2,000건의 재작성 요청이 발생했고, 그중 80%는 두 번째 루프에서 확신도 0.85 이상으로 상승했다. 평균 분류 정확도는 BLEU 기준 0.83, recall 0.91로 측정되었다. 남은 20%(약 400건/일)는 세 번째 루프를 돌거나 수동 검토 대기열로 이동한다. 수동 검토 결과는 다시 학습 데이터로 피드백되어, 시간이 지날수록 Self-Tuning Loop의 1차 해결율이 점진적으로 올라가는 구조다.
4. 다국어 데이터의 일관성 문제
동일한 상품이 언어별로 서로 다른 벡터를 가지는 현상이 발생했다. 예를 들어, 한국어 설명과 영어 설명이 같은 의미임에도 서로 다른 카테고리로 분류되었다. 이는 모델의 언어별 표현 공간이 일치하지 않기 때문이었다. multilingual 모델이라 하더라도 언어 간 벡터 거리는 완전히 0이 아니다. 특히 태국어처럼 학습 데이터가 상대적으로 적은 언어에서 편향이 크게 나타났다.
해결책으로 모든 번역 텍스트를 영어 기준으로 재임베딩 후 평균 벡터를 사용했다.
langs = ["ko","en","zh-CN","th","ms"]
vecs = [encoder.encode(db.get_product_i18n(pid,l)) for l in langs]
mean_vec = np.mean(vecs, axis=0)
store_vector(pid, mean_vec)이 조정으로 언어별 분류 불일치율은 12% → 2.3% 수준으로 감소했다. 또한 Translator-Agent는 이후부터 모든 번역 결과에 "embedding ready" 플래그를 추가하여, 중복 벡터 계산을 피하도록 구조를 개선했다. 평균 벡터 계산은 모든 언어의 번역이 완료된 시점에만 트리거되며, 부분 번역 상태에서는 영어 단일 벡터를 임시로 사용한다.
5. 데이터 중복 및 병합 문제
서로 다른 소스에서 크롤링된 상품이 동일 카테고리로 인식되지 않는 사례가 있었다. 동일 제품이 이름만 다르게 등록되어 벡터 유사도가 낮게 나오는 경우였다. 예를 들어 한 공급사는 "SUS304 Stainless Steel Pipe"로, 다른 공급사는 "스테인레스 배관 304"로 등록한다. 사람이 보면 같은 제품이지만 벡터 유사도는 0.78 정도밖에 나오지 않았다.
이를 해결하기 위해 "Cluster Merge Function"을 도입했다. 주기적으로 모든 상품의 벡터 간 유사도를 계산하고, 0.92 이상인 항목은 동일 그룹으로 묶어 하나의 표준 SKU로 병합했다. 단, 전체 상품 간 pairwise 비교는 O(n^2)이므로 25만 건 전체를 매번 돌리는 것은 불가능하다. 대신 동일 카테고리 내에서만 비교하고, Approximate Nearest Neighbor(ANN) 알고리즘으로 후보군을 먼저 좁힌 다음 정밀 비교를 수행한다.
# ANN으로 후보군 축소 후 정밀 비교
candidates = redis.ft("idx:product").search(
Query("@category:{cat_code} => [KNN 10 @embedding $vec]"), ...)
for a, b in combinations(candidates, 2):
sim = cosine_similarity(vec[a], vec[b])
if sim > 0.92:
merge_sku(a, b)초기에는 병합 정확도가 낮았지만, Translator-Agent가 브랜드명·모델명 구문을 보정하면서 정확도가 급상승했다. AI가 스스로 데이터를 구조화하는 단계에 도달했다.
6. MQ 파이프라인 최적화
Classifier-Agent는 고빈도 이벤트를 처리하므로 MQ 병목이 자주 발생했다. 8월 초, 초당 메시지 처리량이 3,200건을 넘자 큐 지연이 누적되기 시작했다. Ops-Agent가 이를 감지하고 자동으로 큐를 분할하도록 설정했다. 각 카테고리 코드의 prefix로 큐를 샤딩하면 평균 지연이 400ms → 90ms로 줄었다.
for prefix in range(0,10):
channel.queue_declare(queue=f"classify.{prefix}", durable=True)큐 샤딩의 기준은 카테고리 코드의 첫 자리 숫자다. REINDEERS의 카테고리 트리는 10개의 대분류(0~9)로 시작하므로, 자연스럽게 10개의 병렬 큐로 분산된다. 각 큐에는 독립적인 consumer가 붙어 있어서, 특정 카테고리에 트래픽이 몰려도 다른 카테고리 처리에 영향을 주지 않는다.
이후 Translator-Agent의 이벤트와 충돌하지 않도록 라우팅 키 우선순위를 "classifier.#"로 상향시켰다. AI 에이전트 간 우선순위 체계가 명확히 분리되었다.
7. 품질 모니터링 및 자동 보고
품질 측정은 Ops-Agent가 수행한다.
Classifier-Agent는 모든 분류 결과의 확신도 평균, 오탐률(false positive), 중복 병합 건수를 집계해
Telegram /category 명령으로 실시간 보고한다.
*Classifier-Agent Report*
Processed: 124,530
Accuracy: 91.2%
Low-Confidence: 3,442
Merged: 814
Avg Delay: 95ms보고 주기는 매시간 자동 집계와 일일 종합 리포트 두 가지다. 일일 리포트에는 카테고리별 분류 분포, 확신도 하위 10% SKU 목록, Self-Tuning Loop 해결율 추이가 포함된다. 이 데이터는 카테고리 트리 자체를 개선하는 데에도 활용된다. 예를 들어 특정 카테고리에서 지속적으로 낮은 확신도가 나오면, 해당 카테고리의 세분화가 필요하다는 신호로 해석한다.
사람은 수치를 보고 판단만 내리면 된다.
실제 분류나 병합은 모두 AI가 수행하며, 필요 시 /agent restart classifier 명령으로 즉시 재가동할 수 있다.
8. 향후 계획
Classifier-Agent의 도입으로 상품 구조화 과정은 완전 자동화되었다. AI는 카테고리 분류, 데이터 병합, 문맥 보정까지 모두 자체적으로 수행한다. 번역과 분류가 서로 피드백을 주고받는 루프 구조가 완성되었고, MQ 기반 파이프라인은 초당 3,000건 이상 처리에도 안정적으로 유지된다.
다음 단계는 분류 결과를 기반으로 재고·물류·가격 정책에 연동하는 것이다. 구체적으로는 카테고리별 HS Code 자동 매핑, 카테고리 기반 관세율 예측, 그리고 유사 상품 간 가격 벤치마킹이 예정되어 있다. $130B 이상 규모의 동남아 B2B 시장에서 상품 분류의 정확도는 곧 검색 품질이고, 검색 품질은 곧 거래 전환율이다. Classifier-Agent는 그 기반을 자동화한 첫 번째 엔진이다.