외부 데이터 크롤링과 다국어 처리 자동화

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): ...
    def normalize(self, data): ...
    def handle_error(self, error): ...

class ThailandExchangeScraper(BaseScraper):
    """Bangkok Bank exchange rate scraper"""
    def fetch(self, url):
        # Step 1: GetDateTimeLastUpdate for latest sequence
        # Step 2: Getfxrates/{date}/{sequence}/en
        ...

class KoreaExchangeScraper(BaseScraper):
    """Hana Bank exchange rate scraper"""
    def fetch(self, url):
        # AJAX POST with X-Requested-With header
        ...

환율 스크래퍼의 경우, 통합 서비스가 4개국 스크래퍼를 병렬로 실행하고 성공한 결과만 API에 전송하는 구조를 따른다. 일부 국가 스크래퍼가 실패하더라도 나머지 국가의 데이터는 정상적으로 업데이트된다.

3. Anti-Bot 대응과 요청 패턴 관리

각 은행과 기관 사이트마다 봇 차단 방식이 다르기 때문에 대응 전략도 개별적으로 수립했다. 중국은행은 현실적인 User-Agent 헤더를 필수로 요구한다. 메이뱅크는 iPhone Safari User-Agent와 함께 1~3초의 랜덤 딜레이를 적용해야 한다. 한국 하나은행은 AJAX POST 요청에 X-Requested-With: XMLHttpRequest 헤더가 없으면 응답을 거부한다.

# Anti-bot handling per country
HEADERS = {
    "CN": {"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) ..."},
    "MY": {"User-Agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 16_0 ...)"},
    "KR": {
        "User-Agent": "Mozilla/5.0 ...",
        "X-Requested-With": "XMLHttpRequest"
    }
}

# Maybank requires random delay
if country == "MY":
    time.sleep(random.uniform(1, 3))

방콕은행의 경우 API가 2단계 프로세스를 요구한다. 먼저 GetDateTimeLastUpdate를 호출하여 최신 시퀀스 번호와 날짜를 가져오고, 그 값으로 Getfxrates/{date}/{sequence}/en을 호출한다. 시퀀스가 비정상적일 경우를 대비해 여러 시퀀스 번호를 순차적으로 시도하는 fallback 로직이 적용되어 있다.

4. 데이터 정규화와 다국어 처리

Translator-Agent는 크롤러가 발행한 이벤트를 수신하면 자동으로 언어를 감지하고 다국어로 변환한다. 모든 데이터는 영어(en), 한국어(ko), 태국어(th), 중국어(zh-CN), 말레이어(ms) 버전으로 저장된다. 번역 품질이 기준 이하일 경우 자동으로 재번역을 요청한다.

환율 데이터의 정규화는 특히 주의가 필요한 영역이다. 중국은행은 100달러 기준 환율을 제공하므로 100으로 나누어 1달러 기준으로 변환해야 한다. 각 은행의 데이터 형식이 다르기 때문에, 스크래퍼 단계에서 원시 데이터를 통일된 포맷으로 정규화한 후 API에 전송한다.

# China Bank rate normalization
rate_for_100_dollars = float(selling_rate_text)
rate_per_dollar = rate_for_100_dollars / 100

# Unified data format
{
    "country": "CN",
    "currency": "CNY",
    "rate": rate_per_dollar,
    "source": "Bank of China",
    "updated_at": "2025-08-29T09:00:00Z"
}

Translator-Agent는 특히 기술 용어와 단위의 오역을 방지하기 위해 내부 Glossary를 참조했다. Glossary는 AI가 자동 업데이트하며, 3,000개 이상의 기술 용어를 관리한다. 예를 들어 "ISO", "IEC" 같은 국제 표준 약어는 번역하지 않고 원문을 유지하도록 규칙이 설정되어 있다.

5. 에러 핸들링과 재시도 전략

외부 사이트를 대상으로 한 크롤링은 네트워크 환경이나 DOM 변경에 취약하다. 하루에 수백 회 이상 실행되는 크롤러에서 실패가 발생하는 것은 불가피하다. 실패 시 대응 전략은 3단계로 구성된다.

1단계: 동일 요청을 3회까지 재시도. 시도 간격은 지수 백오프(2초, 4초, 6초) 적용
2단계: 3회 재시도 실패 시 MQ DelayQueue에 등록하여 5분 후 재시도
3단계: DelayQueue 재시도도 실패하면 Telegram 알림으로 관리자에게 보고

# Retry with exponential backoff
for attempt in range(3):
    try:
        response = session.get(url, timeout=15)
        response.raise_for_status()
        return response
    except Exception as e:
        if attempt < 2:
            time.sleep(2 * (attempt + 1))
        else:
            publish("crawl.failed", {
                "source": source,
                "url": url,
                "error": str(e),
                "attempts": 3
            })

