Blog of Reindeers

AI와 MQ, 그리고 MCP — 우리가 기술로 문제를 해결한 방식 요약: REINDEERS는 단순한 자동화 시스템이 아니다. 우리는 AI, MQ, MCP를 결합해 사람이 하던 의사결정과 실행을 시스템화했다. 업무의 절반은 사람이, 나머지 절반은 AI Agent가 처리한다. 이번 글은 REINDEERS가 기술로 문제를 해결한 실제 방식을 공개한다. 1. AI가 들어오기 전의 문제 2025년 5월 내부 리셋 이후, 가장 큰 문제는 속도였다. 팀의 기술 수준은 높았지만, 다국적 협업 환경에서는 작은 결정 하나에도 시간이 걸렸다. “이 데이터는 어디에 저장할까?”, “이 로직은 누가 승인해야 하지?” 이런 질문이 하루를 지연시켰다. 사람의 의사결정을 코드로 바꾸는 방법이 필요했다. 그 해답이 AI Agent 였다. 2. MCP + MQ + AI의 결합 구조 REINDEERS의 내부 구조는 세 가지 축으로 이루어져 있다. MCP(Multi-Commerce Platform)는 전체 트랜잭션의 뼈대, MQ(Message Queue)는 데이터 흐름의 신경망, AI Agent는 그 신경망을 제어하는 두뇌 역할을 한다. [MCP] — [MQ Router] — [AI Agent] — [Cloud Functions] — [Data Layer] ↘︎ Logging ↙︎ ↘︎ Scheduler ↙︎ AI는 사람이 하지 않아도 되는 “판단성 업무”를 맡았다. 예를 들어, MQ에 “quote.confirmed” 이벤트가 들어오면 AI가 자동으로 주문 구조...

왜 태국·한국·말레이시아·중국인가 — REINDEERS의 글로벌 확장 전략 요약: REINDEERS는 태국, 한국, 말레이시아, 중국 4개국을 중심으로 글로벌 무역 플랫폼의 기술과 운영 인프라를 동시에 구축했다. 특히 개발은 한국과 중국 양쪽에서 병렬로 진행되며, 두 리전이 서로의 백업 및 실험 환경 역할을 수행한다. 이번 글은 각 리전의 역할과 기술적 이유를 기록한다. 1. 동시 오픈의 배경 REINDEERS는 처음부터 하나의 국가에서 완성될 수 없는 구조였다. 무역은 복수의 국가가 동시에 참여해야 완전한 프로세스를 이룬다. 그래서 우리는 서비스 초기부터 네 개 국가의 리전을 병렬 설계했다. 태국은 시장이자 물류의 중심, 한국과 중국은 개발의 중심, 말레이시아는 운영과 금융의 허브였다. 네 리전이 동시에 작동해야만 “무역이 움직이는 플랫폼”이 가능했다. 2. 태국 — 시장과 물류의 실시간 거점 태국은 REINDEERS의 실제 비즈니스 거래가 이루어지는 핵심 리전이다. 고객사의 견적 요청, 공급사의 견적 발행, DO 생성, 결제, 인보이스 발행 등 모든 상거래 이벤트가 태국 리전의 MCP에서 최초로 발생한다. 서비스 인프라는 Tencent Cloud Bangkok 리전에 구축되었으며, 정적 파일과 이미지 리사이징은 COS Function으로 처리된다. 프론트엔드는 홍콩 CDN에서 배포되어 인접 국가에서도 빠른 응답 속도를 유지한다. 3. 한국 — 기술의 중심이자 MCP의 제어 리전 한국은 REINDEERS의 핵...

