티스토리 뷰


최근 몇 년 사이 대형 언어 모델(LLM)의 발전 속도는 예상보다 훨씬 빠르게 진행되고 있습니다. 단순한 챗봇 수준을 넘어 코드 생성, 문서 요약, 복잡한 추론 보조까지 수행하는 수준으로 발전하면서 많은 기업이 이를 서비스에 도입하기 시작했습니다. 그 과정에서 Retrieval-Augmented Generation(RAG) 구조는 사실상 표준 아키텍처처럼 받아들여졌고, 상당수 조직이 RAG 기반 시스템 구축에 빠르게 투자했습니다.

 

그러나 시간이 지나면서 흥미로운 현상이 나타나기 시작했습니다. 한때 핵심 경쟁력으로 여겨졌던 RAG 파이프라인이 모델 업데이트 이후 오히려 성능 개선을 방해하거나, 유지 비용만 증가시키는 구조로 변하는 사례가 점점 보고되고 있습니다. 이러한 경험은 단순한 기술 실패라기보다는, 신기술 도입 과정에서 자주 나타나는 더닝-크루거 효과와 맞닿아 있는 부분이 있다고 느끼게 됩니다.

 

이 글에서는 LLM과 RAG 도입 과정에서 조직들이 겪었던 기대와 현실의 간극, 그리고 모델 발전 속도가 기존 아키텍처를 어떻게 무력화시켰는지를 정리해보고, 그 과정에서 얻은 몇 가지 기술적 인사이트를 정리해보려고 합니다. 

 


 

RAG가 사실상의 정답처럼 받아들여지던 시기

 

LLM 초기 도입 단계에서 가장 크게 지적된 문제는 최신 정보 반영의 어려움과 환각(hallucination)이었습니다. 모델은 학습 시점 이후의 정보를 알지 못하고, 내부 지식만으로 답변을 생성하다 보니 부정확한 답변을 자신 있게 출력하는 경우가 자주 발생했습니다.

 

이 문제를 해결하기 위해 등장한 대표적 접근 방식이 바로 RAG 구조였습니다. 사용자의 질문과 관련된 문서를 외부 저장소에서 검색하고, 해당 문서를 LLM 입력에 포함시켜 답변을 생성하도록 만드는 방식입니다. 이 구조는 공식 논문과 주요 기업의 기술 블로그에서도 널리 소개되며 빠르게 확산되었습니다.

 

당시 많은 조직에서는 다음과 같은 기대를 가졌습니다.

 

  • 사내 문서를 학습시키지 않고도 정확한 답변 제공 가능
  • 최신 데이터 반영 가능
  • 환각 문제 감소
  • 기존 검색 시스템과 결합 가능

 

이러한 기대는 충분히 합리적이었고, 실제로 초기 RAG 시스템은 상당한 성과를 보이기도 했습니다. 특히 문서 기반 Q&A 시스템이나 사내 지식 검색 영역에서는 빠르게 도입이 이루어졌습니다.

 

하지만 이 시점에서 많은 팀이 한 가지를 과소평가했던 것 같습니다. 바로 LLM 자체의 발전 속도였습니다.

 


 

모델 발전 속도를 과소평가했던 조직들의 경험

 

초기 RAG 도입 프로젝트에서는 상당한 공수가 투입되었습니다. 임베딩 모델 선정, 벡터 DB 구축, 검색 정확도 개선, chunk 분할 전략 설계, 리랭킹 모델 도입 등 다양한 최적화 작업이 이어졌습니다.

 

문제는 이러한 구조가 특정 시점의 모델 성능을 기준으로 설계되었다는 점입니다.

 

시간이 지나면서 LLM 자체의 성능은 빠르게 개선되었습니다. 더 긴 컨텍스트 처리 능력, 향상된 추론 성능, 그리고 사전 학습 데이터의 확장이 이루어지면서 다음과 같은 변화가 나타났습니다.

 

과거에는 외부 문서를 반드시 제공해야 정확한 답변이 가능했던 영역에서도, 최신 모델은 별도의 검색 없이도 충분히 정확한 답변을 생성하는 경우가 늘어나기 시작했습니다. 또한 모델 자체가 더 정교한 요약과 추론을 수행하면서, 오히려 잘못 검색된 문서가 답변 품질을 떨어뜨리는 상황도 발생했습니다.

 

결과적으로 일부 조직에서는 다음과 같은 현상을 경험하게 됩니다.

 

RAG를 제거했더니 오히려 응답 속도와 정확도가 개선되는 경우가 발생한 것입니다.

 

이는 초기 투자 비용을 고려할 때 쉽게 받아들이기 어려운 결과였습니다.

 


 

