Blog

Reindeers.ai — 문서 자동화와 업무 자동화로 확장되는 B2B AI 업무 플랫폼 레인디어스 플랫폼은 처음부터 단순한 B2B 거래 플랫폼을 목표로 설계된 것은 아니었다. 글로벌 유통, 제조, 생산, 물류를 연결하는 플랫폼을 만들다 보니 자연스럽게 하나의 질문에 도달하게 되었다. “기업의 실제 업무는 어디에서 이루어지고 있는가?” 견적 요청, 공급사 커뮤니케이션, 생산 일정 조정, 물류 일정 관리, 그리고 제안서나 사업계획서 같은 문서 작성까지. 기업의 대부분의 업무는 결국 데이터와 문서, 그리고 반복적인 프로세스 안에서 이루어진다. 이 과정에서 우리는 한 가지 명확한 사실을 발견했다. 거래 플랫폼만으로는 기업의 업무를 충분히 지원할 수 없다는 것 이다. 그래서 레인디어스는 거래 플랫폼을 넘어 AI 기반 업무 플랫폼 으로 확장하기 시작했다. Document AI — 문서를 작성하는 방식을 바꾸다 기업 내부에서 가장 많은 시간을 소비하는 업무 중 하나는 문서 작성이다. 제안서 사업계획서 IR 자료 기술 문서 보고서 정책 문서 이러한 문서들은 대부분 일정한 구조와 패턴을 가지고 있지만, 매번 사람이 처음부터 작성해야 하는 경우가 많다. 레인디어스는 이 문제를 해결하기 위해 Document AI Agent 를 개발했다. Document AI는 단순히 텍스트를 생성하는 도구가 아니라 기업 내부에서 발생하는 다양한 문서를 자동으로 작성할 수 있는 문서 생산 시스템 이다. doc.reindeers.ai에서 운영되고 있는 이 시스템은 다음과 같은 기술 구조로 동작한다. LLM 기반 문서 생성 엔진 RAG(Retrieval Augmented Generation) 기반 기업 문서 검색 회사별 템플릿 및 문서 스타일 관리 문서 구조 자동 생성 기존 문서 기반 문서 품질 유지 이를 통해 문서 작성 과정은 다음과 같이 변화한다. 기존 방식 문서 작성 → 검토 → ...

AI는 어디까지 개입하는가 — 레인디어스의 의사결정 보조 전략 플랫폼에 AI를 도입한다고 하면 흔히 “자동화”나 “대체”를 떠올린다. 하지만 레인디어스에서의 AI는 애초부터 사람을 대신하는 존재로 설계되지 않았다. 우리가 정의한 AI의 역할은 명확하다. 결정을 내리는 주체가 아니라, 결정을 가능하게 만드는 보조자 다. 왜 ‘결정형 AI’를 선택하지 않았는가 국제 무역과 물류 영역에서 완전 자동 의사결정은 기술적 문제 이전에 책임 구조의 붕괴 를 가져온다. 견적이 잘못되었을 때 책임은 누구에게 있는가 포워딩 선택이 실패했을 때 수정 권한은 누구에게 있는가 납기 지연이 발생했을 때 AI의 판단을 되돌릴 수 있는가 이 질문들에 명확히 답할 수 없다면, AI는 자동화 도구가 아니라 리스크 증폭기가 된다. 그래서 레인디어스는 AI를 “결정 엔진”으로 두지 않았다. AI 개입의 기준: ‘판단 이전 단계’까지만 레인디어스에서 AI가 개입하는 지점은 항상 사람의 판단 이전 단계 에 위치한다. 구체적으로는 다음과 같은 역할만 수행한다. 정보 수집 및 정리 조건 누락 및 충돌 감지 선택지 구조화 및 비교 기준 제시 즉, AI는 “이게 정답입니다”라고 말하지 않는다. 대신 “지금 상황에서 이런 선택지들이 있습니다”라고 말한다. 견적 단계에서의 AI: 계산이 아니라 정합성 검증 견적 단계에서 AI가 가장 많이 사용하는 기능은 의외로 가격 계산이 아니다. 실제 핵심은 다음과 같다. 필수 조건 누락 감지 비현실적인 수치 범위 경고 이전 유사 케이스 기반 참고 정보 제공 예를 들어 고객사가 물류 견적을 요청할 때, AI는 “이 가격이 적절하다”라고 말하지 않는다. 대신 “이 조건에서 과거 평균 대비 변동폭이 크다”는 정량적 힌트를 제공한다. 공급사(Vendor) 단계에서의 AI: 정보 정리자 공급사 단계에서 AI는 판단 주체가 될 수 없...