Reindeers Delivery - Carrier Mobile App React Native (Expo) 기반 배송 관리 및 추적 모바일 애플리케이션 📋 목차 프로젝트 개요 주요 기능 기술 스택 프로젝트 구조 설치 및 실행 개발 환경 API 연동 알려진 이슈 및 해결방법 디자인 시스템 향후 작업 프로젝트 개요 Reindeers Delivery 는 배송 기사(Carrier)가 배송 관리 및 실시간 위치 추적을 할 수 있는 모바일 애플리케이션입니다. 개발 기간 개발 시작일 : 2025-10-25 개발 종료일 : 2025-10-27 핵심 목표 ✅ 예외 처리 없는 단일 코드베이스 (웹/모바일/에뮬레이터 구분 없음) ✅ 실시간 위치 추적 (5-10분 간격) ✅ 백그라운드에서도 작동 (앱 최소화 시) ✅ 수동 새로고침 방식 (서버 과부하 방지) 앱 정보 앱 이름 : Delivery Bundle ID : com.reindeers.delivery Expo SDK : 54.0.20 React Native : 0.81.5 주요 기능 🚚 배송 관리 3단계 워크플로우 : Pending : 배송 대기 중 Delivery : 배송사 인계 (Vendor에서 픽업 완료) Handover : 최종 인도 (Buyer에게 배송 완료) 탭 기반 배송 목록 (각 상태별 카운트 표시) 상세 배송 정보 (픽업/배송 주소, 화물 정보) Pull-to-refresh 수동 새로고침 📦 화물 추적 상세 상품 정보 (상품명, SKU 코드, 수량, 무게) 주문당 다중 아이템 지원 총 중량 및 수량 요약 📍 위치 및 내비게이션 실시간 GPS 추적 (5분 간격) 백그라운드 위치 추적 (앱 최소화 시에도 작동) Google Maps, Kakao Navi, T map 연동 픽업/배송 위치 마커 표시 API 서버로 위치 전송 ( /logistics/carrier-employee-gps ) ✍️...

