Skip to main content

i18n·다국어·다통화 엔진 및 DTS/Redis 일관성 구조

i18n·다국어·다통화 엔진 및 DTS/Redis 일관성 구조

1. 문제 정의 — "언어, 통화, 그리고 시간"

글로벌 플랫폼을 설계할 때 가장 어려운 점은 단순히 번역이 아니다. 사용자의 언어와 통화, 그리고 거래가 발생하는 시간대(timezone)가 동시에 일관성을 가져야 한다는 것이다. 태국 바이어가 THB(바트)로 주문을 생성하고, 한국 공급사가 KRW(원화) 기준으로 송장을 발행하면, 모든 계산은 "실제 결제일 환율"을 기준으로 변환되어야 한다. 시스템은 태국어·영어·한국어·중국어로 각각 동일한 상품 정보를 제공해야 하며, 어떤 리전에서 접속하더라도 동일한 데이터가 지연 없이 노출되어야 한다.

이 복잡성의 핵심은 세 가지 축이 서로 연결되어 있다는 점이다. 언어가 바뀌면 표시할 텍스트가 달라지고, 통화가 바뀌면 가격 계산 로직이 달라지며, 리전이 바뀌면 캐시 원본 위치가 달라진다. 하나라도 어긋나면 바이어가 보는 가격과 공급사가 받는 정산액이 불일치하는 사고로 이어진다. REINDEERS는 6월에 i18n + Currency + DTS + Redis 통합 구조를 완성하여 이 세 축을 하나의 파이프라인으로 묶었다.

2. i18n 엔진 — 언어 데이터의 추상화와 저장 전략

REINDEERS의 다국어(i18n) 엔진은 단순한 문자열 번역이 아니다. 언어 데이터는 모든 비즈니스 엔터티(Product, Category, Notice 등)와 독립적으로 관리된다. 상품 테이블에 직접 name_th, name_ko 컬럼을 두는 방식은 언어가 추가될 때마다 스키마를 변경해야 하므로 확장성이 없다. 대신 i18n_text 테이블을 도입하여 키-값 기반으로 모든 다국어 텍스트를 관리한다. 

CREATE TABLE i18n_text (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  key_name VARCHAR(255) NOT NULL,
  lang_code VARCHAR(5) NOT NULL,
  value TEXT NOT NULL,
  quality ENUM('MACHINE','HUMAN','APPROVED') DEFAULT 'MACHINE',
  updated_at DATETIME DEFAULT CURRENT_TIMESTAMP,
  UNIQUE (key_name, lang_code)
);

모든 다국어 텍스트는 "키(key_name)" 중심으로 관리된다. 예를 들어 상품명은 product.name.1001, 설명은 product.desc.1001 식으로 저장된다. 이 구조 덕분에 새 언어를 추가하려면 해당 lang_code의 행만 INSERT하면 된다. 스키마 변경은 전혀 필요 없다.

번역이 누락되면 Translator-Agent가 자동으로 기계 번역을 수행하고 품질 상태를 MACHINE으로 지정한다. 운영팀의 인적 검수 후 HUMAN으로 승격되고, 최종 승인 시 APPROVED로 변경되면 해당 키는 Redis 캐시에 고정된다. APPROVED 상태의 텍스트는 TTL 없이 영구 캐싱되어 DB 조회를 완전히 생략한다. 

# i18n 자동 번역 워크플로우
event: product.created
→ translator-agent.translate(key_name, source_lang)
→ i18n_text.insert(lang, value, quality='MACHINE')
→ publish("cache.invalidate", {"type":"i18n", "key": key_name})

API 응답 시에는 요청 헤더의 Accept-Language 값을 기준으로 해당 lang_code의 텍스트를 자동으로 선택한다. 클라이언트가 th를 보내면 태국어, ko를 보내면 한국어 데이터가 반환된다. 4개 언어(TH, KO, ZH, EN) 중 하나라도 누락된 키가 있으면 Translator-Agent가 이를 감지하여 비동기로 채워넣는 자가 보정 루프가 동작한다.

3. 다통화 처리 — 중앙은행 기준 환율 파이프라인

