본문으로 건너뛰기

환불 승인 에이전트 — 35분 walkthrough

가상의 전자제품 쇼핑몰 QuickReturn Electronics의 환불 처리를 D.Hub로 자동화하는 예제입니다. 주문·고객·환불 이력 CSV 3개를 올려 컬렉션 → 데이터셋 → 파이프라인(데이터 보강·리스크 스코어링) → 온톨로지 → 지식/RAG → AI 에이전트(Human-in-the-Loop) → 대시보드를 한 번에 거칩니다. covid19 예제가 "데이터 분석" 흐름이라면, 이 예제는 그 위에 AI 에이전트와 사람 검토(HITL) 레이어를 얹은 "운영 자동화" 흐름입니다.

사전 준비
  • D.Hub 계정 (관리자에게 발급받은 사용자명·비밀번호 또는 SSO)
  • 웹 브라우저(데스크톱 권장)
  • CSV 3개 + 정책 문서를 받아 압축 해제할 폴더 (다음 단계에서 다운로드)
  • Step 8 에이전트용 LLM 모델: 환불 승인 에이전트는 LLM(예: Claude Sonnet)을 사용합니다. 관리자가 등록한 LLM 모델이 있어야 하며, 없으면 에이전트 만들기 - 모델 선택을 참고해 먼저 등록하세요. Step 1~7은 LLM 없이도 진행할 수 있습니다.

시나리오와 데이터​

환불 요청이 들어오면 D.Hub가 주문·고객·과거 환불 이력을 통합해 리스크 점수를 계산하고, 환불 정책 문서를 RAG로 검색한 뒤, AI 에이전트가 승인안을 제안하고 담당자가 최종 승인/거절하는 흐름입니다. 원시 CSV는 3개이며, enriched_orders·risk_assessed_orders는 파이프라인이 만들어 냅니다.

분류파일행수역할
팩트raw_orders.csv12주문 (상품·금액·결제수단·상태)
마스터raw_customers.csv10고객 프로필 (등급 standard/silver/gold/platinum, 누적 주문·지출)
이력refund_history.csv10과거 환불 이력 (사유·상태·금액)
지식refund_policy_guide.md—환불 정책 문서 — Step 7 지식/RAG 검색 대상

데이터 다운로드​

받기크기비고
한 번에 받기 (refund-approval.zip)~3 KBStep 1에서 사용 (CSV 3 + 정책 md)
raw_orders.csv1.4 KB주문 12건
raw_customers.csv1.0 KB고객 10명 (tier 포함)
refund_history.csv1.1 KB과거 환불 10건
refund_policy_guide.md2.9 KB환불 정책 문서 (Step 7)

Step 1. 자산 받기 · D.Hub 로그인 (2분)​

로그인

  1. 위 표의 한 번에 받기 (refund-approval.zip) 링크를 클릭해 zip을 내려받습니다.
  2. zip을 임의의 폴더에 압축 해제합니다. CSV 3개와 refund_policy_guide.md가 평탄하게 풀려야 합니다.
  3. 브라우저에서 D.Hub 포털 URL에 접속합니다.
  4. 사용자명·비밀번호를 입력하고 로그인을 클릭합니다. SSO 환경이면 SSO 로그인 버튼으로 진행합니다.
여기까지 완료하면
  • 로컬 폴더에 raw_orders.csv, raw_customers.csv, refund_history.csv, refund_policy_guide.md 4개 파일이 풀려 있습니다.
  • 브라우저가 D.Hub 홈 화면(/home)에 도착해 있습니다.

Step 2. 컬렉션 환불 승인 운영 생성 (1분)​

  1. 좌측 사이드바에서 컬렉션으로 이동한 뒤 컬렉션 만들기를 클릭하면 생성 마법사가 열립니다.
  2. 기본 정보 단계에서 컬렉션 이름에 refund_ops를, 별칭으로 환불 승인 운영을 입력합니다.
  3. 설명 칸에 QuickReturn 주문·고객·환불 데이터 및 승인 에이전트를 입력합니다(선택).
  4. 다음으로 항목 선택·검토 단계를 지난 뒤 마지막 단계에서 컬렉션 만들기를 클릭합니다.
