Skip to main content

2025년 12월 01일 이후, R&D에서 보는 다음 단계

2025-12-01 이후, 개발팀이 보는 다음 단계

2025년 12월 1일, reindeers.com은 "정식 오픈"이라는 이름으로 서비스를 시작한다. 하지만 개발팀 입장에서 보면, 이 날은 완성의 순간이 아니라 "현장에서 검증을 시작하는 첫날"에 가깝다. 구조는 준비됐고, 데이터는 흐르기 시작했지만, 실제 사용자의 손을 타기 전까지는 알 수 없는 것들이 너무 많다. 2015년 IMARKET Thailand 설립 이후 10년간 축적한 B2B 운영 경험이 플랫폼 설계에 반영되어 있지만, 디지털 전환 이후의 사용자 행동은 오프라인과 다를 수밖에 없다.

1) 초기 오픈 후, 항상 다시 드러나는 현실적인 문제들

플랫폼을 초기 오픈하면 공통적으로 반복되는 현상이 있다. REINDEERS도 예외는 아니다.

  • 업무 플로우와 화면 흐름의 괴리
    기획·설계 단계에서 수십 번 회의를 거친 플로우라고 해도, 실제 고객사/공급사가 사용하는 순간 "이 단계는 너무 길다", "이 정보는 이 타이밍에는 안 보인다" 같은 피드백이 나온다. 특히 견적 → 주문 → 생산/조달 → 물류 → 인도까지 이어지는 긴 체인은 한 단계만 UX가 어색해도 전체가 불편해진다. 바이어 2,500개 이상, 공급사 1,800개 이상이 서로 다른 업무 패턴을 가지고 있기 때문에, "표준 플로우"라는 것 자체가 모든 사용자에게 맞지 않는다.
  • 경계 케이스(edge case)의 폭발
    내부 테스트에서는 정상 플로우(happy path)를 중심으로 검증한다. 하지만 실제 환경에서는 "중간에 결제 방식을 바꾸고 싶다", "견적은 두 개 받고 PO는 하나로 묶고 싶다", "수출은 취소됐지만 내수 전환을 하고 싶다" 같은 복합 케이스가 튀어나온다. 25,000건 이상의 실거래 데이터를 분석해보면, 표준 플로우대로 진행된 거래는 전체의 60~70% 수준이고 나머지는 모두 변형이다. 이때는 플로우 설계 자체를 손봐야 하는 경우도 생긴다.
  • 개념어에 대한 이해 차이
    내부에서는 당연히 통하는 단어(예: DO, ASN, OSN, 결제국, 고객사/공급사 구분 등)가 실제 사용자에게는 처음 듣는 용어일 수 있다. 용어 하나 때문에 입력을 멈추거나, 잘못된 메뉴로 들어가는 일이 반복되면 결국 "시스템이 어렵다"는 인식으로 이어진다. 특히 한국, 태국, 말레이시아, 중국 4개국 사용자가 같은 시스템을 쓰기 때문에, 용어의 다국어 매핑도 정확해야 한다.
  • 성능과 부하 패턴의 현실
    우리가 예상한 트래픽 패턴과 실제 사용 패턴이 항상 일치하는 것은 아니다. 특정 국가의 업무 시간이 겹치거나, 정산·마감일에 API 호출이 몰리면 DB 쿼리·캐시 미스·MQ 대기열 같은 요소들이 한 번에 드러난다. $130B 이상 규모의 시장을 대상으로 하는 만큼, 트래픽 규모가 급성장할 가능성에 대비한 확장성 검증도 필요하다.

2) UX/사용 편의성 측면에서 남아 있는 과제들

