환불 승인 — 데이터 결합부터 리스크 스코어링, HITL 에이전트까지

워크숍 목표

다 끝내고 나면 D.Hub 안에서 다음 흐름을 한 사이클 손으로 통과한 셈이 됩니다.

• 시나리오 1개를 포털로 적재해 raw_data 와 refund_ops 두 sub-collection, 데이터셋 5종, 코드 노드 3종, 파이프라인 3종, 온톨로지 3엔티티/2관계, 대시보드, 지식 1종, 에이전트 1종을 한꺼번에 등록합니다.
• ERP 의 raw_orders, CRM 의 raw_customers, 재무 DB 의 refund_history 세 원천을 복합 조인 한 enriched_orders 를 만듭니다.
• risk_assessment 파이프라인으로 0–100 의 risk_score 와 LOW / MEDIUM / HIGH 3 라벨의 risk_level 을 부여합니다.
• refund_policy 지식을 RAG 로 검색하는 refund-approval 에이전트를 호출해 환불 1건의 AI 분석 → 인간 검토 → 자동 실행 사이클을 통과합니다.
• 고객-주문-환불 그래프를 펼쳐 한 고객의 환불 이력 클러스터 를 시각화합니다.

분석가 코스의 데이터 결합·시각화 와 엔지니어 코스의 파이프라인·에이전트 두 갈래가 한 시나리오로 합쳐지는 통합 실습입니다. HITL(Human-in-the-Loop) 워크플로가 핵심입니다. 권장 소요 시간은 90분.

사전 준비

• D.Hub 포털 접근 가능한 분석가 또는 엔지니어 계정 (Editor 권한 이상)
• 약 55KB 의 zip 한 개를 받을 다운로드 여유

터미널·Python·dhub2-examples 클론은 필요 없습니다. 입문 튜토리얼인 시나리오 zip 으로 한 번에 가져오기 를 먼저 끝내 두면 1단계가 매끄럽게 풀립니다.

1. 시나리오 적재 (10분)

포털 좌측 사이드바의 컬렉션 → Explorer 상단 헤더의 더보기(⋯) 메뉴 → 가져오기 로 받은 zip 을 올립니다. 컬렉션 두 개가 자동으로 만들어집니다.

manifest.json 순서대로 다음 자산이 올라갑니다.

1. 컬렉션 2종 — raw_data (alias: 환불 원시 데이터), refund_ops (alias: 환불 운영)
2. 데이터셋 5종 — raw_orders (raw), raw_customers (raw), refund_history (raw), enriched_orders (ops), risk_assessed_orders (ops)
3. 코드 3종 (Python) — join_order_customer, risk_scorer, build_refund_ontology
4. 파이프라인 3종 — order_enrichment, risk_assessment, ontology_materialization
5. 온톨로지 — 엔티티 3종(customer, sales_order, refund_request), 관계 2종(placed_by, requested_for)
6. 지식 1종 — refund_policy (환불 정책 가이드)
7. 대시보드 — refund_operations
8. 에이전트 — refund-approval (HITL 워크플로)

적재 완료 후 좌측 트리에 raw_data 와 refund_ops 두 컬렉션이 보이면 1단계 끝.

2. 원시 데이터 둘러보기 (15분)

이 시나리오의 핵심은 세 원천의 결합 입니다. raw_data 컬렉션에서 세 데이터셋을 차례로 봅니다.

raw_orders (12 행) — 주문 트랜잭션. 컬럼: order_id, customer_id, product_category (phones / laptops / headphones / tablets), order_date, total_amount, payment_method.

raw_customers (10 행) — 고객 프로필. 컬럼: customer_id, name, email, signup_date, tier (standard / silver / gold / platinum), lifetime_value.

refund_history (10 행) — 과거 환불 기록. 컬럼: refund_id, customer_id, order_id, refund_date, refund_amount, reason (defective / wrong_item / not_as_described / change_of_mind), status (approved / rejected / pending).

세 데이터셋의 스키마 탭 에서 customer_id 와 order_id 가 양쪽에서 같은 타입(string) 인지 확인합니다. §3 의 enrichment 가 두 키로 3-way join 을 하기 때문입니다.

3. 데이터 enrichment 파이프라인 (15분)

refund_ops 컬렉션의 파이프라인 섹션에서 order_enrichment 를 엽니다. 노드 하나, join_order_customer 스크립트가 세 원천을 묶어 enriched_orders 를 만듭니다.

스크립트 본문의 핵심 — raw_orders 와 raw_customers 를 customer_id 로 left join, 그 결과에 refund_history 를 customer_id 로 다시 left join 해 고객의 과거 환불 이력 카운트 를 함께 가져옵니다. 결과 컬럼은 원본 주문 + tier, lifetime_value, past_refund_count, past_approval_rate.

Run 을 눌러 실행합니다. 끝나면 enriched_orders 의 미리 보기 탭 에서 한 행이 세 원천을 다 합친 모양인지 확인합니다. past_refund_count 가 0~3 사이로 잡혀 있을 겁니다.

4. 리스크 스코어링 (15분)

refund_ops 의 risk_assessment 파이프라인을 엽니다. 노드 하나, risk_scorer 스크립트가 enriched_orders 를 읽어 risk_assessed_orders 를 만듭니다. 추가되는 컬럼은 risk_score (0–100) 와 risk_level (LOW / MEDIUM / HIGH).

risk_scorer 스크립트의 가중 점수 공식은 한 줄로 정리됩니다.

risk_score = clip(
    past_refund_count × 12
  + (1 − past_approval_rate) × 30
  + (lifetime_value < 1000 ? 20 : 0)
  + (order_amount > 1500 ? 15 : 0),
  0, 100
)

