요즘 RAG 시스템의 검증/평가 체계에 대해서 업무를 하면서 본부장님이 글을 하나 공유 해줬다. [LINK] 현재 우리가 하고 있는 것과 방향성이 조금 다르지만 습득 할만한 정보였다고 생각한다.
1. RAG 아키텍처 과잉 엔지니어링의 시작과 현실적 문제의식
인공지능 기술이 급격하게 발전하면서 거대 언어 모델(LLM)을 활용한 검색 증강 생성(RAG, Retrieval-Augmented Generation) 시스템은 기업 내 지식 관리와 고객 응대 자동화의 표준적인 아키텍처로 자리를 잡았다.
새로운 프로젝트가 시작될 때마다 많은 엔지니어링 팀은 복잡하고 화려한 기술 스택을 당연한 기본값으로 선택하곤 한다.
문서를 수백 토큰 단위로 잘게 쪼개는 청킹 파이프라인을 구축하고, 다차원 벡터 공간을 탐색하는 벡터 데이터베이스를 도입하며, 수억 개 매개변수를 지닌 최신 덴스(Dense) 임베딩 모델과 교차 인코더 기반의 리랭커(Cross-Encoder Reranker)를 결합한 복잡한 다단계 구조를 설계하는 것이다.
이러한 접근 방식은 기술적으로 매우 세련되어 보이며, 학계 논문이나 주요 AI 벤더사의 튜토리얼 문서에서 제시하는 최첨단 권장 사항과도 정확히 일치한다.
그러나 수개월에 걸친 개발과 인프라 구축 끝에 실제 프로덕션 환경에 배포된 시스템은 종종 예상치 못한 거대한 장벽에 부딪힌다.
막대한 GPU 인프라 유지 비용이 매달 청구되고, 사용자가 질문을 던진 후 답변을 받기까지 수십 초가 소요되는 심각한 지연 시간(Latency)이 발생한다. 더 큰 문제는 이러한 막대한 자원을 쏟아부었음에도 불구하고 실제 비즈니스 도메인에서 발생하는 고유명사나 모델명, 정확한 규격 번호, 청구서 번호 같은 단순한 키워드 질의조차 제대로 회수하지 못해 엉뚱한 답변을 생성하거나 치명적인 환각(Hallucination) 현상을 일으킨다는 점이다.
우리는 흔히 가장 발전된 형태의 인공지능 모델이 이전 세대의 전통적인 검색 기술보다 모든 면에서 우월할 것이라는 환상에 빠지기 쉽다.
최신 딥러닝 기반 임베딩 모델은 문장의 의미론적 맥락과 인간 언어의 뉘앙스를 파악하는 데 탁월한 능력을 발휘하지만, 데이터베이스 내부의 고유한 도메인 용어나 엄격한 철자 일치가 요구되는 상황에서는 오히려 취약한 모습을 드러낸다.
정작 해결해야 할 비즈니스 문제의 60% 이상은 아주 단순한 수준의 검색 파이프라인으로도 충분히 풀 수 있음에도 불구하고, 많은 팀이 상위 5%의 극단적인 특수 사례에나 적합한 고비용 아키텍처를 처음부터 무리하게 도입하고 있는 셈이다.
이러한 문제의식을 명확하게 정립하지 않고 무작정 고도화된 파이프라인을 구축하는 것은 전형적인 오버엔지니어링(Over-engineering)의 함정에 빠지는 지름길이다.
최근 글로벌 개발자 커뮤니티와 해커뉴스(Hacker News) 등에서 뜨거운 논쟁을 불러일으킨 RAG 파이프라인의 현실적 복잡도 단계와 실제 현업 엔지니어들이 지적하는 구조적 한계점을 가감 없이 분석한다. 이론적으로 제시되는 검색 단계별 아키텍처를 하나씩 해부하고, 왜 실무에서는 전통적인 정보 검색(Information Retrieval)의 원칙과 데이터 전처리 작업이 화려한 벡터 데이터베이스보다 더 높은 성공 확률을 보장하는지 그 본질적인 이유를 체계적으로 고찰해보고자 한다.
2. RAG 아키텍처를 결정하는 5가지 핵심 비즈니스 평가 기준
시스템을 설계할 때 가장 먼저 선행되어야 하는 작업은 기술적 유행을 따르는 것이 아니라, 다루고자 하는 비즈니스 데이터의 속성과 실제 사용자들의 접근 행동 패턴을 정량적으로 측정하고 분류하는 일이다. 올바른 RAG 아키텍처를 선택하기 위해서는 다음과 같은 다섯 가지 평가 기준을 면밀하게 검토해야 한다.
ㄱ. 데이터 신선도와 재색인 주기
데이터가 얼마나 자주 변경되고 갱신되는지는 검색 아키텍처의 색인 방식을 결정하는 가장 결정적인 요인이다.
매 초마다 실시간 트윗이나 금융 속보가 인입되는 소셜 미디어 및 뉴스 플랫폼의 경우, 문서가 변경될 때마다 수백만 개의 토큰을 다시 계산하여 벡터 DB에 밀어 넣는 방식은 막대한 연산 비용과 파이프라인 지연을 초래한다.
이러한 환경에서는 텍스트 역색인(Inverted Index)을 빠르게 갱신할 수 있는 전통적인 전문 검색 엔진이 훨씬 유리하다. 반면, 사내 사규나 규정집, 제품 사용 설명서처럼 월 단위나 분기 단위로만 드물게 개정되는 정적인 코퍼스(Corpus)라면 사전에 대량의 임베딩을 계산해 두고 캐싱하는 방식이 운영상 타당성을 갖는다.
ㄴ. 말뭉치 변경률과 접근 분포의 롱테일 현상
전체 코퍼스 중에서 실제로 사용자의 조회를 받는 문서의 비율이 어느 정도인지를 파악해야 한다.
현실 세계의 많은 기업 데이터베이스는 소수의 인기 문서(20%)가 전체 트래픽의 대다수(80%)를 차지하는 파레토(Pareto) 분포나 멱법칙을 따른다. 만약 문서의 90%가 수개월 동안 단 한 번도 조회되지 않는 긴 꼬리(Long-tail) 형태의 접근 패턴을 보이고, 동시에 전체 문서의 10% 이상이 매일 빈번하게 수정된다면 모든 문서를 사전에 벡터화하여 보관하는 것은 극심한 자원 낭비에 해당한다.
조회 빈도가 극히 낮은 문서는 요청이 발생하는 순간에만 임베딩을 계산하거나 단순 키워드 매칭으로 우회하는 전략이 비용 대비 효율적이다.
ㄷ. 사용자 질의의 언어적 패턴
서비스를 이용하는 실제 사용자들의 입력 질의가 어떤 형태로 유입되는지 로그 데이터를 정밀하게 전수 조사해야 한다.
개발자들이 주로 찾는 에러 코드, 부품 번호, 함수명, API 파라미터와 같은 질의는 문맥적 의미보다 토큰의 정확한 일치가 핵심이다.
이러한 환경에서는 밀집 임베딩보다 BM25 기반의 희소(Sparse) 검색이 압도적인 정확도를 발휘한다.
반면에 “지난 분기 마케팅 전략과 유사한 사례를 찾아줘”와 같이 추상적이고 서술적인 질문이 주를 이룬다면 의미론적 벡터 검색이 개입할 여지가 커진다. 대다수의 실제 서비스는 두 가지 질의 형태가 혼재되어 유입되므로, 각 질의의 특성에 맞춰 검색 경로를 분기하는 라우팅 전략이 필수적이다.
ㄹ. 트래픽 규모와 지연 시간(SLA) 허용도
하루에 처리해야 하는 검색 요청의 총량과 사용자가 체감할 수 있는 응답 속도의 임계값(Service Level Agreement)을 계산해야 한다.
일일 질의량이 1,000건 미만인 소규모 내부 도구라면 아키텍처를 극단적으로 단순화하여 운영 복잡도를 낮추는 것이 최선이다.
그러나 초당 수십 건 이상의 트래픽이 몰리는 대규모 대고객 서비스에서 사용자의 클릭 전환율을 유지하기 위해서는 P95 기준 수백 밀리초(ms) 이내의 즉각적인 응답 속도가 보장되어야 한다.
이러한 환경에서는 무거운 신경망 모델을 여러 번 호출하는 체인 구조가 심각한 병목 현상을 유발하므로, 인프라 비용과 응답 속도 사이의 철저한 기회비용 계산이 수반되어야 한다.
ㅁ. 엔지니어링 조직의 머신러닝 운영 역량(MLOps)
시스템을 구축하는 것과 이를 장애 없이 연중무휴로 운영하고 유지보수하는 것은 완전히 다른 차원의 문제이다.
팀 내에 전담 머신러닝 엔지니어나 MLOps 파이프라인 관리 경험이 부족한 상황에서 벡터 데이터베이스 클러스터, 분산 임베딩 워커, 복잡한 재순위화 모델을 성급하게 도입하면 필연적으로 운영 부채가 누적된다.
모델의 버전 업데이트 시점마다 발생하는 데이터 정합성 문제, 벡터 인덱스의 메모리 누수, 모니터링 체계의 부재는 고스란히 서비스 장애로 이어진다. 팀의 기술적 성숙도에 맞는 가장 단순한 도구부터 시작하여 점진적으로 고도화하는 것이 장기적인 소프트웨어 공학 관점에서 올바른 선택이다.
3. RAG 아키텍처의 6단계 점진적 진화 과정
단순한 구조에서부터 초대규모 분산 환경에 이르기까지, RAG 파이프라인이 발전해 나가는 6가지 대표적인 기술적 스텝을 구조적으로 정리하면 다음과 같다.
[Level 1: BM25 / 전문 검색]
│ (어휘 불일치, 동의어 문제 발생 시)
▼
[Level 2: 에이전트형 질의 재작성]
│ (추상적 의미 검색 한계 도달 시)
▼
[Level 3: 희소 + 밀집 하이브리드 재순위화]
│ (일일 문서 변경률 10% 초과 시)
▼
[Level 4: 요청 시 실시간 임베딩 (On-Demand)]
│ (80/20 트래픽 편중 및 비용 최적화 필요 시)
▼
[Level 5: 핫/콜드 계층화 사전 임베딩]
│ (일 1만 건 초과 대규모 트래픽 및 정적 코퍼스)
▼
[Level 6: 전체 사전 임베딩 및 고속 ANN 클러스터]
ㄱ. BM25 기반의 전문 검색 (Full-Text Search)
가장 기초적이면서도 강력한 첫 번째 MVP는 외부 머신러닝 모델이나 벡터 DB를 전혀 사용하지 않는 순수 텍스트 검색 방식이다. PostgreSQL의 기본 텍스트 검색 모듈이나 Elasticsearch, OpenSearch의 BM25 알고리즘을 활용하여 원본 문서의 텍스트 토큰 빈도와 역문서 빈도를 바탕으로 순위를 매긴다.
- 적합한 환경: 신규 검색 시스템을 처음 구축하는 단계, 송장 번호나 로그 ID 등 엄격한 키워드 매칭이 중요한 경우, 사내 전문 용어가 지배적인 환경.
- 비용과 지연 시간: 외부 API 호출 비용이 전혀 발생하지 않으며, P95 기준 지연 시간이 10ms 미만으로 극도로 빠르다.
- 장점: 청킹 크기나 중첩률을 고민할 필요 없이 문서 전체를 안전하게 색인할 수 있으며, 특정 단어가 매칭된 이유를 역색인 테이블을 통해 명확하게 추적할 수 있어 디버깅이 직관적이다. 모델 지원 종료나 파라미터 변경에 따른 마이그레이션 리스크가 전혀 없다.
- 단점: 자동차를 뜻하는 ‘car’와 ‘automobile’처럼 형태가 다른 동의어를 자체적으로 인지하지 못하며, 사용자의 모호한 서술형 질문에 담긴 숨은 의도를 파악할 수 없다.
ㄴ. 에이전트형 질의 재작성 (Agentic Query Rewriting)
사용자가 입력한 모호하거나 구어체 형태의 문장을 경량 거대 언어 모델이 중간에서 가로채 검색 엔진이 소화하기 좋은 정밀한 키워드 쿼리로 변환한 뒤 1단계의 BM25 검색을 수행하는 구조이다. 상당수 검색 실패의 본질적인 원인이 검색 엔진의 성능 부족이 아니라, 사용자가 검색어를 불완전하게 구성했기 때문에 발생한다는 점에 착안한 방식이다.
- 적합한 환경: 사용자가 일상적인 대화체로 질문을 입력하는 고객센터 챗봇 환경, 사용자의 일상 용어와 사내 공식 기술 문서 간의 어휘 간극이 큰 경우.
- 비용과 지연 시간: 소형 언어 모델을 활용할 경우 질의당 약 $0.001 내외의 매우 저렴한 비용이 발생하며, 지연 시간은 약 100~200ms 수준이다.
- 동작 원리: 시스템 프롬프트에 사내 용어집을 주입하여 “우리 서비스의 배치 작업 프레임워크는 Atlas이다”라는 지식을 미리 정의해 둔다. 사용자가 “배치 돌릴 때 쓰는 프레임워크 사용법 알려줘”라고 물으면, LLM이 이를 “Atlas 배치 작업 실행 가이드라인 파이프라인”과 같이 명확한 명사 나열형 키워드로 재작성하여 BM25 엔진으로 전달한다.
- 장점: 전체 코퍼스를 다시 색인하거나 임베딩을 다시 뽑아낼 필요가 전혀 없이, 오직 시스템 프롬프트의 지침을 수정하는 것만으로도 검색 정확도를 드라마틱하게 개선할 수 있다.
ㄷ. 희소 검색과 밀집 재순위화를 결합한 하이브리드 검색
BM25를 활용하여 광범위한 문서 집합에서 상위 50~100개의 후보군을 1차적으로 고속 필터링한 후, 이 소수의 후보군에 대해서만 교차 인코더나 최신 임베딩 모델을 적용하여 의미적 유사도를 바탕으로 최종 상위 10개를 골라내는 구조이다.
- 적합한 환경: 키워드 일치와 의미론적 문맥 파악이 동시에 요구되는 엔터프라이즈 포털, BM25 단독으로는 회수율(Recall)의 한계가 명확히 입증된 시스템.
- 비용과 지연 시간: 상위 소수 후보에 대해서만 딥러닝 연산을 수행하므로 전수 조사 대비 토큰 비용을 대폭 아낄 수 있으나, 모델 연산 시간으로 인해 검색 파이프라인에 약 150~400ms의 지연 시간이 추가된다.
- 장점: 키워드 누락 없는 정확한 회수율과 문맥을 이해하는 고차원 정렬 품질을 동시에 달성할 수 있어 현대 검색 시스템에서 가장 안정적인 표준으로 평가받는다.
ㄹ. 신선한 데이터를 위한 요청 시 실시간 임베딩 (On-Demand Embedding)
전체 데이터베이스를 사전에 임베딩하여 벡터 DB에 영구 적재해 두지 않고, 사용자의 검색 요청이 발생했을 때 BM25가 긁어모은 상위 20~50개의 문서 조각만을 실시간으로 외부 임베딩 API에 전송하여 유사도 점수를 동적으로 계산하는 방식이다.
- 적합한 환경: 매시간 뉴스가 쏟아지거나 소셜 미디어 피드처럼 문서의 갱신 주기와 삭제 주기가 극단적으로 빠른 환경.
- 비용과 지연 시간: 별도의 대용량 벡터 DB를 상시 프로비저닝할 필요가 없으므로 저장소 유지비는 $0에 수렴하지만, 검색 요청마다 외부 네트워크 통신과 모델 인퍼런스가 발생하여 200~500ms의 사용자 지연 시간이 발생한다.
- 장점: 임베딩 모델 공급사가 구형 모델을 중단하고 신형 모델을 출시하더라도, 기존에 쌓아둔 수백만 건의 데이터를 재임베딩하는 마이그레이션 고통 없이 API 파라미터 한 줄만 바꾸어 즉시 신형 모델을 도입할 수 있다.
ㅁ. 핫/콜드 계층화 사전 임베딩 (Tiered Architecture)
문서의 접근 빈도를 정밀하게 추적하여, 상위 20%의 핵심 자주 찾는 문서는 ‘핫(Hot)’ 계층에 배치해 사전에 임베딩을 생성하여 인메모리 벡터 DB에 상주시킨다.
반면 거의 조회되지 않는 나머지 80%의 문서는 ‘콜드(Cold)’ 계층의 일반 RDB에 텍스트 상태로 보관하다가 필요 시에만 선별적으로 조회하는 이원화 아키텍처이다.
- 적합한 환경: 문서 규모가 수십만 건 이상으로 거대하면서도 명확한 파레토 트래픽 집중 현상이 관측되는 중대형 서비스.
- 운영 메커니즘: 사용자의 쿼리가 유입되면 BM25로 후보군을 추린 뒤, 해당 문서가 핫 계층에 존재하면 캐시된 고속 벡터를 조회하고, 콜드 계층에 속해 있다면 즉석에서 계산하여 종합 순위를 도출한다. 주기적인 백그라운드 배치가 문서별 접근 카운트를 분석하여 승격과 강등을 자동으로 조율한다.
- 장점: 비용 절감 효과와 빠른 응답 속도 사이에서 가장 최적화된 기계적 균형점을 제공하며, 모델 교체 시에도 전체 데이터가 아닌 핫 계층의 소량 데이터만 재작업하면 되므로 시스템 다운타임을 최소화할 수 있다.
ㅂ. 초대규모 분산 처리를 위한 전체 사전 임베딩
코퍼스에 존재하는 수백만에서 수천만 건의 모든 문서를 완벽하게 전처리하여 사전에 고정된 임베딩 벡터로 변환하고, 이를 Milvus, Pinecone, Qdrant 등 전용 벡터 데이터베이스의 HNSW(Hierarchical Navigable Small World) 인덱스에 밀어 넣은 뒤 근사 최근접 이웃(ANN) 검색을 수행하는 대규모 엔터프라이즈 구조이다.
- 적합한 환경: 하루 검색 질의가 최소 수만 건 이상 대량으로 발생하고, 문서의 내용 변경률이 월 5% 미만으로 극도로 안정적이며, 50ms 미만의 극초고속 응답 속도가 필수적인 플랫폼.
- 비용과 지연 시간: 초기 수천만 건의 문서를 임베딩하는 데 막대한 1회성 컴퓨팅 비용이 들고 고가의 고용량 메모리 벡터 DB 인프라 유지비가 매달 청구되지만, 쿼리 처리 시점의 검색 지연 시간은 수십 밀리초 단위로 극히 짧아진다.
- 운영 리스크: 한 번 정착된 청킹 규칙이나 임베딩 모델을 변경하기가 극도로 어렵다. 만약 새로운 도메인 특화 모델로 교체하고자 할 경우, 전체 데이터를 처음부터 다시 쪼개고 임베딩하여 수일에서 수주에 걸친 재인덱싱 파이프라인과 회귀 테스트를 감당해야 한다.
4. 해커뉴스(HN) 실무 엔지니어들이 지적하는 아키텍처의 허와 실
단계별 이론적 청사진이 공개되었을 때, 실리콘밸리를 비롯한 글로벌 현업 엔지니어들이 모인 해커뉴스 커뮤니티에서는 이론과 실제 사이의 괴리를 꼬집는 날카로운 반론들이 쏟아져 나왔다.
첫 번째 쟁점: “요청 시 실시간 임베딩”에 대한 비판과 지연 시간의 비현실성
원문 아티클에서 제시한 ‘요청 시 실시간 임베딩’ 방식에 대해 수많은 실무자는 강한 회의감을 드러냈다. 실시간 서비스 환경에서 단일 질의 처리를 위해 300ms에서 500ms에 달하는 추가적인 모델 인퍼런스 지연 시간을 사용자에게 고스란히 전가하는 것은 현대 웹 검색의 사용자 경험(UX) 측면에서 치명적인 결함이라는 지적이다.
숙련된 데이터 엔지니어들은 자주 바뀌는 데이터를 처리하기 위해 굳이 쿼리 타임에 부하를 집중시킬 이유가 없다고 강조한다. 데이터베이스의 변경 데이터 캡처(CDC, Change Data Capture) 스트림을 구축하거나 Kafka와 같은 메시지 큐를 활용하여 비동기식 백그라운드 워커가 변경된 문서 조각만을 수 초 내로 감지하고 재임베딩하여 인덱스를 갱신하는 것이 시스템의 안정성과 지연 시간 방어 관점에서 훨씬 우월한 표준 엔지니어링 패턴이라는 것이다. 즉, 해당 방식은 AI 모델과의 대화 속에서 탄생한 비현실적인 타협안에 가깝다는 냉정한 비판을 받았다.
두 번째 쟁점: RAG의 본질은 마법이 아닌 “전통적 정보 검색(IR)과 데이터 파이프라인”
많은 개발팀이 벡터 데이터베이스를 마치 아무런 전처리 노력 없이도 모든 검색 품질을 기적처럼 끌어올려 주는 ‘은총알(Silver Bullet)’로 착각하는 경향이 있다.
그러나 실제 프로덕션 레벨에서 대규모 RAG 시스템을 성공적으로 론칭한 엔지니어들의 공통된 증언은 정반대였다.
검색 시스템의 최종 품질을 결정짓는 80% 이상의 요인은 고차원 벡터 수학이나 최신 모델의 파라미터 수가 아니라, 매우 지루하고 고통스러운 데이터 엔지니어링 작업에서 판가름 난다.
즉, 원본 데이터에서 불필요한 노이즈를 걷어내는 ETL 전처리, 불용어 처리, 정확한 형태소 및 토큰 필터링, 정교한 동의어 사전 구축, 그리고 마케팅 페이지의 검색 엔진 최적화(SEO)처럼 문서 자체를 인공지능이 쉽게 소비할 수 있도록 계층적 구조(제목, 표, 메타데이터)를 명확히 정돈하는 작업이 선행되지 않으면 그 어떤 최첨단 벡터 검색 엔진도 쓰레기 데이터를 입력받아 쓰레기 결과를 반환할 뿐이라는 지적이다.
세 번째 쟁점: 정형 데이터와 엄격한 규제 도메인에서의 벡터 검색 무용론
금융 거래 내역, 보험 청구서, 제품 가격표, 코드베이스와 같이 엄격한 사실 정합성이 요구되는 도메인에서는 확률론적으로 가장 그럴듯한 벡터를 탐색하는 밀집 검색이 오히려 심각한 운영 위험을 초래한다.
실제 코드 검색 플랫폼인 TheGitAI의 실무 엔지니어는 흥미로운 프로덕션 사례를 공유했다. 코드 저장소 검색 파이프라인에서 기술적인 버그로 인해 장기간 벡터 검색 모듈이 완전히 다운되어 결과를 전혀 반환하지 못하고 있었음에도 불구하고, 수많은 사용자 중 그 누구도 문제를 눈치채지 못했다는 것이다.
오히려 소프트웨어 코드베이스는 파일 경로, 모듈의 import 구문, 명확한 함수 호출 그래프, 그리고 유닉스의 grep과 같은 엄격한 키워드 필터링 도구를 통해 조회할 때 훨씬 저렴하고 정확한 결과를 내놓았다.
동일한 논리가 숫자와 가격 정책을 다루는 엔터프라이즈 시스템에도 그대로 적용된다. 숫자가 조금이라도 틀리면 법적 제재를 받는 규제 산업에서는 모호한 코사인 유사도에 의존하기보다, LLM의 도구 활용(Tool Use) 기능을 통해 정형 데이터베이스(SQL)를 결정론적으로 직접 조회하게 만드는 파이프라인이 훨씬 안전하고 견고하다.
네 번째 쟁점: 양산형 AI 아티클에 대한 피로감과 본질의 망각
커뮤니티의 또 다른 냉소적인 반응은 글의 형식 자체에 쏠렸다.
“질의 재작성에 무조건 GPT-4o-mini를 써라”와 같은 식의 천편일률적인 제안은 실무적 깊이 없이 프롬프트 엔지니어링 튜토리얼을 그대로 복사해 붙여넣은 인공지능 생성물 특유의 냄새를 풍긴다는 것이다.
아이디어 A와 B를 기계적으로 섞어 실무에서는 아무도 쓰지 않는 어설픈 하이브리드 개념을 그럴듯하게 포장하는 AI 블라인드 현상에 대한 비판은, 엔지니어가 외부의 프레임워크나 성공 공식이라는 화려한 수식어를 대할 때 얼마나 비판적인 검증 태도를 견지해야 하는지를 잘 보여준다.
5. 60%의 현실적인 문제에 5%짜리 거대한 구조를 낭비하지 않는 법
검색 증강 생성 시스템을 설계하는 모든 소프트웨어 아키텍트와 엔지니어가 가슴 깊이 새겨야 할 단 하나의 철칙은 “데이터가 증명하지 않은 복잡성은 전부 기술 부채”라는 점이다.
전체 비즈니스 문제의 60%는 아주 단순한 BM25 기반의 키워드 검색과 정교한 동의어 사전, 그리고 필요한 경우 경량 모델을 통한 질의 재작성만으로도 충분히 목표 품질을 달성할 수 있다.
여기에 25% 정도의 시스템만이 희소 검색과 밀집 검색을 결합한 하이브리드 구조를 요구하며, 전수 사전 임베딩이나 거대한 고속 ANN 인프라가 진정으로 필요한 영역은 대규모 트래픽과 안정된 데이터를 가진 상위 10% 미만의 특수한 기업들에 불과하다.
따라서 새로운 RAG 파이프라인을 구축할 때 가장 먼저 해야 할 일은 고가의 벡터 DB 인프라를 프로비저닝하는 것이 아니다.
먼저 가장 가볍고 디버깅이 쉬운 전문 검색 엔진으로 최소 기능 제품(MVP)을 배포하고, 실제 사용자들이 던지는 질의 패턴과 검색 실패 로그를 2주에서 4주간 집요하게 추적 및 관찰해야 한다.
실패한 질의들을 뜯어보았을 때 사용자의 오타나 전문 용어 불일치가 원인이라면 질의 재작성기나 형태소 사전을 보강하는 것이 올바른 해법이다. 이러한 저비용 개선 작업을 거친 후에도 의미론적 맥락이 닿지 않아 문서를 찾지 못한다는 명확한 실측 벤치마크 데이터가 확보되었을 때 비로소 하이브리드 검색이나 임베딩 모델의 도입을 정당화할 수 있다.
기술의 가치는 그것이 얼마나 복잡하고 세련되었는가가 아니라, 당면한 비즈니스 문제를 얼마나 적은 비용과 간결한 구조로 단단하게 해결해 내는가에 달려 있다. 60%짜리 단순한 문제에 상위 5%를 위한 거대한 루브 골드버그 장치(Rube Goldberg Machine)를 얹어 팀과 인프라를 지치게 만드는 우를 범하지 말아야 한다.
이어지는 시리즈 2편에서는 이러한 개념적 원칙을 바탕으로,
실제 프로덕션 환경(일본어 고객센터 도메인)에서 겪었던 뼈아픈 검색 실패 사례들과 토크나이저 튜닝, 표/수치 데이터의 정형 라우팅 대조군 실험, 그리고 서빙 지연 시간과 비용을 종합적으로 통제하는 실전 RAG 평가 체계 표준을 구체적인 실측 수치와 함께 공개할 예정이다.