RAG를 프로덕션에
배치하기 Deploying RAG to Production

한 사람의 사이드 프로젝트와
조직의 기간 시스템

이제 기본에서 고급까지 RAG 파이프라인의 모든 구성요소를 알고 있으니 꽤 괜찮은 개념검증(POC)을 손쉽게 조립할 수 있다. 첫 POC라면 조직에 유의미한 가치가 있으면서 초기 투자가 비교적 적은 사용 사례를 고르는 것이 통례다. 그렇게 하면 이것이 실제로 어떻게 작동하는지 배우고, RAG를 몸으로 이해하게 된다.

POC를 띄우는 일은 아주 재미있다. 강력한 거대언어모델을 가져와 문서나 데이터에 겨누고, 벡터 데이터베이스에서 질의와 청크 임베딩 벡터 사이의 유사도를 구현하면, 짜잔, 문서 내용에 근거한 진짜 답변을 받으며 질문을 시작할 수 있다. 사이드 프로젝트로 한다면 시간과 노력이 적당히만 들어간다.

그러나 목표가 확장 가능하고 안전하고 빠르며 회사에 미션 크리티컬한 서비스를 제공하는 프로덕션급 RAG 애플리케이션이라면 완전히 다른 이야기다. POC에서 프로덕션급 배치로 옮기는 일은 기술과 운영과 조직에 걸친 수많은 난관을 기업에 안긴다. 확장하는 동안 지연 병목, 벤더 통합의 복잡성, 데이터 보안 요구사항, 분야를 넘나드는 전문성의 공백을 마주하게 된다.

프로덕션 RAG의 난관

확장 가능한 프로덕션급 RAG 스택은 처음 보이는 것보다 만들기 어렵다. 응답 품질, 지연, 보안, 지원, 비용을 비롯해 넘어야 할 관문이 많다.

관문 1 — 응답 품질과 환각 감소

AI 조수를 만들든, 질의응답이나 자동 제안서(RFP) 응답 애플리케이션을 만들든, 어떤 사용 사례든 파이프라인의 응답 품질은 대체로 가장 중요한 기능이다. 사용자는 신뢰할 수 없는 애플리케이션에서 이탈한다. 응답 다수가 부정확하거나 환각을 담고 있으면 신뢰가 급격히 떨어지고, 애플리케이션은 사실상 쓸 수 없는 물건이 된다. 저품질 응답을 낳는 요인을 이해해야 원인을 짚고 손을 쓸 수 있다.

# 기본 프롬프트
prompt = """
Use the following pieces of context to answer the question at the end.
{context}
Question: {question}
Helpful Answer:"""

# 흔히 쓰이는 개선형 — 한 문장이 품질을 바꾼다
prompt = """
Use the following pieces of context to answer the question at the end. If you
don't know the answer, just say that you don't know; don't try to make up an
answer.
{context}
Question: {question}
Helpful Answer:"""

“답을 모르면 그냥 모른다고 말하라. 답을 지어내려 하지 말라”처럼 LLM에 구체적 지시를 주는 일은 응답 품질을 개선하는 강력한 방법이 될 수 있다. 프로덕션 RAG가 훨씬 많은 문서와, 기본 프롬프트가 덮지 못하는 예외 사례를 다룰 때 특히 그렇다. 세심한 프롬프트 설계는 저품질 응답을 억제하고 프롬프트 인젝션 공격에 대한 더 나은 방어를 제공하며, 수많은 질의에 걸친 상당한 테스트를 요구한다.

높은 지연

엔터프라이즈 RAG 시스템은 시맨틱 검색, 하이브리드 검색, 재순위, 생성 LLM, 그 밖의 모든 구성요소가 만드는 연산 부하와, 빠른 응답을 바라는 사용자 기대를 화해시켜야 한다.

프로토타입 단계에서는 속도보다 기능을 앞세우는 것이 흔하다. 그러나 프로덕션 배치로 옮기면 애플리케이션은 공개된 ChatGPT에 견줄 만한, 흔히 종단간 몇 초 범위의 더 엄격한 지연 기준을 지켜야 한다.

POC 시점의 데이터량은 보통 프로덕션 데이터 크기의 작은 일부이고, 그 규모 증가는 모든 구성요소가 훨씬 높은 부하에 놓이므로 지연을 손쉽게 크게 높인다.

• 벡터 데이터베이스는 저지연 응답을 유지하도록 제대로 색인되어야 한다.
• 하이브리드 검색은 더 많은 데이터를 지연의 유의미한 증가 없이 감당하도록 최적화되어야 한다.
• 재순위기는 더 많은 후보를 처리해야 할 수 있다.
• 정확도를 유지하기 위해 생성 LLM에 제공하는 청크 수를 늘려야 할 수 있다.

