Blog

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)** 으로 작동했다. “견적 확정” 이벤트가 발생하면 자동으로 “운송 일정 생성”과 “결제 요청” 이벤트가 이어졌다. 관리자는 버튼을 누르지 않아도 업무가 진행되었다. ...

주문 로직의 8번째 재개발: 내부 아키텍처의 표준화와 로직 충돌 해소 요약: 본 기록은 REINDEERS 플랫폼의 주문 시스템이 8번째 리빌드를 거쳐 기존 내부용 주문·운송 아키텍처를 공식 서비스 환경으로 이식하는 과정에서, 세부 로직 충돌과 중복 처리를 해소하고 구조를 정제한 기술적 내용을 다룬다. 이번 재개발은 새로운 기능 추가가 아닌, 이미 존재하던 구조를 외부 서비스 수준으로 재정렬하고 안정화한 프로젝트였다. 1. 배경 — 이미 존재하던 주문 구조 REINDEERS의 주문 구조는 처음부터 복합적이었다. 견적형 주문과 바로구매형 주문이 병존하며, 포워딩과 운송 일정을 포함하는 다단계 프로세스가 이미 내부 MCP 환경에서 운용되고 있었다. 다만, 이 로직은 외부로 공개되지 않았고, 실제 서비스보다는 내부 자동화·테스트 환경에 최적화되어 있었다. 8번째 리빌드는 새로운 시스템을 만든 것이 아니라, 내부적으로 작동하던 고도화된 주문 엔진을 외부 고객사가 사용하는 서비스 레벨로 정식 통합하고 검증하기 위한 작업이었다. 2. 문제 인식 — 로직 충돌과 중복 이벤트 내부 MCP 버전의 주문 시스템은 기능적으로 완성되어 있었지만, 확장성 측면에서는 한계를 드러냈다. 여러 Cloud Function과 MQ Exchange가 동시에 동일 이벤트를 수신하면서, 이벤트 중복 처리, 상태 불일치, TTL 만료 전 복구 불가 등의 문제가 반복되었다. # 과거 문제 사례 (중복 처리) [EVENT] payment.confirmed received (Q1) [EVENT] payment.confirmed received (Q4) → PO double...

팀을 네 번 교체하며 배운 것들 — 진짜 글로벌 팀을 만들기까지 요약: REINDEERS의 개발팀은 네 번의 전면 교체를 거쳤다. 각 시도마다 기술보다 중요한 것은 ‘이해’였고, 문화보다 중요한 것은 ‘책임’이었다. 실패의 반복 끝에, 우리는 기술 중심이 아니라 데이터·AI·협업 언어 로 움직이는 진짜 글로벌 팀을 만들었다. 1. 첫 번째 팀 — 외주 개발사의 한계 REINDEERS의 첫 번째 팀은 외부 개발사였다. 계약은 단순했고, 목표는 “무역 플랫폼의 MVP 구축”이었다. 그러나 현실은 달랐다. 개발사는 무역을 이해하지 못했고, 제조 유통의 흐름을 전자상거래처럼 처리하려 했다. 결과적으로 견적(Quote), 주문(Order), 물류(Logistics), 결제(Payment)가 같은 테이블에 얽혀 있었다. 개발은 빨랐지만, 구조는 위험했다. 첫 번째 팀은 “코드를 만들었지만, 플랫폼은 만들지 못했다.” 2. 두 번째 팀 — 내부화의 첫 시도 두 번째 시도는 “내부 개발팀 구성”이었다. 외주가 실패한 이유를 외부 탓으로 돌릴 수 없다고 판단했기 때문이다. 관리 인력과 몇 명의 풀스택 개발자가 합류해, 직접 시스템을 만들기 시작했다. 하지만 문제는 여전히 같았다. “기술은 있지만 이해가 없었다.” 플랫폼이 무엇을 해야 하는지보다, “어떻게 코드를 짤 것인가”에만 집중했다. 결과적으로 기능은 많았지만, 방향은 없었다. 3. 세 번째 팀 — ‘조직’은 있었으나 ‘구조’는 없었다 세 번째 팀은 형식적으로 완벽했다....

