데이터와 자동화 — 요구조건을 만족시키는 '새로운' 플랫폼만이 해답이었다

1. 요구조건에서 시작한 '새 플랫폼' 선언

Quote → PO → Invoice → Delivery → Settlement 전체 흐름이 단일 데이터 체인으로 연결될 것
국가/언어/통화/세율/물류 규칙을 데이터 레이어에서 통합 관리할 것
데이터 변화가 이벤트(AMQP)를 통해 실시간 전파되고 캐시와 UI가 자동 갱신될 것
사람이 문서/툴을 조작하지 않아도 AI 워크플로우가 명세→스키마→API→배포를 자동 생성할 것

이 요구는 곧 플랫폼의 재정의였다. "코드가 데이터를 설명"하던 과거에서, "데이터가 코드를 지배하는" 구조로의 전환. 이 관점에서 전 계층을 다시 설계했다.

이 요구조건이 왜 기존 시스템으로는 충족될 수 없었는지를 구체적으로 짚어보자. 기존 시스템에서 견적(Quote)과 주문(PO)은 별개의 데이터 저장소에 관리되고 있었다. 견적서에 적힌 단가와 실제 주문에 반영된 단가가 일치하는지 확인하려면 두 개의 테이블을 수동으로 조인해야 했고, 그 과정에서 환율 변환 시점이 달라 금액 불일치가 발생하는 경우가 잦았다. 4개국(태국, 한국, 중국, 말레이시아)의 거래에서 THB, KRW, CNY, MYR, USD라는 5개 통화가 오가는 환경에서 이런 불일치는 단순한 기술 버그가 아니라 비즈니스 신뢰 문제였다.

2. 기존 시스템이 막혀 있던 구체적 지점들

패치로는 해결할 수 없었던 구조적 한계를 정리하면 다음과 같다.

다국어/다통화 하드코딩: i18n 텍스트가 프런트엔드 컴포넌트에 직접 삽입되어 있었다. 새 언어를 추가하려면 수백 개 파일을 수정해야 했다.
단일 리전 종속: 모든 데이터가 싱가포르 리전에 있어서, 태국 바이어와 한국 공급사 모두에게 네트워크 지연이 발생했다.
거래 흐름 단절: 견적, 주문, 인보이스, 선적, 정산이 각각 독립된 모듈로 되어 있어 하나의 거래를 추적하려면 여러 시스템을 오가야 했다.
수동 환율 반영: 환율이 자동으로 갱신되지 않고, 관리자가 수동으로 입력해야 했다. 4개국 환율을 매일 수동 관리하는 것은 운영 리스크 그 자체였다.
물류 추적 불가: 선적 정보가 별도의 스프레드시트로 관리되고 있어서, 바이어가 자신의 화물 상태를 실시간으로 확인할 수 없었다.

이 문제들은 각각 개별적으로 고칠 수 있는 것처럼 보이지만, 근본적으로 데이터 모델 자체가 "단일 국가, 단일 통화, 단일 언어"를 전제로 설계되어 있었다. 이 전제를 바꾸는 것은 리팩토링이 아니라 재설계를 의미했다.

3. 새로운 기술 스택 (Infra / Runtime / Automation / Security)

Infra & Network

홍콩(Primary), 서울(DR) 멀티 리전
DNSPod Geo Routing + Health Check
COS + CDN: 정적 자산 전세계 엣지 배포
컨테이너 오케스트레이션

Data & Messaging

DTS(GTID, Async) 리전 간 복제
Redis Cluster (Session/Cache, TTL 정책)
LavinMQ (AMQP 호환, Topic Exchange)

Automation

Drone CI/CD (self-hosted)
AI Workflow Engine (명령→DBML/Swagger→배포 자동화)
Cloud Functions (DTS/캐시/장애 대응)

Security & Observability

mTLS 내부 통신, JWT 서비스 인증
IAM/KMS 최소권한, Cloud Audit 추적성
Telegram 알림 + Grafana 대시보드

