이 글은 「AI 공부 지도 20부작」의 19편(M9) 입니다.
앞 편: M8 — 에이전트 평가와 관찰 가능성
다음 편: M10 — 전체 지도 마무리
0. 시리즈 안내 — 이번 편은 M9, 내 입장을 찍는 편
이 글은 20부작 중 19번째입니다. M1에서 제가 retrieval 을 네 개 층으로 나눠서 보자는 지도를 그렸었고, 그 뒤로 M2 (long-context 와 memory), M3~M8 을 거쳐 평가·운영·조직 관점까지 한 바퀴 돌았어요. 그 맥락 위에서 이번 M9 는 조금 다른 성격입니다. 이번 편은 태일러 본인의 입장을 찍는 편이에요.
이유는 단순해요. “RAG 는 죽었냐” 라는 질문을 제가 최근 몇 달 동안 반복해서 받았습니다. 기술 블로그 댓글로, 트위터 DM 으로, 스레드에서, 강연장에서. 제가 RAG 기반 시스템을 실무에서 운영해 왔다는 걸 아는 사람들이 “진짜로 죽었느냐, 태일러 생각은 어떠냐” 를 물어와요. 그 질문이 너무 자주 반복되길래, 이번 기회에 한 번에 정리해서 답해두는 편을 쓰기로 한 겁니다.
그래서 이 글은 이전 글들과 톤이 조금 달라요. 다른 사람 이론 소개가 아니라 “내 생각은 이렇다” 를 중심으로 갑니다. 근거는 M1~M8 에서 쌓아둔 층 구조와 실무 관찰로 단단하게 받치고, 입장 표명은 제 말로 합니다. 한번 읽고 나면 독자분들이 “나는 RAG 에 대해 어느 층을 쓰고 있고, 어디로 움직여야 하나” 를 각자 판단할 수 있도록 하는 게 이 글의 목표예요.
1. “RAG 는 죽었다” 라는 헤드라인이 왜 매년 반복되나
먼저 관찰부터 해볼게요. “RAG is dead” 라는 문장은 2023년에도 돌았고, 2024년에도 돌았고, 2025년에도 돌았고, 2026년 지금도 돌고 있어요. 한두 번 죽었다가 다시 살아난 게 아니라 매년 “죽었다” 는 소리가 한 번씩 주기적으로 터집니다. 그러면서도 RAG 관련 논문·제품·컨퍼런스 세션 수는 같은 기간 동안 계속 늘었어요. 죽었다는데 왜 이렇게 살아있느냐.
제가 봐온 패턴은 이래요. “RAG 죽었다” 라는 문장이 주기적으로 나오는 건 세 가지 계기 중 하나가 반복되기 때문이에요.
첫째, 컨텍스트 윈도우가 확장될 때. 2024년에 Gemini 1.5 가 100만 토큰을 선보이면서 한 번 터졌고, 그 뒤 Claude 와 GPT 계열도 긴 컨텍스트를 따라오면서 또 터졌어요. “이제 문서 통째로 넣으면 되는데 왜 retrieval 을 쓰냐” 는 주장이 그때마다 돌죠.
둘째, 새로운 패러다임 제품이 나올 때. Claude Code 가 벡터 DB 없이 grep 과 파일 도구로 코드베이스를 탐색하는 게 화제가 됐을 때 한 번 크게 터졌어요. Perplexity 나 Claude Research 가 웹을 실시간으로 검색하면서 답하는 방식이 주목받을 때도 비슷한 주장이 나오고요.
셋째, 기존 RAG 구현이 크게 실패한 사례가 공유될 때. 누가 벡터 DB 에 회사 문서를 잔뜩 넣었는데 환각이 줄지 않더라, 검색 결과가 엉뚱해서 쓸 만하지 않더라, 이런 경험담이 공유되면 “RAG 는 과대평가 아니었냐” 는 반응이 돕니다.
세 계기의 공통점이 있어요. 전부 “RAG” 라는 한 단어 아래에 실은 아주 다른 여러 구조가 섞여 있다는 사실을 무시할 때 나오는 반응이에요. M1 에서 제가 깐 4층 지도를 다시 꺼내면 이 혼란이 대부분 풀립니다. 그래서 이번 글에서도 그 지도를 축으로 씁니다.
참고로 제 관찰 한 가지 더. “RAG 죽었다” 를 가장 강하게 주장하는 사람들 중 상당수는 자기가 만든 시스템이 1층에 머물러 있어요. 1층에서 잘 안 풀렸던 경험을 가지고 전체 RAG 에 대한 판정을 내리는 거죠. 반대로 2~4층에서 일하는 사람들은 “RAG 는 죽기는커녕 이제 시작이다” 라는 쪽에 서 있습니다. 같은 단어를 쓰지만 가리키는 게 다른 거예요.
2. 내 답 — “죽은 건 1층뿐. 2~4층은 오히려 확장 중이다”
자, 본론으로 바로 들어갑니다. 저의 답은 이겁니다.
“RAG 는 죽었다” 는 말은 절반만 참이다. 죽은 건 1층이고, 2~4층은 오히려 전성기로 가고 있다.
더 풀어 쓰면 이래요.
- 1층 (단순 embedding + 일회성 retrieval) — 실전 경쟁력을 거의 잃었다. 이 층만 쓰는 설계는 요즘 거의 살아남지 못해요. 이 층에 대해서는 “죽었다” 는 말이 절반쯤 맞습니다. 다만 완전히 없어진 게 아니라, 다른 층의 하위 부품 으로 녹아 들어가는 중이에요.
- 2층 (GraphRAG) — 오히려 뜨고 있어요. 엔터프라이즈 문서의 관계 추론 수요가 명확해졌고, Microsoft GraphRAG 가 그 수요의 상징이 됐습니다.
- 3층 (Agentic Retrieval) — 완전히 주류가 됐어요. Perplexity, Claude Research, ChatGPT Browse, Claude Code 가 전부 이 층에서 움직입니다. “RAG = 한 번 검색하는 것” 이라는 예전 공식이 여기서 깨졌어요.
- 4층 (Memory Adaptation, Doc-to-LoRA) — 아직 논문 단계지만 방향이 명확합니다. 2025~2026 년에 실무 진입이 시작됐어요.
층 네 개를 하나씩 보면 “죽었냐” 라는 질문 자체가 너무 거친 질문이라는 게 드러납니다. 어느 층 얘긴지 고르고 나서 따로따로 답해야 하는 질문이에요. 지금부터 그걸 한 층씩 제 입장을 붙여서 풀어 갈 겁니다.
M1 을 안 읽고 오신 분들을 위해 한 줄 요약으로 복습해 드릴게요. RAG 라는 우산 밑에는 네 개의 층이 있다. 1층은 벡터 유사도로 top-k 를 뽑는 기초 검색. 2층은 문서 사이 관계를 그래프로 잡는 검색. 3층은 모델이 검색을 도구로 호출하는 agentic 방식. 4층은 문서를 아예 모델 가중치로 녹이는 기억 방식. 이게 전제입니다. 이 전제를 공유한 채로 제 답을 풀어 놓을게요.
3. 1층이 왜 경쟁력을 잃었나 — 내가 보는 세 가지 이유
1층부터 갑니다. 저는 요즘 “벡터 DB 만들고 top-k 뽑아서 프롬프트에 붙이는” 단순 구조만으로 끝내는 설계는 2026년 현재 잘 안 팔린다고 봐요. 이유를 세 가지로 정리할 수 있습니다.
첫째, 컨텍스트 윈도우 확장이 1층의 수요를 잠식했어요. 소규모 문서 — 긴 매뉴얼 한 권, 논문 몇 편, 회의록 수십 건 — 은 이제 그냥 프롬프트에 통째로 넣어도 됩니다. Gemini 와 Claude 계열의 긴 컨텍스트 모델이 쉽게 쓸 수 있어졌으니까요. 예전에는 “넣을 자리가 없으니 top-k 로 추려야 한다” 가 1층의 존재 이유 중 하나였는데, 그 부분이 사라졌어요. 100만 토큰짜리 프롬프트가 비싸긴 한데, “잘 쪼개서 tops 만 넣기” 보다 “일단 다 넣고 모델이 알아서 찾게 하기” 가 정확도 측면에서 자주 이겨요. 1층의 단독 사용 명분이 여기서 한 번 깎입니다.
둘째, 한 번 검색해서 top-k 프롬프트에 얹는 방식은 복잡한 질문에 약합니다. 이게 제가 실무에서 가장 많이 본 실패 패턴이에요. “A 프로젝트가 왜 중단됐고 그 영향은 뭐였나” 같은 다단계 질문이 들어왔을 때, 1층은 “A 프로젝트 중단” 에 가까운 chunk 몇 개를 뽑아 넣고 끝납니다. 그 다음 단계 — “이 중단의 영향을 추적하려면 어떤 문서를 또 봐야 하나” — 를 시스템이 스스로 못 해요. 사람이 코드를 짜서 “첫 번째 검색 후 두 번째 검색을 돌린다” 를 하드코딩하지 않는 한, 1층의 일회성 구조는 여기서 막혀요.
셋째, 환각 억제 효과가 제한적입니다. 2023~2024 년에는 “RAG 붙이면 환각이 사라진다” 는 신화가 있었어요. 실무를 돌려보면 알지만 이건 과장이에요. 엉뚱한 chunk 가 retrieval 결과로 올라오면 모델은 그 엉뚱한 정보를 근거로 깔끔하게 틀린 답을 만듭니다. 그리고 retrieval 결과가 자기 기존 기억과 충돌할 때 모델이 retrieval 을 무시하고 기존 기억으로 답하는 실패도 흔해요. 그래서 1층 단독으로는 환각 방지 장치 역할이 약합니다. 1층 단독 설계의 마지막 셀링 포인트였던 이 효과가 무너진 게 결정적이에요.
이 세 가지가 합쳐지면 결과는 분명합니다. 1층만 쓰는 설계는 2026년 실전에서 거의 경쟁력을 잃었어요. 저는 신규 프로젝트에서 1층만 깔려고 하는 사람에게 “거기서 멈추면 안 된다” 고 말립니다. 그게 제 입장이에요.
그런데 여기서 주의할 건, 1층 자체가 사라진다는 말이 아니라는 점입니다. 1층은 다른 층의 하위 부품 으로 계속 살아 있어요. 2층 GraphRAG 내부에서도 엔티티 유사도 계산에 embedding 을 씁니다. 3층 agentic retrieval 에서도 검색 도구 안쪽에 1층 인덱스가 깔리는 경우가 많아요. 4층조차 “어떤 문서를 LoRA 로 녹일지 고르는” 사전 단계에서 embedding 을 써요. 1층은 토대로 남는데, 단독 상품으로서의 생명은 끝났다 가 제 표현입니다.
이 구분을 깔끔하게 하지 않으면 “RAG 죽었다” 논쟁이 계속 미끄러져요. 죽은 건 “1층 단독 설계” 고, 1층 기술 자체는 살아있습니다.
4. 2층이 오히려 뜨는 이유 — GraphRAG 가 말해주는 것
1층에서 2층으로 올라가면 분위기가 완전히 달라져요. 여긴 오히려 성장하고 있어요.
GraphRAG 는 2024년 초 Microsoft 가 오픈소스로 공개한 방식인데, 이걸 2025~2026 년에 엔터프라이즈들이 본격적으로 집어드는 게 지금의 흐름이에요. 왜 뜨고 있는지 저는 세 가지로 봐요.
첫째, 엔터프라이즈 문서는 관계 추론이 본질적으로 필요합니다. 회사 사내 문서라는 게 어떤 구조인지 한번 떠올려보세요. 인사 정책 문서는 조직도와 연결돼 있고, 조직도는 프로젝트 문서와 연결돼 있고, 프로젝트 문서는 계약서와 연결돼 있어요. “이 부서가 이 프로젝트를 왜 중단했나” 를 답하려면 최소 세 개 문서를 교차해야 합니다. 1층으로는 안 풀려요. 엔터프라이즈 고객들이 이걸 이제 피부로 알게 된 거예요. 그래서 GraphRAG 수요가 급증하고 있습니다.
둘째, 법률·의료·기술 같은 관계 밀도 높은 도메인에서 효과가 즉시 나와요. 법률 문서는 조항끼리 참조 관계가 복잡하게 얽혀 있어요. 의료 문서는 증상·진단·약물 사이 관계가 핵심이고, 기술 문서는 버전·의존성·API 레퍼런스가 서로 엮여 있습니다. 이런 도메인에서는 GraphRAG 가 1층보다 질문 한 번에 놓치는 문서 수 를 눈에 띄게 줄여줍니다. 저는 이런 사례를 몇 번 관찰했는데, before 상태에서는 관련 조항의 절반 이하만 잡혔던 게 GraphRAG 도입 이후 80% 이상으로 올라가는 케이스가 실무에서 반복됐어요.
셋째, “코퍼스 전체 요약” 이 새로 가능해졌습니다. 1층은 top-k 를 뽑는 구조라 “이 문서 전체를 관통하는 주제가 뭔가” 같은 전체 요약 질문에 약해요. GraphRAG 는 community detection 으로 그래프를 군집화해서 전체 테마를 잡을 수 있습니다. 이게 엔터프라이즈 입장에서 “처음부터 필요했는데 만들 방법이 없었던 기능” 이라서 수요가 큽니다.
제 입장을 말씀드리면, 2층은 앞으로 몇 년간 더 커집니다. 특히 문서가 자주 안 바뀌는 코퍼스 (법률, 내부 매뉴얼, 오랜 기간 쌓인 기술 문서) 에서 기본 옵션으로 자리잡을 거라고 봐요. 지금 “RAG 죽었냐” 를 묻는 분들 중에 이 층의 움직임을 놓치고 있는 분이 꽤 많은데, 2층은 경쟁력을 잃기는커녕 막 시작하는 시장 이에요.
비자명한 포인트 하나. GraphRAG 를 도입했다고 1층을 버리는 게 아니에요. 2층은 1층 위에 얹히는 추가 레이어 입니다. 2층 도입이 “RAG 를 버리고 다른 걸 했다” 가 아니라 “RAG 를 한 단계 더 쌓았다” 로 읽어야 정확해요. 이 지점이 혼동되면 2층의 성장이 1층의 죽음처럼 잘못 해석됩니다.
5. 3층은 완전한 패러다임 전환 — “한 번 검색” 공식이 깨진 지점
3층은 제가 “RAG 라는 단어의 의미가 바뀐 지점” 이라고 부르는 층이에요.
전통적으로 RAG 라고 하면 사람들이 머릿속에 그리는 그림이 있습니다. “질문 들어온다 → 검색 한 번 돌린다 → top-k 뽑는다 → 프롬프트에 붙인다 → 모델이 답한다.” 이 순서. 검색은 한 번 일어나고, 모델은 검색 결과를 수동적으로 받아요.
3층은 이 그림을 뒤집습니다.
Agentic retrieval 에서는 모델이 검색을 도구처럼 호출 해요. 질문을 받으면 모델이 “이걸 풀려면 뭘 검색해야 하지” 를 스스로 판단해서 검색 함수를 부릅니다. 첫 번째 결과를 보고 “이것만으론 부족하다” 싶으면 쿼리를 바꿔 다시 부릅니다. 세 번, 네 번 부를 수도 있어요. 검색의 주체가 사람이 짠 파이프라인에서 모델로 이동 합니다.
제가 왜 이 층을 “패러다임 전환” 이라고 부르느냐. 이 구조에서는 “RAG = 한 번 검색” 이라는 전통 공식이 완전히 깨져요. 검색은 n 번 일어날 수 있고, 검색어는 모델이 중간에 바꾸고, 언제 검색을 멈출지도 모델이 정합니다. 이건 더 이상 이전 세대 RAG 랑 같은 동작이 아니에요. 모양은 검색인데, 행동은 에이전트예요.
어디서 이미 돌아가고 있냐. 우리가 매일 쓰는 제품들이에요.
- Perplexity — 질문 하나에 여러 번 웹 검색을 돌립니다. 검색어 구성, 몇 번 돌릴지, 어느 결과를 볼지 전부 모델이 판단해요.
- Claude Research — 깊이 파는 질문에 여러 쿼리를 반복해가면서 소스를 수집합니다. 사람이 시간을 들여 검색하는 걸 대신하는 방식이에요.
- ChatGPT Browse / GPT-5 search — 비슷한 구조입니다.
- Claude Code — 웹 대신 파일 검색이에요.
grep,glob,read같은 로컬 도구를 모델이 스스로 호출하면서 코드베이스를 탐색합니다. 이게 Anthropic 이 “벡터 DB 없이도 잘 돌아간다” 고 말하는 이유예요. Claude Code 는 1층을 건너뛰고 3층으로 바로 간 사례입니다.
이 네 제품을 한 줄로 묶어 보면 이래요. “RAG 죽었다” 는 주장이 나오게 된 원인 제품들이, 사실은 RAG 의 3층에서 전성기를 구가하고 있다. 겉으로 보면 “벡터 DB 를 안 쓰니까 RAG 가 아니다” 로 보일 수 있는데, 레이어 시각으로 보면 이건 RAG 의 다른 층이에요. 검색이라는 동작은 여전히 핵심이고, 모델이 그 검색의 주체가 됐을 뿐입니다.
제 입장은 분명해요. 3층은 죽지 않았고, 죽기는커녕 지난 2년간 가장 빠르게 성장한 AI 패턴 입니다. “RAG 죽었다” 를 3층까지 포함해서 하는 말이라면, 그 주장은 틀렸어요. 현상을 정반대로 읽고 있는 거예요.
비자명한 포인트. 3층이 주류가 되면서 1층·2층은 3층의 도구 로 편입되고 있어요. Claude Research 안에서도 복잡한 질문에서는 벡터 인덱스를 도구로 호출합니다. Perplexity 의 웹 색인도 내부적으로 거대한 embedding/lexical 인덱스예요. 그러니까 “3층이 1층을 대체한다” 가 아니라 “3층이 1층을 흡수해서 자기 도구로 쓴다” 가 실제 구조입니다.
6. 4층은 아직 논문 단계지만 방향은 명확하다 — Memory Adaptation
4층으로 올라가면 “이게 검색인가” 라는 질문이 흔들리기 시작해요.
1층·2층·3층은 전부 “문서를 매번 입력으로 건넨다” 는 전제를 공유했어요. embedding 으로 뽑든, 그래프로 잡든, 에이전트로 호출하든, 결국 retrieval 결과가 프롬프트에 들어가서 한 번 읽힌 다음 사라지는 구조였습니다.
4층은 이 전제를 버려요.
Doc-to-LoRA 가 대표 연구예요. 이름 그대로 “문서를 LoRA 가중치로 변환” 하는 접근입니다. 회사 전용 문서를 사전 학습 데이터로 써서 작은 LoRA 어댑터를 만들고, 추론 시 그 어댑터를 얹기만 하면 모델이 해당 문서 내용을 “기억” 한 상태가 돼요. 프롬프트에 문서를 넣지 않아도 답합니다.
제가 4층에 대해서 하고 싶은 말은 두 가지예요.
첫째, 아직 논문 단계 색이 강합니다. Doc-to-LoRA 계열 연구가 2024~2025 년에 쏟아져 나왔고 실무 진입은 2025 년 후반부터 시작됐지만, 2026 년 지금 이 층을 프로덕션에 안정적으로 올린 사례는 아직 많지 않아요. 학습 비용, 업데이트 주기, 권한 분리 같은 실무 이슈들이 아직 정리되지 않았거든요. 저도 실험적으로만 써봤어요.
둘째, 방향은 명확합니다. 특정 조건이 맞는 문서 — 거의 안 바뀌고, 대량으로 반복 참조되고, 권한 분리 요구가 적은 — 에서 4층이 1~3층보다 더 유리한 조합이 나와요. 회사 전용 API 스펙 수백 페이지, 사내 코딩 스타일 가이드, 고정된 제품 매뉴얼 같은 자산이 그 예입니다. 이런 자산을 매 쿼리마다 프롬프트에 넣는 토큰 비용이 쌓이면 엄청나요. 그걸 LoRA 로 한 번 녹여두면 비용과 지연 양쪽에서 이깁니다.
제 입장은 이거예요. 4층은 아직 주류가 아니고, 2026년 지금 모든 팀에 권하진 않아요. 다만 2027~2028 년쯤엔 엔터프라이즈의 “당연한 옵션” 으로 들어올 거라고 봅니다. 이 층이 있다는 걸 알고만 있어도 retrieval 설계 선택지가 넓어져요. “어떤 문서는 retrieval 로 두고 어떤 문서는 retrieval 바깥으로 빼낸다” 는 배분 사고가 가능해지거든요.
비자명한 포인트. 4층이 퍼지면 long-context vs RAG 논쟁이 “둘 중 하나” 가 아니라 “문서별로 다르게 배치” 의 문제로 재구성됩니다. 이게 retrieval 담론의 가장 큰 변화예요. 지금도 “long context 로 충분하냐 RAG 가 필요하냐” 라고 이분법으로 묻는 사람이 많은데, 2~3년 안에 그 질문이 “이 문서는 어느 층에 배치할 거냐” 로 바뀔 겁니다.
7. “RAG 는 죽었다” 고 말하는 사람들은 뭘 보고 있나
여기서 잠깐 반대편으로 가볼게요. “RAG 는 죽었다” 를 주장하는 사람들은 뭘 보고 그렇게 말하는 건가. 제가 관찰한 패턴 세 가지를 정리할게요.
패턴 1 — 1층만 쓰다가 실패한 경험. 가장 흔한 경우예요. 회사 문서를 벡터 DB 에 잔뜩 넣고 단순 top-k 검색을 돌렸는데, 정확도가 기대에 못 미치고 환각도 여전하더라, 그래서 “RAG 는 별로” 라는 판정을 내리는 패턴. 이분들이 말하는 RAG 는 사실상 1층을 의미해요. 저도 이 의견에는 절반 동의합니다. 1층 단독 설계는 죽었어요. 다만 이분들이 놓치는 건, 그게 RAG 전체의 판정으로 이어지면 안 된다는 점이에요. 2~4층이 남아있습니다.
패턴 2 — “long context 가 RAG 를 대체한다” 는 주장. 이건 조금 더 이론적인 주장이에요. “100만 토큰이 넘는 컨텍스트가 있으면 전부 넣으면 되는데 왜 검색을 하느냐” 는 논리. 이 논리는 한 지점에서는 맞지만 (작은 코퍼스에서는 맞아요) 확장해서 “그러니까 RAG 가 필요 없다” 로 가면 잘못된 이분법이 됩니다. 다음 섹션에서 이 주장을 본격적으로 반박할 거예요.
패턴 3 — 특정 패러다임 제품을 보고 “이게 RAG 의 죽음이다” 라고 해석하는 경우. Claude Code 가 벡터 DB 없이 잘 돌아가는 걸 보고 “봐라, RAG 필요 없다” 라고 말하는 패턴이 가장 많아요. 이건 제가 앞에서 말한 대로 3층을 1층의 죽음으로 오해하는 건데, 3층도 RAG 다 라는 사실을 놓치면 이런 해석이 나와요. 검색이 여러 번 일어나고 모델이 주체가 됐을 뿐, retrieval 이라는 본질은 그대로입니다.
이 세 패턴을 묶으면 결론이 나와요. “RAG 죽었다” 를 주장하는 사람들이 공통적으로 놓치는 건 “RAG 라는 말이 층에 따라 다른 걸 가리킨다” 는 사실입니다. 1층만 보면서 전체를 판정하거나, long context 로 치환될 수 있다고 착각하거나, 3층을 RAG 바깥으로 밀어내면서 판정하거나. 이 세 실수 중 하나예요.
저는 이걸 악의적인 주장이라고 보지 않아요. 용어가 혼란스러운 탓이 커요. RAG 라는 단어 자체가 2020년에 등장한 이후로 내용이 계속 확장됐는데, 사람들의 머릿속 그림은 여전히 2022~2023년 버전 (1층) 에 머물러 있거든요. 현실이 움직인 속도를 담론이 못 따라간 상태인 거예요. 그래서 이런 글을 쓰는 게 필요한 거고요.
8. long context 가 RAG 를 대체할 수 있나 — 내 답: 아니다
이 질문을 한 섹션 통째로 할애해서 답할게요. 가장 자주 받는 질문이니까요. “Gemini 는 이미 2M 토큰이다. Claude 는 200K 를 넘었고. 이러면 그냥 전부 넣으면 되는데 왜 retrieval 을 하나.” 이 논리에 대한 제 답은 “아니다” 입니다. 세 가지 이유를 드릴게요.
이유 1 — 비용.
긴 컨텍스트는 공짜가 아니에요. 1M 토큰 프롬프트 한 번 돌리는 비용은 사용자당 쿼리당으로 계산하면 무시 못 할 숫자가 나옵니다. 10명짜리 사내 도구면 괜찮은데, 10만명이 쓰는 제품에서 매 쿼리마다 1M 을 넣으면 계산이 안 맞아요. 저는 이걸 실제로 프로덕션에서 돌려보고 포기하는 팀을 여러 개 봤습니다. “long context 로 다 해결된다” 는 아이디어는 pilot 단계까지는 매력적이다가 scale 단계에서 벽을 만나요.
retrieval 의 경제적 합리성이 여기서 되살아나요. 전체 코퍼스에서 관련 있는 부분만 뽑아서 10K~50K 토큰만 모델에 넣는 게 비용 면에서 확실히 유리해요. “quality-per-dollar” 를 계산하면 retrieval 이 이기는 지점이 꽤 많아요.
이유 2 — Lost in the middle.
M2 에서 길게 다뤘던 주제인데 여기서 다시 꺼낼 필요가 있어요. 모델이 긴 컨텍스트를 받았을 때 중간 부분의 정보를 무시하는 경향 이 여전히 있습니다. 2024~2025 년에 걸쳐 많이 개선됐지만 완전히 사라진 건 아니에요. 벤치마크를 보면 컨텍스트 앞쪽과 뒤쪽에 있는 정보는 모델이 잘 찾지만 중간에 묻힌 정보는 놓치는 비율이 여전해요.
그래서 100만 토큰을 통째로 넣어도 모델이 실제로 활용하는 건 일부예요. “다 넣어도 안 쓰는 건 왜 넣나” 가 retrieval 옹호 논리의 또 한 축이 됩니다. 관련 있는 정보를 앞쪽에 집중시켜서 넣는 게 모델 성능을 더 끌어올린다는 증거가 계속 쌓이고 있어요.
이유 3 — 실시간 지식 업데이트 불가.
이게 제가 제일 중요하게 생각하는 이유예요. Long context 접근은 “이 문서들을 프롬프트에 다 넣는다” 는 모델인데, 문서가 실시간으로 바뀌는 환경에서는 이 모델이 안 돌아갑니다.
예를 들어볼게요. 고객 지원 AI 를 만든다고 합시다. FAQ, 제품 매뉴얼, 정책 문서가 매일 갱신돼요. 새 제품 출시, 가격 변경, 정책 업데이트. Long context 로 다 넣는다 치면, 프롬프트 자체가 매일 바뀌어야 해요. 그러면 프롬프트 캐싱이 깨지고, 응답 지연이 생기고, 비용도 매번 다시 폭발합니다. 반대로 retrieval 구조에서는 인덱스만 업데이트하면 돼요. 실시간성이 필요한 환경에서 retrieval 은 long context 가 대체할 수 없는 역할을 합니다.
웹 검색은 더 극단적이에요. 웹은 매초 바뀌어요. Perplexity 나 Claude Research 가 매번 웹 검색을 돌리는 이유가 이거예요. 전체 웹을 모델에 학습시키거나 long context 에 넣는 건 원천적으로 불가능합니다. 실시간 지식이 필요한 한 retrieval 은 절대 사라지지 않아요.
이 세 이유를 묶으면 제 결론은 이렇습니다. Long context 는 retrieval 을 대체하지 않고, retrieval 의 범위를 좁힙니다. 예전에 retrieval 이 담당하던 영역 중 “작은 정적 코퍼스” 부분은 long context 로 빠졌어요. 그건 인정해야 합니다. 하지만 “대규모·동적·실시간” 이라는 나머지 영역은 retrieval 이 계속 가져갑니다. 그리고 그 영역은 시간이 갈수록 더 커지고 있어요. “죽기는커녕 자기 영역을 지키고 있는” 상태가 정확한 표현이에요.
9. 실무자가 지금 해야 할 3가지 판단
여기까지 온 독자분들은 이제 “RAG 죽었냐” 라는 질문에 휘둘릴 필요가 없어요. 대신 실무자로서 해야 할 판단이 있습니다. 세 가지로 정리할게요.
판단 1 — 당신 시스템은 지금 몇 층인가?
먼저 진단부터예요. 당신이 운영하거나 설계하고 있는 retrieval 시스템이 어느 층에 있는지 한 번 정확히 찍어보세요. 다음 질문으로 가늠할 수 있어요.
- 벡터 DB 에 chunk 를 넣어두고 top-k 로 한 번만 뽑아 프롬프트에 붙이는 구조라면 → 1층
- 엔티티·관계를 추출해서 그래프 구조를 얹고 있다면 → 2층
- 모델이 검색 함수를 스스로 호출하면서 여러 번 반복할 수 있다면 → 3층
- 특정 문서를 학습으로 모델에 녹이고 프롬프트에서 빼냈다면 → 4층
대부분의 경우 한 층이 아니라 여러 층의 혼합일 거예요. “주로 1층 + 부분적으로 3층” 같은 형태. 중요한 건 주력 층이 어딘가예요. 주력이 1층이면 이 글의 다음 판단을 꼭 하세요.
판단 2 — 다음에 어느 층으로 움직일 여력이 있나?
현재 층에서 한 단계 올릴 여력이 있는지 계산해봐요. 여력은 주로 세 축에서 결정돼요.
- 엔지니어링 리소스 — 2층·3층을 도입하려면 설계·구현 공수가 1층보다 훨씬 큽니다.
- 운영 비용 — 3층은 검색 호출이 중첩되면서 토큰 비용이 늘어요. 4층은 학습 비용이 듭니다.
- 도메인 적합성 — 모든 도메인에 모든 층이 맞는 건 아니에요. 관계 밀도가 낮은 FAQ 성 코퍼스에 GraphRAG 를 쌓는 건 과잉입니다.
여력이 있으면 한 층씩 올리세요. 저는 1층에 있는 팀한테 바로 4층 가자고 말하지 않아요. 보통 1층 → (필요하면) 2층 → 3층 이 가장 현실적인 경로입니다. 3층이 되면 1~2층이 자연스럽게 도구로 편입돼요.
판단 3 — 4층까지 갈 필요가 있는가?
이 질문은 많은 팀한테 “아니오” 가 답이에요. 4층은 아직 운영 부담이 크고, 이득이 나오는 조건이 제한적이에요. 대부분의 팀은 2~3층 혼합 이 답입니다.
4층이 필요한 조건을 다시 짚으면:
– 반복 참조되는 대형 정적 문서가 있고,
– 문서 업데이트 주기가 주 단위 이상으로 느리고,
– 사용자별 권한 분리가 단순하고,
– 프롬프트 토큰 비용이 누적되면 의미 있게 커지는 스케일.
이 네 조건이 다 맞는 프로젝트가 아니면 4층은 아직 미뤄도 돼요. 대신 “4층이 존재한다” 는 걸 알고 있기만 해도 설계 선택지가 넓어집니다. 지금 당장 가진 무기로 삼지 않더라도, 앞으로 1~2년 안에 꺼낼 수 있는 카드로 머릿속에 둬 두세요.
10. 2년 뒤 이 질문은 어떻게 바뀌어 있을까 — 내 예측
M9 를 쓰면서 제가 마지막으로 해두고 싶은 말은 이거예요. 2028년쯤이면 “RAG 는 죽었냐” 라는 질문 자체가 사라질 겁니다.
왜냐하면 그때가 되면 이 질문이 너무 모호해서 쓸 수 없게 될 거거든요. 2026년 지금도 이미 모호한데, 2~3년 더 지나면 사람들이 이 질문을 입에 올리지 않게 돼요. 대신 더 정확한 질문으로 대체될 거예요.
제 예측으로는 이런 질문들이 그 자리를 대신할 겁니다.
- “우리 팀 문서에는 어느 층이 맞나?”
- “이 문서는 retrieval 로 두고 저 문서는 LoRA 로 녹이는 게 비용 면에서 유리한가?”
- “이 에이전트의 검색 호출 횟수가 적정한가, 과한가?”
- “long context 와 retrieval 의 경계는 우리 워크로드에서 어디쯤인가?”
전부 층 단위 질문 이에요. “RAG 전체가 죽었냐 살았냐” 같은 거친 질문은 이런 세밀한 질문들에 자리를 내줄 겁니다. 어떤 기술 용어든 성숙하면 그렇게 돼요. “데이터베이스 는 죽었냐” 같은 질문을 요즘 아무도 안 하잖아요. 대신 “OLTP 는 뭘 쓸래, OLAP 는 뭘 쓸래, 벡터 DB 는 뭘 쓸래” 라고 묻죠. RAG 도 그렇게 세분화돼서 정착할 거예요.
그래서 제 최종 입장은 이래요. “RAG 죽었냐” 라는 질문은 2026년 기준으로는 절반만 참이다. 그리고 2028년쯤이 되면 그 질문 자체가 사라진다. 그때까지 실무자가 할 수 있는 최선은, 자기 시스템이 어느 층에 있는지 정확히 찍고, 층 단위로 움직이는 습관을 들이는 거예요.
11. 실무자 체크리스트 — 지금 5분 안에 자기 retrieval 시스템 진단하기
마지막으로 체크리스트 하나 드리고 마칠게요. 이 글을 덮기 전에 5분만 내서 직접 답해보시면 자기 시스템의 위치가 분명해집니다.
현재 상태 진단
– [ ] 우리 시스템에 벡터 DB 나 embedding 인덱스가 있나? (있으면 1층 요소 보유)
– [ ] 문서 간 관계를 명시적으로 추출해서 그래프 구조로 저장하고 있나? (있으면 2층)
– [ ] 모델이 검색 함수를 스스로 호출할 수 있는 구조인가? (그렇다면 3층)
– [ ] 특정 도메인 문서를 fine-tuning 이나 LoRA 로 모델에 녹이고 있나? (그렇다면 4층)
– [ ] 위 4개 중 주력 층이 어디인지 한 줄로 쓸 수 있나?
실패 패턴 자가 점검
– [ ] 1층만 쓰고 있는데 복잡한 질문에서 성능이 안 나오는 이슈가 반복되는가? (2~3층으로 움직일 시점)
– [ ] 응답에 환각이 섞이는데 RAG 가 막아줄 거라고 막연히 믿고 있나? (출처 검증 장치 추가 필요)
– [ ] embedding 모델이 우리 언어·도메인에 맞는지 마지막으로 테스트한 게 언제인가? (6개월 이상 전이면 다시 볼 때)
– [ ] 프롬프트에 넣는 토큰 양이 한 쿼리당 얼마인지 모르는 상태인가? (모르면 비용 폭증 위험)
다음 단계 결정
– [ ] 현재 층에서 다음 층으로 올릴 여력이 엔지니어링·비용·도메인 적합성 세 축에서 맞는가?
– [ ] 2~3층 혼합이 우리에게 최종 목표인가, 아니면 4층까지 필요한가?
– [ ] long context 로 대체 가능한 부분이 있나? 있다면 그 부분만 retrieval 에서 빼낼 수 있나?
이 세 블록에 답을 써보세요. 답이 안 나오는 항목이 있으면 그게 다음 달에 공부하거나 정리할 과제예요. RAG 에 대한 감각은 “죽었냐 살았냐” 를 판정하는 것 이 아니라, 자기 시스템의 층 구조를 정확히 찍고 움직이는 감각 에서 만들어집니다. 그 감각만 있으면 담론이 뭐라고 흔들려도 안 흔들려요.
한 문장 닫음: “RAG 는 죽었냐” 라는 질문에 제 답은, 죽은 건 1층뿐이고 2~4층은 오히려 확장 중이며, 2년 뒤엔 그 질문 자체가 사라질 거라는 겁니다. 지금부터는 “우리 시스템은 몇 층인가” 만 물어보시면 됩니다.
다음 읽기
- M10 — AI 공부 지도 전체 마무리 [준비 중] — 20부작의 마지막 편. F1 부터 M9 까지 걸어온 경로를 한 장의 지도로 마무리합니다. 독자분들이 스스로 다음 학습 경로를 그릴 수 있도록 하는 것이 목적이에요.
- M1 — Retrieval 4층 구조 — 이번 글의 전제를 처음 깐 편. 아직 안 읽으셨다면 이 M9 와 묶어서 읽으시길 권합니다.
- M2 — Long-context 와 Memory 는 같은 이야기인가 — 섹션 8 에서 다룬 long context 논의를 더 깊이 풀어둔 편이에요.
시리즈 처음부터: F1 — AI·ML·DL·LLM 용어 구분 · M1 — Retrieval 4층 · M2 — Long-context 와 Memory
자주 묻는 질문 (FAQ)
Q1. 저희 회사는 아직 1층인데, 지금 바로 3층으로 점프하는 게 맞나요?
대부분의 경우 아닙니다. 1층을 건너뛰고 3층으로 가면 검색 호출 주체만 모델로 바뀌고 기저 검색 품질은 그대로예요. 오히려 문제가 모델 안쪽으로 숨어서 디버깅이 더 어려워집니다. 저는 보통 이렇게 권해요. 1층을 먼저 제대로 (embedding 모델 도메인 맞춤, chunk 전략 튜닝, evaluation 셋 확보) 돌려 놓고, 그 위에 3층을 얹으세요. 1층이 부실한 채로 3층을 올리는 건 진흙 위에 지붕을 얹는 거랑 같아요.
Q2. “RAG 는 죽었다” 를 주장하는 글을 읽으면 설득력이 있어 보이는데, 제가 뭘 놓치고 있는 건가요?
거의 항상 층 구분이 빠져있기 때문이에요. 그 글이 주장하는 “RAG” 가 구체적으로 어느 층을 가리키는지 한 번 체크해보세요. 대부분 1층을 가리키고 있을 거예요. 1층에 대한 비판은 맞는 말이 많습니다. 다만 그 비판을 2~4층까지 확장하면 틀려요. 글을 읽을 때 “이 사람이 말하는 RAG 는 몇 층인가” 를 속으로 태깅하는 습관을 들이시면 이런 혼란이 빠르게 정리됩니다.
Q3. 2~3층 혼합으로 가려고 하는데, 어디서부터 공부를 시작하면 좋나요?
3층부터 손대시는 걸 추천합니다. 이유는 3층이 지금 가장 많이 쓰이고 있어서 학습 자료도 많고, 실제 제품 (Perplexity, Claude Research, Claude Code) 을 직접 써보면서 감을 잡을 수 있기 때문이에요. Anthropic 의 “How we built Claude Code” 같은 공식 엔지니어링 포스트가 좋은 출발점입니다. 3층에 대한 감이 잡힌 다음에 2층 (GraphRAG 공식 샘플 돌려보기) 로 넘어가면, 두 층이 어떻게 조합되는지가 자연스럽게 보여요.
뉴스레터 구독 안내
매주 월요일, AI·LLM·에이전트 관련 실무 정리를 한 통씩 보내드립니다. RAG 처럼 “죽었냐 살았냐” 논쟁이 자주 도는 주제들을 층 단위로 풀어 정리하는 일을 계속 하고 있어요. 이런 판단 지도를 차분히 쌓아가고 싶으시면 구독해 주세요.
시리즈 안내 — AI 공부 지도 20부작
– F1~F6: 기초 (LLM·Transformer·딥러닝·embedding·attention·gradient descent)
– B1~B3: 가교 (에이전트·프롬프트 작동원리·fine-tune 대 RAG 대 프롬프트)
– M1~M8: 실무 (retrieval 4층·long-context·평가·운영·비용·조직)
– M9: “RAG 는 죽었냐” — 태일러 본인의 답 (현재 글, 19/20)
– M10: 전체 지도 마무리
📚 전체 지도 보기
태일러 본인의 답: 1층 로컬 vector DB 일회성 retrieval은 경쟁력 잃음. 2~4층은 오히려 확장 중. long context가 RAG를 대체할 수 없는 이유.
소스 리스트
- 태일러 지식백과사전 — 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편은 위키 자료와 공식 논문·공식 문서를 근거로 정리한 체계적 학습 커리큘럼입니다.
