RAG 플랫폼 The RAG Platform

API 뒤로 사라진 복잡성

2장과 3장에서 자체 구축 RAG의 모든 것을 배웠다. 임베딩 모델과 벡터 데이터베이스라는 기본 구성요소에서 하이브리드 검색, 재순위, 환각 검출 같은 더 진전된 구성요소까지다. 4장은 자체 구축 애플리케이션을 단순한 개념검증에서 완전히 프로덕션 준비된 배치로 옮기는 일이 왜 처음 보이는 것보다 복잡한지 탐색하고, 실세계 환경에서 RAG를 확장할 때의 핵심 난관을 짚고, 성공적인 자체 구축 배치의 단계를 제안했다.

RAG 플랫폼은 RAG-as-a-service 또는 턴키 RAG라고도 불리며, RAG 구성요소의 대부분, 어쩌면 전부를 개발자 API 뒤에 구현한 기술 플랫폼을 가리킨다. RAG를 만드는 복잡성 상당 부분을 추상화하고, 개발자가 애플리케이션 자체에 집중하게 한다. 응답이 어떤 데이터에 근거해야 하는가, 그리고 그 애플리케이션을 사업이나 애플리케이션 흐름의 어디에 통합할 것인가에 말이다.

이 장은 RAG 플랫폼이 무엇을 제공하는지, 그리고 필요에 가장 잘 맞는 것을 어떻게 고를지 다룬다. 그리고 Vectara로 그런 플랫폼의 실제 사용을 시연한다.

자체 구축 대 플랫폼

자체 구축 스택을 만들면 파이프라인의 각 구성요소에 대한 세밀한 통제권을 갖는다. Pinecone, Weaviate, Zilliz, Qdrant 같은 벡터 데이터베이스를 고르고 설정하는 일, Cohere의 Embed v4나 Qwen3-Embedding-0.6B 같은 어떤 임베딩 모델이든 호스팅하고 서빙하는 일, 청킹 전략을 정의하고 구현하는 일, LLM 생성 과정을 맞춤화하는 일이 여기 들어간다. 스택을 맞춤화할 힘이 손에 있지만, 그 밑에 놓인 인프라를 프로비저닝하고 통합하고 확장하고 유지할 책임도 함께 있다.

반면 RAG 플랫폼은 관리형 종단간 해법을 제공하며 인프라 복잡성을 추상화한다. 개발자는 API를 통해 서비스와 상호작용해 데이터 소스에서 데이터를 적재하고, 검색 파이프라인을 고르고 설정하고, 임베딩 모델이나 생성 모델을 선택하고, 최소한의 준비로 애플리케이션을 배포한다.

플랫폼 제공자가 이 운영 오버헤드를 대신 짊어지므로, 오직 애플리케이션 로직을 만들고 최종 사용자에게 가치를 전달하는 일에 집중할 수 있다. 이는 더 빠른 개발 주기, 줄어든 데브옵스 부담, 그리고 사용량 기반이나 구독 기반으로 제공되는 일이 많아 잠재적으로 더 낮은 초기 인프라 비용으로 이어진다.

더 나아가 RAG 플랫폼은 대규모 RAG 시스템 운영에서 얻은 제공자의 전문성을 활용해, 저지연·고정확도·비용 효율성을 위한 최적화를 내장해 제공하는 일이 많다. 데이터 소스 커넥터, 진전된 모니터링과 관측성, 그리고 보안·프라이버시 준수를 곧바로 쓸 수 있게 제공하기도 하는데, 자체 구축 환경에서 같은 것을 재현하려면 상당한 엔지니어링 노력이 필요하다.

자체 구축이 최대의 유연성과 맞춤화를 제공하는 반면, RAG 플랫폼은 편의성, 배포 속도, 줄어든 운영 복잡성 때문에 점점 매력적이 되고 있다. 그러나 이 사용 편의는 플랫폼 종속의 위험과, 제공자를 바꿔야 할 때의 이전 비용을 안고 온다.