프런트는 Nuxt 3 + Vue 3, 서버는 내부 API 게이트웨이 뒤에서만 동작한다(백엔드는 비공개). 글로벌 접근은 DNSPod가 지역 엣지로 라우팅, 정적은 CDN, 동적은 Gateway로 분기된다.

4. 데이터 모델 — '의미 있는' 정규화

요구를 충족하려면 테이블 수가 늘어나는 게 목적이 아니라, 관계와 규칙이 데이터에 내재되어야 한다. 새 모델은 6계층으로 조직했다.

1. Master: 통화/세율/국가/언어
2. Partner: 고객/공급사/담당자
3. Transaction: Quote/PO/Invoice/Settlement
4. Logistics: 선적/통관/트래킹
5. Integration: 환율/외부 인증/웹훅
6. Audit: 변경 이력/접근 로그

이 6계층 구조가 해결하는 핵심 문제는 "새 국가를 추가할 때 코드를 건드리지 않아도 된다"는 것이다. Master 레이어에 국가 코드, 통화 코드, 언어 코드를 추가하면 하위 모든 레이어가 자동으로 해당 국가를 인식한다. 세율도 국가-카테고리 조합으로 Master에 정의되므로, 태국의 VAT 7%, 한국의 부가세 10%, 말레이시아의 SST 6% 같은 차이가 코드 수정 없이 데이터만으로 처리된다.

5. 데이터 마이그레이션 — 11년치 거래를 새 구조로

새 플랫폼을 만드는 것과 기존 데이터를 이전하는 것은 별개의 도전이었다. 2015년부터 축적된 25,000건 이상의 거래 데이터와 4,300개 이상의 파트너(바이어 2,500+, 공급사 1,800+, 포워더 30+) 정보를 새로운 6계층 구조로 옮겨야 했다.

마이그레이션 전략은 "Big Bang"이 아니라 "단계적 병행 운영"이었다. 먼저 Master 레이어(국가, 통화, 언어, 세율)를 마이그레이션하고, 다음으로 Partner 레이어를 이전한 후, 마지막으로 Transaction과 Logistics 데이터를 옮겼다. 각 단계에서 데이터 정합성 검증을 자동화된 스크립트로 수행했고, 불일치가 발견되면 즉시 원인을 추적하여 수정했다.

가장 까다로웠던 부분은 과거 거래의 환율 데이터였다. 기존 시스템에서는 환율이 거래 시점에 고정되지 않고 조회 시점의 환율이 적용되는 경우가 있었다. 이런 데이터를 새 구조로 옮길 때 "거래 시점의 환율"을 역추적하여 정확히 기록해야 했다. 이 작업만으로도 상당한 시간이 소요되었지만, 데이터 품질은 새 플랫폼의 신뢰성을 좌우하는 문제이므로 타협하지 않았다.

6. B2B 무역에서 '자동화'가 의미하는 것

B2C 이커머스의 자동화는 비교적 단순하다. 주문이 들어오면 결제 확인 후 배송을 시작하면 된다. B2B 무역의 자동화는 근본적으로 다르다.

하나의 거래에서 자동화되어야 하는 것들을 나열하면 이렇다. 환율 자동 수집(4개국 은행에서 매일 자동 크롤링), 견적서 다국어 자동 생성, 주문 확정 시 재고 자동 할당, 인보이스 자동 발행과 다통화 변환, 선적 스케줄 자동 조회(해운사 3곳의 스케줄을 크롤링), 통관 서류 자동 분류, 정산 시 환율 차이 자동 계산. 이 모든 단계에서 "사람이 스프레드시트를 열어 수동으로 처리"하던 것을 시스템이 이벤트 기반으로 자동 처리하도록 전환하는 것이 목표였다.

특히 환율 자동 수집은 핵심이었다. Bangkok Bank, Hana Bank(한국), Bank of China, Maybank(말레이시아)에서 매일 환율 데이터를 자동으로 수집하여 Master 레이어에 반영한다. 수집 실패 시 Telegram으로 즉시 알림이 가고, 5분간의 중복 알림 방지 쿨다운이 적용된다. 이전에는 관리자가 매일 아침 4개 은행 웹사이트를 직접 확인하고 환율을 입력했다. 이 단순한 자동화 하나로 일일 30분의 관리 시간과 입력 오류 리스크가 제거되었다.

