\”RAG는 죽었다\”를 제대로 읽으려면 4층으로 보라

이 글은 「AI 공부 지도 20부작」의 11편(M1) 입니다.
앞 편: B3 — Fine-tuning·RAG·Prompt 중에 뭘 쓸지 구분하기
다음 편: M2 — Long-context와 Memory는 같은 이야기인가

0. 시리즈 안내 — 여기서부터 “실무 섹션 M” 입니다

AI 공부 지도 시리즈가 F(Foundation) → B(Bridge) → M(Meta·실무) 로 흐른다고 첫 글에서 말씀드렸죠. 이번 편부터가 M 시리즈예요. F1~F6 에서 LLM·Transformer·딥러닝·embedding·attention·gradient descent 까지 기초 감각을 잡았고, B1~B3 에서 프롬프트·에이전트·fine-tuning 대 RAG 대 프롬프트 비교를 했습니다. 이제 그 위에서 실무 이야기를 시작합니다.

M 시리즈의 첫 편으로 retrieval 을 고른 건, 2026년 지금 가장 해석이 흐린 영역이 여기이기 때문이에요. 뉴스는 매일 “RAG 는 죽었다” 와 “RAG 는 계속 남는다” 사이를 왔다갔다 합니다. 제품은 “우리는 RAG 를 안 쓴다” 와 “우리는 RAG 를 쓴다” 를 같은 문장 안에 섞어 써요. 논문은 “Graph”, “Agentic”, “Memory”, “Doc-to-LoRA” 같은 서로 다른 단어를 같은 카테고리처럼 나열합니다. 이걸 한 덩어리로 읽으면 계속 혼란스러울 수밖에 없어요.

이 글의 목표는 하나입니다. “RAG” 라는 한 단어 안에 실제로는 네 개의 매우 다른 층이 들어있다는 감각을 만드는 것. 그 감각이 생기면 뉴스·제품·논문이 같은 속도로 선명해집니다.

1. “RAG 는 죽었다” 라는 말이 왜 자꾸 나오나

먼저 분위기부터. 요즘 AI 커뮤니티에서 “RAG 는 죽었다 (RAG is dead)” 라는 말이 주기적으로 돕니다. Anthropic 의 Claude Code 가 로컬 벡터 DB 없이 그냥 grep 과 파일 읽기 도구만 써서도 코드베이스를 잘 탐색하는 걸 보면서, 한쪽에서 “봐라, 비싸게 벡터 DB 구축하던 게 무색하다” 라고 주장하는 흐름이 있어요. 다른 쪽에서는 Gemini 1.5, Claude 4, GPT-5 같은 모델들의 컨텍스트 윈도우가 100만 토큰까지 올라가면서 “문서 통째로 넣으면 되는데 뭘 따로 검색해” 라는 주장이 나옵니다.

그런데 이 문장을 납작하게 받으면 안 돼요. 죽었다고 불리는 게 정확히 무엇이냐가 중요합니다.

실제로 현장에서 “죽었다” 고 불리는 건 하나의 좁은 영역이에요. “로컬 벡터 DB 를 미리 만들어 두고, 질문 들어올 때 한 번만 top-k 로 chunk 뽑아서 프롬프트 끝에 붙이는” 그 한 패턴. 그게 요즘 과대평가됐다는 지적이에요. RAG 의 다른 층들은 죽기는커녕 지금이 전성기예요. Perplexity 가 매일 웹을 검색하면서 답하는 방식, Claude Research 가 여러 번 재검색하는 방식, Microsoft GraphRAG 처럼 관계 그래프를 쌓는 방식, Doc-to-LoRA 처럼 문서를 아예 가중치로 만드는 방식 — 이건 전부 RAG 의 다른 층들에서 지금 뜨겁게 발전 중입니다.

그러니까 층 구분 없이 “RAG 죽었나” 를 물으면, 대답이 항상 양가적으로 나올 수밖에 없어요. 층을 쪼개면 질문이 달라지고, 답이 선명해집니다.

이 글은 그 층 쪼개기를 같이 해보는 글이에요.

2. Retrieval 을 한 덩어리로 보지 않는 훈련

제가 실무에서 가장 자주 겪는 혼란이 이겁니다. 누가 어떤 제품을 보여줬어요. “이거 RAG 쓴대.” 그 한 문장을 듣고는 감이 안 잡히는 거죠. 벡터 DB 가 돌아가는 건지, 모델이 검색을 여러 번 하는 건지, 그래프 구조가 있는지, 회사 문서가 모델 자체에 녹아 있는 건지 — 전혀 다른 동작들이 같은 한 단어 아래 묶여 있거든요.

뉴스도 마찬가지예요. “RAG 2.0 출시”, “RAG 는 이제 필요 없다”, “우리 회사는 RAG 로 환각을 잡았다” — 같은 단어가 세 문장에서 세 번 다 다른 걸 가리킵니다.