더 나아가, 높은 지연을 피하려면 POC에서 쓴 구성요소를 프로덕션에서 다른 것으로 교체해야 한다는 사실을 발견할 수도 있다. POC에서 쓴 벡터 DB가 모든 데이터를 메모리에 두는 방식이었다면, 프로덕션에서는 그것을 확장해야 하는데 그 규모에서는 성능이 나오지 않을 수 있다.

완화 1 — 병렬화와 오토스케일링

오토스케일링과 함께 종단간 질의 흐름을 병렬화하는 일, 즉 질의량이 적을 때나 많을 때나 지연에 큰 영향 없이 파이프라인이 효율적으로 감당하게 만드는 일은 세심한 시스템 설계를 요구한다.

흔한 설계 패턴은 무상태 오케스트레이터 서비스를 중앙 “두뇌”로 두는 결합 해제된 마이크로서비스 집합이다. 이 오케스트레이터는 CPU에 묶인 경량 API 서버로, 사용자 질의를 받아 종단간 흐름을 관리한다. 먼저 임베딩 서비스를 호출한 다음, 여러 요청을 동시에 “팬아웃”한다. 벡터 데이터베이스와 키워드 기반 어휘 검색 서비스에 정확히 같은 시점에 질의를 던지는 식이다.

이 팬아웃/게더 패턴은 검색 지연이 모든 데이터 소스의 합이 아니라 가장 느린 하나에 의해 결정되도록 보장한다. 후보 청크가 모두 모이면 오케스트레이터는 그것을 전용 재순위 서비스로 보내고, 마지막으로 최적화된 맥락을 LLM 생성 서비스에 넘긴다.

이 결합 해제 설계가 오토스케일링의 열쇠다. CPU에 묶인 오케스트레이터, I/O에 묶인 벡터 DB, 값비싼 GPU에 묶인 LLM 서비스 각각이 자기 복제 그룹으로 관리되며, CPU 사용률, 진행 중인 GPU 요청 수, 데이터베이스 연결 수처럼 저마다의 자원 병목에 따라 독립적으로 확장하거나 축소할 수 있다.

완화 2 — 대체 LLM 사용

응답 품질의 성능 특성을 그대로 유지하려는 경우, POC와 프로덕션에서 정확히 같은 LLM을 쓰는 일은 드물지 않다. 그러나 그저 쉽고 손에 닿아서 POC에 프런티어급 대형 LLM을 썼다면, 지연이 문제이고 그것을 줄여야 한다면 더 작고 빠른 LLM을 시도해 이득을 볼 수 있다. 프로덕션에서 다른 LLM을 써야 한다면 응답 품질에 상당한 영향이 있을 수 있으므로, 파이프라인을 아주 신중히 테스트하고 RAG 평가(6장)를 수행해 품질 저하가 없음을 확인해야 한다.

완화 3 — 소프트웨어·하드웨어 가속

결합 해제된 마이크로서비스 아키텍처 안에서는 각 파드에 특정 하드웨어·소프트웨어 최적화를 전담시켜 성능을 극대화할 수 있다. 물론 파이프라인이 그 기능을 실제로 수행하고 외부 API 서비스를 호출하는 것이 아닐 때의 이야기다.

임베딩, 재순위, LLM 파드는 엔비디아 A100이나 H100 같은 강력한 GPU로 유의미한 성능 향상을 볼 수 있다. 더 중요하게는, 이 모델들을 vLLM, TensorRT-LLM, TGI(Text Generation Inference) 같은 최적화된 추론 서버로 서빙할 수 있다. 이 소프트웨어 계층은 타협 대상이 아니다. 병렬로 도는 여러 오케스트레이터 파드의 동시 생성 요청을 효율적으로 감당하는 연속 배칭(continuous batching)과, RAG에서 전형적인 긴 맥락의 메모리 오버헤드를 잘라내는 페이지드 어텐션(paged attention) 같은 결정적 기법을 구현하기 때문이다.

완화 4 — 효율적 데이터 색인

로컬에 호스팅한 벡터 데이터베이스를 쓴다면 저지연의 전제 조건은 HNSW나 IVFPQ(역파일 곱 양자화) 같은 근사 최근접 이웃(ANN) 색인의 구현이다. 마찬가지로 어휘 검색에서는 Elasticsearch나 OpenSearch 색인에 적절한 샤딩을 구현하고 적합한 텍스트 분석기를 써서 키워드 조회가 빠르게 되도록 만들어야 한다. 잘 설계된 색인이 있어야 검색 파드가 밀리초 단위로 응답하고, 그래야 오케스트레이터의 팬아웃 전략이 성립한다.

