Skip to main content

Translator-Agent와 데이터 품질 관리 체계

Translator-Agent와 데이터 품질 관리 체계

1. 초기 Translator-Agent 도입 배경

7월 초, 플랫폼 내 등록된 상품 수가 20만 건을 초과하면서 다국어 데이터 품질 문제가 심각하게 드러났다. 기존에는 외부 번역 API를 호출해 결과를 저장하는 단순 구조였다. 하지만 언어별 품질 편차가 심했고, 카테고리명, 단위, 브랜드명 등이 잘못 번역되는 사례가 누적되었다.

"Steel Pipe"가 태국어로 "철 담배 파이프"로 번역되거나, "12V DC Motor"의 "DC"가 "직류"가 아닌 "워싱턴 D.C."로 해석되는 사례가 실제로 발생했다. 산업 자재 분야의 전문 용어는 일반 번역 모델로는 정확도가 낮다. 수동 교정 인력을 투입하지 않으면서도 번역 품질을 확보하기 위해 "Translator-Agent"를 내부적으로 개발하기로 결정했다.

Translator-Agent의 설계 목표는 다음과 같았다.

  • 번역 품질 자동 평가 및 등급화 (MACHINE / HUMAN / APPROVED)
  • 다국어 텍스트 캐시 및 중복 요청 제거
  • 문장 단위가 아닌 문맥 단위 번역 처리 — 상품 카테고리, 스펙, 단위를 함께 고려
  • MQ 기반 병렬 번역 및 품질 피드백 루프 자동화
  • 산업 자재 전문 용어 사전(Glossary) 적용

2. 아키텍처 설계 — AI 모델 혼합 전략

Translator-Agent는 MQ 이벤트 소비자로 동작한다. product.created 또는 i18n.missing 이벤트를 수신하면 해당 상품의 기본 언어 데이터를 조회하고, 두 가지 AI 모델을 혼합하여 번역을 수행한다.

첫 번째 단계에서는 대량 번역에 최적화된 모델이 초안(draft)을 생성한다. 이 초안은 속도가 빠르지만 문맥 이해가 약할 수 있다. 두 번째 단계에서는 문맥 검증 모델이 초안을 상품의 카테고리와 스펙 정보와 대조하여 오역을 보정한다. 이 2단계 파이프라인 덕분에 속도와 품질을 동시에 확보할 수 있다. 

def translate_product(evt):
    pid = evt["product_id"]
    base = db.get_product(pid)
    for lang in ["en", "ko", "zh-CN", "th"]:
        if lang == base.lang:
            continue
        # 1단계: 용어 사전 적용 후 대량 번역 모델로 초안 생성
        raw = glossary.apply(base.name, base.description, base.specs)
        draft = bulk_translator.translate(raw, target=lang)
        # 2단계: 문맥 검증 모델로 보정
        refined = context_refiner.refine(draft, category=base.category, specs=base.specs)
        db.save_translation(pid, lang, refined, quality="MACHINE")
        publish("i18n.updated", {"id": pid, "lang": lang})

MQ 큐는 언어별로 분리되어 병렬 처리가 가능했다. 초기에 대량 번역 모델의 API 요청 한도가 낮아 하루 약 3만 건 이상 처리 시 오류가 빈번하게 발생했다. 이 문제는 캐시 구조를 추가하여 이미 번역된 문장은 재요청하지 않도록 수정함으로써 해결했다.

3. 용어 사전(Glossary)과 도메인 특화

산업 자재 분야에서는 일반 번역 모델이 자주 실수하는 용어가 많다. 예를 들어 "Bearing"은 일반적으로 "견디다"로 번역될 수 있지만, 산업 자재에서는 "베어링(축받이)"이 정확한 번역이다. 이런 도메인 특화 용어를 관리하기 위해 Glossary 시스템을 Translator-Agent에 내장했다.

Glossary는 약 8,000개의 산업 용어를 4개 언어로 매핑한 데이터셋이다. 번역 전 원문에서 Glossary에 등록된 용어를 먼저 탐지하고, 해당 용어는 AI 모델의 번역 결과와 관계없이 Glossary 값으로 강제 치환한다. 이 방식으로 브랜드명, 규격 코드, 단위(mm, kg, PSI 등)가 번역 과정에서 왜곡되는 것을 방지한다. 

# Glossary 적용 예시
glossary_map = {
    "bearing": {"th": "แบริ่ง", "ko": "베어링", "zh": "轴承"},
    "stainless steel": {"th": "สแตนเลส", "ko": "스테인리스강", "zh": "不锈钢"},
}

def apply_glossary(text, target_lang):
    for term, translations in glossary_map.items():
        if term.lower() in text.lower():
            text = text.replace(term, translations[target_lang])
    return text

