Blog

B2B 파트너 업무 효율과 자동화를 위한 워크플로우 플랫폼 기술 스택, 서비스 목표, 그리고 실제 업무 효율 증대 사례까지 프로젝트를 시작한 이유: B2B 파트너의 업무 효율과 자동화 REINDEERS 플랫폼은 내부 직원과 B2B 파트너가 함께 사용하는 비즈니스 환경입니다. 반복되는 수작업, 툴 간 데이터 복사·붙여넣기, 수동 알림·리포트 작성 등은 시간을 잠식하고 실수를 늘립니다. 이런 문제를 줄이기 위해 우리는 업무 흐름을 한 곳에서 설계하고, 트리거 기반으로 자동 실행되는 워크플로우 플랫폼이 필요했습니다. 그래서 워크플로우 엔진을 기반으로 자사 브랜딩과 인프라에 맞춘 Reindeers Workflow 프로젝트를 시작했습니다. 목표는 단순했습니다. “파트너와 직원이 코드 없이 워크플로우를 만들고, 폼·웹훅·스케줄·외부 서비스 연동으로 반복 업무를 자동화할 수 있는 하나의 플랫폼”을 제공하는 것입니다. 동시에 보안과 운영을 위해 단일 도메인(workflow.reindeers.com)에서 HTTPS로 서비스하고, 내부 전용(직원·파트너)으로 제한해 사용할 수 있도록 했습니다. 해결하고자 했던 것 첫째, 도구 간 수동 연동 이었습니다. 이메일, 슬랙, 스프레드시트, CRM, API 등 여러 시스템 사이에서 사람이 중간에 끼어 정보를 옮기는 구조는 비효율적이고 지연을 만들었습니다. 둘째, 반복 작업의 자동화 부재 입니다. 주기적 리포트, 이벤트 시 알림, 폼 제출 후처리 등을 매번 사람이 하면 낭비가 큽니다. 셋째, 일관된 자동화 환경 부재 입니다. 팀·파트너마다 스크립트·스케줄러를 따로 쓰면 유지보수와 권한 관리가 어렵습니다. Reindeers Workflow는 “워크플로우 편집기 + 트리거/노드 + 단일 인스턴스”로 이 세 가지를 해결해, 하나의 URL에서 설계·실행·이력 조회가 모두 가능한 플랫폼을 만들었습니다. 기술적 구성...

B2B Document AI Reindeers DAI를 만든 이유와, 문서 업무를 AI 워크플로우로 바꾸는 방법 B2B 파트너의 반복적인 문서 작성 업무를 줄이고, 초안 생성부터 수정, 공유, 출력, 향후 견적 문서 자동화까지 확장할 수 있는 기반을 만들기 위해 설계한 문서 생성 서비스다. 한 줄 요약: Reindeers DAI는 단순히 AI가 문장을 대신 써주는 도구가 아니라, B2B 문서 업무를 구조화된 데이터 입력, 문서 생성, 섹션 단위 편집, 품질 점검, 공유와 출력까지 연결하는 실무형 문서 운영 플랫폼을 지향한다. 왜 이 프로젝트를 시작했는가 B2B 업무 현장에서는 늘 문서가 핵심이다. 제안서, 서비스 소개서, 사업계획서, 매뉴얼, 기술 문서, 투자 유치용 발표 자료처럼 상대를 설득하거나 정보를 전달하기 위한 문서는 항상 필요하다. 문제는 이 문서들이 회사마다 형태는 조금씩 달라도 작성 과정은 놀랄 만큼 비슷하다는 점이다. 담당자는 고객사 정보와 내부 자료를 모으고, 목차를 잡고, 슬라이드나 페이지를 하나씩 작성하고, 표현을 다듬고, 다시 검토하고, PDF로 내보내고, 때로는 공개 링크로 공유한다. 이 과정은 반복적이지만 결코 가볍지 않다. 오히려 반복되기 때문에 더 많은 시간이 소모되고, 사람이 지치는 영역이 된다. Reindeers DAI는 바로 이 반복을 줄이기 위해 시작했다. 출발점은 명확했다. B2B 파트너들의 업무 효율을 높이고, 문서 작성 자동화의 범위를 넓히자. 처음에는 발표 자료나 설명 문서를 더 빨리 만드는 것에 집중했지만, 더 큰 방향은 따로 있었다. 추후에는 견적서와 제안 범위 정리, 요구사항 문서, 고객 대응용 정리 문서까지 포함해 AI가 기업의 문서 업무 상당 부분을 대신하게 만드는 것이다. 즉, 문서 한 장을 잘 만드는 서비스가 아니라, 문서 업무 전체를 자동화 가능한 워크플로우로 바꾸는 것이 이 프로젝트의 본래 목적이다. 실무에서는 빈 ...

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) : 공급사에 전달되는...