1. AI가 들어오기 전의 문제
2025년 5월 내부 리셋 이후, 가장 큰 문제는 속도였다. 팀의 기술 수준은 높았지만, 다국적 협업 환경에서는 작은 결정 하나에도 시간이 걸렸다. "이 데이터는 어디에 저장할까?", "이 로직은 누가 승인해야 하지?" 이런 질문이 하루를 지연시켰다.
사람의 의사결정을 코드로 바꾸는 방법이 필요했다. 그 해답이 AI Agent였다.
구체적으로 말하면, 2025년 4월 기술 감사 당시 전체 코드베이스가 요구사항의 5%만 구현된 상태였다. 4년간의 외주 개발과 팀 교체 끝에 남은 것은 사실상 재사용할 수 없는 코드였다. 5월 리셋 이후 새로 시작했지만, 4개국에 분산된 팀이 동시에 움직여야 했기 때문에 의사결정 병목이 심각했다. 한국팀이 아키텍처를 결정해도 중국팀의 프론트엔드 구현까지 전달되는 데 수일이 걸렸고, 태국팀의 비즈니스 요건이 개발팀에 도달할 때 쯤이면 이미 우선순위가 바뀌어 있었다.
2. MCP + MQ + AI의 결합 구조
REINDEERS의 내부 구조는 세 가지 축으로 이루어져 있다. MCP(Multi-Commerce Platform)는 전체 트랜잭션의 뼈대, MQ(Message Queue)는 데이터 흐름의 신경망, AI Agent는 그 신경망을 제어하는 두뇌 역할을 한다.
[MCP] -- [MQ Router] -- [AI Agent] -- [Cloud Functions] -- [Data Layer]
\ Logging / \ Scheduler /AI는 사람이 하지 않아도 되는 "판단성 업무"를 맡았다. 예를 들어, MQ에 "quote.confirmed" 이벤트가 들어오면 AI가 자동으로 주문 구조를 검토하고, 누락된 필드를 채워넣는다.
{
"event": "quote.confirmed",
"check": "delivery.schedule",
"auto_fill": ["currency", "vat_type", "port_code"]
}이 구조는 MQ와 AI가 상호 작용하도록 설계된 것이다. MQ는 데이터를 전달하고, AI는 그 데이터를 해석해 다음 액션을 생성한다. 사람은 단지 결과를 검토할 뿐이다.
이 세 축의 결합이 만들어내는 가장 큰 변화는 "비동기 의사결정"이다. 기존에는 태국 바이어의 견적 요청에 대해 한국팀 담당자가 직접 확인하고, 중국 공급사에 연락하고, 다시 태국팀에 결과를 전달하는 동기적 프로세스가 필요했다. 이제는 MQ가 이벤트를 전달하고, AI Agent가 각 단계의 검증을 자동으로 수행하며, 사람은 예외 상황에서만 개입한다. 이 구조는 Event + State + Log 데이터 모델 위에서 작동한다. 모든 이벤트가 발생하면 상태가 변경되고, 변경 이력이 로그로 남는다. "지금 이 견적이 왜 이 상태인가"를 언제든 추적할 수 있다.
3. AI Agent의 역할 분화
REINDEERS 내부에는 총 5종류의 AI Agent가 있다. 각각은 특정 업무를 담당하며, 독립적으로 작동한다.
- Data Agent: 크롤링, 정규화, 중복 검출
- Translation Agent: 다국어 자동 번역 및 필드 정합성 검사
- Schedule Agent: 물류 일정 생성 및 충돌 감지
- Validation Agent: 주문 및 결제 데이터 검증
- Insight Agent: 거래 패턴 분석 및 예측 피드백
예를 들어, Schedule Agent는 MQ에서 수신한 DO 데이터를 분석해 포워딩 일정, 항구 스케줄, 세관 업무를 자동 생성한다. 사람이 일정을 확인할 때쯤이면 이미 AI가 모든 옵션을 정리해놓는다.
각 Agent의 작동 방식을 좀 더 구체적으로 보면, Data Agent는 Playwright 기반 크롤러가 수집한 원천 데이터를 받아 MCP 표준 스키마로 정규화한다. 중국 공급사가 등록한 상품명이 기존 SKU와 중복되는지 검출하고, 중복이면 기존 데이터와 병합하거나 신규 레코드로 분리한다. Translation Agent는 4개국 언어(한국어, 태국어, 중국어, 영어)를 자동 번역하되, 산업재 전문 용어의 정확성을 RAG 파이프라인으로 보정한다. "알루미늄 프로파일"을 태국어로 번역할 때 일반 번역이 아닌, 태국 MRO 시장에서 실제로 사용하는 용어로 변환하는 것이다.
Validation Agent는 가장 빈번하게 호출되는 Agent다. 견적서의 필수 항목 누락 검증, 환율 적용 정확성 확인, VAT 세율 일치 여부 등을 자동으로 처리한다. 30개 이상의 포워더가 제출하는 비딩 견적에서도 조건 불일치, 날짜 오류, 운임 단위 불일치 같은 문제를 즉시 감지한다. Insight Agent는 축적된 25,000건 이상의 거래 데이터를 기반으로 계절별 수요 패턴, 공급사별 납기 준수율, 노선별 운임 변동 추세를 분석해 의사결정 근거를 제공한다.
4. MQ -- AI의 동맥
AI Agent는 MQ 없이는 존재할 수 없다. 모든 AI의 입력은 MQ를 통해 들어오고, AI의 판단 결과 역시 MQ를 통해 다음 Function으로 전달된다.
# Example Workflow: Order Processing
quote.confirmed → AI.ValidationAgent → logistics.schedule
logistics.schedule → AI.ScheduleAgent → customs.prepare
customs.prepare → AI.ValidationAgent → payment.requestMQ는 단순한 메시징 시스템이 아니라, AI가 학습한 규칙을 적용하는 실행 파이프라인이 되었다. 이 구조는 REINDEERS의 자동화를 완전히 다른 수준으로 끌어올렸다.
LavinMQ를 선택한 기술적 이유가 있다. REINDEERS의 서버리스 아키텍처에서 각 Cloud Function은 60초 타임아웃 제한이 있다. 장시간 실행이 필요한 작업은 하나의 Function에서 처리할 수 없으며, 여러 Function으로 분리해 MQ로 연결해야 한다. LavinMQ는 AMQP 호환이면서 경량이어서 다국가 분산 환경에 적합했다. 특히 Retry Queue와 Dead Letter Queue를 통한 장애 복구가 핵심이다. 첫 재시도는 2초 후, 두 번째는 4초 후, 세 번째는 6초 후 exponential backoff로 수행되며, 3회 실패 시 DLQ로 이동한다.
MQ의 또 다른 핵심 역할은 캐시 무효화다. 주문이 생성되면 관련 캐시가 자동으로 무효화되고, 인보이스가 갱신되면 정산 모듈의 캐시가 반응한다. Redis에 저장된 환율, 세율, 물류 상태 데이터가 MQ 이벤트에 의해 실시간으로 갱신되는 구조다. 사람이 시스템 간 데이터를 수동으로 동기화하는 작업이 완전히 사라졌다.
5. AI를 위한 개발 문화의 변화
AI Agent의 도입은 개발 문화를 완전히 바꿨다. 기존에는 개발자가 직접 로직을 수정했지만, 이제는 AI가 먼저 분석 리포트를 작성하고, 개발자는 그것을 검토해 Merge 여부를 판단한다.
예를 들어, 중국 개발자가 SKU 매칭 알고리즘을 수정하면 AI Validation Agent가 자동으로 300건의 테스트 데이터를 돌려 오류율과 개선율을 Slack 대신 Telegram으로 보고한다. 이런 구조 덕분에 개발 속도는 2배, 품질은 3배 향상됐다.
이 문화적 변화의 핵심은 "AI가 코드를 작성하는 것"이 아니라 "AI가 검증 기준을 자동화하는 것"이다. REINDEERS의 개발 파이프라인에서 AI는 세 가지 지점에서 개입한다. 첫째, 코드가 커밋되면 CI/CD 파이프라인에서 AI Validation Agent가 데이터 정합성 테스트를 자동 실행한다. 둘째, 크롤링 데이터의 품질이 일정 기준 이하로 떨어지면 AI가 자동으로 경고를 발생시킨다. 셋째, 다국어 번역 결과의 일관성을 AI가 검증하고, 불일치 항목을 리스트로 정리해 Telegram으로 전달한다. 이 모든 알림은 5분 쿨다운이 적용되어 중복 알림 폭탄을 방지한다.
6. 예외와 복구 -- AI가 실패할 때
물론 AI도 완벽하지 않다. 예를 들어 새로운 공급사 코드가 기존 DB 패턴에 맞지 않으면, AI는 "Validation Fail" 상태로 기록한다.
{
"agent": "DataAgent",
"status": "fail",
"reason": "unknown pattern in SKU structure",
"retry_in": "10s"
}이 상태는 MQ Retry Queue로 전송되어 10초 후 재시도된다. 같은 오류가 3회 이상 발생하면 인간 개발자에게 Telegram 알림이 간다. 사람이 개입해야 하는 구간을 최소화하면서, 복구는 여전히 안정적으로 유지된다.
AI 실패의 패턴은 크게 세 가지로 분류된다. 첫째, 데이터 패턴 불일치다. 새로운 공급사가 기존과 완전히 다른 SKU 코드 체계를 사용하는 경우 Data Agent가 정규화에 실패한다. 이 경우 AI는 해당 데이터를 "unknown_pattern" 큐에 보관하고, 사람이 매핑 규칙을 추가하면 이후 동일 패턴은 자동 처리된다. 둘째, 외부 API 장애다. 환율 스크래핑, 선사 스케줄 조회 등 외부 의존성이 있는 작업에서 타임아웃이 발생할 수 있다. 이 경우 MQ의 Retry Queue가 자동으로 재시도하며, 최종 실패 시 마지막으로 성공한 캐시 데이터를 사용한다. 셋째, 비즈니스 로직 충돌이다. 동시에 두 개의 견적이 같은 재고를 참조하는 경우처럼, 동시성 문제가 발생할 수 있다. 이 경우 Validation Agent가 충돌을 감지하고 사람의 판단을 요청한다.
7. MCP -- 모든 흐름의 기반
MCP는 여전히 REINDEERS의 가장 중요한 축이다. 모든 AI와 MQ는 MCP의 데이터 정의서를 기반으로 작동한다. 각 테이블과 이벤트 구조는 JSON Schema로 정의되어 있으며, 새로운 기능이 추가될 때마다 Schema Registry를 자동 업데이트한다.
{
"table": "orders",
"fields": ["order_id", "client_id", "supplier_id", "status", "payment_flag"],
"trigger": ["ai.validation", "ai.schedule", "mq.dispatch"]
}덕분에 새로운 서비스가 추가되어도 AI는 자동으로 데이터 구조를 인식하고 연결할 수 있다. REINDEERS의 기술 핵심은 복잡함을 숨기는 구조에 있다.
MCP의 데이터 모델은 현재 250개 테이블로 구성되어 있으며, Master/Partner/Transaction/Logistics/Integration/Audit 6개 계층으로 정규화되어 있다. 이 6계층 구조가 AI와 MQ의 기반이 되는 이유는, 각 계층이 독립된 이벤트 생성 단위이기 때문이다. Transaction 계층에서 주문 상태가 바뀌면 해당 이벤트가 MQ로 발행되고, Logistics 계층의 관련 데이터가 자동으로 갱신된다. AI Agent는 이 이벤트 흐름을 감시하며, 각 계층 간 데이터 정합성을 실시간으로 검증한다.
Schema Registry는 새로운 기능이 추가될 때마다 자동 업데이트되는데, 이 과정에서 하위 호환성이 항상 보장된다. 필드가 추가되면 기존 AI Agent는 새 필드를 무시하고, 새 Agent만 활용한다. 필드가 변경되면 마이그레이션 이벤트가 발행되어 관련 Agent들이 일괄 갱신된다. 이 구조 덕분에 플랫폼에 새로운 국가가 추가되거나 새로운 비즈니스 모델이 들어와도 기존 시스템이 영향받지 않는다.
8. 결론 -- AI와 사람이 공존하는 플랫폼
REINDEERS는 "AI가 대신 일하는 플랫폼"이 아니다. AI와 사람이 서로의 빈자리를 채우는 구조다. AI는 반복을 줄이고, 사람은 방향을 결정한다. 이 두 요소가 MQ와 MCP 위에서 만나며 REINDEERS는 점점 스스로 진화하는 시스템으로 변해가고 있다.
자동화는 목적이 아니라 결과다. REINDEERS의 목표는 기술이 산업을 이해하도록 만드는 것이다. 우리는 이제 그 첫 단계를 넘어섰다.
이 구조가 실제로 만들어낸 변화를 정리하면 이렇다. 견적 요청부터 정산까지의 전 과정에서 사람이 직접 데이터를 입력하거나 옮겨야 하는 작업이 대폭 줄었다. AI가 처리하는 검증, 분류, 번역, 일정 생성 업무는 이전에 사람이 수시간씩 소비하던 반복 작업이었다. 동시에 AI가 처리할 수 없는 전략적 판단, 예를 들어 신규 공급사 온보딩 결정, 가격 협상 전략, 시장 진출 우선순위 같은 판단은 여전히 사람의 영역이다. AI와 MQ와 MCP, 이 세 가지가 결합되면서 REINDEERS는 "도구"에서 "플랫폼"으로, 다시 "생태계"로 진화하고 있다.