UI/UX 개편 기술 에피소드 — 화면을 바꾼 것이 아니라, 구조를 바꾸었다 플랫폼의 UI/UX를 개편했다고 하면 흔히 디자인 변경이나 사용성 개선을 떠올린다. 하지만 이번 레인디어스 플랫폼의 UI/UX 개편은 그런 종류의 작업이 아니었다. 화면은 결과였고, 실제 변경의 중심은 주문과 견적을 해석하는 내부 구조 였다. 고객사, 공급사, 포워딩이 동시에 사용하는 플랫폼에서 UI는 단순한 인터페이스가 아니라 각 주체가 현재 상황을 어떻게 인식하는지 를 결정한다. 이 인식이 어긋나면, 기술적으로는 정상이어도 운영은 항상 충돌한다. 문제의 시작: 상태는 같았지만, 의미는 달랐다 기존 UI에서 가장 심각했던 문제는 같은 주문을 보고 있음에도 각 사용자가 전혀 다른 단계라고 인식 한다는 점이었다. 고객사 화면에서는 “주문 완료” 공급사 화면에서는 “확정 전” 포워딩 화면에서는 “조건 미정” 데이터상 상태 값은 일치했지만, 그 상태가 의미하는 바는 사용자 역할마다 달랐다. 이는 단순한 UI 문제처럼 보였지만, 실제로는 주문 흐름 자체가 단선 구조로 설계되어 있었기 때문 이었다. UI 개편의 전제 조건: Draft 개념의 도입 UI를 바꾸기 전에 먼저 한 일은, 주문과 물류 흐름을 다시 정의하는 것이었다. 모든 프로세스의 중심에 Draft 개념을 두었다. 확정되지 않은 것은 확정되지 않은 상태로 명확히 표현하도록 했다. Draft Purchase Order Draft Delivery Order Draft Forwarding Quote 이 구조가 만들어진 이후에야 “지금 이 화면에서 사용자가 무엇을 결정할 수 있는가”를 UI로 정확히 표현할 수 있게 되었다. UI/UX 개편의 핵심 원칙 이번 개편에서 지킨 원칙은 단순했다. 입력이 아니라 의사결정 중심 의 화면 상태 값이 아니라 의미가 보이는 상태 표현 다음 액션이 없는 버튼은 존재하지 않음 ...

고객·공급사·포워딩이 ‘같은 화면’을 보게 되기까지 플랫폼을 오래 운영하다 보면, 기술보다 더 복잡해지는 것이 있다. 그것은 기능도 아니고, 트래픽도 아니다. 관계 다. REINDEERS 플랫폼 역시 마찬가지였다. 고객사, 공급사, 포워딩. 각각은 분명 자신의 역할을 충실히 수행하고 있었지만, 플랫폼 안에서는 항상 어딘가 어긋나 있었다. 고객사는 “견적을 요청했다”고 생각했고, 공급사는 “주문이 확정되지 않았다”고 말했으며, 포워딩은 “물류 조건이 확정되지 않았다”고 답했다. 문제는 누구의 잘못도 아니었다. 문제는 각자가 서로 다른 기준점에서 같은 주문을 바라보고 있었다는 것 이었다. 같은 주문, 다른 해석 초기의 구조에서 가장 큰 문제는 견적 → 주문 → 물류 가 단선적인 흐름 으로 설계되어 있었다는 점이다. 현실의 무역에서는 이 세 단계가 결코 직선으로 이어지지 않는다. 견적은 여러 번 바뀌고 주문은 조건부로 확정되며 물류는 생산과 일정에 따라 다시 재조정된다 하지만 시스템은 이를 “한 번 정해지면 끝나는 단계”로 취급했다. 그 결과, 주문 하나를 두고 상태 값은 맞는데 의미는 다른 상황 이 반복해서 발생했다. 이 문제를 해결하기 위해, 우리는 기능을 추가하는 대신 구조를 다시 정의하기로 했다. Draft라는 개념을 중심에 두다 재설계의 출발점은 단순했다. “확정되지 않은 것은, 확정되지 않았다고 명확하게 표현하자.” 그래서 모든 흐름의 중심에 Draft 개념 을 두었다. 고객사의 요청은 Draft Purchase Order Draft PO를 기반으로 Draft Delivery Order Draft DO를 기준으로 포워딩의 물류 견적 발행 이 구조에서 중요한 점은 누구도 ‘확정된 것처럼 행동하지 않아도 된다는 것 이다. 고객사는 여러 시나리오를 비교할 수 있고 공급사는 생산 가능 범위 안에서 조건을 제시하며 포워딩은 실제 실행 가능한 물...

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