완화 5 — 캐싱

Redis나 Dragonfly 같은 고속 인메모리 키–값 저장소로 구현한 캐싱은 여러 마이크로서비스 “앞에” 앉아 전체 지연을 줄이는 데 도움이 된다. 다음 구성요소에 구현할 수 있다.

입력이 자연어 질의인 RAG 애플리케이션에서는 시맨틱 캐싱을 구현하는 것이 유익할 수 있다. 정확한 문자열 일치를 요구하는 대신 저장된 캐시 키에 대해 유사도 검색을 수행하는 방식이다. 최종 사용자가 같은 질문을 두 번 똑같이 표현하는 일은 드물기 때문이다. “비밀번호를 어떻게 재설정하나요?”와 “비밀번호를 바꿔야 합니다”는 전통적인 해시 기반 캐시에서 적중하지 못하는 일이 많다. 시맨틱 캐시에서는 들어온 질의를 벡터로 임베딩하고, 일정 유사도 임계값을 넘는 의미적으로 가까운 과거 질의를 캐시에서 찾는다. 일치를 찾으면 그 유사 질의에 결부된 캐시 응답을 돌려주므로, 자연어 입력의 캐시 적중률이 유의미하게 높아진다.

늘 그렇듯 견고하고 지속적인 모니터링이 실시간 지연 병목과 더 구조적인 지연 문제를 식별하고 교정하도록 돕는다. LangChain으로 검색 캐싱의 발상을 간단한 예로 보인다. 여기서는 시맨틱 캐싱에 Redis를 쓴다. Dragonfly나 KeyDB도 좋은 대안이다.

import numpy as np
from langchain_core.documents import Document

class SemanticCachedRetriever(BaseRetriever):
    """임베딩 유사도로 시맨틱 캐싱을 수행하는 검색기.
    표현이 달라도 의미가 비슷하면 캐시에 적중한다."""

    _base_retriever: any = PrivateAttr()
    _embeddings: any = PrivateAttr()
    _similarity_threshold: float = PrivateAttr(default=0.85)
    _cache_embeddings: List[np.ndarray] = PrivateAttr(default_factory=list)
    _cache_results: List[List[Document]] = PrivateAttr(default_factory=list)
    _cache_queries: List[str] = PrivateAttr(default_factory=list)

    def __init__(self, base_retriever, embeddings,
                 similarity_threshold: float = 0.85, **kwargs):
        super().__init__(**kwargs)
        self._base_retriever = base_retriever
        self._embeddings = embeddings
        self._similarity_threshold = similarity_threshold
        self._cache_embeddings, self._cache_results, self._cache_queries = [], [], []

    def _cosine_similarity(self, a: np.ndarray, b: np.ndarray) -> float:
        return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))

    def _find_similar_cached(self, query_embedding):
        """의미적으로 유사한 과거 질의의 캐시 결과를 찾는다."""
        best_similarity, best_match, best_query = 0.0, None, None
        for i, cached_emb in enumerate(self._cache_embeddings):
            similarity = self._cosine_similarity(query_embedding, cached_emb)
            if similarity > best_similarity:
                best_similarity = similarity
                best_match = self._cache_results[i]
                best_query = self._cache_queries[i]
        if best_similarity >= self._similarity_threshold:
            return best_match, best_query, best_similarity
        return None

    def _get_relevant_documents(self, query: str) -> List[Document]:
        query_embedding = np.array(self._embeddings.embed_query(query))
        cache_hit = self._find_similar_cached(query_embedding)
        if cache_hit:
            docs, original_query, similarity = cache_hit
            print(f"Semantic Cache Hit! (similarity: {similarity:.3f})")
            print(f'  Matched query: "{original_query}"')
            return docs

        # 캐시 미스 — 실제 검색을 수행하고 결과를 캐시에 넣는다
        print("Semantic Cache Miss. Performing vector search...")
        results = self._base_retriever.invoke(query)
        self._cache_embeddings.append(query_embedding)
        self._cache_results.append(results)
        self._cache_queries.append(query)
        return results

    def clear_cache(self):
        self._cache_embeddings, self._cache_results, self._cache_queries = [], [], []

