Blog

1. 개발 환경의 목표 — '사람 없이도 일관된 결과' REINDEERS의 개발 환경은 단 하나의 목표를 갖고 설계되었다. "사람이 없어도 코드 품질과 배포 결과가 동일해야 한다." 이를 위해 모든 개발 환경은 완전히 동일한 컨테이너 기반으로 세팅되었고, 환경 편차나 로컬 의존성 문제는 제거되었다. 개인의 환경은 존재하지 않으며, 모든 환경은 dev , staging , production 세 단계로 통합 관리된다. 이 목표가 생긴 배경이 있다. 팀이 네 번 교체되면서 매번 겪었던 문제가 "내 PC에서는 되는데 서버에서는 안 된다"였다. 운영체제 버전, 런타임 버전, 로컬에 설치된 라이브러리의 차이가 빌드 결과의 불일치를 만들어냈다. 특히 4개국(태국, 한국, 중국, 말레이시아)에 분산된 개발자들이 각자 다른 환경에서 작업하면 이 문제는 기하급수적으로 커진다. 컨테이너화된 개발 환경은 이 문제를 원천적으로 해결한다. 누가, 어디서 빌드하든 결과가 동일하다. 표준 개발 환경 구조 # Dockerfile (공용 개발환경) FROM node:20-bullseye RUN apt-get update && \ apt-get install -y python3 python3-pip vim curl git && \ pip install pre-commit flake8 WORKDIR /app COPY package*.json ./ RUN npm ci COPY . . CMD ["npm", "run", "dev"] 모든 개발자는 동일한 컨테이너 이미지를 사용하며, 코드 수정 시 Dr...

1. 요구조건에서 시작한 '새 플랫폼' 선언 Quote → PO → Invoice → Delivery → Settlement 전체 흐름이 단일 데이터 체인 으로 연결될 것 국가/언어/통화/세율/물류 규칙을 데이터 레이어 에서 통합 관리할 것 데이터 변화가 이벤트(AMQP) 를 통해 실시간 전파되고 캐시와 UI가 자동 갱신될 것 사람이 문서/툴을 조작하지 않아도 AI 워크플로우 가 명세→스키마→API→배포를 자동 생성할 것 이 요구는 곧 플랫폼의 재정의 였다. "코드가 데이터를 설명"하던 과거에서, " 데이터가 코드를 지배 하는" 구조로의 전환. 이 관점에서 전 계층을 다시 설계했다. 이 요구조건이 왜 기존 시스템으로는 충족될 수 없었는지를 구체적으로 짚어보자. 기존 시스템에서 견적(Quote)과 주문(PO)은 별개의 데이터 저장소에 관리되고 있었다. 견적서에 적힌 단가와 실제 주문에 반영된 단가가 일치하는지 확인하려면 두 개의 테이블을 수동으로 조인해야 했고, 그 과정에서 환율 변환 시점이 달라 금액 불일치가 발생하는 경우가 잦았다. 4개국(태국, 한국, 중국, 말레이시아)의 거래에서 THB, KRW, CNY, MYR, USD라는 5개 통화가 오가는 환경에서 이런 불일치는 단순한 기술 버그가 아니라 비즈니스 신뢰 문제였다. 2. 기존 시스템이 막혀 있던 구체적 지점들 패치로는 해결할 수 없었던 구조적 한계를 정리하면 다음과 같다. 다국어/다통화 하드코딩: i18n 텍스트가 프런트엔드 컴포넌트에 직접 삽입되어 있었다. 새 언어를 추가하려면 수백 개 파일을 수정해야 했다. 단일 리전 종속: 모든 데이터가 싱가포르 리전에 있어서, 태국 바이어와 한국...

