제1장 — RAG 아키텍처의 진화

LLM Primer III: RAG로 강화하는 엔터프라이즈 AI를 챕터별로 소개하는 시리즈의 첫 번째 글입니다. 베이스 모델의 구조적 두 한계 — 얼어붙은 지식과 사라진 출처 — 가 단 하나의 아키텍처적 답을 갖는다는 것, 그리고 그 답이 삼 년 사이 네 개의 얼굴로 자라났다는 이야기 안으로 함께 들어갑니다.

이 장이 존재하는 이유

고정된 코퍼스로 학습된 트랜스포머에는 추가 학습으로 완전히 지우기 어려운 두 가지 한계가 있습니다. 지식은 코퍼스가 끝난 날에서 멈춥니다. 그리고 한 문장이 어느 문서에서 왔는지 말해 줄 수 없습니다 — 그 문장은 어느 한 출처의 인용이 아니라 여럿에 대한 통계적 평균이기 때문입니다. 첫 번째 결함은 최근 사안에 자신만만하게 틀린 답을 만들어 냅니다. 두 번째는 자신만만하게 틀린 인용을 만들어 냅니다. 둘이 합쳐지면 이제는 익숙해진 엔터프라이즈의 병증이 됩니다 — 권위 있게 읽히지만 존재하지 않는 조항으로 링크되는 답.

RAG는 이 둘에 대한 아키텍처적 답을 한꺼번에 내놓습니다. 모델에게 모든 것을 미리 알라고 하는 대신, 추론 시점에 여러분이 통제하는 코퍼스에서 관련 자료를 꺼내 건네줍니다. 코퍼스는 재학습 없이 갱신됩니다. 검색된 구절은 의도해서 꺼낸 것이기에 그대로 인용이 됩니다. 모델의 일은 회상에서 종합으로 줄어듭니다. 나머지는, 그 단순한 한 수가 삼 년 동안 점점 더 강력해진 네 개의 아키텍처로 자라난 이야기입니다.

1.1 나이브 RAG: 임베드, 검색, 채우기

가장 단순한 형태는 모든 공개 튜토리얼이 지금도 설명하는 그 모습입니다. 오프라인: 코퍼스를 청크로 나누고, 각 청크를 임베드해 벡터를 인덱스에 씁니다. 온라인: 쿼리를 임베드하고, 가장 가까운 상위 k개 청크를 가져와 프롬프트에 이어 붙여 모델에 보내고, 그 청크들을 인용으로 단 답을 돌려줍니다. 함수 호출 두 번과 벡터 검색 한 번.

데모는 잘 돕니다. 제품은 좀처럼 그렇지 않습니다. 최근접 이웃 유사도는 적합성의 측정이 아니라 그 대리물이고, 일반 웹 텍스트로 학습된 임베딩 모델은 사과 과수원 수확량과 애플의 분기 실적을 흔히 혼동합니다. 청커는 문장이 어디서 끝나고 표가 어디서 시작하는지에 대한 신호를 갖고 있지 않습니다. 한 번의 검색 패스는, 답이 세 문서에 흩어져 있는 질문을 감당하지 못합니다. 그리고 검색이 실패하면 모델은 돌아온 것이 무엇이든 그것을 가지고 종합합니다 — 인용은 진짜지만, 그것은 답의 어느 부분도 받쳐 주지 않습니다.

1.2 어드밴스드 RAG: 같은 파이프라인 둘레의 휴리스틱

두 번째 자세는 임베드-검색-생성의 뼈대를 유지하면서, 검색 호출의 앞뒤로 처리를 더해 갑니다. 검색 전 보강은 쿼리를 겨냥합니다 — 재작성, 확장, 분해, 그리고 가상의 답을 한 번 써서 그것을 쿼리로 임베드하는 HyDE. 검색 후 보강은 후보를 겨냥합니다 — 쿼리와 구절을 함께 점수 매기는 크로스 인코더 리랭커, 중복 제거, 메타데이터 필터링, 컨텍스트 압축.

얻는 폭은 작지 않습니다. 벡터 리트리버 위에 크로스 인코더 리랭커를 얹으면 상위 5의 적합도는 보통 50~70% 구간에서 75~90% 구간으로 옮겨 갑니다. 원 표현이 모호했던 경우 쿼리 재작성은 5~10점을 더 얹어 줍니다. 오늘 그냥 「RAG」라고 불리는 대부분의 프로덕션 시스템은 이 아키텍처를 돌리고 있고, 폭넓은 엔터프라이즈 문제군 — 내부 문서 Q&A, 지원 부담 감소, 지식 베이스 검색 — 에 대해서는 적절한 투자 수준입니다. 다만 유연성을 주지는 않습니다. 모든 쿼리가 여전히 같은 파이프라인을 지나갑니다.

1.3 모듈러 RAG: 조립 가능한 컴포넌트와 명시적 라우팅

2024년에 이르러 연구와 도구가 모듈러 RAG로 수렴했습니다. 같은 기법들이 여전히 자리해 있지만, 이제는 서로 교체 가능한 별개의 컴포넌트로 노출되고 파이프라인은 요청별로 조립됩니다. 라우터가 어떤 리트리버를 호출할지를 정하고 — 어쩌면 밀집 벡터 인덱스, BM25 인덱스, SQL 저장소, 외부 API — 그 결과는 흔히 RRF(reciprocal rank fusion)로 융합됩니다. 리랭커는 쿼리 유형에 따라 선택되고, 생성기는 요구되는 품질 등급에 따라 선택됩니다. 아키텍처는 단계의 선이 아니라 컴포넌트의 그래프가 되었습니다.