Telegram 알림은 5분 쿨다운이 적용되어 동일한 실패가 반복될 때 알림이 폭주하지 않도록 했다. 실패 국가와 성공 국가를 분리하여 추적하기 때문에, 하나의 국가 스크래퍼가 실패하더라도 나머지는 정상적으로 데이터를 갱신한다.

6. 데이터 중복 제거와 캐시 전략

크롤링 데이터는 동일 표준이 여러 언어 페이지에서 중복 수집될 수 있다. Translator-Agent는 각 데이터의 MD5 해시를 계산해 중복을 검증한다. 중복 항목은 Redis 캐시에 24시간 저장되어, 재수집 시 즉시 스킵된다.

key = f"hash:{hashlib.md5(content.encode()).hexdigest()}"
if redis.exists(key):
    publish("crawl.skipped", {"url": url})
else:
    redis.set(key, 1, ex=86400)
    save_data(content)

이 로직으로 일일 데이터 중복률은 12%에서 0.7%로 감소했다. 저장된 데이터는 국가별로 분류되어 MySQL과 Redis에 병렬로 저장되며, Redis TTL은 48시간으로 설정된다.

7. 해운 스케줄 크롤링과 운항 데이터 통합

해운 스케줄 크롤링은 환율이나 인증 데이터와 성격이 다르다. HMM, KMTC, SM Line 세 개 선사의 웹사이트에서 월별 운항 일정을 수집하며, 각 선사의 HTML 구조와 인터랙션 방식이 전혀 다르기 때문에 선사별 전용 스크래퍼가 필요하다.

스케줄 크롤링은 순차적으로 실행되며, 각 선사별로 10분의 타임아웃이 설정된다. 수집된 스케줄 데이터는 출발항, 도착항, 예상 소요일, 선박명, 출항일 등으로 정규화된 후 API를 통해 플랫폼에 등록된다. 물류 담당자가 수동으로 스케줄을 입력할 필요가 없어져 업무 부담이 크게 줄었다.

8. AI 품질 평가 및 재처리 루프

Translator-Agent는 번역 품질을 BLEU 점수로 평가하고, 기준(0.75) 이하일 경우 재번역 요청 이벤트를 발행한다. Ops-Agent는 모든 번역 결과를 요약해 품질 리포트를 Telegram으로 전송한다. 품질 데이터는 주간 단위로 학습되어 Translator-Agent의 다음 번역에 반영된다.

*Crawler & Translator Report*
Source: TISI
Entries: 1,284
Valid: 1,271
Duplicates: 9
Avg BLEU: 0.82
Retries: 4
Processing Time: 17m 42s

보고서에는 크롤링 성능, 번역 정확도, 중복률, 평균 처리 시간 등이 포함된다. 관리자는 단순히 Telegram 메시지를 검토해 전체 수집 상태를 확인할 수 있다.

9. 다국어 인덱싱 및 검색 최적화

번역된 데이터는 Redis Search 인덱스로 자동 등록된다. 검색어는 사용자 언어에 따라 자동 변환되어 일관된 결과를 제공한다. 예를 들어 "전선 규격"을 검색하면 태국어 표준도 동일 결과로 노출된다.

FT.CREATE idx_standards
ON HASH
PREFIX 1 "std:"
SCHEMA name TEXT WEIGHT 2.0 description TEXT WEIGHT 1.0 lang TAG SORTABLE

검색 적중률은 언어별 평균 96% 이상이며, 크롤링된 데이터는 실시간으로 인덱스에 반영된다.

10. 결과 및 현재 상태

9월 기준, 크롤링 시스템은 환율 4개 은행, 해운 3개 선사, 인증 기관 12곳의 데이터를 자동 수집 중이다. 환율 데이터는 매일 갱신되어 플랫폼의 가격 계산에 즉시 반영되며, 해운 스케줄은 물류 일정 자동 배정의 기초 데이터로 활용된다.

평균 크롤링 성공률 98.6%
번역 품질 BLEU 0.82
중복 제거 정확도 99.3%
MQ 처리량 2,400 msg/sec
전체 파이프라인 지연 380ms
환율 갱신 주기: 매일 1회 (4개국 병렬)
해운 스케줄 갱신 주기: 월 1회 (3개 선사 순차)

크롤링 시스템의 핵심 가치는 외부 데이터 소스에 대한 의존성을 내재화한 것이다. 공공 기관이 API를 제공하지 않더라도, 은행이 환율 데이터를 별도로 연동해주지 않더라도, 플랫폼은 자체적으로 필요한 데이터를 수집하고 정규화하여 서비스에 반영한다. 이 구조 덕분에 REINDEERS는 외부 협력 없이도 글로벌 무역에 필요한 데이터를 확보할 수 있게 되었다.

Blog

Search This Blog