여기까지 완료하면
  • 좌측 사이드바 컬렉션 아래에 환불 승인 운영 컬렉션이 보입니다.
  • 페이지가 자동으로 컬렉션 상세로 이동했습니다 (URL에 컬렉션 ID 포함).

Step 3. 3개 CSV 빠른 추가 업로드 (3분)​

  1. 컬렉션 상세 페이지 헤더에서 항목 추가 → 빠른 추가… 메뉴를 선택합니다.
  2. 업로드 다이얼로그에 Step 1에서 압축 해제한 CSV 파일 3개(raw_orders.csv, raw_customers.csv, refund_history.csv)를 모두 드래그 앤 드롭 합니다. (refund_policy_guide.md는 데이터셋이 아니라 Step 7에서 지식으로 등록하므로 여기서는 올리지 않습니다.)
  3. 3개 항목이 모두 목록에 보이는지 확인한 뒤 업로드 버튼을 클릭합니다.
  4. 업로드가 끝나면 데이터셋 목록에 새 항목 3개가 자동 생성됩니다.
여기까지 완료하면
  • 컬렉션의 포함 항목 목록에 데이터셋 3개가 보입니다: raw_orders(12행), raw_customers(10행), refund_history(10행).
  • 행수가 맞지 않으면 CSV 인코딩(UTF-8)이나 헤더 라인을 다시 확인하세요.

Step 4. 주문 데이터 보강 파이프라인 (7분)​

raw_orders에 고객 등급(raw_customers)과 고객별 과거 환불 통계(refund_history)를 붙여 enriched_orders를 만듭니다. D.Hub 파이프라인에는 전용 조인 노드가 없어 조인·집계는 SQL 코드 노드 안에서 처리합니다. 구조는 소스 데이터셋 노드 → 코드 노드 → 출력 데이터셋 노드 순입니다.

  1. 컬렉션 상세에서 항목 추가 → 파이프라인을 선택하면 워크플로우 편집기가 열립니다.

  2. 좌측 컴포넌트 라이브러리의 컬렉션 섹션에서 raw_orders, raw_customers, refund_history 데이터셋을 캔버스로 각각 드래그합니다(소스 데이터셋 3개).

  3. 빠른 추가 → 코드에서 SQL 노드를 캔버스에 추가합니다.

  4. 세 데이터셋 노드의 출력 핸들을 SQL 코드 노드의 입력 핸들에 각각 연결합니다. 연결한 데이터셋은 코드 안에서 데이터셋 이름과 같은 테이블로 참조됩니다.

  5. SQL 코드 노드를 선택하고 코드 탭에 다음 쿼리를 작성합니다.

    SELECT
      o.order_id,
      o.order_date,
      o.customer_id,
      c.name        AS customer_name,
      c.tier        AS customer_tier,
      o.product_name,
      o.total_amount,
      o.status,
      COALESCE(r.past_refund_count, 0)   AS past_refund_count,
      COALESCE(r.past_refund_total, 0.0) AS past_refund_total
    FROM raw_orders AS o
    INNER JOIN raw_customers AS c
      ON o.customer_id = c.customer_id
    LEFT JOIN (
      SELECT customer_id,
             COUNT(*)           AS past_refund_count,
             SUM(refund_amount) AS past_refund_total
      FROM refund_history
      GROUP BY customer_id
    ) AS r
      ON o.customer_id = r.customer_id
    입력 테이블 이름

    연결한 입력 테이블 이름은 코드 노드의 옵션 탭에서 확인합니다(기본값은 데이터셋 이름). 쿼리의 FROM/JOIN 대상이 이 이름과 일치해야 합니다.

  6. SQL 코드 노드를 우클릭하고 결과 데이터셋 추가를 선택해 출력 데이터셋 노드를 만들고, 이름을 enriched_orders로 지정합니다.

  7. 우상단 저장을 클릭하고 파이프라인 이름에 주문 데이터 보강을 입력해 저장한 뒤, 지금 실행을 클릭합니다.