이제 RAG 스택 안의 모든 구성요소가 무엇이고 어떻게 작동하는지 알고 있으니, 조직의 필요에 비추어 장단점을 저울질하며 직접 만들지 플랫폼을 쓸지 결정할 토대를 갖췄다. 아래에서는 그 이해를 정련하고 온전히 정보에 근거한 결정을 내리도록 돕는 미묘한 지점들을 논의한다.

핵심 RAG 역량

첫 번째 고려사항은 물론 RAG 응답의 품질이며, 그것은 데이터 적재와 질의·검색 파이프라인 양쪽의 역량에 달려 있다. 각 구성요소를 차례로 검토해 자체 구축과 플랫폼 사이의 트레이드오프를 이해한다.

데이터 소스와 커넥터

많은 플랫폼 제공자가 점점 늘어나는 데이터 소스 목록에 대한 커넥터를 지원한다. 이메일 시스템, 구글 드라이브, SharePoint, Notion, Jira, Confluence, 웹페이지, 내부 문서, 각종 데이터베이스 시스템, Salesforce, 그리고 파일을 위한 Box나 Dropbox까지 있다. 플랫폼을 고려한다면 요구사항에 맞는지 확인하기 위해 가용 커넥터를 깊이 살펴봐야 한다.

자체 구축 스택이라면 외부 데이터를 다루는 데 세 가지 선택지가 있다.

1. 커넥터를 직접 만들고 유지하며, 필요할 때마다 새 커넥터를 추가한다.
2. Airbyte 같은 오픈소스 데이터 커넥터 프로젝트나, LlamaIndex·LangChain처럼 커넥터를 포함한 LLM 오케스트레이션 프레임워크를 쓴다.
3. Airbyte Cloud, LlamaCloud 같은 상용 해법을 쓴다.

어떤 접근을 택하든 애플리케이션에 필요한 데이터 소스를 냉정하게 들여다보고, 커넥터 구현의 작업량을 고려해야 한다. 최초 적재만이 아니라 데이터 리프레시와 갱신까지 포함해서 말이다.

RAG 스프롤과 중앙 거버넌스

자체 구축은 파이프라인에 대한 온전한 통제를 제공하지만, 이른바 RAG 스프롤로 이어질 수 있다. 조직 전체에 걸쳐 서로 다르고 독립적으로 관리되는 RAG 애플리케이션이 번식하는 현상이다.

그런 애플리케이션마다 자기 벡터 데이터베이스(Weaviate, Zilliz 등)와 임베딩 모델과 생성 LLM을 고르고, 데이터 적재도 서로 다르게 구현할 수 있다. 이는 중앙 IT에게 빠르게 악몽이 된다. 각자 고유한 복잡성을 가진 여러 유형의 RAG 구성요소를 관리해야 하고, 그중 다수가 조직 정책과 호환되지 않을 수 있다.

보안 관점에서 보면 자체 구축 애플리케이션마다 접근 통제, 데이터 취급 정책, 보안 설정을 저마다 구현할 수 있어, 일관된 보안 조치를 집행하고 취약점을 효과적으로 감시하는 일이 어려워진다. 이 단편화는 정책 드리프트로 이어진다. 개별 파이프라인이 중앙의 감독 없이 갱신되고 수정되는 동안 보안과 준수의 보장이 시간에 걸쳐 침식되는 현상이다. 이런 표준화의 부재는 (의도치 않게) 서로 다른 보호 수준을 가진 데이터 사일로를 낳고, 데이터 유출과 무단 접근, 그리고 GDPR이나 CCPA(캘리포니아 소비자 프라이버시법) 같은 규제의 준수 실패 위험을 높인다.

플랫폼이 진짜로 빛나는 영역이 여기다. RAG 애플리케이션을 배포하고 관리하는 중앙집중적이고 표준화된 접근을 제공하며, 다음 서비스를 포함한다.

• 저장과 연산 같은 IT 자원의 관리(CPU와 GPU 양쪽 포함).
• 데이터 거버넌스, 관측성, 감사 가능성, 릴리스 절차의 내장 메커니즘.
• 견고한 접근 통제 메커니즘, 암호화 프로토콜, 감사 추적 같은 보안 기능.

