아직도 RAG 하고 계세요?

많은 AI 제품이 기본처럼 사용하는 RAG 아키텍처. 하지만 정말 필요한 선택일까요?
Ella's avatar
Mar 10, 2026
아직도 RAG 하고 계세요?

이 글은 커널스페이스 CEO이자 AI 박사인 정민규 대표의 개인 포스팅을 옮겨온 글입니다.

RAG는 이제 놓아줘야 할 LLM 초기의 과도기적 유산입니다.

아직도 많은 곳에서 RAG를 AI 제품의 표준 아키텍처처럼 이야기합니다. 임베딩 기반 RAG가 필요한 케이스는 생각보다 훨씬 적은데도 말입니다. RAG가 불필요한 이유는 두 가지입니다.

  1. 구조적으로 잘못된 접근이고,

  2. 성능도 기대만큼 나오지 않습니다.

맥락 없이 유사도만으로 청크를 덕지덕지 붙이는 방식은 오히려 모델의 맥락을 흐트러뜨려 성능을 저하시킵니다. 청크 분할 방식, 임베딩 모델 선택, similarity threshold 튜닝에 따라 결과가 크게 달라지고, 프로덕션에서 recall/precision을 안정적으로 유지하는 건 생각보다 훨씬 어렵습니다.

많은 팀이 RAG를 도입했다가 기대한 품질이 나오지 않아 파이프라인을 계속 덧대는 상황을 겪습니다.

구조적으로도 문제입니다. 임베딩은 스키마와 계층이 있는 데이터를 텍스트 덩어리로 비구조화하고 → 수백 차원의 벡터로 손실 압축한 뒤 → cosine similarity로 근사 검색합니다. 정확한 길이 있는데 눈 감고 걷는 방식입니다.
본질은 오히려 단순합니다.

구조가 있다면, LLM이 구조를 타게 하세요.

사람은 정보를 어떻게 찾나요? 책의 목차를 보고, 폴더를 열고, 항목을 따라 내려갑니다. 대부분의 데이터는 이미 그런 구조를 갖추고 있습니다. SQL의 JOINWHERE, 파일시스템 탐색, 문서의 계층과 메타데이터, 그래프의 엣지 순회. 이것들은 확정적이고 정확합니다. LLM이 스스로 탐색할 수 있도록 툴만 잘 쥐어주면 됩니다. DB를 조회하게 하거나, 파일시스템을 탐색하게 하거나, 문서의 계층 구조를 따라 내려가게 하세요. Claude Code는 수백만 줄의 코드베이스를 벡터 없이 GlobGrep만으로 탐색합니다. 창시자 Boris Cherny는 X에서 이렇게 밝혔습니다.

"초기 버전은 RAG와 로컬 벡터 DB를 썼지만, Agentic Search가 훨씬 낫다는 걸 금방 알게 됐다." (출처)

구조가 없다면, 만들어서 타게 하세요.

대부분의 데이터는 생각보다 자연스럽게 구조를 뽑아낼 수 있습니다. 날짜·출처·타입 같은 메타데이터를 스키마로 정의하거나, 정규표현식과 파싱으로 반복 패턴에서 필드를 추출하거나, 관계 중심 도메인이라면 Knowledge Graph로 엣지를 명시화할 수 있습니다. 어떻게 해서든 데이터에 계층 구조를 만들 수 있다면 이 구조를 LLM이 활용하게만 해도 훨씬 효율적이고 맥락에 맞는 정보가 추출됩니다. 그래도 안 된다면 BM25 같은 텍스트 검색을 병행할 수도 있습니다. 임베딩이 정말 필요한 순간은 이 모든 방법이 소진된 이후입니다.

어쩌면 검색 자체가 필요하지 않을 수도 있습니다. 데이터가 크지 않다면 프롬프트 캐싱이 더 효율적일 수 있기 때문입니다. 최신 모델들인 GPT-5.4, Claude Opus 4.6, Gemini 3.1 Pro 모두 100만 토큰 이상을 지원합니다. 웬만한 데이터는 통째로 넣어도 됩니다. 웬만한 LLM은 캐시 히트 시 토큰 비용이 90% 절감되고, 모델이 정보 유실 없이 전체 맥락을 정확하게 봅니다.

진짜 AI native 설계는 판단과 탐색의 로직을 LLM에 과감히 넘기는 것에서 시작합니다. 토큰 사용을 두려워할 필요도 없습니다. 막상 해보면 속도나 비용에서도 RAG와 큰 차이가 없는 경우가 대부분이고, 오히려 파이프라인 관리 비용을 생각하면 비효율적인 경우가 더 많습니다. 훨씬 단순한 설계로 빠르고 정확하며 효율적인 구조를 운영할 수 있습니다. "AI 제품이면 일단 RAG"라는 관성이 데이터 설계에 대한 고민을 대체하고 있진 않은지, 한번쯤 돌아볼 필요가 있다고 생각합니다.

지금 설계를 고민 중인 에이전트 시스템이 있다면, 이번엔 RAG 없이 한번 설계해보시면 어떨까요?


그리디 AI는 구조를 이해합니다.

스프레드시트는 대표적인 구조적 데이터입니다. 이미 가로 축과 세로 축, 좌표라는 구조를 가지고 있죠. 그 덕분에 전체적인 구조만 보여주면 전체 데이터를 보지 않아도 효율적인 탐색이 가능합니다. 그리디가 시트에서 특정 행들을 골라내는 방식은 다음과 같습니다.

1행의 값이 "거래처"인 열을 찾아서, 그 값이 "OO은행"인 행을 모두 찾는다.

사람이 시트를 탐색하는 과정과 상당히 흡사합니다. 게다가 이 과정은 AI가 가장 잘하는 코딩을 사용하면 단숨에 해낼 수 있습니다.

코드와 구조를 이용해서 검색하게 되면 RAG보다 한 차원 더 유연한 조작이 가능해집니다. 가령, 위 예시에서 찾은 행들의 좌표를 기억해뒀다가 다음 코드에 활용할 수도 있고, RAG에서는 불가능한 값이 누락된 셀을 찾는 것, 배경색이 파란색인 셀을 찾는 것도 얼마든지 가능합니다.

그리디를 활용한 검색과 연산

그리디는 스프레드시트라는 구조가 가진 정보와 AI의 추론 능력을 최대한으로 활용하여, 벡터검색 없이도 필요한 값을 정확히 찾아냅니다.

RAG와의 작별인사를 건네는 2026년의 AI 트렌드, 그 중심에 그리디가 있습니다.

Share article