5가지 그래프는 하나의 DB에 다 담을 수 없다: 실무 레이어 설계

제1부·제2부에서 역할을 나눈 뒤, 현장에서 자주 나오는 질문은 "전부 Neo4j에 넣으면 충분할까"입니다. 관계를 추적하는 질문에는 적합하지만, 유사 장애 탐색이나 건수 집계는 다른 스토어(Store)가 더 적합한 경우가 많습니다.

본 기사에서는 가상의 장애 INC-001(제품 Acme Search, 고객 Globex Corp)을 소재로, 동일한 데이터에 질문을 차례로 던졌을 때 Markdown 파편과 그래프(필요 시 계층 분리)를 통해 무엇이 반환되는지 살펴봅니다. 데모가 보여주는 것은 에이전트에게 정확한 정보를 어떻게 전달할 것인가까지입니다. 티켓 업데이트나 승인 등 세상을 바꾸는 조작은 다루지 않습니다.

로컬에서의 재현 절차는 experiment README에 있습니다. 본 기사에서는 질문별 출력 결과와 그로부터 알 수 있는 점만을 추적합니다.

데이터 환경

사용하는 메모 파편은 다음과 같습니다. 소스마다 입도(Granularity)가 다르며, 관계의 타입은 없습니다.

[jira] INC-001: Acme Search의 검색 레이턴시(Latency) 악화. 고객은 Globex Corp.
[slack] globex-support: 검색이 느림. 별도 티켓 INC-099도 같은 증상?
[email] From: ops@globex.example — 장애 보고. 제품 Acme Search.
...

동일한 세계를 다음 계층(Layer)에도 싣고 있습니다.

계층	보유 항목
Neo4j	티켓→제품→고객, 동일성(Identity), 권한, 의존성, 이벤트 체인
...

이후의 출력은 ./run_demo.sh compare 결과입니다.

(AI 없이) 얻은 결과입니다. 각 질문에서 "파일"은 위의 메모만을 의미하며, "그래프"는 계층을 나누어 추출한 사실입니다. 유사 장애와 건수 집계에서는 전부를 Neo4j에서 가져왔을 경우도 병기합니다.

Q1. 이 티켓의 고객은?

질문: INC-001의 고객은 누구인가.

전달 방식	결과
파일	jira는 Globex, slack은 고객명 없음, email은 제품만 있음 → 추측
그래프	INC-001 → Acme Search → Globex Corp → 확정

파일 ▲ 추측 파편마다 입도가 다름
→ jira: Globex Corp / slack: 고객명 없음 / email: 제품만 있음
그래프 ◎ 확정 Neo4j KG
...

메모만으로는 파편마다 표현이 다릅니다. 제품과 고객의 관계를 추적할 수 있으면 고객명을 확정할 수 있습니다.

Q2. Slack과 이메일은 동일 고객인가?

질문: 채널 globex-support와 ops@globex.example은 같은 고객인가.

전달 방식	결과
파일	문자열이 나열될 뿐 → 다른 고객으로 오인하기 쉬움
그래프	둘 다 Globex Corp에 SAME_AS → 동일함으로 확정

파일 ▲ 추측 SAME_AS가 없음
→ slack: globex-support / email: ops@globex.example
그래프 ◎ 확정 Neo4j SAME_AS
...

겉보기에 유사한 문자열만으로는 부족합니다. 동일성 관계가 있으면 근거를 가지고 답할 수 있습니다.

Q3. 이 에이전트는 봐도 되는가?

질문: agent_guest는 INC-001을 열람해도 되는가.

전달 방식	결과
파일	"기밀을 답하지 마라"라고 적을 수밖에 없음 → 섞이면 유출됨
그래프	CAN_READ가 없음 → False (본문을 전달하지 않음)

파일 ✗ 불가 CAN_READ 타입이 없음
그래프 ◎ 확정 Neo4j CAN_READ → False

권한은 프롬프트의 주의 사항이 아니라, 취득 전에 평가할 수 있는 관계로 보유하면 차단할 수 있습니다.

Q4. 로그 기반의 영향 범위는?

질문: 로그 기반이 다운되었을 때, 무엇이 중단되는가.

전달 방식	결과
파일	runbook의 서술은 있으나, 기계는 추적할 수 없음
그래프	BLOCKS로 Search API를 반환

파일 △ 일부 가능 서술만 존재
그래프 ◎ 확정 Neo4j BLOCKS → ['Search API']

절차서의 문장보다 의존 관계를 추적하는 편이 영향 범위를 기계적으로 파악할 수 있습니다.