이렇게 IT 정책을 모든 애플리케이션에 일관되게 적용하는 능력이 RAG 스프롤을 피하도록 돕는다. 마케팅 부서가 비준수 벡터 데이터베이스를 쓰면서 적절한 GDPR 마스킹 없이 EU 고객 데이터를 적재하는 애플리케이션을 만들었다고 하자. 동시에 법무팀은 계약 검토를 위해 전혀 다른, 보안이 매우 강한 LLM으로 별도의 시스템을 만든다. 중앙 IT는 마케팅 앱의 준수 위험을 볼 수도 없고, 단일한 데이터 취급 표준을 강제할 방법도 없다. 플랫폼은 하나의 사전 설정된 “골든 패스”를 제공해 이 문제를 해결한다. 승인된 벡터 스토어의 사용을 강제하고, 어느 부서가 만들었든 모든 새 애플리케이션에 PII 레닥션 규칙을 자동으로 적용한다.

비용과 유지

보안과 거버넌스를 넘어, 자체 구축과 플랫폼 사이의 선택이 갖는 재무적·운영적 함의를 고려해야 한다. 자체 구축은 흔히 RAG 여정의 첫걸음이다. 팀이 생성형 AI를 배우고 첫 프로토타입을 만들어 조직에 가치를 빠르게 입증하고, 가장 영향력 있는 사용 사례를 파악하는 과정이다.

직접 구독료, 즉 LLM 사용 토큰 비용만 따지면 자체 구축이 덜 비싸 보이는 일이 많다. 그러나 API 사용 비용조차 신중히 감시하고 통제하고 지속적으로 최적화하지 않으면 꽤 빠르게 부풀어 오른다. 진짜 비용은 훨씬 더 많은 것을 포괄한다. 더 현실적인 그림을 얻으려면 다음에서 발생하는 비용을 고려해야 한다.

이 책임들은 전문 기량을 갖춘 전담 팀을 요구하며, 지속적인 운영 지출이자 내부 자원의 유출을 뜻한다. 그 자원은 그러지 않았다면 핵심 사업 혁신에 쓸 수 있었을 것들이다.

반면 플랫폼은 이 지속적 유지와 운영 오버헤드의 상당 부분(전부는 아니다)을 벤더에게 옮기고, 높고 예측 불가능한 TCO를 더 예측 가능한 것으로 바꿔 준다. 흔히 다음 두 가격 모델 가운데 하나다.

가격이 소비 기반이든 연간 구독이든, 이 요금은 업데이트와 보안과 플랫폼 진화를 포함한다. 확장성과 미래 대비를 염두에 두면 플랫폼은 정돈된 길을 제공한다. 벤더는 자기 플랫폼을 최전선에 유지하려는 유인을 갖고 LLM과 검색 기법과 보안 관행의 최신 진전을 반영하며, 고객은 자기 사용 사례에 집중하게 된다.

배포 선택지

배포 선택지를 고려할 때, SaaS 해법을 쓸지, 더 맞춤화가 가능한 VPC 배포를 쓸지, 완전히 자체 관리하는 온프레미스 구성을 쓸지의 선택이 통제 수준, 지원 SLA, 책임 영역, 자원 배분에 함의를 갖는다는 점을 유념해야 한다.

자체 구축의 배포 선택지

자체 구축이라면 분명히 유연성이 크고 거의 어디에나 배포할 수 있다. 제약은 구성요소에서 온다. 벡터 데이터베이스가 관리형 서비스인데 온프레미스 시스템이 필요하다면 다른 벡터 데이터베이스를 골라 로컬에 배포해야 한다. 마찬가지로 온프레미스 환경에서는 데이터가 환경 밖으로 나가지 못하게 하는 정책 때문에 상용 API 기반 LLM이나 임베딩 모델이나 재순위기를 쓸 수 없을 수 있고, 그러면 자체 호스팅 LLM에 의존해야 한다.

플랫폼의 배포 선택지