통화 데이터는 각국 중앙은행의 공시 환율을 기준으로 한다. 하루 1회 서버리스 함수가 각 중앙은행(BOT, BNM, PBoC, BOK) 사이트에서 환율 정보를 수집하고, 정규화 테이블에 저장한다. 4개국 환율을 하나의 통합 스키마로 관리하기 때문에 국가 추가 시에도 데이터 구조가 변하지 않는다. 

CREATE TABLE currency_rate_norm (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  base_currency CHAR(3) NOT NULL,
  quote_currency CHAR(3) NOT NULL,
  rate DECIMAL(20,10) NOT NULL,
  effective_at DATETIME NOT NULL,
  provenance JSON NOT NULL,
  UNIQUE (base_currency, quote_currency, effective_at)
);

각 환율 정보는 원본 HTML의 해시와 기관명을 provenance 필드에 기록한다. 이는 나중에 특정 환율 값의 출처를 역추적해야 할 때 사용된다. 수집 과정에서 각국 은행 웹사이트의 구조가 다르고, 안티봇 대책도 제각각이기 때문에 국가별로 별도의 스크래퍼가 동작한다.

환율이 저장되면 MQ를 통해 currency.updated 이벤트가 발행되고, 이를 구독하는 서비스들이 가격 표시를 자동 갱신한다. 바이어가 THB로 보는 가격과 공급사가 KRW로 보는 가격은 동일한 effective_at 기준 환율로 계산되므로 양쪽의 금액이 정확히 대응된다. 정산 시점과 주문 시점의 환율이 다를 경우, DTS(Distributed Transaction Sync) 모듈이 양쪽 리전에서 동일한 환율 스냅샷을 참조하도록 보장한다.

4. DTS — 리전 간 데이터 복제의 신뢰성 확보

REINDEERS는 홍콩(HK)을 Primary, 서울(KR)을 Secondary로 설정했다. 두 리전 간의 데이터 복제는 DTS(Data Transmission Service)를 기반으로 구성되며, 비동기 복제(Async GTID Mode)로 평균 지연은 350~500ms 수준이다. 이 지연은 일반적인 API 응답에는 영향을 주지 않지만, 결제나 정산처럼 두 리전의 데이터가 정확히 일치해야 하는 트랜잭션에서는 문제가 될 수 있다.

이를 해결하기 위해 DTS 모듈은 Cloud Function에서 지속적으로 모니터링된다. 지연이 500ms를 초과하면 자동으로 복제 재시작 명령이 실행되고, Telegram으로 알림이 발송된다. 지연이 2초를 초과하는 극단적 상황에서는 Secondary 리전의 쓰기가 자동 차단되어 데이터 불일치를 원천적으로 방지한다. 

def dts_guard(event):
    delay = event["dts_delay_ms"]
    if delay > 2000:
        set_readonly("kr-secondary")
        publish("alert", {"text": f"KR set read-only, delay {delay}ms", "level": "critical"})
    elif delay > 500:
        resume_dts("hk-seoul")
        publish("alert", {"text": f"DTS Delay {delay}ms, resuming", "level": "warn"})

DTS 상태 데이터는 매 5분마다 집계되어 dts_health_log 테이블에 기록된다. 운영자는 Telegram 명령 /dts로 현재 지연 시간, 복제 상태, 최근 장애 이력을 즉시 확인할 수 있다. 이 자동 복구 루틴은 인프라의 인간 의존도를 크게 줄여주었고, 실제 운영에서 DTS 관련 수동 개입은 월 평균 1회 미만으로 감소했다.

5. Redis 일관성 — Write-through + Event-driven Invalidation

Redis는 리전별 캐시 역할을 담당한다. 데이터는 Write-through 방식으로 저장된다. 즉, DB에 쓰기가 발생하면 동시에 Redis에도 동일 데이터가 기록되고, MQ를 통해 cache.invalidate 이벤트가 발행되어 반대 리전의 캐시도 무효화되거나 최신 상태로 동기화된다. 

import redis, pika, json

r = redis.StrictRedis(host="redis.ap.hk", port=6379)
ch = pika.BlockingConnection(pika.ConnectionParameters("mq.ap.hk")).channel()
ch.queue_declare(queue="cache_invalidator", durable=True)

def on_message(ch, method, _, body):
    evt = json.loads(body)
    r.delete(f"cache:{evt['table']}:{evt['id']}")
    ch.basic_ack(method.delivery_tag)

ch.basic_consume(queue="cache_invalidator", on_message_callback=on_message)
ch.start_consuming()