• 과거 환불 1건당 +12 점 (3건이면 36)
• 과거 거부 비율이 100% 면 +30 점
• LTV 가 1000 미만이면 +20 점
• 주문 금액이 1500 초과면 +15 점 (고가품)

라벨 컷오프: ≤30 = LOW, 31~60 = MEDIUM, ≥61 = HIGH.

Run 을 눌러 실행합니다. 끝나면 risk_assessed_orders 미리 보기에서 12 건의 risk_level 분포를 봅니다. 시드 데이터 기준 LOW : MEDIUM : HIGH ≈ 5 : 4 : 3 비율이 잡힙니다.

5. 온톨로지 + 그래프 탐색 (10분)

ontology_materialization 을 한 번 돌립니다. build_refund_ontology 스크립트가 세 raw + 두 enrichment 데이터셋을 batch 모드로 읽어 다음 5개 산출물을 upsert 모드로 적재합니다.

그래프 탐색기 에서 platinum 고객 한 명을 시작점으로 다음 Cypher 한 줄을 돌립니다.

MATCH (c:customer {tier: 'platinum'})<-[:placed_by]-(o:sales_order)<-[:requested_for]-(r:refund_request)
RETURN c, o, r
LIMIT 25

한 platinum 고객의 주문 ↔ 환불 클러스터 가 한 그래프에 펼쳐집니다. platinum 인데 환불 많은 고객 패턴이 시각적으로 잡힙니다.

6. HITL 에이전트 — 환불 1건 처리 (20분)

refund_ops 의 에이전트 영역에서 refund-approval 카드를 열고 새 세션을 시작합니다. 이번 단계가 워크숍의 결말입니다.

에이전트 워크플로는 다섯 단계로 구성됩니다.

1. get_enriched_order 도구 호출 — 사용자가 환불 검토할 주문 ID 입력 → enriched_orders 에서 한 행 fetch.
2. search_refund_policy 도구 호출 (RAG) — refund_policy 지식을 임베딩 검색해 이 환불 사유에 적용되는 정책 단락을 가져옵니다.
3. LLM 분석 — 주문 컨텍스트 + 정책 단락 + risk_level 을 합쳐 권고 (APPROVE / PARTIAL / REJECT) 와 근거 3줄 을 생성.
4. 인간 검토 (capture_review_decision 액터) — 검토자가 권고를 그대로 받거나 덮어쓰기. 본 단계가 HITL 의 H. UI 의 Approve / Partial / Reject 버튼 하나를 누르면 다음 액터로 흐릅니다.
5. 자동 실행 — 결정이 APPROVE 면 issue_refund 액터 (백엔드 환불 API 호출), REJECT 면 send_rejection_email 액터.

세션 시작 후 검토할 주문 ID 로 order_id = ORD-007 (시드 기준 HIGH 리스크 주문 중 하나) 을 입력하고, 에이전트가 권고를 띄울 때까지 기다립니다. 권고 본문에 risk_level: HIGH 와 환불 정책 §3.2 인용 이 함께 보이면 RAG 가 제대로 grounding 한 신호입니다.

Reject 를 눌러 한 사이클을 마무리합니다. 이메일 발송 액터 로그가 떨어지고 세션이 종료됩니다.

7. 대시보드 + 다음 단계 (5분)

refund_operations (alias: 환불 운영 대시보드) 를 한 번 둘러봅니다. 위젯 6종이 모두 refund_history 한 데이터셋만 봅니다.

• Total Refund Requests (statistic) — COUNT(*)
• Total Refund Amount (statistic) — SUM(refund_amount)
• Decision Distribution (도넛) — status 별 건수 (approved / rejected / pending)
• Refund by Reason (막대) — reason 별 건수 (defective / wrong_item / not_as_described / change_of_mind)
• Refund Amount by Customer (막대, Top 10) — customer_id 별 SUM(refund_amount) 내림차순
• Recent Refund Requests (데이터 테이블) — requested_at 내림차순 최근 100건

본 대시보드는 과거 환불 데이터 의 운영 시점 요약입니다. AI 권고 vs 사람 결정의 일치율 같은 메타 지표는 시드 데이터에 빌트인 되어 있지 않습니다 — §6 의 HITL 에이전트가 운영에 안착하고 권고/결정 페어가 쌓이기 시작하면 이를 표 형태로 추가하는 게 자연스러운 다음 라운드 의제입니다.

끌리는 방향으로 한 발 더:

• 에이전트 코스 (Phase 2) 에서 RAG + HITL 패턴을 더 깊이 다룹니다.
• 엔지니어 코스 의 파이프라인 스케줄링 으로 가서, risk_assessment 를 15분 주기 CDC 로 등록합니다.
• 자기 도메인 의 권고 + 결정 흐름 (대출 심사·계약 갱신·티켓 분류) 으로 본 형판을 옮겨 씁니다.

검증 체크리스트

• 컬렉션 트리에 raw_data 와 refund_ops 두 컬렉션, 데이터셋 5종이 다 올라가 있는지
• order_enrichment 실행 뒤 enriched_orders 의 past_refund_count 컬럼이 채워졌는지
• risk_assessment 실행 뒤 risk_assessed_orders 의 risk_level 이 LOW / MEDIUM / HIGH 세 라벨로 분포돼 있는지
• 그래프 탐색기에서 platinum 고객 한 명의 주문 ↔ 환불 클러스터 를 한 화면에 펼칠 수 있는지
• 에이전트 세션 1회에서 RAG 가 정책 단락을 인용한 권고를 생성하고, 검토자가 Reject 버튼을 누르면 이메일 액터 로그가 떨어지는지