대다수 플랫폼 벤더는 SaaS 배포만 지원한다. 벤더가 전체 스택을 관리하고 하이퍼스케일러 제공자에게 인프라 비용을 직접 지불하는 방식이다. 일부는 VPC와 온프레미스 선택지도 지원한다. SaaS 모델에서 많은 제공자가 적절한 보안과 데이터 거버넌스 통제를 갖추어 HIPAA, GDPR, SOC-2 준수를 보장한다. 그러나 조직이 데이터와 환경에 대한 더 큰 통제를 요구하거나, 심지어 데이터가 시스템을 떠나지 않는 “에어갭” 설치를 요구한다면 SaaS 접근은 애초에 논외다.

최대의 보안과 저지연 접근을 제공하는 반면, 온프레미스 RAG는 구체적인 아키텍처 난제를 풀어야 한다.

궁극적으로 SaaS와 VPC와 온프레미스 사이의 결정은 데이터 보안, 통제, 맞춤화 필요, 가용한 기술 전문성, 예산, 원하는 배포 속도에 관한 조직의 우선순위를 세심히 평가하는 데 달려 있다. 만능 답은 없다. SaaS는 편의와 속도를 우선하고, 온프레미스는 통제와 데이터 격리를 우선하며, VPC는 유연한 중간지대를 제공한다.

사례 연구: Vectara

자체 구축 접근은 모든 구성요소를 골라 통합하는 일을 뜻한다. LlamaIndex, LangChain, Weaviate 같은 오픈소스든 Cohere, Pinecone, Gemini, OpenAI 같은 관리형 서비스든 마찬가지다.

주요 클라우드 제공자들은 자체 구축과 플랫폼 사이의 중간지대를 제공한다. Amazon Bedrock Knowledge Bases, Google Cloud Vertex AI Search, Azure AI Search 같은 “서비스의 플랫폼”이다. 자체 구축을 단순화하는 강력한 도구 모음이지만, 여전히 개발자가 여러 구성요소를 고르고 설정하고 조율해야 한다. 별도의 벡터 데이터베이스를 연결하거나 검색과 생성 API 호출을 손으로 이어 붙이는 식이다.

이는 Vectara나 Nuclia 같은 진정한 종단간 RAG 플랫폼과 대비된다. 문서 추출, 청킹, 임베딩, 벡터 저장, 검색, 생성, 환각 검출이라는 모든 구성요소를 하나의 통합 API로 묶고 개발자에게서 복잡성을 감춘다. 그러면 개발자는 RAG 인프라를 관리하는 대신 애플리케이션을 만드는 일에 집중할 수 있다. 여기서는 시연에 필요한 구성요소에 곧바로 접근할 수 있어 Vectara를 예로 쓰지만, Nuclia 같은 다른 선택지로도 비슷한 탐색을 할 수 있다.

시작하기 — 코퍼스와 문서

Vectara에서 코퍼스(corpus)는 적재된 모든 데이터가 전처리되고 정제되고 질의를 위해 조직된 뒤 담기는 가상 컨테이너를 가리킨다. 각 코퍼스는 격리되어 있어 애플리케이션마다 별개의 데이터셋을 가질 수 있다. 회사 내부 문서용 코퍼스 하나, 고객 지원 티켓용 코퍼스 하나, 제품 리뷰용 코퍼스 하나를 두는 식이다. 문서(document)는 코퍼스 안에 존재하며 검색과 응답 생성에 쓰이는 개별 정보 단위다.

계정을 만들면 웹 기반 인터페이스인 콘솔로 계정과 코퍼스와 데이터를 관리할 수 있다. 코퍼스를 만드는 절차는 이렇다. 좌측 사이드바의 “Corpora” 섹션으로 이동해 “Create corpus”를 누르면 다음 항목을 채우게 된다.

생성이 끝나면 코퍼스는 데이터를 받을 준비가 된다. 그러나 API로 코퍼스를 다루기 전에 API 키를 만들어야 한다. Vectara에는 세 종류의 API 키가 있다.

아래 모든 예제는 코퍼스 키 RAGBOOK을 쓰고, query+index 키나 personal 키를 만들었다고 가정한다. Vectara는 API 키 대신 OAuth 2.0을 통한 접근도 지원하지만 그것은 이 책의 범위를 넘어선다.

Vectara에 데이터 적재하기

