2026. 06. 30.

RAG가 못 찾는 건 결국 구조의 문제다 — Hyper-Extract가 풀려는 것

#hyper-extract#knowledge-graph#graphrag#llm#open-source

지식 검색이 안 되는 건 모델이 멍청해서가 아니다. 구조가 평평하기 때문이다. 이 사실을 나는 M365 Copilot을 쓰면서 매일 확인하고 있다. 수년 치 리서치 리포트, 회의록, 분석 자료가 OneDrive와 SharePoint에 쌓여 있는데, Copilot에게 뭘 물어보면 자꾸 엉뚱한 문서를 가져온다. 같은 Claude, 같은 GPT를 직접 쓸 때는 똑똑한데, 회사 자료 검색에 연결하면 멍해진다. 모델이 바뀌는 게 아니라, 검색 구조가 바뀌는 거다. 평평한 텍스트 더미에서 의미를 찾으라고 하니까 못 찾는 거다.

그래서 관심을 갖게 된 게 지식 그래프다. 텍스트를 노드와 엔티티, 관계로 구조화하면 검색이 달라진다. "A보고서가 인용한 B데이터" 같은 관계를 잡아낼 수 있다. 회사 보고서 검색을 Text RAG에서 GraphDB까지 4단계로 키우는 로드맵을 정리한 적도 있고, Neo4j LLM Graph Builder를 써보고 싶다고 쓴 적도 있다. 아직 직접 GraphRAG를 프로덕션에서 돌려본 건 아니다. 관심이 있어서 이것저것 읽고 있는 단계다. 그러다 PyTorchKR에서 Hyper-Extract라는 프로젝트를 발견했다.

Hyper-Extract가 뭘 하는 건가

Hyper-Extract는 한마디로 "비정형 텍스트를 구조화된 지식으로 바꾸는" 프레임워크다. LLM으로 문서를 읽고, 엔티티와 관계를 추출하고, 그걸 8가지 형태의 구조화된 데이터로 내보낸다. 단순한 리스트부터 지식 그래프, 하이퍼그래프, 시공간 그래프까지 지원한다.

핵심은 8가지 Auto-Type이다. AutoModel은 Pydantic 구조화 요약, AutoList와 AutoSet은 아이템 컬렉션, AutoGraph는 전통적 지식 그래프다. 여기까지는 기존 도구들도 한다. 흥미로운 건 뒤의 네 가지다. AutoHypergraph는 하나의 관계가 3개 이상의 엔티티를 동시에 연결하는 하이퍼엣지를 만든다. AutoTemporalGraph는 관계에 시간 정보를 붙이고, AutoSpatialGraph는 위치 정보를 붙인다. AutoSpatioTemporalGraph는 둘 다. 이 조합을 지원하는 오픈소스 도구는 내가 아는 한 없다.

하이퍼그래프가 왜 중요한가. 현실의 관계는 대부분 다자간이다. "A사가 B정부와 C기업의 합작으로 D프로젝트를 2024년에 수주했다" — 이 문장을 전통적 지식 그래프로 풀면, 이진 관계 여러 개로 쪼개야 한다. A-D, B-D, C-D, D-2024. 이 과정에서 정보가 손실된다. 이게 하나의 사건인데 여러 개의 엣지로 분해되면서 "수주"라는 관계의 주체가 누구인지 흐려진다. 하이퍼그래프는 이걸 하나의 하이퍼엣지로 보존한다. 회사 리포트에서 "한 브랜드가 3개 세그먼트에 걸쳐 어떤 캠페인을 했다"는 정보도 마찬가지다.

왜 기존 도구로는 부족했나

GraphRAG, LightRAG, KG-Gen. 지식 그래프 기반 RAG 도구는 이미 여러 개 있다. 나도 이름은 계속 들어왔다. 그런데 이 도구들에는 공통의 한계가 있다.

기능GraphRAGLightRAGKG-GenHyper-Extract
지식 그래프지원지원지원지원
시간 그래프부분미지원미지원지원
공간 그래프미지원미지원미지원지원
하이퍼그래프미지원미지원미지원지원
도메인 템플릿없음없음없음80+

Hyper-Extract는 이 도구들을 추출 엔진으로 통합한다. GraphRAG 알고리즘을 선택하되, 출력은 AutoHypergraph로 받을 수 있다. 기존 도구의 알고리즘은 쓰되, 출력 구조는 더 풍부하게 가져가는 셈이다.