REINDEERS 플랫폼의 기본 구조는 "업무 단위 중심"으로 설계했지만, 정식 오픈 이후에는 더 구체적인 UX 개선이 필요하다.

  • "목록 → 상세" 중심에서 "상황 → 작업" 중심으로
    전통적인 B2B 시스템은 리스트를 보여주고, 그 안에서 검색하게 만드는 구조가 많다. 하지만 실제 현장은 "오늘 내가 해야 할 일" 기준으로 움직인다. 개발적으로는 /tasks/today 같은 관점의 API와 화면이 더 필요하다. 예: "오늘 승인해야 할 견적", "오늘 마감해야 할 PO", "오늘 출고되는 오더"를 한 번에 묶어서 보여주는 뷰. 이 접근은 단순한 대시보드가 아니라, 사용자의 역할(바이어/공급사/물류담당)에 따라 보여지는 항목과 우선순위가 달라지는 컨텍스트 기반 UI다.
  • 국가별 UX 패턴 차이 반영
    태국, 한국, 말레이시아, 중국의 사용자들은 같은 화면을 보더라도 우선순위가 다르다. 어떤 국가는 모바일 우선, 어떤 국가는 데스크톱 + 인쇄물을 선호한다. 이 차이는 단순 반응형 레이아웃이 아니라, "어떤 정보를 첫 화면에서 보여줄 것인가" 수준에서 다시 설계해야 한다. 태국의 경우 LINE 메신저 기반의 알림이 이메일보다 훨씬 효과적이고, 한국은 카카오톡, 중국은 WeChat이 주요 채널이다. 알림 채널 다변화도 UX 과제에 포함된다.
  • 에러 메시지와 피드백의 정제
    현재 시스템은 주로 개발자 관점의 에러 메시지 구조를 가지고 있다. 예를 들어 "필수 필드 누락"이 아니라 "픽업 날짜를 선택해야 다음 단계로 진행할 수 있습니다"처럼 실제 업무 언어로 메시지를 바꾸는 작업이 필요하다. 이 작업은 단순 번역이 아니라, 각 에러 상황에서 사용자가 "다음에 무엇을 해야 하는지"를 안내하는 것이 핵심이다.
  • 초기 온보딩 흐름
    고객사/공급사가 처음 로그인했을 때, "무엇을 먼저 설정하고 무엇을 먼저 등록해야 하는지"를 안내하는 온보딩 플로우가 아직은 얇다. 개발적으로는 onboarding_state 플래그와, 필요한 체크리스트를 묶어 주는 API/화면 구성이 다음 단계에서 필요하다. 회사 정보 등록, 상품 카탈로그 업로드, 배송지 등록, 결제 수단 설정 등의 필수 단계를 명확히 가이드해야 첫 거래까지의 이탈률을 줄일 수 있다.

3) 기술적으로 해결해야 할 부분들 — 관측, 안정성, 구조 보완

