Blog

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인가 견적 업무가 느린 이유는 복잡해서가 아니다. 반복적인 정보 수집과 조합이 사람의 시간을 잡아먹기 때문이다. 공급사 담당자가 바이어의 과거 주문 이력을 ...

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 규제는 수시로 개정된다. 선사 운임은 매...

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