Blog

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

 우리 팀에서는 하루에 한 번 이상 이런 대화가 오갔다. "이 주문 상태가 왜 DVRP에서는 '배송중'인데 REINDEERS 본체에서는 '결제완료'로 남아있어요?" "Document AI에서 생성된 인보이스가 Workflow에서 승인된 건 맞는데, 그게 실제 거래 시스템에 반영됐는지 어떻게 확인하죠?" 5개 플랫폼을 동시에 운영하는 팀이라면 이런 질문이 매일 나올 수밖에 없다. REINDEERS(거래), DVRP(물류), POP(생산), Document AI(문서), Workflow AI(업무 자동화). 각각 다른 도메인을 담당하지만, 결국 하나의 거래 흐름 위에서 동작하는 플랫폼들이다. 문제는 이 플랫폼들이 각자의 방식으로 데이터를 관리하고 있었다는 것이다. 이 문제가 단순한 개발자의 디버깅 고충에 그쳤다면, 우리는 지금처럼 데이터 모델을 처음부터 다시 설계하지 않았을 것이다. 우리가 Event+State+Log로 전부 밀어버린 진짜 이유는 따로 있다. REINDEERS·POP·DVRP는 지금 AI로 전환되는 구조 위에 올라서고 있다. 조직도 안에 사람과 AI Agent, 로봇이 같이 직원으로 등록되고, 사람은 전략과 방향을 결정하고, 반복 업무는 AI Agent가 실행한다. Agent가 실행을 하려면 "지금 이 주문이 어느 단계에 있고, 왜 그렇게 됐는가"를 사람의 도움 없이 스스로 읽을 수 있어야 한다. 플랫폼마다 데이터 포맷이 다르면 Agent가 읽을 수 없다. 그래서 모델 통일이 AI 전환의 전제 조건이었다. Event Sourcing — Append-only 로그에서 State 재계산 Event Log (시간순) E1 created → E2 paid → E3 shipped → E4 arrived → E5 received → E6 settled ↓ Current State = fold(E1, E...

REINDEERS가 처음 시작된 건 태국에서 한국 산업 자재를 수입하는 B2B 무역이었다. 그때는 아무도 이걸 "데이터 회사"라고 부르지 않았다. 바이어와 공급사를 연결하고, 견적을 주고받고, 물류를 관리하는 무역 중개 플랫폼이었다. 11년이 지났다. 25,000건 이상의 거래, 4,300개 이상의 파트너사, 태국-한국-중국-말레이시아 4개국에 걸친 무역 데이터가 플랫폼 안에 쌓였다. 그리고 어느 시점부터 이 데이터 자체가 플랫폼의 가치를 결정하는 핵심 자산이 되기 시작했다. 기능은 복제할 수 있다. 그러나 11년간 축적된 동남아 산업 무역 데이터는 복제할 수 없다. 최근 1년 동안 이 데이터의 용도가 한 단계 더 바뀌었다. 이전까지 데이터는 '더 좋은 추천'을 만드는 연료였다. 지금 이 데이터는 'AI Agent가 사람 대신 업무를 실행할 수 있게 하는' 연료다. REINDEERS와 POP, DVRP는 지금 AI로 전환되는 구조 위에 올라서 있다. 사람은 전략과 방향을 결정하고, 실제 업무는 조직도 안에 등록된 AI Agent가 실행한다. 이 전환은 데이터가 없으면 시작조차 할 수 없다. 그래서 데이터 플라이휠의 의미가 단순히 "추천 정확도"에서 "AI Agent의 판단 근거"로 넘어간다. REINDEERS 데이터 플라이휠 거래 → 데이터 → AI → 인사이트 → 다시 거래. 네 단계가 순환하며 자기 강화. 1 거래 실행 REINDEERS 거래 플랫폼 · DVRP 물류 · POP 운영 · 실제 B2B 거래가 일어난다 ↓ 2 데이터 축적 모든 이벤트 · 상태 · 로그가 append-only로 기록된다 (11년 × 25,000+ 실거래) ↓ 3 AI 학습 · 판단 도메인 특화 모델이 환각 없이 판단 · AI Agent가 실제 업무 실행 ↓ 4 인사이트 제공 가격 · 공급 · 경로 추천 · 파트너...

올해 1분기, 이상한 일이 반복됐다. REINDEERS 영업팀 미팅 로그를 보면 동남아 제조·유통 기업들로부터 컨설팅 요청이 쏟아지고 있었는데, 내용이 기대와 달랐다. B2B 거래 플랫폼 문의가 아니었다. "REINDEERS가 쓰고 있다는 AI, 우리도 적용할 수 있나요?" 태국 식품 가공업체, 말레이시아 부품 제조사, 중국 원자재 무역상까지. 업종은 제각각인데 질문은 같았다. 처음에는 단순히 AI 트렌드에 편승한 문의라고 생각했다. 요즘 어디서나 AI 이야기가 나오니까. 하지만 미팅을 직접 다녀 보면 상황이 달랐다. 그들은 막연한 호기심이 아니라 구체적인 고통을 가지고 있었다. 그리고 그 고통의 근원을 추적해 보면, 놀랍도록 동일한 지점에서 출발하고 있었다. 미리 한 가지를 짚고 가자. POP는 단순한 MES+ERP+WMS SaaS가 아니다. 우리가 설계한 것은 회사 운영 자체가 AI로 전환되는 구조 다. 사람은 결정과 방향을 제시하고, 실제 업무는 AI Agent가 실행한다. 조직도 안에서 사람, AI Agent, 로봇이 같은 단위로 등록되어 함께 일한다. POP의 진짜 얼굴은 이 구조에 있다. POP 조직도 사람은 전략, CEO Agent가 지휘, 하위 AI Agent · 사람 · 로봇이 실제 업무를 수행 사용자 (사람) 전략 · 방향 결정 ↓ 방향 제시 CEO Agent 전사 조율 · KPI 모니터링 · 자원 배분 ↓ 부서별 업무 지시 구매 Agent 발주 · 공급사 관리 생산 Agent 계획 · 실행 감독 영업 · 물류 · 재무 · 통관 Agent 각 부서별 업무 관리 ↓  세부 업무 지시  ↓ ━━━ 실행 레이어 ━━━ AI 하위 AI Agent 세부 업무 자동 실행 · API 호출 · 문서 생성 · 승인 요청 人 사람 (담당자) 판단 · 예외 처리 · 거래처 대면 · 최종 승인 ⚙ 로봇 물리 작업...