인프라와 아키텍처는 이미 구체적으로 설계되어 있지만, 정식 오픈 이후에는 "코드를 더 쓰는 것"보다 지금 만들어 놓은 구조를 얼마나 안정적으로 운영할 수 있는가가 더 중요해진다.

  • 관측 가능성(Observability) 강화
    현재도 구조화 로그와 기본 메트릭은 수집하고 있지만, 다음 단계에서는 비즈니스 이벤트 단위의 모니터링이 필요하다. 예를 들어, "견적 생성 → 주문 확정까지 평균 소요 시간", "DO 생성 후 실제 출고까지의 병목 구간" 등을 바로 확인할 수 있어야 한다. 이를 위해 MQ 소비 속도, DB 쿼리 지연, 프론트 응답 시간 등을 하나의 대시보드에서 연결해서 보는 작업이 남아 있다. NCP Cloud Functions 기반의 서버리스 환경에서는 콜드 스타트 지연도 관측 대상에 포함해야 한다.
  • DB 쿼리/인덱스 튜닝
    250개 이상의 테이블 구조는 설계 단계에서 최대한 정규화하고 인덱스를 잡았지만, 실제 쿼리 패턴은 항상 예상과 다르다. 정식 오픈 이후에는 slow query 로그를 기준으로
    • 실제 사용 빈도가 높은 조회 API의 쿼리 재작성
    • 복합 인덱스 추가 및 불필요 인덱스 제거
    • 리포트용 쿼리를 별도 테이블/뷰로 분리
    같은 작업이 순차적으로 필요하다.
  • MQ 및 비동기 작업의 백프레셔(Backpressure) 설계
    환율 크롤링, 카테고리 재생성, 번역, 외부 문서 파싱 등은 Cloud Functions + MQ 기반으로 비동기 처리되고 있다. 정식 오픈 후에는 특정 시점(마감, 캠페인, 신규국가 런칭 등)에 큐가 한 번에 몰리는 상황이 생길 수 있다. 메시지 재시도 정책, DLX(Dead Letter Queue), 소비자 수 자동 조정 전략을 더 정교하게 잡아야 한다. 현재 환율 크롤링만 해도 4개국(태국, 한국, 중국, 말레이시아) 은행 데이터를 NCP Cloud Functions에서 병렬로 수집하고 있는데, 이 작업이 다른 비동기 작업과 리소스를 경합하지 않도록 큐 우선순위를 설정해야 한다.
  • 멀티 리전 데이터 일관성
    홍콩-서울 MySQL 이중화 구조에서, 읽기/쓰기 패턴과 네트워크 상황에 따라 레이턴시나 레플리카 지연이 발생할 수 있다. 어느 API는 반드시 Master를 읽어야 하고, 어느 API는 Replica를 읽어도 되는지에 대한 룰을 더 구체적으로 나눠야 한다. 특히 주문/결제/정산 관련 데이터는 강한 일관성을 유지해야 하므로, 이 영역의 접근 정책을 한 번 더 정리하는 것이 필요하다.
  • 기능 플래그(Feature Flag)와 무중단 배포
    프론트는 COS/CDN을 통해 정적 배포되고, 백엔드는 점진적으로 롤링 업데이트를 적용하고 있다. 정식 오픈 이후에는 "국가별로 기능을 다르게 켜고 끄는" 시나리오가 많아질 것이기 때문에, 코드 수준에서 feature_flags를 관리하고 국가/회사/역할별로 다른 경험을 제공하는 구조가 필요하다. 예를 들어 DVRP 기능은 2026년 3월 베타 단계에서 특정 고객사에게만 먼저 열고, POP 기능은 2026년 4~5월에 순차적으로 오픈하는 방식이다.
  • DVRP 연동을 위한 이벤트 스키마 고정
    2026년 3월 DVRP 오픈을 고려하면, 지금부터는 주문·DO·ASN/OSN 관련 이벤트 스키마를 함부로 바꾸지 않는 것이 중요하다. 재사용 가능한 이벤트 포맷을 고정하고, 버전 관리(event_version)와 event_type 규칙을 함께 정의해 두어야 나중에 WMS + DVRP 통합 시 불필요한 마이그레이션을 줄일 수 있다.

4) 오픈 이후의 방향

2025-12-01 정식 오픈은 REINDEERS 입장에서는 큰 이정표다. 하지만 개발팀 입장에서 보면, 이것은 장기 운영을 전제로 한 베이스라인 확정에 가깝다. 이제부터는 기능을 많이 만드는 것보다, 이미 만들어 둔 구조를 얼마나 안정적이고, 쓰기 편하고, 다른 시스템(DVRP 포함)과 연결하기 좋은 형태로 다듬느냐가 더 중요하다.

구체적인 로드맵으로 보면, 정식 오픈 직후 3개월은 안정화와 UX 개선에 집중하고, 2026년 3월 DVRP 베타, 4~5월 POP 베타가 순차적으로 이어진다. 각 단계에서 발생하는 문제와 해결 과정을 기록으로 남기는 것이 REINDEERS 기술 블로그의 역할이다.

우리는 이 글을 "끝난 이야기"로 남기고 싶지 않다. 오픈 이후에 드러나는 문제들을 기록하고, 그 문제를 어떤 기술적·논리적 선택으로 해결해 나갔는지 계속해서 남길 예정이다. 그것이 REINDEERS 개발팀이 생각하는 진짜 "플랫폼 운영"에 가깝기 때문이다.

관련 글

Labels:

Popular posts from this blog

Reindeers Workflow: B2B 파트너 업무 효율과 자동화를 위한 워크플로우 플랫폼

