Blog

프로젝트 개요 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 ) 전자 서명 2단계 서명 프로세스 : Pickup (픽업 시) : Carrier (배송 기사) Vendor (판매자) Delivery (배송 시) : Carrier (배송 기사) Vendor (판매자) 서명 이미지를 base64로 저장 서버 업로드 후 PDF 생성 문서 관리 3가지 문서 타입 : PO (Purchase Ord...

1. IMARKET Thailand -- REINDEERS의 출발점 REINDEERS의 역사는 태국 법인 IMARKET Thailand Co., Ltd. 에서 시작되었다. 이 법인은 2015년 설립되어 11년 넘게 태국 산업재 유통 시장에서 활동해왔다. MRO(Maintenance, Repair, Operations) 제품을 중심으로 3만여 개 SKU를 관리하고, 2,000여 개 기업 고객을 직접 대응한 경험이 있었다. REINDEERS는 이 법인의 실제 유통, 조달 데이터 위에서 설계되었다. 기술보다 먼저 있었던 것은 산업이었다. IMARKET Thailand가 11년간 쌓은 거래 데이터, 구매 패턴, 납기 리듬이 오늘날 REINDEERS 데이터베이스의 기반이 되었다. CEO 김명훈은 동남아시아에서 20년 이상을 보낸 사람이다. 그가 2015년에 태국에 법인을 세운 것은 "플랫폼을 만들겠다"는 비전 때문이 아니었다. 태국 제조업체들이 산업재를 조달하는 방식이 너무 비효율적이라는 것을 현장에서 직접 목격했기 때문이다. 공장의 구매 담당자가 필요한 부품 하나를 주문하기 위해 전화 세 통, 팩스 두 장, 이메일 다섯 통을 보내는 것이 일상이었다. 그 비효율의 한가운데에서 사업이 시작되었다. 2. MRO -- 태국 제조업의 숨은 동맥 MRO는 Maintenance(유지보수), Repair(수리), Operations(운영)의 약자다. 공장이 돌아가기 위해 필요한 모든 소모품과 부품을 의미한다. 절삭공구, 베어링, 안전장비, 윤활유, 전기 자재, 배관 부속 -- 완성품에는 보이지 않지만 생산 라인이 멈추지 않기 위해 반드시 있어야 하는 것들이다. 태국은 동남아시아에서 가장 큰 제조업 기반을 가진 나라 중 하나다. 자동차, 전자, 식품 가공, 석유화학 -- 대규모 공장들이 방콕 외곽과 동부 해안 지역에 밀집해 ...

🇰🇷 플랫폼 매니저 (운영 / 글로벌 B2B & AI Agent 기반 자동화 플랫폼) 회사명: (주)레인디어스 | REINDEERS Co., Ltd. 근무지: 서울 / 방콕 (Hybrid 가능) 고용형태: 정규직 (계약-전환형 가능) 회사 소개 REINDEERS는 산업자재 및 무역 중심의 글로벌 B2B 플랫폼을 운영하는 기술 기반 기업입니다. 한국, 태국, 말레이시아, 중국 4개 주요 아시아 시장에서 견적–발주–물류(3PL)–통관–정산–재고관리(WMS)를 통합 관리하는 시스템을 제공합니다. REINDEERS는 POP과 DVRP를 AI로 전환되는 구조로 설계하고 있습니다. 사람은 전략과 방향을 결정하고, 실제 업무는 AI Agent가 실행하는 구조입니다. 조직도에 직원을 등록할 때 사람, AI Agent, 로봇 중에서 선택할 수 있으며, 같은 워크플로우와 같은 권한 체계로 협업합니다. CEO Agent가 전사 전략과 자원 배분을 총괄하고, 구매·생산·영업·물류·재무·통관 Agent가 각 부서 업무를 자율적으로 실행합니다. REINDEERS는 운영 중심의 플랫폼 관리 전문가를 찾습니다. 본 포지션은 플랫폼의 운영·유지·관리·발전·확장을 담당하며, 사람 담당자와 AI Agent, 그리고 향후 합류할 로봇 작업자가 같은 조직도 안에서 협업하는 환경을 관리하는 역할을 맡습니다. (※ 개발 업무를 직접 수행하지 않으며, 개발팀 및 AI Agent 팀과 협업해 개선을 주도합니다.) 이 포지션이 일하는 환경 REINDEERS는 POP과 DVRP를 "조직도 기반 AI 법인" 구조로 설계하고 있습니다. 외부 AI 도구를 연결하는 방식이 아니라, AI Agent가 회사 조직 구조에 직접 통합되어 있습니다. 플랫폼 매니저는 이 Agent들이 정상적으로 작동하는지 모니터링하고, 예외 상황에 대한 승인과 에스컬레이션을 처리하며, 사람 운영자와 AI Agent 간의 협업 경계를 정의하는 역할을 합니다. 현재는 Tool 단계(사...

1. Buybly의 한계 -- 이름보다 방향의 문제 Buybly는 2021년, 산업재와 소비재를 동시에 다루는 B2B 플랫폼으로 시작되었다. 이름은 "Buy + Easily"의 조합으로, 빠르고 간편한 구매를 의미했다. 하지만 시간이 지나면서 이 이름은 우리가 만들고자 한 시스템의 본질과 멀어졌다. Buybly는 거래 중심의 사고에서 출발했지만, REINDEERS는 데이터 중심의 사고 에서 출발했다. 우리는 "무엇을 팔 것인가"보다 "산업이 어떻게 연결되어야 하는가"를 고민하기 시작했다. 그 순간, Buybly라는 이름은 한계가 되었다. "Buy + Easily"라는 조합은 본질적으로 거래의 한쪽 면만 바라보고 있었다. 구매자의 편의. 하지만 B2B 무역에서 "쉽게 산다"는 것은 절반의 이야기에 불과하다. 공급사는 어떻게 연결되는가? 물류는 누가 조율하는가? 통관과 인증은 어느 시점에 처리되는가? Buybly라는 이름 아래에서 이런 질문들은 항상 부차적인 것으로 밀려났다. 이름이 사고를 제한하고, 사고가 제품을 제한했다. 실제로 Buybly 시절의 제품 로드맵을 보면, 대부분의 기능이 "구매 경험 개선"에 집중되어 있었다. 상품 검색 고도화, 장바구니 UI 개선, 결제 프로세스 간소화. 이것들은 B2C 전자상거래에서는 핵심 과제이지만, 제조업체와 공급사 사이의 국경 간 거래를 연결하는 플랫폼에서는 우선순위가 달랐다. 우리에게 진짜 필요한 것은 견적서 자동 생성, 다중 통화 정산, 선적 스케줄 연동, 규제 인증 자동 확인 같은 산업 인프라였다. 2. 리브랜딩의 출발 -- 철학부터 다시 세우다 리브랜딩은 단순한 네이밍 작업이 아니었다. Buybly는 기능적인 이름이었고, REINDEERS는 방향이 있는 이름이어야 했다...

1. 무역은 코드보다 복잡했다 REINDEERS의 출발점은 단순했다. "제조업과 유통을 연결하자." 하지만 그 말 한 줄을 시스템으로 바꾸는 데 4년이 걸렸다. 무역은 전자상거래와 다르다. 주문에는 견적(Quote), 발주(PO), 납품서(DO), 상업송장(CI), 관세, 운송, 보험까지 포함된다. 각 단계가 독립적이지만 서로 연결되어야 한다. 한 문서가 늦으면 물류 전체가 멈춘다. 우리는 이 복잡한 절차를 단순한 버튼 하나로 연결해야 했다. 그 시작이 바로 MCP (Multi-Commerce Platform) 였다. 2. 왜 무역 플랫폼은 전자상거래보다 어려운가 일반적인 전자상거래 플랫폼은 "상품 등록 - 결제 - 배송"이라는 비교적 단순한 흐름을 따른다. 통화는 하나이고, 규제는 한 국가의 법률만 따르면 되고, 물류는 국내 택배사에 위탁하면 된다. 하지만 국경을 넘는 B2B 무역은 완전히 다른 세계다. 첫째, 다중 통화(Multi-Currency) 문제가 있다. 태국 바트로 견적을 내고, 중국 위안으로 결제하고, 한국 원화로 정산하는 거래가 일상적이다. 견적 시점의 환율과 결제 시점의 환율이 다르면 마진이 증발하거나 손실이 발생한다. 환율은 하루에도 여러 번 변동하므로, 시스템은 견적 발행 시점의 환율을 고정하고, 결제 시점에 실시간 환율로 재계산하는 이중 구조를 가져야 한다. 둘째, 다중 언어(Multi-Language) 의 벽이 있다. 단순히 UI를 번역하는 것이 아니다. 상품명, 규격서, 인증서, 통관 서류까지 모든 것이 거래 당사자의 언어로 작성되어야 한다. 태국 구매 담당자가 보는 품목명과 중국 공급사가 등록한 품목명이 서로 대응되어야 하고, 통관 서류에는 또 다른 공식 명칭이 필요하다. 셋째, 다중 규제(Multi-Regulation...

1. 배경 - 이미 존재하던 주문 구조 REINDEERS의 주문 구조는 처음부터 복합적이었다. 견적형 주문과 바로구매형 주문이 병존하며, 포워딩과 운송 일정을 포함하는 다단계 프로세스가 이미 내부 MCP 환경에서 운용되고 있었다. 다만, 이 로직은 외부로 공개되지 않았고, 실제 서비스보다는 내부 자동화-테스트 환경에 최적화되어 있었다. 8번째 리빌드는 새로운 시스템을 만든 것이 아니라, 내부적으로 작동하던 고도화된 주문 엔진을 외부 고객사가 사용하는 서비스 레벨로 정식 통합하고 검증하기 위한 작업이었다. 2015년 IMARKET Thailand 설립 이후 수년간 운영해온 주문 로직이 7번의 리빌드를 거치며 내부적으로 성숙해 있었지만, 4,300개 이상의 파트너가 직접 사용하는 서비스 레벨에서는 다른 수준의 안정성이 요구되었다. 2. 문제 인식 - 로직 충돌과 중복 이벤트 내부 MCP 버전의 주문 시스템은 기능적으로 완성되어 있었지만, 확장성 측면에서는 한계를 드러냈다. 여러 Cloud Function과 MQ Exchange가 동시에 동일 이벤트를 수신하면서, 이벤트 중복 처리, 상태 불일치, TTL 만료 전 복구 불가 등의 문제가 반복되었다. # 과거 문제 사례 (중복 처리) [EVENT] payment.confirmed received (Q1) [EVENT] payment.confirmed received (Q4) → PO double-issued (2개의 purchase order 생성) → Redis TTL mismatch → DO 전환 실패 특히 포워딩 스케줄 확정 로직과 결제 처리 로직이 동시에 MQ를 발행하면서 순서가 어긋나는 경우가 발생했다. 그 결과, PO가 생성되기 전에 DO가 먼저 발행되거나, 운송 일정이 존재하지 않는 상태에서 통관 요청이 들어오는 등 논리적 오류가 다수 발견되었다. 이 문제는 내부 운영 환경에서는 수동 개입으로 해결할 수 있었다. 하지만 바이어 2,500곳, 공급사 1,800곳, 포워딩 업체 ...

1. 첫 번째 팀 -- 외주 개발사의 한계 REINDEERS의 첫 번째 팀은 외부 개발사였다. 계약은 단순했고, 목표는 "무역 플랫폼의 MVP 구축"이었다. 그러나 현실은 달랐다. 개발사는 무역을 이해하지 못했고, 제조 유통의 흐름을 전자상거래처럼 처리하려 했다. 결과적으로 견적(Quote), 주문(Order), 물류(Logistics), 결제(Payment)가 같은 테이블에 얽혀 있었다. 개발은 빨랐지만, 구조는 위험했다. 첫 번째 팀은 "코드를 만들었지만, 플랫폼은 만들지 못했다." 무역에서는 견적 하나가 여러 개의 발주서로 분리되기도 하고, 하나의 발주가 복수의 선적으로 나뉘기도 한다. 결제 조건은 T/T, L/C, D/A 등 거래 상대와 품목에 따라 완전히 달라진다. 외주 개발사는 이 모든 것을 하나의 "주문-결제" 테이블로 처리하려 했다. 일반적인 쇼핑몰이라면 가능한 설계였지만, B2B 무역에서는 첫 주부터 문제가 드러났다. 가장 치명적이었던 것은 통화(Currency) 처리였다. 태국 바트로 견적을 내고, 중국 위안으로 결제하고, 한국 원화로 정산하는 구조를 외주팀은 전혀 고려하지 않았다. 환율 변동에 따른 마진 계산, 선적 시점과 결제 시점의 환차손 -- 이런 것들은 사양서에 한 줄로 적혀 있었지만, 실제로 구현하려면 완전히 다른 데이터 모델이 필요했다. 외주팀에게 이것은 "추가 요구사항"이었지만, 우리에게는 플랫폼의 본질이었다. 2. 두 번째 팀 -- 내부화의 첫 시도 두 번째 시도는 "내부 개발팀 구성"이었다. 외주가 실패한 이유를 외부 탓으로 돌릴 수 없다고 판단했기 때문이다. 관리 인력과 몇 명의 풀스택 개발자가 합류해, 직접 시스템을 만들기 시작했다. 하지만 문제는...