이 안개를 걷어내는 가장 단순한 방법은 층으로 나눠서 보기예요. 네 개로 나눕니다. 외울 필요는 없어요. 이 글을 다 읽으면 자연스럽게 손에 붙습니다. 먼저 이름만 한번 훑어보세요.

층이 위로 갈수록 “검색” 의 개념이 바뀌어요. 1층은 고정된 벡터 공간에서 top-k 를 뽑는 것. 4층은 “이건 더 이상 검색이 아니고 기억이다” 라고 말할 수 있는 지점. 같은 RAG 우산 아래 있지만 성격이 완전히 다릅니다.

지금부터 한 층씩 들어가 볼게요. 각 층에서 “어떤 제품이 여기 들어가는지”, “이 층을 골라야 하는 상황은 언제인지”, “이 층의 한계는 뭔지” 를 하나씩 붙여 나가겠습니다.

3. 1층 — Embedding 기반 기초 검색

F5 에서 embedding 얘기를 했었죠. 문장이나 단어를 고차원 벡터로 바꾸는 변환기. “의미가 가까운 것은 벡터 공간에서도 가깝게 놓인다” 는 성질이 핵심이었어요. 이 성질이 retrieval 의 가장 기초층을 가능하게 합니다.

1층이 하는 일은 직관적이에요. 도서관 사서를 떠올려 보세요. 사서 앞에 책이 1만 권 있어요. 당신이 “고양이 울음에 대한 행동학 책 있나요” 라고 물었을 때, 사서는 모든 책을 펼쳐보지 않아요. 책 등의 주제 태그를 보고 관련 있을 법한 10권을 뽑아서 보여줍니다. 그 10권 안에서 답을 찾으면 되는 거죠.

Embedding 기반 retrieval 이 정확히 이 일을 합니다.

• 쿼리 (질문) 를 embedding 모델로 벡터화합니다
• 이미 벡터화해 둔 문서 조각들 (chunk) 을 같은 공간에서 검색합니다
• 코사인 유사도가 높은 top-k 를 뽑습니다
• 뽑힌 chunk 를 프롬프트에 붙여서 LLM 에 넣습니다

저장소는 벡터 DB 예요. Pinecone, Weaviate, Chroma, pgvector 같은 도구들이 이 층에서 돌아갑니다. 요즘은 Postgres 에 pgvector 확장을 얹어서 그냥 기존 DB 안에서 끝내는 패턴도 흔해요.

이 층의 장점은 단순함과 예측 가능성이에요. chunk 의 품질이 좋고 embedding 모델이 내 도메인에 맞으면 꽤 잘 돌아갑니다. 비용도 가장 쌉니다. 한 번 벡터화해 두면 그 이후 검색은 거의 공짜예요.

한계도 분명합니다. chunk 사이의 관계가 사라져요. 같은 문서 안에서 바로 옆에 있던 두 chunk 가 벡터 공간에서는 서로 남남이에요. “A 는 B 의 자식 프로세스” 같은 구조 정보나 “이 절은 앞 절의 반박” 같은 논리 관계는 chunk 로 자르는 순간 날아갑니다. 그래서 여러 문서를 걸쳐야 답이 나오는 질문 이나 구조적인 질문 에는 약해요.

또 하나의 함정은 “embedding 모델은 다 비슷하겠지” 라는 오해입니다. 실제로는 영어 벤치마크 상위 모델이 한국어나 일본어 같은 동아시아 언어에서는 추락하는 경우가 흔해요. 도메인도 마찬가지라서, 일반 문서용 embedding 은 의료 문서나 코드에서는 성능이 뚝 떨어집니다. chunk 크기도 성능에 크게 영향을 줘요. 너무 크면 의미가 뿌옇고, 너무 작으면 맥락이 없어서 헛걸음을 합니다.

“RAG 죽었다” 이야기가 주로 이 1층을 겨냥한 얘기라는 걸 여기서 기억해 두세요. 100만 토큰 컨텍스트 시대에 “작은 코퍼스를 미리 벡터화해 두고 top-k 로 뽑는” 단순 워크플로는 굳이 필요 없는 상황이 많아졌거든요. 그렇다고 1층이 사라지지는 않아요. 다만 1층만 쓰는 설계가 줄고, 1층이 “다른 층의 기초 부품” 으로 편입되는 방향으로 움직이고 있습니다.

4. 2층 — GraphRAG, 문서 사이의 관계까지

1층이 “유사한 책 찾기” 라면 2층은 “책과 책의 연결선 그리기” 예요.

