Blog

B2B 국제 무역에서 하나의 거래가 완료되기까지 관여하는 시스템과 사람의 수는 예상보다 훨씬 많다. 견적 요청에서 시작해 공급사 선정, 발주, 포워딩 비딩, 통관 서류 준비, 출하, 배송, 정산까지 — 각 단계마다 서로 다른 담당자가 서로 다른 도구에서 수작업을 반복한다. 이 현장에서 반복적으로 발생하는 비효율은 분명하다. 바이어가 견적을 확정하면 공급사에게 이메일이나 메신저로 직접 통보해야 하고, 결제가 완료되면 수동으로 정산 시트에 옮기면서 1~3일이 소요된다. 출하 후에는 선적 정보를 기반으로 CI, PL, CO를 수동 생성하며 누락이 발생하고, 배송 완료 후 공급사/포워더 정산을 수작업으로 대조하면서 오차가 누적된다. ERP, 이메일, 스프레드시트, CRM에 같은 데이터를 반복 입력하는 것도 일상이다. 이 문제들의 공통점은 명확하다. "이벤트가 발생했을 때 후속 작업이 자동으로 실행되지 않는다" 는 것이다. 견적이 확정되었다는 '사실'은 시스템에 기록되지만, 그 사실이 다음 단계의 업무를 자동으로 트리거하지는 않는다. Reindeers Workflow는 이 문제를 해결하기 위해 만들어졌다. 단순히 "자동화 도구를 제공한다"가 아니라, REINDEERS 플랫폼에서 발생하는 실제 거래 이벤트를 기반으로 후속 업무가 자동 실행되는 구조를 만드는 것이다. REINDEERS 플랫폼과의 연결: 거래 이벤트가 워크플로우를 트리거한다 Reindeers Workflow의 가장 중요한 차별점은 범용 자동화 도구가 아니라 REINDEERS 본 플랫폼의 거래 이벤트에 직접 연결 된다는 것이다. REINDEERS에서 발생하는 핵심 거래 이벤트가 MQ(Message Queue)를 통해 워크플로우의 트리거가 된다. 거래 이벤트 트리거되는 워크플로우 실행 내용 quote.confirmed 공...

B2B 업무 현장에서 문서는 매출과 신뢰를 결정짓는 핵심 자산이다. 제안서, 서비스 소개서, 사업계획서, 기술 문서, IR 자료 등 상대를 설득하거나 정보를 전달하기 위한 문서가 항상 필요하고, 그 작성 과정은 회사마다 형태만 다를 뿐 구조적으로 동일하다. 자료를 모으고, 목차를 잡고, 섹션별로 작성하고, 표현을 다듬고, 검토하고, 내보내는 과정이 반복된다. 문제는 기존 AI 문서 도구가 이 반복 구조를 해결하지 못한다는 점이다. 대부분의 생성형 도구는 "프롬프트 한 줄 입력 → 결과물 한 덩어리 출력"으로 끝난다. 한 번 생성된 결과를 부분적으로 수정하거나, 과거 문서의 패턴을 재활용하거나, 생성된 내용의 사실 관계를 검증하는 구조가 없다. 기존 생성형 AI 도구에는 네 가지 근본적인 한계가 있다. 단발성 생성이라 전체를 한 번에 만들고 끝나서 섹션 단위 편집이 불가능하고, 기업의 과거 데이터나 도메인 지식을 참조하지 못하며, 할루시네이션 체크나 스타일 일관성 검증이 없고, Token 사용량이 보이지 않아 통제할 수 없다. Reindeers Document AI는 이 문제를 문서를 조작 가능한 섹션 단위로 분리하여 관리하는 운영 플랫폼 으로 해결한다. 단순히 AI가 문장을 생성하는 도구가 아니라, 구조화된 데이터 입력 → 섹션별 생성 → 편집 → 품질 검증 → 공유/출력까지 이어지는 문서 운영 체계다. 섹션 기반 데이터 모델 기술 스택은 Next.js App Router 기반이며, Cloudflare Workers에 배포된다. 데이터 저장은 Turso 기반 libSQL과 Drizzle ORM을 사용하고, 인증은 JWT 쿠키 방식으로 구성했다. 핵심은 문서를 "하나의 파일"이 아니라 "프로젝트 → 섹션"의 2레벨 계층 구조 로 관리한다는 점이다. 엔티티 주요 필드 역할 Proje...

