레인디어스 플랫폼은 특정 기능이나 특정 산업만을 위한 도구로 설계되지 않았다. 플랫폼의 출발점은 항상 동일했다. "현실의 거래 구조와 운영 흐름을 그대로 수용하면서, 이를 기술로 연결할 수 있는가"라는 질문이다.
앞선 글에서 설명했듯이 레인디어스는 구매자-공급사-포워딩-물류를 하나의 흐름으로 연결하는 구조로 전환했고, DVRP를 통해 창고와 배차까지 통합하는 단계에 이르렀다. 이번 글에서는 그 다음 질문, "플랫폼이 확장될수록 왜 더 복잡해지지 않는가"에 대해 설명한다.
1) 왜 운영 안정화가 확장보다 우선인가
무역과 물류, 포워딩이 결합된 영역에서 작은 오류 하나는 단순한 불편이 아니라 직접적인 비용 손실과 신뢰 붕괴로 이어진다. 일정이 어긋나고, 책임이 불분명해지고, 결국 사람의 개입이 폭발적으로 늘어난다.
레인디어스는 이 문제를 구조적으로 해결하기 위해 기능 확장 이전에 운영 안정성을 최우선 설계 기준으로 삼았다. 모든 업무는 버튼 클릭이나 단일 이벤트가 아니라, 명확한 상태(State)를 가지는 단계적 흐름으로 정의된다.
한 단계가 끝나기 전에는 다음 단계로 이동할 수 없고, 각 단계에는 명확한 책임 주체가 존재한다. 이 구조 덕분에 참여자가 늘어나도 "지금 어디에서 문제가 발생했는지"를 즉시 파악할 수 있다.
실제 운영에서 이 원칙이 적용되는 방식은 구체적이다.
예를 들어 구매자가 발주를 확정하면, 해당 주문은 CONFIRMED 상태로 전이된다. 이 시점에서 공급사 화면에는 생산 착수 버튼이 활성화되고, 포워딩 업체 화면에는 아직 아무 액션도 노출되지 않는다. 공급사가 생산 완료를 보고하고 READY_TO_SHIP 상태로 전환되어야만 포워딩 견적 요청이 시작된다. 각 상태 전이에는 타임스탬프와 책임 주체가 기록되기 때문에, 지연이 발생했을 때 어느 단계에서 얼마나 머물렀는지 데이터로 확인할 수 있다.
2) 확장을 전제로 한 플랫폼의 기본 구조
레인디어스는 처음부터 모든 참여자를 한 번에 끌어안는 거대한 올인원 플랫폼을 지향하지 않았다. 대신, 역할(Role) 단위로 분리되고 연결되는 구조를 선택했다.
현재 플랫폼의 기본 참여자는 다음과 같이 정의된다.
- 구매자: 거래를 요청하고 발주를 결정하는 주체
- 공급사: 생산과 납품을 수행하는 주체
- 포워딩 업체: 국제 물류와 선사를 연결하는 주체
- 물류 운영 주체: 창고-배차-배송(DVRP)을 담당하는 주체
이 참여자들은 동일한 플랫폼을 사용하지만, 동일한 화면이나 동일한 기능을 공유하지 않는다. 각 역할은 자신의 단계에서 필요한 정보만 확인하고, 다음 단계로 넘겨야 할 결과만 확정한다.
기술적으로 이 구조는 Next.js 기반 프론트엔드에서 역할별 라우팅과 컴포넌트 분리로 구현된다.
구매자가 접근하는 /buyer/orders 경로와 공급사가 접근하는 /vendor/orders 경로는 동일한 주문 데이터를 참조하되, 노출되는 필드와 가능한 액션이 완전히 다르다.
포워딩 업체는 /forwarder/quotes 경로에서 입찰 가능한 건만 확인한다.
이렇게 역할 단위로 화면과 데이터 접근 범위가 분리되어 있기 때문에,
새로운 역할이 추가되어도 기존 참여자의 인터페이스를 변경할 필요가 없다.
3) 플랫폼 참여자가 늘어날수록 복잡해지지 않는 이유
일반적인 플랫폼은 참여자가 늘어날수록 화면이 늘고, 기능이 늘고, 예외 처리가 폭발적으로 증가한다. 결국 "누구를 위한 화면인지 알 수 없는 시스템"이 된다. 레인디어스는 이 문제를 기술이 아니라 구조 설계로 해결했다.
첫 번째 이유는 역할 중심 설계다. 플랫폼 사용자는 단순한 사용자 계정이 아니라 "구매자", "공급사", "포워딩", "물류", "시공"이라는 명확한 역할로 정의된다. 새로운 참여자가 추가되더라도 기존 역할의 화면과 흐름을 침범하지 않는다. 현재 레인디어스 플랫폼에는 바이어 2,500곳 이상, 공급사 1,800곳 이상, 포워딩 업체 30곳 이상이 등록되어 있다. 이 4,300개 이상의 파트너가 동일한 플랫폼 위에서 각자의 역할에 맞는 화면만 사용하고 있다.
두 번째 이유는 단계별 책임 고정이다. 한 단계가 확정되면 이전 단계로 되돌아가 전체 흐름을 흔드는 것을 허용하지 않는다. 이 구조는 참여자가 늘어날수록 책임 소재를 더욱 명확하게 만들고, 운영 복잡도를 오히려 낮춘다. 예를 들어 공급사가 납품 일정을 확정한 이후에는 구매자가 발주 조건을 수정할 수 없다. 변경이 필요한 경우 새로운 주문으로 처리된다. 이 규칙 덕분에 각 단계의 데이터 무결성이 보장되고, 나중에 분쟁이 발생했을 때도 어느 시점에 누가 무엇을 확정했는지 추적할 수 있다.
세 번째는 자동화와 예외의 분리다. 정상적인 흐름은 시스템과 AI가 처리하고, 예외만 사람이 개입한다. 참여자가 늘어나도 자동화 비율이 유지되기 때문에 운영 리소스는 선형적으로 증가하지 않는다. 실제로 레인디어스는 환율 조회, 선사 스케줄 수집, 견적 조건 검증 같은 반복 업무를 NCP Cloud Functions와 Cloudflare Workers 기반의 서버리스 함수로 자동화해 두었다. 이 자동화 레이어가 정상 흐름을 처리하고, 운영팀은 자동화가 감지한 예외 케이스에만 집중한다.
결과적으로 레인디어스 플랫폼은 "기능이 늘어나는 구조"가 아니라 연결되는 역할이 늘어나는 구조를 유지한다. 25,000건 이상의 실거래 데이터가 이 구조 위에서 처리되었고, 4개국(한국, 태국, 말레이시아, 중국)에 걸친 법인 운영도 동일한 플랫폼 구조 안에서 이루어지고 있다.
4) 다음 확장 단계: 시공 업체 참여
플랫폼의 다음 확장 시나리오는 시공(설치-현장 작업) 업체의 참여다. 이는 물류의 끝이 "배송 완료"로 끝나지 않는 산업군을 자연스럽게 수용하기 위한 단계다.
예를 들어 설비, 장비, 인프라 자재의 경우 국제 물류와 통관이 끝난 뒤에도 실제 현장에서의 설치-세팅-검수가 이어진다. 레인디어스는 이 과정을 플랫폼 외부의 수작업 영역으로 남겨두지 않는다.
- 생산 및 국제 물류
- 통관 및 국내 배송
- 현장 반입 일정 조율
- 시공 업체 배정 및 작업 수행
- 설치 완료 및 인계 확정
시공 업체 역시 하나의 역할로 플랫폼에 참여하며, 작업 일정 관리, 현장 확인, 완료 보고를 수행한다. 이는 기존 물류-배차 흐름과 충돌하지 않고 동일한 상태 기반 구조 안에서 연결된다.
시공 업체의 참여가 기존 구조와 충돌하지 않는 이유는 명확하다.
시공 단계는 배송 완료(DELIVERED) 상태 이후에 활성화되는 새로운 상태 체인일 뿐이다.
INSTALLATION_REQUESTED, INSTALLER_ASSIGNED, WORK_IN_PROGRESS, INSTALLATION_COMPLETE 같은 상태가 기존 주문-물류 상태 머신의 끝에 연결되는 방식이다.
포워딩 업체와 마찬가지로 시공 업체도 입찰 방식으로 참여하게 되며,
구매자가 조건을 비교한 뒤 시공 업체를 선정하는 흐름을 따른다.
5) 상태 머신이 플랫폼 확장의 핵심인 이유
레인디어스 플랫폼의 확장성은 결국 상태 머신 설계에서 비롯된다. 모든 거래는 하나의 상태 머신 인스턴스로 존재하고, 각 상태 전이에는 전이 조건, 책임 주체, 타임아웃 규칙이 정의되어 있다.
새로운 역할이 추가된다는 것은 상태 머신에 새로운 상태 노드와 전이 경로가 추가된다는 의미다. 기존 상태 노드의 로직은 변경되지 않는다. 이 원칙이 지켜지는 한, 참여자가 10개 역할로 늘어나도 구조적으로는 동일한 복잡도를 유지한다.
현재 이 상태 머신은 Turso(LibSQL) 기반의 데이터베이스에 기록되며, 상태 전이 이력은 이벤트 로그 형태로 보존된다. 이 로그는 운영 분석뿐 아니라 분쟁 해결, AI 학습 데이터로도 활용된다. 2015년 IMARKET Thailand로 시작해 2025년 12월 REINDEERS로 공식 오픈하기까지, 10년 동안 축적된 운영 노하우가 이 상태 머신 설계에 반영되어 있다.
마무리
레인디어스 플랫폼의 확장은 "더 많은 기능을 추가하는 과정"이 아니다. 운영 안정성을 유지한 상태에서 현실의 참여자를 하나씩 연결해 나가는 과정이다.
참여자가 늘어날수록 복잡해지지 않는 이유는 단순하다. 이 플랫폼은 처음부터 복잡해지지 않도록 설계되었기 때문이다. $130B 이상 규모의 동남아 B2B 시장에서, 역할 기반 구조와 상태 머신 설계가 실제로 작동하고 있다.