보다시피 이것은 의미 유사도를 활용해 작동한다. 질의를 해싱하는 대신 벡터 임베딩으로 변환해, 앞서 캐시된 질의 벡터들과 코사인 유사도로 비교한다. 과거 질의가 충분히 유사하면(여기서는 0.85로 정한 임계값을 넘으면) 저장된 결과를 즉시 돌려준다. 그렇지 않으면 표준 검색을 진행하고, 새 질의와 그 임베딩과 결과를 앞으로를 위해 로컬 메모리 캐시에 저장한다.

그러나 정확 일치나 시맨틱 캐싱이 POC에서는 구현하기 단순해도, 프로덕션 규모에서 캐싱은 유의미하게 복잡해진다. 세 가지 주요 난제를 다뤄야 한다.

Redis LangCache가 정확히 이 목적으로 설계되었고, 턴키 RAG 플랫폼은 흔히 이 전략들을 스택의 일부로 구현해 둔다.

데이터 보안과 프라이버시

프로덕션 RAG 배치는 세 개의 결정적 공격면에 걸쳐 심층 방어 전략을 구현해야 한다. 적재 계층, 벡터·어휘 데이터베이스, 그리고 생성 단계다.

적재 계층의 보안

다른 어떤 ETL 파이프라인처럼 적재 흐름은 데이터가 원천에서 파이프라인으로 이동하는 동안의 안전을 보장하기 위해 표준 암호화 프로토콜을 써야 한다. 더 나아가 문서 추출, 표·이미지 처리, 청킹, 임베딩, 그리고 벡터 데이터베이스·어휘 데이터스토어·(쓰는 경우) 그래프 데이터베이스 저장까지 파이프라인의 모든 구성요소에서 같은 보안 프로토콜이 구현되도록 보장해야 한다.

데이터에 개인식별정보(PII)나 보호대상 건강정보(PHI)가 있다면 레닥션 전략을 고려해야 하고, 동시에 정보 손실로 응답 품질이 떨어지지 않도록 주의해야 한다.

from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine
from presidio_anonymizer.entities import OperatorConfig

def entity_aware_redaction(text):
    """유형 마스킹 전략. 민감 데이터를 그 범주(예: [PERSON])로 대체한다."""
    analyzer = AnalyzerEngine()
    anonymizer = AnonymizerEngine()

    # 1. PII 엔티티 검출
    results = analyzer.analyze(
        text=text, entities=["PERSON", "PHONE_NUMBER"], language='en'
    )

    # 2. 엔티티 유형으로 대체 — 의미 구조를 보존한다
    anonymized_result = anonymizer.anonymize(
        text=text,
        analyzer_results=results,
        operators={
            "PERSON": OperatorConfig("replace", {"new_value": "<PERSON>"}),
            "PHONE_NUMBER": OperatorConfig(
                "replace", {"new_value": "<PHONE_NUMBER>"}
            ),
        }
    )
    return anonymized_result.text

input = "Dr. Bao called 123-555-1122."
print(entity_aware_redaction(input))

정보 출처에 관한 ISO/IEC 27001 표준을 준수해야 한다면, 데이터의 이력이 신뢰할 만하고 몰래 변경되지 않았음을 증명할 수 있어야 한다. 여기서 흔한 접근이 해시 기반 추적이다. 파이프라인의 매 단계에서 데이터의 고유한 “디지털 지문”(해시)을 만들어, 감사자가 완전성을 확인할 수 있는 검증 가능한 증거의 사슬을 제공한다.

데이터 저장소의 보호

RAG 파이프라인에서 벡터 DB는 벡터 임베딩과 그에 결부된 텍스트 데이터 양쪽의 저장소로 기능한다. 하이브리드 검색을 쓰면 어휘 검색에 최적화된 별도의 텍스트 데이터베이스가 구현에 포함되고, 지식 그래프를 구현한다면 그래프 데이터베이스까지 더해진다.

모든 경우에 핵심 요구사항은 암호화(저장 시와 전송 시)와 역할 기반 접근 통제(RBAC)다. 회사의 보안 정책을 준수하거나 EU 일반개인정보보호법(GDPR)의 “최소 필요” 원칙을 집행하기 위해서다. 애플리케이션 기능에 필요한 필수 데이터만 저장하고, 불필요한 데이터를 정기적으로 검토하고 폐기하며, 민감 정보의 노출을 최소화하는 설계에 의한 프라이버시 원칙을 구현하는 일이 그 내용이다. 안전한 어떤 기업 시스템과 마찬가지로, 이 모든 데이터 저장소에 네트워크 보안 모범 사례와 지속적 모니터링, 사고 대응 절차를 구현해야 한다.

데이터 유출의 방지

