Blog

AI 품질 보정과 데이터 재생산 파이프라인 1. Translator-Agent 2.0의 설계 목표 9월 초부터 수집되는 데이터의 양이 폭증하면서 AI 번역 품질이 일관되지 않다는 문제가 보고되었다. 평균 BLEU 점수는 0.82 수준이었지만 언어 간 편차가 컸고, 특정 기술 문서에서 용어가 반복적으로 오역되었다. Translator-Agent 2.0의 목적은 AI가 스스로 품질을 예측하고, 낮은 품질의 데이터를 재생산하도록 만드는 것이었다. BLEU, TER, Context Vector를 이용한 품질 점수화 자동 재번역 루프 (Re-Translation Loop) Quality-Driven Event Routing (품질 점수 기반 라우팅) 자동 승인 및 검증 리포트 생성 이 시스템에서 "품질 보정"이라 함은 AI가 생성한 결과물을 AI가 다시 검증하는 구조를 말한다. 사람이 모든 번역 결과를 하나씩 검토하는 것은 물리적으로 불가능하므로, AI가 1차 생성 후 별도의 검증 파이프라인을 거쳐 기준을 충족하지 못하는 데이터만 재처리하는 방식을 채택했다. 2. 품질 평가 메커니즘 Translator-Agent 2.0은 번역이 완료되면 즉시 BLEU와 TER을 계산하고, 품질 점수를 생성한다. 이 점수는 0~1 사이 실수값으로 표현되며, 0.75 미만이면 재번역 큐에 등록된다. BLEU는 의미 유사도, TER은 문장 수정 비율을 측정한다. 품질 점수는 Redis의 Sorted Set에 저장되어 우선순위 처리가 가능하다. score = (bleu * 0.7 + (1 - ter) * 0.3) redis.zadd("i18n.quality", {key: score}) if score ...

외부 데이터 크롤링과 다국어 처리 자동화 1. 배경 — 외부 연동 대신 크롤링 선택의 이유 REINDEERS 플랫폼은 각국의 표준, 인증, 관세 데이터를 기반으로 상품 정보를 구조화해야 했다. 그러나 각 기관의 공개 API는 존재하지 않거나 접근이 제한적이었다. 태국 TISI, 한국 UNIPASS, 중국 GB표준, 말레이시아 SIRIM 등은 모두 웹 기반 HTML 구조만 제공했다. 이에 따라 API 연동 대신 크롤링 구조를 도입했다. 크롤링은 인증/표준 데이터뿐 아니라 환율과 해운 스케줄에도 적용되었다. 환율은 4개 은행(방콕은행, 하나은행, 중국은행, 메이뱅크)에서 매일 수집되며, 해운 스케줄은 HMM, KMTC, SM Line 세 개 선사에서 크롤링된다. 이 모든 외부 데이터가 플랫폼의 가격 계산, 물류 일정, 인증 검증의 기초가 된다. 2. 국가별 스크래퍼 아키텍처 크롤러는 국가별로 독립적인 설정을 가진다. 각 크롤러는 Cloud Function에서 주기적으로 호출되며, 수집 주기는 데이터의 성격에 따라 다르다. 환율 데이터는 매일 1회, 해운 스케줄은 월 1회, 인증 데이터는 주 1회 수집된다. 스크래퍼는 계층 구조로 설계되어 있다. 최상위에 공통 인터페이스(Scraper Layer)가 있고, 그 아래에 국가별 구현이 존재한다. 공통 인터페이스는 HTTP 요청, 응답 파싱, 데이터 정규화, 에러 핸들링의 표준을 정의한다. 국가별 구현은 해당 사이트의 HTML 구조와 인증 방식에 맞춰 구체적인 파싱 로직을 담당한다. # Scraper architecture example class BaseScraper: def fetch(self, url): ... def parse(self, html):...

MQ + Redis 기반 글로벌 데이터 일관성 구조 1. 문제 인식 — 다국가 데이터 일관성의 복잡성 8월 초, 홍콩(HK), 서울(KR), 쿠알라룸푸르(MY), 방콕(TH)의 네 개 리전이 동시에 서비스되면서 가장 큰 문제는 데이터 일관성이었다. 각 리전의 Redis 캐시와 MySQL 데이터베이스가 서로 다른 타임스탬프로 업데이트되어, 동일 상품의 재고 수량, 세션, 장바구니 데이터가 불일치하는 현상이 자주 발생했다. 기존 복제(Replication) 방식은 지연이 300~800ms 수준으로 불안정했고, Redis async replication은 트래픽 피크 시 복제 손실이 발생했다. 이 문제는 단순 데이터 복제가 아니라 이벤트 레벨에서의 보정(Event-level Consistency) 으로 접근해야 했다. 특히 B2B 무역 플랫폼에서는 재고 데이터의 불일치가 실제 주문 오류로 직결된다. 한 리전에서 재고가 0인 상품이 다른 리전에서는 재고가 있는 것으로 표시되면, 주문이 접수된 후 취소되는 상황이 발생한다. 이는 공급사와 바이어 양쪽 모두에게 신뢰 문제를 만든다. 따라서 데이터 일관성은 단순 기술 과제가 아니라 비즈니스 신뢰도의 문제였다. 2. MQ 토폴로지 설계 — Topic Exchange와 Routing Key 우리는 Redis 복제 대신 MQ 기반의 "Event-driven Sync" 구조로 전환했다. LavinMQ의 Topic Exchange를 사용하여 이벤트를 라우팅한다. 각 리전의 데이터 변경 이벤트는 data.sync 토픽으로 발행되며, routing key는 data.sync.{source_region}.{data_type} 형식을 따른다. # Routing key examp...

