Blog

배차 최적화는 말로 하면 단순하다. "트럭에 화물을 싣고 가장 효율적인 경로로 배송한다." 하지만 실제로 구현하면 조합 폭발이 일어나는 NP-hard 문제다. 50건의 배송을 8대의 트럭에 배정하는 경우의 수는 8의 50승에 가깝다. 모든 경우를 탐색해서 최적해를 찾는 건 현재의 컴퓨팅 파워로도 불가능하다. DVRP(Dynamic Vehicle Routing Problem)는 이 문제를 실시간으로, 현실의 제약 조건 하에서 풀어야 한다. 이 글은 REINDEERS DVRP의 경로 최적화 엔진이 어떤 구조로 설계되었는지, 어떤 제약 조건을 어떻게 처리하는지, 그리고 AI가 이 과정에서 어떤 역할을 하는지에 대한 기술적인 이야기다. 동시에, DVRP가 왜 단순한 최적화 엔진이 아니라 조직도에 등록될 "물류 Agent"의 심장이 되는지에 대한 이야기이기도 하다. 조금 더 정확히 말하면 이렇다. REINDEERS와 POP, DVRP는 지금 AI로 전환되는 구조 위에 올라서 있다. 사람은 "오늘 배송 방침"을 결정한다 , 비용 우선인지, 정시 배송 우선인지, 특정 고객 우선인지. 실제 배차와 재배차, 지연 대응, 운전자 지시는 조직도 안에 등록된 물류 Agent가 수행한다. DVRP 엔진은 이 물류 Agent의 "손과 발"에 해당한다. 제약 기반 계산이 Agent의 실행 엔진이고, 그 위에 AI 레이어가 "왜 이 결정인가"를 언어로 설명하는 층이다. VRP: 문제 정의 Vehicle Routing Problem(VRP)은 운영 연구(Operations Research)의 고전적인 문제다. 1959년 Dantzig와 Ramser가 처음 공식화한 이후로 60년 넘게 연구되었고, 아직도 완벽한 해법은 없다. NP-hard 문제이기 때문에 최적해를 보장하는 다항 시간 알고리즘이 존재하지 않는다. 기본 VRP는 이렇게 정의된다. 하나의 창고(depot)에서 출발하는...

만약 회사 조직도에 새로운 직원을 등록할 때, '사람' 외에 'AI Agent'나 '로봇'을 선택할 수 있다면 어떤 일이 벌어질까요? 이것은 먼 미래의 상상이 아닙니다. 현재 REINDEERS Works, POP, DVRP 플랫폼에서 구현되고 있는 핵심 설계 사상입니다. 우리는 “사람은 결정과 방향을 제시하고, 실제 업무는 AI가 실행한다”는 비전을 시스템의 가장 근간이 되는 조직 구조 자체에 반영하고 있습니다. 외부 AI 도구를 잠시 빌려 쓰는 것이 아니라, AI를 회사의 정식 구성원으로 조직도 안에 통합하는 것입니다. 외부 도구가 아닌, 내부 구성원으로서의 AI 시중의 많은 AI Agent 도구들은 외부 조력자처럼 작동합니다. 사용자가 필요할 때 호출해서 특정 업무를 지시하고 결과를 받는 구조입니다. 이 관계는 명확히 ‘사용자’와 ‘도구’의 관계입니다. 하지만 REINDEERS의 접근 방식은 근본적으로 다릅니다. AI Agent는 우리 시스템 안에서 하나의 ‘직원’으로 정의됩니다. 조직도에 등록된 AI Agent는 자신만의 직책, 소속 부서, 보고 라인(상사), 그리고 관리 대상(부하 직원)을 가집니다. 상사와 부하 직원은 사람이 될 수도, 또 다른 AI Agent나 로봇이 될 수도 있습니다. 이것은 단순히 용어의 차이가 아닙니다. AI가 조직의 정식 구성원이 된다는 것은, 그에게 회사의 공식적인 역할, 책임, 데이터 접근 권한이 시스템적으로 부여된다는 의미입니다. 예를 들어, 구매팀 AI Agent 는 승인된 예산 범위 내에서 발주를 실행할 권한을 가지며, 모든 활동은 해당 Agent의 이름으로 감사 로그에 기록됩니다. 더 이상 특정 직원이 사용하는 도구가 아니라, 회사 시스템 안에서 자율적으로 역할을 수행하는 주체가 되는 것입니다. CEO Agent가 이끄는 AI 부서 이러한 조직 구조는 계층적으로 작동하도록 설계되었습니다. 최상단에는 사람 사용자가 전략적 방향을 제시합니다. 그러면 CEO Agent 가 이 ...

AI가 "업무를 대신한다"는 말은 이제 누구나 한다. 문제는 구체적으로 어떻게인지를 설명하는 곳이 드물다는 거다. LLM이 텍스트를 잘 생성한다는 건 모두가 안다. 그런데 그 LLM이 실제로 발주서를 작성하고, 물류를 배정하고, 서류를 검증하려면 어떤 구조가 필요한가? 이 글은 REINDEERS에서 현재 설계 중인 AI Agent 시스템의 구조에 대한 이야기다. Phase 1 구현에 진입하는 단계이며, 여기서 설명하는 내용은 설계 방향과 목표 아키텍처다. 이 구조가 최종적으로 지향하는 모습부터 먼저 밝히겠다. REINDEERS·POP·DVRP는 지금 AI로 전환되는 구조 위에 올라서고 있다. 조직도 안에서 직원을 등록할 때 '사람', 'AI Agent', '로봇' 중 하나를 선택하는 구조다. 사람은 전략과 방향을 결정하고, 실제 업무는 조직도 안에 등록된 AI Agent가 수행한다. paperclip 같은 외부 AI 도구를 외부에서 연결하는 방식이 아니라, 회사 조직 구조 자체에 AI가 직원으로 편입되는 방식이다. 이 글은 그 AI 직원들이 실제로 업무를 실행하기 위해 시스템이 어떤 모습이어야 하는지에 대한 이야기다. REINDEERS에서는 이걸 AX라고 부른다. Agent Experience. UX가 사람이 시스템을 경험하는 방식이라면, AX는 AI Agent가 시스템 안에서 업무를 수행하는 방식이다. 사람을 위해 UI를 설계하듯, Agent를 위해 시스템의 인터페이스를 설계한다는 뜻이다. CEO Agent 지휘 체계 사용자 (사람) │ CEO Agent 전략 실행 · 자원 배분 · KPI │ 구매 Agent 발주·공급사 생산 Robot 계획·실행 영업 Human 견적·주문 물류 Robot 배차·운송 재무 Agent 정산·대금 통관 Agent HS·서류 사람은 전략만, AI Agent가 각 부서의 실제 업무를 ...

 우리 팀에서는 하루에 한 번 이상 이런 대화가 오갔다. "이 주문 상태가 왜 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 인사이트 제공 가격 · 공급 · 경로 추천 · 파트너...