캐시 키는 cache:{table}:{id} 패턴을 사용한다. MQ 메시지에는 idempotency-key 헤더가 추가되어 동일한 이벤트가 중복 실행되지 않도록 한다. Redis TTL은 일반 데이터 15분, i18n APPROVED 데이터는 무기한으로 차등 적용된다.

캐시 미스가 발생하면 DB에서 조회한 후 Redis에 다시 적재하는 Cache-Aside 패턴이 보조적으로 동작한다. Cross-region 시나리오에서는 HK 리전의 캐시가 Primary 역할을 하고, KR 리전은 MQ 이벤트를 통해 수백 밀리초 내에 동기화된다. 캐시 적중률은 평균 96% 이상을 유지하며, 적중 실패 시에도 DB fallback 경로가 300ms 이내에 응답을 반환한다.

6. 검증 루틴 — 데이터·언어·환율의 삼중 동기화 테스트

데이터 검증은 세 가지 관점에서 수행된다.

  1. 데이터 정합성: DTS 복제 후 rowcount/CRC 비교. Primary와 Secondary의 테이블별 행 수와 체크섬을 대조하여 복제 누락을 탐지한다.
  2. 언어 일관성: 각 언어별 키 누락 검사. 4개 언어 중 하나라도 빠진 키가 있으면 Translator-Agent에 재번역 이벤트를 발행한다.
  3. 환율 정확성: 삼각검증 USD→KRW→THB 경로와 USD→THB 직접 경로의 오차율이 20bps 이하인지 확인한다. 초과 시 해당 환율 데이터를 무효 처리하고 재수집을 트리거한다.
-- 언어 키 누락 검사
SELECT key_name FROM i18n_text
GROUP BY key_name HAVING COUNT(DISTINCT lang_code) < 4;

-- 삼각 환율 검증
SELECT ABS(
  (SELECT rate FROM currency_rate_norm WHERE base_currency='USD' AND quote_currency='THB' ORDER BY effective_at DESC LIMIT 1)
  -
  (SELECT rate FROM currency_rate_norm WHERE base_currency='USD' AND quote_currency='KRW' ORDER BY effective_at DESC LIMIT 1)
  *
  (SELECT rate FROM currency_rate_norm WHERE base_currency='KRW' AND quote_currency='THB' ORDER BY effective_at DESC LIMIT 1)
) AS triangular_gap;

검증 결과는 data_quality_check 테이블에 기록되며, CI/CD 파이프라인에서 매 배포 전 자동 실행된다. 오류 발생 시 Telegram 알림이 발송되고 배포가 차단된다. 이 삼중 검증 체계가 가동된 이후, 환율 관련 정산 오류는 0건을 유지하고 있다.

7. 결론 — "Localization을 넘은 Systemization"

많은 글로벌 플랫폼이 언어나 통화 문제를 '현지화(Localization)'로 다룬다. 하지만 REINDEERS는 접근 방식이 다르다. 우리는 현지화가 아니라 "Systemization"을 선택했다. 즉, 시스템 자체가 다국어·다통화를 처리하도록 구조화한 것이다.

이번 개편으로, 다국어 문장 하나가 누락되어도 시스템이 자동으로 번역을 생성하고, 환율이 변동되면 자동으로 정산 금액을 재계산하며, Redis는 지역 간 일관성을 유지하면서 캐시를 자동으로 교체한다. DTS는 리전 간 복제 지연을 스스로 감시하고 복구한다. 사람이 개입해야 하는 지점은 최종 번역 승인과 환율 이상 알림 확인, 이 두 가지뿐이다.

5개 플랫폼, 4개 국가, 4개 언어, 4개 통화가 하나의 파이프라인 위에서 동작한다. 6월은 REINDEERS가 "사람이 아니라 시스템이 운영을 보정하는 구조"로 진화한 달이었다.

관련 글

Labels:

Popular posts from this blog

11년의 무역 데이터가 AI를 만든다 , RAG 지식 베이스 구축 과정

