Skip to main content

글로벌 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건 이상의 실거래를 안정적으로 지원하는 기반이 되었다.

관련 글

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