Q5. 유사한 과거 장애는?

질문: 현재 장애와 의미적으로 유사한 과거 티켓은 무엇인가.

여기서부터는 「전부를 관계형 DB (Relational DB)에 넣었을 경우」도 나열합니다.

전달 방식	결과
파일	키워드 일치하는 단편뿐
...

파일 ▲ 추측 키워드 일치만
Neo4j 단독 ▲ 추측 벡터층(Vector Layer) 없음 → ['INC-001']
층 분리 ◎ 확정 Qdrant → ['INC-00042', 'INC-00017']

관계를 추적하는 Graph DB만으로는 의미적 유사성 검색이 약해집니다. 임베딩 (Embedding) 층이 필요합니다.

Q6. 최근 30일간의 P0 Top 제품은?

질문: 최근 30일간의 P0 승격 건수 기준으로, 제품의 순위는 무엇인가.

전달 방식	결과
파일	"많은 것 같다" 뿐 → 집계 불가
...

파일 ✗ 불가 GROUP BY 불가
Neo4j 단독 ▲ 추측 Issue.severity 만 → Acme Search: 1
층 분리 ◎ 확정 SQLite → Acme Search: 2, Platform Logging: 1

건수 집계를 Cypher에 밀어 넣으면 감사 로그 (Audit Log)와 어긋납니다. SQL 층이 적합합니다.

Q7. P0 승격 30분 전에는?

질문: P0로 승격되기 30분 전에 무엇이 일어나고 있었는가.

전달 방식	결과
파일	시계열 관계가 없음 → 불가
그래프	릴리스(Release) → 레이턴시(Latency) 악화 → 승격, 순으로 추적 가능

파일 ✗ 불가 시계열 Edge 없음
그래프 ◎ 확정 Neo4j Event + BEFORE
→ Release v2.3.1 deployed (14:00)
...

이 질문은 Neo4j의 이벤트 체인 (Event Chain)만으로 충분합니다. 유사성이나 집계처럼 층을 추가할 필요는 없습니다. 나누어야 할 질문과, 나누지 않아도 되는 질문이 있습니다.

Q8. 에이전트에게 보여줘도 되는 엔티티(Entity)는?

질문: 이 장애 대응에서 에이전트에게 보여줘도 되는 엔티티는 무엇인가.

Q1~Q7은 장애 그 자체에 대한 질문입니다. 여기만은 답을 내기 전에 "어디까지 보여줄 것인가"를 결정하는 질문입니다. 메모 전문을 전달하면 매번 어떤 단편이 포함될지 흔들립니다. 스코프 (Scope)를 미리 정해두면 보여줄 대상이 고정됩니다.

전달 방식	결과
파일	jira / slack / email … 단편 이름만 나열되어 범위가 흔들리기 쉬움
그래프	엔지니어용 스코프에 INC-001, Acme Search, Globex만 포함됨

파일 ▲ 추측 단편 세트가 흔들림
그래프 ◎ 확정 ['INC-001', 'acme-search', 'globex']

보여주는 범위를 고정하면 에이전트에게 전달할 재료가 안정됩니다.

요약

동일한 장애 데이터라도 질문이 바뀌면 필요한 관계와 위치가 바뀝니다.

고객·동일성·권한·의존성은 메모보다 타입이 지정된(Typed) 관계가 필요함
유사성은 벡터, 건수는 SQL이 적합하며, 전부를 Graph DB에 밀어 넣으면 약해짐
시간축처럼 Neo4j만으로 충분한 질문도 있음
보여줄 엔티티의 범위를 고정하면 에이전트에게 전달할 재료가 안정됨

제1부의 지도 → 제2부의 특수화 → 본 기사의 배치 순으로 설계가 일련의 흐름으로 연결됩니다. 로컬 환경에서는 ./run_demo.sh setup 실행 후 compare (정확도 표)와 agent (동일한 질문을 LLM에 전달)를 통해 재현할 수 있습니다. 절차는 experiment README를 참조하십시오.

테마	기사
본 시리즈 제1부	지식 그래프(Knowledge Graph)뿐만이 아니다. AI 에이전트가 사용하는 5가지 종류의 그래프
...

업데이트 이력

2026-07-16: 초판 공개

피드백 접수

내용에 오류가 있거나 추가 정보가 있다면 Zenn의 댓글로 알려주세요.

Insights

5가지 그래프는 하나의 DB에 다 담을 수 없다: 실무 레이어 설계

요약

핵심 포인트