Microsoft 가 2024년에 오픈소스로 공개한 GraphRAG 가 이 층의 대표 주자입니다. 단순히 유사도로 chunk 를 뽑는 게 아니라, 문서 안에서 엔티티 (인물·회사·개념·제품) 를 추출하고, 그 엔티티들 사이의 관계를 그래프 구조로 쌓습니다. 검색할 때는 “이 질문과 관련된 노드” 만 찾는 게 아니라 “그 노드에 연결된 이웃 노드들” 까지 같이 가져와요.

예를 들어볼게요. 당신이 어떤 IT 대기업의 과거 5년간 사내 문서 10만 건을 검색하는 시스템을 만든다고 해봅시다. “우리 회사에서 [A 프로젝트] 가 왜 중단됐는지” 라는 질문이 들어와요.

• 1층 (embedding) 으로 풀면: “A 프로젝트 중단” 에 가까운 chunk 를 top-10 뽑아서 넣습니다. 잘 되면 중단 공지 하나가 잡히는데, 그게 왜 중단됐는지의 맥락 — 이전에 사내 어떤 부서와 마찰이 있었는지, 어떤 의사결정 회의에서 결정됐는지 — 은 다른 문서에 흩어져 있어서 놓치기 쉬워요.
• 2층 (GraphRAG) 으로 풀면: A 프로젝트 라는 엔티티 노드에서 출발해서 연결된 이웃 노드들 (결정 회의, 책임자, 이해관계 부서, 대체 프로젝트) 을 같이 가져옵니다. 중단의 맥락이 한 묶음으로 잡혀요.

GraphRAG 가 특히 힘을 쓰는 영역은 몇 가지 있어요.

• 여러 문서를 걸친 질문: “이 인물이 어떤 회사들을 거쳐왔고 지금 어디에 있는가” 처럼 답이 한 문서에 없고 여러 문서를 엮어야 나오는 질문.
• 조직·계통·관계 추적: 인물 관계, 회사 인수 계통, 제품 버전 계보, 법률 조항의 참조 관계 같은 것들.
• 전체 구조 파악 질문: “이 코퍼스 전체에서 핵심 테마는 뭔가” 처럼 요약급 질문. GraphRAG 는 community detection 으로 그래프를 군집화해서 전체 그림을 뽑을 수 있어요.

한계도 확실합니다. 그래프를 쌓는 비용이 꽤 커요. 엔티티 추출, 관계 추출, 군집화 — 전부 LLM 호출이 들어가는 전처리예요. 문서가 자주 바뀌는 동적 코퍼스에서는 그래프를 계속 다시 쌓아야 하니 부담이 큽니다. 그리고 관계 정보가 희박한 코퍼스 — 예를 들어 서로 독립적인 FAQ 들의 집합 — 에서는 그래프 층을 쌓아도 얻는 게 별로 없어요.

2층을 “1층 대체” 로 읽으면 안 된다는 점이 중요합니다. GraphRAG 내부에서도 노드 간 유사도 계산에 embedding 을 쓰는 구현이 많아요. 1층이 아래에 그대로 남아 있고, 2층이 그 위에 관계 레이어를 더하는 구조입니다.

5. 3층 — Agentic Retrieval, 모델이 검색을 도구로 쓴다

1층과 2층까지는 “한 번 검색한다” 는 전제를 공유했어요. 질문이 들어오면 시스템이 관련 정보를 한 번 끌어오고, 그걸 프롬프트에 붙여서 모델이 답을 만듭니다. 모델은 검색 결과를 수동적으로 받는 쪽이었어요.

3층은 이 전제를 뒤집습니다.

Agentic retrieval 은 모델이 검색을 스스로 도구처럼 호출해요. B1 에서 다뤘던 tool use 를 기억하시죠. 모델에게 함수 몇 개를 쥐어주고 “필요하면 호출해” 라고 시키는 패턴. agentic retrieval 은 그 패턴 안에 검색 함수를 넣는 겁니다.

실제 동작은 이런 식이에요.

1. 사용자: “작년 4분기 우리 팀 OKR 달성률 분석해줘.”
2. 모델: (내부 판단) 이 질문에 답하려면 OKR 문서가 필요하다 → search("2025 Q4 팀 OKR") 호출
3. 검색 결과 수신: OKR 원본 문서 요약이 돌아옴
4. 모델: 이 문서를 보니 평가 결과가 따로 있는 것 같은데 없네 → search("Q4 OKR 평가 결과") 한 번 더 호출
5. 결과 수신 → 만족 → 답을 구성해서 사용자에게 전달

여기서 포인트는 검색이 여러 번 일어날 수 있다는 것, 그리고 두 번째 검색어는 첫 번째 결과를 본 뒤에 모델이 만든다는 거예요. 이게 “agentic” 이라는 단어의 뜻입니다. 검색의 주체가 사람이 미리 짠 스크립트에서 모델로 이동해요.

어디서 이미 쓰고 있냐고요. 당신이 매일 만지는 도구들이 거의 다 여기예요.

