1. 첫 번째 팀 -- 외주 개발사의 한계
REINDEERS의 첫 번째 팀은 외부 개발사였다. 계약은 단순했고, 목표는 "무역 플랫폼의 MVP 구축"이었다. 그러나 현실은 달랐다. 개발사는 무역을 이해하지 못했고, 제조 유통의 흐름을 전자상거래처럼 처리하려 했다.
결과적으로 견적(Quote), 주문(Order), 물류(Logistics), 결제(Payment)가 같은 테이블에 얽혀 있었다. 개발은 빨랐지만, 구조는 위험했다. 첫 번째 팀은 "코드를 만들었지만, 플랫폼은 만들지 못했다."
무역에서는 견적 하나가 여러 개의 발주서로 분리되기도 하고, 하나의 발주가 복수의 선적으로 나뉘기도 한다. 결제 조건은 T/T, L/C, D/A 등 거래 상대와 품목에 따라 완전히 달라진다. 외주 개발사는 이 모든 것을 하나의 "주문-결제" 테이블로 처리하려 했다. 일반적인 쇼핑몰이라면 가능한 설계였지만, B2B 무역에서는 첫 주부터 문제가 드러났다.
가장 치명적이었던 것은 통화(Currency) 처리였다. 태국 바트로 견적을 내고, 중국 위안으로 결제하고, 한국 원화로 정산하는 구조를 외주팀은 전혀 고려하지 않았다. 환율 변동에 따른 마진 계산, 선적 시점과 결제 시점의 환차손 -- 이런 것들은 사양서에 한 줄로 적혀 있었지만, 실제로 구현하려면 완전히 다른 데이터 모델이 필요했다. 외주팀에게 이것은 "추가 요구사항"이었지만, 우리에게는 플랫폼의 본질이었다.
2. 두 번째 팀 -- 내부화의 첫 시도
두 번째 시도는 "내부 개발팀 구성"이었다. 외주가 실패한 이유를 외부 탓으로 돌릴 수 없다고 판단했기 때문이다. 관리 인력과 몇 명의 풀스택 개발자가 합류해, 직접 시스템을 만들기 시작했다.
하지만 문제는 여전히 같았다. "기술은 있지만 이해가 없었다." 플랫폼이 무엇을 해야 하는지보다, "어떻게 코드를 짤 것인가"에만 집중했다. 결과적으로 기능은 많았지만, 방향은 없었다.
두 번째 팀의 개발자들은 기술적으로 유능했다. React, Node.js, Java Spring -- 스택 선택에 문제가 있었던 것은 아니다. 문제는 그들이 "산업재 유통"이라는 도메인을 경험해본 적이 없다는 점이었다. MOQ(최소주문수량)가 왜 품목마다 다른지, 납기일이 왜 견적서에 명시되어야 하는지, 포워딩 비용이 왜 견적 단가에 포함되는 경우와 별도인 경우가 있는지 -- 이런 맥락 없이 만들어진 기능은 현장에서 쓸 수 없었다.
단적인 예로, 개발팀은 "상품 검색" 기능에 많은 공을 들였다. 필터링, 정렬, 페이지네이션까지 완벽하게 구현했다. 하지만 실제 MRO 구매 담당자는 상품명으로 검색하지 않았다. 그들은 규격 번호(Part Number)나 브랜드+사이즈 조합으로 찾았다. "M8 볼트 스테인리스 100개"라는 식의 자연어 주문이 일상이었다. 화려한 검색 UI는 결국 아무도 쓰지 않았다.
3. 세 번째 팀 -- '조직'은 있었으나 '구조'는 없었다
세 번째 팀은 형식적으로 완벽했다. 백엔드, 프론트엔드, UI/UX, 기획, QA까지 구성되었고, 일간 미팅과 주간 보고 체계도 정비됐다. 하지만 플랫폼은 여전히 전진하지 않았다.
구성원 각자가 자기 역할에 충실했지만, 서로의 코드가 연결되지 않았다. "백엔드는 기능을, 프론트는 화면을, 기획은 문서를 만들었다." 그러나 그 어느 것도 '비즈니스 로직'을 완성하지 못했다. 협업은 있었으나, 공동의 목표는 부재했다.
세 번째 팀에서 가장 눈에 띄었던 문제는 도구의 난립이었다. 기획은 Notion에, 디자인은 Figma에, 태스크는 Jira에, 소통은 Slack과 LINE에 흩어져 있었다. 각 도구는 그 자체로 훌륭했지만, "견적서 발행 프로세스를 개선한다"는 하나의 목표를 위해 네 개의 도구를 오가야 했다. 정보는 많았지만 맥락은 분절되었고, 회의는 늘었지만 결론은 줄었다.
더 근본적인 문제는 "무엇을 만들 것인가"에 대한 합의가 없었다는 것이다. 백엔드 개발자는 API 스펙을 먼저 정하자고 했고, 프론트엔드 개발자는 화면 설계가 먼저라고 했다. 기획자는 경쟁사 분석 보고서를 쓰고 있었고, QA는 테스트할 대상이 없어 문서화 작업을 하고 있었다. 모두가 바쁘게 일했지만, 플랫폼은 한 줄의 실제 거래도 처리하지 못하는 상태였다. 프로세스는 있었지만 비전이 없었고, 역할은 있었지만 방향이 없었다.
4. 네 번째 팀 -- 내부 감사 이후의 전면 교체
2025년 4월 내부 감사를 통해, 우리는 결론을 내렸다. "개발은 있었지만, 시스템은 없었다." 이때 네 번째 팀이 만들어졌다. 새로운 기준은 단순했다. "기술보다 사고가 빠른 사람을 모으자."
코드 품질보다 논리 구조를 평가했고, 스택보다 문제 해결 방식을 검증했다. AI를 이해하고, 스스로 업무를 자동화할 수 있는 인력이 필요했다. 2025년 5월, 완전히 새로운 개발 문화가 출발했다.
네 번째 팀의 핵심 인력은 NHN 에이컴메이트 출신이라는 공통점이 있었다. CSO 박준영은 커머스 분야 20년 경력자로 플랫폼 비즈니스의 성장과 실패를 모두 경험한 사람이었다. CPO 진청지는 B2B SaaS 20년 경력으로 복잡한 기업용 시스템을 설계하는 데 익숙했다. CTO 저우치롱은 AI와 RAG 분야 15년 경력자로, 데이터에서 비즈니스 가치를 추출하는 방법을 알고 있었다. COO 장웨이는 물류 8년 경력으로 실제 화물이 움직이는 현장을 이해하는 사람이었다.
이 팀이 이전 세 팀과 결정적으로 달랐던 것은 "같은 언어를 사용한다"는 점이었다. 기술 용어만이 아니라, B2B 무역과 유통의 맥락을 공유하고 있었다. "견적 확정 후 PO가 발행되기까지의 리드타임"이라는 말을 했을 때, 팀 전원이 그것이 무슨 의미인지, 왜 중요한지, 어떤 예외 상황이 있는지를 이해했다. 이전 팀들에서는 이 한 문장을 설명하는 데 30분짜리 미팅이 필요했다.
5. 기술이 아닌 '이해'를 중심으로
네 번째 팀은 기존 팀과 완전히 달랐다. 그들은 코드를 짜기 전에 구조를 설계했고, 코드를 합치기 전에 이유를 공유했다.
우리는 "왜 이 API가 존재하는가"를 질문하는 문화부터 만들었다. 누군가는 그것을 느리다고 했지만, 그 느림이 처음으로 플랫폼을 앞으로 나아가게 했다. 시스템은 점점 '사람이 관리하지 않아도 동작하는 구조'로 변해갔다.
네 번째 팀이 가장 먼저 한 일은 기존 코드를 전부 버리는 것이 아니라, "어떤 거래가 실제로 플랫폼 위에서 완결되어야 하는가"를 정의하는 것이었다. 태국의 제조 공장이 중국 공급사에게 MRO 부품을 발주하고, 그 부품이 선적되어 방콕 창고에 도착하고, 최종 고객에게 배송되기까지의 전 과정을 하나의 시나리오로 정리했다. 그리고 그 시나리오의 각 단계를 독립된 서비스로 분리해 MCP(Multi-Commerce Platform) 아키텍처를 설계했다.
데이터와 AI를 공통 언어로 삼은 것도 중요한 전환점이었다. 이전 팀들은 회의와 문서로 소통했지만, 네 번째 팀은 데이터 파이프라인과 로그로 소통했다. "이 기능이 잘 작동하는가?"라는 질문에 의견이 아닌 수치로 답했다. 실제 거래 데이터의 흐름을 추적하면서, 어디서 병목이 생기고 어디서 오류가 발생하는지를 객관적으로 파악할 수 있게 되었다.
6. 글로벌 협업의 시작
태국, 한국, 중국, 말레이시아 개발자들이 하나의 Git 브랜치에서 일하기 시작했다. 언어는 달랐지만, "코드와 데이터는 공용 언어"였다. 우리는 Git과 MQ 로그를 통해 의사소통했다. 문서 대신 코드가, 회의 대신 로그가 팀의 기록이 되었다.
AI 번역기가 코드 리뷰를 보조했고, Cloud Function이 자동 배포를 처리했다. 업무의 절반은 사람, 나머지 절반은 AI가 수행했다. REINDEERS는 그 순간 진짜 글로벌 팀이 되었다.
4개국에 분산된 팀이 하나의 플랫폼을 만든다는 것은 단순히 시차 문제를 넘어선 도전이었다. 한국어, 태국어, 중국어, 영어가 뒤섞인 환경에서 Slack 메시지 하나를 이해하는 데도 시간이 걸렸다. 그래서 팀은 의사소통의 중심을 "사람의 언어"에서 "시스템의 언어"로 옮겼다. 코드 커밋 메시지, MQ 이벤트 로그, API 응답 코드 -- 이것들은 국적과 관계없이 모든 팀원이 동일하게 읽을 수 있었다.
7. 교체의 의미 -- 실패가 남긴 자산
네 번의 교체는 단순한 인력 문제 해결이 아니었다. 그 과정에서 우리는 "어떤 사람이 플랫폼을 만든다"는 것을 배웠다.
- 기술력보다 프로세스 이해력이 중요한 사람
- 문제를 설명하는 속도보다 구조를 정리하는 사람이 필요했다
- 일을 자동화할 줄 아는 사람, 즉 AI를 다루는 사람이 필요했다
그 깨달음이 REINDEERS 조직의 DNA가 되었다. 이후 모든 채용은 "AI 친화적 사고를 가진 사람인가?"로 시작되었다.
B2B 무역 플랫폼을 만드는 일에서 가장 어려운 부분은 코딩이 아니었다. 가장 어려운 것은 "무역이라는 산업 자체를 이해하는 사람"을 찾는 일이었다. 견적서의 유효기간이 왜 중요한지, FOB와 CIF의 차이가 시스템 설계에 어떤 영향을 미치는지, 선하증권(B/L) 발행 시점이 왜 결제 트리거가 되는지 -- 이런 것들은 개발 문서에 적혀 있지 않다. 현장에서 직접 부딪혀야만 알 수 있는 지식이다.
네 번의 팀 교체를 거치면서 우리가 확립한 채용 원칙은 명확하다. 첫째, 도메인 경험이 기술 스택보다 우선한다. 둘째, 문제를 정의하는 능력이 문제를 해결하는 능력보다 중요하다. 셋째, AI 도구를 자연스럽게 업무에 통합할 수 있는 사람을 뽑는다. 이 세 가지 기준은 4,300개 이상의 파트너사와 25,000건 이상의 거래를 처리하는 지금의 REINDEERS를 만든 토대가 되었다.