파일 업로드

PDF, 워드, PPT, HTML, 마크다운, 텍스트 같은 다양한 유형의 파일을 upload_file 엔드포인트로 업로드할 수 있다.

import requests
import os

corpus_key = "RAGBOOK"
api_key = os.getenv("VECTARA_API_KEY")
url = f"https://api.vectara.io/v2/corpora/{corpus_key}/upload_file"

payload = {}
files = [
    ('file',
     ('pet_policy',
      open('pet_policy.pdf', 'rb'),
      'application/octet-stream')
    )
]
headers = {
    'Accept': 'application/json',
    'x-api-key': api_key
}

response = requests.request("POST", url, headers=headers, data=payload, files=files)
res = response.json()
print(res)

이 한 번의 호출 배후에서 벌어진 일은 이렇다.

1. Vectara가 파일 내용을 받았다. PDF였으므로 파일에서 실제 텍스트를 추출했다.
2. 그 텍스트가 Vectara의 기본 청킹 전략(“문장 청킹”)으로 청킹되었다.
3. Vectara의 Boomerang 임베딩 모델이 각 청크에 적용되어 벡터 임베딩이 만들어지고 내부 벡터 데이터베이스에 저장되었다. 각 청크의 텍스트는 (메타데이터가 있으면 함께) 벡터 임베딩과 나란히 별도의 텍스트 데이터베이스에 저장되었다.

파일 업로드에서는 선택 인자로 추가 역량을 고를 수 있다. 파일에 적용할 청킹 전략(문장 또는 고정)을 선택하는 일, 표 추출이나 이미지 추출을 활성화해 문서에 박힌 표나 이미지가 파이프라인에서 제대로 처리되게 하는 일, 그리고 문서에 메타데이터 필드를 붙이는 일이다. PDF라면 저자명이나 생성일을 메타데이터로 붙이고 싶을 수 있다.

직접 데이터 적재

파일 업로드에 더해 텍스트 데이터를 직접 적재할 수도 있다. 개별 파일에서 오지 않고 데이터베이스나 Notion, Jira, Confluence, Salesforce, Slack 같은 소스에서 오는 데이터에 유용하다.

url = f"https://api.vectara.io/v2/corpora/{corpus_key}/documents"

payload = json.dumps({
    "id": "selected-works-of-shakespeare",
    "type": "structured",
    "title": "William Shakespeare, Greatest Hits",
    "metadata": {
        "timespan": "26 April 1564---23 April 1616",
        "stars": 5,
        "author": "William Shakespeare"
    },
    "sections": [
        {
            "title": "King Lear",
            "text": """Synopsis: King Lear, intending to divide his power and
                       kingdom among his three daughters, demands public
                       professions of their love. His youngest daughter, ...""",
            "sections": [
                {
                    "title": "Act I",
                    "text": """KENT: I thought the king had more affected the
                               Duke of Albany than Cornwall.\nGLOUCESTER: It
                               did always seem so to us...""",
                    "metadata": {
                        "stage-instructions": "Enter KENT, GLOUCESTER, and EDMUND"
                    }
                },
                {
                    "title": "Act II",
                    "text": "EDMUND: Save thee, Curan. ...",
                    "metadata": {
                        "stage-instructions": "Enter EDMUND, and CURAN meets him"
                    }
                }
            ]
        },
        {
            "title": "Antony and Cleopatra",
            "text": """PHILO: Nay, but this dotage of our general's\nO'erflows
                       the measure: those his goodly eyes, ..."""
        }
    ]
})

response = requests.request("POST", url, headers=headers, data=payload)
print(response.json())

이 예제에서는 『리어 왕』의 텍스트 일부를 적재했다. 코드에서 보듯 문서 수준 메타데이터를 붙였고, 텍스트 자체는 섹션으로 쪼개져 있다. 섹션은 중첩될 수 있어 데이터 소스의 복잡한 텍스트 구조를 표현할 수 있고, 각 섹션에도 메타데이터를 붙일 수 있다는 점을 주목할 만하다.

질의 실행하기

