안녕하세요, 자바파커입니다.
"이거 다 만들고 나니까 — 정말 쓸 만한가요?"
5편짜리 구현을 마치고 며칠 운영해본 뒤의 회고입니다. 1편에서 약속한 "벡터만으로 부족했던 RAG"를 GraphRAG로 풀어봤고, 그 결과가 어땠는지 솔직히 짚어보려 합니다.
결론부터 말씀드리면 — 관계 기반 질의 정확도는 확실히 올랐습니다. 다만 "모두에게 추천하느냐"는 별개 문제입니다. 잘 맞는 도메인이 있고, 솔직히 오버킬인 도메인도 있어요.
이번 편에서는 다섯 가지를 정리합니다. (1) 좋았던 것, (2) 비용 실측, (3) 한계와 함정, (4) 어떤 도메인에 추천하나, (5) 다음에 시도하고 싶은 것.
좋았던 것 — 답이 "사실"에 근접해진다
가장 인상 깊었던 변화는 답변에 근거가 따라붙는다는 점이었습니다.
벡터 RAG만 쓸 때는 "이 글에 따르면 X일 것입니다"라는 식의 모호한 답이 흔했습니다. 지금은 답변 끝에 [refs: ontology-search-02-modeling, ontology-search-04-llm-extraction]처럼 출처 slug가 붙고, 클릭해서 검증할 수 있습니다.
특히 효과가 컸던 질의 유형:
- "X 시리즈의 N번째 글" — 메타데이터 기반 정확도 100%
- "A·B 태그를 모두 가진 글" — 교집합 정확
- "이 글이 인용한 외부 자료" — 본문에서 추출한 인용 그대로 반환
- "이 글 이해하려면 먼저 읽어야 할 글" — 선수 관계 추적
순수 벡터로는 위 네 유형 모두 정확도가 낮았습니다. 명시적 관계는 그래프, 의미 매칭은 벡터라는 역할 분담이 깔끔하게 됐어요.
비용 실측 — 생각보다 싸지만 모니터링은 필수
이번 시리즈 도메인(블로그 글 100개) 기준 한 달 운영 비용을 실측해봤습니다.
| 항목 | 빈도 | 단가 | 월 비용 |
|---|---|---|---|
| Neo4j Community (로컬 도커) | 상시 | $0 | $0 |
| LLM 추출 (4편, 글 변경 시) | 글당 1회, 평균 5건/주 | ~$0.009 | ~$0.18 |
| 임베딩 (5편 벡터) | 글당 1회, 평균 5건/주 | ~$0.001 | ~$0.02 |
| 질의 시 LLM 호출 (라우팅+Cypher+합성) | 질의당 3회 | ~$0.005 | 질의 1000회 시 ~$5 |
| 합 (질의 1000회/월 가정) | 약 $5.2 |
블로그 규모에선 거의 부담이 없습니다. 다만 글이 1만 개 넘어가고 질의가 일 단위로 수천 건이면 그림이 달라집니다. 그때는 LLM 호출 캐싱(질문 해시 → Cypher), 라우팅 결정 캐싱, 답변 캐싱까지 다 켜야 합니다.
비용 관점에서 가장 위험한 패턴은 모든 질의를 hybrid로 라우팅하는 것입니다. LLM 호출이 2배가 되고 합성 컨텍스트도 커져서, 한 번 잘못 굳어지면 비용이 조용히 부풀어 오릅니다. 라우팅 로그를 주기적으로 본 비율로 확인하세요.
한계와 함정 — 솔직히 어려웠던 것
다 잘 풀린 건 아닙니다. 부딪힌 한계 네 가지.
1) 온톨로지 변경 시 마이그레이션이 무겁다
운영 중 "Category 아래 SubCategory를 두자"는 식의 스키마 변경이 한 번이라도 생기면, 적재 스크립트·Cypher·시스템 프롬프트의 SCHEMA 세 곳을 동시에 수정해야 합니다. 한 곳이라도 빠지면 LLM이 잘못된 라벨을 생성합니다.
대응: SCHEMA를 단일 파일에 두고 적재·질의 양쪽에서 import해서 쓰는 패턴이 필수입니다. 처음부터 그렇게 안 짜면 나중에 갈아엎습니다(저처럼).
2) LLM 추출 결과의 일관성
같은 글을 두 번 추출하면 결과가 미세하게 다릅니다. 특히 RELATED_TO처럼 주관적 판단이 들어가는 관계가 흔들립니다.
대응: 4편에서 권한 대로 추출 결과를 frontmatter에 역으로 적어두는 패턴이 가장 안정적이었습니다. 한 번 사람이 검수한 결과를 frontmatter에 굳히면, 이후엔 LLM 호출 없이 frontmatter 파싱만으로 끝납니다.
3) 다국어/표기 흔들림
"Claude Code"와 "claude code", "GraphRAG"와 "Graph RAG"이 다른 Tag 노드로 적재되는 사고가 종종 났습니다.
대응: 적재 시 태그 정규화 함수를 두세요. 케이스, 공백, 동의어 매핑까지. 그래도 완벽하진 않아서, 운영하며 주기적으로 MATCH (t:Tag) RETURN t.name으로 훑어보고 머지합니다.
4) "사실인지 의견인지" 구별 못 함
본문에 "X는 좋다"라는 의견이 있을 때 LLM이 그걸 사실처럼 추출해 그래프에 흘려보내는 경우가 있었습니다.
대응: 4편 시스템 프롬프트에 "의견/주장은 추출하지 말 것"을 명시하고, evidence 필드의 인용문을 사람이 한 번 보는 단계가 결국 필요합니다. 자동화 100%는 위험합니다.
어떤 도메인에 추천하나
직접 해보고 정리한 도메인 적합도입니다.
| 도메인 | 적합도 | 이유 |
|---|---|---|
| 블로그·문서 검색 | 좋음 | 명시적 관계(태그, 시리즈, 인용)가 본문에 풍부 |
| e-commerce(제품·브랜드·카테고리) | 매우 좋음 | 관계가 명확하고 정량적, 추천에도 활용 |
| 학술 논문·인용망 | 매우 좋음 | 인용 관계가 곧 그래프, 이미 RDF 진영의 정공법 |
| 법령·규정 | 좋음 | 조항·예외·참조 관계가 그래프와 자연스럽게 매핑 |
| 대화 로그·소셜 텍스트 | 보통 | 비정형이 강해 LLM 추출 비용·잡음이 커짐 |
| 시계열 센서 데이터 | 비추천 | 관계보다 수치 집계 — 시계열 DB가 답 |
| 단순 FAQ | 비추천 | 벡터 RAG로 충분, GraphRAG는 오버킬 |
가장 큰 분기점은 관계가 본질적으로 풍부한 도메인인가라는 질문입니다. 그렇다면 그래프가 핵심 자산이 되고, 그렇지 않다면 벡터 RAG로도 충분합니다.
다시 한다면 무엇을 다르게 할까
다섯 가지가 떠오릅니다.
1) SCHEMA를 처음부터 단일 소스로
위의 1번 한계와 직결됩니다. 적재 스크립트, Cypher 생성기, 검수 스크립트가 같은 SCHEMA 객체를 import하는 구조로 짜야 합니다.
2) 글이 적을 땐 vectors는 나중에
이번엔 5편에 벡터를 같이 도입했지만, 글이 100개 미만일 땐 그래프만으로 시작하는 게 빨랐습니다. 의미 매칭 질의가 들어오기 시작했을 때 그때 도입해도 늦지 않습니다.
3) 사람 검수 UI를 일찍 만들기
LLM 추출 결과를 콘솔 로그로만 보면 검수 부담이 큽니다. 간단한 웹 페이지로 "추출 결과 OK/Drop/Edit"만 누를 수 있게 해두면, 운영이 훨씬 가볍습니다.
4) 회귀 테스트셋 일찍 만들기
핵심 질의 20개를 골라 사람이 직접 답한 정답 목록을 만들어두세요. 프롬프트나 모델을 바꿀 때마다 이 테스트셋을 돌려 점수를 매기면 회귀를 즉시 잡습니다. 처음엔 귀찮지만, 운영 두 달 차부터 가장 큰 자산이 됩니다.
5) "안 풀리는 질의" 로그를 따로 모으기
LLM이 답을 못 만들었거나 빈 결과가 나온 질의를 별도 로그로 모아두면, 다음 라운드 온톨로지 확장의 가장 정확한 입력이 됩니다. 사용자가 원하는 게 곧 그래프의 다음 모습이에요.
시리즈 마무리
6편에 걸쳐 다음을 거쳐왔습니다.
- 1편 — 왜 온톨로지인가
- 2편 — 클래스·속성·관계 설계
- 3편 — Neo4j 선정과 frontmatter 적재
- 4편 — LLM Tool Use로 본문 자동 추출
- 5편 — GraphRAG 자연어 검색
- 6편 — 운영 회고 (지금 이 글)
- 확장편 — 정형 DB·빅데이터와 함께 가기
시리즈를 시작할 때 가졌던 가설은 단순했습니다. "LLM 시대에 오래된 도구인 온톨로지가 다시 의미를 가질 것이다." 직접 만들어보니 그 가설은 맞기도 하고 조건부이기도 했어요. 관계가 풍부한 도메인이고 답변의 근거가 중요한 서비스라면 GraphRAG는 분명한 답입니다. 그게 아니면 벡터 RAG로 충분합니다.
도구는 도구입니다. 무엇을 풀고 싶은지가 항상 먼저고요.
자주 묻는 질문 (FAQ)
Q1. 1인이 운영하기엔 결국 어렵지 않나요? 이 시리즈 분량으로도 보셨겠지만, 만드는 건 며칠이고 운영은 평생입니다. 도메인 자체가 명확하고 본인이 그 도메인을 잘 아는 상태라면 1인 운영도 충분히 가능합니다. 도메인이 너무 넓거나 자주 바뀌는 영역이라면 팀이 필요합니다.
Q2. Microsoft GraphRAG로 처음부터 시작했으면 더 빠르지 않았을까요? 빠르지만 비싸요. Microsoft GraphRAG는 LLM이 자동으로 그래프를 만들어내는 방식이라 초기 토큰 비용이 큽니다. 이 시리즈처럼 사람이 온톨로지를 먼저 설계하고 LLM을 추출 일부분에만 쓰는 방식이 비용도 적고 그래프 품질도 통제하기 쉽습니다.
Q3. 시리즈 코드 전체를 공개하실 건가요? 정리되는 대로 GitHub에 올리고 본 블로그에 링크 추가하겠습니다. 댓글로 알림 원하시면 댓글 남겨주시면 공개 시점에 따로 연락드리겠습니다.
긴 시리즈를 끝까지 따라와 주셔서 감사합니다. 여러분이 이 도구를 직접 손에 잡으시고, 본인의 도메인에서 의미를 발견하시면 이 시리즈가 제 역할을 다한 거예요.
시리즈 발행 후 "이미 RDB·DW·검색엔진이 있는 조직 관점이 빠졌다"는 피드백을 받아 확장편을 한 편 더 붙였습니다. 도입 의사결정에 도움이 될 거예요.
다음 시리즈는 운영 자동화 쪽으로 가볼까 생각 중입니다. 의견 있으시면 댓글로 알려주세요.