크로스보더 팀이 ChatGPT 계정이 없어서 고생하는 경우는 드뭅니다. 진짜 문제는 다섯 업무선이 각각 반쯤 자동화된 상태입니다. 헬프데스크 복붙, 스프레드시트 소싱, ROAS만 보는 광고, ERP 출고, 이메일·마켓플레이스 티켓을 오가는 AS. 이를 AI Agent로 감사 가능한 한 줄 파이프라인에 묶으려면 (1) 통합 이벤트 버스, (2) 도메인 Agent + 명확한 도구 권한, (3) 사람 승인 게이트(환불·가격·내림·대규모 예산)가 필요합니다.
아래는 0에서 운영까지의 순서: 아키텍처·데이터 계약, 다섯 Agent( CS·소싱·광고·주문·AS ), 오케스트레이션·관측·컴플라이언스. 예시는 Shopify + Amazon Seller + Meta/Google Ads. Webhook·큐·LLM API로 자체 구축도 가능합니다. 24/7 게이트웨이는 고정 리전 Cloud Mac에서 cron·로컬 스크립트를 돌리고 API는 공식 엔드포인트를 유지하세요.
전체 구조: 이벤트 버스·오케스트레이터·도구층
모든 API를 한 «슈퍼 Agent»에 넣지 마세요. 유지보수 가능한 형태는 얇은 오케스트레이션 + 두꺼운 도구입니다:
- 이벤트 버스: Kafka, Redis Streams, SQS, Postgres
outbox등. 인입을 JSON Schema로 통일(order.created,ticket.opened,ads.campaign.overspend). - 오케스트레이터: 이벤트 유형별 Agent Worker 라우팅; 주문 단위 상태 기계(답변 대기 → 출고 대기 → 예외 → 종료).
- 도메인 Agent: 도메인별 도구만(CS는 KB, 주문은 WMS); 읽기 전용 고객 프로필 공유.
- 승인 큐: 환불·가격·내림·예산 > 임계값은
pending_approvals; Slack/飞书 카드 승인 후 실행.
데이터·인증 정보: 단일 진실 공급원
Agent가 엉뚱한 답을 하는 경우 대부분 데이터가 갈라진 때문입니다. 출시 전 최소:
- 상품 마스터: SKU, 변형, 통관 신고, 금수 국가—ERP/PIM이 정본, 스토어 관리자는 읽기 동기화.
- 주문 상태: 마켓플레이스 주문 ID ↔ 내부
order_id↔ 운송장 매핑 테이블; Agent는 매핑 레이어만 조회. - 고객 타임라인: 이메일, 사이트 메시지, WhatsApp, 마켓플레이스 메시지를 하나의
customer_id. - 비밀 관리: Shopify Admin API, Amazon SP-API, Meta Marketing API 토큰은 Vault/KMS; 실행 시 단기 토큰—프롬프트 금지.
Agent 출력을 구조화(intent, confidence, proposed_actions[]). 자유 텍스트는 사람용, 오케스트레이터는 JSON만 파싱해 재현·감사.
CS Agent: 멀티채널 의도·KB·에스컬레이션
입력: Gorgias, Zendesk, Shopify Inbox, Amazon Buyer-Seller Messaging webhook. 도구: 정책 KB(반품 기간·보증), 배송 조회, 티켓 메모. 정책:
- 의도: 배송 조회 / 누락 / 품질 / 취소 / 리뷰 협박—의도별 액션 화이트리스트.
- 버전 있는 RAG KB: 정책 변경 시 버전 올리고 이전 스레드에 새 규칙 섞지 않기.
- 낮은 신뢰도·격한 톤 →
escalate_to_human, Agent가 이미 조회한 주문 사실 첨부.
답변 언어는 구매자 스토어 언어; 구조화 의도는 하나, 언어별 Agent 분리 금지.
소싱 Agent: 시그널·점수·사람 풀
소싱 Agent는 «승인 상架»가 아니라 정보 압축: 트렌드·경쟁가·마진·컴플라이언스를 결정 카드로.
- 시그널: 마켓 트렌드, 제3자 판매 추정, 광고 라이브러리, 간이 특허·상표 검색(법무 최종).
- 점수: 규칙 + LLM 요약;
score,risks[],suggested_moq. - 사람 풀: 점수 > 임계값 → «구매 회의» 보드; Agent는 경쟁 비교표만, PO 자동 생성 안 함.
광고 Agent: 크리에이티브·입찰·이상 차단
광고는 예산을 가장 빨리 태웁니다. 권한은 읽기 많고 쓰기 적게:
- 읽기 모니터링: 매시 캠페인 spend·CTR·ROAS; 급증·CTR 급락 →
ads.anomaly. - 제안 모드: «예산 축소/소재 교체/타겟 확대» 카드—기본은 예산 자동 변경 없음.
- 자동 모드(선택): ROAS > 목표이고 spend < 일한도일 때만 ±5% 미세 조정; 상향은 승인.
- 문안은 별도: headline+primary text 3세트; 사람이 고른 뒤 Meta/Google 업로드.
주문 Agent: 이행·예외·대사
order.paid, inventory.low, shipment.exception 수신:
- 주소 검증(우편번호·도서 추가비), 블랙리스트, 중복 주문.
- 창고 라우팅: 재고·SLA·헤드코스트; 품절 시 분할 출고 또는 CS Agent가 구매자 알림.
- 추적 번호 스토어·마켓플레이스에 기록; 예외는 AS 준비 티켓.
- 일말 대사: 마켓플레이스 정산 ↔ 결제 게이트웨이 ↔ ERP 매출채권, 차이 > 임계값 알림.
AS Agent: RMA·환불·플랫폼 분쟁
CS와 고객 타임라인 공유, 도구는 더 민감:
- RMA: 반품 기간·개봉·크로스보더 반송—
approve_rma제안, 실행은 승인 후. - 환불: 부분/전액/배송비 단계는 정책 표; Agent는 금액 제안만.
- 분쟁: Amazon A-to-z, PayPal—증빙 패키지(배송·채팅·정책 캡처)는 사람이 제출.
오케스트레이션: n8n / 자체 FSM / Agent 프레임워크
| 방식 | 적합 | 주의 |
|---|---|---|
| n8n / Make | 10인 미만, webhook 많음, 속도 | 복잡한 상태 기계는 스파게티—JSON을 Git 관리 |
| Temporal / 자체 FSM | 긴 주문 흐름, 안정적 재시도 | 개발 비용↑, 주문/AS 코어 |
| LangGraph 등 | 단일 도메인 다단계 추론 | 도메인 간은 버스, 한 그래프에 전부 X |
| OpenClaw 등 멀티채널 게이트웨이 | 승인·알람을 Telegram/Slack | 게이트웨이는 메시지·도구 라우팅, 상태는 DB |
권장: 1주 n8n «신규 티켓 → 주문 조회 → 초안»; 2–3주 주문 상태 기계를 코드로; 4주 광고 읽기 모니터링.
관측·비용·보안 기준선
- 추적: 호출마다
trace_id, 모델, 토큰, 도구, 승인 여부. - 재현: 입력 이벤트+구조화 출력 저장, 분쟁 시 «정책 준수» 증명.
- 비용: CS 분류는 소형 모델, 초안은 대형; 소싱/광고 다이제스트는 배치.
- 컴플라이언스: GDPR·개인정보 최소화; 가짜 리뷰·순위 조작 금지—액션 화이트리스트는 법무가 읽을 수 있게.
4주 로드맵
- 1주: 이벤트 schema+주문/고객 매핑; CS 읽기 조회+초안(사람 발송).
- 2주: 주문 Agent 자동 창고 라우팅+추적 반영; 예외→AS 준비.
- 3주: 소싱 일보+광고 이상 알림; Slack/飞书 승인.
- 4주: AS RMA 제안+대사 차이 알림; 전체 trace·주간 ROAS/CSAT.
FAQ
구조화 FAQ는 페이지 JSON-LD. 요약: 한 Agent로 전부?, Shopify·Amazon 공통 CS?, 광고 완전 자동?, 프롬프트 인젝션, 오케스트레이션 실행 위치.