글로벌 DB 레이어링과 데이터 구조 재설계

1. 데이터 구조 개편의 배경

기존 구조는 AWS 싱가포르 단일 리전에 집중되어 있었고, 데이터 테이블은 약 50~60개 수준이었다. 문제는 명확했다. 각국의 통화, 언어, 세율, 운송 단가 등이 모두 하드코딩되어 있었고, 국가별 운영 정책에 맞춘 데이터 확장이 사실상 불가능했다.

특히, PO(구매 주문)와 Invoice(송장) 간 데이터 일관성이 보장되지 않아, 회계/정산 단계에서 오류가 빈번하게 발생했다. 예를 들어, 태국 바트화로 생성된 PO에 한국 원화 기준의 환율이 잘못 적용되거나, 말레이시아 링깃의 세율 계산에 태국 VAT 7%가 적용되는 경우가 있었다. 이런 문제들은 코드 레벨의 패치로는 해결할 수 없었다. CEO가 제시한 요구사항은 간단했지만 깊었다. "데이터의 출발점이 한국이 아니라, 세계 어디서든 동일한 구조로 작동해야 한다." 이 한 문장이 전체 리디자인의 기준이 되었다.

REINDEERS는 한국, 태국, 말레이시아, 중국 4개국에 법인을 두고 있고, 4,300개 이상의 파트너사가 이 플랫폼을 사용한다. 바이어 2,500개 이상, 공급사 1,800개 이상, 포워더 30개 이상이 각기 다른 통화와 언어로 거래를 진행하는 상황에서, 단일 국가 기준의 데이터 구조는 한계에 도달해 있었다.

2. 6-Layer Architecture: 데이터의 논리적 분리

DB 구조는 기능적 목적에 따라 6개의 계층으로 나뉘었다. 각 계층은 물리적으로 같은 MySQL 인스턴스 내에 존재하지만, 논리적으로는 독립된 스키마로 분리되어 있다. 이 분리의 핵심 원칙은 "변경 빈도가 다른 데이터는 같은 계층에 두지 않는다"는 것이었다.

Layer-M: Master — 국가, 통화, 세율, 언어 등 글로벌 기준값. 변경 빈도가 가장 낮다.
Layer-P: Partner — 고객사/공급사, 연락처, 계약정보. 주 단위로 변경될 수 있다.
Layer-T: Transaction — 견적(Quote), 주문(PO), 송장, 정산. 매일 수백~수천 건 생성.
Layer-L: Logistics — 운송, 선적, 통관, 운임. 물류 실행 데이터를 담당.
Layer-I: Integration — 외부 연동 (환율, 세관, 결제 게이트웨이). API 응답 캐시 포함.
Layer-A: Audit — 변경 이력, 접근 로그, 승인 흐름. 모든 계층의 이력을 기록.

이 구조는 데이터가 "비즈니스 단위별로 독립적으로 확장되며, 동시에 글로벌 공통 규칙을 유지"하도록 설계되었다. 실제로 이 구조 덕분에 새로운 국가를 추가할 때 변경이 필요한 테이블 수가 기존 30개 이상에서 3~5개로 줄었다. Layer-M에 국가/통화/세율 기준값만 추가하면 나머지 계층은 자동으로 적용된다.

3. 핵심 테이블 설계 예시

