허브 노드 질문에서 하이퍼 엣지 설계까지

자정이 막 지난 에이전트코리아에 그래프 검색 질문이 올라왔다. 한 참가자가 그래프 로직을 구축할 때 허브 스포크 구조로 링크를 잇는다고 소개하며, 공 노드 하나를 농구·축구·야구 세 계열에 모두 연결하면 정확도가 오르겠느냐고 물은 것이다. 이 화제는 364건으로 이날 가장 길게 이어졌다.

키워드가 쏟아진 새벽

첫 답은 슈퍼노드라는 키워드였다. 허브(중심) 노드를 가리키는 이름이라는 취지의 답이었다. 이어 그래프 쿼리 엔진을 쓰는 것이 아니라면 노드 타입을 정해 주지 않으면 쿼리가 잘 틀린다는 지적이 나왔다. 질문한 참가자는 neo4j가 무거워 데몬 없이 qrlite와 LLM 위키만으로 그래프 DB를 구축하는 중이라고 밝혔다.

방향을 두고는 처방이 갈렸다. 한 참가자는 그래프 RAG라면 무조건 단방향이라고 했고, 다른 참가자는 1홉까지만 양방향으로 두라고 했다.

2홉이상부터 양방향하면 oom남

여기서 oom은 메모리가 모자라 멈추는 상태를 가리킨다.

또 다른 참가자는 역방향이 필요한 분야도 있다고 덧붙였고, 대화는 결국 설계하기 나름이라는 정리로 모였다. 하이퍼 엣지(여러 노드를 한꺼번에 묶는 연결)는 홉(노드 사이 연결 한 단계)이 길어질수록 불필요한 과부하가 걸리고 정확도가 떨어질 수 있다는 이유로 권해졌다. 같은 계층의 노드를 묶어 엣지로 만든다는 설명이었다.

허브 구조에 대한 반론

공을 매개로 세 종목을 잇는 방식에는 반대 의견이 있었다.

공을 통해 농구 야구 축구 연결하는건 노이즈가 많이 낄거같아요

축구를 물었는데 야구와 농구 정보까지 딸려 올 것 같다는 우려였고, 이 참가자는 사실을 농구·사용도구·농구공처럼 원자 사실 단위로 묶자고 제안했다. 또 다른 참가자는 범주를 L# 계층으로 두고 상위에서 하위로 내려가듯 설계하라고 권했다.

한쪽에서는 그래프를 쓰기로 했다면 규약과 레이어를 먼저 잡고 들어가야 한다는 말도 나왔다.

그래프를 쓸거다 → 무조건 규약 다 잡고 레이어 잡고 들어가야하고

낮에 이어진 하이브리드 검색

오전 10시 23분 질문한 참가자가 돌아와 키워드 덕분에 설계가 바뀌었다고 알렸다. 다른 참가자가 이를 두고 한 말이 눈에 띈다.

키워드만 던져주셔도 설계가 바뀌는 매직

한편 다른 참가자들은 그 조언이 질문자의 상황에 꼭 맞는지 기술 검토는 어렵다고 털어놓았다. 11시 15분 질문자는 검색 로직을 싹 다 갈아엎고 있다고 다시 알렸다.

낮 12시 38분에는 조합 처방이 올라왔다. 리랭커에 RDB 필터·BM25·키워드를 섞으면 효과가 좋고, 자신은 정보 계층화를 선호해 L4 ~ 5까지만 나눠도 대부분 적절한 그래뉼러티가 나온다는 설명이었다. 지도를 확대할수록 숫자가 15, 5, 7, 3으로 쪼개지는 중간 클러스터링에 빗대 렌더링 부담도 줄일 수 있다고 했다. 질문자는 홉 수를 넉넉하게 잡았던 설정을 최대 3개로 제한하고 대신 세렌디피티 전용 로직을 넣었다고 답했다.

정리 발언은 이랬다.

그렇다고 홉수 안따지면 메모리 터지고

홉 수를 따지면 원래 잡히던 것이 안 나오고, 안 따지면 메모리가 터진다는 취지였다.

해석

이날 오간 조언은 도구 추천보다 개념 키워드 중심이었다. 단방향과 1홉 양방향, 하이퍼 엣지와 계층화, 홉 제한이 같은 대화 안에서 서로 다른 처방으로 나란히 놓였다. 대화에는 정확도가 실제로 얼마나 올랐는지 수치가 나오지 않았고, 이는 하나의 정답보다 섞어 쓰는 설계가 논의의 결론에 가까웠음을 시사한다.