종합 과제 — 품질 사고 대응 앱 만들기

지금까지 배운 것을 모두 엮습니다. 품질 사고 하나를 받아, 원천을 잇고, 묻고, 구축하고, 조치하고, 그 흐름을 하나의 앱으로 만듭니다. 팀 프로젝트(2~3명)로 2~3시간 분량입니다.

상황#

월요일 아침, 도쿄의 고객 Tokyo Devices가 “PCB 납땜 불량” 클레임(T-3)을 냈습니다. 품질팀장이 묻습니다.

1. 이 불량 PCB는 어느 협력사에서 왔고, 그 협력사의 아직 들어오지 않은 물량은 얼마나 되나?
2. 같은 PCB를 쓰는 다른 고객의 미결 주문은?
3. 조사가 끝날 때까지 그 협력사의 미결 발주를 보류하고, 영향받는 고객에게 안내를 보내라.
4. 이 모든 것을 매일 보는 한 화면으로 만들어라.

과제#

1단계 — 데이터 잇기 (5~6장)#

• erp.po_line을 PoLine 가상 노드로 노출하고 IN_ORDER, OF_ITEM 관계를 만듭니다(6장에서 했다면 그대로 씁니다).
• 산출물: SHOW VIRTUAL RELATIONSHIPS 결과 캡처

2단계 — Cypher로 답하기 (7~9장)#

포털(그래프 sample)에서 질문 1과 2에 답하는 Cypher를 씁니다.

• 질문 1: 클레임 → 판매 주문 → 품목 ← 발주 품목 → 발주 → 협력사, 그리고 그 발주를 싣고 오는 선적 중 DELIVERED가 아닌 것.
• 질문 2: 같은 품목의 판매 주문 중 status = 'OPEN'인 것과 그 고객.
• EXPLAIN FABRIC으로 원천 몇 곳을 건드리는지 확인합니다.
• 산출물: Cypher 두 개, 결과 표, EXPLAIN FABRIC 결과

3단계 — 온톨로지 넓히기 (11~13장)#

예제 온톨로지에는 발주 품목이 없습니다. 「공급망 운영 (예제)」에 추가 인제스천으로 넓힙니다.

• 소스: 데이터소스 erp
• 골든 퀘스천 추가: “PCB 납땜 불량 클레임의 품목을 공급한 협력사와, 그 협력사의 미입고 물량은?”
• 구축 후 질의·액션 탭에서 이 질문을 던져 2단계의 Cypher와 같은 답이 나오는지 검산합니다.
• 산출물: 구축 보고서 캡처, 질의 답과 2단계 결과의 비교

4단계 — 조치하기 (14~16장)#

• 질의·액션 탭에서 “그 협력사의 미결 발주를 모두 보류해 줘 (사유: PCB 납땜 불량 조사)”와 “영향받는 고객에게 조치 안내를 보내 줘”를 지시합니다.
• 계획 카드의 허용·거부와 사유를 기록하고, 승인·실행 후 데이터소스 탭에서 erp.purchase_order, crm.notice가 바뀐 것을 확인합니다.
• 마지막에 모두 취소해 원상태로 돌리고, 보상 이력의 순서를 설명합니다.
• 산출물: 계획 카드, 실행 결과, 원천 확인, 보상 이력 캡처와 설명

5단계 — 앱 만들기 (17~20장)#

• 코드 앱 「품질 사고 대응」: 위에 클레임 요약, 가운데 영향 협력사와 미입고 물량, 아래에 영향 고객의 미결 주문.
• 말로 두 번 이상 고치고, app.js의 질의 하나를 2단계 Cypher와 비교합니다.
• (0.1.1부터) 협력사 행에 「발주 보류」, 고객 행에 「안내 보내기」 버튼.
• 산출물: 앱 화면, app.js에서 질의 부분 발췌

평가 기준 (예시)#

생각해 볼 거리#

• 2단계에서 직접 쓴 Cypher와, 3단계에서 에이전트가 쓴 답은 무엇이 같고 무엇이 달랐나요?
• 4단계의 “안내 보내기”를 정말 운영에 쓴다면, 정책에 어떤 조건을 더해야 할까요? (예: 같은 고객에게 하루 한 번만)
• 원천 DB를 복사하지 않는 방식(데이터 패브릭)의 장단점을, 2단계에서 본 EXPLAIN FABRIC 결과를 근거로 설명해 보세요.