AI를 제품에 넣겠다고 하면 대부분 두 가지 중 하나를 떠올린다. GPT를 fine-tuning하거나, RAG를 쓰거나. 우리는 RAG를 택했다. 이유가 있다. REINDEERS는 2015년 IMARKET Thailand 설립 이후 약 11년간 동남아시아에서 B2B 무역을 해왔다. 25,000건 이상의 거래, 4,300개 이상의 파트너, 4개국의 규제 데이터. 이 데이터가 우리의 경쟁력이다. 문제는 이 데이터를 AI가 활용할 수 있는 형태로 만드는 과정이 생각보다 훨씬 복잡했다는 거다. 이 글은 그 과정에 대한 기록이다. 한 가지를 먼저 밝히고 시작한다. 이 RAG 지식 베이스는 단순히 "챗봇이 무역 지식을 참조하는 데이터 창고"가 아니다. REINDEERS와 POP, DVRP는 지금 AI로 전환되는 구조 위에 올라서 있다. 사람은 전략과 방향을 결정하고, 실제 업무는 조직도 안에 등록된 AI Agent가 수행한다. 이 Agent들 , 구매 Agent, 물류 Agent, 통관 Agent, 재무 Agent , 이 사람 대신 판단을 내릴 때 "왜 이렇게 결정했는가"를 반드시 설명할 수 있어야 한다. 그 설명의 출처가 바로 이 RAG 지식 베이스다. 11년의 무역 데이터는 Agent가 환각 없이 결정을 내릴 수 있는 유일한 근거다. RAG를 선택한 이유 먼저 RAG(Retrieval-Augmented Generation)가 뭔지를 간단히 정리하자. LLM에 질문을 던질 때, 질문만 보내는 게 아니라 관련 데이터를 함께 보내는 방식이다. "태국산 베어링 수입 단가가 얼마야?"라고 물으면, 우리 데이터베이스에서 관련 거래 이력을 찾아서 LLM에 컨텍스트로 넘긴다. LLM은 그 컨텍스트를 바탕으로 답을 생성한다. Fine-tuning을 선택하지 않은 이유는 명확하다. 무역 데이터는 계속 바뀐다. 베어링 단가는 분기마다 변동한다. 태국 FDA 규제는 수시로 개정된다. 선사 운임은 매...
Read more

B2B 견적의 AI Agent화 , 고객사·공급사·포워더가 AI로 견적을 주고받는 구조

B2B 거래에서 견적은 단순한 가격표가 아니다. 바이어의 구매 이력, 공급사의 재고 상황, 물류 비용, 인코텀즈, 납기일, 결제 조건 , 이 모든 변수가 얽힌 협상의 산물이다. 현재 이 과정은 이메일과 전화, 스프레드시트로 이루어진다. 바이어가 RFQ를 보내면 공급사가 검토하고, 포워더에게 물류 견적을 받아 합산하고, 다시 바이어에게 회신한다. 건당 수일이 걸리는 이 과정을 AI Agent가 대신할 수 있다면 어떨까. REINDEERS는 이 구조를 설계하고 있다. 먼저 이 글의 전제를 분명히 한다. REINDEERS·POP·DVRP는 지금 AI로 전환되는 구조 위에 올라서 있다. 조직도 안에서 직원을 등록할 때 '사람', 'AI Agent', '로봇' 중에서 선택할 수 있고, 사람은 전략과 방향을 결정하고, 실제 업무는 조직도 안에 등록된 AI Agent가 수행한다. 이 글의 Buyer Agent / Supplier Agent / Forwarder Agent는 외부 AI 도구가 아니라, 각 회사의 조직도 안에 '구매팀 담당자', '영업팀 담당자', '물류팀 담당자'로 실제 등록되는 AI 직원이다. 사람 직원과 동일한 권한 모델, 동일한 예산 한도, 동일한 감사 로그 위에서 일한다. B2B 견적의 AI Agent 간 통신 시퀀스 # Buyer Agent → Supplier Agent → Forwarder Agent 1 RFQ 발송 → RFQ 수신 2 물류 견적 요청 → 요청 수신 3 견적 수신 ← 상품 견적 발송 4 물류 견적 수신 ← 물류 견적 발송 ★ 비교표 생성 → 담당자 승인 5 PO 발행 → 주문 확정 6 부킹 요청 → 부킹 확정 왜 견적에 AI Agent인가 견적 업무가 느린 이유는 복잡해서가 아니다. 반복적인 정보 수집과 조합이 사람의 시간을 잡아먹기 때문이다. 공급사 담당자가 바이어의 과거 주문 이력을 ...
Read more

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