RAG 데이터 저장소에는 질의를 구동하는 데 필요한 모든 데이터가 들어 있다. 조직 안에서 서로 다른 권한 수준의 대상인 다양한 문서와 데이터가 뒤섞여 있다. 어떤 문서는 전 직원이 접근할 수 있고, 어떤 문서는 기밀로 남아 CEO나 인사 부서 같은 고위 경영진에게만 보인다.

권한 관련 데이터 유출을 피하는 흔한 접근은 질의 흐름에 권한 기반 필터링 메커니즘을 통합하는 것이다. 이 필터는 회사의 RBAC 정책을 활용해, 질의하는 사용자에게 인가된 데이터만 생성 LLM에 전달되도록 보장한다. 그렇게 해서 무단 접근을 막고 기밀 정보 노출 위험을 완화한다. 효과적인 접근이지만, 파이프라인에 적재되는 모든 데이터에 걸쳐 일관된 역할 기반 권한 전략을 요구한다. 이런 방어를 어떻게 구현하든, 질의 흐름의 정기 감사, 필터링 메커니즘의 철저한 테스트, 외부 상호작용의 지속적 모니터링이 유출을 탐지하고 예방하는 결정적 조치다.

LLM 생성 가드레일

생성 LLM은 검색된 데이터와 사용자 질의를 결합해 최종 출력을 만드는 책임을 진다. 회사 정책과 규제 요구사항에 부합하려면, 애플리케이션은 허용되지 않는 내용의 생성을 막는 견고한 보호를 갖춰야 한다. 1장에서 소개하고 3장에서 자세히 논의한 가드레일이 혐오 표현, 편향된 언어, 그 밖의 해롭거나 부적절한 출력 같은 문제를 다룬다.

POC에서 프로덕션으로 옮기면 이런 가드레일은 엄격한 요구사항이 되고, 규모에서 작동하게 만들려면 세심한 구현만이 아니라 파이프라인 성능을 추적하고 잠재적 위반을 식별하고 사고 시 빠른 대응을 돕는 포괄적 로깅과 모니터링이 필요하다. 프로덕션에서 최종 사용자가 문제 있는 출력을 신고할 수 있게 하는 것은 단순하지만 효과적인 전략이며, 이런 문제를 일찍 잡아 시스템의 안전성과 준수 조치를 지속적으로 정련하게 해준다.

벤더 혼란과 통합의 고통

프로덕션급 RAG 스택을 만드는 일은 벡터 데이터베이스와 임베딩 모델과 생성 LLM을 조립하는 것 이상이다. 스택이 진화하면 높은 응답 품질과 견고한 성능을 유지하기 위해 구성요소를 추가로 통합해야 할 수 있다.

이 “직접 만들기” 접근은 흔히 조각조각 나뉘고 부서지기 쉬운 아키텍처를 낳는다. 모든 연결의 통합과 유지가 자기 책임이 된다. 각 시스템이나 서비스를 조달하고 도입하는 일만이 아니라, 그 전부를 스택 안에 통합해 조화롭게 작동하도록 만들고 높은 가동률과 낮은 지연을 유지해야 한다. 게다가 그것들을 시스템 모니터링 인프라와 보안 절차에 통합하는 일이 취약점을 일찍 식별하고 시스템 완전성을 유지하는 데 결정적이다.

특히 지원은 예상 밖으로 복잡해질 수 있다. 버그가 발견되거나, 지연이 허용 기준을 넘어 오르거나, 응답 품질이 갑자기 떨어질 때 무슨 일이 벌어지는지 생각해 보자. 각자 자기 지원 인력과 지원 SLA를 가진 여러 벤더와 동시에 일하게 되고, 그 모든 당사자 사이의 조율자 역할은 당신에게 남는다.

팀과 전문성

또 하나의 중요한 난관은 최초의 RAG 애플리케이션을 구현하는 데 그치지 않고, 시간이 흐르며 그것을 지원하고 개선하며 추가 사용 사례를 지탱하도록 필요한 변경을 해낼 팀을 만드는 일이다.

단일 사용 사례로 여정을 시작하면, 성공과 함께 추가 사용 사례에 대한 수요가 늘어나는 것이 당연하다. 실제로 어떤 대형 금융기관들은 생성형 AI 사용 사례를 무려 400개까지 식별했다. 모든 조직이 같지는 않겠지만, 성숙한 대다수 기업은 RAG를 쓰는 첫 두 해 안에 사업 운영에 유의미한 가치를 주는 생성형 AI 사용 사례를 최소 30개는 식별할 수 있을 것이다.