여기까지 완료하면
  • 캔버스에 노드 5개(데이터셋 3 + SQL 코드 + 출력 데이터셋)가 연결된 그래프가 보입니다.
  • 배치 상태가 성공(녹색)이 되면 enriched_orders 데이터셋이 생성됩니다. 행수는 12행(raw_orders와 동일)이며, customer_name·customer_tier·past_refund_count·past_refund_total 컬럼이 추가돼 있어야 합니다.
  • 예: ORD-2025-0001(CUS-001, Kim Minjun, gold)의 past_refund_count는 2, past_refund_total은 1549.98입니다.

Step 5. 리스크 스코어링 파이프라인 (6분)​

enriched_orders의 과거 환불 빈도·주문 금액·고객 등급을 가중 합산해 환불 리스크 점수(0~1) 와 등급(low/medium/high) 을 계산합니다. 이 점수는 Step 8 에이전트가 승인 여부를 판단할 때의 핵심 컨텍스트입니다.

  1. 항목 추가 → 파이프라인으로 새 워크플로우 편집기를 엽니다.

  2. 컬렉션 섹션에서 enriched_orders 데이터셋을 캔버스로 드래그합니다.

  3. 빠른 추가 → 코드 → SQL 노드를 추가하고, enriched_orders 출력 핸들을 SQL 노드 입력에 연결합니다.

  4. SQL 코드 노드 코드 탭에 다음 쿼리를 작성합니다. 가중치는 빈도 0.3 · 금액 0.3 · 등급 0.2 · 반복 0.2이며, 등급 페널티는 platinum 0.0 → standard 0.5 순입니다.

    SELECT
      order_id, order_date, customer_id, customer_name, customer_tier,
      product_name, total_amount, status, past_refund_count, past_refund_total,
      ROUND(risk_raw, 3) AS risk_score,
      CASE
        WHEN risk_raw > 0.6  THEN 'high'
        WHEN risk_raw >= 0.3 THEN 'medium'
        ELSE 'low'
      END AS risk_level
    FROM (
      SELECT
        e.*,
        0.3 * LEAST(e.past_refund_count / 5.0, 1.0)
        + 0.3 * LEAST(e.total_amount / 1000.0, 1.0)
        + 0.2 * CASE e.customer_tier
                  WHEN 'platinum' THEN 0.0
                  WHEN 'gold'     THEN 0.1
                  WHEN 'silver'   THEN 0.3
                  ELSE 0.5
                END
        + 0.2 * (1.0 - LEAST(e.past_refund_count, 1.0)) AS risk_raw
      FROM enriched_orders AS e
    ) AS scored

  5. SQL 노드 우클릭 → 결과 데이터셋 추가 → 이름을 risk_assessed_orders로 지정합니다.

  6. 저장(파이프라인 이름 환불 위험도 평가) → 지금 실행.

여기까지 완료하면
  • 배치가 성공이 되면 risk_assessed_orders 데이터셋(12행)에 risk_score·risk_level 컬럼이 추가됩니다.
  • risk_score는 모두 0.0~1.0 범위입니다. platinum 고객(CUS-003)의 주문은 등급 페널티가 0이라 상대적으로 낮은 점수가 나옵니다.
  • 등급 경계는 점수 > 0.6 → high, 0.3~0.6 → medium, < 0.3 → low 입니다.

Step 6. 온톨로지 엔티티 3개 + 관계 2개 (6분)​

표로 다루던 주문·고객·환불을 엔티티(Entity)와 관계(Relationship)로 모델링해 그래프로 봅니다. 좌측 사이드바 온톨로지 → 모델링에서 환불 승인 운영 컬렉션을 클릭해 빌더 캔버스를 엽니다.