레인디어스 플랫폼은 처음부터 단순한 B2B 거래 플랫폼을 목표로 설계된 것은 아니었다. 글로벌 유통, 제조, 생산, 물류를 연결하는 플랫폼을 만들다 보니 자연스럽게 하나의 질문에 도달하게 되었다. "기업의 실제 업무는 어디에서 이루어지고 있는가?" 견적 요청, 공급사 커뮤니케이션, 생산 일정 조정, 물류 일정 관리, 그리고 제안서나 사업계획서 같은 문서 작성까지. 기업의 대부분의 업무는 결국 데이터와 문서, 그리고 반복적인 프로세스 안에서 이루어진다. 4,300개 이상의 파트너사가 레인디어스 플랫폼에서 거래를 진행하면서, 거래 이외의 업무 영역에서도 동일한 수준의 자동화를 요청하는 경우가 늘어났다. 이 과정에서 우리는 한 가지 명확한 사실을 발견했다. 거래 플랫폼만으로는 기업의 업무를 충분히 지원할 수 없다는 것 이다. 그래서 레인디어스는 거래 플랫폼을 넘어 AI 기반 업무 플랫폼 으로 확장하기 시작했다. 이 확장의 첫 번째 결과물이 Document AI와 Workflow AI다. Document AI - 문서를 작성하는 방식을 바꾸다 기업 내부에서 가장 많은 시간을 소비하는 업무 중 하나는 문서 작성이다. 제안서 사업계획서 IR 자료 기술 문서 보고서 정책 문서 이러한 문서들은 대부분 일정한 구조와 패턴을 가지고 있지만, 매번 사람이 처음부터 작성해야 하는 경우가 많다. 특히 B2B 무역 업종에서는 국가별로 요구되는 서류 양식이 다르고, 언어도 한국어, 태국어, 영어, 중국어가 혼재되어 있어 문서 작성의 난이도가 높다. 레인디어스는 이 문제를 해결하기 위해 Document AI Agent 를 개발했다. Document AI는 단순히 텍스트를 생성하는 도구가 아니라 기업 내부에서 발생하는 다양한 문서를 자동으로 작성할 수 있는 문서 생산 시스템 이다. doc.reindeers.ai에서 운영되고 있는 이 시스템은 다음과 같은 기술 구조로 동작한다. LLM 기반...

플랫폼에 AI를 도입한다고 하면 흔히 "자동화"나 "대체"를 떠올린다. 하지만 레인디어스에서의 AI는 애초부터 사람을 대신하는 존재로 설계되지 않았다. 우리가 정의한 AI의 역할은 명확하다. 결정을 내리는 주체가 아니라, 결정을 가능하게 만드는 보조자 다. 왜 '결정형 AI'를 선택하지 않았는가 국제 무역과 물류 영역에서 완전 자동 의사결정은 기술적 문제 이전에 책임 구조의 붕괴 를 가져온다. 견적이 잘못되었을 때 책임은 누구에게 있는가 포워딩 선택이 실패했을 때 수정 권한은 누구에게 있는가 납기 지연이 발생했을 때 AI의 판단을 되돌릴 수 있는가 이 질문들에 명확히 답할 수 없다면, AI는 자동화 도구가 아니라 리스크 증폭기가 된다. 그래서 레인디어스는 AI를 "결정 엔진"으로 두지 않았다. 여기에는 규제적 현실도 크게 작용한다. 국제 무역은 국가별 수출입 규제, 관세율, 인증 요건이 얽혀있다. 태국의 TISI 인증, 한국의 KC 마크, 중국의 CCC 인증 등 각 국가의 규제 기관은 "누가 이 결정을 내렸는가"에 대해 명확한 책임 소재를 요구한다. AI가 자동으로 통관 서류를 작성하거나 인증 요건을 판단했을 때, 오류가 발생하면 규제 기관은 해당 결정의 책임자를 추적한다. "알고리즘이 판단했다"는 답변은 어느 나라의 관세청에서도 통하지 않는다. 신뢰 측면도 있다. 4,300개 이상의 파트너사가 연결된 B2B 플랫폼에서, AI가 견적 금액을 자동 결정하거나 공급사를 자동 선택했다면, 그 판단에 대한 불신은 곧 플랫폼 자체에 대한 불신으로 이어진다. B2B 거래에서 신뢰는 한 번 무너지면 복구하기 어렵다. 특히 $130B 규모의 시장에서 거래 한 건의 금액이 수만 달러에 달할 때, "AI가 알아서 처리합니다"라는 메시지는 안심이 아니라 불안의 원인이 된다. AI 개입의 기준: '...

