Skip to main content

Posts

Showing posts with the label Tech

B2B 플랫폼의 결제·정산 구조 , 다국가·다통화 환경에서의 기술적 설계

돈이 움직이는 부분은 언제나 제일 어렵다. 코드를 짤 때도, 시스템을 설계할 때도, 운영을 할 때도. B2B 무역에서는 여기에 "다국가"와 "다통화"가 붙으면서 난이도가 한 단계 더 올라간다. REINDEERS는 태국, 한국, 중국, 말레이시아를 오가는 거래를 처리한다. 바이어는 태국 바트(THB)로 결제하고, 공급사는 중국 위안(CNY)으로 받고 싶어한다. 중간에 포워더는 한국 원(KRW)으로 물류비를 청구한다. 여기에 미국 달러(USD)가 기준 통화로 들어간다. 한 건의 거래에 통화가 3~4개 관여하는 게 일상이다. 이 글에서는 REINDEERS가 이 다통화 결제와 정산을 어떤 구조로 설계했는지를 기술적으로 풀어본다. 현재 운영 중인 환율 스크래퍼부터, 원장(Ledger) 기반 회계 구조, 이벤트 드리븐 정산 파이프라인까지. 그리고 이 구조가 왜 장기적으로 "재무 Agent"와 "통관 Agent"가 조직도 안에서 자율적으로 일할 수 있는 기반이 되는지도 함께 이야기한다. 왜 단순한 결제 연동으로는 안 되는가 국내 커머스의 결제는 비교적 단순하다. PG사(결제대행사) 하나 붙이고, KRW 단일 통화로 결제받고, 정산일에 수수료 뺀 금액을 판매자에게 보내면 된다. 결제와 정산이 동일 통화이고 동일 법역이다. 국제 B2B는 전혀 다른 세계다. 몇 가지 현실적 문제를 나열해보면 이렇다. 통화 변환 시점의 문제. 바이어가 THB로 결제하는 시점과, 공급사가 CNY로 받는 시점 사이에 시차가 있다. 빠르면 며칠, 느리면 한 달이다. 이 사이에 환율이 움직인다. 누가 이 환율 리스크를 지는가? 견적 시점의 환율을 쓰는가, 결제 시점을 쓰는가, 정산 시점을 쓰는가? 이 하나의 결정이 거래 수익률을 좌우한다. 국가별 PG 인프라의 차이. 태국은 PromptPay와 은행 이체가 주류다. 한국은 계좌이체와 카드 결제가 혼재한다. 중국은 위챗페이, 알리페이, 그리고 전...

B2B 플랫폼에서 멀티테넌시를 설계하는 방법 , DVRP와 POP의 격리 구조

4개국 법인과 다수 고객사의 데이터를 하나의 인프라에서 격리하면서 비용 효율과 보안을 동시에 달성하는 것 , 이 글은 REINDEERS의 DVRP(물류 배차 최적화)와 POP(생산 운영 플랫폼)에 적용된 멀티테넌시 아키텍처를 다룬다. 왜 공유 DB + Row-Level Security 모델을 선택했는지, 테넌트 컨텍스트가 시스템 전체에 어떻게 전파되는지, 다층 방어 구조가 어떤 원칙으로 설계되었는지, 그리고 4개국 규제 환경에서의 컴플라이언스 전략까지 정리한다. 한 가지를 먼저 덧붙인다. DVRP와 POP는 지금 AI로 전환되는 구조 위에 올라가고 있다. 사람은 전략과 방향을 결정하고, 실제 업무는 조직도 안에 등록된 AI Agent가 실행한다. 직원을 등록할 때 "사람", "AI Agent", "로봇" 중 선택할 수 있는 구조다. 이 구조에서 멀티테넌시는 "화면이 섞이지 않게 하는" 수준을 훨씬 뛰어넘는 의미를 갖는다. Agent가 사람 대신 데이터를 읽고 실행 결정을 내리기 때문에, 테넌트 격리가 깨지는 순간 "다른 회사의 구매 Agent가 우리 회사 데이터로 발주를 내렸다" 같은 재앙이 발생할 수 있다. 멀티테넌시는 AI 전환의 전제 조건이다. 멀티테넌시 3중 방어 구조 LAYER 1 API Gateway · 요청 인증 JWT 검증 · 테넌트 식별 · 역할 결정 ↓ LAYER 2 애플리케이션 · 테넌트 컨텍스트 주입 미들웨어가 모든 쿼리에 tenant_id 바인딩 ↓ LAYER 3 데이터베이스 · Row-Level Security tenant_id 불일치 행은 DB가 직접 차단 한 레이어가 뚫려도 다음 레이어에서 차단. 실수로 인한 데이터 유출 방지. 왜 멀티테넌시가 중요한가 REINDEERS는 두 개의 SaaS 플랫폼을 운영한다. DVRP 는 물류 회사를 위한 배차 최적화 시스템이고, POP 는 ...

