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

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

2025년 12월 1일, reindeers.com은 “정식 오픈”이라는 이름으로 서비스를 시작한다. 하지만 개발팀 입장에서 보면, 이 날은 완성의 순간이 아니라 “현장에서 검증을 시작하는 첫날”에 가깝다. 구조는 준비됐고, 데이터는 흐르기 시작했지만, 실제 사용자의 손을 타기 전까지는 알 수 없는 것들이 너무 많다.

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

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

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

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

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

• “목록 → 상세” 중심에서 “상황 → 작업” 중심으로
  전통적인 B2B 시스템은 리스트를 보여주고, 그 안에서 검색하게 만드는 구조가 많다. 하지만 실제 현장은 “오늘 내가 해야 할 일” 기준으로 움직인다. 개발적으로는 /tasks/today 같은 관점의 API와 화면이 더 필요하다. 예: “오늘 승인해야 할 견적”, “오늘 마감해야 할 PO”, “오늘 출고되는 오더”를 한 번에 묶어서 보여주는 뷰.
• 국가별 UX 패턴 차이 반영
  태국, 한국, 말레이시아, 중국의 사용자들은 같은 화면을 보더라도 우선순위가 다르다. 어떤 국가는 모바일 우선, 어떤 국가는 데스크톱 + 인쇄물을 선호한다. 이 차이는 단순 반응형 레이아웃이 아니라, “어떤 정보를 첫 화면에서 보여줄 것인가” 수준에서 다시 설계해야 한다.
• 에러 메시지와 피드백의 정제
  현재 시스템은 주로 개발자 관점의 에러 메시지 구조를 가지고 있다. 예를 들어 “필수 필드 누락”이 아니라 “픽업 날짜를 선택해야 다음 단계로 진행할 수 있습니다”처럼 실제 업무 언어로 메시지를 바꾸는 작업이 필요하다.
• 초기 온보딩 흐름
  고객사/공급사가 처음 로그인했을 때, “무엇을 먼저 설정하고 무엇을 먼저 등록해야 하는지”를 안내하는 온보딩 플로우가 아직은 얇다. 개발적으로는 onboarding_state 플래그와, 필요한 체크리스트를 묶어 주는 API/화면 구성이 다음 단계에서 필요하다.

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

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

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

4) 결론 — “오픈이 끝이 아니라 시작”이라는 말을, 실제 구조로 증명해야 한다

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

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