RAG 시스템은 기계학습, 소프트웨어 엔지니어링, 도메인 특화 지식의 교차점에 앉아 있어 다양한 역량을 갖춘 팀을 요구한다. 주된 난관은 다음 역량 묶음 사이의 간극을 메울 사람을 모으는 데 있다.

사정을 더 어렵게 만드는 것은, LLM과 RAG에 관한 지식 자체가 비교적 새롭고 우리가 본 적 없는 속도로 계속 변한다는 사실이다. 모든 모범 사례를 따라가고 그 복잡성에 대한 깊은 이해를 유지하는 일은 유능한 대다수 팀에게도 꽤 어렵다. 팀원 각자가 자기 분야의 전문가여야 하고, 앞으로 더 심해질 것으로 예상되는 AI 인재 경쟁은 이것을 실제적인 난관으로 만든다.

결론은 이렇다. 조직으로서 전체 파이프라인을 직접 만들려면 AI 엔지니어링, 기계학습 엔지니어링, 데브옵스, 보안 전문성을 가진 인력의 채용과 역량 개발에 지속적이고 적극적인 투자를 감당할 준비가 되어 있어야 한다. 대안은 차별화되지 않는 구성요소에는 턴키 RAG 서비스를 채택하고, 사업의 필요와 요구사항에는 사내 도메인 전문성과 인재를 활용하는 것이다.

총소유비용

애플리케이션을 POC에서 프로덕션으로 옮길 때는 필요한 총소유비용(TCO)을 고려하고 예산을 계획하는 것이 도움이 된다. 성공적인 최초 배치만이 아니라 RAG와 에이전틱 RAG의 추가 사용 사례까지 감당할 예산이 있는지 확인하기 위해서다.

직접비

스택에 포함된 어떤 서비스나 구성요소 라이선스에 대해 벤더에게 직접 지불하는 비용이다.

간접비와 지속비

선행 지출을 넘어 여러 간접 요인이 전체 TCO에 기여한다. 스택이 커지며 데이터가 늘고 사용 사례가 확장되고 질의량이 증가하면 연산과 저장 필요가 시간에 따라 늘어난다. 게다가 각 벤더와의 지속적 지원 계약, 정기적 시스템 업데이트, 인프라 모니터링이 무시할 수 없는 비용을 빠르게 더한다. IT 조직과 그 요구사항에 따라 기존 기업 소프트웨어나 서드파티 도구와 스택을 통합하는 비용, 데이터 적재·테스트·데브옵스·모니터링을 위한 추가 시스템 구현 비용, 보안·프라이버시 통제 비용이 발생할 수 있다.

그 밖의 고려사항

철저한 TCO 평가는 침입 탐지, 정기 감사, 조직이 준수해야 하는 추가 요구사항 같은 사이버보안 통제도 반영해야 한다. 그리고 불행히도 어떤 시스템도 다운타임에 완전히 저항하지 못한다. 프로덕션 규모에서는 흔히 사업 연속성 요구사항과 복구 해법을 지켜야 하고, 그것이 비용을 더 얹는다. 이를 위해 다중 리전 배포 같은 고가용성(HA) 아키텍처를 구현할 수 있다. 주 사이트가 실패하면 자동 페일오버로 정상적인 보조 사이트로 신속히 전환해 사업 연속성을 보장한다. 물론 추가 비용이 들고, 그래서 TCO에 영향을 준다.

비용 모니터링

토큰당 과금 LLM API와 오토스케일링 연산에서 비용 급등 위험이 특히 높으므로, 강한 경보와 함께 세분화된 비용 모니터링을 구현해야 한다. 프로덕션 아키텍처에서 클라우드 공급자와 LLM 벤더의 청구·사용 대시보드를 주 모니터링 시스템에 직접 통합하고, 예산 기반 경보와 속도 제한을 포함해야 한다.

비용을 통제하는 또 하나의 전략은 캐스케이딩 모델 접근을 채택하는 것이다. 모든 질의를 가장 강력하고 가장 비싼 LLM에 보내는 대신 “라우터” 로직을 구현한다. 이 라우터는 질의를 먼저 더 작고 빠르고 훨씬 싼 모델에 보낸다. 그 모델이 높은 신뢰도의 답을 주거나 질의가 “단순”으로 표시되면 응답을 즉시 돌려준다. 질의가 복잡하거나 싼 모델이 실패한 경우에만 비싼 프런티어 모델로 “에스컬레이션”한다. 이 계층적 접근은 가장 어려운 질문에 대한 높은 품질을 유지하면서 질의당 평균 비용을 극적으로 낮출 수 있다.

