Enterprise AI Infrastructure · RAG 2.0
에이전틱 워크플로우 시대의 RAG 아키텍처 — 청킹·임베딩·오케스트레이션 실전 기준
2026년 6월 | Enterprise RAG · Agentic AI · Vector DB
올해 들어 비슷한 질문을 여러 번 받았다. "컨텍스트 윈도우가 수십만 토큰 단위로 늘었는데, 굳이 RAG를 유지할 이유가 있나요?" 틀린 질문은 아니다. 하지만 현장에서 실제로 시스템이 무너지는 원인을 추적해보면 답은 뜻밖의 곳에서 나온다. 모델이 멍청한 게 아니라, 모델에 넣어주는 데이터가 엉터리였던 것이다.
수십억 개 토큰으로 구성된 사내 데이터 레이크를 아무런 필터링 없이 LLM에 그대로 집어넣는다고 상상해보자. 비용은 두 번째 문제다. 첫 번째 문제는 RBAC다 — 팀장과 신입사원이 같은 컨텍스트 창을 공유하는 순간 보안 거버넌스 전체가 무너진다. 여기에 에이전틱 워크플로우가 더해지면 위험은 배가된다. 에이전트는 단일 조회가 아니라 수십 번의 추론·검색·관찰 루프를 반복한다. 검색 단 한 번의 오염이 이후 전체 추론 경로를 오염시키는 현상 — 흔히 메모리 오염(Memory Poisoning)이라고 부른다 — 은 실제로 프로덕션 환경에서 자주 일어난다.
결국 2026년에도 RAG는 살아있다. 오히려 에이전틱 시대에 들어서면서 검색 레이어의 정밀도가 시스템 전체의 신뢰도를 결정하는 1차 요인이 됐다. NeurIPS 등에 발표된 최근 연구들도 같은 결론을 가리킨다 — RAG 시스템 오류의 대다수는 생성 모델 자체가 아니라 검색 실패 혹은 잘못된 청킹에서 비롯된다.
문서를 어떻게 자르는가 — 청킹 전략의 현실
RAG 파이프라인에서 가장 과소평가되는 단계가 청킹이다. 많은 팀이 여전히 글자 수나 토큰 수 기준의 고정 크기 분할을 쓰고 있는데, 이 방식의 문제는 단순하다. 문장 중간에서 잘리면 맥락도 같이 잘린다. 검색기가 돌려주는 게 질문과 전혀 무관한 파편이 되고, 에이전트는 불완전한 정보로 추론을 시작한다. 이를 컨텍스트 부패(Context Rot)라고 부른다.
시맨틱 더블 패스 병합 (SDPM)
문장 간 코사인 유사도를 계산해서 주제가 전환되는 지점에서 자르는 기본 시맨틱 청킹에 스킵 윈도우(skip-window)를 추가한 방식이다. 바로 옆 문장만 보는 게 아니라 그 다음 다음 청크까지 들여다보면서, 중간에 수식·코드·인용문이 끼어들어도 전체 맥락의 흐름을 유지한다. 기술 매뉴얼이나 API 명세서처럼 이질적인 포맷이 섞인 기업 문서에서 체감 차이가 뚜렷하다. 단점은 반복적인 임베딩 연산으로 인덱싱 비용이 올라간다는 것이다.
지연 청킹 (Late Chunking)
분할 순서를 뒤집는다. 기존 방식이 '먼저 자른 뒤 임베딩'이라면, 지연 청킹은 문서 전체를 먼저 트랜스포머에 통과시켜 양방향 어텐션으로 글로벌 맥락을 흡수시킨 뒤 청크로 나눈다. 덕분에 문서 앞부분에서 정의된 개념이 뒷부분 청크에서 대명사로 지칭돼도 벡터에 그 참조가 담긴다. 법률 계약서나 금융 규제 문서처럼 상호 참조가 복잡한 경우 검색 재현율이 눈에 띄게 오른다.
주의할 점
지연 청킹은 코퍼스 단위 검색률은 대폭 끌어올리지만, 단일 문서 내 미세한 주제 간 판별력은 다소 떨어진다. 모든 청크가 동일한 글로벌 맥락을 공유하다 보니 벡터 공간에서 청크 간 구별이 희석되기 때문이다. 하위 주제가 다양한 긴 문서에는 챕터 단위로 먼저 나눈 뒤 챕터 내에서 지연 청킹을 적용하는 하이브리드 방식이 더 안전하다.
계층적 부모-자식 아키텍처
청크 크기 딜레마를 구조적으로 해결한다. 작은 자식 청크(100~200 토큰)는 검색 정밀도는 높지만 LLM이 해석할 맥락이 부족하다. 큰 부모 청크(800~1,000 토큰)는 맥락은 풍부하지만 노이즈가 많아 검색 적합성이 떨어진다. 이 구조는 벡터 DB에 작은 자식 청크만 저장하되, 각 자식 청크 메타데이터에 부모 청크 포인터를 기록한다. 검색은 자식 청크로 정밀하게 수행하고, LLM에 실제로 주입하는 것은 포인터를 통해 끌어온 부모 청크 전체다. 검색 정밀도와 생성 단계 맥락 공급을 동시에 잡는 구조다.
전략 | 적합한 워크로드 | 주요 트레이드오프 |
재귀적 분할 | 범용 RAG, 일반 텍스트 문서 | 구현 단순, 의미 전환 포착 약함 |
SDPM | 기술 매뉴얼, 수식·코드 혼재 문서 | 인덱싱 연산 비용 높음 |
Late Chunking | 법률·규제·계약 문서, 장문 보고서 | 문서 내 미세 주제 판별력 저하 가능 |
Parent-Child | 멀티 홉 추론, 에이전트 워크플로우 | 2단계 조회로 캐싱 미최적화 시 레이턴시 발생 |
임베딩 모델 선택 — MTEB 점수만 보면 실패한다
2026년 MTEB 리더보드 최상단을 보면 KaLM-Embedding-Gemma3-12B가 평균 72.32점(검색 75.66점)으로 현존 최고 성능을 찍고 있다. 그런데 이 모델을 단일 인스턴스에 올리려면 44.8GB 이상의 GPU 메모리가 필요하다. 수준급 모델 대비 2~3점 성능 차이에 인프라 비용이 기하급수적으로 올라가는 수확 체감 구간이다.
기업 환경에서 TCO 대비 성능의 균형점은 4B~8B 체급에 있다. Qwen3-Embedding-4B는 약 8GB 메모리로 MTEB 평균 69.45점을 낸다. 12B 모델과 성능 차이가 극히 작으면서 상용 서버에서 무리 없이 돌아간다. 엣지 환경이나 CPU 기반 추론이 필요하다면 BGE-M3가 2GB로 54점 이상을 낸다. 워크로드별 세부 점수(분류·군집화·검색)를 보지 않고 전체 평균만 보고 모델을 고르면 불필요한 인프라 낭비나 병목이 생긴다.
마트료시카 표현 학습 (MRL) — 차원 축소의 실용화
마트료시카 표현 학습(Matryoshka Representation Learning, MRL)은 훈련 단계부터 벡터 앞쪽 차원에 핵심 의미 정보를 집중시켜서, 뒷부분을 잘라내도 성능 저하가 미미하도록 설계된 구조다. Gemini Embedding 2와 최신 OpenAI 임베딩 모델이 이 방식을 채택하고 있다. 기본 3,072 차원으로 생성된 벡터를 768 차원으로 잘라써도 검색 품질은 90% 이상 유지되면서 스토리지 비용과 메모리 I/O 부담이 줄어든다.
여기서 더 나아가 다단계 리랭킹 파이프라인에 활용할 수 있다. 1차 검색은 256 차원 초경량 벡터로 상위 후보 100개를 빠르게 추리고, 그 100개에 대해서만 원래의 3,072 차원 전체 벡터로 정밀 재순위화(reranking)한다. 무거운 연산 비용을 내지 않으면서 최고 수준의 검색 정확도를 유지하는 구조다.
멀티모달 임베딩 — Gemini Embedding 2
기존 파이프라인은 이미지·비디오·오디오를 다룰 때 OCR이나 STT 전처리를 거쳐야 했다. 이 과정에서 원본에 담긴 비언어적 정보가 영구적으로 소실된다. Gemini Embedding 2는 별도 변환 레이어 없이 텍스트·이미지·비디오 클립·오디오·복잡한 레이아웃의 PDF를 단일 벡터 공간에 직접 매핑한다. 이미지와 텍스트가 혼재한 기술 문서나 제조 현장 데이터를 다루는 팀이라면 파이프라인 단순화 효과가 상당하다.
검색 품질을 높이는 두 접근 — GraphRAG와 HyDE
단순 벡터 유사도 검색의 한계는 복잡하게 얽힌 사내 데이터에서 두드러진다. "A 프로젝트 실패 원인이 B팀 인력 변동과 연관이 있나"처럼 여러 문서를 건너뛰며 추론해야 하는 멀티 홉 질문에 단일 벡터 룩업은 답을 내지 못한다.
GraphRAG는 문서에서 엔티티와 관계를 추출해 지식 그래프를 구성한다. Leiden 알고리즘으로 상위 군집 요약을 미리 만들어두면 거시적 동향 파악과 미시적 연관 검색을 오갈 수 있다. 단순 의미 유사도 매칭을 초월해 구조적 관계 추론이 필요한 워크로드에서 효과적이다.
HyDE(Hypothetical Document Embeddings)는 다른 방향에서 접근한다. 짧고 모호한 사용자 쿼리로 바로 검색하는 대신, LLM이 해당 쿼리에 대한 가상의 이상적인 답변을 먼저 생성하고, 그 가상 문서와 가장 유사한 실제 문서를 찾는다. 쿼리 벡터의 품질이 낮을 때 검색 정확도를 끌어올리는 데 효과적이다.
에이전틱 워크플로우와 지연 시간 복리 누적 문제
단일 패스 검색 → 생성의 정적 RAG 파이프라인은 에이전틱 환경에서 금세 한계를 드러낸다. ReAct 패턴을 따르는 에이전트는 하나의 문제를 풀기 위해 추론-검색-관찰 루프를 3번에서 10번 이상 반복한다. 여기서 실무자들이 간과하기 쉬운 문제가 있다.
지연 시간 복리 누적 (Compounding Latency)
벡터 DB 조회에 250ms가 걸린다고 가정하면, 에이전트가 8번 루프를 돌 때 DB I/O 대기만으로 2초가 쌓인다. LLM 추론 시간까지 더하면 음성 봇이나 실시간 고객 응대 시스템의 SLA를 가볍게 초과한다. 단일 요청에서 미미해 보이는 레이턴시가 루프가 쌓이면 복리로 증가한다는 점이 핵심이다. 에이전틱 인프라에서 Qdrant 같은 인메모리 기반 검색 환경(15~30ms 응답)은 단순한 성능 최적화가 아니라 서비스 가능 여부 자체를 가르는 설계 요소다.
LlamaIndex vs LangGraph — 배타적 선택이 아니라 레이어 설계
데이터 레이어
LlamaIndex
청킹·임베딩·벡터 DB 저장, 쿼리 라우팅, 복잡한 검색 경로 설계에 강점. "어디서 어떤 데이터를 어떻게 꺼낼 것인가"를 처리하는 인프라. GraphRAG 같은 관계형 지식망 탐색 구현에서도 핵심 엔진으로 쓰인다.
제어 흐름 레이어
LangGraph
상태 관리·다단계 추론 루프·Human-in-the-loop 중단/재개·복수 에이전트 간 분기·병합에 특화. "어떤 순서로 어떻게 협력할 것인가"를 관장하는 중앙 통제소.
실제 기업 환경의 최적 구성은 두 프레임워크를 배타적으로 선택하는 게 아니라 레이어로 쌓는 것이다. LlamaIndex로 정밀한 검색 파이프라인을 만들고 전체를 하나의 도구(Tool) 객체로 래핑한 뒤, LangGraph 기반 멀티 에이전트 오케스트레이터가 상위에서 전체 워크플로우를 제어하며 필요할 때 검색 툴을 호출하는 구조가 2026년 현장에서 검증된 베스트 프랙티스다.
평가 지표 없이는 운영 신뢰도가 없다
"답변이 꽤 잘 나오는 것 같다"는 직감으로는 엔터프라이즈 AI를 운영할 수 없다. RAGAS나 DeepEval 같은 정량 평가 프레임워크를 CI/CD 파이프라인에 연동해야 한다. 핵심 지표는 세 가지다 — 검색된 문맥이 질문과 얼마나 관련 있는지(Context Relevance), 답변이 주어진 문서에만 근거하고 있는지(Faithfulness), 환각 발생 여부. 이 수치를 모니터링하지 않으면 모델 버전 업데이트나 데이터 추가 이후 품질 저하를 감지하지 못한다.
에이전틱 RAG를 도입할 때 가장 흔한 실수는 처음부터 전사 데이터를 모두 엎고 시작하는 것이다. 특정 부서의 작고 명확한 워크플로우 하나를 골라 파일럿을 만들고, 시맨틱 청킹과 평가 지표를 제대로 붙여서 성공 사례를 확보하는 것이 현실적인 출발점이다. 청킹과 임베딩 레이어가 탄탄하지 않으면 그 위에 아무리 정교한 에이전트를 올려도 모래 위에 쌓는 구조다. 가장 화려해 보이는 부분이 오케스트레이션처럼 보여도, 시스템의 실제 한계는 데이터 처리 파이프라인에서 정해진다.
S’abonner à 'BLOGGER'
En vous abonnant à ce site, vous recevrez en avant-première les dernières mises à jour, comme les nouveaux articles, par notification et par e-mail.
Inscrivez-vous à Slashpage et abonnez-vous à 'BLOGGER' !
Inscrivez-vous à Slashpage et abonnez-vous à 'BLOGGER' !
S’abonner