MCP 아키텍처 설계기 — 글로벌 인프라의 뼈대를 세우다 2025년 5월, REINDEERS 플랫폼의 인프라 재설계가 본격적으로 시작되었다. 4월 한 달 동안 우리는 기존 시스템을 전면 점검했고, AWS 싱가폴 리전에 산재된 비효율적인 구조를 확인했다. CI/CD는 단순 스크립트 수준에 머물렀고, 운영 스테이지도 명확히 구분되지 않았다. 소스 관리조차 통합되지 않아 빌드가 환경마다 달랐다. 결국 우리는 아키텍처를 완전히 다시 세워야 했다. MCP가 무엇인가 — 아키텍처적 정의 MCP는 Multi-Commerce Platform의 약자다. 단일 서비스가 아니라 5개의 독립 플랫폼이 하나의 메시지 브로커를 중심으로 연결된 구조를 가리킨다. 각 플랫폼은 고유한 도메인을 담당하면서도, 무역 거래의 전체 흐름 안에서 하나의 시스템처럼 동작해야 한다. 5개 플랫폼이 독립적으로 동작하면서도 거래 데이터를 일관되게 공유해야 하는 요구사항은 기존의 모놀리식 구조로는 해결할 수 없었다. 견적 플랫폼에서 생성된 PQ(Price Quotation)가 공급사 플랫폼의 QA(Quote Answer)와 연결되고, 이것이 다시 QB(Quote Back) - PO(Purchase Order) - DO(Delivery Order) - FWD(Forwarding) - Pay - Settlement으로 이어지는 무역 거래의 흐름은 각 플랫폼 간의 정교한 이벤트 전달 없이는 성립하지 않는다. 왜 이벤트 드리븐인가 — Request-Response를 버린 이유 초기 설계에서 플랫폼 간 통신을 REST API 기반 동기 호출로 구현하는 안을 검토했다. 거래 플랫폼이 공급사 플랫폼의 API를 직접 호출하고, 응답을 받아 다음 단계로 진행하는 방식이다. 이 구조의 문제는 무역 거래의 특성에서 드러난다. PO가 확정되면 동시에 여러 일이 발생해야 한다. 공급사에 생산 지시가 전달되고, 포워딩 플랫폼에서 물류 견적 준비가 시작되며, 결제 플랫폼에서 선수금 요청이 생성되고,...

1. 리빌드의 시작 — 사람부터 바꿨다 2025년 4월 초, REINDEERS는 중대한 결정을 내렸다. 시스템을 새로 만드는 일보다 먼저, 사람을 바꾸기로 한 것이다. 플랫폼은 기술로 움직이지만, 운영의 일관성을 무너뜨리는 것은 언제나 사람이다. 결국 기존 직원들은 모두 퇴사했다. 이전 팀은 실험적이었지만, 운영 가능한 구조를 만들기엔 역부족이었다. 남은 것은 코드 일부와 배포 스크립트뿐이었다. 우리는 그 위에 새로운 문화를 세우기보다, 완전히 새 팀을 만드는 길을 선택했다. 이것이 네 번째 팀 교체였다. 2015년 IMARKET Thailand 창업 이후 10년 동안 팀이 네 번 바뀌었다는 사실은 글로벌 스타트업이 겪는 현실을 그대로 보여준다. 2. 새 팀의 탄생 — 기술 커트라인부터 통과해야 했다 신규 채용의 기준은 단순했다. " 운영 가능한 기술을 이해하는가 ." 단순히 코드를 작성할 줄 아는 개발자가 아니라, 시스템이 어떻게 동작하고 복제되며, 장애를 어떻게 복구해야 하는지를 아는 엔지니어만이 합류할 수 있었다. 기술 커트라인 (필수 항목) Nuxt 3 / Vue3 + SSR 구조 이해 API 서버 설계 경험 CI/CD 파이프라인 구축 및 유지 경험 COS/CDN 배포 자동화 경험 Redis TTL 관리, MQ(AMQP) 이벤트 설계 경험 Git 브랜치 전략 및 Pull Request 프로세스 숙지 테스트 주도 개발(TDD) 환경 설정 경험 신규 구성원들은 모두 위 기준을 통과해야 했으며, 각자 DevOps, Front, API, Data, AI 셀로 배치되었다. 시스템 설계...