1장에서 서술한 질의 흐름은 벡터 검색과 하이브리드 검색과 재순위를 포함할 수 있는 전체 검색 파이프라인으로 질의를 처리하고, 검색된 청크를 맥락으로 담은 프롬프트를 구성해 생성 LLM을 호출하고, 마지막으로 환각 검출과 교정을 수행하는 과정이다. 데이터 적재와 마찬가지로 플랫폼 API는 이 질의 과정을 흔히 단 한 번의 API 호출로 단순화한다.

url = f"https://api.vectara.io/v2/corpora/RAGBOOK/query"
query_str = "Are pets allowed in the office?"

payload = json.dumps({
    "query": query_str,
    "search": {
        "lexical_interpolation": 0.025,          # 하이브리드 검색 보간값
        "offset": 0,
        "limit": 50,
        "context_configuration": {
            "sentences_before": 2,
            "sentences_after": 2
        },
        "reranker": {
            "type": "customer_reranker",
            "reranker_name": "Rerank_Multilingual_v1"
        }
    },
    "generation": {
        "max_used_search_results": 7,
        "response_language": "eng",
        "prompt_name": "vectara-summary-ext-24-05-med-omni",
        "enable_factual_consistency_score": True
    }
})

response = requests.request("POST", url, headers=headers, data=payload)
res = response.json()
search_results = res['search_results']
print(res['summary'])
print(f"Factual Consistency Score: {res['factual_consistency_score']}")

여기서는 요약과 사실 일관성 점수(환각 점수)를 출력했다. 물론 res 변수에는 검색된 청크 전체가 들어 있다. 여러 쪽을 잡아먹을 것이므로 출력하지 않았다.

세부를 많이 감추면서도 질의 API가 상당한 유연성과 통제를 허용한다는 점을 주목할 만하다.

환각 교정

3장에서 환각을 검출하는 데 그치지 않고 교정하는 능력을 언급했다. 위 질의 호출은 응답마다 사실 일관성 점수를 돌려주어 환각일 수 있는 응답을 검출하도록 돕는다. Vectara의 correct_hallucinations 엔드포인트는 그렇게 검출된 환각을 교정한다.

url = f"https://api.vectara.io/v2/hallucination_correctors/correct_hallucinations"

payload = json.dumps({
    "generated_text": hallucinated_response,
    "documents": [
        {"text": r["text"]}
        for r in search_results
    ],
    "model": "vhc-large-1.0"
})

response = requests.request("POST", url, headers=headers, data=payload)
res = response.json()
print(hallucinated_response)
print(res['corrected_text'])

“규칙이 없다”와 “뱀”이라는 잘못된 사실이 원본 텍스트에 근거해 제대로 교정되었다. 어떤 교정이 그 결과를 만들었는지도 확인할 수 있다.

print(res['corrections'])

이 분해는 유용하다. 원본 텍스트의 구체적인 구간을 보여 주고, 각 구간에 대해 어떤 교정이 있었는지와 그 교정의 근거까지 함께 보여 준다.

그 밖의 관리 API 엔드포인트

적재·업로드와 질의가 가장 많이 쓰이는 엔드포인트이지만, 관리에 쓰이는 엔드포인트도 여럿 있다.

url = f"https://api.vectara.io/v2/corpora/RAGBOOK/documents"
headers = {
    'Content-Type': 'application/json',
    'Accept': 'application/json',
    'x-api-key': api_key
}
response = requests.request("GET", url, headers=headers)
res = response.json()

예상대로 두 문서가 보인다. 하나는 파일 업로드로 적재한 pet_policy.pdf이고, 다른 하나는 색인 연산으로 텍스트로 적재한 것이다.

플랫폼을 고를 때는 비슷한 API 엔드포인트가 존재하는지 확인해 각종 관리 업무의 자동화를 가능하게 하는 것이 중요하다. 그래야 중앙 IT가 여러 애플리케이션을 더 잘 관리하고, 적재와 질의 활동을 모두 파악하고, 사람이 조직에 들어오고 나갈 때 사용자를 관리하고, 조직 안의 모든 RAG 애플리케이션에 걸친 중요한 IT 업무를 자동화할 수 있다.