7. 실시간 데이터 동기화 — DTS + Redis + MQ

핵심은 사람 개입 없는 일관성이다. 데이터 변경 → 이벤트 발행 → 캐시 무효화 → DR 복제 감시까지 자동.

# DTS (개념 구성)
Source: DB (ap-hongkong, Primary)
Target: DB (ap-seoul, DR)
Mode: Asynchronous (GTID)
LatencyThreshold: 500ms
Recovery: AutoResume

# Redis 캐시 정책
cache.hit_target = >= 80%
cache.ttl.default = 300s
session.ttl = 3600s

# MQ (Topic Exchange)
exchange: reindeers.global
bindings:
  - routing_key: order.created  -> queue: cache_invalidator
  - routing_key: invoice.updated -> queue: finance_worker
  - routing_key: exchange_rate.updated -> queue: rate_broadcaster

이 구조에서 Event + State + Log 모델이 어떻게 동작하는지 실제 예를 들어보자. 바이어가 주문을 확정하면: (1) State: 주문 테이블의 상태가 DRAFT에서 CONFIRMED로 변경된다. (2) Event: order.confirmed 이벤트가 MQ에 발행된다. (3) Log: Audit 레이어에 "누가, 언제, 어떤 주문을, 어떤 상태로 변경했는지"가 기록된다. 이 세 가지가 항상 함께 발생하고 분리 관리되기 때문에, 현재 상태 조회, 이력 추적, 다운스트림 서비스 연동이 모두 깔끔하게 처리된다.

8. AI 워크플로우 — 사람이 아닌 시스템이 명세를 만든다

"AI 워크플로우가 명세를 자동 생성한다"는 요구조건은 처음에는 과도해 보였다. 하지만 실제로 구현해보니 가장 생산성 향상에 기여한 부분이었다.

AI Workflow Engine은 자연어 명령을 받아 데이터 스키마(DBML), API 명세(OpenAPI/Swagger), 타입 정의를 자동 생성한다. 생성된 결과물은 사람이 검토하고 승인한 후에만 배포 파이프라인에 진입한다. 여기서 REINDEERS의 AI 철학이 적용된다: AI는 의사결정 보조자이지, 의사결정자가 아니다. AI가 만든 스키마를 그대로 사용하는 것이 아니라, AI가 초안을 만들고 사람이 검증하는 RAG 기반의 협업 구조다.

9. 보안 — '기본이 강한' 운영

mTLS 서비스 간 통신, Private Endpoint만 허용
JWT + 롤 기반 접근제어(RBAC)
IAM/KMS 최소권한 정책, 비밀은 런타임에서만 복호화
Cloud Audit 전 활동 추적, 변경 불가능(append-only) 저장
SSO/OIDC 5개 플랫폼 통합 인증, 파트너 역할별 권한 분리

10. 결론 — 왜 '새' 플랫폼만 정답인가

CEO의 요구는 "데이터로 비즈니스를 설명하고, 변화가 시스템을 자동으로 움직이는 구조"였다. 이를 만족하려면:

데이터가 전 구간에서 체인으로 연결되어야 한다.
국가/언어/통화/세율/물류 규칙이 데이터 레이어에서 일원화돼야 한다.
변화가 이벤트로 전파되어 캐시, UI, DR이 자동 갱신돼야 한다.
명세→스키마→API→배포가 AI 워크플로우로 자가 생성, 자가 검증돼야 한다.

기존 플랫폼 구조로는 이 요구를 달성할 수 없다. 그래서 우리는 인프라, 데이터, 자동화, 보안을 처음부터 다시 만들었다. 지금의 REINDEERS는 "사람이 문서를 쓰는 조직"이 아니라, "데이터가 시스템을 스스로 구성하는 플랫폼"이다. 2025년 12월 1일 공식 오픈 이후, 이 구조는 실제 운영에서 검증되고 있다.

Blog

Search This Blog