4. 중복 번역 방지 및 캐시 전략

두 번째 이슈는 동일 문장이 중복 번역되는 문제였다. MQ 이벤트가 일시적으로 중복 발행되거나, DB 저장 직후 재번역 이벤트가 발행되는 경우에 발생했다. Translator-Agent가 이미 번역된 텍스트를 덮어쓰면서 품질 점수가 불안정하게 변했다.

Redis 기반의 번역 키 해시를 추가했다. 각 번역 요청 전에 hash(content+lang) 키를 조회해 동일 원문+동일 언어의 번역이 이미 존재하는지 확인한다. 이미 존재하면 MQ 메시지를 소비하지 않고 스킵 로그만 남긴다. 

key = f"tr:{hashlib.md5((content + lang).encode()).hexdigest()}"
if redis.exists(key):
    publish("i18n.skipped", {"lang": lang, "pid": pid})
else:
    redis.set(key, 1, ex=86400)
    process_translation(content, lang)

이 변경 이후 MQ 소비량은 약 35% 감소했고, 중복 번역은 90% 이상 줄었다. 품질 점수의 표준편차도 0.18에서 0.05 수준으로 안정화되었다.

5. 품질 평가 및 자동 보정 루프

번역 품질은 BLEU와 TER 지표를 기반으로 측정했다. 각 언어별 기준 점수는 BLEU >= 0.7, TER <= 0.3으로 설정했다. 기준 이하인 문장은 자동으로 재번역 대상에 등록된다. 재번역은 문맥 검증 모델 단독으로 수행되며, 상품 카테고리와 스펙 정보를 추가 컨텍스트로 제공하여 정확도를 높인다. 

score = bleu_score(reference_text, translated)
if score < 0.7:
    corrected = context_refiner.correct(translated, base.category, base.specs)
    db.update_translation(pid, lang, corrected, quality="REWRITE")
    publish("i18n.rewrite", {"id": pid, "lang": lang, "score": score})

평균 품질 점수는 3회 루프 이후 0.68에서 0.83으로 상승했다. BLEU 점수가 0.85 이상이면 품질 등급을 자동으로 APPROVED로 승격하고, Redis 캐시에 영구 저장하여 DB 조회를 생략한다.

6. 인적 검수(Human Review) 워크플로우

AI가 아무리 정확해도 최종 검수는 사람이 해야 하는 영역이 있다. 특히 신규 카테고리의 전문 용어나, 법적 문서에 사용되는 표현은 AI 단독으로 판단하기 어렵다.

Translator-Agent는 품질 등급이 MACHINE인 번역 중 BLEU 점수가 0.65~0.75 구간에 있는 항목을 "Human Review 후보"로 분류한다. 이 후보 목록은 운영 대시보드에 노출되며, 검수자가 번역을 확인하고 승인하면 등급이 HUMAN으로 변경된다. 이후 운영팀 최종 승인을 거치면 APPROVED로 확정된다.

검수 대상은 전체 번역의 약 8% 수준이다. 나머지 92%는 AI가 자동으로 APPROVED까지 처리한다. 이 비율은 Glossary가 확충되고 모델이 개선될수록 점차 감소하고 있다.

7. 캐시 무효화 및 데이터 일관성

번역 데이터가 갱신될 때 Redis 캐시와 DB 간 일관성이 깨지는 문제가 있었다. 일부 페이지가 갱신된 번역을 반영하지 못하고 이전 데이터를 그대로 노출했다. 이는 Cloud Function이 i18n.updated 이벤트를 수신하지 못했을 때 발생했다.

해결책으로 MQ 재시도 큐(Delay Queue)를 추가했다. 이벤트 수신이 실패한 경우 30초 후 재발행되도록 구성했다. Function 로그는 Ops-Agent가 수집하여 Telegram /cache 명령으로 즉시 조회 가능하게 했다. 

publish("cache.invalidate", {"kind": "i18n", "id": pid, "lang": lang}, delay=30)

이후 페이지 캐시 불일치율은 2.4%에서 0.3% 수준으로 감소했다. 동일 상품의 다국어 데이터를 동시에 요청해도, Redis TTL(15분) 내에서는 항상 최신 상태를 유지했다.

8. AI 에이전트 간 협업 및 우선순위 체계

Translator-Agent는 Classifier-Agent, Crawler-Agent와 동일한 MQ를 사용한다. 이벤트 혼선이 발생하지 않도록 각 에이전트에 우선순위를 부여했다. Crawler → Classifier → Translator 순으로 이벤트를 처리하며, Translator-Agent는 product.normalized 이벤트를 수신한 이후에만 작동한다. 

