B2B 거래에서 견적은 단순한 가격표가 아니다. 바이어의 구매 이력, 공급사의 재고 상황, 물류 비용, 인코텀즈, 납기일, 결제 조건 , 이 모든 변수가 얽힌 협상의 산물이다. 현재 이 과정은 이메일과 전화, 스프레드시트로 이루어진다. 바이어가 RFQ를 보내면 공급사가 검토하고, 포워더에게 물류 견적을 받아 합산하고, 다시 바이어에게 회신한다. 건당 수일이 걸리는 이 과정을 AI Agent가 대신할 수 있다면 어떨까. REINDEERS는 이 구조를 설계하고 있다.
먼저 이 글의 전제를 분명히 한다. REINDEERS·POP·DVRP는 지금 AI로 전환되는 구조 위에 올라서 있다. 조직도 안에서 직원을 등록할 때 '사람', 'AI Agent', '로봇' 중에서 선택할 수 있고, 사람은 전략과 방향을 결정하고, 실제 업무는 조직도 안에 등록된 AI Agent가 수행한다. 이 글의 Buyer Agent / Supplier Agent / Forwarder Agent는 외부 AI 도구가 아니라, 각 회사의 조직도 안에 '구매팀 담당자', '영업팀 담당자', '물류팀 담당자'로 실제 등록되는 AI 직원이다. 사람 직원과 동일한 권한 모델, 동일한 예산 한도, 동일한 감사 로그 위에서 일한다.
| # | Buyer Agent | → | Supplier Agent | → | Forwarder Agent |
|---|---|---|---|---|---|
| 1 | RFQ 발송 | → | RFQ 수신 | ||
| 2 | 물류 견적 요청 | → | 요청 수신 | ||
| 3 | 견적 수신 | ← | 상품 견적 발송 | ||
| 4 | 물류 견적 수신 | ← | 물류 견적 발송 | ||
| ★ | 비교표 생성 → 담당자 승인 | ||||
| 5 | PO 발행 | → | 주문 확정 | ||
| 6 | 부킹 요청 | → | 부킹 확정 | ||
왜 견적에 AI Agent인가
견적 업무가 느린 이유는 복잡해서가 아니다. 반복적인 정보 수집과 조합이 사람의 시간을 잡아먹기 때문이다. 공급사 담당자가 바이어의 과거 주문 이력을 찾고, 현재 재고를 확인하고, 최근 시세를 파악하고, 물류비를 포워더에게 문의하고, 이 모든 것을 조합해서 견적서를 만든다. 이 과정에서 진짜 의사결정이 필요한 구간은 최종 가격 승인 정도다. 나머지는 데이터 수집과 조합이다.
AI Agent가 효과적인 영역이 바로 이런 구간이다. 정형화된 데이터를 수집하고, 과거 패턴을 참조하여 초안을 만들고, 사람에게 승인을 요청하는 구조. REINDEERS 플랫폼에는 이미 이 Agent가 참조할 데이터가 있다. 4,300+ 파트너(바이어 2,500+, 공급사 1,800+, 포워더 30+)의 프로필, 25,000+건의 실거래 데이터, 2015년 IMARKET Thailand 설립 이후 약 11년간 축적된 거래 패턴이다.
이 데이터를 기반으로 세 종류의 AI Agent를 설계하고 있다. 바이어 측 Agent, 공급사 측 Agent, 포워더 측 Agent. 각 Agent는 자기 측의 이해관계를 반영하여 견적을 요청하거나 발행하며, Agent 간 통신으로 견적 교환이 이루어지는 구조다. 여기서 중요한 설계 원칙은 "한쪽이 모두를 대표하지 않는다"는 점이다. 바이어·공급사·포워더는 이해관계가 다른 독립 주체이므로, 각자의 Agent가 각자의 관점에서 행동해야 협상 구조가 성립한다.
LLM 모델링 전략
견적 AI Agent를 설계할 때 가장 먼저 결정해야 하는 것은 LLM을 어떻게 활용할 것인가다. 모든 작업에 동일한 모델을 쓰는 것은 비용 낭비이자 지연 시간 낭비다. 견적 프로세스를 분석하면 작업의 복잡도가 확연히 다른 구간들이 존재한다.
작업별 모델 배정 전략
모델 배정 기준은 작업 복잡도와 응답 품질 요구 수준이다. 세 티어로 나눈다.
| 모델 티어 | 적용 작업 | 선택 근거 | 예상 비용 |
|---|---|---|---|
| 경량 모델 | RFQ 파싱, 품목 분류, HS Code 매칭, 인코텀즈 추출, 구조화 데이터 변환 | 정형 데이터 추출은 경량 모델로 충분. 처리 속도가 중요한 구간 | ~$0.001/건 |
| 중간 모델 | 견적 초안 생성, 가격 산출 추론, 공급사 매칭 스코어링, 다국어 견적서 작성 | 컨텍스트를 종합하여 추론이 필요한 핵심 작업. 비용 대비 품질 최적점 | ~$0.01/건 |
| 고성능 모델 | 복잡 협상 시나리오, 예외 처리(비표준 인코텀즈, 분할 선적 조건), 다자간 카운터 오퍼 | 다수 제약조건을 동시에 충족하는 최적해 탐색. 호출 빈도가 낮아 비용 부담 적음 | ~$0.08/건 |
실제 견적 프로세스에서 대부분의 호출은 경량 모델과 중간 모델이 처리한다. 고성능 모델은 전체 호출의 5% 미만으로 추정하고 있다. 이 분배가 중요한 이유는 비용이다. 하루 100건의 견적을 처리한다고 가정할 때, 전부 고성능 모델을 쓰면 약 $8/일이 드는 반면, 티어링을 적용하면 $1.5/일 수준으로 줄어든다. "작업 난이도에 맞는 모델을 쓴다"는 단순한 원칙이 비용 구조 전체를 바꾼다.
Prompt Engineering vs Fine-tuning 전략
견적 도메인에 LLM을 적용하는 방법은 크게 두 가지다. 프롬프트 엔지니어링(지시와 예시)과 파인튜닝(도메인 데이터로 모델 자체를 조정). 두 가지를 순차로 도입하는 2단계 전략을 설계하고 있다.
시스템 프롬프트 구성:
1. 역할 정의: "B2B 무역 견적 전문가. 동남아 시장 11년 거래 데이터 기반"
2. 출력 포맷: 구조화된 JSON 강제 (자유 텍스트 금지)
3. Few-shot 예시: 실제 성사된 견적 3~5건을 예시로 주입
- 예시 선정 기준: 동일 품목 카테고리, 유사 거래 규모
- 예시 포함 정보: RFQ 원문, 생성된 견적, 최종 합의 가격, 성사 여부
4. 컨텍스트: 의미 검색 + 정형 조회 결과를 구조화하여 주입
// Phase 2: Fine-tuning (데이터 축적 후)
전제 조건:
- 라벨링된 견적-응답 쌍 5,000건 이상 축적
- 라벨: (RFQ, 생성 견적, 최종 합의가, 성사/불발, 수정 내역)
- 현재 25,000+건 거래 데이터에서 견적 교환 이력을 추출/정제하는 작업 필요
파인튜닝 대상:
- 중간 모델을 도메인 특화 모델로 조정
- 기대 효과: 프롬프트 길이 축소(예시 주입 불필요) -> 토큰 비용 30~40% 절감
- 가격 예측 정확도 향상: 도메인 특화 패턴 학습
Phase 1에서 충분한 성과가 나오면 Phase 2는 하지 않을 수도 있다. 파인튜닝은 데이터 준비, 학습, 검증에 상당한 리소스가 필요하기 때문에, 프롬프트 엔지니어링만으로 목표 정확도(견적 수락율 70% 이상)에 도달하면 유지하는 편이 낫다. 이 결정은 "성능의 마지막 10%"와 "운영 비용" 사이의 트레이드오프다.
토큰 비용 최적화
LLM 비용에서 가장 큰 비중은 입력 토큰이다. 컨텍스트를 무작정 많이 넣으면 정확도는 오를 수 있지만 비용도 비례해 증가한다. 설계하고 있는 최적화는 세 가지다.
첫째, 구조화 출력이다. 자유 텍스트 대신 정해진 스키마를 강제하면, 모델이 불필요한 설명 문구를 생성하지 않는다. 견적서 항목(가격, 수량, 납기, 조건)은 모두 정형화할 수 있으므로, 출력 토큰을 60~70% 줄일 수 있다.
둘째, 선택적 컨텍스트 주입이다. 과거 거래 이력 전체를 넣는 것이 아니라, 의미 검색으로 가장 유사한 건만 top-5로 필터링하고, 정형 조회 결과는 집계값(평균가, 거래 횟수, 최종 가격)만 넣는다. 원시 데이터가 아니라 요약된 팩트를 주입하는 방식이다.
셋째, 패턴 캐싱이다. 동일한 바이어-공급사-품목 조합으로 반복 견적이 요청되면, 이전 응답을 캐시하여 재사용한다. 최근 시세 대비 2% 이내 변동 구간에서는 캐시된 견적 템플릿에 수치만 업데이트해 LLM 호출을 건너뛸 수 있다.
다국어 견적 처리
REINDEERS의 견적은 4개 언어가 혼재한다. 한국어, 태국어, 영어, 중국어. 바이어가 태국어로 RFQ를 보내고, 공급사가 한국어로 내부 시스템을 운영하며, 공식 견적서는 영어로 작성되는 상황이 일상적이다. 두 가지 전략을 설계하고 있다.
전략 1: 내부 처리 언어 통일
입력(TH/KR/CN/EN) -> 경량 모델로 영어 번역 -> Agent 내부 처리(EN)
-> 견적 생성(EN) -> 수신자 선호 언어로 번역 -> 출력(TH/KR/CN/EN)
전략 2: 구조화 데이터는 번역하지 않음
수량, 가격, HS Code, 인코텀즈 등 정형 필드: 언어 무관
번역 대상: 품목 설명, 특수 조건, 비고란 등 자유 텍스트만
-> 번역 대상 토큰을 최소화하여 비용과 오역 리스크 동시 절감
다국어 의미 검색도 필요하다. 태국어 RFQ와 과거 한국어 견적서 사이의 의미적 유사도를 계산해야 하므로, 다국어 임베딩 모델의 도입을 검토하고 있다. 이 부분은 RAG 파이프라인 설계에서 다시 다룬다.
Buyer Agent: 견적 요청의 자동화
바이어의 AI Agent는 구매 요청을 RFQ로 변환하여 적절한 공급사에게 전송한다. 단순히 "이 품목 견적 주세요"를 보내는 것이 아니다. 바이어의 컨텍스트를 이해하고, 그에 맞는 조건을 포함한 구조화된 RFQ를 생성한다.
Buyer Agent가 참조하는 데이터는 다음과 같다. 해당 바이어의 과거 구매 이력(품목, 수량, 단가, 빈도), 선호 공급사 목록과 각 공급사별 거래 만족도, 예산 범위와 목표 단가, 납기 요구사항(긴급/일반), 필요한 인증 정보(TISI, FDA 등). 이 정보들은 REINDEERS 플랫폼의 거래 데이터에서 추출된다.
BuyerAgent.createRFQ(purchaseRequest)
1. 구매 요청 분석
- 품목: PP Resin, 수량: 200MT, 희망 납기: 45일 이내
2. 컨텍스트 수집
- 의미 검색: 최근 6개월 평균 단가: $1,180/MT
-> 주요 공급사: S-0412 (3회), S-1087 (2회), S-0953 (1회)
- 정형 조회: 필요 인증: TISI 마크, FDA 수입허가
3. 공급사 선정 (scoring)
- S-0412: 거래 빈도 높음, 납기 준수율 94%, 단가 경쟁력 중
- S-1087: 거래 빈도 중, 납기 준수율 98%, 단가 경쟁력 상
- S-0953: 거래 빈도 낮, 신규 물량 확보 의지 높음
-> 3개 공급사 모두에게 RFQ 전송 결정
4. 구조화된 RFQ 메시지 생성
{
rfq_id, buyer_id,
items: [{ sku, qty, unit }],
delivery_deadline,
preferred_incoterms,
certifications_required,
budget_range
}
여기서 중요한 점은 Buyer Agent가 직접 발주를 넣지 않는다는 것이다. Agent는 RFQ를 생성하고, 바이어 담당자에게 "이 조건으로 3개 공급사에 견적을 요청하겠습니다"라고 확인을 구한다. 담당자가 승인하면 RFQ가 전송되고, 수정 사항이 있으면 반영 후 재전송한다. "제안은 Agent, 결정은 사람"이라는 원칙이 RFQ 단계부터 구현된다.
Supplier Agent: 견적 발행의 자동화
Supplier Agent는 Buyer Agent로부터 RFQ를 수신하면 견적서 초안을 생성한다. 이 Agent가 견적을 만드는 과정이 시스템의 핵심이다. 단순히 카탈로그 가격을 회신하는 것이 아니라, 바이어별 맞춤 가격을 산출한다.
Supplier Agent의 컨텍스트
Supplier Agent가 견적을 생성할 때 참조하는 데이터 소스는 크게 네 가지다.
| 데이터 소스 | 내용 | 견적에 미치는 영향 |
|---|---|---|
| 과거 견적 이력 | 이 바이어 + 유사 바이어에게 발행한 이전 견적 | 가격 일관성 유지, 이전 할인율 참조 |
| 바이어 프로필 | 소재지, 주문 빈도, 결제 신뢰도, 매출 규모 | 전략적 가격 책정 (대량 거래처 우대 등) |
| 재고/생산 현황 | 현재 재고 수량, 생산 캐파, 납기 가능일 | 납기 설정, 긴급 주문 시 할증 여부 |
| 시장 가격 데이터 | 25,000+건 거래 기록 기반 시세 추이 | 시장 대비 경쟁력 있는 가격 산출 |
이 네 가지 데이터를 조합하여 Supplier Agent는 견적 초안을 만든다. 예를 들어, 바이어 B-2847이 과거 6개월간 3회 주문했고 결제가 항상 정시에 이루어졌다면, Agent는 이를 "신뢰도 높은 반복 거래처"로 판단하여 2~3% 우대 가격을 제안할 수 있다. 반면 첫 거래 바이어에게는 시장 평균가로 견적을 시작한다.
SupplierAgent.generateQuote(rfq, supplierContext)
Step 1: 바이어 히스토리 조회
buyerHistory = retrieve(
collection: "quotes",
filter: { supplier_id, buyer_id },
sort_by: created_at desc, limit: 10
)
Step 2: 시장 가격 벤치마크
marketPrice = query(
"최근 90일 동일 품목 평균 단가"
) // -> $1,185/MT
Step 3: 바이어 등급 기반 가격 조정
buyerTier = evaluateBuyerTier(buyerHistory)
// orderCount: 3, paymentScore: 100, avgVolume: 180MT
// -> tier: "SILVER", discountRange: 1~3%
Step 4: 재고/캐파 확인
inventory = query("현재 가용 재고") // -> 450MT
Step 5: 견적 초안 생성 (사람 승인 전)
quoteDraft = {
unit_price: 1155, // 시장가 대비 2.5% 할인
lead_time_days: 30,
valid_until: "...",
incoterms: "FOB Bangkok",
confidence: 0.82, // 자동 승인 임계값(0.9) 미달
reasoning: "반복 거래처 우대(SILVER), 시장가 대비 경쟁력"
}
마지막 줄의 confidence: 0.82가 중요하다. 이 값은 Agent가 자체적으로 산출하는 신뢰도 점수다. 과거 유사 견적의 승인율, 가격 편차, 바이어 반응 패턴을 기반으로 계산한다. 임계값(예: 0.9) 이상이면 자동으로 바이어에게 전송되고, 미달이면 공급사 담당자의 검토를 거친다. "AI가 제안하고, 사람이 결정한다"는 원칙이 이 점수를 통해 구체화된다.
Forwarder Agent: 물류 견적의 자동화
B2B 무역에서 상품 가격만으로 거래가 결정되지 않는다. 물류비가 총비용의 상당 부분을 차지하며, 인코텀즈에 따라 물류비 부담 주체가 달라진다. FOB 조건이면 바이어가 물류를 담당하고, CIF나 DDP 조건이면 공급사가 포함한다. 이 물류 견적을 담당하는 것이 Forwarder Agent다.
REINDEERS 플랫폼에는 30+개의 포워더가 등록되어 있다. 각 포워더는 강점이 다르다. 태국-한국 해상 운송에 강한 포워더, 중국-동남아 항공 화물에 경쟁력 있는 포워더, 소량 화물에 유연한 포워더, 대량 벌크에서 가격이 좋은 포워더. Forwarder Agent는 이 특성을 학습하여 최적의 물류 견적을 생성한다.
Forwarder Agent의 견적 산출 기준
| 입력 변수 | 설명 |
|---|---|
| 인코텀즈 | FOB, EXW, CIF, DDP 등에 따라 물류 범위가 달라짐 |
| 출발지/도착지 | 공급사 공장 위치, 바이어 창고/항구 위치 |
| 운송 모드 | 해상, 항공, 트럭, 복합 운송. 화물 종류와 긴급도에 따라 결정 |
| 스케줄 요구사항 | 납기일 기준 역산하여 선적일, 도착 예정일 계산 |
| 포워더별 이력 | 각 포워더의 노선별 가격 패턴, 계절별 변동, 화물 유형별 경쟁력 |
Forwarder Agent의 특징은 경쟁 구조를 만들 수 있다는 점이다. 하나의 물류 요청에 대해 복수의 Forwarder Agent가 각각 견적을 생성하고, Buyer Agent(또는 Supplier Agent)가 이를 비교한다. 지금까지 사람이 수작업으로 3~5개 포워더에 이메일을 보내고 회신을 기다리던 과정을 Agent 간 통신으로 대체한다. 포워더 측도 자동 견적의 이점이 있다. 반복적인 견적 요청에 빠르게 대응해 수주 기회를 높일 수 있다.
Agent 간 통신 구조
세 종류의 Agent가 견적을 주고받으려면 구조화된 통신 프로토콜이 필요하다. 자연어 이메일처럼 비정형 데이터를 교환하면 Agent가 파싱에 실패하거나 오해석할 수 있다. 설계하고 있는 구조는 구조화된 메시지 포맷이다.
Phase 1: RFQ 전송
BuyerAgent -> SupplierAgent(s): RFQ 메시지
BuyerAgent -> ForwarderAgent(s): 물류 견적 요청 (인코텀즈에 따라)
Phase 2: 견적 수신
SupplierAgent -> BuyerAgent: 상품 견적 (가격, 납기, 조건)
ForwarderAgent -> BuyerAgent: 물류 견적 (운임, 스케줄, 경로)
Phase 3: 비교 및 조합
BuyerAgent: 상품 견적 + 물류 견적 조합 -> 총비용 비교표 생성
BuyerAgent -> 바이어 담당자: 비교표 + 추천안 제시
Phase 4: 협상 (선택)
BuyerAgent -> SupplierAgent: 가격 조정 요청 (카운터 오퍼)
SupplierAgent -> BuyerAgent: 수정 견적
Phase 5: 확정
바이어 담당자 승인 -> BuyerAgent -> SupplierAgent: PO 전송
-> ForwarderAgent: 부킹 요청
전체 흐름에서 사람이 개입하는 지점은 두 곳이다. Phase 1에서 RFQ 발송 전 바이어 담당자의 승인, Phase 5에서 최종 발주 전 바이어 담당자의 승인. 나머지 구간은 Agent가 자율 처리한다. 담당자가 원하면 어느 시점에서든 개입해 조건을 수정하거나 Agent의 판단을 오버라이드할 수 있다.
Agent 아키텍처 상세
Agent 시스템의 구현에서 가장 중요한 설계 결정은 오케스트레이션 패턴이다. 세 Agent가 독립적으로 동작하면서도 하나의 견적 프로세스를 완결해야 하기 때문이다.
오케스트레이션 패턴: 계층형 vs 피어투피어
두 가지 패턴을 비교 검토하고 있다.
| 패턴 | 구조 | 장점 | 단점 |
|---|---|---|---|
| 계층형 | Orchestrator Agent가 Buyer/Supplier/Forwarder Agent를 지휘 | 흐름 제어가 명확, 디버깅 용이, 상태 관리 집중화 | Orchestrator가 단일 장애점, 복잡한 협상 시 병목 |
| 피어투피어 | 각 Agent가 직접 메시지 교환, 중앙 조정자 없음 | 유연한 협상 흐름, 확장성 | 상태 추적 어려움, 교착 상태 가능성 |
현재 기울어지고 있는 쪽은 계층형이다. 견적 프로세스는 Phase가 명확하고(RFQ → 견적 → 비교 → 협상 → 확정), 각 Phase의 진입/종료 조건을 Orchestrator가 관리하는 것이 안정적이다. Orchestrator Agent 자체는 LLM이 아니라 상태 머신으로 구현하고, 각 단계에서 적절한 전문 Agent를 호출하는 방식이다. 이 선택의 논리는 단순하다. "Agent끼리 자유롭게 대화하게 두면 놀라운 결과가 나올 수도, 교착 상태에 빠질 수도 있다. 돈이 움직이는 영역에서는 예측 가능한 흐름이 우선이다."
Agent 프레임워크 요구사항
Agent 프레임워크를 선택하기 위해 평가하고 있는 요구사항은 다음과 같다.
| 요구사항 | 설명 | 우선순위 |
|---|---|---|
| Tool Binding | Agent가 DB 조회, 의미 검색, 환율 조회, 알림 전송 등의 도구를 호출 | 필수 |
| Human Approval Gate | Agent 실행 흐름 중간에 사람 승인을 요청하고 대기하는 메커니즘 | 필수 |
| Multi-Agent 오케스트레이션 | 복수 Agent 인스턴스의 동시 실행, 메시지 라우팅, 상태 동기화 | 필수 |
| 메모리 관리 | 협상 컨텍스트 유지(단기), 바이어-공급사 패턴 학습(장기) | 높음 |
| 관측 가능성 | 각 Agent의 추론 과정, 도구 호출 이력, 의사결정 근거 추적 | 높음 |
| 비용 추적 | 견적 건별 LLM 호출 비용, 토큰 사용량 집계 | 중간 |
Tool Binding 구조
각 Agent가 호출할 수 있는 도구는 역할에 따라 다르다. Buyer Agent는 공급사 검색과 비교에 특화된 도구를, Supplier Agent는 재고/가격 조회 도구를, Forwarder Agent는 운송 스케줄/요금 조회 도구를 사용한다. 공통 도구도 있다.
공통 도구:
db_query(query, params) // 정형 데이터 조회
semantic_search(query, filters) // 의미 검색
get_exchange_rate(from, to) // 실시간 환율
notify_human(user_id, message) // 승인 요청 알림
Buyer Agent 전용:
search_suppliers(criteria) // 조건에 맞는 공급사 검색
compare_quotes(quote_ids) // 수신 견적 비교표 생성
get_buyer_budget(buyer_id) // 예산 한도 조회
Supplier Agent 전용:
check_inventory(sku) // 재고/생산 캐파 확인
get_pricing_history(sku, buyer) // 바이어별 가격 이력
get_market_benchmark(sku) // 시장 벤치마크 가격
Forwarder Agent 전용:
get_shipping_schedule(route) // 선사별 스케줄
calc_freight(origin, dest, cargo) // 운임 산출
check_port_congestion(port) // 항구 혼잡도 확인
환율과 선사 스케줄 도구는 이미 REINDEERS 인프라에서 운영 중인 서비스를 그대로 활용한다. 환율 수집 모듈이 4개국 환율을 집계하고 있고, 해운 스케줄 크롤러가 주요 선사 스케줄을 주기적으로 수집한다. 기존 인프라를 Agent의 도구로 래핑하는 것이므로 추가 개발 부담이 크지 않다. 이건 작은 일 같지만 중요하다. "Agent를 붙이기 위해 새 인프라를 만드는 것"이 아니라 "Agent가 쓸 수 있도록 기존 인프라에 얇은 어댑터를 덧대는 것"이 실제 비용과 리스크를 결정한다.
메모리 아키텍처
Agent가 지능적으로 동작하려면 컨텍스트를 기억해야 한다. 모든 것을 기억할 필요는 없다. 설계하고 있는 메모리는 세 계층이다.
| 메모리 계층 | 저장 내용 | 저장소 성격 | 수명 |
|---|---|---|---|
| 단기 메모리 | 현재 견적 협상 컨텍스트. 진행 중인 RFQ, 수신 견적, 카운터 오퍼 이력 | 분산 캐시 / 인메모리 | 견적 완료 시 소멸 (최대 7일) |
| 장기 메모리 | 바이어-공급사 쌍별 학습된 가격 패턴, 할인 기준, 선호 조건 | 분산 SQL DB | 영구 (주기적 갱신) |
| 에피소딕 메모리 | 과거 협상 결과, 사람이 수정한 내역, 실패 사유 | 의미 검색 DB | 영구 (검색 대상) |
에피소딕 메모리가 가장 흥미로운 부분이다. "3개월 전 바이어 B-2847이 PP Resin 견적에서 가격을 거부했는데, 그때 가격이 $1,220이었고 최종 합의가 $1,170이었다"는 정보는 다음 견적에서 직접적인 참조가 된다. 이런 협상 에피소드가 저장되면, 유사한 상황에서 Agent가 더 현실적인 가격을 제안할 수 있다. 사람이 수정한 내역이야말로 가장 가치 있는 학습 데이터다. "Agent가 제안한 가격을 사람이 $1,170으로 내렸다"는 기록은 모델 파인튜닝에 쓰지 않더라도 다음 번 컨텍스트 주입으로 즉시 반영된다.
상태 관리: 멀티턴 협상 처리
견적 협상은 단일 요청-응답이 아니다. 카운터 오퍼가 2~3회 오갈 수 있고, 중간에 물류 조건이 변경되거나 납기가 조정될 수 있다. 이 멀티턴 협상을 Agent가 처리하려면 대화 상태를 일관되게 유지해야 한다.
NegotiationSession {
session_id,
rfq_id,
state: "COUNTER_OFFER",
// INIT|RFQ_SENT|QUOTES_RECEIVED|COMPARING|COUNTER_OFFER|APPROVED|CLOSED
participants: { buyer, suppliers[], forwarders[] },
turn_history: [
{ turn: 1, from: "BuyerAgent", type: "RFQ" },
{ turn: 2, from: "SupplierAgent", type: "QUOTE", price: 1180 },
{ turn: 3, from: "BuyerAgent", type: "COUNTER", target: 1150 },
{ turn: 4, from: "SupplierAgent", type: "REVISED", price: 1160 }
],
constraints: {
max_turns: 5, // 무한 협상 방지
timeout_hours: 72,
auto_approve_threshold: 0.9
}
}
max_turns: 5는 의도적인 제한이다. AI Agent끼리 무한히 카운터 오퍼를 주고받는 상황을 방지한다. 5회 이내에 합의에 도달하지 못하면 세션이 사람에게 에스컬레이션되어 직접 협상으로 넘어간다. "Agent가 끝없이 대화해도 비용은 계속 나간다"는 실무적 사실이 이 숫자의 배경이다.
RAG 파이프라인 설계
각 Agent가 적절한 견적을 생성하려면 올바른 컨텍스트를 참조해야 한다. 이를 위한 RAG(Retrieval-Augmented Generation) 파이프라인을 설계하고 있다. 핵심은 두 가지 검색 경로의 조합이다.
[경로 1: 의미 검색 -- 유사 견적 탐색]
입력: RFQ 내용 (품목, 수량, 조건)
-> 임베딩 생성
-> 유사 견적 top-K 검색
-> 결과: 과거 유사 거래의 가격, 조건, 결과(성사/실패)
[경로 2: 정형 조회 -- 정확한 팩트]
-> partner: 바이어 등급, 소재지, 결제 조건
-> transaction: 최근 거래 가격, 수량, 빈도
-> inventory: 현재 재고, 생산 캐파
-> market_price: 품목별 시세 추이
[병합]
의미 검색 결과 + 정형 조회 결과 -> LLM 컨텍스트 윈도우에 주입
-> Agent가 근거 기반 견적 초안 생성
두 경로를 분리하는 이유가 있다. "이 바이어에게 비슷한 품목으로 과거에 어떤 가격을 제시했는가"는 의미 검색이 효과적이다. 견적서 텍스트의 의미적 유사도로 관련 사례를 찾는다. 반면 "현재 재고가 몇 톤인가", "이 바이어의 결제 신뢰도 점수는 얼마인가"는 정확한 수치가 필요하므로 정형 쿼리가 적합하다. 두 결과를 LLM 컨텍스트에 함께 주입하면, Agent는 유사 사례의 패턴과 현재의 정확한 팩트를 모두 참조하여 견적을 생성할 수 있다. 한쪽만 쓰면 반드시 실수가 난다. 의미 검색만 쓰면 "비슷하지만 재고에 없는 품목"을 제안할 수 있고, 정형 조회만 쓰면 "바이어의 과거 선호"를 놓친다.
임베딩 모델 선정
의미 검색의 품질은 임베딩 모델에 의해 결정된다. REINDEERS의 견적 데이터는 4개 언어가 혼재하므로, 단일 언어 모델은 사용할 수 없다. 평가 기준은 다음과 같다.
| 평가 기준 | 요구 사항 | 비고 |
|---|---|---|
| 다국어 지원 | KR/TH/EN/CN 4개 언어의 의미적 유사도를 동일 벡터 공간에서 비교 가능 | 다국어 임베딩 모델 후보 비교 중 |
| 도메인 적합성 | B2B 무역 용어(인코텀즈, HS Code, 선적 조건)의 의미를 정확히 표현 | 범용 모델 성능 확인 후, 필요시 대조 학습으로 도메인 적응 |
| 추론 속도 | 견적 생성 시 50ms 이내 임베딩 완료 | 배치 임베딩은 오프라인, 실시간 쿼리 임베딩만 지연 시간 영향 |
| 차원 수 | 1024차원 이하 (저장 비용과 검색 속도 균형) | 768~1024 범위가 정확도/비용 최적점 |
도메인 적응이 필요한 이유는 구체적이다. "FOB Bangkok"이라는 텍스트는 범용 임베딩에서는 단순한 지명으로 처리될 수 있지만, 무역 도메인에서는 "방콕항 선적 기준 가격, 내륙 운송비 미포함, 수출 통관 공급사 부담"이라는 복합 의미를 가진다. 이런 도메인 특수 의미를 벡터에 반영하기 위해, 실제 견적서에서 추출한 용어 쌍(동일 의미/다른 의미)으로 대조 학습을 적용하는 것을 검토하고 있다.
청킹 전략
문서를 임베딩 단위로 분할하는 청킹 전략은 문서 유형별로 다르게 설계하고 있다. 무역 견적 데이터는 일반 텍스트 문서와 구조가 다르기 때문이다.
1. 견적서 (Quote Documents)
청킹 단위: 라인 아이템(line item) 기준
예시: 견적서 1건에 품목 5개 -> 5개 청크
각 청크 포함 정보:
{ sku, description, qty, unit_price, total, incoterms }
메타데이터: quote_id, buyer_id, supplier_id, date, status(성사/불발)
2. 거래 기록 (Transaction Records)
청킹 단위: 건별(per-transaction)
각 청크 포함 정보:
{ sku, qty, final_price, route, incoterms, lead_time_actual }
메타데이터: buyer_id, supplier_id, forwarder_id, date, satisfaction_score
3. 파트너 프로필 (Partner Profiles)
청킹 단위: 속성별(per-attribute) 분리
- 기본 정보 청크: 회사명, 소재지, 취급 품목, 인증
- 결제 이력 청크: 결제 신뢰도, 평균 결제일, 연체 이력
- 주문 이력 청크: 주문 빈도, 평균 주문량, 선호 인코텀즈
이유: 가격 산출 시에는 결제 이력이, 공급사 선정 시에는 기본 정보가 검색되도록 분리
라인 아이템 기준으로 견적서를 쪼개는 이유는 검색 정밀도 때문이다. "PP Resin 200MT FOB 견적"을 검색할 때, 견적서 전체가 하나의 벡터이면 다른 품목(PE Resin, ABS 등)이 포함된 견적서도 높은 유사도로 반환된다. 품목별로 쪼개면 정확히 해당 품목의 과거 가격만 검색할 수 있다. "무엇을 하나의 의미 단위로 삼을 것인가"라는 질문은 단순하지만 검색 품질을 좌우한다.
의미 검색 저장소 선정 기준
의미 검색 저장소는 아직 확정하지 않았다. 선정을 위해 평가하고 있는 기준은 다음과 같다.
| 평가 항목 | 가중치 | 구체적 요구사항 |
|---|---|---|
| 메타데이터 필터링 | 매우 높음 | buyer_id, supplier_id, sku, date_range로 검색 범위 사전 제한 가능해야 함 |
| 검색 지연 시간 | 높음 | 100K 문서 기준 p99 < 50ms |
| 운영 비용 | 높음 | 초기 규모에서 월 $50 이하 |
| 하이브리드 검색 | 중간 | 키워드 + 시맨틱 동시 지원 여부 |
| 서버리스/관리형 | 중간 | 현 인프라와 접근 가능한 관리형 서비스 선호 |
4단계 검색 파이프라인
단순히 유사도 top-K를 가져오는 것으로는 충분하지 않다. 견적 도메인에서는 결과의 관련성, 신선도, 중복 제거가 모두 중요하다. 설계하고 있는 검색 파이프라인은 4단계다.
Step 1: 조 검색 (Coarse Retrieval)
방법: 근사 최근접 이웃 탐색
결과: top-100 후보
목적: 넓은 범위에서 후보 확보. 속도 우선
Step 2: 메타데이터 필터링
필터 조건:
- 동일 무역 루트 (출발국-도착국 일치 또는 인접 시장)
- 동일 품목 카테고리 (HS Code 앞 4자리 일치)
- 최근 12개월 이내 데이터
결과: ~30개로 축소
Step 3: 리랭킹
방법: (쿼리, 문서) 쌍의 관련도를 정밀 재계산하는 모델
특징: 조 검색보다 정확하지만 느림. 30개에만 적용하므로 실용적
결과: 관련도 순으로 재정렬
Step 4: 중복 제거 + 신선도 가중
중복 제거: 동일 바이어-공급사 쌍의 견적이 여러 건이면 최신 1건만 유지
신선도 가중:
- 3개월 이내: 가중치 1.0
- 3~6개월: 0.7
- 6~12개월: 0.4
최종 결과: top-5를 LLM 컨텍스트에 주입
하이브리드 검색: 키워드 + 시맨틱
의미 검색만으로는 부족한 경우가 있다. HS Code(예: 3901.10), 부품 번호(예: PP-H1500), 인코텀즈(FOB, CIF) 같은 코드성 데이터는 의미적 유사도보다 정확한 문자열 매칭이 중요하다. "3901.10"을 의미 검색하면 숫자가 비슷한 전혀 다른 품목(예: 3902.10 , PE Resin)이 높은 유사도로 나올 수 있다.
이를 해결하기 위해 키워드 검색(BM25 같은)과 의미 검색을 결합하는 하이브리드 검색을 설계하고 있다. HS Code, 부품 번호, 인코텀즈 같은 코드 필드는 키워드로 정확 매칭하고, 품목 설명·거래 조건 같은 자유 텍스트는 의미 검색으로 처리한다. 두 결과를 RRF(Reciprocal Rank Fusion) 같은 랭크 병합 방식으로 섞으면, 코드 정확성과 의미적 관련성을 동시에 확보할 수 있다.
Human-in-the-Loop: 신뢰도 기반 승인 게이트
"AI가 제안하고, 사람이 결정한다." 이것이 견적 AI Agent 설계의 기본 원칙이다. 하지만 모든 견적에 사람의 승인을 요구하면 자동화의 의미가 없어진다. 반복 거래처에 대한 정형화된 견적까지 매번 사람이 확인할 필요는 없다.
이 문제를 풀기 위해 설계하고 있는 것이 신뢰도 기반 승인 게이트다. Agent가 생성하는 모든 견적에는 confidence score가 부여된다. 이 점수는 다음 요소를 기반으로 산출한다.
| 요소 | 가중치 | 설명 |
|---|---|---|
| 유사 견적 존재 여부 | 높음 | 과거에 같은 바이어 + 같은 품목 견적이 있으면 신뢰도 상승 |
| 가격 편차 | 높음 | 시장 평균 대비 가격 편차가 클수록 신뢰도 하락 |
| 거래 이력 길이 | 중간 | 바이어와의 거래 이력이 길수록 패턴 예측이 정확 |
| 조건 복잡도 | 중간 | 특수 인증, 비표준 인코텀즈 등 예외 조건이 많으면 신뢰도 하락 |
| 금액 규모 | 중간 | 고액 거래일수록 자동 승인 임계값을 높게 설정 |
각 기업은 자체 자동 승인 임계값을 설정할 수 있다. 예를 들어 $50,000 이하 견적은 confidence 0.85 이상이면 자동 전송, $50,000 초과는 무조건 사람 검토와 같은 규칙이다. 임계값 미달 시 Agent는 견적 초안과 함께 산출 근거(참조한 과거 견적, 시장가 비교, 바이어 등급)를 담당자에게 제시하고 승인을 요청한다. 담당자는 이 근거를 보고 승인·수정·거부를 선택한다.
이 구조에서 Agent는 시간이 지날수록 정확해진다. 담당자가 견적을 수정하면 그 수정 패턴이 다음 견적 생성에 반영된다. 처음에는 대부분 사람 검토를 거치지만, 거래 이력이 쌓이고 Agent가 해당 바이어-공급사 쌍의 가격 패턴을 학습할수록 자동 승인 비율이 점진적으로 높아지는 것을 목표로 한다. "처음부터 완벽한 Agent를 만들지 않는다. 사람과 함께 배우며 정확해지는 Agent를 만든다"는 접근이다.
POP 연동: 생산에서 발주까지 자동화
견적 AI Agent의 장기 비전은 POP(Production Operation Platform)과의 연동이다. POP은 제조사를 위한 생산 운영 플랫폼으로 MES, ERP, WMS 기능을 통합하며, 2026년 4~5월 베타 출시를 준비하고 있다.
POP이 관리하는 재고 수량, 구매 주기, 소비율이 견적 AI Agent와 직접 연결된다. 설계하고 있는 시나리오는 다음과 같다.
1. POP 재고 모니터링
PP Resin 재고: 45MT (안전재고 기준: 50MT)
평균 소비율: 8MT/주
발주 리드타임: 30일
-> 안전재고 미달 감지. 자동 발주 트리거
2. REINDEERS 자동 구매 요청 생성
POP -> REINDEERS API: 구매 요청
{ sku, qty, urgency, reason: "safety_stock_threshold" }
3. Buyer Agent 자동 기동
Buyer Agent: RFQ 생성 -> 등록된 공급사 Agent들에게 전송
4. Supplier Agent 견적 회신
3개 공급사로부터 견적 수신 (수 시간 이내)
5. Forwarder Agent 물류 견적
인코텀즈 기반 물류비 산출 (복수 포워더 경쟁)
6. 비교 및 승인
Buyer Agent: 총비용 비교표 생성 -> 구매 담당자에게 알림
담당자 승인 -> PO 발행 -> 거래 개시
7. 이후 프로세스 (AI Agent 확장 영역)
거래 -> 통관 -> 물류 추적 -> 입고 -> POP 재고 반영
전체 사이클이 데이터로 축적 -> 다음 발주의 정확도 향상
이 시나리오가 완성되면 "재고가 줄었다"는 신호 하나로 견적 요청, 가격 비교, 물류 수배, 발주까지 이어지는 자동화 파이프라인이 만들어진다. 사람은 최종 발주 승인과 예외 상황 처리에만 집중한다. 물론 이것은 향후 목표이며, POP 베타 이후 실제 생산 데이터가 축적되어야 구현이 가능한 단계다.
데이터 파이프라인
AI Agent가 정확한 견적을 생성하려면 최신의, 정제된 데이터가 필요하다. 원시 데이터를 Agent가 참조할 수 있는 형태로 가공하는 데이터 파이프라인을 설계하고 있다. 크게 실시간 경로와 배치 경로 두 가지다.
데이터 수집 경로
실시간 경로 (Event-Driven):
새 거래 생성 -> 이벤트 발행 -> 임베딩 파이프라인 -> 의미 검색 저장소 적재
새 견적 발행 -> 이벤트 발행 -> 임베딩 + 메타데이터 추출 -> 양쪽 저장소
파트너 정보 변경 -> 이벤트 발행 -> 해당 파트너 청크 재임베딩
환율 변동 -> 기존 수집기가 수집 -> Agent 도구로 실시간 제공
배치 경로 (Scheduled):
매일 02:00: 시장 가격 집계 (품목별 최근 90일 평균/중앙값/추이)
매주 일요일: 파트너 신뢰도 점수 재계산
매월 1일: 전체 임베딩 재생성 (모델 업데이트 반영)
수시: 신규 거래 데이터 라벨링 (성사/불발, 최종가 대비 초기 견적 편차)
실시간 경로가 필요한 이유는 명확하다. 오전에 새 거래가 성사되었는데 오후에 같은 바이어가 같은 품목 견적을 요청하면, 방금 성사된 가격을 참조해야 한다. 하루 전 배치 데이터만 보면 최신 시세를 반영하지 못한다.
데이터 품질 관리
견적 데이터의 품질 문제는 세 가지로 정리된다.
| 문제 | 예시 | 처리 방법 |
|---|---|---|
| 중복 | 같은 견적이 이메일, 플랫폼, 메신저로 중복 입력 | (buyer, supplier, sku, date) 복합 키로 중복 감지, 최신 버전만 유지 |
| 단위 불일치 | 가격이 USD인지 THB인지, 수량이 MT인지 KG인지 혼재 | 정규화: 모든 가격을 USD 기준값으로 환산, 수량은 기본 단위로 통일 |
| 시효성 | 2년 전 가격 데이터가 현재 시세에 영향을 줌 | 신선도 점수: 3개월 이내=1.0, 3~6개월=0.7, 6~12개월=0.4, 그 이상=패턴 참조만 |
견적 문서 스키마
의미 검색 저장소에 저장되는 견적 문서의 구조를 정리한다. 어떤 필드가 임베딩 대상이고 어떤 필드가 메타데이터인지를 명확히 구분하는 것이 검색 품질의 핵심이다.
QuoteDocument {
// === 임베딩 대상 (벡터 생성에 사용) ===
text_for_embedding:
"{sku_description} {qty}{unit} {incoterms} {origin}->{destination}"
// 예: "PP Resin H1500 200MT FOB Bangkok->Busan"
// === 메타데이터 (필터링에 사용, 임베딩에 포함하지 않음) ===
quote_id, buyer_id, supplier_id,
sku, hs_code, // 키워드 매칭 대상
unit_price_usd, // USD 정규화 가격
quantity, incoterms,
trade_route, // "TH->KR" 등
quote_date,
status, // ACCEPTED | REJECTED | EXPIRED | COUNTERED
final_price_usd, // 최종 합의가 (성사된 경우)
freshness_score // 0.0~1.0, 배치 잡에서 주기적 갱신
}
text_for_embedding에 가격을 넣지 않는 것은 의도적이다. 가격은 시간에 따라 변하는 값이므로 임베딩에 포함하면 의미적 유사도가 왜곡된다. "동일 품목, 동일 루트의 과거 거래"를 찾는 것이 의미 검색의 목적이고, 찾은 후에 메타데이터의 가격을 참조하여 현재 시세를 추론하는 것이 LLM의 역할이다. 두 레이어의 책임을 명확히 나누면 검색이 단순해지고 LLM의 추론이 정확해진다.
평가와 모니터링
AI Agent 시스템에서 가장 위험한 것은 "동작은 하는데 성과를 측정하지 못하는 상태"다. 견적 AI Agent가 실제로 비즈니스 가치를 만들고 있는지 판단하기 위한 평가 체계를 설계하고 있다.
핵심 성과 지표
| 지표 | 정의 | 목표값 | 측정 방법 |
|---|---|---|---|
| 견적 수락율 | AI 생성 견적이 상대방에게 수락된 비율 | Phase 1: 50%+ Phase 2: 70%+ |
수락 견적 수 / 전체 AI 생성 견적 수 |
| 가격 정확도 | AI 제안가와 최종 합의가의 차이 | MAPE 5% 이내 | |AI 제안가 - 최종가| / 최종가의 평균 |
| 처리 시간 | RFQ 수신부터 견적 초안 생성까지 소요 시간 | 3분 이내 | 타임스탬프 차이 (현재 수작업: 수 시간~수일) |
| 사람 오버라이드율 | 담당자가 AI 견적을 수정한 비율 | 30% 이하 | 수정 건수 / 사람 검토 건수. 낮을수록 AI 정확도 높음 |
| 자동 승인 비율 | 사람 검토 없이 자동 전송된 견적 비율 | 초기 10% -> 6개월 후 40% | 자동 전송 건수 / 전체 건수. 시간에 따라 상승해야 정상 |
평가 프레임워크
오프라인 평가와 온라인 평가를 병행하는 구조를 설계하고 있다.
오프라인 평가 (백테스팅): 프로덕션 배포 전에 과거 데이터로 Agent의 성능을 검증한다. 25,000+건의 거래 기록에서 견적 교환 이력이 포함된 건을 추출하고, AI Agent에게 해당 RFQ를 입력했을 때 실제 성사 가격에 얼마나 근접한 견적을 생성하는지 측정한다. 백테스팅의 한계는 "당시 시장 상황"을 완벽히 재현할 수 없다는 점이다. 따라서 절대 정확도보다는 상대적 개선(기준 모델 대비)을 평가 기준으로 삼는다.
온라인 평가 (A/B 테스트): 프로덕션 배포 후에는 A/B 테스트로 실제 효과를 측정한다. 동일한 바이어 세그먼트를 두 그룹으로 나누어, 하나는 AI 견적 보조를 받고 하나는 기존 수작업으로 진행한다. 측정 항목은 견적 처리 시간, 성사율, 최종 가격, 고객 만족도다. A/B 테스트는 최소 2개월 이상 운영하여 통계적 유의미성을 확보해야 한다.
비용 구조 분석
AI Agent의 경제성을 판단하기 위해 견적 건당 비용을 추산하고 있다.
LLM API 비용:
경량 모델 (분류/파싱) x 2~3회: ~$0.003
중간 모델 (견적 생성) x 1회: ~$0.010
고성능 모델 (필요시) x 0.05회: ~$0.004
소계: ~$0.017/건
의미 검색 비용:
100K 문서 기준 호스팅: ~$30/월
건당 배분: ~$0.01 (월 3,000건 가정)
합계: ~$0.027/건
// 손익분기점 분석
수작업 견적 비용:
담당자 시급(동남아 평균): ~$8/시간
견적 1건 소요 시간: 평균 2시간
수작업 비용: ~$16/건
AI 보조 견적 비용:
AI Agent 비용: $0.027
담당자 검토 시간: 평균 10분 ($1.33)
AI 보조 비용: ~$1.36/건
절감 효과: 건당 ~$14.64 (91.5% 절감)
월 3,000건 기준: ~$43,920/월 절감
이 추산은 이상적인 시나리오다. 실제로는 Agent 개발/유지보수 비용, 데이터 파이프라인 운영 비용, 초기 학습 기간의 낮은 정확도에 따른 추가 검토 시간이 포함된다. 그래도 핵심은 변하지 않는다. LLM API 비용은 건당 3센트 미만이고, 사람의 반복 노동 비용이 건당 $16인 상황에서 AI 보조의 경제성은 명확하다. 손익분기는 월 50건만 처리해도 달성된다.
현재 상태와 구현 로드맵
솔직하게 현재 상태를 정리한다. 견적 AI Agent 시스템은 아키텍처 설계와 데이터 파이프라인 구축 단계에 있다. 프로덕션에서 동작하고 있는 것이 아니다.
| 구분 | 상태 | 비고 |
|---|---|---|
| 파트너 데이터 | 운영 중 | 4,300+ 파트너 프로필, 거래 이력 25,000+건 |
| REINDEERS 거래 플랫폼 | 운영 중 | 2025-12-01 공식 오픈 |
| DVRP (물류 배차) | 베타 운영 | 2026-03 베타 출시 |
| POP (생산 운영) | 개발 중 | 2026년 4~5월 베타 목표 |
| RAG 파이프라인 | 설계 중 | 의미 검색 + 정형 조회 이중 경로 아키텍처 |
| Agent 간 통신 프로토콜 | 설계 중 | 메시지 포맷, 승인 게이트 정의 |
| Buyer/Supplier/Forwarder Agent | 계획 단계 | RAG 파이프라인 완성 후 순차 개발 |
| POP 연동 자동 발주 | 계획 단계 | POP 베타 이후 데이터 축적 필요 |
이 시스템을 구축할 수 있다고 판단하는 근거는 데이터다. 11년간의 거래 이력, 4,300+ 파트너 네트워크, 25,000+건의 실거래 기록. AI Agent가 "그럴듯한 견적"이 아니라 "실제 성사 가능한 견적"을 만들려면, 실제 거래 데이터에서 패턴을 학습해야 한다. 시장에서 B2B 견적 자동화를 시도하는 스타트업은 있지만, 이 규모의 실거래 데이터를 보유한 곳은 드물다.
기술 스택은 SSR 프론트엔드 프레임워크, 서버리스 런타임 기반 백엔드, 분산 SQL DB를 사용하고 있다. Agent 시스템은 이 인프라 위에 구축하며, 의미 검색을 위한 임베딩 파이프라인을 추가하는 방향으로 설계하고 있다.
견적 AI Agent는 REINDEERS가 단순한 거래 플랫폼을 넘어, 거래의 시작부터 완료까지를 AI Agent 팀이 실행하는 구조로 진화하기 위한 핵심 설계다. 견적 요청, 가격 산출, 물류 수배, 비교 분석 , 이 모든 업무가 조직도 안에 등록된 Buyer/Supplier/Forwarder Agent 사이의 메시지 교환으로 이루어진다. 사람의 역할은 "실행"에서 "결정과 방향"으로 옮겨간다. "올해는 중국 공급사 의존도를 낮춘다", "이번 분기는 납기 안정성을 가격보다 우선한다" 같은 방침을 사람이 내리면, Agent들이 그 방침을 실제 견적 교환에 구체화한다. 금액·신규 파트너·예외 조건처럼 사람이 반드시 확인해야 하는 지점만 에스컬레이션된다.
사람과 AI Agent의 역할 분담
"AI Agent가 견적을 처리한다"고 말하면 자주 받는 질문이 있다. "그럼 구매·영업 담당자는 사라지는가?" 우리가 설계한 답은 명확하다. 사라지지 않는다. 역할이 바뀐다.
| 업무 | 이전 (사람만) | 이후 (사람 + AI Agent) |
|---|---|---|
| 과거 거래 이력 확인 | ERP·엑셀 수동 조회 | Agent가 조회 후 요약 제공 |
| RFQ 작성/전송 | 이메일·메신저로 수작업 작성 | Buyer Agent가 초안 생성, 담당자 승인 후 전송 |
| 가격 산출 | 엑셀 + 경험으로 계산 | Supplier Agent가 거래 데이터 기반 단가 제안 |
| 물류비 수배 | 포워더에 전화·이메일 반복 | Forwarder Agent가 실시간 비딩, 결과 자동 집계 |
| 여러 견적 비교 | 엑셀 시트 만들어 수동 비교 | Agent가 총소유비용(TCO) 기준으로 정렬 |
| 방침·전략 수립 | 사람 담당 | 사람 담당 (변화 없음) |
| 예외·고액 승인 | 사람 담당 | 사람 담당 (변화 없음) |
이 분담의 핵심은 "반복적인 데이터 수집과 조합"을 Agent가 가져가고, "방침 결정"과 "예외 판단"을 사람이 유지한다는 점이다. 직원 10명이 견적 업무에만 매달리는 상황이 있다면, Agent 팀이 들어온 뒤에는 같은 직원 10명이 다수 법인·다수 시장의 구매 전략을 동시에 돌릴 수 있게 된다. 이것이 "AI Agent 법인 운영"이라는 이름의 실체다. 사람 수를 줄이는 게 목적이 아니라, 사람의 시간이 더 큰 결정에 쓰이게 만드는 것이 목적이다.
AI Agent 진화 4단계에서 견적 Agent의 위치
마지막으로 이 Agent 시스템이 더 큰 로드맵 어디에 해당하는지 정리한다. REINDEERS Works의 AI Agent 진화는 네 단계로 나뉜다.
| 단계 | 자동화 | 견적 Agent에서의 의미 |
|---|---|---|
| 1. Tool | ~20% | Agent가 견적 초안·요약을 만들고 사람이 매번 직접 클릭해서 보냄 |
| 2. Assistant | ~50% | Agent가 RFQ·견적·물류비를 자동 교환, 사람은 승인만 |
| 3. Agent Team | ~80% | Buyer·Supplier·Forwarder Agent 팀이 자율 협상, 사람은 예외만 |
| 4. Autonomous Operator | ~95% | 사람은 방침만 내리고 여러 법인의 전체 견적 흐름을 Agent가 운영 |
견적 Agent 시스템은 2026년 기준으로 1단계 Tool에서 2단계 Assistant로 넘어가는 구간에 있다. Phase 1에서 Agent가 제안만 하고, Phase 2부터 Write 행동을 사람이 승인한 뒤 자동 실행한다. Agent Team 단계로 가려면 두 가지가 필요하다. 첫째는 이 글에서 설명한 RAG 파이프라인의 성숙(답의 근거가 항상 실거래 데이터에 있도록). 둘째는 Event+State+Log 기반의 감사 추적(사람이 "왜 그 결정을 내렸는지" 언제든 역추적 가능하도록). 이 두 가지가 쌓여야만 사람이 안심하고 Agent에게 자율 실행을 맡길 수 있다. 견적은 돈이 직접 움직이는 영역이기 때문에 이 안전벨트가 특히 중요하다.
요약하면 이 시스템은 견적이라는 개별 기능의 자동화가 아니다. 조직도 안에 AI 직원을 등록하고, 그들이 서로 메시지를 주고받으며 거래를 진행하고, 사람은 방향과 예외만 보는 , 그런 운영 구조로의 전환이다. 견적은 그 전환의 첫 번째 도메인일 뿐이다. 다음은 구매 Agent, 통관 Agent, 재무 Agent로 확장된다. 그 과정의 매 단계마다, 사람의 역할은 점점 "전략"에 가까워지고, Agent의 역할은 점점 "실행"에 가까워진다.