레거시 RAG 구조가 모델 업데이트 이후 방해물이 된 이유

 

이 현상이 발생한 이유는 몇 가지 기술적 요소에서 찾을 수 있습니다.

 

첫째, 검색 품질이 모델 성능을 따라가지 못한 경우입니다. 검색 단계에서 불완전한 문서가 선택되면, 모델은 해당 정보를 기반으로 답변을 생성하게 됩니다. 모델이 이미 더 정확한 내부 지식을 가지고 있음에도, 외부 문서가 오히려 답변 품질을 떨어뜨리는 상황이 발생합니다.

 

둘째, chunk 분할 전략의 한계입니다. 문서를 작은 단위로 분할하는 방식은 검색 효율을 높이지만, 문맥 손실을 유발할 수 있습니다. 모델의 컨텍스트 처리 능력이 커진 이후에도 과거 전략을 유지하면, 오히려 정보 단편화가 문제로 작용하게 됩니다.

 

셋째, 운영 복잡성 증가입니다. 벡터 DB 관리, 임베딩 업데이트, 색인 재구축, 리랭킹 모델 관리 등 추가적인 시스템 운영 부담이 지속적으로 발생합니다. 모델 자체 성능이 향상될수록 이러한 구조는 비용 대비 효용이 감소합니다.

 

결국 초기에는 필수 요소였던 RAG가 시간이 지나면서 유지 비용만 높은 구조로 변하는 경우가 나타난 것입니다.

 


 

더닝-크루거 효과 관점에서 본 기술 도입 과정

 

이러한 경험을 더닝-크루거 효과 관점에서 바라보면 흥미로운 지점이 보입니다.

 

기술 도입 초기에는 “우리는 이미 문제 해결 방법을 알고 있다”는 확신이 강하게 형성됩니다. RAG를 적용하면 문제를 해결할 수 있다는 믿음이 빠르게 확산됩니다.

 

하지만 실제 운영 단계로 넘어가면서 예상하지 못한 변수들이 나타납니다. 검색 품질 문제, 유지 비용, 모델 업데이트와의 충돌 등 복합적인 문제가 드러나면서 기술 이해도가 재조정되는 과정이 발생합니다.

 

그리고 시간이 지나면서 보다 균형 잡힌 시각에 도달하게 됩니다. RAG는 만능 해결책이 아니라, 특정 상황에서 효과적인 도구라는 점을 받아들이게 됩니다.

 

이 과정은 특정 조직만의 문제가 아니라, 빠르게 변화하는 기술 환경에서 반복적으로 나타나는 현상이라고 생각됩니다.

 


 

지금 시점에서 RAG를 어떻게 바라보는 것이 현실적인가

 

현재 시점에서 RAG는 여전히 중요한 아키텍처입니다. 특히 다음과 같은 경우에는 여전히 효과적입니다.

 

사내 전용 데이터 접근이 필요한 경우, 최신 정보 반영이 필수적인 서비스, 특정 도메인 문서 기반 답변이 필요한 환경 등에서는 여전히 핵심 구조로 활용됩니다.

 

다만 한 가지 변화가 필요해 보입니다. RAG를 기본 전제로 설계하기보다, 모델 자체 성능과 비교하여 필요성을 지속적으로 평가하는 접근이 중요해졌습니다.

 

모델이 발전하면 아키텍처 역시 단순해질 수 있다는 점을 항상 고려해야 합니다.

 


 

개인적으로 정리하게 된 인사이트

 

최근 몇 년간 LLM과 관련된 다양한 프로젝트를 지켜보면서 한 가지를 반복적으로 느끼게 됩니다. 우리가 설계한 시스템은 기술 발전 속도를 전제로 하지 않는 한 언제든지 레거시가 될 수 있다는 점입니다.

 

특히 AI 영역에서는 1년 전 최선의 설계가 지금은 과한 구조가 되는 경우도 자주 발생합니다. 그렇기 때문에 특정 기술을 절대적인 해법으로 바라보기보다, 지속적으로 재평가하고 단순화할 수 있는 구조를 고민하는 것이 더 중요하다고 느끼게 됩니다.

 

RAG 역시 마찬가지라고 생각합니다. 필요한 곳에서는 강력한 도구이지만, 모델이 충분히 발전한 영역에서는 오히려 제거하는 것이 더 나은 선택일 수도 있습니다.

 

결국 중요한 것은 최신 기술을 빠르게 도입하는 것만이 아니라, 변화에 맞춰 구조를 다시 단순하게 만들 수 있는 용기를 가지는 것이라고 생각하게 됩니다. 이런 경험들이 앞으로의 설계 판단에 조금씩 도움이 되기를 기대하며 글을 마무리합니다.