agents:
  - name: crawler
    priority: 1
    output_event: "product.crawled"
  - name: classifier
    priority: 2
    depends_on: ["crawler"]
    output_event: "product.normalized"
  - name: translator
    priority: 3
    depends_on: ["classifier"]
    output_event: "i18n.updated"

이 설정 이후 각 에이전트의 처리 순서가 명확히 보장되었고, MQ 지연률은 60% 이상 개선되었다. 하루 평균 번역 처리량은 약 18만 건, 품질 점검 루프는 2만 건 수준에서 안정적으로 유지되고 있다.

9. 품질 보고 자동화 및 운영 피드백

Translator-Agent는 모든 번역 결과와 품질 점수를 요약해 Telegram으로 자동 보고한다. Ops-Agent는 /quality 명령으로 지난 24시간의 번역 통계를 텍스트로 출력한다. 품질 저하나 모델 응답 지연이 감지되면 자동 재시작이 수행된다. 

*Translator-Agent Report*
Processed: 183,412 items
Average BLEU: 0.81
Rewrites: 2,948
Human Review Pending: 14,672
Failures: 46
Skipped (duplicate): 5,130
Cache Hit Rate: 96.2%

10. 결론 및 현재 상태

Translator-Agent의 도입 이후 수동 번역 프로세스는 완전히 제거되었다. AI는 크롤링된 원문 데이터를 수집하고, 자체적으로 번역, 검증, 보정, 저장, 품질 평가를 수행한다. MQ 이벤트를 통해 실시간으로 다른 시스템과 연동되며, 사람은 전체 번역의 8%에 해당하는 검수 후보만 확인하면 된다.

번역 품질은 언어별 BLEU 기준 0.8 이상을 유지 중이며, 캐시 일관성, 이벤트 동기화, 품질 자동보정 루프 모두 안정화되었다. Glossary에는 매주 약 200개의 신규 용어가 추가되고 있으며, 이는 Classifier-Agent가 감지한 오분류 사례에서 자동 추출된다. AI가 데이터를 번역하고, 품질을 측정하고, 스스로 개선하는 순환 구조가 완성되었다.

관련 글

Labels:

Popular posts from this blog

Reindeers Workflow: B2B 파트너 업무 효율과 자동화를 위한 워크플로우 플랫폼

B2B 국제 무역에서 하나의 거래가 완료되기까지 관여하는 시스템과 사람의 수는 예상보다 훨씬 많다. 견적 요청에서 시작해 공급사 선정, 발주, 포워딩 비딩, 통관 서류 준비, 출하, 배송, 정산까지 — 각 단계마다 서로 다른 담당자가 서로 다른 도구에서 수작업을 반복한다. 이 현장에서 반복적으로 발생하는 비효율은 분명하다. 바이어가 견적을 확정하면 공급사에게 이메일이나 메신저로 직접 통보해야 하고, 결제가 완료되면 수동으로 정산 시트에 옮기면서 1~3일이 소요된다. 출하 후에는 선적 정보를 기반으로 CI, PL, CO를 수동 생성하며 누락이 발생하고, 배송 완료 후 공급사/포워더 정산을 수작업으로 대조하면서 오차가 누적된다. ERP, 이메일, 스프레드시트, CRM에 같은 데이터를 반복 입력하는 것도 일상이다. 이 문제들의 공통점은 명확하다. "이벤트가 발생했을 때 후속 작업이 자동으로 실행되지 않는다" 는 것이다. 견적이 확정되었다는 '사실'은 시스템에 기록되지만, 그 사실이 다음 단계의 업무를 자동으로 트리거하지는 않는다. Reindeers Workflow는 이 문제를 해결하기 위해 만들어졌다. 단순히 "자동화 도구를 제공한다"가 아니라, REINDEERS 플랫폼에서 발생하는 실제 거래 이벤트를 기반으로 후속 업무가 자동 실행되는 구조를 만드는 것이다. REINDEERS 플랫폼과의 연결: 거래 이벤트가 워크플로우를 트리거한다 Reindeers Workflow의 가장 중요한 차별점은 범용 자동화 도구가 아니라 REINDEERS 본 플랫폼의 거래 이벤트에 직접 연결 된다는 것이다. REINDEERS에서 발생하는 핵심 거래 이벤트가 MQ(Message Queue)를 통해 워크플로우의 트리거가 된다. 거래 이벤트 트리거되는 워크플로우 실행 내용 quote.confirmed 공...
Read more

레인디어스, Buybly로 동남아시아 산업자재 시장 혁신