좌측 패널 엔티티 뷰에서 엔티티 추가(+)로 엔티티 만들기 모달을 열어, 세부 정보 탭(이름·별칭)과 속성 탭(속성·타입 + 식별 키 + 표시 컬럼)을 채우고 저장합니다.

6-1. 엔티티 3개​

이름별칭식별 키표시 컬럼주요 속성
customerCustomercustomer_idnamecustomer_id, name, email, region, tier, lifetime_orders(Integer), lifetime_spend(Decimal)
sales_orderSales Orderorder_idproduct_nameorder_id, order_date(Date), customer_id, product_name, total_amount(Decimal), status, risk_score(Decimal), risk_level
refund_requestRefund Requestrefund_idreasonrefund_id, order_id, customer_id, refund_amount(Decimal), reason, status, requested_at(Date)
이름과 별칭

엔티티 이름은 소문자로 시작하고 소문자·숫자·밑줄만 씁니다. 화면에 보이는 대문자 표기는 별칭에 넣습니다.

6-2. 관계 2개​

그래프 뷰에서 엔티티의 연결 핸들을 다른 노드로 드래그하면 관계 만들기 모달이 열리고, 소스·대상은 드래그 방향대로 자동 지정됩니다.

  1. sales_order 핸들 → customer로 드래그 → 이름 placed_by (주문이 어느 고객에 의해 발생했는지)
  2. refund_request 핸들 → sales_order로 드래그 → 이름 requested_for (환불 요청이 어느 주문에 대한 것인지)
여기까지 완료하면
  • 캔버스에 Customer·Sales Order·Refund Request 세 엔티티 노드와 placed_by·requested_for 두 화살표가 보입니다.
  • 각 노드를 클릭하면 인스펙터에 속성·식별 키·표시 컬럼이 채워져 있습니다.
  • 엔티티에 실제 행을 적재하려면 데이터셋 → SQL 코드 노드 → 엔티티 노드 파이프라인을 만듭니다. 적재 방법은 covid19 온톨로지 예제의 Step 4가 같은 패턴을 단계별로 보여줍니다 — customer는 raw_customers, sales_order는 risk_assessed_orders, refund_request는 refund_history를 소스로 매핑하면 됩니다.

Step 7. 환불 정책 지식 등록 + RAG 검색 (4분)​

에이전트가 환불 사유에 맞는 정책 조항을 찾아 근거로 삼을 수 있도록, refund_policy_guide.md(반품 기한·자동 승인·에스컬레이션·거절·부분 환불·SLA)를 지식(Knowledge) 으로 등록하고 RAG 검색을 확인합니다.

  1. 좌측 사이드바 지식에서 지식 만들기로 새 지식을 만듭니다. 컬렉션은 환불 승인 운영을 선택합니다. (지식은 컬렉션 범위에 종속됩니다 — 지식 관리 참고.)
  2. 이름에 refund_policy, 별칭에 환불 정책을 입력합니다.
  3. 문서 탭에서 파일 업로드로 Step 1에서 받은 refund_policy_guide.md를 올립니다. 청크 크기·임베딩 모델은 기본값을 사용합니다 (청킹과 옵션 참고).
  4. 색인이 끝나면 검색 탭에서 결함 상품 환불 정책 또는 defective product return window로 검색해, 반품 기한·자동 승인 규칙 청크가 상위에 검색되는지 확인합니다 (검색 테스트 참고).
여기까지 완료하면
  • 지식 목록에 환불 정책(refund_policy)이 보이고, 문서 1건(refund_policy_guide.md)이 색인된 상태입니다.
  • 검색 탭에서 정책 관련 질의를 넣으면 관련 청크가 점수와 함께 반환됩니다. 결과가 비어 있으면 색인이 아직 진행 중일 수 있으니 잠시 후 다시 검색하세요.

Step 8. 환불 승인 AI 에이전트 + Human-in-the-Loop (6분)​

