리서치 회사에는 산업 보고서와 경쟁사 분석, 소비자 조사 자료가 계속 쌓인다. 원문에 적었던 내 관심은 “보고서 A가 인용한 수치 B를 다시 찾고 싶다”는 것이었다. 같은 기업 이름이 들어간 문서를 찾는 일에서 더 나아가 어느 보고서의 어떤 시점 수치를 근거로 썼는지 확인하고 싶었다.
Neo4j LLM Graph Builder를 아직 직접 실행하지 않았다. 이 글은 사용 후기나 사내 도입 성공 사례가 아니라 공식 저장소를 검토해 만든 도입 계획이다. 기존 글의 “방대한 자료를 다루는 유일한 길은 지식 그래프”라는 판단은 수정한다. 키워드·벡터·메타데이터 필터·관계 탐색을 조합하는 여러 방법이 있고 무엇이 필요한지는 실패한 질문으로 확인해야 한다.
보고서 검색의 실패를 먼저 분류한다
M365 Copilot이나 다른 검색 서비스에서 원하는 자료를 찾지 못했다고 그래프 구조 부족을 원인으로 확정할 수는 없다. 사용자의 접근 권한, 색인 대상, 파일 형식, 문서의 최신성, 질문에 포함한 조건을 따로 봐야 한다. 자료에 접근할 수 없는 문제가 원인이라면 다른 검색 엔진도 같은 권한 안에서는 답을 찾기 어렵다.
시험 질문은 문서 이름을 아는 경우와 모르는 경우로 나눈다. “2024년 보고서의 시장 규모 표”를 못 찾는다면 표 추출과 날짜 메타데이터를 확인한다. “보고서 A가 인용한 B기관의 원자료”가 필요하다면 인용 관계를 보존하는 방법을 검토한다. 이 두 질문에서 같은 개선을 기대하면 도구를 과대평가하기 쉽다.
첫 비교에는 기존 검색을 남긴다. 정확한 제목이나 기관 이름으로 근거를 찾을 수 있다면 그 결과와 새 방식을 비교한다. 그래프를 추가한 뒤에만 좋은 질문을 골라서는 도입 비용의 정당성을 설명하기 어렵다. 원문을 찾은 뒤 사람이 답을 확인하는 시간도 기록할 계획이다.
Graph Builder에서 얻는 기능과 직접 책임질 부분
공식 저장소는 PDF 등 비정형 문서를 LLM과 LangChain을 이용해 Neo4j 지식 그래프로 변환하고 생성한 자료를 조회하는 기능을 설명한다. 사용자 스키마와 다양한 모델 연결도 안내한다. 구체적인 제공자·검색 모드·설정 이름은 버전에 따라 바뀌므로 설치할 커밋의 문서를 확인해야 한다. Neo4j Labs 공식 저장소
도구가 문서와 청크, 개체와 관계를 만들더라도 내가 확인할 책임은 남는다. 같은 이름의 기업을 한 개체로 합쳤는지, 계열사를 별도 법인으로 구분했는지, “논의 중인 협력”을 확정 계약으로 바꾸지 않았는지 검수해야 한다. 그래프 화면에서 연결선이 많아 보이는 것과 관계가 정확하다는 사실은 다르다.
벡터 검색과 그래프 탐색을 조합할 수 있다는 점은 검토할 가치가 있다. 다만 관계를 몇 단계 따라갈지 늘리면 관련 없는 문서를 함께 가져올 수 있다. 커뮤니티 요약이나 전체 자료를 묻는 모드도 원문 추적과 최신성 검사가 필요하다. 각 모드를 켰다는 사실만으로 답의 설명 가능성을 확보했다고 평가하지 않는다.
공개 문서 다섯 개로 시작하는 설치 전 준비
첫 실행에는 회사 PDF 수백 개를 넣지 않을 생각이다. 재사용 권리를 확인한 공개 문서 다섯 개를 고르고 원문 파일의 해시와 다운로드 날짜를 기록한다. 표가 있는 문서, 같은 기관이 반복 등장하는 문서, 수정본이 있는 문서를 섞는다. 페이지에서 텍스트를 복사할 수 있는지, 표의 숫자와 단위가 보존되는지도 먼저 본다.
2026년 9월 8일 확인한 README는 Neo4j 5.23 이상과 APOC를 요구하고 로컬 백엔드에는 Python 3.12 이상을 안내한다. Docker Compose 방식과 프론트엔드·백엔드를 따로 실행하는 방식이 있으므로 DB 형태에 맞춰 선택한다. 저장소 문서에는 Neo4j Desktop 사용 시 별도 실행 안내가 있으니 환경과 관계없이 한 명령만 제시하지 않는다.
다음 명령은 저장소와 실행 도구를 확인하는 준비 예시다. 이 글에서 실제 설치를 마쳤다는 뜻이 아니며 API를 호출하거나 회사 문서를 업로드하지 않는다.
git clone https://github.com/neo4j-labs/llm-graph-builder.git
cd llm-graph-builder
git rev-parse HEAD
docker compose version
docker compose config --services
커밋 식별자를 실험 기록에 복사한 뒤 해당 버전의 README와 backend/example.env, frontend/example.env를 읽는다. 환경 변수 전체를 화면에 출력하면 키와 비밀번호를 노출할 수 있으므로 필요한 항목의 존재와 설정 여부만 확인한다. 예제 비밀번호를 운영 자격증명처럼 재사용하지 않는다.
설정에는 DB 주소·계정·데이터베이스 이름, 추출 모델, 임베딩 모델, 프론트엔드가 연결할 백엔드 주소가 포함된다. 브라우저가 컨테이너 내부 이름을 해석할 수 없는 경우도 있으므로 백엔드 연결 오류와 DB 접속 오류를 구분한다. 공식 문서를 따라 실행하더라도 사용 포트, 노출 범위, 로그 위치를 기록하고 첫 시험은 외부 공개 없이 진행한다.
산업 분류보다 원문 추적을 먼저 설계한다
리서치 보고서는 한 문서에서 소비재, 기술 도입, 장기 추세를 함께 다룬다. 산업별로 노드 타입을 늘리기 전에 문서, 주장, 기업과 출처의 관계를 작게 정하는 편이 검수하기 쉽다. 다음 표는 도구의 기본 스키마가 아니라 내가 시험할 논리 모델이다. 실제 구현 때는 도구가 제공하는 구조와 매핑해야 한다.
| 대상 | 저장할 정보 | 확인할 오류 |
|---|---|---|
| Document | 문서 ID, 제목, 발행일, 파일 해시 | 같은 파일의 중복 등록 |
| Claim | 원문 문장, 수치, 단위, 기준 시점 | 예측치를 확정 실적으로 변경 |
| Organization | 공식 이름, 별칭, 식별 근거 | 이름이 같은 다른 기관을 통합 |
| Evidence | 문서 ID, 페이지, 문단 위치 | 원문으로 돌아갈 경로 누락 |
가상 문장으로 “A기관은 2024년 B시장 규모를 100으로 추정했다”를 생각해보자. 100은 시장의 영구적인 속성처럼 저장하기보다 출처와 기준 시점을 가진 주장에 붙인다. 다른 기관이 같은 시점을 90으로 추정하면 기존 값을 덮어쓰지 않고 두 주장을 남긴다. 숫자의 단위와 가격 기준이 다른 경우에도 비교 전에 확인할 수 있다.
기업의 이름만 보고 자동 병합하는 기준은 조심스럽게 정한다. 영문·한글 별칭이 같은 기업을 뜻할 수도 있고 비슷한 이름의 별도 법인일 수도 있다. 애매한 경우에는 서로 다른 노드를 유지하고 확인 대상으로 남긴다. 잘못 합친 뒤 모든 관계를 되돌리는 비용보다 초기에 보류하는 비용이 작은지 살펴볼 계획이다.
Azure OpenAI를 선택해도 데이터 경로를 확인한다
기존 글에는 Azure를 쓰면 데이터가 회사 테넌트 안에서만 처리되고 외부 API로 나가지 않는다고 적었다. 이 표현은 정확하지 않았다. Azure 서비스를 호출하는 것도 클라우드로 데이터를 전송하는 행위이며 처리 위치와 저장·보관 조건은 배포 유형과 기능에 따라 달라진다.
Microsoft의 공식 안내는 지역, Global, DataZone 같은 배포 유형에 따른 처리 위치와 일부 기능의 데이터 저장, 악용 감시 등을 설명한다. Azure 사용이라는 이름만으로 회사의 보안 요구를 충족한다고 판단하지 않는다. 프롬프트를 기반 모델 학습에 쓰는지와 데이터를 어디에서 처리·보관하는지는 서로 다른 질문이다. Microsoft의 데이터·개인정보·보안 안내
추출용 LLM을 Azure로 연결했어도 임베딩은 다른 제공자를 사용할 수 있다. PDF 로더, OCR, 로그 수집, 업로드 저장소, Neo4j 호스팅까지 경로를 그려봐야 한다. 도구의 모든 단계가 같은 서비스 경계를 사용한다고 추정해서는 안 된다. Ollama 같은 로컬 모델을 골라도 별도 임베딩이나 업로드 단계가 외부에 연결되면 완전한 로컬 처리라고 부르기 어렵다.
시험 전에는 데이터 소유자의 사용 허용, 계정 권한, 접속 경로, 저장 위치와 보관 기간을 확인한다. 고객사 보고서라면 계약상 재처리와 외부 제공 조건도 검토해야 한다. 실험용 계정에는 필요한 DB와 모델만 접근하도록 하고 설정 파일을 Git에 넣지 않는다. 보안 검토를 끝내기 전에는 공개 연습 자료만 사용한다.
첫 업로드에서 성능보다 추출 오류를 본다
문서 다섯 개를 넣었다면 질문부터 반복하지 않고 원문과 추출물을 대조한다. 표의 숫자, 퍼센트와 퍼센트포인트, 단위, 인용 기관, 부정 문장을 확인한다. “관계가 없다”는 문장에서 관계를 생성했거나 회사 이름을 문서 저자로 잘못 연결했다면 검색기까지 가기 전에 수정해야 한다.
질문 시험에서는 한 문서의 수치, 두 문서 사이의 인용, 문서에 없는 사실을 나눠 묻는다. 답변에 달린 출처가 실제 주장을 지지하는지 연다. 관련 보고서 링크를 달았지만 해당 페이지에는 답이 없는 경우를 통과로 처리하지 않는다. 응답 시간이 길어졌다면 검색·생성·네트워크 대기를 나눠 기록한다.
문서 하나를 수정한 뒤 같은 질문을 다시 묻는 과정도 필요하다. 새 수치가 들어왔는데 이전 청크나 관계를 함께 사용하면 결과가 흔들릴 수 있다. 수정·삭제 시 어떤 데이터를 갱신해야 하는지 문서화한다. 그래프를 한 번 예쁘게 생성한 결과보다 이 갱신 시험을 통과했는지가 운영 검토에 더 쓸모 있다.
도입 판단에는 추출 정확도, 근거 확인 시간, 질문 처리 비용, 갱신 비용을 함께 놓을 생각이다. 기존 검색으로 충분한 자료군은 그대로 두고 관계 탐색이 필요한 일부 문서에만 적용할 수도 있다. 지금은 Graph Builder를 설치해 검증할 후보로 남겨둔다. 다음 단계에서 공개 문서의 실행 로그와 틀린 관계를 기록하면 도구 소개를 실제 평가로 이어갈 수 있다.
참고자료
- Neo4j Labs, LLM Graph Builder: 기능, 지원 환경, 모델·배포 설정. 2026년 9월 8일 문서 확인 기준.
- Neo4j Graph Builder 환경 변수 예제: 설치할 버전에서 추출·임베딩 설정을 확인할 파일.
- Microsoft Foundry 데이터·개인정보·보안 안내: 처리 위치·저장·악용 감시 등 확인 항목.