[Hacker News 요약] RAG 스택, 복잡하게 생각할 필요 없이 단계별로 구축하기
0
설명
최근 생성형 AI 시스템 구축 시 검색 증강 생성(RAG) 스택을 과도하게 복잡하게 설계하는 경향이 있습니다.
하지만 사용자들은 단순히 "비밀번호 재설정 방법"과 같은 문서를 찾고 싶어 할 뿐입니다.
이 글에서는 RAG를 단순하게 시작하여 필요에 따라 점진적으로 발전시키는 6가지 접근 방식을 소개합니다.
### 배경 설명
검색 증강 생성(RAG)은 대규모 언어 모델(LLM)이 외부 지식 소스를 참조하여 더 정확하고 관련성 높은 답변을 생성하도록 하는 기술입니다. 최근 몇 년간 LLM의 발전과 함께 RAG는 정보 검색, 질의응답, 콘텐츠 생성 등 다양한 분야에서 핵심적인 역할을 수행하고 있습니다. 특히, LLM이 학습 데이터에 포함되지 않은 최신 정보나 특정 도메인 지식을 활용해야 할 때 RAG의 중요성은 더욱 커집니다. 하지만 많은 개발자들이 RAG 시스템을 구축할 때 임베딩, 벡터 데이터베이스, 재순위화 파이프라인 등 복잡한 기술 스택을 처음부터 도입하려는 경향이 있습니다. 이는 불필요한 개발 시간과 비용을 초래할 뿐만 아니라, 실제 사용자 요구사항과 동떨어진 복잡한 시스템을 만들 수 있습니다. 이 글은 이러한 과잉 설계를 지양하고, 문제의 복잡성에 맞춰 RAG 스택을 단계적으로 구축하는 실용적인 접근 방식을 제시합니다.
### RAG 스택 구축 시 고려해야 할 핵심 요인
RAG 스택을 설계할 때 어떤 접근 방식을 선택할지는 몇 가지 핵심 요인에 따라 달라집니다. 첫째, **데이터 신선도 요구사항**입니다. 실시간 업데이트가 필요한 뉴스나 소셜 미디어 데이터는 빠른 재색인(re-indexing)이 가능한 접근 방식을 선호합니다. 일별 또는 주별 업데이트는 하이브리드 접근 방식이 적합하며, 월별 또는 분기별 업데이트가 이루어지는 안정적인 코퍼스는 사전 임베딩이 효율적입니다. 둘째, **코퍼스 특성**입니다. 매일 10% 이상 변경되는 높은 변경률(churn)을 가진 코퍼스는 전체 사전 임베딩을 피해야 합니다. 안정적인 문서는 사전 임베딩에 적합하며, 90%가 거의 접근되지 않는 롱테일 분포를 가진 코퍼스는 온디맨드(on-the-fly) 방식이 유리합니다. 셋째, **쿼리 패턴**입니다. 키워드 중심의 쿼리는 전문 검색(full-text search)으로 시작하는 것이 좋고, 의미론적 또는 대화형 쿼리는 임베딩이 효과적입니다. 혼합된 패턴에는 하이브리드 접근 방식이 필요합니다. 넷째, **규모 및 성능**입니다. 하루 1,000개 미만의 쿼리는 단순한 접근 방식으로 충분하며, 1,000~10,000개는 선택적 최적화, 10,000개 이상은 전면적인 최적화가 필요합니다. 마지막으로 **팀 역량**입니다. 머신러닝 전문 지식이 없다면 전문 검색과 쿼리 재작성으로 시작하고, 일부 경험이 있다면 하이브리드 검색, ML 팀이 있다면 고급 접근 방식이 가능합니다.
### 단계별 RAG 구축 레시피: MVP부터 고급까지
RAG 스택 구축은 가장 단순한 방법부터 시작하여 데이터가 필요성을 증명할 때 점진적으로 복잡성을 더해가는 것이 좋습니다.
**레시피 1: MVP - 전문 검색(Full-Text Search)만 사용**
가장 기본적인 접근 방식으로, Elasticsearch나 PostgreSQL의 전문 검색 기능을 활용합니다. 임베딩이나 ML 복잡성 없이 키워드 기반 쿼리에 효과적이며, API 비용이 없고 응답 속도가 빠릅니다. 특히 고유 용어가 많은 코퍼스에 유리합니다. 단점은 동의어 처리나 의미론적 이해가 어렵다는 것입니다. 하지만 많은 경우 이 방법만으로도 충분한 성능을 낼 수 있습니다.
**레시피 2: 에이전트 기반 쿼리 재작성(Agentic Query Rewriting)**
LLM을 사용하여 사용자의 불분명한 쿼리를 명확한 키워드 검색어로 변환합니다. 이는 "의미론적 검색" 문제의 상당 부분이 쿼리 구성 문제임을 해결합니다. 예를 들어, "Atlas"라는 내부 프레임워크 용어를 LLM이 "Atlas 데이터 처리 파이프라인"과 같이 정확한 키워드로 변환하여 전문 검색의 정확도를 높입니다. 이는 임베딩 기반 방식보다 유연하며, 시스템 프롬프트 수정만으로 빠르게 반복 테스트가 가능합니다. GPT-4o-mini를 사용 시 쿼리당 약 0.001달러의 비용이 발생합니다.
**레시피 3: 하이브리드 검색 (희소 + 밀집 재순위화)**
전문 검색으로 상위 50-100개의 후보를 가져온 후, 임베딩을 사용하여 상위 10개를 재순위화합니다. 이는 전문 검색의 키워드 매칭 능력과 임베딩의 의미론적 이해 능력을 결합하여 서로의 약점을 보완합니다. 사용자 쿼리가 의미론적이고, 전문 검색 및 쿼리 재작성만으로는 부족할 때, 그리고 100-500ms의 지연 시간을 감내할 수 있을 때 유용합니다. 임베딩 비용은 쿼리당 약 0.0005달러 수준이지만, 온디맨드 임베딩 시 지연 시간이 늘어나는 점을 고려해야 합니다. 문서 분할(chunking) 전략이 다시 중요해집니다.
**레시피 4: 온디맨드 임베딩 (신선한 데이터)**
데이터 변경이 잦은 경우(일일 10% 이상), 매번 모든 데이터를 재임베딩하는 대신 쿼리 시점에 필요한 문서를 임베딩합니다. 뉴스, 소셜 미디어 등 실시간 콘텐츠나 임베딩 모델 실험 시 유용합니다. 데이터 신선도가 매우 중요할 때 적합하며, 모델 변경 시 코드 한 줄만 수정하면 되므로 매우 유연합니다. 단점은 쿼리당 200-500ms의 지연 시간이 발생한다는 것입니다.
**레시피 5: 사전 임베딩과 핫/콜드 티어 (Hot/Cold Tiers)**
자주 접근되는 문서(핫 티어)는 사전 임베딩하고, 드물게 접근되는 문서(콜드 티어)는 온디맨드 임베딩하는 방식입니다. 파레토 법칙(20%의 문서가 80%의 트래픽을 처리)을 활용하여 자주 사용되는 문서에 대한 응답 속도를 높입니다. 10만 개 이상의 중간 규모 코퍼스에서 명확한 접근 패턴이 있을 때 적합하며, 모델 변경 시 핫 티어만 재임베딩하면 되므로 비용과 시간을 절약할 수 있습니다. 이는 지연 시간, 비용, 유연성 간의 최적의 균형을 제공합니다.
**레시피 6: 전체 사전 임베딩 (대규모 플레이)**
모든 문서를 사전에 임베딩하여 벡터 데이터베이스에 저장하고 근사 최근접 이웃(ANN) 검색을 사용하는 방식입니다. 하루 10,000개 이상의 매우 높은 쿼리 볼륨과 50ms 미만의 지연 시간이 필요하며, 코퍼스가 매우 안정적일 때(월 5% 미만 변경) 사용됩니다. Pinterest, Shopify와 같이 대규모 데이터를 처리하는 경우에 해당합니다. 하지만 모델 변경 시 수백만 개의 문서를 재임베딩해야 하는 막대한 비용과 시간, 다운타임이 발생할 수 있어 대부분의 시스템에는 과도합니다.
### 복합 의도 쿼리 처리 및 의사 결정 트리
사용자들은 종종 "CSV 파일을 읽고, 누락된 데이터를 정리하고, 결과를 플롯하는 방법"과 같이 여러 의도를 가진 복합 쿼리를 입력합니다. Perplexity나 ChatGPT와 같은 최신 에이전트 RAG 시스템은 이를 효과적으로 처리합니다. 쿼리 이해 에이전트가 복합 쿼리를 여러 개의 하위 쿼리로 분해하고, 각 하위 쿼리를 최적의 방식으로(예: 단순 쿼리는 전문 검색, 복잡한 쿼리는 LLM 재작성 후 검색) 병렬로 처리하여 최종 결과를 종합합니다. 이 방식은 비용을 15배 절감하면서도 더 나은 품질의 결과를 제공합니다.
RAG 스택 구축 시 **의사 결정 트리**를 따르는 것이 중요합니다. 먼저 검색 시스템이 있는지 확인하고, 없다면 전문 검색부터 구축합니다. 현재 검색 시스템의 사용자 피드백을 수집하여 만족도를 평가합니다. 불만족 시, "문서가 분명히 있는데 찾기 어렵다"는 피드백에는 쿼리 재작성을, "결과는 괜찮지만 완벽하지 않다"는 피드백에는 하이브리드 검색을 고려합니다. 하이브리드 검색 시 데이터 변경 빈도, 코퍼스 규모, 안정성 등을 고려하여 온디맨드 임베딩, 핫/콜드 티어, 또는 전체 사전 임베딩을 선택합니다. "더 나은 의미론적 이해가 필요하다"는 피드백에도 마찬가지로 하이브리드 검색을 적용합니다. 핵심은 60%의 시스템은 전문 검색과 쿼리 재작성으로 충분하며, 25%는 하이브리드, 10%는 전체 사전 임베딩, 5%는 맞춤형 솔루션이 필요하다는 80/20 규칙을 이해하고, 60%의 문제를 5% 솔루션으로 해결하려 하지 않는 것입니다.
### 가치와 인사이트
이 글은 RAG 시스템 구축 시 흔히 발생하는 과잉 설계를 경계하고, 문제의 복잡성에 맞춰 단계적으로 접근하는 실용적인 방법론을 제시합니다. 개발자는 전문 검색(BM25)부터 시작하여 사용자 피드백과 데이터 특성에 따라 쿼리 재작성, 하이브리드 검색, 온디맨드 임베딩, 핫/콜드 티어, 그리고 최종적으로 전체 사전 임베딩까지 점진적으로 복잡성을 더해갈 수 있습니다. 특히, 고유 용어 처리, 데이터 변경 빈도, 쿼리 패턴, 규모 및 팀 역량 등 구체적인 의사 결정 요인을 제시하여 실무 적용 가능성을 높였습니다. 또한, 복합 의도 쿼리 처리 방식을 설명하며 최신 에이전트 RAG 시스템의 효율성을 보여줍니다. 이 접근 방식은 개발 시간과 비용을 절감하고, 실제 사용자 요구에 부합하는 효율적인 RAG 시스템을 구축하는 데 도움을 줄 것입니다.
### 기술·메타
- 전문 검색 (BM25, Elasticsearch, PostgreSQL)
- LLM 기반 쿼리 재작성 (GPT-4o-mini)
- 임베딩 모델 (OpenAI text-embedding-3-small)
- 벡터 데이터베이스 (ANN 검색)
- Python (예시 코드)
### 향후 전망
RAG 기술은 LLM의 발전과 함께 계속 진화할 것입니다. 향후에는 더욱 정교한 쿼리 이해 및 분해 기술, 실시간 데이터 처리 능력 강화, 그리고 다양한 데이터 소스를 통합하는 능력이 중요해질 것입니다. 또한, 임베딩 모델의 지속적인 업데이트와 최적화는 RAG 시스템의 성능에 큰 영향을 미칠 것이며, 모델 변경 시 발생하는 비용과 복잡성을 최소화하는 전략이 더욱 중요해질 것입니다. 경쟁 측면에서는 OpenAI, Google, Anthropic 등 주요 AI 기업들이 자체 RAG 솔루션을 강화하고 있으며, 오픈소스 커뮤니티에서는 LangChain, LlamaIndex와 같은 프레임워크를 중심으로 RAG 구축의 편의성과 효율성을 높이는 노력이 계속될 것입니다. 개발자는 이러한 기술 동향과 커뮤니티의 발전을 주시하며 자신의 RAG 시스템을 지속적으로 개선하고 최적화해야 할 것입니다.
📝 원문 및 참고
- Source: Hacker News
- 토론(HN): [news.ycombinator.com](https://news.ycombinator.com/item?id=49445727)
- 원문: [링크 열기](https://www.lighthousenewsletter.com/p/rag-is-simpler-than-you-think)
---
출처: Hacker News · [원문 링크](https://www.lighthousenewsletter.com/p/rag-is-simpler-than-you-think)
신고 · 불법·유해·아동 안전(CSAE) 관련 콘텐츠
댓글 0
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.