• Perplexity: 질문에 답하기 전에 웹 검색을 여러 번 돌립니다. 검색어 구성, 검색 횟수, 어느 결과를 볼지를 모델이 결정합니다.
• Claude Research (Anthropic): 깊은 질문에는 여러 쿼리를 반복해가면서 소스를 수집합니다.
• ChatGPT Browse / GPT-5 search: 비슷한 구조예요.
• Claude Code: 이 경우는 웹 검색이 아니라 파일 검색이에요. grep, glob, read 같은 로컬 도구를 호출해서 코드베이스를 스스로 탐색합니다. 벡터 DB 없이도 잘 돌아가는 게 이 덕이에요.

3층이 강한 지점은 예상 밖 질문이에요. 1층·2층은 개발자가 사전에 “이 질문에는 이런 검색을 한다” 를 어느 정도 설계해둬야 합니다. 3층은 모델이 상황을 보고 검색 전략을 즉석에서 짜기 때문에 시나리오가 다양한 환경에서 잘 버팁니다. 또 하나, 재검색이 가능해요. 첫 결과가 부족하면 키워드를 바꿔 한 번 더 들어갑니다. 사람이 구글 검색 쓸 때 하는 그 동작이에요.

한계는 있어요. 비용과 지연이에요. 검색 한 번이 모델 호출 한 번을 유발하고, 다시 검색 결과를 모델에 넣어야 하니 토큰과 시간이 곱해집니다. 그리고 모델이 검색을 너무 많이 부르거나 너무 적게 부르는 실패 패턴도 흔해요. 이 균형 잡기가 agentic retrieval 설계의 핵심 숙제 중 하나입니다.

3층은 “검색을 더 잘 하는” 층이 아니라 “검색의 호출 주체를 사람에서 모델로 옮기는” 층이라는 게 정확한 포착이에요. 아래층 (embedding · graph) 이 기본기가 안 돼 있으면 3층에서 검색을 부르는 주체만 바뀌어도 결과는 안 좋습니다.

6. 4층 — Memory Adaptation, retrieval 을 가중치에 녹이기

여기서부터 “이게 검색인가?” 라는 감각이 흔들리기 시작해요.

1·2·3층은 전부 “문서를 매번 입력으로 건넨다” 는 전제를 공유했어요. 형태만 다를 뿐이죠. embedding 으로 뽑은 chunk 를 프롬프트에 붙이든, 그래프 이웃까지 같이 붙이든, 모델이 도구로 불러서 붙이든, 그 문서는 프롬프트에 들어가서 한 번 읽힌 다음 사라집니다.

4층은 이 전제를 버리는 층이에요.

대표 연구가 2024년 말부터 뜨고 있는 Doc-to-LoRA 입니다. 이름 그대로 “문서를 LoRA 가중치로 변환” 하는 접근이에요. LoRA 는 모델 전체를 재학습하지 않고 일부 가벼운 가중치 차분만 얹는 fine-tuning 기법인데 (B3 에서 다뤘죠), 이걸 retrieval 대용으로 쓰는 거예요.

흐름을 비유로 풀면 이렇습니다. 당신이 회사에 새 직원을 들였어요.

• 1~3층 방식: 질문 들어올 때마다 매뉴얼을 펼쳐서 해당 페이지를 보여주며 답하게 합니다. 효과는 있는데 매번 매뉴얼을 꺼내야 해요.
• 4층 방식: 매뉴얼을 직원 머리에 심어 놓습니다. 학습이 끝나면 매뉴얼 없이도 해당 내용을 알고 있는 상태가 되죠. 프롬프트에 매뉴얼을 넣을 필요가 없어요.

기술적으로는 회사 문서를 미리 훈련 데이터로 넣어 작은 LoRA 어댑터를 학습시킵니다. 추론 시에는 그 LoRA 를 모델에 얹기만 하면 모델이 해당 도메인의 내용을 “기억” 한 상태로 답해요. 프롬프트에 해당 문서를 넣지 않아도 됩니다.

어떤 상황에서 쓰느냐가 중요한 층이에요. 이건 1~3층처럼 “기본 설정” 이 아니라 “특정 상황을 다른 층으로 빼내는 선택지” 로 이해해야 오차가 적습니다.

4층이 맞는 상황:
– 같은 문서를 반복해서 프롬프트에 넣는 비용이 큰 경우. 예: 회사 전용 API 스펙 수백 페이지를 개발자 모두가 매일 수십 번 쿼리함.
– 문서가 거의 바뀌지 않는 정적 자산. 예: 법규, 내부 코딩 스타일 가이드, 고정된 제품 매뉴얼.
– 응답 지연을 극도로 줄여야 하는 환경. 문서를 매번 읽을 시간이 없는 실시간 서비스.