태국에서 시작된 혁신 — 10년간 쌓아온 MRO 유통의 노하우 요약: REINDEERS의 시작은 태국 법인 IMARKET Thailand 였다. 10년 넘게 쌓아온 산업소모품(MRO) 유통 경험과 데이터, 그리고 제조업 고객과 공급사 간의 관계가 오늘의 플랫폼을 만든 토대가 되었다. 이번 글은 REINDEERS가 태국에서 쌓은 산업적 이해를 어떻게 기술로 바꿨는지를 기록한다. 1. IMARKET Thailand — REINDEERS의 출발점 REINDEERS의 역사는 태국 법인 IMARKET Thailand Co., Ltd. 에서 시작되었다. 이 법인은 2014년 설립되어 10년간 태국 산업재 유통 시장에서 활동해왔다. MRO(Maintenance, Repair, Operations) 제품을 중심으로 3만여 개 SKU를 관리하고, 2,000여 개 기업 고객을 직접 대응한 경험이 있었다. REINDEERS는 이 법인의 실제 유통·조달 데이터 위에서 설계되었다. 기술보다 먼저 있었던 것은 산업이었다. IMARKET Thailand가 10년간 쌓은 거래 데이터, 구매 패턴, 납기 리듬이 오늘날 REINDEERS 데이터베이스의 기반이 되었다. 2. 태국 산업재 시장의 현실 태국의 MRO 시장은 규모는 크지만, 데이터화는 더뎠다. 공장마다 거래 방식이 다르고, 같은 제품도 이름과 단위가 달랐다. 하나의 절연테이프가 브랜드마다 다른 코드로 유통되었고, 주문서는 대부분 이메일이나 팩스로 처리되었다. REINDEERS는 바로 이 비효율에서 기회를 보았다. 2020년부터 SKU 표준화(No...

🇰🇷 플랫폼 매니저 (운영 / 글로벌 B2B & AI 기반 자동화 플랫폼) 회사명: (주)레인디어스 | Reindeers Co., Ltd. 근무지: 서울 / 방콕 (Hybrid 가능) 고용형태: 정규직 (계약-전환형 가능) ⸻ 회사 소개 레인디어스는 산업자재 및 무역 중심의 글로벌 B2B 플랫폼을 운영하는 기술 기반 기업입니다. 한국, 태국, 말레이시아, 중국 등 주요 아시아 시장에서 **견적–발주–물류(3PL)–통관–정산–재고관리(WMS)**를 통합 관리하는 시스템을 제공하며, AI 기반 자동화와 데이터 인사이트로 업무 효율과 무역 생산성을 혁신하고 있습니다. 레인디어스는 운영 중심의 플랫폼 관리 전문가를 찾습니다. 본 포지션은 플랫폼의 운영·유지·관리·발전·확장을 담당하며, 서비스가 안정적으로 성장하도록 전체적인 흐름을 관리하는 역할을 맡습니다. (※ 개발 업무를 직접 수행하지 않으며, 개발팀과 협업을 통해 개선을 주도합니다.) ⸻ 주요 업무 • REINDEERS B2B 플랫폼의 운영 및 서비스 유지관리 • 상품, 주문, 물류(3PL), 통관, 정산 등 운영 프로세스 실행 및 관리 • 사용자(공급사·고객사) 중심의 운영 이슈 대응 및 개선 요청 관리 • 운영 효율화 및 신규 기능 제안을 위한 서비스 개선 기획 및 테스트 • AI 기반 자동화 기능(데이터 매칭, 견적 추천 등) 운영 및 모니터링 • 국가별 서비스 환경(태국·말레이시아·중국·한국) 유지 및 운영 품질 관리 • 운영 데이터 분석을 통한 서비스 개선 및 운영 인사이트 도출 • 개발·물류·영업 등 유관 부서와의 운영 협의 및 실행 관리 ⸻ 자격 요건 • 플랫폼 운영 또는 서비스 관리 경력 3~7년 내외 • e-Commerce, B2B, 무역, Fulfillment(3PL/WMS) 관련 서비스 운영 경험 • 플랫폼 운영 프로세스(주문·정산·물류·CS 등)에 대한 이해 • 데이터 기반 문제 해결 및 서비스 ...

Buybly에서 REINDEERS로 — 브랜드 리포지셔닝의 비밀 요약: Buybly는 단순한 유통 플랫폼이었다. 하지만 우리가 만들고자 했던 것은 “산업의 언어를 바꾸는 기술 플랫폼”이었다. 이름이 바뀐 것이 아니라, 존재의 방향이 달라졌다. 이번 글은 Buybly가 REINDEERS로 진화한 이유와 그 전략적 배경을 기록한다. 1. Buybly의 한계 — 이름보다 방향의 문제 Buybly는 2021년, 산업재와 소비재를 동시에 다루는 B2B 플랫폼으로 시작되었다. 이름은 “Buy + Easily”의 조합으로, 빠르고 간편한 구매를 의미했다. 하지만 시간이 지나면서 이 이름은 우리가 만들고자 한 시스템의 본질과 멀어졌다. Buybly는 거래 중심의 사고에서 출발했지만, REINDEERS는 데이터 중심의 사고 에서 출발했다. 우리는 “무엇을 팔 것인가”보다 “산업이 어떻게 연결되어야 하는가”를 고민하기 시작했다. 그 순간, Buybly라는 이름은 한계가 되었다. 2. 리브랜딩의 출발 — 철학부터 다시 세우다 리브랜딩은 단순한 네이밍 작업이 아니었다. Buybly는 기능적인 이름이었고, REINDEERS는 방향이 있는 이름이어야 했다. 그래서 우리는 기술, 사람, 그리고 시장의 본질에서부터 새로운 철학을 세웠다. 기술의 본질: 자동화와 데이터가 사람의 일을 돕는 구조 산업의 본질: 제조와 공급이 언어 없이도 연결되는 구조 조직의 본질: 글로벌 팀이 하나의 목표를 공유하는 구조 이런 철학을 표현할 새로운 이름이 필요했다. 그 이름이 바로 REINDEE...

IT와 무역이 만나다: 제조업의 새로운 길을 설계하다 요약: REINDEERS는 단순한 플랫폼이 아니다. 우리는 “무역”이라는 복잡한 산업 언어를 소프트웨어 언어로 바꾸는 실험을 했다. 그리고 그 과정에서 IT와 무역은 충돌했지만, 결국 하나의 구조로 융합되었다. 이번 글은 REINDEERS가 무역 프로세스를 기술로 재정의한 과정을 기록한다. 1. 무역은 코드보다 복잡했다 REINDEERS의 출발점은 단순했다. “제조업과 유통을 연결하자.” 하지만 그 말 한 줄을 시스템으로 바꾸는 데 4년이 걸렸다. 무역은 전자상거래와 다르다. 주문에는 견적(Quote), 발주(PO), 납품서(DO), 상업송장(CI), 관세, 운송, 보험까지 포함된다. 각 단계가 독립적이지만 서로 연결되어야 한다. 한 문서가 늦으면 물류 전체가 멈춘다. 우리는 이 복잡한 절차를 단순한 버튼 하나로 연결해야 했다. 그 시작이 바로 **MCP (Multi-Commerce Platform)** 였다. 2. MCP — 무역 절차를 시스템화한 첫 구조 MCP는 단순한 백엔드 시스템이 아니었다. PO, DO, CI, BL, Payment, Refund 등 각 무역 단계를 독립된 서비스로 나누고, 메시지 큐(LavinMQ)를 통해 연결한 분산 구조였다. 각 서비스는 **이벤트 기반(Event-Driven Architecture)** 으로 작동했다. “견적 확정” 이벤트가 발생하면 자동으로 “운송 일정 생성”과 “결제 요청” 이벤트가 이어졌다. 관리자는 버튼을 누르지 않아도 업무가 진행되었다. ...