영상 핵심 정리 (영상을 못 봤어도 따라잡을 수 있게)

이 영상은 "왜 단일 DB로는 제조 AI를 못 만드는가" 를 3가지 DB 비교로 풀어낸다.

---

1. 3종 DB가 푸는 문제는 서로 다르다

종류	대표 제품	잘 풀리는 질문	못 푸는 질문
벡터DB	Pinecone, Weaviate, Qdrant	"이 정비 보고서와 비슷한 과거 사례는?"	"이 고장의 원인 설비는?"
그래프DB	Neo4j, ArangoDB, TigerGraph	"CNC-001 고장이 어느 후공정까지 영향?"	"이 진동 패턴을 닮은 다른 라인은?"
시계열DB	InfluxDB, TimescaleDB	"지난 1시간 평균 진동 추이는?"	"이 부품과 연결된 설비는?"

각 DB는 저장 구조 자체가 질문 유형에 맞춰 설계돼 있다. 잘못 고르면 같은 질문에 100배 느려진다.

---

2. 제조 도메인에는 왜 그래프가 필수인가

제조 데이터의 본질은 관계망이다.

설비(CNC-001) ──사용──> 부품(스핀들) ──조립──> 공정(밀링) ──>...
   │                        │
   └─ 고장 이력 ──> 정비 작업 ──> 부품 교체

질문 예시:

• "스핀들 교체했을 때, 어느 라인의 어느 공정까지 영향받는가?" → 2-hop 이상의 관계 탐색
• "같은 고장 패턴이 재발한 설비 그룹은?" → 관계 + 패턴 매칭

→ 벡터DB / SQL은 이런 질문을 답하기 매우 어렵다.

---

3. 그렇다고 그래프DB만 쓰면?

실시간 센서 데이터(초당 수만 건)는 그래프DB에 넣으면 안 된다 — 노드/엣지가 폭증한다.

실무 패턴 (하이브리드 스토어)

           ┌─── Neo4j ─── 설비-부품-공정 정적 관계 (Knowledge Graph)
원천 데이터 ─┼─── TimescaleDB ─── 센서 시계열 (1초 ~ 1분 단위)
           └─── 벡터DB ─── 정비 보고서 / 매뉴얼 임베딩 (RAG)

질의 흐름:

1. "CNC-001 진동 이상의 원인 후보?" → 그래프에서 인접 부품/공정 추출
2. 시계열 DB에서 해당 부품의 최근 센서 추이 가져오기
3. 벡터DB에서 유사 과거 사례 검색
4. LLM이 3가지를 종합해 답변

→ 이것이 다음 Day부터 배우는 GraphRAG의 토대다.

---

4. 결정 가이드 (체크리스트)

• 질문의 핵심이 "관계/연결" 이다 → 그래프DB
• 질문의 핵심이 "닮음/유사도" 다 → 벡터DB
• 질문의 핵심이 "시간 추이/집계" 다 → 시계열DB
• 위 셋이 섞여 있다 → 하이브리드 (이번 주차 Day 3 GraphRAG)

---

다음 Task 와의 연결

다음 reading 에서는 "왜 제조 현장에 Knowledge Graph가 필요한가" 를 진짜 공장 사례로 들어간다. 이 영상에서 본 '그래프DB가 강한 이유' 가 현장 문제와 어떻게 연결되는지 확인하자.

스마트팩토리 지식 그래프 시스템을 설계할 때, 설비-부품-공정 정적 관계는 그래프DB(Neo4j), 실시간 센서는 시계열DB(InfluxDB), 매뉴얼·보고서 검색은 벡터DB(Qdrant)로 분리하는 이유를 설명해줘. 또한 RAG에 벡터DB만 쓸 때 '왜 그렇게 됐는지' 추론이 안 되는 한계와 GraphRAG가 이를 어떻게 해결하는지도 알려줘.