1. 출발 -- 2015년, 태국에서 시작하다
2015년, IMARKET Thailand가 태국 방콕에서 설립되었다. 왜 태국이었는가. CEO 김명훈 대표가 20년 이상 동남아에서 사업을 해온 경험에서 나온 선택이었다. 태국은 ASEAN에서 제조업 기반이 탄탄한 국가 중 하나였고, 한국 기업의 진출이 활발했으며, MRO(유지보수/수리/운영) 산업재 유통에 명확한 수요가 있었다.
초기 사업 모델은 플랫폼이 아니었다. 태국 내 제조업체에 산업재를 공급하는 MRO 유통 사업이었다. 공장에서 필요한 베어링, 공구, 안전장비, 화학제품 등을 한국, 중국, 일본 공급사로부터 조달해서 태국 현지 공장에 납품했다. 전화, 이메일, 엑셀로 운영했다. 당시에는 그것이 업계 표준이었다.
2. 2016-2019: 고객 기반 구축, 시장의 현실 학습
4년간 태국 현지에서 직접 영업하고, 납품하고, 클레임을 처리하며 산업재 B2B 무역의 실상을 배웠다.
고객 수는 점진적으로 늘어 2,500개 이상의 바이어 관계가 형성되었다. 동시에 한국, 중국의 공급사 네트워크도 1,800개 이상으로 확장되었다. 이 숫자는 마케팅으로 모은 것이 아니라 실제 거래를 통해 쌓인 것이다. 한 건 한 건의 견적, PO, 인보이스, 납품을 거치며 신뢰가 만들어졌다.
이 시기에 배운 것들이 나중에 플랫폼 설계의 핵심이 되었다.
첫째, 동남아 산업재 무역의 비효율은 구조적이라는 것. 바이어가 공급사를 찾으려면 전시회에 가거나 지인을 통해야 했다. 가격 비교는 담당자가 공급사별로 전화를 돌려 엑셀에 정리했다. 물류 추적은 포워더에게 매번 전화하는 것이었다. 이 비효율은 개별 기업의 문제가 아니라 산업 전체의 문제였다.
둘째, 국가마다 규제와 관행이 완전히 다르다는 것. 태국의 VAT 7%, 한국의 VAT 10%, 중국의 증치세 13%. 태국의 TISI 인증, 한국의 KC 인증, 중국의 CCC 인증. 통관 절차, 결제 관행, 인보이스 형식까지 모두 달랐다. 하나의 시스템으로 이것을 처리하려면 데이터 모델부터 다르게 설계해야 한다는 것을 깨달았다.
셋째, B2B 무역은 B2C와 근본적으로 다르다는 것. B2C는 "장바구니에 넣고 결제"하면 끝이다. B2B는 견적 요청, 가격 협상, PO 발행, 생산 확인, 선적 예약, 통관, 납품, 정산까지 수주에서 수개월이 걸리는 복합 프로세스다. 쇼핑몰 로직을 적용할 수 없다.
3. 2020-2021: 플랫폼 결심, 첫 번째 시도
2020년, 결정을 내렸다. 더 이상 전화와 엑셀로는 성장에 한계가 있었다. 2,500개 이상의 바이어, 1,800개 이상의 공급사를 수작업으로 관리하는 것은 인력의 한계에 부딪히고 있었다. 동남아 제조업체들이 글로벌 시장에 직접 접근하지 못하는 구조를 바꾸기 위한 플랫폼을 만들기로 했다.
2021년, 첫 번째 개발을 외주로 진행했다. 그러나 개발사는 무역의 구조와 산업재 유통의 특성을 이해하지 못했다. 전자상거래의 논리를 그대로 적용하려 했고, 복잡한 견적, PO, DO, 물류 절차를 단일 주문 로직으로 단순화시켜버렸다.
결과적으로 플랫폼은 외형만 존재했을 뿐, 실제 무역 프로세스를 처리할 수 없었다. 외주 개발은 그 시점에서 중단되었다.
이 실패에서 배운 핵심 교훈: 무역 프로세스를 이해하지 못하는 팀은 코드를 아무리 잘 짜도 작동하는 플랫폼을 만들 수 없다. "개발 능력"이 아니라 "도메인 이해"가 병목이었다.
4. 2022: 한국 법인, R&D 센터, 두 번째 시도
외주 프로젝트 종료 이후, 내부적으로 개발 관리 인력을 영입해 자체 개발을 시도했다. 한국에 법인을 설립하고 R&D 센터를 구성했다. 태국 현장의 업무 경험을 한국 개발팀에 전달해서 플랫폼을 만든다는 계획이었다.
그러나 시스템의 복잡성과 기술적 요구 수준은 생각보다 높았다. "개발"이 아니라 "플랫폼 설계"가 필요한 수준이었다. 4개국의 통화, 세율, 언어, 규제를 하나의 데이터 모델에서 처리하고, 견적에서 정산까지 수개월에 걸친 거래 흐름을 추적하는 것은 일반적인 웹 개발과 차원이 달랐다.
우리는 여러 차례 기능 단위의 개발을 시도했지만, 데이터 구조는 일관성을 잃었고 API 설계는 통합되지 않았다. 결국 플랫폼은 부분적으로 동작했지만, 상용화 수준에는 도달하지 못했다.
이 시기에 한 가지 중요한 성과가 있었다. 기술 특허를 출원하고, 벤처기업 인증을 받았다. 플랫폼 자체는 완성되지 못했지만, 문제 정의와 해결 방향은 명확해지고 있었다.
5. 2023: 전담 조직 구성, 세 번째 시도
2023년, 완전한 내부 개발 조직을 구성했다. 전담 백엔드, 프론트엔드, 디자인 인력을 배치하고 본격적인 플랫폼 개발에 착수했다. 동시에 말레이시아로의 사업 확장도 진행했다. 태국에서 검증된 모델을 말레이시아에 적용하면서 "다중 국가 운영"의 현실적 요구사항을 더 깊이 이해하게 되었다.
하지만 이번에도 문제는 기술력이 아니었다. "이해"의 문제였다. 글로벌 무역 프로세스에 대한 경험이 부족했고, 물류, 관세, 정산 구조를 코드로 옮기는 데 실패했다. 개발은 진행되고 있었지만, 플랫폼은 목표했던 방향으로 성장하지 못했다.
세 번의 시도에서 동일한 패턴이 반복되었다. 기술적으로 코드를 작성할 수 있는 인력은 있었지만, "왜 이 데이터가 이렇게 흘러야 하는가"를 설명할 수 있는 사람이 개발팀에 없었다. 무역 실무자와 개발자 사이의 간극이 근본 원인이었다.
6. 2024: 특허, 벤처 인증, 기반 다지기
플랫폼 개발이 기대만큼 진행되지 않는 동안에도 사업 기반은 계속 강화되었다. 특허 등록이 완료되었고, 벤처기업 인증이 유지되었다. 태국과 말레이시아 현지 법인의 운영이 안정화되었고, 한국 법인의 R&D 조직이 유지되었다.
이 시기의 가장 큰 자산은 데이터였다. 25,000건 이상의 거래 데이터가 축적되었다. 품목별 가격 이력, 공급사별 납기 패턴, 물류 경로별 비용 데이터. 플랫폼이 완성되지 않았지만, 플랫폼에 넣을 데이터는 계속 쌓이고 있었다.
또 하나의 자산은 실패의 경험이었다. 세 번의 개발 시도에서 "무엇이 안 되는가"를 정확히 알게 되었다. 외주로는 안 된다. 도메인을 모르는 개발팀으로도 안 된다. 기능 단위로 쪼개서 만드는 접근으로도 안 된다. 이 교훈들이 다음 시도의 설계 원칙이 되었다.
7. 2025년 4월: 내부 감사와 리셋 결정
2025년 4월, 내부 기술 감사를 실시했다. 당시 코드베이스는 실제 서비스 요구사항의 5% 수준만 구현되어 있었다. 아키텍처는 단순히 "작동"할 뿐, 확장성이나 복구성은 존재하지 않았다.
우리는 결론을 내렸다. "이 플랫폼은 처음부터 다시 설계해야 한다." 코드가 아닌 구조부터 다시 시작하기로 결정했다.
이 결정이 4년의 여정에서 가장 어려운 결정이었다. 3년간의 개발 결과물을 버리는 것이었다. 팀을 다시 구성해야 했고, 투자된 시간과 비용을 매몰 비용으로 인정해야 했다. 하지만 5%만 구현된 코드베이스 위에 나머지 95%를 쌓는 것보다 처음부터 올바른 구조 위에 새로 짓는 것이 더 빠르다는 판단이었다.
8. 2025년 5월: 네 번째 시작, 이번에는 다르게
2025년 5월, 프로젝트는 완전히 리셋되었다. 새로운 기술 조직이 구성되었고, 개발 정책의 첫 문장은 명확했다. "AI를 적극적으로 도입하라."
단순 자동화가 아닌, AI를 팀의 일부로 통합하기 위한 시도였다. 코드를 작성하는 조직이 아니라, 스스로 문제를 분석하고 해결 방안을 제시할 수 있는 AI 기반 조직으로의 전환이었다.
이전 세 번과 무엇이 달랐는가.
첫째, 데이터 모델을 먼저 설계했다. Event + State + Log 구조를 전체 플랫폼의 기반으로 정의하고, 60개였던 테이블을 250개의 6계층 구조로 재설계했다. Master, Partner, Transaction, Logistics, Integration, Audit. 코드를 한 줄도 쓰기 전에 데이터가 어떻게 흘러야 하는지를 먼저 결정했다.
둘째, MQ(LavinMQ)를 전체 아키텍처의 중심에 놓았다. 모든 데이터 변경이 이벤트로 발행되고, 관련 모듈이 이벤트를 구독하여 반응하는 구조. 모듈 간 직접 호출이 아니라 이벤트를 통한 느슨한 결합. 이 구조 덕분에 5개 플랫폼(REINDEERS, DVRP, POP, Document AI, Workflow AI)이 독립적으로 개발되면서도 하나의 네트워크로 연결될 수 있었다.
셋째, 무역 실무 경험을 직접 설계에 반영했다. 11년간의 현장 경험, 4개국 운영 경험, 25,000건의 거래 데이터에서 나온 실무 요구사항이 데이터 모델과 비즈니스 로직의 기반이 되었다. 이전처럼 "개발팀에게 설명하고 개발팀이 이해하는 방식"이 아니라 현장의 요구사항이 데이터 구조에 직접 반영되는 방식이었다.
9. 각 단계가 남긴 것
4년의 여정을 돌아보면, 각 단계가 다음 단계의 전제 조건을 만들었다.
2015-2019년의 현장 운영이 없었다면 "B2B 무역 플랫폼이 왜 쇼핑몰과 다른가"를 이해할 수 없었을 것이다.
2021년의 외주 실패가 없었다면 "도메인 이해가 왜 기술력보다 중요한가"를 깨닫지 못했을 것이다.
2022-2023년의 내부 개발 시도가 없었다면 "기능 단위 개발이 왜 통합에 실패하는가"를 알 수 없었을 것이다.
2025년 4월의 5% 감사 결과가 없었다면 "전체 리셋"이라는 가장 어려운 결정을 내릴 근거가 없었을 것이다.
그래서 4년이 낭비가 아니었다고 말할 수 있다. 각 실패가 다음 단계의 설계 원칙을 만들었다. 지금의 Event + State + Log 데이터 모델, MQ 기반 이벤트 아키텍처, 6계층 250개 테이블의 데이터 구조, AI 보조 + 사람 승인의 의사결정 구조. 이 모든 것은 4년간의 시행착오에서 나온 결론이다.
10. AI 기반 개발 문화의 출발
새로운 팀은 개발의 방식부터 달랐다. 모든 코드 리뷰와 설계 회의는 AI 지원 도구를 통해 진행되었고, 문서화, 테스트, 배포 자동화가 표준 프로세스로 자리잡았다. 기존의 '사람 중심 개발'에서 '데이터 중심 개발'로 방향이 바뀌었다.
이는 단순한 기술적 변화가 아니라, REINDEERS가 "산업을 디지털화하는 방식" 자체를 다시 정의한 순간이었다. 이 시점이 REINDEERS 플랫폼의 진짜 출발점이었다.
2025년 12월 1일 공식 오픈까지 7개월. 5월의 리셋부터 12월의 오픈까지, 이전 4년에서 배운 모든 것을 응축한 7개월이 시작되었다.