CREATE TABLE currency_master (
  code CHAR(3) PRIMARY KEY,        -- ISO 4217 코드
  symbol VARCHAR(8) NOT NULL,       -- ₩, ฿, RM, ¥
  country_code CHAR(2) NOT NULL,    -- ISO 3166-1 alpha-2
  exchange_rate DECIMAL(20,10) NOT NULL,
  updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE customer_company (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(255) NOT NULL,
  country_code CHAR(2) NOT NULL,
  currency_code CHAR(3) NOT NULL,
  language_code VARCHAR(5) NOT NULL, -- ko, th, zh-CN, en
  status ENUM('ACTIVE','SUSPENDED') DEFAULT 'ACTIVE',
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (currency_code) REFERENCES currency_master(code)
);

CREATE TABLE order_po (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  customer_id BIGINT NOT NULL,
  supplier_id BIGINT NOT NULL,
  po_number VARCHAR(50) UNIQUE,
  quote_ref VARCHAR(50),
  total_amount DECIMAL(18,2),
  currency CHAR(3),
  status ENUM('DRAFT','CONFIRMED','SHIPPED','CLOSED') DEFAULT 'DRAFT',
  FOREIGN KEY (customer_id) REFERENCES customer_company(id)
);

모든 테이블은 UTC 타임스탬프 기반으로 저장되며, 모든 수치 데이터는 DECIMAL(20,10) 고정 포맷으로 처리된다. 통화, 언어, 국가코드는 ISO 표준을 따른다. float나 double을 사용하지 않는 이유는 금융 데이터에서 부동소수점 오차가 정산 단계에서 실질적인 차이를 만들기 때문이다. 실제로 이전 구조에서 float 사용으로 인해 수백 원 단위의 정산 오차가 월 수십 건씩 발생했고, 이를 수동으로 보정하는 데 불필요한 시간이 소요되었다.

4. 데이터 품질 관리와 자동 검증

테이블이 250개로 확장되면 수동 검증은 불가능하다. 그래서 데이터 품질 관리에는 자동화된 검증 루틴이 도입되었다. 각 테이블별로 필수 필드 누락, 참조 무결성 위반, 비정상 값 등을 체크하는 검증 쿼리를 등록하고, CI/CD 파이프라인에서 매 배포 시 자동 실행한다.

CREATE TABLE data_quality_check (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  table_name VARCHAR(128),
  check_name VARCHAR(128),
  check_sql TEXT,
  severity ENUM('WARN','ERROR'),
  last_run DATETIME,
  result TEXT
);

INSERT INTO data_quality_check (table_name, check_name, check_sql, severity)
VALUES ('order_po', 'missing_currency',
        'SELECT COUNT(*) FROM order_po WHERE currency IS NULL', 'ERROR');

이 스크립트는 Drone CI 파이프라인에서 자동 실행되며, 실패 시 Slack Webhook을 통해 즉시 보고된다. severity가 ERROR인 검증이 실패하면 배포가 자동으로 중단된다. WARN 수준의 경우 알림만 전송되고 배포는 진행된다. 현재 등록된 검증 쿼리는 약 120개이며, 평균 실행 시간은 테이블 크기에 따라 2~15초이다. 데이터가 많아질수록 "정합성의 자동화"는 필수였다.

5. DTS 동기화와 Redis 캐시의 공존

REINDEERS의 인프라는 홍콩(주 서버)과 서울(보조 서버) 간 비동기 복제를 사용한다. DTS(Distributed Transmission Service)는 초당 10만 트랜잭션 수준에서도 안정적으로 동작해야 한다. 홍콩에서 서울까지의 복제 지연은 평균 200~500ms 수준이며, 이 지연이 사용자 경험에 영향을 주지 않도록 설계되었다.

Redis는 이중화된 캐시로서, 읽기 부하를 분산하고 각 리전별 조회 성능을 80% 이상 향상시켰다. 모든 DB write 후에는 MQ 이벤트가 발행되고, 해당 키를 캐시에서 무효화한다. 캐시 무효화 전략은 "Write-Through" 방식이 아니라 "Cache-Aside + Event-based Invalidation" 방식을 사용한다. DB에 쓰기가 발생하면 MQ 이벤트가 발행되고, 구독자가 해당 캐시 키를 삭제한다. 다음 읽기 요청 시 캐시 미스가 발생하면 DB에서 최신 데이터를 읽어 캐시에 다시 적재한다.

import pika, redis, json

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

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

mq.basic_consume(queue="cache_invalidate", on_message_callback=on_message)
mq.start_consuming()

6. 결과 — "데이터가 시스템을 움직인다"

이 개편 이후, 시스템은 더 이상 코드를 중심으로 움직이지 않는다. 데이터 그 자체가 로직을 정의하고, 모든 기능은 이 데이터에 종속된다. 예를 들어, 새로운 국가를 추가하려면 단순히 country_master에 레코드를 삽입하고 language_code를 지정하면 된다. 그 즉시 API와 UI는 자동으로 새로운 지역을 지원한다.

6-Layer 구조 도입 전과 후를 비교하면 차이가 명확하다. 테이블 수는 60개에서 250개로 늘었지만, 신규 국가 추가에 필요한 작업 시간은 2주에서 2일로 줄었다. 정산 오류는 월 50건 이상에서 0건으로 감소했다. 데이터 검증 커버리지는 0%에서 95% 이상으로 올라갔다.

이것이 바로 REINDEERS가 지향하는 데이터 중심 구조다. 코드를 줄이고, 데이터가 규칙을 말하게 한다. 6월은 바로 그 철학이 기술로 구현된 시점이었다. 이후 REINDEERS가 2025년 12월 공식 오픈을 맞이했을 때, 이 데이터 구조는 4개국, 4,300개 이상의 파트너사, 25,000건 이상의 실거래를 안정적으로 지원하는 기반이 되었다.

Blog

Search This Blog