DVRP 배차 최적화 엔진의 기술 구조 , 제약 기반 경로 계산과 AI 보정

배차 최적화는 말로 하면 단순하다. "트럭에 화물을 싣고 가장 효율적인 경로로 배송한다." 하지만 실제로 구현하면 조합 폭발이 일어나는 NP-hard 문제다. 50건의 배송을 8대의 트럭에 배정하는 경우의 수는 8의 50승에 가깝다. 모든 경우를 탐색해서 최적해를 찾는 건 현재의 컴퓨팅 파워로도 불가능하다. DVRP(Dynamic Vehicle Routing Problem)는 이 문제를 실시간으로, 현실의 제약 조건 하에서 풀어야 한다. 이 글은 REINDEERS DVRP의 경로 최적화 엔진이 어떤 구조로 설계되었는지, 어떤 제약 조건을 어떻게 처리하는지, 그리고 AI가 이 과정에서 어떤 역할을 하는지에 대한 기술적인 이야기다. 동시에, DVRP가 왜 단순한 최적화 엔진이 아니라 조직도에 등록될 "물류 Agent"의 심장이 되는지에 대한 이야기이기도 하다. 조금 더 정확히 말하면 이렇다. REINDEERS와 POP, DVRP는 지금 AI로 전환되는 구조 위에 올라서 있다. 사람은 "오늘 배송 방침"을 결정한다 , 비용 우선인지, 정시 배송 우선인지, 특정 고객 우선인지. 실제 배차와 재배차, 지연 대응, 운전자 지시는 조직도 안에 등록된 물류 Agent가 수행한다. DVRP 엔진은 이 물류 Agent의 "손과 발"에 해당한다. 제약 기반 계산이 Agent의 실행 엔진이고, 그 위에 AI 레이어가 "왜 이 결정인가"를 언어로 설명하는 층이다. VRP: 문제 정의 Vehicle Routing Problem(VRP)은 운영 연구(Operations Research)의 고전적인 문제다. 1959년 Dantzig와 Ramser가 처음 공식화한 이후로 60년 넘게 연구되었고, 아직도 완벽한 해법은 없다. NP-hard 문제이기 때문에 최적해를 보장하는 다항 시간 알고리즘이 존재하지 않는다. 기본 VRP는 이렇게 정의된다. 하나의 창고(depot)에서 출발하는...

AI Agent는 어떻게 업무를 대신하는가 — Reindeers AX 설계

AI가 "업무를 대신한다"는 말은 이제 누구나 한다. 문제는 구체적으로 어떻게인지를 설명하는 곳이 드물다는 거다. LLM이 텍스트를 잘 생성한다는 건 모두가 안다. 그런데 그 LLM이 실제로 발주서를 작성하고, 물류를 배정하고, 서류를 검증하려면 어떤 구조가 필요한가? 이 글은 REINDEERS에서 현재 설계 중인 AI Agent 시스템의 구조에 대한 이야기다. Phase 1 구현에 진입하는 단계이며, 여기서 설명하는 내용은 설계 방향과 목표 아키텍처다. 이 구조가 최종적으로 지향하는 모습부터 먼저 밝히겠다. REINDEERS·POP·DVRP는 지금 AI로 전환되는 구조 위에 올라서고 있다. 조직도 안에서 직원을 등록할 때 '사람', 'AI Agent', '로봇' 중 하나를 선택하는 구조다. 사람은 전략과 방향을 결정하고, 실제 업무는 조직도 안에 등록된 AI Agent가 수행한다. paperclip 같은 외부 AI 도구를 외부에서 연결하는 방식이 아니라, 회사 조직 구조 자체에 AI가 직원으로 편입되는 방식이다. 이 글은 그 AI 직원들이 실제로 업무를 실행하기 위해 시스템이 어떤 모습이어야 하는지에 대한 이야기다. REINDEERS에서는 이걸 AX라고 부른다. Agent Experience. UX가 사람이 시스템을 경험하는 방식이라면, AX는 AI Agent가 시스템 안에서 업무를 수행하는 방식이다. 사람을 위해 UI를 설계하듯, Agent를 위해 시스템의 인터페이스를 설계한다는 뜻이다. CEO Agent 지휘 체계 사용자 (사람) │ CEO Agent 전략 실행 · 자원 배분 · KPI │ 구매 Agent 발주·공급사 생산 Robot 계획·실행 영업 Human 견적·주문 물류 Robot 배차·운송 재무 Agent 정산·대금 통관 Agent HS·서류 사람은 전략만, AI Agent가 각 부서의 실제 업무를 ...