Graph Engineering은 언제 Knowledge Graph 값을 만들까

그래프는 모든 에이전트 문제의 답이 아니다. 단순 질의응답, 짧은 승인 플로우, 고정된 배치 작업은 리스트, 큐, 상태 머신만으로도 충분하다. Knowledge Graph가 값을 만드는 순간은 “데이터가 많다”가 아니라 관계 자체가 답의 품질과 책임 추적을 좌우할 때다.

도입 신호: 질문이 관계를 타고 이동할 때

그래프가 필요한 질문은 보통 한 문서 안에서 끝나지 않는다. 예를 들어 고객지원 에이전트가 “이 장애가 어떤 고객 계약, 권한, 최근 배포, 과거 보상 이력과 연결되는가?”를 답해야 한다면 단순 검색만으로는 부족하다. 고객, 계약, 장애, 배포, 조치 이력이 서로 다른 시스템에 있고, 답은 그 사이를 두세 단계 이상 건너가야 나오기 때문이다.

다음 신호가 두 개 이상 겹치면 그래프 파일럿을 검토할 만하다.

• 같은 엔터티가 여러 이름으로 등장하고 병합 여부가 중요하다.
• 관계의 시간성이 중요하다. 지금 유효한 계약과 지난달 유효했던 계약이 다르다.
• 답변에 “어떤 근거에서 이 관계를 믿는가”가 함께 필요하다.
• 여러 에이전트나 팀이 같은 세계 상태를 공유해야 한다.
• 한 번 확인한 관계를 다음 작업에서도 재사용해야 한다.

핵심은 그래프 데이터베이스를 쓰는지가 아니다. 보존해야 할 관계, 변경 이력, 책임 소재가 반복 업무의 중심인가가 기준이다.

그래프가 아닌 것으로 시작해야 할 때

반대로 다음 경우라면 그래프는 과한 선택이다.

• 답이 대부분 한 문서 안에 있다.
• 독자가 검색 결과를 직접 읽고 판단한다.
• 데이터가 표 형식이고 조인 조건이 안정적이다.
• 처리 순서가 고정되어 있어 상태 머신으로 테스트하는 편이 쉽다.
• 관계를 최신 상태로 유지할 담당자와 평가 기준이 없다.

이때는 Vector RAG, SQL, 상태 머신이 더 싸고 검증하기 쉽다. 오래된 그래프는 틀린 답을 그럴듯한 구조로 포장한다. 그래프의 실패는 검색 실패보다 위험하다. 사용자는 “관계가 있으니 맞겠지”라고 믿기 때문이다.

파일럿은 작고 검증 가능해야 한다

그래프를 도입한다면 범용 지식 저장소부터 만들지 않는다. 먼저 반복해서 물어보는 고비용 질문 하나를 고른다.

flowchart TD
  question[대표 질문 선정] --> schema[최소 그래프 모델링]
  schema --> baseline[기준선 측정]
  baseline --> pilot[파일럿 구축]
  pilot --> compare[효과와 유지비 비교]
  compare --> keep{계속 운영할 가치가 있는가?}
  keep -->|예| operate[품질 루프 운영]
  keep -->|아니오| stop[검색·데이터 정리로 회귀]

좋은 첫 범위는 “20~40개의 대표 질문을 더 빠르고 정확하게 답할 수 있는가” 정도다. 엣지마다 원천, 추출 시점, 검토 상태, 유효 기간을 남길 수 없다면 그래프를 작게 유지하거나 시작하지 않는 편이 낫다.

실무 판단 기준

도입 여부는 다음 질문으로 결정한다.

1. 관계를 두 단계 이상 탐색해야 하는 질문이 반복되는가?
2. 관계의 변경 이력과 유효 시점이 답에 영향을 주는가?
3. 잘못된 병합이나 누락된 관계가 실제 비용을 만드는가?
4. 기존 검색이나 SQL 기준선보다 정확도나 검토 시간이 개선되는가?
5. 스키마와 엔터티 해소를 계속 관리할 사람이 있는가?

셋 이상이 “아니오”라면 지금은 그래프가 아니라 검색 품질, 데이터 정리, 평가 세트를 먼저 개선해야 한다. 그래프는 멋진 인프라가 아니라 유지비가 있는 데이터 제품이다.