이제 앞에서 만든 데이터·지식을 묶어, 환불 요청을 분석하고 담당자 승인을 거쳐 처리하는 AI 에이전트를 구성합니다. 에이전트의 논리적 흐름은 다음과 같습니다.

사용자 입력(주문번호·사유·금액)
  → ① 주문/리스크 조회 (risk_assessed_orders)
  → ② 환불 정책 RAG 검색 (refund_policy 지식)
  → ③ AI 분석: 정책·리스크 근거로 승인안 제안
  → ④ 담당자 검토 (HITL 승인 카드) — 승인 / 부분환불 / 거절
  → ⑤ 분기: 승인·부분환불 → 환불 처리 / 거절 → 거절 안내

  1. 좌측 사이드바 에이전트에서 에이전트 만들기를 선택합니다. 생성 방식에서 AI 에이전트를 고릅니다 (에이전트 만들기 참고). 컬렉션은 환불 승인 운영.

  2. 이름 refund-approval, 별칭 환불 승인 에이전트를 입력하고, 모델은 사전 준비에서 확인한 LLM(예: Claude Sonnet)을 선택합니다.

  3. 지시문에 에이전트의 역할과 순서를 적습니다(요지).

    QuickReturn Electronics 환불 승인 어시스턴트입니다. 사용자가 주문번호·환불 사유·요청 금액을 제시하면 ① 주문/리스크를 조회하고 ② 환불 정책을 검색한 뒤 ③ 승인 여부·권장 금액을 분석하고 ④ 담당자 승인을 요청합니다. ⑤ 담당자가 승인/부분환불하면 환불을 처리하고, 거절하면 거절 안내를 보냅니다. 담당자 승인 전에는 환불/거절을 실행하지 않습니다. 모든 응답은 한국어로 작성합니다.

  4. 도구(Tools) 와 액터(Actors) 를 연결합니다. 이 예제 시나리오는 다음을 사용합니다 — 도구·액터 정의와 확인 정책은 도구와 액터에서 만드는 방법을 따릅니다.

    • 도구: 주문/리스크 조회(risk_assessed_orders 조회), 환불 정책 RAG 검색(refund_policy 지식 검색)
    • 액터: 담당자 검토(확인(confirm) 정책 — HITL 카드 노출), 환불 처리(자동(auto)), 거절 안내(자동(auto))
    Human-in-the-Loop의 핵심

    담당자 검토 액터의 확인 정책을 확인(confirm) 으로 두면, 에이전트가 그 단계에 도달했을 때 자동으로 진행하지 않고 승인 카드를 띄워 사람의 결정을 기다립니다. 환불 처리·거절 안내 액터는 자동(auto) 이라 담당자 결정 이후 곧바로 실행됩니다. 정책별 동작은 도구와 액터 - 확인 정책을 참고하세요.

  5. 에이전트를 배포합니다 (배포 참고). 배포 상태가 실행 중이 되면 채팅에서 테스트합니다.

  6. 채팅에 환불 요청을 입력합니다. 예:

    주문번호 ORD-2025-0001, 사유 defective, 금액 1299.99 환불 요청합니다.

    에이전트가 주문/리스크를 조회하고 정책을 검색한 뒤 승인안을 제안하면, 승인 카드가 나타납니다. 카드에서 승인 / 부분환불 / 거절 중 하나를 고르고 의견을 입력해 확정합니다.

여기까지 완료하면
  • 에이전트 채팅에서 환불 요청을 보내면, ① 주문·리스크 ② 정책 검색 ③ AI 분석 순으로 진행한 뒤 승인 카드(Human-in-the-Loop)가 표시됩니다.
  • 담당자가 카드에서 결정을 확정하기 전에는 환불/거절이 실행되지 않습니다.
  • 승인/부분환불을 선택하면 환불 처리 결과가, 거절을 선택하면 거절 안내 결과가 한국어로 요약됩니다.
  • 모델 호출이 실패하면 사전 준비의 LLM 모델 등록(특히 API 키)을 다시 확인하세요.