플랫폼의 UI/UX를 개편했다고 하면 흔히 디자인 변경이나 사용성 개선을 떠올린다. 하지만 이번 레인디어스 플랫폼의 UI/UX 개편은 그런 종류의 작업이 아니었다. 화면은 결과였고, 실제 변경의 중심은 주문과 견적을 해석하는 내부 구조 였다. 고객사, 공급사, 포워딩이 동시에 사용하는 플랫폼에서 UI는 단순한 인터페이스가 아니라 각 주체가 현재 상황을 어떻게 인식하는지 를 결정한다. 이 인식이 어긋나면, 기술적으로는 정상이어도 운영은 항상 충돌한다. 레인디어스에는 바이어 2,500곳 이상과 공급사 1,800곳 이상, 포워딩 업체 30곳 이상이 참여하고 있다. 이 4,300개 이상의 파트너가 동일한 주문을 서로 다른 관점에서 바라본다는 것은, 화면 하나의 문제가 곧 운영 전체의 문제가 된다는 뜻이다. 문제의 시작: 상태는 같았지만, 의미는 달랐다 기존 UI에서 가장 심각했던 문제는 같은 주문을 보고 있음에도 각 사용자가 전혀 다른 단계라고 인식 한다는 점이었다. 고객사 화면에서는 "주문 완료" 공급사 화면에서는 "확정 전" 포워딩 화면에서는 "조건 미정" 데이터상 상태 값은 일치했지만, 그 상태가 의미하는 바는 사용자 역할마다 달랐다. 이는 단순한 UI 문제처럼 보였지만, 실제로는 주문 흐름 자체가 단선 구조로 설계되어 있었기 때문 이었다. 기존에는 하나의 상태 필드가 모든 역할에 동일하게 노출되었다. ORDER_PLACED 라는 상태가 구매자에게는 "주문을 넣었으니 기다리면 된다"였지만, 공급사에게는 "아직 내가 수락하지 않은 요청"이었고, 포워딩 업체에게는 "물류 조건이 아직 정의되지 않은 건"이었다. 하나의 상태 값이 세 가지 해석을 만들어내고 있었다. UI 개편의 전제 조건: Draft 개념의 도입 UI를 바꾸기 전에 먼저 한 일은, 주문과 물류 흐름을 다시 정의하는 것이었다. 모든 프로세...