REINDEERS, 4년의 여정 — 동남아 제조업 혁신을 향한 출발점 요약: REINDEERS 프로젝트는 동남아 제조·유통 시장의 불균형을 해결하기 위해 시작된 글로벌 무역 플랫폼 구축 여정이었다. 4년에 걸친 시행착오 끝에, 기술 중심의 조직으로 재편되고 AI를 핵심 전략으로 채택하며 새로운 출발선을 맞이했다. 1. 출발 — 동남아 제조 유통의 혁신을 꿈꾸다 REINDEERS의 시작은 단순한 플랫폼 사업이 아니었다. 동남아 제조업체들이 글로벌 시장에 직접 접근하지 못하는 구조를 바꾸기 위한 시도였다. 태국, 말레이시아, 베트남의 수많은 중소 제조사는 여전히 전화와 이메일로 거래를 이어가고 있었고, 가격 비교·납기 관리·운송 연계 등 모든 과정이 수작업에 머물러 있었다. 이러한 현실을 개선하기 위해 우리는 “제조업 기반 B2B 무역 플랫폼”을 설계하기로 했다. 하지만 초기 단계에서 가장 큰 문제는 기술이 아니라 이해의 부족 이었다. 2. 외주 개발의 한계 2021년, 우리는 첫 번째 개발을 외주로 진행했다. 그러나 개발사는 무역의 구조와 산업재 유통의 특성을 이해하지 못했다. 전자상거래의 논리를 그대로 적용하려 했고, 복잡한 견적·PO·DO·물류 절차를 단일 주문 로직으로 단순화시켜버렸다. 결과적으로 플랫폼은 외형만 존재했을 뿐, 실제 무역 프로세스를 처리할 수 없었다. 외주 개발은 그 시점에서 중단되었다. 3. 내부 개발팀의 첫 시도와 실패 외주 프로젝트 종료 이후, 내부적으로 개발 관리 인력을 영입해 자체 개발을 시도했다. 그러나 시스템의 복잡성과 기술적 요구 수준은 생...

베타 오픈 준비: 국가별 시뮬레이션과 부하 테스트 자동화 요약: 본 기록은 REINDEERS 플랫폼의 베타 오픈 직전, 4개국(태국·한국·중국·말레이시아)을 대상으로 진행된 AI 주도형 시뮬레이션 및 부하 테스트 자동화 과정을 기술한다. Ops-Agent가 실제 사용자 트래픽을 재현하고, MQ·Redis·Cloud Function의 병목 구간을 자동 분석하며, 시스템이 스스로 최적화·복구되는 구조를 완성하였다. 1. 테스트 목적과 시나리오 설계 베타 오픈을 앞두고 가장 중요한 검증 항목은 세 가지였다. 1) 다국가 접속 부하 분산 — 각국 DNS 및 CDN 라우팅 검증 2) 데이터 일관성 — Redis와 MQ의 복제 지연 검증 3) 무중단 배포 및 장애 복구 — Cloud Function의 자율 회복 테스트 테스트는 AI Ops-Agent가 생성한 가상 세션을 이용해 수행됐다. 각국의 평균 사용 환경(네트워크 속도·언어·기기 비율)을 기반으로 50,000명의 가상 사용자를 생성하고, 실제 주문, 견적, 채팅, 결제 시나리오를 반복 실행했다. 2. 트래픽 시뮬레이션 구조 모든 부하 테스트는 실제 트래픽과 동일하게 처리되도록 설계되었다. AI Ops-Agent는 Playwright 기반의 브라우저 클러스터를 이용해 각국 DNS를 통해 접속하며, 트래픽은 Cloud Function → MQ → Redis → DB로 실제 서비스 경로를 그대로 통과한다. { "country": "TH", "user_id": "TH_839210", "actions": [...

AI 품질 보정과 데이터 재생산 파이프라인 요약: 본 기록은 Translator-Agent 2.0의 도입 이후, AI가 자체적으로 번역 품질을 평가하고 품질 기준 이하의 데이터를 자동 보정·재생산하는 구조를 정립한 과정을 기술한다. BLEU/TER 점수 기반 평가, 품질 예측 모델, 재번역 큐 관리, 인간 승인 없는 자동 검증 루프를 포함한다. 1. Translator-Agent 2.0의 설계 목표 9월 초부터 수집되는 데이터의 양이 폭증하면서 AI 번역 품질이 일관되지 않다는 문제가 보고되었다. 평균 BLEU 점수는 0.82 수준이었지만 언어 간 편차가 컸고, 특정 기술 문서에서 용어가 반복적으로 오역되었다. Translator-Agent 2.0의 목적은 **AI가 스스로 품질을 예측하고, 낮은 품질의 데이터를 재생산하도록 만드는 것**이었다. BLEU, TER, Context Vector를 이용한 품질 점수화 자동 재번역 루프 (Re-Translation Loop) Quality-Driven Event Routing (품질 점수 기반 라우팅) 자동 승인 및 검증 리포트 생성 2. 품질 평가 메커니즘 Translator-Agent 2.0은 번역이 완료되면 즉시 BLEU와 TER을 계산하고, 품질 점수를 생성한다. 이 점수는 0~1 사이 실수값으로 표현되며, 0.75 미만이면 재번역 큐에 등록된다. BLEU는 의미 유사도, TER은 문장 수정 비율을 측정한다. 품질 점수는 Redis의 Sorted Set에 저장되어 우선순위 처리가 가능하다. score = (bleu * 0.7 + (1 - ter) * 0.3) redis.zadd("i18n.qualit...