4층이 안 맞는 상황:
– 문서가 매일 바뀌는 동적 코퍼스. 학습을 자주 돌려야 해서 비용이 더 커져요.
– 최신성이 중요한 정보. 어제 추가된 뉴스가 오늘 모델에 반영되려면 재학습을 거쳐야 합니다.
– 권한 분리가 필요한 경우. 사용자마다 볼 수 있는 문서가 다르면 LoRA 를 사용자별로 따로 둬야 해서 운영이 복잡해져요.

4층의 진짜 의미는 이렇게 읽는 편이 좋아요. “어떤 문서는 retrieval 로 남기고, 어떤 문서는 retrieval 바깥으로 빼내서 모델에 녹인다” 는 배분 문제가 가능해집니다. long-context vs RAG 논쟁이 “둘 중 하나” 가 아니라 “문서별로 다르게 배치” 의 문제로 재구성되는 거예요. 이 재구성이 2025년 이후 retrieval 담론의 가장 중요한 변화입니다.

7. 4층을 한 장에 비교하는 표

지금까지 나온 네 층을 한 화면에 올려 볼게요. 외울 필요는 없고, 실무에서 뉴스를 읽을 때 이 표를 머릿속에 꺼내 놓으면 좋아요.

이 표를 읽는 팁 하나. 층이 위로 갈수록 “검색” 의 순간이 사라지는 방향이에요. 1층은 매 쿼리마다 검색을 한 번, 2층은 여전히 한 번이지만 구조가 풍부, 3층은 여러 번 반복, 4층은 아예 검색이 일어나지 않아요 (대신 학습이 한 번 일어남). 검색 행위가 점점 “모델 내부” 로 이동하는 흐름이라고 봐도 돼요.

또 하나. 층이 서로를 배제하지 않아요. 4층을 쓴다고 1층이 없어지는 게 아니에요. 회사 코어 지식은 4층에 심고, 동적 문서는 1층에 두고, 복잡한 질문은 3층 에이전트가 1층을 반복 호출하도록 하는 — 이런 혼합 구성이 실제 프로덕션의 기본이에요.

8. “지금 이 뉴스·이 제품이 몇 층인가” 묻는 훈련

층 구조를 머리에 넣었으면 이제 연습이 필요해요. 실제 기사나 제품을 볼 때마다 속으로 “이거 몇 층 얘기지” 를 묻는 훈련이에요. 예시 몇 개를 같이 풀어볼게요.

예시 1. “Anthropic 의 Claude Code 가 벡터 DB 없이 코드베이스를 잘 탐색한다” 는 기사를 읽었어요. 몇 층?

→ 3층 (agentic retrieval) 얘기예요. Claude Code 는 grep, glob, read 같은 도구를 모델에게 쥐어 주고, 모델이 “지금 이 파일을 봐야 한다” 를 판단해서 호출합니다. 1층 (벡터 DB 에 미리 넣어두는) 을 건너뛰고 3층으로 바로 간 사례예요. “RAG 가 죽었다” 가 이 맥락에서 자주 나옵니다. 정확히 말하면 “여기서는 1층이 필요 없었다” 가 맞아요.

예시 2. “Perplexity 가 신규 모델로 답변 품질이 올랐다” 는 릴리즈 노트를 읽었어요. 몇 층?

→ 주로 3층이지만 1층도 걸쳐 있어요. Perplexity 는 모델이 여러 번 검색 쿼리를 만들어 돌리고 결과를 종합합니다 (3층). 동시에 웹 색인 자체는 거대한 embedding/lexical 인덱스로 구축돼 있어요 (1층 계열). 그래서 “답변 품질” 개선은 모델의 에이전틱 판단이 좋아진 건지, 기저 색인 품질이 좋아진 건지를 구분해서 읽어야 합니다.

예시 3. “Microsoft 가 GraphRAG 오픈소스 2.0 을 발표했다” 는 뉴스. 몇 층?

→ 2층 얘기예요. 관계 그래프를 얹는 층입니다. 이게 1층을 대체한다는 뜻이 아니라, 1층 위에 그래프 구조층이 더 풍부해진다는 의미예요.

예시 4. “이 회사는 자사 법률 문서 10만 페이지로 LoRA 를 학습해 전용 모델을 만들었다” 는 사례. 몇 층?

→ 4층이에요. 정적이고 권한이 회사 내부에만 있는 대형 법률 문서는 4층의 전형적인 적용 사례입니다. 매번 법률 문서 10만 페이지를 retrieval 로 꺼내는 것보다 모델에 심어 놓는 게 비용과 지연 면에서 유리해요.

이 연습이 익숙해지면 뉴스 속도가 다르게 흐릅니다. “RAG 2.0”, “RAG is dead”, “우리는 RAG 안 쓴다” 같은 마케팅 문장이 더 이상 혼란스럽지 않아요. “이 사람이 RAG 라고 말할 때 몇 층을 가리키는가” 만 보면 됩니다.