실용적 귀결이 둘. 첫째, 시스템이 이전 자세들과는 다른 방식으로 테스트 가능해집니다 — 컴포넌트 단위로 따로 평가하고 교체할 수 있습니다. 둘째, 시스템이 쿼리 클래스별로 튜닝 가능해집니다: 사실 조회는 빠른 리트리버와 작은 생성기를 거치고, 다문서 종합은 여러 리트리버와 큰 생성기를 거치되 같은 컴포넌트 라이브러리에서 끌어다 씁니다. 대가는 운영입니다. 답이 틀렸을 때 어디서 잘못된 것인가?라는 질문에 이제 가능한 답이 여럿이고, 팀은 실패를 단일 컴포넌트로 위치 특정할 수 있는 계측이 필요합니다. 관측가능성에 먼저 투자한 다음 모듈러로 가십시오 — 그 반대가 아니라.

1.4 에이전틱 RAG: LLM이 파이프라인을 운전한다

네 번째 자세는 앞선 세 자세가 조용히 공유하던 가정 — LLM이 마지막 단계라는 것 — 을 뒤집습니다. 에이전틱 RAG에서 LLM은 파이프라인을 운전합니다. 도구 카탈로그(벡터 검색, SQL, 웹 페치, 리랭커, 계산기)가 주어지면, 모델은 생각하고, 도구를 고르고, 결과를 관찰하고, 다시 생각하고, 답을 얻었거나 스텝 한도에 닿으면 멈춥니다. 아키텍처는 더 이상 파이프라인이 아니고, 모델이 매 쿼리마다 새로 쓰는 작은 프로그램이 되었습니다.

이로써 다단계 계획, 동적 도구 선택, 그리고 planner/retriever/critic/writer 같은 다중 에이전트 협업 패턴을 얻습니다. 대가는 지연, 토큰 비용, 재현 가능성입니다 — 하나의 쿼리가 이제 고정된 시퀀스가 아니라 결정의 나무이고, 병리적 쿼리는 답을 내기 전 여러 턴을 헛돌 수 있습니다. 프로덕션의 에이전틱 시스템은 고정 파이프라인이 고민할 필요 없던 예산 통제, 스텝 한도, 타임아웃 정책을 두어야 합니다. 옳은 쓸 자리는 깊이가 가변적이고 예측 어려운 질문입니다 — 연구 종합, 판례 위에서의 법률 조회, 문헌 리뷰. 그른 자리는 정적인 지원 봇으로, 그 일감이 필요로 하지 않은 분산을 에이전틱 루프가 보태 줄 뿐입니다.

1.5 RAG와 파인튜닝

모든 팀이 결국 묻는 질문입니다. 솔직한 틀짓기는, 둘은 다른 문제를 푼다는 것입니다. RAG는 지식 문제를 다룹니다 — 모델이 X를 모르고, X는 바뀌며, 사용자는 인용을 필요로 합니다. 파인튜닝은 행동 문제를 다룹니다 — 모델이 답은 알지만 잘못된 형식으로 보여 주거나, 회사 템플릿을 따르지 않거나, 짧아야 할 자리에서 늘어집니다. RAG는 셋업이 싸고 쿼리당 비쌉니다. 파인튜닝은 한 번이 비싸고 쿼리당 쌉니다. RAG는 분 단위로 반복합니다(문서를 바꿉니다). 파인튜닝은 며칠 단위로 반복합니다. 쓸모 있는 휴리스틱: 실패가 모델이 모른다는 것이라면 RAG로 손을 뻗고, 모델은 아는데 잘못 한다는 것이라면 파인튜닝으로 손을 뻗습니다. 성숙한 시스템은 결국 둘 다 하지만, RAG로 시작하시기 바랍니다 — 대부분의 엔터프라이즈 실패는 행동이 아니라 지식의 실패이기 때문입니다.

제1장이 준비하는 것

모든 RAG 아키텍처는 — 네 자세 중 어느 것을 고르든 — 원천 문서를 얼마나 잘 읽을 수 있느냐의 하류에 놓입니다. 최첨단 모듈러 파이프라인에 에이전틱 오케스트레이터가 얹혀 있어도, 그것은 어딘가 상류의 파싱 단계에서 떨어져 나온 청크를 가지고 일합니다. 그 단계가 표의 구조를 잃었거나, 다단 읽기 순서를 뒤섞었거나, 그림 캡션을 깨진 OCR로 바꿔치웠다면, 모든 하류 컴포넌트는 오염된 입력 위에서 추론하고 있는 셈입니다. 아키텍처가 시스템의 천장을 정한다면, 파서는 그 바닥을 정합니다. 대부분의 프로덕션 시스템에서는 바닥이 더 중요한데, 대부분의 프로덕션 시스템이 천장 근처에 있지 않기 때문입니다.

다음 → 제2장: 지능형 문서 파싱. 단순한 PDF-텍스트 추출기가 검색 품질을 어떻게 조용히 무너뜨리는지, 레이아웃 인지 파싱이 실제로 무엇을 보존하는지, 그리고 페이지 이미지 자체에서 검색하는 멀티모달 대안.