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

REINDEERS TECH CHRONICLES

요약: 2025년 6월, REINDEERS 개발팀은 플랫폼의 핵심 구조를 완전히 재설계했다. 목표는 단순했다 — “다국가, 다언어, 다통화를 단일 DB 모델 안에서 일관성 있게 운영하자.” 그 결과, 총 250개 이상의 테이블이 계층적 레이어로 구분되었고, 각 레이어는 서로 독립적으로 확장 가능한 구조로 설계되었다.

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

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

특히, PO(구매 주문)와 Invoice(송장) 간 데이터 일관성이 보장되지 않아, 회계/정산 단계에서 오류가 빈번하게 발생했다. CEO가 제시한 요구사항은 간단했지만 깊었다. “데이터의 출발점이 한국이 아니라, 세계 어디서든 동일한 구조로 작동해야 한다.” 이 한 문장이 전체 리디자인의 기준이 되었다.

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

DB 구조는 기능적 목적에 따라 6개의 계층으로 나뉘었다. 각 계층은 물리적으로 같은 MySQL 인스턴스 내에 존재하지만, 논리적으로는 독립된 스키마로 분리되어 있다.

Layer-M: Master — 국가, 통화, 세율, 언어 등 글로벌 기준값
Layer-P: Partner — 고객사/공급사, 연락처, 계약정보
Layer-T: Transaction — 견적(Quote), 주문(PO), 송장, 정산
Layer-L: Logistics — 운송, 선적, 통관, 운임
Layer-I: Integration — 외부 연동 (환율, 세관, 결제 게이트웨이)
Layer-A: Audit — 변경 이력, 접근 로그, 승인 흐름

이 구조는 데이터가 “비즈니스 단위별로 독립적으로 확장되며, 동시에 글로벌 공통 규칙을 유지”하도록 설계되었다.

3. 핵심 테이블 설계 예시

CREATE TABLE currency_master (
  code CHAR(3) PRIMARY KEY,
  symbol VARCHAR(8) NOT NULL,
  country_code CHAR(2) NOT NULL,
  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,
  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 표준을 따른다.

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

테이블이 250개로 확장되면 수동 검증은 불가능하다. 그래서 데이터 품질 관리에는 자동화된 검증 루틴이 도입되었다.

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을 통해 즉시 보고된다. 데이터가 많아질수록 “정합성의 자동화”는 필수였다.

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

REINDEERS의 인프라는 홍콩(주 서버)과 서울(보조 서버) 간 비동기 복제를 사용한다. DTS(Distributed Transmission Service)는 초당 10만 트랜잭션 수준에서도 안정적으로 동작해야 한다.

Redis는 이중화된 캐시로서, 읽기 부하를 분산하고 각 리전별 조회 성능을 80% 이상 향상시켰다. 모든 DB write 후에는 MQ 이벤트가 발행되고, 해당 키를 캐시에서 무효화한다.

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는 자동으로 새로운 지역을 지원한다.

이것이 바로 REINDEERS가 지향하는 데이터 중심 구조다. “코드를 줄이고, 데이터가 규칙을 말하게 하라.” 6월은 바로 그 철학이 기술로 구현된 시점이었다.

Blog of Reindeers

Search This Blog