고급 Cypher: "이 설비가 멈추면 무슨 일이 벌어지나?"

1. 가변 길이 경로 탐색

---

2. 영향도 분석: "이 설비가 멈추면?"

---

3. 집계와 통계

---

4. 실전 분석 쿼리 모음

---

4. 자주 빠뜨리는 핵심 4가지 (실무 직결)

4-1. WITH 절 — 쿼리 체이닝의 핵심

WITH 가 없으면 복잡한 쿼리는 사실상 불가능하다. 중간 결과를 다음 절에 전달하는 "파이프" 역할.

함정: WHERE partCount >= 5 를 WITH 없이 쓰면 에러. count() 같은 집계 후 필터는 항상 WITH 가 필요하다.

4-2. MERGE ON CREATE / ON MATCH — 업서트 분기

MERGE 단독은 "있으면 매칭, 없으면 생성". 두 경우에 다른 동작이 필요할 때:

함정: MERGE (e:Equipment {serial: "...", status: "운전중"}) 처럼 속성을 여러 개 묶으면 그 조합 모두 일치할 때만 매칭. status 가 다르면 새 노드를 만든다 — 의도와 어긋나는 가장 흔한 실수.

4-3. 인덱스 + UNIQUE 제약 — 성능과 무결성 동시에

100만 노드부터는 인덱스 없으면 단순 lookup 도 초 단위가 든다.

운영 룰: KG 적재 전에 인덱스/제약을 먼저 만든다. 적재 후 인덱스 생성은 비싸다. MERGE 가 빠르려면 매칭 속성에 반드시 인덱스 또는 UNIQUE 가 있어야 한다.

4-4. APOC — Neo4j 표준 확장 라이브러리

실무 운영의 절반은 APOC 로 해결된다. Neo4j 설치 시 같이 깔거나 apoc.conf 로 활성.

추천 출발점 3개: apoc.periodic.iterate (대용량 처리), apoc.export.json.all (백업), apoc.load.json (외부 JSON 로드). 이 셋만 알아도 운영 부담이 절반으로 준다.

---

다음 task 와의 연결

다음 reading "그래프 데이터 모델링 패턴: 좋은 KG vs 나쁜 KG" 에서 위 4가지가 "좋은 KG" 의 필수 조건으로 다시 등장한다. 특히 인덱스 누락과 MERGE 오용은 "나쁜 KG" 의 가장 흔한 패턴이다.