AI 협업 환경 구축과 코드 자동화 시스템 1. AI 협업 환경 도입 배경 8월 초, 전체 개발 속도는 아키텍처 안정화와 함께 급격히 느려졌다. 다국어 코드베이스, 서비스 간 인터페이스 복잡도, 릴리즈 간 충돌 등으로 개발자가 직접 관리해야 할 영역이 지나치게 많았다. 단순 반복적인 테스트, 리뷰, 빌드 작업을 사람 대신 AI에게 맡기기로 했다. 목표는 다음과 같았다. AI가 코드 문맥을 이해하고 변경 사항을 요약 및 리뷰 CI/CD 파이프라인과 직접 연동하여 코드 품질 평가 Prompt Repository를 통한 코드 수정 자동화 Telegram을 통한 빌드/배포 명령 및 상태 보고 핵심 원칙은 하나였다. AI는 코드를 생성하고 수정하지만, 최종 병합과 배포는 반드시 사람이 승인한다. 어떤 상황에서도 AI가 단독으로 프로덕션에 코드를 반영하는 일은 없도록 설계했다. 이 원칙은 이후 모든 자동화 시스템의 기본 전제가 되었다. 2. 환경 구성 — Cursor & Claude Code 기반 개발 체계 모든 개발 작업은 Cursor 에디터를 기본으로 통합했다. Cursor는 프로젝트의 디렉토리 구조와 문맥을 인식하여 Claude Code API와 연결된다. 개발자는 명령을 직접 내리지 않고, "의도(Prompt)"만 작성한다. 예를 들어 "상품 등록 API의 중복 검증 로직 최적화"라고 명시하면, Claude Code가 Git 브랜치를 생성하고 수정된 diff를 자동으로 커밋한다. # Example of AI-generated commit feat(product): optimize duplicate validation logic - a...

1. 문제 인식 — 이미지 트래픽과 품질의 불균형 8월 초, 상품 이미지 요청량이 하루 평균 1200만 건을 넘어서면서 CDN 트래픽 비용이 급격히 증가했다. 원인은 대부분 비효율적인 이미지 크기와 중복 요청이었다. 크롤링 단계에서 원본 이미지는 고해상도 상태로 저장되었고, 프런트엔드는 단일 사이즈 이미지를 모든 기기에서 공통 사용했다. REINDEERS 플랫폼에는 4,300개 이상의 파트너사가 등록되어 있고, 각 공급사가 올리는 상품 이미지는 평균 5~8장이다. 이 이미지들이 바이어 2,500개 이상의 검색과 조회를 통해 요청되면서 트래픽이 기하급수적으로 증가했다. 특히 태국, 말레이시아, 중국 등 여러 국가에서 동시에 접속하는 구조이기 때문에 지역별 CDN 분산도 필수였다. 초기에는 Cloud Function을 이용한 이미지 리사이징 API를 직접 운영했으나, 처리량 대비 비용이 높고, 콜드 스타트 지연이 잦았다. 평균 응답 시간이 200ms를 넘었고, 동시 요청이 몰리는 시간대에는 500ms까지 치솟았다. 따라서 Tencent COS의 내장 이미지 처리 기능을 이용한 서버리스 구조로 전환하기로 결정했다. 2. COS 서버리스 이미지 처리 구조 설계 COS(Cloud Object Storage)는 별도의 서버나 Lambda 없이도 URL 파라미터 기반으로 이미지 변환을 수행할 수 있다. 이 기능을 이용하면 단 한 번의 업로드로 모든 변환 버전을 실시간으로 생성할 수 있다. 예를 들어, 800x800 썸네일을 webp로 변환하려면 다음과 같이 요청한다. https://cdn.reindeers.com/images/p/12345.jpg?imageMogr2/thumbnail/800x800/quality/90/for...

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에서 가장 유사한 카테고리를 탐색한다. SentenceTransfo...

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 이벤트를 수신하면 해당 상품의 기본 언어 데이터를 조회하...