RAG 해체, 경직된 프로토콜에서 유연한 추상화로

Source: Dev.to

번역할 텍스트가 제공되지 않았습니다. 번역이 필요한 전체 내용을 알려주시면 한국어로 번역해 드리겠습니다.

저자 주

이 글은 원래 2025년 9월에 작성했으며, GraphRAG와 같은 아키텍처가 정착되기 직전이었습니다. “디지털 서랍”에 보관해 두었지만, 오늘 다시 살펴보니 그 건축 진단이 아직도 많이 유효하다는 사실에 놀랐습니다. 분석의 맥락을 보존하기 위해 원문을 그대로 유지하면서, 마지막에 최근 몇 달간 RAG 생태계가 어떻게 진화했는지에 대한 짧은 메모만 추가하기로 했습니다.

---

이 정의는 폭넓고 강력합니다. 회수를 어떻게 해야 하는지는 규정하지 않지만, 실제로는 생태계가 벡터 유사도 검색을 비구조화 텍스트 데이터베이스에 적용하는 매우 구체적인 구현으로 대규모 수렴했습니다. 이 기술은 너무나 지배적이어서 우리가 RAG를 인식하는 방식뿐만 아니라 그 주변에 구축하는 도구와 프로토콜까지 형성하고 있습니다. 그리고 여기서, 건축가로서 우리는 그 결과를 면밀히 분석해야 합니다.

API가 메커니즘을 반영하고 의도를 반영하지 않을 때

클라이언트 애플리케이션이 외부 서비스로서 retriever와 상호작용해야 할 때, 이는 API를 통해 이루어진다. 공식적인 표준은 없지만, 사실상의 패턴은 명확하며, 이는 Pinecone, Weaviate, Chroma와 같은 벡터 데이터베이스의 부상으로 크게 대중화되었다:

• RESTful API는 HTTP/S(와 JSON) 위에서
• gRPC는 더 높은 성능을 위해

악마는 언제나 그렇듯 이 API들의 세부 사항에 있다. 벡터 retriever 서비스에 대한 일반적인 호출은 다음과 같다:

{
  "vector": [0.12, 0.54, ..., -0.08],
  "topK": 5,
  "metric_type": "cosine"
}

이 API의 언어를 살펴보자. 그 “동사”와 “명사”는 vector, topK(가장 가까운 K 이웃) 및 metric_type이다. 이는 본질적으로 기하학적이고 통계적인 언어이다. 이 API는 “정보를 검색”하도록 설계된 것이 아니라, “N 차원 공간에서 한 점에 가장 가까운 이웃들을 찾는” 용도로 설계되었다.

깊은 함의: 이 API에 맞춰 프로그래밍된 모든 클라이언트는 추상적인 RAG 개념이 아니라 가능한 구현 중 하나에 강하게 결합된다. 전송 계층이 우리를 하나의 패러다임에 가두었다.
우리의 “retriever”가 벡터를 사용하지 않는다면 어떻게 될까?
SQL 데이터베이스라면?
기상 API라면?
논리적 지식 그래프라면?

현재 API는 이러한 질문들을 표현할 어휘가 없다.

애플리케이션 계층으로 올리기

이러한 애플리케이션과 하위 “엔진” 간의 결합 문제는 우리 산업에서 새로운 것이 아닙니다. 수십 년 전 데이터베이스에서도 각 제조사가 고유한 프로토콜을 가지고 있었죠. 해결책은 ODBC와 JDBC라는 애플리케이션 수준의 추상화 계층을 만드는 것이었습니다.

오늘날 우리는 RAG 생태계에서도 정확히 같은 해결책을 보고 있습니다. LangChain 같은 라이브러리가 이를 주도하고 있습니다. 개발자에게 경직된 전송 API에 코딩하도록 강요하는 대신, 더 높은 수준의 계약을 제시합니다.

LangChain의 BaseRetriever 인터페이스

LangChain에서 이것이 BaseRetriever 인터페이스입니다. 그 주요 메서드는 매우 단순해서 이해하기 쉽습니다:

get_relevant_documents(query: str) -> List[Document]

이 계약의 분석

이 인터페이스에 맞춰 코딩하는 클라이언트는 아래에 무엇이 있는지, 혹은 어떻게 동작하는지 알 필요도, 알 필요도 없습니다. BaseRetriever는 다음과 같이 구현될 수 있습니다:

• PineconeRetriever – 내부적으로 query를 벡터로 변환하고 앞서 본 HTTP 호출을 수행합니다.
• SQLRetriever – 자연어 질문을 구조화된 SQL 쿼리로 변환합니다(언어 모델이나 규칙 집합을 이용).
• 우리가 생각해낼 수 있는 다른 모든 종류의 retriever.