1. MCP(Modular Cloud Platform) 개요 MCP는 REINDEERS의 핵심 인프라 아키텍처로, 모든 기능을 독립된 모듈로 분리하고, 각 모듈이 자체 CI/CD 파이프라인을 통해 배포되며, 장애 시 자동으로 재배포 및 복구되는 구조를 목표로 설계되었다. 모듈화: 모든 서비스(API, AI, 물류, 결제, WMS 등)는 컨테이너 단위로 격리 복제: 리전 간 데이터 실시간 복제 (DTS + GTID 기반) 자동화: Drone CI/CD, COS 업로드, CDN 캐시 자동 무효화 보안: IAM 최소 권한, HTTPS + mTLS 내부 통신, VPC 내 Private Endpoint MCP라는 이름에 "Modular"가 들어간 이유는 명확하다. REINDEERS는 단일 서비스가 아니다. 거래 플랫폼(REINDEERS), 물류 SaaS(DVRP), 생산/재고 관리(POP), 문서 자동화(Document AI), 업무 자동화(Workflow AI)까지 5개의 플랫폼이 하나의 생태계를 이루고 있다. 이 플랫폼들이 독립적으로 배포되면서도 데이터와 이벤트를 공유하려면, 처음부터 모듈 간 경계가 명확하게 정의되어야 한다. MCP는 이 경계를 인프라 수준에서 강제하는 구조다. 2. 왜 이벤트 드리븐인가 — 일반 커머스 플랫폼과의 차이 일반적인 이커머스 플랫폼은 요청-응답(Request-Response) 패턴으로 충분하다. 사용자가 주문하면 서버가 처리하고 결과를 돌려준다. 하지만 B2B 무역 플랫폼은 다르다. 하나의 거래가 견적 → 주문 → 인보이스 → 선적 → 통관 → 정산이라는 긴 생명주기를 가지며, 각 단계마다 다른 주체(바이어,...

1. 초기 상황 — AWS 싱가포르, 복잡하게 얽힌 실험의 흔적 REINDEERS 초기 버전은 AWS ap-southeast-1 (Singapore) 리전 위에서 운영되었다. 하지만 이는 서비스 운영을 위한 구조가 아니라 "학습" 중심의 환경에 가까웠다. EC2, S3, RDS, CloudFront, Lambda 등 AWS 주요 기능이 모두 혼재했지만, 어떤 구성요소도 서로 명확히 연결되어 있지 않았다. 인프라 구성 예시 (기존 AWS) VPC (10.0.0.0/16) ├── Subnet-Public (10.0.1.0/24) │ ├── EC2: react-build-server │ └── EC2: spring-api-server ├── Subnet-Private (10.0.2.0/24) │ ├── RDS: mysql-v1 │ └── ElasticCache: disabled └── SecurityGroup: default (80/443 open to 0.0.0.0/0) IAM은 Root Key로 접근했고, Auto Scaling Group은 설정만 되어 있을 뿐 실제 트리거가 비활성화되어 있었다. CloudFront는 S3 버킷에 연결되어 있었지만, TTL(캐시 수명) 설정이 24시간으로 고정되어 실시간 반영이 어려웠다. API 응답 속도는 태국에서 평균 620ms, 말레이시아에서 710ms로 측정됐다. 이 수치는 글로벌 B2B 플랫폼으로는 치명적이었다. 감사(audit) 과정에서 가장 먼저 확인한 것은 인프라의 가동률이었다. Auto Scaling이 비활성화되어 있다는 것은, 트래픽 증가에 대한 대응 능력이 사실상 없다는 의미였다. 태국과 말레이시아의 바이어가 동시에 접속하는 시간대(오전 9시~11시 현지 시간)에 서버 부하가 집...

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