도메인 템플릿이란 것도 눈에 띄었다. 금융, 법률, 의료, 산업 등 80개 이상의 템플릿을 내장하고 있다. "이 산업에서 어떤 엔티티가 중요한가"를 미리 정의해둔 상태에서 시작할 수 있다는 뜻이다. 내가 회사에서 산업 리포트를 다룰 때마다 드는 생각이 있다. 리포트에 등장하는 브랜드, 소비자 세그먼트, 유통 채널, 시장 규모 수치 — 이런 엔티티들이 매번 비슷한 패턴으로 나오는데, 매번 새로 스키마를 짜야 한다면 그건 비효율이다. 템플릿이 있으면 거기서부터 시작해서 내 상황에 맞게 수정하면 된다.

점진적 진화(Incremental Evolution) 기능도 인상적이다. 새 문서를 추가하면 기존 지식 추상체를 확장한다. 전체를 다시 처리하지 않는다. 회사에 매월 새 리포트가 들어오는 상황에서, 이건 꽤 중요한 기능이다. 매번 전체 그래프를 재구축하는 건 비용도 비용이거니와, 결과가 매번 달라지면 신뢰할 수 없다. 축적되어야 의미가 있다.

이게 내 문제를 풀어줄 수 있을까

솔직히 말하면, 아직 모르겠다. Hyper-Extract는 프레임워크다. CLI와 Python SDK를 제공하고, uv tool install hyperextract 한 줄로 설치할 수 있다. Apache-2.0 라이선스다. 하지만 내가 진짜 필요한 건 "이 도구가 회사 리포트 수백 개를 먹고, 내가 '작년 Q3에 우리가 추정한 시장 규모가 어디 있지?'라고 물었을 때 정확한 답을 주는가"다. 그건 직접 돌려봐야 안다.

당장 설치할 생각은 없다. 관련된 실전 사례나 베스트 프랙티스가 쌓이면 그때 살펴보고 적용을 고려하려 한다. 프레임워크가 좋아 보인다고 당장 내 워크플로에 들어가진 않는다. 내가 이미 겪은 일이다. Neo4j LLM Graph Builder도 써보고 싶다고 쓴 지 반년이 됐는데, 아직 안 돌려봤다. 이유는 단순하다. 일이 밀려있고, 혼자서 리서치 업무와 기술 실험을 병행하려면 검증된 도구부터 써야 한다. Hyper-Extract는 2026년 6월 현재 문서만 보고 판단하는 단계다.

내가 확실하게 아는 건 하나다. 지금의 평평한 RAG로는 안 된다. M365 Copilot이 내 자료를 못 찾는 건 모델의 한계가 아니라 검색 인프라의 한계다. 텍스트 청크를 벡터화해서 코사인 유사도로 가져오는 방식은, "어떤 문서가 어떤 문서를 인용했고, 그 안의 어떤 수치가 어떤 맥락에서 쓰였는지"를 잡아내지 못한다. 그러려면 관계가 필요하고, 관계를 표현하려면 그래프가 필요하다. Hyper-Extract가 그 방향으로 가고 있다는 건 분명하다.

불확실한 건, 하이퍼그래프와 시공간 그래프가 내 사용 사례에서 실제로 유의미한 차이를 만들어낼 것인가이다. 회사 리포트에서 "A브랜드가 B세그먼트와 C채널에서 2024년에 D캠페인을 했다"는 정보가 얼마나 자주 등장하는가. 이걸 하이퍼엣지로 표현하는 게 이진 관계 4개로 표현하는 것보다 검색 품질을 얼마나 높이는가. 이건 해봐야 안다. 논문이 아니라 실제 데이터에서.

그래도 읽으면서 고개를 끄덕이게 되는 건, 방향이 맞다는 거다. 지식이 쌓이는 구조, 검색이 구조를 타는 구조. RAG가 매번 처음부터 시작하는 것과 달리, 지식이 축적되고 진화하는 구조. 내가 OpenClaw로 위키를 운영하면서 경험한 것과 같은 원리가 지식 그래프에도 적용된다. 누가 유지보수하느냐. LLM이 한다. 내가 할 일은 주제를 정하고 소스를 던지는 것이다.

방대한 지식에서 내가 원하는 걸 찾아주는 시스템. 그게 결국 필요한 거다. Hyper-Extract가 그 퍼즐의 한 조각이 될 수 있을까?

참고: 아티클 «Hyper-Extract: LLM-Powered Knowledge Extraction Framework» — yifanfeng97

← 모든 글