B2B 국제 무역에서 하나의 거래가 완료되기까지 관여하는 시스템과 사람의 수는 예상보다 훨씬 많다. 견적 요청에서 시작해 공급사 선정, 발주, 포워딩 비딩, 통관 서류 준비, 출하, 배송, 정산까지 — 각 단계마다 서로 다른 담당자가 서로 다른 도구에서 수작업을 반복한다. 이 현장에서 반복적으로 발생하는 비효율은 분명하다. 바이어가 견적을 확정하면 공급사에게 이메일이나 메신저로 직접 통보해야 하고, 결제가 완료되면 수동으로 정산 시트에 옮기면서 1~3일이 소요된다. 출하 후에는 선적 정보를 기반으로 CI, PL, CO를 수동 생성하며 누락이 발생하고, 배송 완료 후 공급사/포워더 정산을 수작업으로 대조하면서 오차가 누적된다. ERP, 이메일, 스프레드시트, CRM에 같은 데이터를 반복 입력하는 것도 일상이다. 이 문제들의 공통점은 명확하다. "이벤트가 발생했을 때 후속 작업이 자동으로 실행되지 않는다" 는 것이다. 견적이 확정되었다는 '사실'은 시스템에 기록되지만, 그 사실이 다음 단계의 업무를 자동으로 트리거하지는 않는다. Reindeers Workflow는 이 문제를 해결하기 위해 만들어졌다. 단순히 "자동화 도구를 제공한다"가 아니라, REINDEERS 플랫폼에서 발생하는 실제 거래 이벤트를 기반으로 후속 업무가 자동 실행되는 구조를 만드는 것이다. REINDEERS 플랫폼과의 연결: 거래 이벤트가 워크플로우를 트리거한다 Reindeers Workflow의 가장 중요한 차별점은 범용 자동화 도구가 아니라 REINDEERS 본 플랫폼의 거래 이벤트에 직접 연결 된다는 것이다. REINDEERS에서 발생하는 핵심 거래 이벤트가 MQ(Message Queue)를 통해 워크플로우의 트리거가 된다. 거래 이벤트 트리거되는 워크플로우 실행 내용 quote.confirmed 공...
Read more

레인디어스, Buybly로 동남아시아 산업자재 시장 혁신

B2B 오픈마켓 REINDEERS, 한국 기업의 글로벌 진출을 돕다 레인디어스, 머신러닝 기반의 산업자재 매칭 솔루션으로 경쟁력 강화 김명훈 레인디어스 대표 산업자재 시장의 복잡성과 유통장벽은 많은 기업들에게 큰 도전 과제가 되어왔다. 특히 동남아시아 시장 진출을 원하는 한국의 산업자재 제조사들은 현지의 불투명한 거래 환경과 물류 문제로 어려움을 겪어왔다. 이러한 상황에서 레인디어스의 REINDEERS 플랫폼은 새로운 기회를 제시하고 있다. REINDEERS는 B2B 오픈마켓으로, 한국 기업들이 손쉽게 동남아시아 시장에 진출할 수 있도록 지원하며, 유통의 복잡성을 해결하는 혁신적인 솔루션으로 주목받고 있다. 이러한 변화의 중심에는 레인디어스 대표가 있다. 그는 지난 9년간 태국에서의 경험을 바탕으로 고객의 pain point를 해결하기 위해 REINDEERS를 개발했다. 이번 인터뷰를 통해 그의 비전과 경영 철학, 그리고 REINDEERS가 어떻게 산업자재 시장을 변화시키고 있는지에 대해 깊이 있는 이야기를 나누게 되었다. 김명훈 레인디어스 대표 -.소개 레인디어스는 국내 산업자재 제조사들이 동남아시아 시장에 쉽게 진출할 수 있도록 돕는 B2B 오픈마켓인 REINDEERS를 운영하고 있다. 해외 시장 진출에서 가장 큰 장애물인 유통, 물류, 무역의 장벽을 해결해주는 것이 이 플랫폼의 핵심이다. REINDEERS는 단순한 거래 플랫폼이 아니라, 산업자재 구매와 공급 과정을 간소화하고 최적화하는 One-Stop 솔루션으로 자리 잡았다. 레인디어스의 서비스는 REINDEERS와 Enterprise Solution(ERP, POP, WMS)으로 구성되어 있다. 이 솔루션은 동남아시아 현지의 고객사와 공급사에 맞춤형으로 제공되며, 산업현장의 선진화를 이끌어낸다. 기업 운영과 생산 관리, 재고 관리를 전산화해 이익을 극대화하는 데 기여하고 있다. REINDEERS는 산업현장에서 획득한 Raw data를 활용해 인공지능 분석을 통해 발주 ...
Read more

JD 플랫폼 매니저 (Platform Manager )

🇰🇷 플랫폼 매니저 (운영 / 글로벌 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 단계(사...
Read more