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

그래프는 모든 에이전트 문제의 답이 아니다. 단순한 질의응답이나 짧은 워크플로는 리스트, 큐, 상태 머신만으로 충분하다. 그래프가 값을 만드는 순간은 관계 자체가 추론과 운영의 핵심 데이터가 될 때다.

그래프가 필요한 신호

다음 조건이 겹치면 그래프 모델링을 검토할 만하다.

• 개체 간 관계가 답의 품질을 좌우한다.
• 같은 정보가 여러 경로로 발견되고 충돌한다.
• 에이전트가 작업 중 만든 중간 산출물을 나중에 재사용해야 한다.
• “왜 이 결론이 나왔는가”를 출처 경로로 설명해야 한다.
• 단순 벡터 검색이 비슷한 문서는 찾지만 구조적 관계를 놓친다.

나래위키의 concepts, entities, summaries, sources 구조는 이 방향과 맞다. 원문만 쌓는 저장소가 아니라, 요약과 개념, 엔티티를 별도 층으로 컴파일하기 때문이다.

그래프가 과한 경우

반대로 다음 상황에서는 그래프가 오버엔지니어링이다.

• 문서 수가 적고 관계가 자주 바뀌지 않는다.
• 검색 결과를 사람이 직접 읽고 판단한다.
• 관계 설명보다 빠른 키워드 검색이 중요하다.
• 운영팀이 그래프 스키마를 계속 유지할 여력이 없다.

그래프는 “멋진 인프라”가 아니라 운영 비용이 있는 데이터 모델이다. 블로그 자동 운영에서는 글 주제 선정, 내부 링크 추천, 출처 관계 설명처럼 직접 이득이 나는 곳부터 적용해야 한다.

블로그에서의 현실적 적용

초기 구현은 단순해야 한다.

1. 글마다 위키 페이지 경로를 sources frontmatter에 남긴다.
2. 태그는 concepts와 맞춘다.
3. 관련 글 추천은 같은 태그와 source prefix로 시작한다.
4. 나중에 충분한 글이 쌓이면 개념 그래프 기반 추천을 붙인다.

이 순서가 안전하다. 그래프 저장소부터 도입하면 콘텐츠 품질보다 인프라 유지가 먼저 문제가 된다.