이 유연성은 단순한 이론적 연습이 아니라, 벡터 유사도 검색만으로는 해결할 수 없는 문제들을 풀 수 있게 하는 열쇠입니다.

사용 사례: 공간 논리가 필요한 도메인

잠시 생각해 보자, “진실”이 단순한 텍스트가 아니라 논리적·공간적 구조인 도메인, 즉 지리 정보 시스템 (GIS) 을.

예시 질의:
“지난 2년 동안 가뭄을 겪은 물줄기에서 500 미터 이내에 있는 농지들은 무엇인가요?”

전통적인 벡터 retriever는 어떻게 동작할까?

parcela, cauce, sequía, 500 metros 같은 단어를 포함하는 문서를 찾는다. 결과는 텍스트(기술 보고서, 뉴스 등)의 목록이 될 것이며, 질문에 대한 직접적이고 정확한 답변은 절대 나오지 않는다.

가상의 GeoRetriever는 어떻게 작동할까?

1. 질의 해석

   • LLM이 retriever와 협업하여 질의를 공간적·시간적 요소로 분해한다:
     • tipo: parcela
     • relación: distancia < 500 m
     • condición: sequía en los últimos 2 años

2. 공간 논리 실행

   • 지리 데이터베이스(예: PostGIS)를 조회해 거리 조건과 시간 제한을 만족하는 농지를 찾는다.

3. 답변 구성

   • 결과를 구조화된 목록이나 인터랙티브 지도 형태로 포맷하여 사용자에게 반환한다.

참고: 이렇게 GeoRetriever를 구축하는 일은 여러 분야가 얽힌 거대한 엔지니어링 과제이다. 이는 쉬운 해결책이라기보다 우리가 놓치고 있는 잠재력을 보여주는 예시다.

왜 우리는 유연한 아키텍처가 필요한가

유연한 아키텍처는 다음을 가능하게 합니다:

• 오늘날에는 해결하기 어려워 보이는 문제에 대한 해결책을 상상하고, 궁극적으로 구축할 수 있습니다.
• 단순 벡터 검색보다 더 강력한 지식 엔진이 등장할 때마다 애플리케이션을 전면 철거하고 재구축할 필요 없이 점진적으로 발전할 수 있습니다.

지배적이지만 제한적인 솔루션과 더 큰 유연성에 대한 필요 사이의 이 긴장은 우리 분야에서 새로운 현상이 아니며, 기술 생태계 진화에서 반복되는 패턴입니다.

역사적 비유: 데이터베이스

수년간 각 제조업체는 자체 통신 프로토콜을 강요하여 개발자를 독점 생태계에 가두었습니다. 혁신은 제동을 걸렸지만 ODBC와 JDBC와 같은 추상화 계층이 등장하면서 애플리케이션이 구현 세부 사항에서 해방되고 생태계가 번성할 수 있었습니다.

우리가 RAG와 함께 목격하고 있는 것은 그 주기의 반복입니다:

• 생태계는 효율적인 구현(벡터 검색)으로 빠르게 수렴했지만 acoplante.
• 답은 그 구현을 버리는 것이 아니라 그 위에 추상화 계층을 구축하여 혁신의 자유를 되찾는 것입니다.

이러한 계층은 단순한 기술적 편의가 아니라 모든 기술의 장기적인 건강을 위한 근본적인 메커니즘입니다.

개발자의 좌절감

“현재 API는 효율적이지만, 한 종류의 질문만 통과시킬 수 있는 좁은 문이다.”

개발자로서 나는 기술 자체 때문에가 아니라, 우리가 사용하도록 제공받은 “입구” 때문에 제한받는 것이 깊이 좌절스럽다.

더 유연한 API를 향하여

우리의 목표는 내부 메커니즘이 아니라 사용자의 의도를 표현하는 API를 설계하는 것입니다. 다음과 같은 질문을 하는 API 대신:

“이 벡터와 가장 가까운 K개의 이웃은 무엇인가요?”

우리는 다음과 같이 질문하는 API를 지향해야 합니다:

“이 전략을 사용하여 이 질의에 대한 관련 정보를 검색합니다.”

가능한 전략

가능한 한 메커니즘 결정은 서버 측에 두어야 하며, 인프라가 진화하는 동안 애플리케이션 계층이 안정적으로 유지될 수 있습니다.

왜 중요한가

• **“방법”**에 대해 지나치게 구체적인 API는 더 나은 **“방법”**이 등장하자마자 구식이 된다.
• **“무엇”**에 초점을 맞춘 API는 지속된다, 왜냐하면 상위 세계가 변할 필요 없이 혁신이 표면 아래에서 번창하도록 허용하기 때문이다.