9. 층끼리 섞는 현실 — 프로덕션 패턴

순수하게 한 층만 쓰는 제품은 드물어요. 실제 프로덕션에서는 층을 조합합니다. 자주 나오는 패턴을 몇 개 보여드릴게요.

패턴 A — 1층 필터 + 3층 refine

사용자가 질문을 해요. 먼저 1층 embedding 검색으로 관련 있을 법한 문서 100개를 빠르게 뽑습니다 (싸고 빠르니까). 그 100개를 모델에게 주고 3층 agentic retrieval 로 “이 중에서 진짜 관련 있는 건 뭔지” 를 한 번 더 추립니다. 마지막에 남은 10개 정도만 프롬프트에 들어가요.

장점: 1층의 저비용과 3층의 정확도를 같이 씁니다. 단점: 호출이 중첩돼서 설계가 복잡해져요.

패턴 B — 2층 + 3층

GraphRAG 로 만든 그래프를 도구로 감쌉니다. 모델은 graph_query(entity, depth) 같은 함수를 호출해서 관계 이웃을 받아와요. 질문에 따라 모델이 깊이를 조절할 수 있게 됩니다.

장점: 구조 정보를 동적으로 활용해요. 단점: 그래프 구축 비용 + 에이전트 운영 비용이 둘 다 듭니다.

패턴 C — 4층 시스템 지식 + 1층 동적 문서

회사 전용 제품 매뉴얼·코딩 가이드·스타일 가이드처럼 거의 안 바뀌는 문서는 4층 LoRA 로 모델에 녹입니다. 매일 바뀌는 티켓·리포트·대시보드는 1층 벡터 DB 로 보관하고 필요할 때만 꺼냅니다.

장점: 정적 지식은 프롬프트에서 사라지니 토큰 예산에 여유가 생겨요. 동적 지식은 최신성 유지됩니다. 단점: 운영 파이프라인이 두 개로 쪼개져요.

패턴 D — 100만 토큰 컨텍스트 + 1층 사전 필터

요즘 뜨는 패턴이에요. Gemini 1.5 나 Claude 4 같은 모델의 1M+ 컨텍스트를 활용합니다. 전체 코퍼스 1000만 토큰 중에서 1층 embedding 으로 100만 토큰 정도를 추려서 통째로 모델에 넣어요. 그 안에서는 컨텍스트 윈도우가 알아서 다 처리합니다. “chunk 쪼개기” 의 부담이 확 줄어요.

장점: chunk 품질 문제에서 해방돼요. 단점: API 비용이 쿼리당 꽤 커집니다.

여기서 감이 잡히시는 포인트가 있어요. 층은 선택이 아니라 배치라는 점. “우리는 몇 층을 쓸 것인가” 가 아니라 “어떤 문서를 어느 층에, 어떤 질문을 어느 경로로” 가 올바른 질문이에요.

이 배치 감각이 retrieval 설계의 실무 핵심입니다.

10. 여기서 실수하기 쉬운 3가지

마지막으로 이 주제를 보는 독자들이 자주 빠지는 착각 세 개만 짚고 갈게요.

착각 1 — “context window 가 커졌으니 RAG 필요 없다”

길게 쓴 버전은 이래요. “이제 Gemini 는 1M 토큰, Claude 는 200k, GPT 는 200k+ 다. 문서를 전부 프롬프트에 넣으면 되는데 왜 따로 검색을 하나.”

이 말은 작은 코퍼스 와 큰 코퍼스 를 섞어서 생각할 때 생기는 착각이에요. 책 한 권 (30만 토큰), 긴 논문 몇 개 (50만 토큰) 같은 건 이제 그냥 넣으면 됩니다. 그런데 회사 전체 위키 (5000만 토큰), 전체 코드베이스 (수천만 토큰), 고객 문의 이력 (수억 토큰) 은 여전히 통째로 못 넣어요. 양이 맞지 않으면 검색은 남습니다. 그리고 돈과 시간의 문제도 있어요. 1M 토큰을 매 쿼리마다 넣는 건 비용도 지연도 부담이에요. “관련 부분만 뽑아서 넣는” retrieval 의 역할은 당분간 남아요.

착각 2 — “RAG 붙였으니 환각 사라졌다”

RAG 를 쓰면 환각이 줄어드는 건 맞지만 사라지지 않아요. 이유는 두 가지예요.

첫째, retrieval 결과가 부정확할 수 있어요. 엉뚱한 chunk 가 올라오면 모델이 그 엉뚱한 정보를 근거로 깔끔하게 틀린 답을 만듭니다. RAG 는 “외부 정보를 잘 넣는 공정” 이지 “외부 정보가 맞다는 보장” 이 아니에요.