LLM 라우터를 직접 구현할 수도 있고, LiteLLM이나 Not Diamond 같은 기존 라이브러리나 서비스를 쓸 수도 있다. 어떻게 구현하든 늘 그렇듯 관측성과 로깅 시스템에 통합하는 일이 중요하다. 어떤 유형의 호출이 있었는지 보고하는 데 그치지 않고 특정 LLM의 비용에 근거해 비용을 자동으로 계산하게 만들어야 한다.

총소유비용의 복잡성은 기업이 턴키 RAG 해법을 택하는 흔한 이유다. 단일 벤더가 RAG의 모든 기능을 제공하면 비용 구조가 유의미하게 단순해지고, 초기와 장기 양쪽에서 TCO가 훨씬 예측 가능하고 관리 가능해진다.

RAG 평가

높은 응답 품질, 낮은 환각, 낮은 지연, 높은 가용성을 갖춘 건강한 파이프라인을 유지하는 일은 규모를 키울수록 까다로워진다. 이 난관을 다루는 데 도움이 되는 중요한 구성요소가 신뢰할 수 있는 RAG 평가 프레임워크이며, 6장에서 논의한다.

파이프라인을 지속적으로 측정하는 일은 흔히 검색 지표와 생성 지표의 확장 가능하고 효율적인 구현, 그리고 종단간 응답 품질 평가를 요구한다. 여기까지 POC에서 프로덕션으로 옮길 때 마주할 난관을 많이 짚었지만 절망할 필요는 없다. 많은 기업이 이 이행을 성공적으로 항해하고 있다.

참조 프로덕션 아키텍처

프로덕션으로 옮기는 일의 중대한 난관을 개괄했으니, 이제 무엇에서 어떻게로 넘어간다. 높은 지연, 보안, 벤더 혼란 같은 문제를 다루려면 의도적인 시스템 설계가 필요하다. 견고하고 확장 가능한 RAG 파이프라인은 결합 해제된 마이크로서비스 기반 시스템으로 만드는 것이 가장 좋다. 지연을 논의할 때 짧게 서술한 이 아키텍처가 복잡성을 관리하고 독립적 확장을 가능하게 하는 열쇠다. 그런 시스템을 만드는 방법은 여러 가지이고, 다음은 그중 하나의 참조 아키텍처다.

적재 측

적재 처리가 끝나면 임베딩 벡터는 벡터 DB에 저장되고, 텍스트 자체는 어휘 검색 시스템에 저장된다. 메타데이터를 추출한 경우 이후 검색을 위해 어휘 검색 시스템에 함께 저장하는 것이 일반적이다. 이 마이크로서비스 각각을 고가용성으로(여러 인스턴스로) 구현할 수 있고, 물론 모두 종단간 암호화 같은 보안 모범 사례를 구현해야 한다.

질의 측

• 질의 문자열이 질의 임베딩 서비스로 보내지고, 이어 벡터 데이터베이스를 이용한 시맨틱 검색으로 간다. 동시에 같은 질의 문자열이 어휘 검색 시스템으로 보내진다.
• 벡터 검색과 어휘 검색 양쪽에서 온 관련 청크가 결합되어 최종 관련성 순위를 위해 재순위 서비스로 보내진다.
• 이 단계에서 필요하다면 청크가 프롬프트를 통해 LLM에 보내지기 전에 PII 마스킹을 적용할 수 있고, 이어 가드레일이 적용된다. 이 모든 것이 생성 마이크로서비스 안에서 일어나며 최종 응답이 나온다.

앞서 지연을 논의할 때 언급한 대로 캐싱은 이 아키텍처 전체에 걸쳐 검색·청크·전체 응답 수준에서 적용할 수 있다. 보안은 저장 시와 전송 시 모두, 모든 계층과 모든 구성요소에서 다뤄져야 하며, 취약점 탐지와 완화의 모범 사례를 각 구성요소와 마이크로서비스에 적용해야 한다.

POC에서 프로덕션으로의
성공적 이행

이제 위험과 난관을 알았으니 프로덕션 배치를 계획할 준비가 되었다. 복잡한 기술 스택의 어떤 배치와 마찬가지로 세심한 계획이 위험 완화에 도움이 되고, 생성형 AI도 예외가 아니다. 대부분의 경우 POC가 이미 손에 익은 경험을 어느 정도 제공했으므로, 물어야 할 좋은 질문 목록과 무엇이 중요한지에 대한 감각을 갖고 있을 것이다.

POC에서 배운 것을 정리한다

POC의 모든 학습을 요약한 보고서를 만드는 것에서 시작한다. 보고서에 넣을 만한 질문과 세부는 다음과 같다.

