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

요약: REINDEERS의 글로벌화를 가능하게 한 핵심은 단순히 데이터베이스 확장이 아니었다. 언어(i18n)·통화(currency)·데이터 일관성(DTS/Redis)이 완벽하게 연결된 하나의 기술 체계였다. 이번 편에서는 다국어/다통화 엔진의 내부 구조와, 홍콩-서울 리전 간 동기화 및 캐시 일관성을 유지하는 기술을 다룬다.

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

글로벌 플랫폼을 설계할 때 가장 어려운 점은 단순히 번역이 아니다. 사용자의 언어와 통화, 그리고 거래가 발생하는 시간대(timezone)가 동시에 일관성을 가져야 한다는 것이다.

예를 들어, 태국 고객이 THB(바트)로 주문을 생성하고, 한국 공급사가 KRW(원화) 기준으로 송장을 발행하면, 모든 계산은 “실제 결제일 환율”을 기준으로 변환되어야 한다. 또, 시스템은 태국어·영어·한국어로 각각 동일한 상품 정보를 제공해야 한다. 이 복잡성을 해결하기 위해 REINDEERS는 6월에 **i18n + Currency + DTS + Redis** 통합 구조를 완성했다.

2. i18n 엔진 — 언어 데이터의 추상화

REINDEERS의 다국어(i18n) 엔진은 단순한 문자열 번역이 아니다. 언어 데이터는 모든 비즈니스 엔터티(Product, Category, Notice 등)와 독립적으로 관리된다. 이를 위해 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 식으로 저장된다. 번역이 누락되면 Translator-Agent가 자동으로 기계 번역을 수행하고 품질 상태를 MACHINE으로 지정한다. 인적 검수 후 APPROVED로 승격되면, 해당 키는 캐시에 고정된다.

# pseudo workflow
event: product.created
→ translator-agent.translate(key_name)
→ i18n_text.insert(lang, value, quality='MACHINE')
→ publish("cache.invalidate", {"type":"i18n", "key":key_name})

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

통화 데이터는 각국 중앙은행의 환율 기준을 사용한다. 하루 1회 Playwright를 통해 각 중앙은행(BOT, BNM, PBoC, BOK) 사이트에서 환율 정보를 수집하고, 정규화 테이블에 저장한다.

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에 기록한다. 이렇게 저장된 환율은 API 호출 시 실시간 계산에 사용되며, 가격 표시와 정산 시점이 다를 경우 DTS 동기화를 통해 정확히 일치한다.

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

REINDEERS는 홍콩(HK)을 Primary, 서울(KR)을 Secondary로 설정했다. 두 리전 간의 데이터 복제는 Tencent DTS를 기반으로 구성되며, 비동기 복제(Async GTID Mode)로 평균 지연은 350~500ms 수준이다.

DTS 모듈은 Cloud Function에서 모니터링되며, 지연이 500ms를 초과하면 자동으로 복제 재시작 명령을 실행한다.

def dts_guard(event):
    if event["dts_delay_ms"] > 500:
        resume_dts("hk-seoul")
        publish("alert", {"text": f"DTS Delay {event['dts_delay_ms']}ms"})

지연 상황이 감지되면 경고가 Slack으로 발송되며, 필요 시 읽기 전용 모드로 자동 전환된다. 이러한 “자동 복구 루틴”은 인프라의 인간 의존도를 줄여주었다.

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

Redis는 리전별 캐시 역할을 담당한다. 데이터는 Write-through 방식으로 저장되며, DB에 변경이 발생할 때마다 MQ 이벤트를 발행해 캐시를 무효화하거나 최신 상태로 동기화한다.

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)  # {table, id}
    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()

캐시 키는 “table:id” 패턴을 사용하고, MQ 메시지에는 idempotency-key 헤더가 추가되어 동일한 이벤트가 중복 실행되지 않도록 한다. Redis TTL은 15분이며, 지역별 리플리케이션으로 서울 리전에서도 실시간 일관성이 유지된다.

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

6월 말 기준으로, 데이터 검증은 세 가지 관점에서 수행된다.

데이터 정합성: DTS 복제 후 rowcount/CRC 비교
언어 일관성: 각 언어별 키 누락 검사 (SELECT key_name FROM i18n_text GROUP BY key_name HAVING COUNT(*) < 5)
환율 정확성: 삼각검증 USD↔KRW↔THB 오차율 ≤ 20bps

검증 결과는 data_quality_check 테이블에 기록되며, Drone CI 파이프라인에서 자동 실행된다. 오류 발생 시 Slack 알림을 발송하고 배포가 차단된다.

7. 결론 — “Localization을 넘은 Systemization”

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

이번 개편으로, 다국어 문장 하나가 누락되어도 시스템은 스스로 번역을 생성하고, 환율이 변동되면 자동으로 정산 금액을 재계산하며, Redis는 지역 간 일관성을 유지하면서 캐시를 자동으로 교체한다. 6월은 REINDEERS가 “사람이 아니라 시스템이 운영을 보정하는 구조”로 진화한 달이었다.

Blog of Reindeers

Search This Blog