B2B 오픈마켓 REINDEERS, 한국 기업의 글로벌 진출을 돕다 레인디어스, 머신러닝 기반의 산업자재 매칭 솔루션으로 경쟁력 강화 김명훈 레인디어스 대표 산업자재 시장의 복잡성과 유통장벽은 많은 기업들에게 큰 도전 과제가 되어왔다. 특히 동남아시아 시장 진출을 원하는 한국의 산업자재 제조사들은 현지의 불투명한 거래 환경과 물류 문제로 어려움을 겪어왔다. 이러한 상황에서 레인디어스의 REINDEERS 플랫폼은 새로운 기회를 제시하고 있다. REINDEERS는 B2B 오픈마켓으로, 한국 기업들이 손쉽게 동남아시아 시장에 진출할 수 있도록 지원하며, 유통의 복잡성을 해결하는 혁신적인 솔루션으로 주목받고 있다. 이러한 변화의 중심에는 레인디어스 대표가 있다. 그는 지난 9년간 태국에서의 경험을 바탕으로 고객의 pain point를 해결하기 위해 REINDEERS를 개발했다. 이번 인터뷰를 통해 그의 비전과 경영 철학, 그리고 REINDEERS가 어떻게 산업자재 시장을 변화시키고 있는지에 대해 깊이 있는 이야기를 나누게 되었다. 김명훈 레인디어스 대표 -.소개 레인디어스는 국내 산업자재 제조사들이 동남아시아 시장에 쉽게 진출할 수 있도록 돕는 B2B 오픈마켓인 REINDEERS를 운영하고 있다. 해외 시장 진출에서 가장 큰 장애물인 유통, 물류, 무역의 장벽을 해결해주는 것이 이 플랫폼의 핵심이다. REINDEERS는 단순한 거래 플랫폼이 아니라, 산업자재 구매와 공급 과정을 간소화하고 최적화하는 One-Stop 솔루션으로 자리 잡았다. 레인디어스의 서비스는 REINDEERS와 Enterprise Solution(ERP, POP, WMS)으로 구성되어 있다. 이 솔루션은 동남아시아 현지의 고객사와 공급사에 맞춤형으로 제공되며, 산업현장의 선진화를 이끌어낸다. 기업 운영과 생산 관리, 재고 관리를 전산화해 이익을 극대화하는 데 기여하고 있다. REINDEERS는 산업현장에서 획득한 Raw data를 활용해 인공지능 분석을 통해 발주 ...
Read more

견적·주문 UI/UX 개편: “흐름”을 보여주다

REINDEERS 플랫폼에서는 최근 견적(PQ–QA–QB)과 주문(PO–DO–포워딩–결제) 전반의 UI/UX를 다시 설계했다. 겉으로 보면 “화면이 더 깔끔해졌다” 정도로 보일 수 있지만, 실제로는 내부적으로 이미 정리된 고객사–공급사–포워딩 관계 구조 를 사용자 화면에 그대로 노출하기 위한 구조 개편이었다. 현재 시점은 명확하다. 플랫폼의 거래 구조(고객사/공급사/포워딩 연결)는 개선을 완료했고, 이제는 DVRP 베타(2026년 3월 예정) 를 위한 개발이 진행되는 단계다. 즉, 지금 UI/UX 개편은 “보기 좋은 화면”이 목적이 아니라, 실행 레이어(DVRP)로 연결 가능한 형태의 데이터·흐름을 UX로 고정 하는 작업에 가깝다. 1) UI/UX 개편의 출발점: “상태 리스트”는 국제 거래를 설명하지 못한다 국제 무역/물류 플랫폼에서 거래는 ‘단계’가 아니라 ‘관계’다. 견적이 주문을 만들고, 주문은 여러 DO로 분기되고, 포워딩 선택은 DO 단위로 붙으며, 결제는 확정된 실행 결과를 기준으로 발생한다. 문제는 기존 화면이 이 구조를 “리스트”로 표현하고 있었다는 점이다. 문서가 나열되고 상태가 나열되면, 사용자는 결국 다음 질문을 하게 된다. 어떤 견적이 확정되었고, 그 확정이 주문과 어떻게 연결되었나? 왜 DO가 여러 개로 나뉘고, 각각의 물류 실행은 어떤 차이가 있나? 포워딩은 언제 선택하는가? 결제는 무엇을 기준으로 묶이는가? 이 질문은 사용자가 부족해서가 아니라, UI가 “흐름”을 전달하지 못해서 생긴다. 그래서 이번 개편은 디자인보다 먼저 흐름의 표현 단위 를 재정의하는 것에서 시작했다. 2) 견적 흐름 재정의: PQ → QA → QB (객체 분리 + 분기 표현) 견적은 다음 구조로 정리되었다. PQ (Purchase Quote) : 고객사의 견적 시작점 QA (Quote Request) : 공급사에 전달되는 요청 단위(분기 가능) QB (Quote...
Read more