둘째, 모델은 받은 정보를 무시하고 자기 기억으로 답할 수 있어요. 특히 retrieval 결과가 모델이 원래 알고 있던 내용과 충돌하면, 모델이 검색 결과를 무시하는 실패가 흔합니다.

그래서 RAG 를 붙였다고 해서 출처 표시 없는 답을 그대로 믿으면 안 돼요. 출처 제시·인용·검증 같은 장치가 별도로 필요합니다.

착각 3 — “embedding 모델은 다 비슷비슷하다”

1층의 기초를 깔 때 “OpenAI text-embedding-3-small 이든 BGE 든 뭐든 차이 미미하겠지” 라고 넘기는 사람이 많아요. 이게 치명적일 때가 있어요.

언어별로 성능 편차가 큽니다. 영어 벤치마크 상위 모델이 한국어에서는 이상하게 동작하는 경우가 있어요. 도메인별로도 그래요. 일반 문서 embedding 이 코드나 의료 문서에서는 뚝 떨어집니다. chunk 크기와의 상호작용도 있어요. 긴 chunk 에 강한 모델이 있고, 짧은 chunk 에 강한 모델이 따로 있어요.

retrieval 디버깅의 절반 이상이 1층 문제에서 나온다는 게 제 경험입니다. 상위 층을 화려하게 꾸미기 전에, 1층에서 embedding 모델이 내 언어·도메인에 맞는지, chunk 는 적절하게 잘랐는지 먼저 확인하는 게 순서예요.

11. M9 에서 다시 다룰 질문 — “그래서 RAG 는 정말 죽었나?”

이 글은 입문 편이라서 여기서 단답을 하진 않아요. M9 에서 “RAG 는 죽었는가” 라는 질문을 본격적으로 다룰 예정입니다. 대신 4층 관점에서의 짧은 프리뷰만 드릴게요.

• 1층은 역할이 줄고 있다. 작은 코퍼스 + 대형 컨텍스트 조합에서는 1층의 단독 사용 명분이 약해졌어요. 다만 큰 코퍼스의 사전 필터로는 여전히 살아 있습니다.
• 2층은 특정 코퍼스에서 점점 중요해지고 있다. 관계 정보가 중요한 기술·법률·의료 문서에서는 GraphRAG 가 강해지고 있어요.
• 3층은 주류가 되고 있다. Perplexity·Claude Research·Claude Code 가 보여주는 방향이 이쪽입니다. “모델이 검색을 도구처럼 쓴다” 는 패턴은 사라지지 않아요.
• 4층은 틈새지만 성장 중이에요. 회사 전용 지식·정적 대형 문서 쪽에서 조용히 늘고 있습니다.

그러니까 “죽었나” 라는 단답은 정답이 안 됩니다. 맞는 질문은 “내 상황에서 어느 층이 병목이고, 어느 층으로 일을 배치할까” 예요. 이 감각이 손에 붙으면 RAG 담론 전체가 차분해집니다.

한 문장 닫음: “RAG” 한 단어 안에는 서로 매우 다른 네 개의 층이 있고, 그 층을 분리해서 볼 때만 “RAG 죽었다” 류의 문장도 제품 설명도 논문 해석도 같이 선명해진다. 이 4층 지도를 들고 다니시면 됩니다.

다음 읽기

• M2 — Long-context 와 Memory 는 같은 이야기인가 [준비 중] — 100만 토큰 컨텍스트가 정말 RAG 를 대체하는지, 그리고 “memory” 라는 단어가 최근 제품들에서 실제로 가리키는 것이 뭔지를 다룹니다.
• M9 — RAG 는 정말 죽었나 [준비 중] — 이번 글의 4층 관점을 가지고 본격적인 답을 찾으러 갑니다.

시리즈 처음부터: F1 — AI·ML·DL·LLM 용어 구분 · F5 — Embedding 감각 잡기 · B3 — Fine-tuning vs RAG vs Prompt

자주 묻는 질문 (FAQ)

Q1. 4층 중 어느 층부터 공부해야 할까요?

1층부터입니다. embedding 과 벡터 검색 한 줄을 직접 코드로 돌려 보면 위 층들의 얘기가 훨씬 빠르게 붙어요. LangChain 튜토리얼에서 10줄짜리 vector retrieval 예제를 먼저 돌려 보고, 그 다음에 2층 (GraphRAG 공식 샘플), 3층 (Claude Code 에서 코드베이스 탐색 관찰), 4층 (LoRA 기초 학습 실습) 순서로 올라가는 걸 권장합니다. 순서를 건너뛰면 위에서 본 “4층이 왜 존재하는지” 감각이 안 생겨요.

Q2. 우리 회사 제품에 어느 층을 써야 할지 어떻게 정하나요?