이 보고서를 적어 두면 실제 프로덕션 구현의 목표를 정의할 준비가 된다.

목표와 요구사항을 정의한다

실제 구현에 착수하기 전에 프로덕션 배치의 목표와 요구사항을 정의해 두면 큰 도움이 된다. 사실 사업 목표를 다시 들여다보고 POC의 목적이 프로덕션 목표와 정렬되는지 확인하는 것도 좋다. 해당되는 곳에서는 핵심성과지표(KPI)로 요구사항을 수치로 정의한다. POC 보고서의 결과를 채워 넣고, 프로덕션 배치에서 그것이 얼마나 나아져야 하는지를 정의한다.

아래는 Vectara가 많은 고객과 일하며 본 KPI와 요구사항이다. 이 목록을 그대로 쓰거나 필요에 맞게 고쳐도 된다. 예시 값은 설명을 위한 것이며, 당신의 POC 값이나 프로덕션 목표는 물론 다를 수 있다.

표 4-2의 항목에 더해, 프로덕션 배치에서 계획해야 할 시스템 고려사항이 더 있다.

계획이 끝나면 구현으로 넘어간다. 여기서는 프로젝트 관리, 애자일 개발, 강한 팀 조율이라는 전통적인 실행 역량이 필요하다. 기업 안에서의 성공적인 기술 구현은 조직마다 크게 다른 R&D·IT 관행에 크게 의존하며, 이 책의 범위를 넘어선다.

지속적 성공의 보장

첫 프로덕션 배치가 2주 앞으로 다가왔고 이제 조직 전체에 굴릴 준비가 되었다고 하자. 그다음은 무엇인가.

무엇보다 먼저 순조롭고 성공적인 출시를 보장해야 한다. 그러려면 직원이나 고객에게 새 애플리케이션을 교육해, 모든 역량을 온전히 알고 언제 어떻게 쓰는 것이 가장 효과적인지 이해하게 만드는 일이 흔히 필요하다.

사용자가 애플리케이션을 쓰는 동안, 공들여 심어 둔 지표에 세심한 주의를 기울이는 일이 결정적이다. 질의 응답에 대한 사용자 만족도만이 아니라 지연과 시스템 성능까지 봐야 한다.

배치 후 첫 2주 안에 어떤 문제가 생기는 일은 드물지 않다. 예상하지 못했던 것, 출시 전 테스트에서 드러나지 않았던 것들이다. 그러니 모든 지표를 살펴보고 어떤 문제든 빠르게 해결하도록 해야 한다. 강한 모니터링과 관측성 역량을 구현의 일부로 갖추면 성공 확률이 극적으로 높아진다. 사용자 질의와 응답을 들여다보고, 지연 지표를 이해하고, 일상 운영에서 발생하는 문제를 기록함으로써 실제 애플리케이션 문제를 빠르게 식별하고 신속히 손을 쓸 수 있다.

초기 출시가 순조롭게 지나갔다 해도(빠르게 손을 쓸 몇 가지 문제는 예상해야 한다) 앞으로 할 일이 상당히 남아 있다. 시스템 유지나 질의량과 사용량 증가에 따른 연산 업그레이드 같은 잡무에서, 가동률 문제의 해결까지 걸쳐 있다. 때때로 구성요소를 업그레이드해야 할 수도 있다. 벡터 데이터베이스에서 보안 취약점을 발견하면 업그레이드가 필요해지는 식이다.

새 기법을 파이프라인에 들여올 때

새 기법을 파이프라인에 통합하는 일은 더 큰 난관이다. 모든 사용 사례에서 일관되게 5% 품질 향상을 보이는 새 임베딩 모델이 나왔다고 상상해 보자. 채택하고 싶지 않겠는가. 물론 그럴 것이다. 그러려면 이 새 모델을 파이프라인의 적재 시점과 질의 시점 양쪽에 구현하고, 종단간으로 전부 테스트하고, 시스템 의존성을 갱신하고, 옛것과 새것을 비교하는 RAG 평가를 돌려 모든 것이 잘 작동하고 그 5% 향상이 실제로 보이는지 증명해야 한다.

말은 쉽지만 실제로는 훨씬 어려울 수 있다. 새 모델의 지연이 훨씬 높을 수 있다. 다른 유형의 GPU 머신이 필요해서 그것을 구매하거나 하이퍼스케일러에서 임대해야 할 수도 있다. 그리고 이것은 하나의 예일 뿐이다. 새 유형의 LLM, 더 나은 하이브리드 검색 알고리즘, 새 재순위기, 개선된 환각 검출이나 교정 구성요소를 넣고 싶을 수 있다.