문을 만들자, 복도만이 아니라

El paradigma RAG es mucho más que la búsqueda por similitud. Es la promesa de una IA que consulta dinámicamente cualquier fuente de conocimiento para fundamentar sus respuestas.

Las APIs que dominan hoy son un pasillo estrecho que solo lleva a un destino: la búsqueda vectorial.

La solución no es abandonar ese pasillo, sino construir un vestíbulo con muchas puertas. Abstracciones como las de LangChain son el primer paso: desacoplan la aplicación del mecanismo de recuperación y nos dan un “enchufe” estándar para conectar futuros motores de conocimiento.

다음 큰 도약

RAG에서 다음 큰 도약은 1 % 더 빠른 벡터 알고리즘이 아니다. 지금까지 연결될 것이라고 생각하지 못했던 완전히 새로운 Retriever 클래스가 될 것이다. 이를 사용하려면 이를 가능하게 하는 아키텍처를 구축해야 한다.

성찰: 우리가 구축하는 도구가 우리가 해결할 수 있는 문제를 정의한다. 벡터 검색을 위한 API만 있다면 통계적 유사성 문제만 해결할 수 있을 뿐, 구조적 추론이 필요한 문제는 해결할 수 없다.

결론

건축가로서 우리의 일은 알려진 경로만 최적화하는 것이 아니라, 아직 존재하지 않는 경로를 탐색할 자유를 확보하는 것입니다.

---

주석

몇 달 전 이 글을 쓰기 시작했을 때, 벡터 검색은 여전히 RAG에서 지배적인 패러다임이었습니다. 그 이후로 생태계는 빠르게 진화했습니다:

• Microsoft의 GraphRAG (및 보다 효율적인 변형인 LazyGraphRAG)
• LinearRAG
• LightRAG

이 프로젝트들은 여기서 주장한 추세를 보여줍니다: 우리는 엄격히 벡터 기반인 RAG에서 지식 그래프, 구조화된 추론 및 하이브리드 검색 메커니즘을 통합하는 접근 방식으로 전환하고 있습니다.

이러한 발전은 벡터 데이터베이스의 기하학적 API에 대한 비판을 무효화하지 않으며, 오히려 강화합니다. LangChain 등과 같은 추상화 계층 덕분에만 우리는 이러한 새로운 가능성을 온전히 활용할 수 있습니다.

LlamaIndex: 애플리케이션을 다시 작성하지 않고 새로운 retrievers 통합

우리가 상상하던 미래가 이미 다가오고 있습니다.

시스템 RAG의 기술적·아키텍처적 기본을 깊이 파고들고, 주류 구현을 넘어 탐구하고자 하는 분들을 위해 여기 핵심 자료들을 선정했습니다.

📚 원본 기본

• “Retrieval‑Augmented Generation for Knowledge‑Intensive NLP Tasks”
  Patrick Lewis, et al. (2020)

  이 논문은 RAG라는 약어의 기원이 된 논문입니다. 원래 프레임워크의 비전을 이해하려면 반드시 읽어야 하며, 이는 현재 많은 구현이 사용하는 검색 메커니즘에 구애받지 않는 보다 넓고 중립적인 접근을 의도하고 있습니다.

🔧 주류 생태계 (벡터 검색)

• 벡터 데이터베이스 문서

  • Pinecone
  • Weaviate
  • Chroma

  튜토리얼을 넘어, 개념 및 아키텍처 섹션은 기사에서 분석한 API 뒤에 있는 ‘왜’를 상세히 설명합니다. 이는 생태계를 형성한 사실상의 프로토콜을 이해하기 위한 최고의 자료입니다.

• “Vector Search for Practical Machine Learning”
  A. Aji, et al.

  대규모 유사도 검색을 가능하게 하는 알고리즘 및 데이터 구조(예: HNSW)에 대한 견고한 기술적 통찰을 제공하는 리뷰 논문입니다.

🧩 추상화와 미래

• LangChain 및 LlamaIndex의 “Retrievers” 문서

  • LangChain의 BaseRetriever 인터페이스를 분석합니다.
  • LlamaIndex에서 QueryEngine 및 Retriever 개념을 탐구합니다.

  우리가 제안하는 추상화 계층을 실제로 확인할 수 있는 가장 직접적인 방법입니다. 유연하고 분리된 RAG 시스템을 구축하고자 하는 모든 개발자에게 필수적입니다.

• “Seven Failure Points When Engineering a Retrieval Augmented Generation System”
  Scott Barnett, et al. (2024)

  견고한 RAG 파이프라인을 설계할 때 흔히 발생하는 위험 요소와 이를 완화하는 방법을 설명하는 실용적인 기사입니다.