AI와 MQ, 그리고 MCP — 우리가 기술로 문제를 해결한 방식

요약:
REINDEERS는 단순한 자동화 시스템이 아니다. 우리는 AI, MQ, MCP를 결합해 사람이 하던 의사결정과 실행을 시스템화했다. 업무의 절반은 사람이, 나머지 절반은 AI Agent가 처리한다. 이번 글은 REINDEERS가 기술로 문제를 해결한 실제 방식을 공개한다.

1. AI가 들어오기 전의 문제

2025년 5월 내부 리셋 이후, 가장 큰 문제는 속도였다. 팀의 기술 수준은 높았지만, 다국적 협업 환경에서는 작은 결정 하나에도 시간이 걸렸다. “이 데이터는 어디에 저장할까?”, “이 로직은 누가 승인해야 하지?” 이런 질문이 하루를 지연시켰다.

사람의 의사결정을 코드로 바꾸는 방법이 필요했다. 그 해답이 AI Agent였다.

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는 그 데이터를 해석해 다음 액션을 생성한다. 사람은 단지 결과를 검토할 뿐이다.

3. AI Agent의 역할 분화

REINDEERS 내부에는 총 5종류의 AI Agent가 있다. 각각은 특정 업무를 담당하며, 독립적으로 작동한다.

Data Agent: 크롤링, 정규화, 중복 검출
Translation Agent: 다국어 자동 번역 및 필드 정합성 검사
Schedule Agent: 물류 일정 생성 및 충돌 감지
Validation Agent: 주문 및 결제 데이터 검증
Insight Agent: 거래 패턴 분석 및 예측 피드백

예를 들어, Schedule Agent는 MQ에서 수신한 DO 데이터를 분석해 포워딩 일정, 항구 스케줄, 세관 업무를 자동 생성한다. 사람이 일정을 확인할 때쯤이면 이미 AI가 모든 옵션을 정리해놓는다.

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.request

MQ는 단순한 메시징 시스템이 아니라, AI가 스스로 학습한 규칙을 적용하는 실행 파이프라인이 되었다. 이 구조는 REINDEERS의 자동화를 완전히 다른 수준으로 끌어올렸다.

5. AI를 위한 개발 문화의 변화

AI Agent의 도입은 개발 문화를 완전히 바꿨다. 기존에는 개발자가 직접 로직을 수정했지만, 이제는 AI가 먼저 분석 리포트를 작성하고, 개발자는 그것을 검토해 Merge 여부를 판단한다.

예를 들어, 중국 개발자가 SKU 매칭 알고리즘을 수정하면 AI Validation Agent가 자동으로 300건의 테스트 데이터를 돌려 오류율과 개선율을 Slack 대신 Telegram으로 보고한다. 이런 구조 덕분에 개발 속도는 2배, 품질은 3배 향상됐다.

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 알림이 간다. 사람이 개입해야 하는 구간을 최소화하면서, 복구는 여전히 안정적으로 유지된다.

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의 기술 핵심은 복잡함을 숨기는 구조에 있다.

8. 결론 — AI와 사람이 공존하는 플랫폼

REINDEERS는 “AI가 대신 일하는 플랫폼”이 아니다. AI와 사람이 서로의 빈자리를 채우는 구조다. AI는 반복을 줄이고, 사람은 방향을 결정한다. 이 두 요소가 MQ와 MCP 위에서 만나며 REINDEERS는 점점 스스로 진화하는 시스템으로 변해가고 있다.

자동화는 목적이 아니라 결과다. REINDEERS의 목표는 기술이 스스로 산업을 이해하도록 만드는 것이다. 우리는 이제 그 첫 단계를 넘어섰다.

Blog of Reindeers

Search This Blog