고객·공급사·포워딩이 '같은 화면'을 보게 되기까지 플랫폼을 오래 운영하다 보면, 기술보다 더 복잡해지는 것이 있다. 그것은 기능도 아니고, 트래픽도 아니다. 관계 다. REINDEERS 플랫폼 역시 마찬가지였다. 고객사, 공급사, 포워딩. 각각은 분명 자신의 역할을 충실히 수행하고 있었지만, 플랫폼 안에서는 항상 어딘가 어긋나 있었다. 고객사는 "견적을 요청했다"고 생각했고, 공급사는 "주문이 확정되지 않았다"고 말했으며, 포워딩은 "물류 조건이 확정되지 않았다"고 답했다. 문제는 누구의 잘못도 아니었다. 문제는 각자가 서로 다른 기준점에서 같은 주문을 바라보고 있었다는 것 이었다. 같은 주문, 다른 해석 -- 기존 데이터 모델의 한계 초기의 구조에서 가장 큰 문제는 견적 - 주문 - 물류가 단선적인 흐름 으로 설계되어 있었다는 점이다. 현실의 무역에서는 이 세 단계가 결코 직선으로 이어지지 않는다. 견적은 여러 번 바뀌고 주문은 조건부로 확정되며 물류는 생산과 일정에 따라 다시 재조정된다 하지만 시스템은 이를 "한 번 정해지면 끝나는 단계"로 취급했다. 그 결과, 주문 하나를 두고 상태 값은 맞는데 의미는 다른 상황 이 반복해서 발생했다. 기존 데이터 모델을 구체적으로 보면 이렇다. Order라는 단일 엔티티가 견적부터 배송 완료까지의 모든 상태를 관리했다. status 필드 하나가 quoted , confirmed , in_production , shipped , delivered 를 순차적으로 거치는 구조였다. 문제는 현실에서 하나의 PO에 대해 여러 번의 배송이 발생할 수 있다는 점이었다. 공급사가 생산 완료된 물량부터 분할 배송하는 경우, 기존 모델에서는 Order의 status를 shipped 로 바꿔야 하는데, 아직 생산 중인 물량도 남아있었다. partially_shipped 같은 중간 상...

REINDEERS 플랫폼에서는 최근 견적(PQ–QA–QB)과 주문(PO–DO–포워딩–결제) 전반의 UI/UX를 다시 설계했다. 겉으로 보면 “화면이 더 깔끔해졌다” 정도로 보일 수 있지만, 실제로는 내부적으로 이미 정리된 고객사–공급사–포워딩 관계 구조 를 사용자 화면에 그대로 노출하기 위한 구조 개편이었다. 현재 시점은 명확하다. 플랫폼의 거래 구조(고객사/공급사/포워딩 연결)는 개선을 완료했고, 이제는 DVRP 베타(2026년 3월 예정) 를 위한 개발이 진행되는 단계다. 즉, 지금 UI/UX 개편은 “보기 좋은 화면”이 목적이 아니라, 실행 레이어(DVRP)로 연결 가능한 형태의 데이터·흐름을 UX로 고정 하는 작업에 가깝다. 1) UI/UX 개편의 출발점: “상태 리스트”는 국제 거래를 설명하지 못한다 국제 무역/물류 플랫폼에서 거래는 ‘단계’가 아니라 ‘관계’다. 견적이 주문을 만들고, 주문은 여러 DO로 분기되고, 포워딩 선택은 DO 단위로 붙으며, 결제는 확정된 실행 결과를 기준으로 발생한다. 문제는 기존 화면이 이 구조를 “리스트”로 표현하고 있었다는 점이다. 문서가 나열되고 상태가 나열되면, 사용자는 결국 다음 질문을 하게 된다. 어떤 견적이 확정되었고, 그 확정이 주문과 어떻게 연결되었나? 왜 DO가 여러 개로 나뉘고, 각각의 물류 실행은 어떤 차이가 있나? 포워딩은 언제 선택하는가? 결제는 무엇을 기준으로 묶이는가? 이 질문은 사용자가 부족해서가 아니라, UI가 “흐름”을 전달하지 못해서 생긴다. 그래서 이번 개편은 디자인보다 먼저 흐름의 표현 단위 를 재정의하는 것에서 시작했다. 2) 견적 흐름 재정의: PQ → QA → QB (객체 분리 + 분기 표현) 견적은 다음 구조로 정리되었다. PQ (Purchase Quote) : 고객사의 견적 시작점 QA (Quote Request) : 공급사에 전달되는 요청 단위(분기 가능) QB (Quote...