고급 RAG 시스템 구축 프로젝트 - 상세 분석 보고서
관련 프로젝트
1. 프로젝트 개요
본 프로젝트는 Knowledge Graph 기반의 하이브리드 검색 엔진을 갖춘 차세대 RAG(Retrieval-Augmented Generation) 시스템을 구축하는 것을 목표로 한다. 단순히 문서를 임베딩하여 검색하는 기존 방식을 넘어, 엔티티와 관계를 추출하여 지식 그래프로 구조화하고, 다양한 검색 전략을 결합한 후 재순위화(Reranking)를 통해 정밀도를 극대화하는 접근법을 채택했다.
이 시스템은 1,437개의 문서를 처리하여 42,462개의 고품질 청크를 생성하고, 169,886개의 엔티티 노드와 775,366개의 관계를 Knowledge Graph로 구축했다. 특히 주목할 점은 “데이터의 양이 아닌 구조화의 질이 검색 성능을 결정한다”는 핵심 가설을 실제 구현과 평가를 통해 검증했다는 것이다. 초기 버전에서 108,000개의 청크를 무차별적으로 인덱싱했을 때보다, 품질이 낮은 데이터를 제거하고 42,462개로 정제한 현재 버전이 오히려 12.5% 더 높은 성능을 보였다.
2. 기술 스택 상세 설명
2.1 AI Service Layer - 지능형 처리 핵심
AI Service 레이어는 Python 3.11을 기반으로 FastAPI 프레임워크를 사용하여 구축되었다. FastAPI는 높은 성능과 자동 문서화 기능, 그리고 타입 힌팅을 통한 안정성으로 최근 AI 서비스 개발에서 표준으로 자리잡고 있다. 이 레이어에서는 LangGraph와 LangChain을 활용하여 복잡한 RAG 워크플로우를 구현했다.
LangGraph는 그래프 기반으로 AI 에이전트의 워크플로우를 정의할 수 있게 해주는 프레임워크다. 본 프로젝트에서는 문서 검색, 엔티티 추출, 답변 생성 등의 단계를 그래프 노드로 구성하고, 조건부 분기를 통해 동적으로 처리 경로를 결정하는 로직을 구현했다. LangChain은 LLM과의 통신, 프롬프트 관리, 메모리 처리 등 기본적인 LLM 애플리케이션 구성 요소를 제공한다.
2.2 API Gateway - 안정적인 서비스 제공
API Gateway는 SpringBoot 3.x로 구축되었다. 최신 버전의 SpringBoot는 Java 17 이상을 지원하며, 개선된 성능과 보안 기능을 제공한다. 여기에 Resilience4j를 통합하여 서킷 브레이커(Circuit Breaker), 재시도(Retry), 속도 제한(Rate Limiting) 등의 회복탄력성(Resilience) 패턴을 구현했다.
Resilience4j는 Netflix Hystrix의 후속 프로젝트로, 함수형 프로그래밍 스타일을 지원하고 경량화된 설계로 최근 마이크로서비스 아키텍처에서 널리 사용되고 있다. AI 서비스는 LLM 호출로 인해 응답 시간이 불안정할 수 있기 때문에, API Gateway에서 이러한 장애를 격리하고 우아하게 처리하는 것이 중요하다.
2.3 Frontend - 현대적인 사용자 경험
프론트엔드는 React 18을 기반으로 구축되었다. React 18에서 도입된 Concurrent Rendering과 자동 배칭(Automatic Batching) 기능은 사용자 인터페이스의 반응성을 크게 개선했다. Tailwind CSS를 스타일링 프레임워크로 선택하여 유틸리티 퍼스트(Utility-first) 접근법으로 빠르고 일관된 UI를 구축했다.
TypeScript를 사용함으로써 컴파일 시점에 타입 오류를 잡아내고, IDE의 자동완성과 리팩토링 기능을 최대한 활용할 수 있었다. 특히 AI 서비스의 복잡한 응답 구조를 타입으로 정의함으로써, 프론트엔드와 백엔드 간의 인터페이스를 명확하게 관리할 수 있었다.
2.4 Database - 다층 저장소 전략
데이터베이스 레이어는 세 가지 특화된 저장소로 구성된다. PostgreSQL 16은 정형 데이터와 메타데이터를 관리하는 주 데이터베이스로 사용된다. 문서 정보, 청크 메타데이터, 사용자 쿼리 로그 등이 여기에 저장된다. PostgreSQL 16에서는 성능 개선과 함께 SQL/JSON 기능이 강화되어 반구조화 데이터도 효율적으로 다룰 수 있다.
Neo4j 5.x는 Knowledge Graph를 저장하고 쿼리하는 그래프 데이터베이스다. 169,886개의 엔티티 노드와 775,366개의 관계를 저장하며, Cypher 쿼리 언어를 통해 복잡한 관계 탐색과 패턴 매칭을 수행한다. 예를 들어 “A라는 기술을 사용하는 프로젝트 중 B라는 사람이 언급된 것”과 같은 다중 홉(Multi-hop) 쿼리를 효율적으로 처리할 수 있다.
Elasticsearch 8.x는 전문 검색 엔진으로, Dense 벡터 검색, Sparse 벡터 검색, 그리고 BM25 기반 키워드 검색을 모두 지원한다. Elasticsearch 8에서는 k-NN 벡터 검색 성능이 대폭 개선되었고, HNSW(Hierarchical Navigable Small World) 알고리즘을 통해 수백만 개의 벡터에서도 밀리초 단위의 응답 시간을 보장한다.
2.5 LLM - 하이브리드 모델 전략
본 프로젝트는 비용 효율성과 성능을 동시에 고려한 하이브리드 LLM 전략을 채택했다. 런타임에서는 DeepSeek V3.2를 사용한다. DeepSeek V3.2는 중국의 AI 스타트업 DeepSeek이 개발한 오픈소스 모델로, GPT-4 수준의 성능을 보이면서도 API 비용이 극도로 저렴하다는 장점이 있다. 실제로 본 프로젝트에서는 전체 파이프라인을 약 75,000원에 운영할 수 있었다.
개발 단계에서는 Claude Opus 4.6을 사용한다. Opus 4.6은 Anthropic의 최상위 모델로, 복잡한 추론과 긴 컨텍스트 처리에서 탁월한 성능을 보인다. 개발 초기에는 시스템 설계와 프롬프트 엔지니어링에 최고 성능의 모델을 사용하여 기준점을 확립한 후, 운영 단계에서 비용 효율적인 모델로 전환하는 전략이다.
2.6 Embedding - 하이브리드 임베딩 전략
임베딩 모델로는 BGE-M3를 사용한다. BGE-M3는 BAAI(Beijing Academy of Artificial Intelligence)에서 개발한 다국어 임베딩 모델로, Dense 벡터와 Sparse 벡터를 동시에 생성할 수 있다는 점이 특징이다.
Dense 임베딩은 의미적 유사도를 잘 포착하지만 정확한 키워드 매칭에는 약할 수 있다. 반대로 Sparse 임베딩(또는 BM25 같은 전통적인 키워드 검색)은 정확한 용어 일치에는 강하지만 의미적 유사성을 놓칠 수 있다. BGE-M3는 두 가지를 동시에 제공함으로써, 하이브리드 검색의 기반을 마련한다.
2.7 문서 파싱 - 다형식 지원
Docling 2.x를 사용하여 다양한 형식의 문서를 파싱한다. PDF, DOCX, 한글(HWP), 마크다운(MD), 텍스트(TXT), HTML 등 주요 문서 형식을 모두 지원한다. 특히 한글 문서를 지원한다는 점이 국내 환경에서 중요한 장점이다.
문서 파싱은 RAG 시스템의 품질을 좌우하는 첫 단계다. 레이아웃을 제대로 인식하지 못하거나, 표와 이미지를 누락하거나, 인코딩 문제로 텍스트가 깨지면 이후 모든 단계가 의미가 없어진다. Docling은 머신러닝 기반의 레이아웃 분석을 통해 복잡한 문서 구조도 정확하게 파싱할 수 있다.
2.8 Infrastructure - 컨테이너 기반 오케스트레이션
인프라는 Docker Compose를 사용하여 18개의 컨테이너로 구성된다. 각 컴포넌트가 독립적인 컨테이너로 실행되므로 격리성과 확장성이 보장된다. Nginx를 리버스 프록시로 사용하여 로드 밸런싱과 SSL 종료를 처리한다.
18개 컨테이너는 PostgreSQL, Neo4j, Elasticsearch와 같은 데이터베이스부터 FastAPI 서비스, SpringBoot Gateway, React 프론트엔드, 그리고 Prometheus, Grafana, Kibana, Loki, Jaeger 같은 관측성(Observability) 스택까지 포함한다.
2.9 Observability - 종합 모니터링
관측성 스택은 메트릭, 로그, 트레이스를 모두 커버한다. Prometheus는 시계열 메트릭을 수집하고, Grafana는 이를 시각화한다. API 응답 시간, 에러율, 데이터베이스 커넥션 풀 상태, LLM 호출 레이턴시 등을 실시간으로 모니터링할 수 있다.
Kibana는 Elasticsearch에 저장된 로그를 검색하고 분석하는 도구다. 사용자 쿼리, 검색 결과, LLM 응답 등을 로그로 남기고, Kibana를 통해 패턴을 분석할 수 있다. Loki는 경량 로그 집계 시스템으로, Prometheus와 같은 라벨 기반 쿼리를 지원한다.
Jaeger는 분산 추적(Distributed Tracing) 시스템이다. 사용자 요청이 API Gateway → FastAPI → Elasticsearch → Neo4j → LLM을 거치는 전체 경로를 추적하고, 각 구간의 지연 시간을 분석할 수 있다. 이는 성능 병목을 찾는 데 필수적이다.
3. 데이터 현황 분석
3.1 문서와 청크의 품질 관리
시스템은 현재 1,437개의 문서를 처리하여 42,462개의 청크를 생성했다. 여기서 중요한 것은 이 숫자가 단순히 문서를 기계적으로 분할한 결과가 아니라, 철저한 품질 관리를 거친 결과라는 점이다.
초기에는 56,063개의 청크가 생성되었다. 그러나 품질 분석 결과 13,601개의 청크가 “쓰레기 청크”로 분류되었다. 이들은 토큰 수가 50개 미만(tc<50)으로, 의미 있는 정보를 담고 있지 않거나 문맥이 너무 짧아 검색 결과로서 가치가 없는 것들이다. 예를 들어 목차만 있는 페이지, 페이지 번호만 있는 푸터, 의미 없는 광고 문구 등이 여기에 해당한다.
이러한 저품질 청크를 Elasticsearch, Neo4j, PostgreSQL 세 저장소에서 모두 제거함으로써, 검색 노이즈를 줄이고 정밀도를 높일 수 있었다. “덜어내기”가 때로는 “더하기”보다 중요하다는 교훈을 보여주는 사례다.
3.2 Knowledge Graph의 규모와 구조
Knowledge Graph는 169,886개의 엔티티 노드로 구성된다. 이 노드들은 Entity(일반 개체), Technology(기술 용어), Person(인물) 세 가지 타입으로 분류된다. 엔티티 추출은 두 단계에 걸쳐 수행되었다.
Phase 3 Round 1에서는 토큰 수가 100개 이상인 청크(tc>=100)를 대상으로 엔티티를 추출하여 16,185건의 엔티티를 얻었다. 이들은 비교적 긴 문맥에서 추출되었기 때문에 중요한 개념일 가능성이 높다.
Phase 3 Round 2에서는 기준을 낮추어 토큰 수가 50개 이상인 청크(tc>=50)까지 포함시켰다. 이를 통해 23,074건의 엔티티 추출 작업을 완료했다. 최종적으로 169,886개의 엔티티가 생성된 것은 동일한 엔티티가 여러 문서에서 언급되면서 중복 제거와 정규화를 거쳤기 때문이다.
관계는 총 775,366개가 구축되었다. 관계 타입은 MENTIONS(청크가 엔티티를 언급), RELATED_TO(엔티티 간 관계), HAS_ENTITY(문서가 엔티티를 포함), PART_OF(계층 구조) 등이 있다. 이러한 관계를 통해 “이 기술을 사용하는 프로젝트는?”, “이 사람과 관련된 문서는?” 같은 복잡한 쿼리에 답할 수 있다.
3.3 임베딩과 3-Store 정합성
Dense와 Sparse 임베딩은 100% 완료되었다. 모든 청크가 두 가지 형태의 벡터 표현을 가지며, Elasticsearch에 인덱싱되어 있다. 이는 Colab의 무료 GPU를 활용하여 처리되었는데, 로컬에 고가의 GPU가 없어도 대규모 임베딩 작업을 수행할 수 있다는 것을 보여준다.
Entity Extraction도 100% 완료되었다. 23,074건의 청크에서 엔티티를 추출하고, 이를 Neo4j에 저장했다. 중요한 것은 3-Store 정합성이 100%라는 점이다. Elasticsearch, PostgreSQL, Neo4j 세 저장소의 데이터가 완벽하게 동기화되어 있다.
이는 ETL(Extract, Transform, Load) 파이프라인의 트랜잭션 관리가 제대로 되어 있다는 의미다. 한 저장소에는 있는데 다른 저장소에는 없는 고아 레코드(Orphan Record)가 없으며, 청크 ID를 기준으로 세 저장소를 조인할 수 있다. 이는 디버깅과 데이터 신뢰성 측면에서 매우 중요하다.
4. 진행 상황 및 마일스톤
4.1 Sprint 12의 성과 (2026-02-16 기준)
Sprint 12는 프로젝트의 중요한 전환점이 되었다. ETL Phase 1에서 파싱과 청킹을 완료하여 1,437개 문서로부터 56,063개의 초기 청크를 생성했다. ETL Phase 2에서는 Colab GPU를 활용하여 Dense와 Sparse 임베딩을 100% 완료했다.
Phase 3는 두 단계로 나뉘어 진행되었다. Round 1에서는 고품질 청크(tc>=100)를 대상으로 16,185건의 엔티티를 추출했다. Round 2에서는 기준을 완화하여(tc>=50) 23,074건까지 처리 범위를 확대했다. 동시에 저품질 청크 13,601건을 Elasticsearch, Neo4j, PostgreSQL에서 모두 정리하여 데이터 품질을 높였다.
검색 알고리즘 측면에서는 4-Way RRF(Reciprocal Rank Fusion) 검색을 구현했다. Dense 벡터 검색, Sparse 벡터 검색, BM25 키워드 검색, 그리고 Graph 검색의 결과를 RRF 알고리즘으로 융합하여 각 방법의 장점을 결합했다.
여기에 BGE-Reranker를 적용하여 Post-RRF Cross-encoder 재순위를 수행했다. Reranker는 검색된 후보 문서들을 쿼리와 함께 BERT 스타일의 Cross-encoder에 입력하여, 양방향 어텐션을 통해 더 정확한 관련성 점수를 계산한다. 이는 단방향 임베딩 기반 검색보다 훨씬 정밀하지만, 모든 문서에 적용하기에는 비용이 크기 때문에 상위 후보에만 적용하는 것이 일반적이다.
마지막으로 RAGAS v11 평가를 수행하여 A- 등급을 달성했다. 51개의 쿼리를 7개 도메인에 걸쳐 평가한 결과, 산술평균 0.711을 기록했다.
4.2 주요 마일스톤 타임라인
프로젝트의 여정을 시간순으로 살펴보면 체계적인 접근과 지속적인 개선이 돋보인다.
1월 16일에는 설계 문서 6종을 완성했다. 시스템 아키텍처, 데이터 모델, API 명세, ETL 파이프라인, 평가 프레임워크, 배포 전략을 포함하는 설계 문서가 종합 9.1/10점의 평가를 받았다. 이는 실행 전 충분한 계획과 설계에 시간을 투자했다는 것을 보여준다.
1월 24일에는 인프라 18개 컨테이너와 CI/CD 파이프라인을 구축했다. Docker Compose로 전체 스택을 로컬에서 재현 가능하게 만들고, GitHub Actions나 Jenkins를 통한 자동 배포 파이프라인을 구축했다.
1월 30일에는 Backend API 12개를 구현하고, 테스트 커버리지 626/627을 달성했다. 99.8%의 테스트 통과율은 코드 품질과 안정성에 대한 높은 기준을 보여준다.
2월 5일에는 Phase 5 배포를 완료하고, 테스트 커버리지를 97%까지 끌어올렸다. 이 시점에서 Claude Opus 4.6으로 모델을 전환했는데, 이는 개발 단계에서 최고 성능의 모델로 기준점을 확립하기 위함이었다.
2월 10일에는 ETL Phase 1과 2를 완료하여 56,063건의 청크와 임베딩을 100% 처리했다.
2월 15일에는 Phase 3 Entity Extraction Round 1과 RAGAS v9 평가를 수행했다.
2월 16일에는 Phase 3 Round 2를 완료하고, Reranker를 적용하여 RAGAS v11에서 A- 등급을 달성했다. 이는 현재까지의 최고 성과다.
5. 프로젝트 성과 분석
5.1 검색 품질 - RAGAS v11의 의미
RAGAS(Retrieval Augmented Generation Assessment)는 RAG 시스템을 평가하는 프레임워크로, 여러 지표를 통해 종합적으로 성능을 측정한다. v11 평가에서는 Reranker를 적용한 후의 성능을 측정했으며, v10과 비교하여 의미 있는 개선을 보였다.
Faithfulness(충실도) 는 LLM이 생성한 답변이 검색된 컨텍스트에 얼마나 충실한지를 측정한다. v11에서 0.935를 기록했는데, 이는 환각(Hallucination) 비율이 6.5%에 불과하다는 의미다. v10의 0.919에서 0.016 상승한 것으로, 역대 최고치를 경신했다. 높은 Faithfulness는 시스템이 신뢰할 수 있는 정보를 제공한다는 것을 의미한다.
Answer Relevancy(답변 관련성) 는 생성된 답변이 질문과 얼마나 관련이 있는지를 측정한다. v11에서 0.621로 v10의 0.647보다 0.026 하락했다. 이는 의외로 보일 수 있지만, Reranker가 컨텍스트의 정확성을 높이는 대신 다소 보수적으로 작동하면서 나타난 트레이드오프로 해석된다. 전체적으로는 여전히 양호한 수준이다.
Context Precision(컨텍스트 정밀도) 는 검색된 문서 중 실제로 관련 있는 문서의 비율을 측정한다. v11에서 0.618을 기록하여 v10의 0.489에서 0.129(26.4%) 상승했다. 이는 Reranker의 가장 직접적인 효과다. 불필요한 문서를 걸러내고 정말 중요한 문서를 상위에 배치함으로써, LLM이 노이즈가 아닌 시그널에 집중할 수 있게 했다.
Context Recall(컨텍스트 재현율) 은 질문에 답하기 위해 필요한 모든 관련 정보가 검색 결과에 포함되어 있는지를 측정한다. v11에서 0.672로 v10의 0.474에서 0.198(41.8%) 대폭 상승했다. 이는 4-Way RRF와 Reranker의 결합 효과로, 다양한 검색 방법을 융합하고 재순위를 거침으로써 필요한 정보를 놓치는 경우가 크게 줄었다.
종합적으로 v11은 A- 등급을 받았다. 51개 쿼리 중 HIGH 33건(65%), PARTIAL 12건, NONE 6건으로 분류되었다. 이는 대부분의 경우 만족스러운 답변을 제공하고, 일부는 부분적으로 유용하며, 극소수만 실패한다는 의미다.
5.2 핵심 성과 - 품질이 양을 이긴다
본 프로젝트의 가장 중요한 발견은 “데이터의 양이 아닌 구조화의 질이 검색 성능을 결정한다”는 명제를 정량적으로 입증했다는 것이다.
v8 시스템은 108,000개의 청크를 무차별적으로 인덱싱했고, 산술평균 0.632의 성능을 보였다. v11은 그 중 61%를 제거하여 42,462개만 남겼다. 데이터가 절반 이상 줄었음에도, 성능은 0.711로 12.5% 향상되었다.
이것이 가능했던 이유는 단순한 삭제가 아니라, 92,209개의 엔티티와 775,366개의 관계로 Knowledge Graph를 구축하고, 4-Way RRF로 다차원 검색을 수행하며, BGE-Reranker로 정밀 재순위를 했기 때문이다. 즉, “덜어내고, 구조화하고, 지능적으로 검색한” 결과다.
도메인별 성과를 보면 entity_relation 도메인에서 특히 두드러진다. 7건의 쿼리 전부 HIGH 등급을 받았고, Faithfulness는 1.000으로 완벽했다. “A라는 기술과 관련된 프로젝트는?”, “B라는 사람이 언급된 문서는?” 같은 엔티티 관계 질의에 완벽하게 대응했다는 의미다. 이는 Knowledge Graph의 위력을 보여준다.
multi_hop 도메인에서는 7건 중 6건이 HIGH(86%)를 기록했다. Multi-hop은 “A 기술을 사용하는 프로젝트 중 B 회사와 협력한 것은?”처럼 여러 단계의 추론이 필요한 쿼리다. 단일 문서가 아닌 여러 문서에 걸친 정보를 종합해야 하므로 어렵지만, Graph 검색과 관계 탐색을 통해 높은 성공률을 보였다.
semantic 도메인은 v10에서 D등급이었으나 v11에서 C등급으로 승격했다(+0.152). 이는 Reranker의 효과가 가장 크게 나타난 영역이다. Semantic 쿼리는 정확한 키워드가 아닌 의미적 유사성에 의존하므로, Cross-encoder 기반의 정밀한 관련성 평가가 중요하다.
버전별 진화를 정리하면 다음과 같다:
- v8: “양으로 밀어붙이기” - 108,000개 청크 무차별 인덱싱
- v9: “품질 정제” - 저품질 청크 제거, 기본 구조화
- v10: “Knowledge Graph 보강” - 엔티티 추출과 관계 구축
- v11: “Reranker로 정밀도 향상” - Post-RRF 재순위로 최종 최적화
5.3 기술적 의의 - 4가지 검증된 패턴
첫째, 4-Way RRF + Reranker 검증이다. Dense 벡터, Sparse 벡터, BM25(Nori 형태소 분석기), Graph 검색을 RRF로 결합하고, BGE-Reranker(ONNX 최적화)로 재순위하는 파이프라인을 한국어 1,437문서, 7도메인 51쿼리에서 체계적으로 평가했다. 이는 학술 논문이나 벤치마크가 아닌, 실제 프로덕션 수준의 시스템에서 검증되었다는 점에서 의미가 크다.
둘째, 3-Phase ETL 확립이다. GPU가 없는 환경에서도 Colab 무료 GPU를 활용하여 대규모 RAG 시스템을 구축할 수 있음을 증명했다. Phase 1은 로컬에서 파싱과 청킹, Phase 2는 Colab GPU에서 임베딩, Phase 3는 다시 로컬에서 엔티티 추출과 그래프 구축이다. 이는 소규모 팀이나 개인 프로젝트에서 현실적으로 적용 가능한 아키텍처다.
셋째, Post-RRF 엔티티 보강이다. RRF 퓨전으로 상위 후보를 선정한 후, chunk_id로 Neo4j의 MENTIONS 관계를 직접 조회하여 검색 재현율을 유지하면서 답변 관련성을 높이는 패턴을 적용했다. 이는 벡터 검색과 그래프 검색의 장점을 단순 결합이 아닌 순차적 보강으로 활용하는 방법이다.
넷째, Reranker의 ROI가 최고다. 코드 변경량 대비 효과가 가장 큰 개선이었다. Context Precision 26%, Recall 42% 향상을 10~20줄의 코드 추가로 달성했다. 이는 많은 RAG 프로젝트에서 Reranker를 “나중에 추가할 수 있는 옵션”으로 생각하지만, 실제로는 “초기부터 필수로 포함해야 하는 컴포넌트”라는 교훈을 준다.
5.4 비용 효율 - DeepSeek V3.2의 파괴력
전체 파이프라인을 DeepSeek V3.2로 약 $52(~75,000원)에 완료했다. 이는 단순히 “저렴하다”는 수준이 아니라, 기존의 상식을 뒤엎는 수준이다.
비교해보면, GPT-4o를 사용했다면 약 $775(15배), Claude Sonnet 4.5는 $1,063(20배), Claude Opus 4.6은 $5,314(102배)가 소요되었을 것으로 추정된다. 특히 Opus 4.6과 비교하면 100배 이상의 차이다.
$52로 무엇을 했는가? 92,209개의 엔티티를 추출하고, 775,366개의 관계를 구축하고, 51개 쿼리로 RAGAS 평가를 수행하고, A- 등급을 달성했다. 이는 DeepSeek V3.2의 비용 효율이 “실험적으로 재미있는 수준”이 아니라 “실용 시스템 구축을 가능하게 하는 수준”임을 의미한다.
물론 DeepSeek V3.2가 모든 면에서 Claude Opus 4.6과 동등하다는 것은 아니다. 복잡한 추론, 긴 컨텍스트 유지, 미묘한 뉘앙스 파악 등에서는 Opus가 여전히 우월하다. 그러나 엔티티 추출, 관계 식별, 질의응답 같은 구조화된 작업에서는 DeepSeek V3.2가 충분한 성능을 보이며, 비용 대비 효율은 압도적이다.
이는 AI 시스템 구축의 경제성을 근본적으로 바꾼다. 과거에는 대규모 RAG 시스템을 구축하려면 수백만 원의 LLM API 비용이 필요했다. 이제는 10만 원 이하로 프로토타입을 넘어 실제 운영 시스템을 구축할 수 있다. 이는 스타트업, 중소기업, 연구자, 개인 개발자에게 엄청난 기회를 열어준다.
6. 결론 및 시사점
본 프로젝트는 Knowledge Graph 기반 하이브리드 검색과 Reranking을 결합한 고급 RAG 시스템을 성공적으로 구축했다. 핵심 교훈은 “양보다 질”, “구조화의 힘”, “하이브리드 접근의 우월성”, “비용 효율의 중요성”으로 요약할 수 있다.
데이터를 무작정 많이 모으는 것이 아니라, 품질을 관리하고 의미 있는 구조로 조직하는 것이 성능을 결정한다. 단일 검색 방법에 의존하지 않고, Dense/Sparse/BM25/Graph를 결합하고 Reranker로 정제하는 것이 강건한 시스템을 만든다. 그리고 이 모든 것을 DeepSeek V3.2 같은 비용 효율적인 LLM으로 구현함으로써, 현실적으로 지속 가능한 시스템을 만들 수 있다.
향후 개선 방향으로는 Answer Relevancy 회복, NONE 쿼리 6건 분석 및 개선, 실시간 엔티티 업데이트 파이프라인 구축, 그리고 사용자 피드백 루프 통합 등이 있다. 그러나 현재 상태로도 프로덕션 환경에 배포하여 실제 사용자에게 가치를 제공할 수 있는 수준에 도달했다.
이 프로젝트는 RAG 시스템 구축에 관심 있는 모든 이들에게 실질적인 참고 사례가 될 것이다. 설계, 구현, 평가, 최적화의 전 과정이 투명하게 문서화되어 있으며, 비용 효율적이면서도 높은 품질을 달성하는 방법을 구체적으로 보여주기 때문이다.
문서 작성 일자: 2026-02-17