Blog

4개국 법인과 다수 고객사의 데이터를 하나의 인프라에서 격리하면서 비용 효율과 보안을 동시에 달성하는 것 , 이 글은 REINDEERS의 DVRP(물류 배차 최적화)와 POP(생산 운영 플랫폼)에 적용된 멀티테넌시 아키텍처를 다룬다. 왜 공유 DB + Row-Level Security 모델을 선택했는지, 테넌트 컨텍스트가 시스템 전체에 어떻게 전파되는지, 다층 방어 구조가 어떤 원칙으로 설계되었는지, 그리고 4개국 규제 환경에서의 컴플라이언스 전략까지 정리한다. 한 가지를 먼저 덧붙인다. DVRP와 POP는 지금 AI로 전환되는 구조 위에 올라가고 있다. 사람은 전략과 방향을 결정하고, 실제 업무는 조직도 안에 등록된 AI Agent가 실행한다. 직원을 등록할 때 "사람", "AI Agent", "로봇" 중 선택할 수 있는 구조다. 이 구조에서 멀티테넌시는 "화면이 섞이지 않게 하는" 수준을 훨씬 뛰어넘는 의미를 갖는다. Agent가 사람 대신 데이터를 읽고 실행 결정을 내리기 때문에, 테넌트 격리가 깨지는 순간 "다른 회사의 구매 Agent가 우리 회사 데이터로 발주를 내렸다" 같은 재앙이 발생할 수 있다. 멀티테넌시는 AI 전환의 전제 조건이다. 멀티테넌시 3중 방어 구조 LAYER 1 API Gateway · 요청 인증 JWT 검증 · 테넌트 식별 · 역할 결정 ↓ LAYER 2 애플리케이션 · 테넌트 컨텍스트 주입 미들웨어가 모든 쿼리에 tenant_id 바인딩 ↓ LAYER 3 데이터베이스 · Row-Level Security tenant_id 불일치 행은 DB가 직접 차단 한 레이어가 뚫려도 다음 레이어에서 차단. 실수로 인한 데이터 유출 방지. 왜 멀티테넌시가 중요한가 REINDEERS는 두 개의 SaaS 플랫폼을 운영한다. DVRP 는 물류 회사를 위한 배차 최적화 시스템이고, POP 는 ...

배차 최적화는 말로 하면 단순하다. "트럭에 화물을 싣고 가장 효율적인 경로로 배송한다." 하지만 실제로 구현하면 조합 폭발이 일어나는 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...