세 가지 질문을 순서대로 던져 보세요. (1) 코퍼스 크기는 컨텍스트 윈도우에 들어가나 — 들어가면 일부러 retrieval 을 안 써도 됩니다. (2) 문서가 자주 바뀌나 — 자주 바뀌면 4층은 아니에요. 1~3층에서 고르세요. (3) 질문이 한 문서 안에서 끝나나, 여러 문서 걸쳐야 하나 — 여러 문서 걸친다면 2층이나 3층이 필요해요. 이 세 답이 나오면 조합이 거의 자동으로 정해집니다.

Q3. Claude Code 나 Perplexity 내부 구조를 더 깊게 알고 싶어요.

두 제품 다 공식 블로그·엔지니어링 포스트에서 단서를 꽤 공개하고 있어요. Anthropic 의 “How we built Claude Code” 글이 3층 agentic retrieval 패턴을 잘 설명합니다. Perplexity 는 공식 블로그에서 검색 쿼리 구성 방식을 일부 밝혀 뒀어요. 이 글의 4층 지도를 들고 그 글들을 다시 읽으면 훨씬 많은 게 읽힙니다.

뉴스레터 구독 안내

매주 월요일, AI·LLM·에이전트 관련 실무 정리를 한 통씩 보내드립니다. 이런 기술 지도를 차분히 쌓아가고 싶으시면 구독해 주세요.

뉴스레터 구독하기

시리즈 안내 — AI 공부 지도 20부작
– F1~F6: 기초 (LLM·Transformer·딥러닝·embedding·attention·gradient descent)
– B1~B3: 가교 (에이전트·프롬프트 작동원리·fine-tune 대 RAG 대 프롬프트)
– M1: Retrieval Layer 4층 구조 (현재 글)
– M2: Long-context 와 Memory 는 같은 이야기인가
– M3 이후: 평가·운영·비용·조직 관점의 실무 지도
– M9: RAG 는 정말 죽었나 — 4층 관점의 본격 답변
– M20: 전체 지도 마무리

소스 리스트

• 태일러 지식백과사전 — AI 공부 지도 카테고리 (본 시리즈 20편 전체)
• AI 공부 지도 엔트리맵 — 전체 구조 + 3가지 독법
• “Attention Is All You Need” (Vaswani et al., 2017)
• Anthropic · OpenAI · Google 공식 docs
• mathbullet (YouTube) / Jay Alammar “Illustrated Transformer” / 3Blue1Brown 영상 — 쉬운 설명 레퍼런스

著者: 바이브코딩 태일러 (VibeCoding Tailor) — Lovable公式アンバサダー. AI·バイブコーディング専門メディアshuntailor.net運営.
本シリーズ “AI 공부 지도” 22편은 위키 자료와 공식 논문·공식 문서를 근거로 정리한 체계적 학습 커리큘럼입니다.

바이브코딩 태일러

AI의 작동 원리와 비즈니스 적용을 일본어·한국어로 기록합니다. 매주 월요일 뉴스레터 발행 중.

뉴스레터 구독하기 →

이 시리즈의 다음 편

”Claude 1M 토큰”이 AI 기억력 향상이 아닌 이유

Claude 1M 토큰, Gemini 2M이라는 헤드라인이 "AI 기억력 향상"으로 들리지만 사실 context window·session memory·persistent memory는 완전히 다른 3가지다. Lost in the middle·compaction·Doc-to

Agent를 5층으로 뜯으면 제품 평가가 가능해진다

Agent를 tool use·state·planning·reflection·multi-agent 5층으로 뜯어보면 Claude Code·Cursor·Devin·Auto-GPT가 왜 다른 결과를 냈는지 정확히 보인다. Agent 제품 평가·도입에 쓰는 10가지 체크리스트까지. A

좋은 Agent는 좋은 모델보다 먼저 좋은 하네스를 가진다

같은 Claude·GPT를 써도 agent 품질이 천차만별인 진짜 원인은 하네스다. System prompt·AGENTS.md·skills·hooks·permissions·sandbox·compaction·verification 8층으로 하네스를 뜯고, Claude Code C

★ 태일러의 다른 추천

LLM이 뭐냐고 물으면 말이 막히는 분께 — 자동완성이 끝까지 간 이야기

ChatGPT·Claude 2~3년째 쓰는데도 "LLM이 뭐예요?"에 막히는 분을 위한 해설. 다음 토큰 예측, 토큰, 파라미터, 학습/추론, 환각까지 비유 하나로 이어 읽는다. AI 공부…

Transformer가 뭔지 진짜 이해하고 싶은 분께

ChatGPT·Claude 안에는 다 Transformer가 들어 있다. 근데 Transformer가 정확히 뭐냐고 물으면 다들 얼버무린다. RNN 한계부터 attention, multi-head, stacking까지 비유 하나로 따라가게 정리.…