Step 9. 환불 운영 대시보드 · 마무리 (4분)​

마지막으로 환불 현황을 한눈에 보는 대시보드를 만듭니다. 위젯 데이터는 refund_history를 사용합니다.

  1. 좌측 사이드바 대시보드 → 대시보드 만들기로 편집 화면을 열고, 제목에 환불 운영 현황을 입력합니다.

  2. 위젯 라이브러리 열기에서 위젯을 추가하고, 각 위젯의 데이터 소스에서 컬렉션 환불 승인 운영 → 데이터셋 refund_history를 선택합니다. 집계는 데이터 모드의 SQL로 작성합니다 (데이터 설정 참고).

    • 통계(Statistic) — 총 환불 건수: SELECT COUNT(*) AS value FROM refund_history
    • 통계(Statistic) — 총 환불 금액: SELECT SUM(refund_amount) AS value FROM refund_history (접두사 $)
    • 파이 차트(도넛) — 상태 분포: SELECT status, COUNT(*) AS count FROM refund_history GROUP BY status (레이블 status, 값 count)
    • 막대 차트 — 사유별 건수: SELECT reason, COUNT(*) AS count FROM refund_history GROUP BY reason (레이블 reason, 값 count)

  3. 변경 적용 → 위젯이 렌더링되면 우상단 저장으로 대시보드를 저장합니다.

여기까지 완료하면
  • 대시보드에 통계 2개 + 도넛 + 막대 차트가 보입니다.
  • 총 환불 건수는 10, 상태 분포 도넛은 approved(다수)·partial·rejected·pending으로 나뉩니다.
  • 사유별 막대에서 defective가 가장 많게 나타납니다.

축하합니다 — D.Hub의 Collection → Dataset → Pipeline → Ontology → Knowledge/RAG → Agent(HITL) → Dashboard 흐름을 한 번에 거쳤습니다. 35분 동안 만든 결과를 정리하면 다음과 같습니다.

  • ✅ 컬렉션 1개 (환불 승인 운영)
  • ✅ 데이터셋 3개 (빠른 추가) + 2개 (파이프라인 산출물 enriched_orders·risk_assessed_orders)
  • ✅ 파이프라인 2개 (주문 데이터 보강·환불 위험도 평가)
  • ✅ 온톨로지 엔티티 3개 + 관계 2개
  • ✅ 지식 1개 (환불 정책) + RAG 검색
  • ✅ AI 에이전트 1개 (Human-in-the-Loop 승인)
  • ✅ 대시보드 1개 + 위젯 4개

다음 단계​

더 깊이 가려면가이드
엔티티에 실제 행을 적재해 그래프로 탐색covid19 온톨로지 튜토리얼
도구·액터를 직접 만들고 확인 정책 조정도구와 액터
지식 청킹·임베딩·검색 전략 튜닝청킹과 옵션 · AI 채팅
파이프라인을 매일 자동 실행하도록 스케줄스케줄링
컬렉션을 환불 담당자 그룹에 공유공유 및 권한

문제 해결​

증상점검
Step 4 조인 결과 행수가 12가 아님raw_orders·raw_customers의 customer_id가 일치하는지, INNER JOIN 대상이 맞는지 확인
Step 5 risk_level이 한 등급에 몰림경계값(0.3·0.6)과 등급 페널티 CASE의 customer_tier 문자열이 정확한지 확인
Step 7 검색 결과가 비어 있음색인이 진행 중일 수 있음 — 잠시 후 재검색. 컬렉션 범위가 환불 승인 운영인지 확인
Step 8 승인 카드가 안 뜸담당자 검토 액터의 확인 정책이 확인(confirm) 인지 확인 (도구와 액터)
Step 8 모델 호출 실패사전 준비의 LLM 모델 등록·API 키를 확인 (에이전트 만들기)
Step 9 위젯이 비어 있음SQL 모드에서 데이터셋 이름이 refund_history인지, 컬럼명이 정확한지 확인