레인디어스 플랫폼의 확장 가능한 시나리오와 운영 안정화 전략 참여자가 늘어나도 복잡해지지 않는 구조, 그리고 시공 업체까지 이어지는 다음 단계 레인디어스 플랫폼은 특정 기능이나 특정 산업만을 위한 도구로 설계되지 않았다. 플랫폼의 출발점은 항상 동일했다. “현실의 거래 구조와 운영 흐름을 그대로 수용하면서, 이를 기술로 연결할 수 있는가” 라는 질문이다. 앞선 글에서 설명했듯이 레인디어스는 구매자–공급사–포워딩–물류를 하나의 흐름으로 연결하는 구조로 전환했고, DVRP를 통해 창고와 배차까지 통합하는 단계에 이르렀다. 이번 글에서는 그 다음 질문, “플랫폼이 확장될수록 왜 더 복잡해지지 않는가” 에 대해 설명한다. 1) 왜 운영 안정화가 확장보다 우선인가 무역과 물류, 포워딩이 결합된 영역에서 작은 오류 하나는 단순한 불편이 아니라 직접적인 비용 손실과 신뢰 붕괴 로 이어진다. 일정이 어긋나고, 책임이 불분명해지고, 결국 사람의 개입이 폭발적으로 늘어난다. 레인디어스는 이 문제를 구조적으로 해결하기 위해 기능 확장 이전에 운영 안정성 을 최우선 설계 기준으로 삼았다. 모든 업무는 버튼 클릭이나 단일 이벤트가 아니라, 명확한 상태(State)를 가지는 단계적 흐름 로 정의된다. 한 단계가 끝나기 전에는 다음 단계로 이동할 수 없고, 각 단계에는 명확한 책임 주체가 존재한다. 이 구조 덕분에 참여자가 늘어나도 “지금 어디에서 문제가 발생했는지”를 즉시 파악할 수 있다. 2) 확장을 전제로 한 플랫폼의 기본 구조 레인디어스는 처음부터 모든 ...

레인디어스 플랫폼 구조 전환과 AI 기반 물류 생태계 확장 Buyer–Supplier–Forwarder 견적 경쟁 + DVRP(WMS·배차관제)로 연결되는 End-to-End 플랫폼으로의 진화 레인디어스 플랫폼은 초기 단계에서 구매자(Buyer) – 레인디어스 – 공급사(Supplier) 를 연결하는 구조로 출발했습니다. 이 구조에서 레인디어스는 단순 중개를 넘어, 선사 스케줄 정보를 수집·표준화하고 이를 기반으로 포워딩 업무를 자동화하여 “정보 비대칭을 줄이고 의사결정 속도를 높이는” 방향을 목표로 했습니다. 그러나 실 운영 단계에서 현실의 견적 형성 구조 와 플랫폼의 자동화 방식 사이에 괴리가 발생했고, 이는 비용 구조 및 운영 안정성 측면에서 개선이 필요한 지점으로 드러났습니다. 레인디어스는 이 문제를 해결하기 위해 플랫폼 구조를 재정의하고, 포워딩 업체가 직접 참여하는 확장형 플랫폼 으로 전환했습니다. 1) 기존 구조의 한계: 스케줄 기반 자동화의 현실 괴리 포워딩 견적은 단순히 선사 스케줄만으로 결정되지 않습니다. 견적은 다양한 변수를 통해 시장 참여자에 의해 실시간으로 형성 됩니다. 예를 들어 다음과 같은 요소가 견적에 직접적인 영향을 줍니다. 선복(스페이스) 수급 상황과 노선별 수요 변화 시기별 계약 단가, 단기 스팟 운임 변동 포워딩 업체별 확보한 스페이스/네트워크/운영 전략 긴급 출항, 지연, 환적 조건 등 일정 리스크 결과적으로, 플랫폼 내부에서 스케줄 기반으로 자동 산출한 견적과 실제 포워딩 업체의 견적 간 차이가 반복적으로 발생했고, 이는 운영 측면에서 다음과 같은 문제로 이어졌습니다. 실제 비...